EU AI Act en proyectos de videovigilancia

El EU AI Act ya empezó a exigir obligaciones de transparencia aplicables desde el 2 de agosto de 2026. Para proyectos de videovigilancia, reconocimiento facial, analítica de video y plataformas de seguridad, el punto inmediato no es “certificar todo como alto riesgo”, sino demostrar que el usuario sabe cuándo interactúa con un sitema de inteligencia artificial o cuándo recibe contenido generado, manipulado o clasificado por algoritmos. Esto impacta especificaciones técnicas, interfaces, señalización, documentación, compras y pruebas de aceptación.

EU AI Act, ¿Qué ha pasado?

EU AI Act dejó de ser una conversación de abogados y empezó a tocar tableros, cámaras, VMS, reportes de incidentes y contratos de integración. Te cuento algo que ya se ve venir en proyectos reales: una plataforma de seguridad puede parecer “solo CCTV”, pero si resume eventos automáticamente, clasifica personas por atributos biométricos, genera evidencia sintética para entrenamiento o activa un asistente conversacional para operadores, el alcance cambia.

Desde el 2 de agosto de 2026, el Artículo 50 del Reglamento de Inteligencia Artificial de la Unión Europea aplica obligaciones de transparencia para determinados sistemas. La Comisión Europea confirmó que estas reglas incluyen informar a las personas cuando interactúan directamente con un sistema de inteligencia artificial, marcar contenido generado o manipulado de forma legible por máquina, notificar exposición a reconocimiento de emociones o categorización biométrica, y etiquetar deepfakes o cierto contenido de interés público generado artificialmente.

La verdad, ahí se complica para ingeniería: no basta con comprar una solución “cumplidora”. Hay que diseñar evidencias de cumplimiento dentro del proyecto.

¿Qué cambió desde agosto de 2026 con el EU AI Act en seguridad electrónica?

Desde el 2 de agosto de 2026, el cambio práctico más importante es que las obligaciones de transparencia del Artículo 50 comenzaron a aplicarse para proveedores y usuarios profesionales —“deployers”— de ciertos sistemas de inteligencia artificial. La propia Comisión Europea indica que el Artículo 50 cubre sistemas interactivos, sistemas generativos y deepfakes, entre otros casos.

En seguridad electrónica, esto puede aparecer en sitios donde antes nadie hablaba de regulación tecnológica: recepción automatizada, video analítica avanzada, control de acceso con biometría, centros de monitoreo, reportes automáticos de incidentes y herramientas de generación de contenido para entrenamiento.

No significa que todos los requisitos de alto riesgo hayan caído encima esta semana. La página oficial del marco regulatorio del AI Act explica que ciertas reglas para sistemas de alto riesgo integrados en productos regulados tienen transición hasta el 2 de agosto de 2028, y que los casos de alto riesgo del Anexo III fueron extendidos hasta el 2 de diciembre de 2027 por el paquete conocido como AI Omnibus.

El punto inmediato es más concreto: transparencia demostrable. El integrador debe poder responder preguntas como estas:

En proyectos internacionales, este cambio también afecta a fabricantes fuera de Europa que venden equipos o software dentro del mercado europeo. No es raro que una empresa latinoamericana integre una solución europea, o que un fabricante asiático venda a un cliente con operación en España, Francia o Alemania. La cadena contractual importa.

¿Cómo afecta el EU AI Act a reconocimiento facial y analítica de video?

El EU AI Act afecta a reconocimiento facial y analítica de video cuando esas funciones usan inteligencia artificial para identificar, clasificar, inferir o generar información sobre personas. No todas las cámaras entran en el mismo nivel de riesgo, pero muchas soluciones modernas ya no son simples grabadoras: detectan comportamientos, estiman atributos, hacen búsquedas por apariencia o generan resúmenes automáticos.

Un VMS con detección de movimiento tradicional no es lo mismo que una plataforma que clasifica personas por características biométricas. Tampoco es lo mismo contar objetos en una zona industrial que aplicar reconocimiento de emociones en una entrada pública. Ahí el diseño del sistema debe separarse por casos de uso.

Ejemplo práctico: una cámara en una planta industrial detecta si hay una persona en una zona de peligro. Si solo identifica presencia humana para activar una alarma de seguridad física, el análisis puede enfocarse en desempeño, ciberseguridad y documentación operativa. Pero si además clasifica edad aparente, género, expresión emocional o identidad probable, entramos en otra conversación.

Para proyectos de reconocimiento facial, conviene revisar al menos cuatro capas:

1. Captura: cámara, iluminación, ángulo, calidad de imagen y señalización.
2. Procesamiento: algoritmo, servidor, nube, edge device o VMS.
3. Decisión: alerta, bloqueo, autorización, reporte o intervención humana.
4. Transparencia: aviso al usuario, etiqueta, registro y evidencia verificable.

Me pasó en un proyecto de control de acceso: el cliente pensaba que “biometría” era solo la plantilla de huella. Pero el proveedor también ofrecía búsqueda facial en video histórico. Ese módulo no estaba en el alcance inicial, sin embargo apareció en la demostración comercial. Para cumplimiento, esa diferencia es enorme.

