Reducir falsas alarmas en cámaras de IA: dos técnicas que sí funcionan

La falsa alarma no es un error puntual del sistema. Es la consecuencia previsible de un modelo que decide solo, sin verificación cruzada y sin contexto operativo. Quien la trata como ruido aceptable termina apagando funciones que pagó para tener encendidas.

En la práctica, la mayoría de los despliegues de videoanalítica con IA que se encuentran en obra, en planta o en plataforma logística generan más alarmas falsas que verdaderas durante los primeros seis meses. La consecuencia no es solo el desgaste del operador en la central receptora. La consecuencia es la pérdida de credibilidad del sistema dentro de la propia organización del cliente. Cuando el responsable de seguridad recibe la séptima alerta nocturna por una bolsa arrastrada por el viento, la octava alerta deja de leerla. Cuando deja de leerla, deja de actuar. Y cuando deja de actuar, el sistema ya no protege. Existe en el armario, consume ancho de banda, paga licencia, pero no protege.

Este artículo describe dos técnicas que reducen falsas alarmas de forma medible. Las dos son fáciles de nombrar y difíciles de implementar bien. La diferencia entre un proveedor que las menciona en una presentación y un fabricante que las opera en producción se ve en los detalles que siguen.

La tasa de falsas alarmas como indicador de madurez

Una cámara con IA mal calibrada puede emitir entre veinte y sesenta alertas diarias en un perímetro de obra de tamaño medio. Una cámara con IA correctamente calibrada, en el mismo perímetro, debe operar por debajo de tres alertas diarias, de las cuales al menos dos corresponden a eventos reales verificables. La distancia entre ambas cifras no se cubre con un parche en la configuración. Se cubre con una arquitectura distinta.

La tasa de falsas alarmas es el indicador más honesto de madurez de una instalación de videoanalítica. Más honesto que la resolución de la cámara, más honesto que la marca del sensor, más honesto que el número de funciones que aparecen en la ficha técnica. Una cámara de cuatro megapíxeles con analítica bien afinada protege más que una cámara de ocho megapíxeles que dispara cada vez que pasa un zorro. La resolución es una condición previa. La analítica es la decisión. Y la decisión es donde casi todos los proveedores fallan.

La AEPD ha publicado criterios sobre proporcionalidad en el uso de videovigilancia con tratamiento algorítmico. El INCIBE, a través de sus alertas operativas, ha señalado en distintas ocasiones la fatiga de alertas como vector indirecto de incidentes, porque desconecta al operador del flujo real. Quien diseña un sistema de seguridad sin medir la tasa de falsas alarmas durante los primeros noventa días de operación no está diseñando un sistema, está vendiendo un equipo.

La cuestión, entonces, no es si la IA va a generar falsas alarmas. Va a generarlas. La cuestión es cuántas, durante cuánto tiempo, y con qué pendiente de mejora. Un sistema bien gobernado reduce su tasa de falsas alarmas mes a mes durante el primer año, y se estabiliza por debajo de un umbral acordado con el cliente. Un sistema mal gobernado mantiene la misma tasa de falsas alarmas durante tres años, porque nadie lo recalibra. La diferencia no es técnica. Es contractual y operativa.

Confirmación multicanal: la lógica de la doble verificación

La primera técnica que sí funciona se llama confirmación multicanal. La idea es sencilla. Ningún evento se eleva a alarma sobre la base de un único sensor. Una alarma requiere coincidencia temporal de al menos dos canales independientes, dentro de una ventana definida en milisegundos. La cámara con analítica visual detecta una silueta humana en zona restringida. El segundo canal, que puede ser un sensor térmico, un radar de baja frecuencia, una barrera microondas o incluso una segunda cámara con ángulo distinto, confirma o desmiente. Si los dos canales coinciden, se eleva alarma. Si solo uno reacciona, se registra como evento de bajo nivel y se almacena para análisis posterior, sin notificar al operador.

