Visión por computador en industria: casos reales y ROI

Más allá del proof of concept

La visión por computador tiene un problema de credibilidad. Hay miles de demos impresionantes en LinkedIn: un modelo que detecta grietas en puentes, otro que cuenta personas en una tienda, otro que identifica defectos en una línea de producción. Lo que falta en esas demos son tres cosas: el coste real de operarlo, la precisión real en condiciones de producción (no en el dataset curado), y los números que demuestran que la inversión se recupera.

Este artículo documenta tres implementaciones reales en sectores diferentes, con sus números reales. No son proyectos hipotéticos. Son sistemas que procesan imágenes todos los días y generan valor medible.

Caso 1: Seguimiento de progreso de obra (construcción)

El problema

Un promotor inmobiliario con 6 obras simultáneas necesitaba verificar el avance real de cada obra contra el cronograma. El método existente: un jefe de obra visita cada obra semanalmente, toma fotos, escribe un informe, y lo envía por email. El promotor recibe 6 informes subjetivos con 3-5 días de retraso.

Las consecuencias de no detectar retrasos a tiempo: penalizaciones contractuales de hasta 1.500 euros diarios por obra, sobrecostes por re-planificación, y tensión con compradores que esperan fechas de entrega.

La solución

Cámaras fijas instaladas en cada obra (una por cada fachada principal, típicamente 4 por obra) capturan imágenes cada hora. Un modelo de detección de objetos entrenado con YOLOv8 identifica elementos estructurales: pilares, forjados, cerramientos, cubiertas, carpintería. Un segundo modelo compara el estado detectado contra el BIM del proyecto y calcula el porcentaje de avance por fase.

El pipeline es: cámara -> almacenamiento en S3 -> inferencia en GPU (un T4 de AWS) -> comparación con BIM -> dashboard en Grafana con porcentaje de avance por obra y por fase -> alertas si el avance real diverge del planificado más de un 5%.

La precisión del modelo en producción: 91.4% en detección de elementos estructurales (medido contra inspección manual trimestral). El error se concentra en fases tempranas (cimentación) donde los elementos son visualmente ambiguos desde cámaras fijas. En fases de estructura y acabados, la precisión sube al 95.8%.

El ROI

Costes:

• Hardware: 24 cámaras (4 por obra x 6 obras) a 280 euros cada una = 6.720 euros.
• Infraestructura cloud: GPU T4 spot instance + almacenamiento = 340 euros/mes.
• Desarrollo e integración: 35.000 euros (una vez).
• Mantenimiento: 2.000 euros/mes (monitorización, re-entrenamiento trimestral).

Ahorros:

• Detección temprana de retrasos: reducción del 40% en penalizaciones contractuales. El promotor pagaba una media de 22.000 euros anuales en penalizaciones. Reducción: 8.800 euros/año.
• Eliminación de 80% de visitas físicas del jefe de obra (solo necesita visitar cuando el sistema detecta anomalías). Ahorro en tiempo y desplazamientos: 14.400 euros/año.
• Mejora en planificación: reducción del 15% en sobrecostes por re-planificación. Ahorro estimado: 45.000 euros/año.

Payback: El coste total del primer año (hardware + desarrollo + operación) es aproximadamente 65.000 euros. El ahorro anual es 68.200 euros. Payback en 11.4 meses. A partir del segundo año, el coste operativo es 28.000 euros contra un ahorro de 68.200. El ROI neto es de 144%.

Caso 2: Monitorización de estanterías (retail)

El problema

Una cadena de supermercados con 45 tiendas perdía un estimado del 3.2% de ventas por roturas de stock no detectadas. Los lineales vacíos representan ventas perdidas directas. El método existente: reposición programada cada 4 horas y reportes manuales de los empleados de planta. Los vacíos entre reposiciones no se detectaban hasta que un cliente se quejaba o hasta el siguiente ciclo.

La solución

Cámaras existentes de seguridad (ya instaladas en todas las tiendas) reutilizadas para monitorización de lineales. Un modelo de detección de vacíos entrenado con un dataset propio de 12.000 imágenes etiquetadas por personal de la cadena. El modelo detecta secciones de estantería vacías y las cruza con el planograma para identificar qué producto falta.

El pipeline procesa una imagen por pasillo cada 15 minutos. Cuando detecta un vacío que persiste en dos capturas consecutivas (30 minutos), genera una alerta al equipo de reposición con la ubicación y el producto identificado.

