Visión Computacional en Obra: Qué Dice la Evidencia

No existe evidencia publicada y creíble de que la visión computacional reduzca los accidentes de construcción. La tecnología detecta personas, equipos y elementos de protección en un cuadro de video — esa parte funciona y lleva años funcionando. Lo que nadie ha demostrado con metodología publicada es el paso siguiente: que alertar sobre esas detecciones produzca menos lesiones. La industria ha estado vendiendo lo segundo mientras demuestra lo primero.

Resumen rápido

• La visión computacional responde de forma confiable “¿hay una persona en esta zona?”. No responde de forma confiable “¿está esta persona en peligro?”.
• Una revisión técnica del campo de 2025 no encontró métricas de éxito a escala de producción para monitoreo de seguridad en construcción: ni cifras de reducción de incidentes, ni ROI, ni resultados de casos.
• Las restricciones técnicas documentadas son oclusión, degradación por clima y falsos positivos en entornos visualmente complejos, y las tres empeoran en una obra que se reorganiza cada semana.
• En 2024 murieron 1.032 trabajadores de construcción y extracción, 370 de ellos por caídas. El problema es real, y por eso una solución sobrevendida cuesta algo.
• Los casos de uso defendibles son de detección de presencia: seguridad perimetral, ubicación de equipos, acceso a zonas restringidas. Son verificables y no dependen de inferir comportamiento.

Es una instancia de un patrón que recorre todo este vertical: la capacidad que se demuestra y el resultado que se vende no son lo mismo. Más sobre dónde queda ese hueco en qué construyen las empresas de construcción cuando su plataforma se queda corta.

¿Qué dice realmente la investigación publicada?

Una revisión técnica de 2025 sobre visión computacional para monitoreo de seguridad en construcción cataloga las capacidades en detalle: detección y reconocimiento de objetos, reconocimiento de acciones y actividades, detección de anomalías — identificar trabajadores, equipos, cumplimiento de EPP y señalar conductas inseguras.

No contiene ningún resultado cuantificado. Ni porcentaje de reducción de incidentes, ni cifra de retorno, ni resultados de casos de estudio. La revisión afirma con claridad que todavía no existen métricas de éxito a escala de producción para esta tecnología en construcción.

No es un vacío de un solo artículo. Buscar estudios revisados por pares o de la industria que vinculen el monitoreo por cámaras con una reducción medible de incidentes en obra devuelve afirmaciones de proveedores sin metodología. Una cifra muy difundida —que se puede prevenir el 80% de los accidentes— se rastrea hasta una entrada de blog sin estudio detrás. No debería citarse, y se cita constantemente.

El problema que busca resolver no es hipotético. La Oficina de Estadísticas Laborales registró 1.032 muertes entre trabajadores de construcción y extracción en 2024, 370 de ellas por caídas, resbalones y tropiezos. Construcción y extracción fue el segundo grupo ocupacional con más muertes del país. Cuando lo que está en juego es eso, una solución sobrevendida no es una exageración inofensiva: desplaza atención y presupuesto de intervenciones que sí funcionan.

¿Dónde funciona de verdad la tecnología?

La distinción que importa es entre presencia y comportamiento.

Las preguntas de presencia son problemas de detección de objetos: ¿hay una persona en este cuadro?, ¿está dentro de una zona demarcada?, ¿está la excavadora en su posición asignada?, ¿hay un casco sobre esa cabeza en esta imagen? Tienen soluciones maduras. Los modelos de detección llevan años siendo confiables en esta clase de problema, y lo que queda es afinamiento e integración, no investigación.

Las preguntas de comportamiento son de otra naturaleza: ¿está este trabajador en riesgo?, ¿es insegura esa acción?, ¿está esta situación por volverse peligrosa? Responderlas exige inferir intención y predecir un estado futuro cercano a partir de un cuadro de video. Eso no es un problema resuelto en ningún dominio, y la construcción es un entorno más difícil que la mayoría.

Casi toda afirmación ambiciosa de seguridad en el mercado depende de la segunda categoría mientras las demostraciones muestran la primera. CodeBranch dimensiona los proyectos de visión computacional alrededor de la primera, porque es la parte que se puede especificar, probar y verificar contra un criterio de aceptación.

¿Qué sabemos de construir uno de estos sistemas?

CodeBranch construyó un sistema de visión computacional en producción para detección de presencia — y vale la pena ser precisos sobre el contexto, porque no era una obra. La plataforma de videovigilancia con IA es un sistema de detección de intrusos: análisis en tiempo real de flujos de video identificando presencia humana no autorizada en zonas demarcadas, sobre un modelo YOLOv3 afinado a medida con OpenCV, corriendo en una LAN que soporta hasta 64 cámaras simultáneas, con alertas por múltiples canales.

Tres cosas de ese trabajo se trasladan directamente a la pregunta de obra.