La consecuencia matemática es directa. Si cada canal genera, por separado, una tasa de falsos positivos del cinco por ciento, la probabilidad de que ambos canales generen el mismo falso positivo en la misma ventana temporal cae al cero coma veinticinco por ciento. La reducción no es lineal, es geométrica. Esta es la razón por la que los sistemas serios siempre se construyen sobre arquitecturas redundantes, y la razón por la que los sistemas de bajo coste, que dependen de un único canal visual, fallan sistemáticamente cuando se les exige operar en condiciones reales.

La dificultad de implementación está en los detalles. La ventana temporal entre canales debe estar calibrada según la velocidad esperada del objeto detectado. Una persona que cruza un perímetro genera detecciones casi simultáneas en cámara y en radar. Una persona que se mueve lentamente por una zona ciega puede generar la detección térmica varios segundos antes de aparecer en el campo visual de la cámara. Una ventana mal dimensionada elimina los verdaderos positivos. Una ventana demasiado amplia mantiene los falsos. El equilibrio se encuentra con datos reales del sitio, no con valores genéricos de fábrica.

El segundo detalle, menos visible, es la independencia real de los canales. Dos cámaras del mismo modelo, con el mismo firmware, miran al mismo objeto desde ángulos parecidos y comparten los mismos errores de clasificación. No son canales independientes. Son el mismo canal duplicado. La independencia se obtiene combinando tecnologías distintas, no productos distintos del mismo catálogo. Quien evalúa una propuesta de videoanalítica debe pedir, en concreto, qué tecnologías sensoras participan en la confirmación, cuál es la ventana temporal configurada y qué porcentaje de eventos pasa el filtro multicanal en el sitio de referencia. Si el proveedor no tiene esos datos, no tiene la técnica. Tiene un nombre.

Filtro contextual: lo que el sistema sabe del sitio

La segunda técnica se llama filtro contextual. Es más sutil que la confirmación multicanal y, por eso, peor implementada en el mercado. La idea es que el sistema sepa qué se espera en cada zona del perímetro y en cada franja horaria. Un movimiento humano en la zona de almacén a las dos de la madrugada es un evento. El mismo movimiento humano en la misma zona a las siete y media de la mañana, durante el cambio de turno, no lo es. Una camioneta que entra por el portón principal a media tarde es operación normal. La misma camioneta entrando por la misma puerta a las cuatro y diez de la madrugada es operación a verificar.

El filtro contextual requiere que el sistema mantenga un modelo del sitio. No un modelo aprendido en abstracto, sino un modelo configurado con conocimiento operativo. Las franjas horarias de actividad legítima, los puntos de paso autorizado, los vehículos esperados, los uniformes reconocibles, las rutas habituales del personal de mantenimiento. Sin este modelo, el sistema trata cada movimiento como sospechoso por defecto. Con este modelo, el sistema solo eleva alarma cuando la observación se desvía del patrón esperado.

El reto de implementación está en mantener el modelo vivo. Una obra cambia cada dos semanas. Una planta logística cambia turnos según temporada. Un centro de datos modifica sus accesos cuando entra una nueva contrata. Un filtro contextual que se configura una vez y no se revisa pierde precisión rápidamente. A los tres meses, vuelve a generar las mismas falsas alarmas que generaba el sistema sin contexto. Mantener el modelo es un trabajo, no una función. Y ese trabajo tiene que estar asignado a alguien con responsabilidad nombrada.

La segunda dificultad es jurídica. El filtro contextual, bien hecho, implica categorizar comportamientos esperados y comportamientos desviados. En entornos con presencia de trabajadores, esto roza el tratamiento sistemático de datos personales del personal propio. La AEPD ha señalado los límites de este tratamiento en varios criterios. Un filtro contextual diseñado por un fabricante serio incorpora desde el origen las restricciones del Reglamento General de Protección de Datos, no las añade como capa posterior. La diferencia se ve en los registros de auditoría que el sistema genera, en los plazos de conservación, en quién accede a qué y cuándo. Un proveedor que no menciona la AEPD en la fase de diseño está empujando el problema al cliente, que es quien firmará la responsabilidad. El cliente debe negarse a recibir ese problema.