La precisión: 88.7% en detección de vacíos, 76.3% en identificación del producto faltante. La identificación de producto es el punto débil porque las cámaras de seguridad no tienen la resolución óptima para leer etiquetas. Para mejorar este punto, combinamos la detección visual con datos de inventario: si el lineal está vacío y el stock en almacén del producto asignado a esa posición es mayor que cero, la probabilidad de que sea ese producto es alta.

El ROI

Costes:

• Hardware adicional: cero (se reutilizan cámaras existentes; se añade un NVR con capacidad de export por tienda, 800 euros x 45 = 36.000 euros).
• Infraestructura cloud: procesamiento de imágenes = 1.200 euros/mes.
• Desarrollo: 42.000 euros (una vez, incluyendo etiquetado de dataset).
• Mantenimiento: 1.500 euros/mes.

Ahorros:

• Reducción de roturas de stock del 3.2% al 1.8%. En una cadena con una facturación media de 180.000 euros mensuales por tienda, eso representa un incremento de ventas recuperadas de 2.520 euros/tienda/mes. Con 45 tiendas: 113.400 euros/mes.
• Reducción del 25% en horas de reposición por mejor priorización. Ahorro estimado: 18.000 euros/mes en toda la cadena.

Payback: Coste del primer año: 110.400 euros (hardware + desarrollo + 12 meses de operación). Ahorro del primer año: 1.576.800 euros. Payback en 25 días. Estos números explican por qué computer vision en retail es uno de los casos de uso con adopción más rápida.

Caso 3: Inspección de paquetes (logística)

El problema

Un operador logístico que procesa 8.000 paquetes diarios necesitaba detectar daños visibles (aplastamientos, roturas, humedad) antes de la entrega al destinatario. El método existente: inspección visual manual en la zona de expedición. Con 8.000 paquetes y 12 operarios, cada operario disponía de una media de 6 segundos por paquete. La tasa de detección de daños era del 62% (medida contra auditorías aleatorias).

Los paquetes dañados entregados generaban reclamaciones, devoluciones, y costes de re-envío que sumaban una media de 18.000 euros mensuales.

La solución

Cuatro cámaras de alta velocidad instaladas en el túnel de expedición, capturando cada paquete desde cuatro ángulos mientras pasa por la cinta transportadora. Un modelo de detección de anomalías entrenado con ResNet-50 como backbone y fine-tuned con un dataset de 8.500 imágenes de paquetes (4.200 con daños, 4.300 sin daños). El modelo clasifica cada paquete como “OK” o “requiere revisión” en 180 milisegundos.

Los paquetes marcados como “requiere revisión” son desviados automáticamente a una línea de inspección manual donde un operario verifica el estado y decide si se entrega, se reempaqueta o se devuelve.

Precisión en producción: 94.1% de recall (detecta el 94.1% de los daños reales) con un 8.3% de false positives (paquetes marcados como dañados que están bien). El false positive rate es aceptable porque el coste de revisar un paquete innecesariamente es bajo (30 segundos de un operario), mientras que el coste de no detectar un daño es alto (reclamación, re-envío, cliente insatisfecho).

El ROI

Costes:

• Hardware: 4 cámaras industriales + iluminación del túnel + PC de inferencia con GPU = 12.800 euros.
• Integración con cinta transportadora (desvío automático) = 8.500 euros.
• Desarrollo y entrenamiento: 28.000 euros.
• Mantenimiento: 1.200 euros/mes.

Ahorros:

• Reducción del 52% en reclamaciones por daños (de 18.000 a 8.640 euros/mes). Ahorro: 9.360 euros/mes.
• Reducción de 4 operarios dedicados a inspección visual (reasignados a otras tareas). Ahorro en coste de oportunidad: 7.200 euros/mes.
• Reducción del 35% en costes de re-envío. Ahorro: 3.150 euros/mes.

Payback: Coste del primer año: 63.700 euros. Ahorro del primer año: 236.520 euros. Payback en 3.2 meses.

Patrones comunes de implementación

Los tres casos comparten patrones que se repiten en cualquier despliegue de visión por computador en producción.

Edge vs. cloud. La decisión de procesar en el edge (en la ubicación) o en cloud depende de la latencia requerida y el volumen de imágenes. La inspección de paquetes requiere 180ms de latencia: edge obligatorio. La monitorización de obra puede tolerar minutos: cloud es más eficiente. El retail es un caso intermedio donde el procesamiento puede ser local (en el NVR) o en cloud con batching cada 15 minutos.