¿Qué debe incluir una cláusula de transparencia en especificaciones de seguridad?

Una cláusula técnica de transparencia debe convertir el cumplimiento del EU AI Act en requisitos verificables. No sirve escribir “el sistema cumplirá con la normativa aplicable” y dejarlo ahí. Eso no ayuda al comprador, al integrador ni al fabricante cuando llega la prueba de aceptación.

Una buena cláusula debería cubrir, como mínimo:

Una redacción útil para pliegos podría ser:

“El proveedor deberá identificar explícitamente todas las funciones del sistema que utilicen inteligencia artificial para interacción con usuarios, generación o manipulación de contenido, categorización biométrica, reconocimiento de emociones o generación automatizada de reportes. Cuando aplique, el sistema deberá entregar avisos claros al usuario, etiquetado visible y/o marcado legible por máquina conforme a las obligaciones de transparencia aplicables del EU AI Act.”

Ese texto no sustituye revisión legal, claro. Pero obliga al proveedor a declarar funciones. Y eso, en ingeniería, ya es medio camino ganado.

También conviene pedir una matriz de aplicabilidad por módulo. Por ejemplo: “asistente virtual del lobby: aplica aviso de interacción”; “resumen automático de incidente: aplica etiquetado de contenido”; “video analítica perimetral sin identificación personal: revisar caso específico”; “categorización biométrica: requiere control reforzado”.

¿Cuándo deben etiquetarse reportes de incidentes generados por sistemas inteligentes?

Los reportes de incidentes generados automáticamente deben etiquetarse cuando el contenido haya sido producido o manipulado por un sistema de inteligencia artificial y pueda influir en decisiones operativas, administrativas o de seguridad. En el Artículo 50, la Comisión Europea destaca obligaciones para contenido generado o manipulado y para interacciones directas con sistemas de inteligencia artificial.

En un centro de monitoreo, esto no es teoría. Imagina un sistema que toma eventos de cámaras, sensores de intrusión y control de acceso, y redacta un resumen como:

“Persona no autorizada ingresó por puerta lateral a las 22:14, permaneció 3 minutos y salió por estacionamiento.”

Si ese texto fue generado automáticamente, el operador, el supervisor y el cliente deben saberlo. ¿Por qué? Porque el reporte puede contener inferencias, errores de correlación o lenguaje demasiado conclusivo. Una cámara puede detectar una silueta; eso no siempre prueba intención, identidad o responsabilidad.

Buenas prácticas para reportes automáticos:

• Incluir una etiqueta visible: “Contenido generado automáticamente y revisado por operador”.
• Separar datos observados de inferencias.
• Registrar fuentes: cámara, sensor, puerta, hora, evento.
• Mantener historial de edición humana.
• Evitar lenguaje acusatorio si no hay verificación.

La diferencia entre “el sistema detectó una persona” y “un intruso ingresó” puede ser legalmente sensible. En campo, esa línea se cruza más fácil de lo que parece.

¿Qué requisitos normativos deben revisar integradores y gerentes de proyecto?

El marco principal es el Reglamento de Inteligencia Artificial de la Unión Europea, especialmente el Artículo 50 para transparencia. La Comisión Europea publicó guías sobre obligaciones de transparencia para proveedores y deployers, aplicables desde el 2 de agosto de 2026.

También hay que mirar el calendario completo. El marco oficial indica que el AI Act entró en vigor el 1 de agosto de 2024; algunas obligaciones, como prácticas prohibidas y alfabetización en inteligencia artificial, aplicaron desde el 2 de febrero de 2025; las obligaciones de modelos de propósito general comenzaron el 2 de agosto de 2025; y varias reglas de alto riesgo tienen plazos posteriores por el AI Omnibus.

Para seguridad electrónica, el paquete normativo no termina ahí. Según el tipo de proyecto, pueden aparecer:

El error frecuente es revisar solo la ficha técnica del equipo. Un proyecto serio debe revisar arquitectura, flujos de datos, roles, documentación, señalización y contratos. Además, si el sistema opera en infraestructura crítica o entornos sensibles, la evaluación no puede quedarse en “el fabricante dice que cumple”.

¿Cómo integrar el EU AI Act con VMS, control de acceso, BMS y PSIM?

La integración es donde la transparencia se gana o se pierde. Un módulo aislado puede mostrar una etiqueta correctamente, pero cuando se conecta con VMS, PSIM, BMS, control de acceso o plataformas de gestión de incidentes, esa etiqueta puede desaparecer.

Ejemplo: una cámara genera un evento con clasificación automática. El VMS lo recibe, el PSIM lo correlaciona con una alarma de puerta, y luego se genera un ticket en la plataforma de mantenimiento. Si la marca de origen se pierde en el primer salto, el reporte final parece humano u objetivo, aunque no lo sea.

Para evitarlo, los proyectos deberían tratar la transparencia como dato de arquitectura:

• Campo de metadatos: ai_generated = true.
• Fuente del análisis: cámara, servidor, nube o módulo externo.
• Tipo de función: detección, clasificación, resumen, manipulación, predicción.
• Nivel de revisión humana: sin revisar, revisado, corregido, aprobado.
• Fecha y versión del modelo o módulo.
• Retención de evidencia técnica.

En interoperabilidad, el reto no es solo “que se conecte por API”. El reto es que el significado sobreviva. Si un sistema genera una alerta por categorización biométrica, esa naturaleza debe viajar al VMS, al PSIM y al reporte final.

Esto también toca ciberseguridad. Las marcas legibles por máquina, los metadatos y los logs pueden ser manipulados si no hay controles de integridad. Aquí entran firmas, control de acceso, auditoría y segmentación de red. Para proyectos con SCADA, BMS o infraestructura crítica, conviene alinear esta capa con IEC 62443 o con políticas internas de seguridad de la información.

¿Qué deben cambiar los equipos de ingeniería en pruebas de aceptación?

Las pruebas de aceptación ya no deberían limitarse a verificar que la cámara detecta, que el acceso abre o que el reporte se exporta en PDF. Ahora se debe probar que la transparencia funciona en condiciones reales.

Una matriz FAT/SAT puede incluir casos como:

Aquí hay una observación profesional: muchos fabricantes cumplen en su interfaz nativa, pero no necesariamente en la integración. En demo todo se ve bonito; en operación, el evento pasa por tres sistemas, se exporta a Excel, se manda por correo y termina en un informe mensual sin ninguna etiqueta. Ese es el hueco.

También hay que revisar manuales. Un sistema puede tener la función de aviso, pero si nadie la configura, no sirve. Por eso el checklist de entrega debe incluir parámetros configurados, evidencias gráficas, logs, responsables y procedimiento de operación.

¿Qué tendencias tecnológicas aumentan el riesgo de incumplimiento?

La evolución de la seguridad electrónica va hacia más automatización, más generación de contenido y más correlación de datos. Eso aumenta productividad, sí, pero también aumenta la superficie regulatoria.

Tres tendencias son especialmente relevantes:

1. Analítica en borde.
Las cámaras ya procesan eventos localmente. Esto reduce latencia y ancho de banda, pero dificulta centralizar controles de transparencia si cada dispositivo maneja su propia lógica.

2. Reportes automáticos multimodales.
Los sistemas combinan video, audio, control de acceso, sensores y bitácoras para redactar incidentes. Esto puede mejorar operación, pero exige trazabilidad clara de qué fue observado y qué fue inferido.

3. Datos sintéticos para entrenamiento.
El uso de imágenes o videos generados para entrenar operadores, probar algoritmos o simular amenazas puede requerir marcado cuando el contenido parezca realista o pueda confundirse con evidencia.

La Comisión también publicó un Código de Práctica sobre transparencia de contenido generado, diseñado para apoyar la implementación de estas obligaciones desde agosto de 2026.

La recomendación práctica es simple: no esperar a que compras pida “cumplimiento AI Act” al final. La transparencia debe entrar desde ingeniería conceptual, igual que cálculo de almacenamiento, ancho de banda o matriz de permisos.

FAQ sobre EU AI Act en seguridad electrónica

¿El EU AI Act aplica a cualquier cámara de seguridad?

No necesariamente. Una cámara básica no tiene el mismo tratamiento que una plataforma con reconocimiento facial, categorización biométrica, generación de reportes o interacción automatizada. Hay que evaluar función por función.

¿El EU AI Act exige etiquetar todos los videos analizados?

No todos. El etiquetado depende de si el contenido fue generado o manipulado, si hay deepfake, si existe interacción directa con inteligencia artificial o si se aplican funciones como reconocimiento de emociones o categorización biométrica.

¿Un integrador puede delegar todo el cumplimiento al fabricante?

No conviene. El fabricante puede aportar funciones y documentación, pero el integrador define arquitectura, configuración, señalización, flujos de datos y pruebas de aceptación. Ahí también se juega el cumplimiento.

¿El EU AI Act ya activó todos los requisitos de alto riesgo?

No. La aplicación inmediata desde el 2 de agosto de 2026 se centra en transparencia y algunas obligaciones relacionadas. Varias reglas de alto riesgo tienen plazos posteriores, según el calendario oficial y el AI Omnibus.

Conclusión

El EU AI Act obliga a mirar los proyectos de seguridad electrónica con otra lupa. No basta con saber si una cámara detecta mejor o si un VMS reduce falsas alarmas. Ahora también hay que saber si el sistema informa, marca, registra y conserva evidencia de sus funciones inteligentes.

Para ingenieros y gerentes de proyecto, la acción inmediata es revisar especificaciones, matrices de cumplimiento, interfaces, reportes automáticos e integraciones. Empieza por los sistemas que operan en Europa o que podrían venderse allí. Después baja el análisis a módulos concretos: biometría, analítica, asistentes, contenido sintético y reportes.

Suscríbete al boletín de Infoteknico para recibir más guías técnicas como esta, deja tus comentarios con casos reales de implementación, y revisa normas o libros especializados en Amazon antes de cerrar tus próximos pliegos.