El modelo tuvo que afinarse para su entorno específico. No configurarse: afinarse. Y eso fue en un escenario controlado, con cámaras fijas e iluminación estable. Una obra se reorganiza cada semana, lo que invalida ángulos de cámara y definiciones de zona a medida que avanza el trabajo. El costo de afinamiento que existe en un entorno estable es un costo recurrente en uno inestable.

El hardware de cámaras es heterogéneo y eso condiciona la arquitectura. Algunas cámaras soportan detección de eventos nativa; otras hay que consultarlas periódicamente. En una obra con equipos de distintos proveedores instalados en distintos momentos, esa variación es el caso normal, y determina el diseño más que la elección del modelo.

La detección es la mitad fácil del sistema. Lo que tomó tiempo de ingeniería fue el pipeline de alertas: a quién se notifica, por cuál canal, cuántos contactos, qué pasa cuando el primero no responde. Eso también es cierto para seguridad en obra, y es la mitad que determina si una detección cambia algo. Un sistema que identifica un peligro perfectamente y alerta a alguien que no está en posición de actuar produjo un registro en un log, no un resultado de seguridad.

¿Por qué una obra es más difícil que una instalación fija?

Tres restricciones, todas documentadas y todas peores en una obra que en un edificio.

Oclusión. Los objetos bloquean la vista de las cámaras, y en una obra activa los objetos se mueven. Una cámara con línea de vista despejada el lunes está detrás de una estiba de material el jueves.

Clima. La lluvia, el polvo y la poca luz degradan la calidad de imagen, y la degradación no es uniforme: afecta a unas clases de detección más que a otras, así que la precisión cae de forma despareja y difícil de predecir desde las condiciones de prueba.

Complejidad visual. Las obras son desordenadas, lo que produce falsos positivos y falsos negativos. Los falsos positivos son la falla más corrosiva: un sistema que grita lobo se empieza a ignorar, y una vez la cuadrilla aprende a descartar las alertas, la detección técnicamente correcta que viene después se descarta también. CodeBranch trata el presupuesto de falsos positivos como una restricción de diseño fijada antes de elegir el modelo, no como un número que se reporta al final.

¿Qué debería comprar realmente un contratista?

Dimensione el proyecto alrededor de la detección de presencia, donde la tecnología es madura y el valor es verificable.

Seguridad perimetral fuera de horario es el caso más claro. Es el mismo problema para el que se construyó la plataforma descrita arriba, el entorno es más controlado de noche, y el robo y el acceso no autorizado son resultados medibles: se pueden contar antes y después.

Ubicación y utilización de equipos es un problema de detección con vínculo directo al costo. La maquinaria ociosa y las herramientas perdidas son cuantificables, y la inferencia requerida es superficial.

Acceso a zonas restringidas funciona cuando las zonas son estables el tiempo suficiente para valer la pena definirlas. En una obra con un área peligrosa fija —una excavación, el radio de una grúa— la detección de presencia en un límite es exactamente lo que la tecnología hace bien.

Lo que no dimensionaría alrededor de la reducción de accidentes, al menos no como criterio de éxito, es cualquier cosa cuyo valor dependa de predecir comportamiento inseguro. No porque la ambición esté mal, sino porque no hay forma de verificar la afirmación del proveedor ni el resultado propio, y un programa de seguridad construido sobre un insumo no verificable es peor que uno construido sobre uno más pequeño pero verificado.

¿Qué debería preguntarle a un proveedor?

Tres preguntas, y la tercera es la prueba.

Qué detecta exactamente el modelo, expresado como clases de objetos y no como resultados. Una respuesta precisa aquí es buena señal.

Cuál es la tasa de falsos positivos en condiciones parecidas a las suyas —clima, iluminación, densidad de obra— y qué pasa operativamente cuando se dispara de forma equivocada.

Y qué evidencia publicada conecta la detección con la reducción de incidentes. Un proveedor que responde las dos primeras con precisión y reconoce que la tercera no tiene buena respuesta pública le está diciendo la verdad sobre el estado del campo. Uno que produce un porcentaje debería poder mostrar el estudio detrás.

CodeBranch aplica ese estándar a su propio trabajo, y por eso este artículo reporta que falta la evidencia en vez de llenar el vacío con una cifra que sería más fácil de vender. La misma disciplina condiciona cómo dimensiona el software para empresas de construcción: alrededor de capacidades que se pueden especificar en un criterio de aceptación, no alrededor de resultados que nadie puede verificar.

CodeBranch es un partner de desarrollo de software agéntico para empresas de EE.UU., desde construir nuevos productos hasta escalar los existentes — equipos senior en Colombia, en horario de EE.UU. Entregamos con pipelines nativos de IA y nuestro propio framework Spec-Driven Development, con calidad y seguridad en cada línea de código.