KANAN AI — Plan de Trabajo y Capacitación Técnica del MVP
Documento de planeación interna · v2 · Junio 2026 Confidencial — Inmersys
1. Objetivo del documento
El presente reporte define el plan de capacitación técnica y construcción del MVP de Kanan AI, alineado al cronograma de 16 semanas y a la estructura de tres fases establecidos en el pitch deck (Junio 2026). El documento responde a tres preguntas: si el proyecto es técnicamente viable, qué debe aprenderse para ejecutarlo, y cómo se distribuye el trabajo dentro del marco temporal propuesto.
A diferencia de la propuesta comercial, este plan asume que el desarrollo de la capa de visión se realiza en su totalidad con recursos internos, sin especialista externo. El rol de "Especialista CV" contemplado en el pitch deck queda asignado al responsable técnico del proyecto (Isai), quien parte de un perfil full-stack web sin experiencia previa en Python ni en visión por computadora. En consecuencia, la curva de aprendizaje se integra dentro del cronograma de construcción y no como una etapa previa independiente.
2. Parámetros y supuestos confirmados
Recursos de cómputo. El desarrollo se realiza sobre una estación de trabajo equipada con GPU NVIDIA RTX 3070 Ti (8 GB de VRAM). Esta capacidad es suficiente para entrenar y ajustar modelos YOLO en variantes nano, small y medium con resoluciones estándar (~640 px) y lotes moderados, así como para ejecutar inferencia en tiempo real sobre uno o varios flujos de video. La limitación de 8 GB restringe el uso de modelos de mayor tamaño (variantes large/extra-large) o resoluciones muy altas, y hace que el entrenamiento sobre datasets grandes sea más lento que en hardware de centro de datos, pero no representa un obstáculo para el alcance del MVP. La estrategia de cómputo para despliegue multiplanta en producción (servidor o edge) se evalúa en una fase posterior.
Material de origen. El desarrollo arranca con video pregrabado. La integración con flujos RTSP en vivo se incorpora más adelante; durante la construcción del MVP, las pruebas de detección se realizan sobre grabaciones representativas de planta o centro logístico.
Equipo. Ejecución 100% interna. Toda referencia a contratación de especialista externo o a evaluación de candidatos queda fuera del alcance de este plan. El responsable técnico concentra el desarrollo de la capa de visión; el resto del equipo interno aporta en backend, CMS, base de datos y dashboard según su experiencia web previa.
Marco temporal. 16 semanas, organizadas en tres fases conforme al pitch deck. No existe una fecha calendario fija; la referencia es el número de semanas. El plan a continuación respeta esa estructura e indica explícitamente los puntos en los que el cronograma resulta ajustado.
3. Evaluación de viabilidad técnica
El proyecto es técnicamente viable con herramientas maduras y disponibles. La viabilidad varía por módulo según su complejidad de implementación:
| Módulo | Complejidad | Fundamento técnico | Principal reto |
|---|---|---|---|
| Zonas y control de acceso | Baja | Detección de persona (clase nativa de COCO) + polígono de exclusión + seguimiento (tracking) para eventos de entrada/salida | Definición correcta de zonas y manejo de oclusiones |
| Detección de EPP (casco, chaleco) | Media | Detección con modelo entrenado sobre clases específicas; existen datasets públicos de referencia | Calidad y representatividad de los datos de entrenamiento |
| Ergonomía | Media | Estimación de pose corporal + cálculo de ángulos articulares + criterio de evaluación postural (estándares RULA/REBA) | Robustez de la estimación de pose ante ángulos de cámara y oclusiones |
| Montacargas y control vehicular | Media-alta | Detección entrenada sobre clase no nativa + seguimiento + lógica espacial de interacción peatón-vehículo | Requiere datos propios; la interacción peatón-vehículo añade complejidad de tracking y reglas |
Los módulos de conducta segura y analytics avanzado descritos en el pitch deck no forman parte del alcance de construcción de las 16 semanas y se posponen a fases posteriores. El módulo de housekeeping no se contempla en este plan.
Conclusión de viabilidad: los cuatro módulos del MVP (zonas, EPP, ergonomía, montacargas) son construibles con el stack y el hardware definidos. El factor crítico no es el algoritmo, sino la disponibilidad de datos propios anotados y la validación sobre material real de planta.
4. Mapa de las tres fases (alineado al pitch deck)
| Fase | Semanas | Foco | Entregable principal |
|---|---|---|---|
| Fase 0 — Arranque | 1–2 | Capacitación base + arquitectura + viabilidad demostrada | Demos de viabilidad funcionando + arquitectura definida |
| Fase 1 — MVP Base | 3–8 | Zonas, EPP, ergonomía, dashboard + CMS, validación | MVP de tres módulos sobre video grabado + dashboard |
| Fase 2 — Montacargas e integración | 9–16 | Detección vehicular, motor de reglas, integraciones EHS, iteración | MVP completo de cuatro módulos + integraciones |
Evaluación de realismo del calendario
El cronograma de 16 semanas es alcanzable, con tensión concentrada en las Fases 0 y 1. La razón es que la propuesta original dimensionaba estas fases para un especialista de CV ya formado; al asumir ese rol una persona en proceso de aprendizaje, la capacitación debe ocurrir en paralelo a la construcción.
Puntos donde el calendario queda apretado y ajustes recomendados:
- Fase 0 (2 semanas) es el punto más ajustado. Pasar de cero conocimiento de Python y visión por computadora a "listo para construir" en dos semanas es insuficiente. Se recomienda tratar la Fase 0 como un bloque de 2 a 3 semanas, absorbiendo la semana adicional del margen de la Fase 2 (que es más holgada), o bien ejecutar los demos de viabilidad en paralelo a la capacitación base.
- Fase 1 (6 semanas) es viable pero sin holgura. Construir tres módulos, el dashboard y la validación en seis semanas exige que cada módulo se mantenga acotado y que el entrenamiento del modelo de EPP (la tarea con mayor riesgo de tiempo, por la anotación de datos) no se extienda. La fortaleza web del equipo interno acelera la parte de dashboard y CMS, lo que compensa parcialmente.
- Fase 2 (8 semanas) es la más holgada y absorbe bien la complejidad de montacargas, el motor de reglas y las integraciones.
Recomendaciones transversales para sostener el calendario:
- Usar video grabado para la "prueba en planta" del MVP y posponer la integración con RTSP en vivo a la Fase 2.
- Acotar estrictamente el alcance de cada módulo; evitar funcionalidades no esenciales en la primera versión.
- Reconocer que los datos anotados son el cuello de botella real y reservar tiempo explícito para su preparación.
5. Fase 0 — Arranque y capacitación base (semanas 1–2, recomendado 1–3)
Objetivo. Adquirir el dominio mínimo del stack para construir, definir la arquitectura del sistema y demostrar la viabilidad de cada capacidad con prototipos pequeños.
Capacitación (qué se aprende).
- Python idiomático orientado a quien ya programa: estructuras de datos, entornos virtuales, gestión de paquetes, manejo de imágenes como arreglos con NumPy.
- OpenCV: lectura de video, manipulación de fotogramas, dibujo de regiones.
- Ultralytics YOLO: ejecución de modelos preentrenados (detección de personas) sin entrenamiento propio.
- MediaPipe (o YOLO-Pose): estimación de pose corporal.
- Streamlit o Gradio: construcción rápida de interfaces de demostración.
Trabajo (qué se construye).
- Demo de zona de peligro: detección de persona preentrenada + polígono + verificación de entrada.
- Demo de EPP: detección de casco/chaleco con dataset o modelo público.
- Demo de ergonomía: estimación de pose + cálculo de ángulos.
- Demo de montacargas: ajuste mínimo o modelo comunitario.
- Definición de la arquitectura del sistema (ver sección 8).
Entregable. Cuatro demos de viabilidad ejecutándose sobre video grabado, una interfaz de demostración integrada y un documento de arquitectura. Este entregable cumple simultáneamente la función de "viabilidad demostrada" y de cierre de la capacitación base.
6. Fase 1 — MVP Base (semanas 3–8)
Objetivo. Construir la versión funcional de los tres módulos base sobre una arquitectura común, junto con el dashboard y el CMS, y validar sobre material grabado.
Capacitación (qué se profundiza durante esta fase).
- Fundamentos de visión por computadora: detección frente a segmentación, pose y seguimiento; métricas de evaluación (IoU, mAP, precisión, recall), umbral de confianza y supresión de no-máximos (NMS).
- YOLO en profundidad: formato de dataset, anotación (Roboflow, CVAT o Label Studio), entrenamiento y ajuste fino, aumento de datos y evaluación.
- Seguimiento (tracking) con ByteTrack o BoT-SORT, necesario para contar personas y generar eventos de entrada y salida de zona a lo largo del tiempo.
- Ergonomía aplicada: implementación de un sistema de puntuación postural basado en estándares RULA/REBA.
Trabajo (qué se construye), en orden de complejidad creciente.
- Zonas y control de acceso. Es el primer módulo porque es el más sólido y permite construir la columna vertebral del pipeline (ingesta → inferencia → lógica de eventos → API) que reutilizan los demás módulos.
- Detección de EPP. Modelo propio de casco y chaleco entrenado sobre la misma arquitectura. Tarea con mayor riesgo de tiempo por la anotación de datos.
- Ergonomía. Estimación de pose y evaluación postural.
- Dashboard y CMS. Construido con la experiencia web del equipo interno; representa una ventaja de velocidad en esta fase.
- Validación. Pruebas sobre video grabado representativo, con métricas medidas por módulo.
Entregable. MVP funcional de tres módulos (zonas, EPP, ergonomía) integrado con dashboard y CMS, validado sobre material grabado, con métricas documentadas.
7. Fase 2 — Montacargas e integración (semanas 9–16)
Objetivo. Incorporar el módulo de mayor complejidad, formalizar la lógica de negocio mediante un motor de reglas, integrar con sistemas EHS e iterar.
Capacitación (qué se profundiza durante esta fase).
- Manejo de flujos RTSP en condiciones de producción: reconexión automática, manejo de fotogramas perdidos, latencia, uso de FFmpeg o GStreamer.
- Optimización de inferencia: exportación a ONNX, aceleración con TensorRT, y criterios de decisión entre cómputo en servidor y en edge para el despliegue eventual.
- Arquitectura de integración: conexión del servicio de visión con backend, colas de eventos y sistemas externos (EHS, ERP).
Trabajo (qué se construye).
- Detección de montacargas y control vehicular, incluyendo la lógica espacial de interacción peatón-vehículo. Requiere preparación de datos propios.
- Motor de reglas configurable por zona, turno y nivel de riesgo, que traduce detecciones en alertas e incidencias.
- Integraciones EHS y, en su caso, la primera conexión con RTSP en vivo.
- Iteración sobre los cuatro módulos a partir de la validación con material real, endurecimiento y ajuste de precisión.
Entregable. MVP completo de cuatro módulos con motor de reglas e integraciones, listo para piloto.
8. Arquitectura de referencia
Cámara / video → Ingesta → Servicio de inferencia (Python + YOLO + tracking)
→ Motor de reglas / eventos → API → Backend · CMS · Base de datos → Dashboard
La capa de visión (Python) constituye el componente nuevo del sistema. Desde la API hacia la derecha, la arquitectura corresponde al dominio web que el equipo interno ya domina, lo que permite distribuir el esfuerzo de acuerdo con las fortalezas existentes.
Stack tecnológico.
- Lenguaje: Python.
- Visión: OpenCV, Ultralytics YOLO, MediaPipe (pose).
- Seguimiento: ByteTrack / BoT-SORT (integrados en Ultralytics).
- Anotación de datos: Roboflow, CVAT o Label Studio.
- Interfaces de demostración: Streamlit o Gradio.
- Optimización: ONNX, TensorRT (sobre la GPU disponible).
- Integración: stack web interno (API, base de datos, CMS, dashboard).
9. Riesgos y recomendaciones
- Compresión de la capacitación. Aprender y construir en paralelo es el principal riesgo de calendario. Mitigación: tratar la Fase 0 como bloque de 2–3 semanas y acotar el alcance de cada módulo.
- Disponibilidad de datos. El desempeño de los módulos de EPP y montacargas depende de datos propios anotados y representativos de las plantas objetivo. El modelo es una fracción menor del esfuerzo frente a la preparación y validación de datos.
- Brecha entre video grabado y RTSP en vivo. Trabajar sobre grabaciones simplifica el desarrollo, pero los flujos en vivo introducen problemas de reconexión, latencia y pérdida de fotogramas. Posponer esta integración es razonable, pero debe asumirse como trabajo pendiente explícito, no resuelto.
- Límite de VRAM (8 GB). Suficiente para el MVP. Para despliegue multiplanta y multicámara en producción se requerirá una estrategia de cómputo dedicada.
- Privacidad y cumplimiento. El sistema procesa imágenes de trabajadores. Las implicaciones legales y de privacidad deben evaluarse antes del despliegue en planta.
10. Currículo de capacitación (referencia consolidada)
| Bloque | Contenido | Fase |
|---|---|---|
| Python + NumPy | Sintaxis idiomática, entornos, imágenes como arreglos | 0 |
| OpenCV | Lectura de video, manipulación de fotogramas | 0 |
| YOLO preentrenado | Inferencia básica, detección de personas | 0 |
| Pose (MediaPipe / YOLO-Pose) | Estimación de pose, ángulos articulares | 0 |
| Fundamentos de CV | Detección/segmentación/pose/tracking, métricas (IoU, mAP, NMS) | 1 |
| YOLO avanzado | Dataset, anotación, entrenamiento, ajuste fino, evaluación | 1 |
| Tracking | ByteTrack / BoT-SORT, eventos temporales | 1 |
| Ergonomía aplicada | RULA / REBA | 1 |
| RTSP en producción | Reconexión, latencia, FFmpeg / GStreamer | 2 |
| Optimización | ONNX, TensorRT, edge vs. servidor | 2 |
| Arquitectura de integración | Conexión visión ↔ backend ↔ EHS | 2 |
Recursos de aprendizaje (seleccionados por bloque).
-
OpenCV y YOLO (Fases 0–1): curso "Especialización en Visión Artificial 2025" (Udemy, español). Se aprovechan las secciones de procesamiento digital de imágenes, OpenCV, contornos y prueba de polígono de puntos —incluido el ejemplo de videovigilancia con detección de personas y zona segura— así como la sección completa de YOLO (preparación de CUDA para GPU NVIDIA, instalación de PyTorch, entrenamiento de modelo propio, Roboflow, métricas de precisión/recall y contabilización por zonas y de entrantes/salientes). Se omiten las secciones de Python básico, SQL/SQLite y Raspberry Pi por quedar fuera del alcance.
-
Ergonomía / estimación de pose (Fases 0–1): tutorial "Building a Body Posture Analysis System using MediaPipe" (LearnOpenCV, inglés) como referencia práctica principal; implementa directamente la medición de ángulos de inclinación de cuello y torso, el umbral de mala postura y la medición de tiempo en postura, que corresponde al caso de uso del módulo de ergonomía. Como complemento conceptual para la lógica de puntuación de riesgo, el artículo "Ergonomic Risk Assessment Using Human Pose Estimation with MediaPipe Pose" (ACM, 2024), que documenta la integración de pose con los métodos OWAS, RULA y REBA. Como base de código mínima para la función de cálculo de ángulo articular (hombro–cadera–rodilla–tobillo), el repositorio "Squats-angle-detection-using-OpenCV-and-mediapipe".
- Nota técnica: la API clásica
mp.solutions.posecontinúa operativa pero quedó deprecada en mayo de 2023 a favor de la nueva API de MediaPipe Tasks (Pose Landmarker); debe usarse la versión vigente. Alternativa a evaluar: YOLO-Pose de Ultralytics, que permite realizar la estimación de pose sobre el mismo framework empleado en los demás módulos, unificando el stack.
- Nota técnica: la API clásica
-
Referencias base: documentación oficial de Ultralytics, OpenCV y MediaPipe; tutorial oficial de Python y material de NumPy; Roboflow para anotación y datasets; estándares RULA y REBA para la lógica de ergonomía.
11. Próximos pasos
- Confirmar si la Fase 0 se ejecuta como bloque de 2 o de 3 semanas, ajustando el resto del cronograma en consecuencia.
- Definir el origen del material grabado de planta para entrenamiento y validación.
- Detallar el plan de la Semana 1 (instalación de entorno, primeras ejecuciones, orden de tareas) como guía de arranque.