Existe una tercera dimensión, raramente discutida en los procesos comerciales. El filtro contextual aprende. Si aprende sobre datos sesgados, refuerza el sesgo. Si en los primeros meses de operación el operador marca como falsa alarma todas las detecciones nocturnas en una zona concreta, porque hay una rama de árbol que se mueve, el sistema aprenderá que en esa zona, de noche, no debe elevar alarma. El día que alguien aproveche esa zona para entrar, el sistema lo verá y lo silenciará. Esta deriva no es teórica. Es operativa. La gobernanza del aprendizaje, qué se aprende, quién lo valida, cada cuánto se audita, es la diferencia entre un sistema que mejora y un sistema que se degrada en silencio.

Cómo evaluar al proveedor antes de firmar

La mayoría de los pliegos de adjudicación describen cámaras, no describen sistemas. Detallan resolución, sensor, ángulo, almacenamiento, ancho de banda. No detallan tasa de falsas alarmas objetivo, ventana temporal de confirmación multicanal, frecuencia de revisión del filtro contextual, ni responsabilidad nominal por la calibración. El resultado es que el proveedor que gana es el que entrega el equipo más barato, no el que opera el sistema más fiable. Esta es una falla de método, no una falla de mercado.

Quien quiera evaluar a un proveedor seriamente debe pedir cuatro cosas concretas, por escrito, antes de firmar. La primera es la tasa de falsas alarmas medida en al menos dos instalaciones comparables, durante los últimos doce meses, con detalle mensual. No promedios anuales. Detalle mensual, porque el promedio anual oculta los meses malos. La segunda es la descripción técnica de la arquitectura de confirmación multicanal, con identificación de los sensores que participan, las ventanas temporales y el comportamiento del sistema cuando uno de los canales falla. La tercera es la documentación del filtro contextual, incluyendo el procedimiento de revisión, la frecuencia, el responsable nombrado y los registros de auditoría que se generarán. La cuarta es el plan de degradación. Qué pasa cuando el modelo deja de funcionar, qué umbrales disparan una recalibración, qué cláusula contractual cubre el coste de esa recalibración.

Un proveedor que entrega estas cuatro cosas en una semana es un fabricante. Un proveedor que tarda un mes en responder y entrega documentos genéricos es un revendedor. La diferencia tiene consecuencias operativas durante toda la vida del sistema. Un sistema instalado por un revendedor termina, antes o después, con el ingeniero del cliente intentando entender por qué el equipo no funciona, mientras la cadena de soporte rebota entre cuatro empresas distintas que se señalan unas a otras.

Hay una pregunta adicional, menos técnica pero más reveladora. Quién calibra el sistema. Si la respuesta es el cliente, el proveedor está descargando la responsabilidad sobre quien no tiene los datos para hacerlo bien. Si la respuesta es un servicio externo contratado aparte, el coste real del sistema es muy superior al precio inicial. Si la respuesta es el propio fabricante, dentro del precio de servicio, con responsabilidad nominal y tiempos de respuesta acordados, la conversación se vuelve seria. La calibración no es un extra. Es el sistema.

La diferencia entre laboratorio y campo

Las demostraciones comerciales de videoanalítica suelen ocurrir en condiciones de laboratorio. Iluminación controlada, escenarios preparados, actores que cruzan el campo de visión en momentos previsibles. En estas condiciones, cualquier modelo razonable detecta lo que tiene que detectar. La verdadera prueba ocurre en condiciones de campo. Lluvia oblicua, niebla, contraluz al amanecer, vibración del soporte, suciedad acumulada en el objetivo, vegetación que se mueve con el viento, animales que cruzan el perímetro, vehículos que reflejan los focos.

Un fabricante que ha operado en obras durante años tiene un repertorio de fallos reales que un fabricante de salón nunca verá. Una rama de pino oscila de una manera concreta. Un conejo cruza a una velocidad que activa los sensores cinemáticos. Una grúa, cuando gira, lanza un destello que ciega temporalmente el sensor. Cada uno de estos casos exige una decisión de diseño. La acumulación de decisiones de diseño es lo que separa un sistema que sobrevive en campo de un sistema que falla en cuanto sale del recinto controlado.

En el libro BOSWAU + KNAUER. Del oficio constructor a la tecnología de seguridad se desarrolla la idea de que la robustez no es una propiedad del componente, sino del conjunto. Una cámara robusta dentro de una arquitectura frágil es una cámara robusta en un sistema frágil. La videoanalítica con IA hereda esta lógica. La precisión del modelo importa menos que la arquitectura en la que ese modelo está embebido. Quien compra precisión sin arquitectura compra una promesa de laboratorio.