Re-entrenamiento continuo. Los modelos se degradan cuando las condiciones visuales cambian (nueva iluminación, nuevos tipos de producto, cambio de estación). Un pipeline de re-entrenamiento trimestral con imágenes frescas de producción mantiene la precisión. Automatizar el etiquetado asistido (el modelo propone, un humano valida) reduce el coste de re-entrenamiento en un 60%.

Métricas de negocio, no métricas de modelo. El mAP del modelo es relevante para el equipo técnico. El negocio quiere saber: cuántos daños detectamos, cuántas roturas de stock evitamos, cuánto nos ahorramos en penalizaciones. Las métricas de modelo alimentan las métricas de negocio, pero el dashboard que ve el director financiero muestra euros, no porcentajes de precisión.

Empezar simple. Los tres proyectos empezaron con modelos pre-entrenados y fine-tuning con datasets relativamente pequeños (entre 4.000 y 12.000 imágenes). Ninguno requirió entrenar un modelo desde cero. La inversión en etiquetado de datos es significativa pero predecible. La inversión en arquitecturas de modelo exóticas es impredecible y rara vez justificada en aplicaciones industriales.

Errores comunes que arruinan proyectos

Después de participar en más de una docena de proyectos de visión por computador en diferentes sectores, hay errores que vemos con suficiente frecuencia para considerarlos sistemáticos.

Subestimar las condiciones de producción. El modelo funciona perfecto en el laboratorio con iluminación controlada y cámaras de alta resolución. En producción, la iluminación cambia con el clima y la hora del día, las cámaras se ensucian, la vibración de la maquinaria causa blur. Un modelo entrenado exclusivamente con imágenes limpias pierde entre 8 y 15 puntos de precisión cuando se enfrenta a condiciones reales. La solución es obvia pero requiere disciplina: entrenar con imágenes de producción, no con imágenes de laboratorio. Incluir augmentation que simule las condiciones adversas reales (cambios de luminosidad, blur por movimiento, oclusiones parciales).

Ignorar los false positives. Mucha atención se dedica al recall (no perder detecciones) y poca a la precisión (no generar falsas alarmas). En un contexto industrial, un false positive tiene coste: un operario que revisa un paquete que no tiene daño, un reponedor que va a un lineal que no está vacío, una alerta de progreso de obra que no corresponde. Si la tasa de false positives es demasiado alta, el equipo operativo pierde confianza en el sistema y deja de atender las alertas. Alert fatigue mata proyectos de visión por computador igual que mata proyectos de monitoring.

No planificar la infraestructura de etiquetado. El entrenamiento inicial es una fracción del etiquetado total del proyecto. El re-entrenamiento trimestral, la corrección de errores, la adaptación a nuevos productos o condiciones requieren etiquetado continuo. Sin un proceso de etiquetado eficiente (herramientas como Label Studio o CVAT, un pipeline de etiquetado asistido por modelo, y personas asignadas a la tarea), el modelo se queda congelado en su versión inicial y se degrada.

Optimizar la métrica equivocada. El equipo técnico optimiza mAP. El negocio necesita optimizar el coste de errores no detectados vs. el coste de falsas alarmas. Estas dos métricas no siempre se alinean. Un umbral de confianza alto reduce falsas alarmas pero aumenta los errores no detectados. Un umbral bajo hace lo contrario. El punto óptimo depende de la economía del caso de uso, no de la métrica del modelo. Incluir al equipo de negocio en la decisión del umbral de confianza es más importante que mejorar el mAP un punto porcentual.

Cuándo no usar visión por computador

No todo problema visual requiere visión por computador. Hay casos donde sensores más simples (peso, infrarrojo, ultrasonido) resuelven el problema con menos complejidad y menor coste. Si la pregunta es “hay algo en esta posición?” un sensor de presencia cuesta 15 euros y tiene una fiabilidad del 99.9%. Un modelo de visión que responde a la misma pregunta cuesta miles en desarrollo y tiene una fiabilidad del 95%.

La visión por computador se justifica cuando la pregunta es visual y semántica: “qué hay en esta posición y en qué estado está?” “ha cambiado algo respecto a la imagen de referencia?” “este objeto tiene un defecto visible?” Si la pregunta puede responderse sin interpretar una imagen, probablemente hay una solución más simple y fiable.

La visión por computador en industria ya no es tecnología experimental. Es tecnología de producción con ROI demostrable. El factor limitante no es el modelo. Es la ingeniería que conecta la cámara con la decisión de negocio.

Para el caso específico de retail, nuestro artículo sobre smart retail y gestión de stock con IA profundiza en la monitorización de estanterías. Y para llevar estos modelos a producción con un pipeline fiable, consulta nuestra guía de MLOps.