Las dos técnicas descritas, confirmación multicanal y filtro contextual, no son técnicas de modelo. Son técnicas de arquitectura. Por eso funcionan en campo. Por eso reducen falsas alarmas de forma sostenida. Y por eso son raras en el mercado, porque exigen una manera de pensar que no se aprende vendiendo equipos, sino operándolos.

Lo que permanece

Un sistema de videoanalítica con IA que reduce falsas alarmas no es un sistema con mejor modelo. Es un sistema con arquitectura de confirmación multicanal y con filtro contextual mantenido. Estas dos técnicas, aplicadas con disciplina y revisadas periódicamente, transforman un equipo que genera ruido en un sistema que protege.

La diferencia entre un proveedor que las menciona y un fabricante que las opera se ve en cuatro documentos: tasa medida en instalaciones reales, arquitectura técnica detallada, documentación del filtro contextual con responsable nombrado, y plan de degradación con cláusulas contractuales. Quien no entrega estos cuatro documentos antes de firmar no es el proveedor correcto, aunque su precio sea atractivo.

Para una organización que ya tiene un sistema desplegado y sospecha que sus falsas alarmas están por encima del umbral razonable, el primer paso útil es una conversación confidencial de sesenta minutos, sin coste y sin compromiso, en la que se sitúa el problema. Para una organización que prepara un nuevo despliegue y quiere evitar reproducir los errores del anterior, el paso siguiente es una auditoría de tres a cinco días con entregables definidos. Para quien ya ha decidido invertir y necesita datos antes de escalar, un piloto de noventa días sobre un único emplazamiento entrega los números que ninguna presentación entrega.

Preguntas frecuentes

¿Qué tasa de falsas alarmas es tolerable?

Depende del tamaño del perímetro y del tipo de instalación, pero existe un orden de magnitud razonable. En un perímetro de obra mediano, por debajo de tres alertas diarias con al menos dos terceras partes correspondientes a eventos reales verificables. En una planta logística estable, por debajo de una alerta diaria. Por encima de cinco alertas diarias en sostenido durante más de tres meses, el sistema está mal calibrado. La cifra exacta se acuerda con el cliente al inicio del despliegue y se incluye como umbral contractual, no como aspiración.

¿Cómo funciona la confirmación multicanal?

Un evento solo se eleva a alarma si dos sensores independientes lo confirman dentro de una ventana temporal definida en milisegundos. Por ejemplo, cámara con analítica visual y radar de baja frecuencia, o cámara y sensor térmico. La probabilidad matemática de coincidencia simultánea de falsos positivos cae geométricamente, no de forma lineal. La condición crítica es que los canales sean realmente independientes en tecnología, no dos equipos del mismo tipo con los mismos sesgos. La ventana temporal se calibra con datos reales del sitio, no con valores genéricos.

¿Qué es el filtro contextual?

Es un modelo del sitio que el sistema mantiene, donde se registran las franjas horarias de actividad legítima, los puntos de paso autorizado, los vehículos esperados y las rutas habituales. El sistema solo eleva alarma cuando la observación se desvía del patrón esperado. Bien implementado, reduce drásticamente las falsas alarmas en cambios de turno o entradas operativas habituales. Requiere mantenimiento activo, porque los sitios cambian, y debe diseñarse desde el origen con las restricciones de la AEPD sobre tratamiento de datos del personal propio.

¿Quién calibra el sistema?

Esta es la pregunta que separa al fabricante del revendedor. Si la respuesta es el cliente, el proveedor descarga responsabilidad sobre quien no tiene los datos para hacerlo. Si es un servicio externo contratado aparte, el coste real del sistema es muy superior al inicial. La respuesta correcta es el propio fabricante, dentro del contrato de servicio, con responsabilidad nominal, frecuencia acordada y tiempos de respuesta definidos. La calibración no es un extra opcional, es parte del sistema. Sin calibración mantenida, cualquier sistema de IA se degrada en silencio.