Reglamento de IA UE para sistemas de seguridad física — lo que debe saber

El Anexo III del Reglamento de IA enumera ocho áreas de sistemas de IA de alto riesgo. La interpretación más fuerte sitúa a Perimetro Platform fuera del Anexo III. El punto más discutible es el 2 (infraestructura crítica), pero su lectura literal cubre IA utilizada en la prestación de un servicio crítico (IA que controla la distribución de energía, IA en SCADA, IA que controla el tráfico vial) — no IA utilizada para proteger el perímetro de un sitio que presta un servicio crítico.

Un razonamiento análogo aplica a los sistemas CCTV, que no se clasifican como de alto riesgo a pesar de servir a la protección de infraestructura crítica. Los siete puntos restantes del Anexo III (biometría, educación, empleo, acceso a servicios, fuerzas del orden, migración, justicia) inequívocamente no cubren a Perimetro. El clasificador de detección tiene tres clases genéricas (persona, vehículo, incursión en zona, drone* en la hoja de ruta de detección) sin subtipos ni identificación individual.

Una lectura conservadora podría incluir a Perimetro bajo el Art. 6(2) si el cliente implementador utiliza el sistema como componente de seguridad de su infraestructura — en cuyo caso Perimetro sería un sistema de IA de alto riesgo para esa implementación específica. La decisión final pertenece a la autoridad de supervisión y a la evaluación legal del cliente implementador en su contexto operativo. Perimetro proporciona documentación para ambas vías.

Un malentendido común es asumir que «certificado de alto riesgo» es una posición más fuerte que «fuera del alto riesgo». En la práctica de compras y cumplimiento, ocurre lo contrario. El cliente implementador fuera del alto riesgo se ahorra cuatro categorías de obligaciones formales del Art. 8-17 y Art. 71 del Reglamento de IA.

Primero, evaluación de conformidad por organismo notificado (Art. 43) — coste EUR 50-150 mil de una sola vez más renovaciones tras cambios materiales del sistema. Segundo, marcado CE y declaración de conformidad (Art. 47-48) — proceso formal de 3-6 meses. Tercero, registro en la base de datos UE de sistemas IA de alto riesgo (Art. 71) — notificación pública más obligaciones de actualización. Cuarto, vigilancia poscomercialización formal (Art. 72) — notificación de incidentes a la EU AI Office.

Mientras tanto, Perimetro implementa el conjunto completo de controles del Art. 9-15 — el cliente obtiene un sistema diseñado como de alto riesgo sin las obligaciones de alto riesgo de su lado. Por comparación, soluciones alternativas cloud-first que transfieren vídeo bruto típicamente requieren al cliente implementador realizar una evaluación de conformidad por cada cambio material, ejecutar una vigilancia poscomercialización completa y construir su propia infraestructura de registro de inferencia.

Posición de Perimetro: el cliente obtiene una herramienta auditable, documentada, con riesgo documentado — independientemente de la clasificación formal. La clasificación fuera del Anexo III significa que el cliente se ahorra 6-12 meses de compras y EUR 50-150 mil de coste de evaluación de conformidad formal, mientras recibe una arquitectura que excede los requisitos mínimos de alto riesgo.

El Art. 5 del Reglamento de IA enumera ocho prácticas prohibidas. Perimetro satisface este artículo mediante restricciones arquitectónicas, no mediante políticas organizativas. Identificación biométrica individual (Art. 5(1)(h)): el clasificador de detección tiene tres clases genéricas sin subtipos ni identificación. El esquema de la carga del evento no tiene campos que permitan identificación individual.

Categorización biométrica (Art. 5(1)(g)): el clasificador no analiza atributos demográficos — no existen tales características en la arquitectura del modelo, no existen tales categorías en el esquema del evento. Reconocimiento de emociones (Art. 5(1)(f)): sin funcionalidad de reconocimiento de emociones, sin tales clases en la taxonomía de detección, el modelo ML no tiene cabezas de detección para afecto, gestos o postura.

Puntuación social (social scoring) (Art. 5(1)(c)): el sistema no califica personas, evalúa eventos (incidentes de incursión en zona). El registro de eventos no contiene puntuaciones agregadas por persona ni historiales de comportamiento individual. Vigilancia policial predictiva (predictive policing) para delitos individuales (Art. 5(1)(d)): el sistema no califica personas, la escalada es basada en eventos, no en personas. Extracción no selectiva de imágenes faciales (Art. 5(1)(e)): el sistema no construye bases de datos de rostros, los key frames se almacenan por evento con retención configurable y difuminado de rostros (face blur) opcional activado por defecto.

Todas las prohibiciones anteriores se aplican estructuralmente en el esquema Protocol Buffers que define el formato de comunicación edge ↔ cloud. La ausencia de campos como face_descriptor, emotion_score, demographic_attribute, behavioral_score es una barrera CI/CD — los tests automáticos verifican que un nuevo build no haya introducido campos prohibidos. Un cambio (pull request) que modifique el esquema del evento se revisa obligatoriamente por el compliance officer y el CTO antes de la fusión.

El Art. 9 del Reglamento de IA exige un proceso continuo e iterativo de gestión de riesgo cubriendo identificación de riesgos conocidos y previsibles, estimación de riesgos del uso previsto, evaluación de riesgos del posible mal uso, medidas de gestión para riesgos identificados, y eliminación o reducción de riesgos mediante diseño.

El registro de riesgos de Perimetro está bajo control de versiones y cubre seis categorías de riesgo. Operativo: falso positivo de clasificación causando escalada innecesaria, falso negativo permitiendo el paso de un intruso, fallo de conectividad durante una misión — medidas: umbral de confianza configurable por cada clase, cola de salida para el funcionamiento sin conexión, regreso a la base (RTH) autónomo ante pérdida de conectividad.

Cumplimiento: acceso no autorizado a datos del cliente, pérdida del rastro de auditoría, violación de la residencia de datos — medidas: cifrado por tenant con borrado criptográfico (cryptographic erasure), cadena hash HMAC para el registro de eventos, infraestructura solo en la UE. Seguridad del modelo: ejemplos adversarios (adversarial), deriva del modelo por cambios estacionales de iluminación — medidas: pruebas adversarias (adversarial) en CI, evaluación del modelo en cada versión sobre un conjunto de prueba con casos límite (edge cases), detección de deriva en producción.

El registro de riesgos se actualiza en cada versión del modelo ML (revisión de riesgos previa a la implementación como barrera CI/CD), trimestralmente (revisión sistemática por compliance officer más ML lead más CTO), de forma puntual ante incidentes de producción, y tras cambios regulatorios materiales. Cada actualización lleva timestamp, autor y razón. El histórico está disponible para auditores bajo NDA como parte de la documentación alineada con el Art. 11 del Reglamento de IA (Anexo IV).

El Art. 14 del Reglamento de IA exige que los sistemas de IA de alto riesgo se diseñen para permitir supervisión humana efectiva. Perimetro implementa el modelo HITL (Human-in-the-Loop) como restricción arquitectónica, no como opción configurable. Los eventos HIGH (intruso en zona restringida, anomalía térmica de alta confianza) requieren confirmación explícita del operador con una de cuatro opciones de acción: escalar, verificar, marcar como error de clasificación, manejo normal.

El sistema no realiza ninguna respuesta cinética autónoma. El dron Aero puede cambiar su ruta de patrulla pero no puede perseguir activamente a un intruso ni tomar acciones más allá de la observación y el reporting. Tower y Connect generan solo alertas — la respuesta física (bloqueo del acceso, activación de grabación, despacho de patrulla) requiere decisión del operador o se entrega mediante integraciones con sistemas del cliente (Genetec, Milestone, control de acceso).

La UI del operador está diseñada conforme a las buenas prácticas de accesibilidad WCAG AA. Las alertas HIGH son bloqueantes (modal) — el operador no puede pasar a otra tarea sin tomar una decisión. La auto-escalada al supervisor ocurre tras 60 segundos (tiempo de espera (timeout) configurable por cliente) sin decisión del operador — con una entrada del registro de eventos indicando que el supervisor fue notificado por tiempo de espera, no por escalada activa del operador.

La ausencia de respuesta cinética autónoma se aplica estructuralmente. La máquina de estados de eventos no tiene transición «auto-respond» — cada evento HIGH debe pasar por una decisión de operador o supervisor. Un cambio (pull request) que introduzca tal transición sería bloqueado en la revisión de código por el compliance officer.

El Art. 15 del Reglamento de IA exige que los sistemas de IA de alto riesgo alcancen un nivel apropiado de precisión, robustez y ciberseguridad a lo largo de su ciclo de vida. La precisión del clasificador de Perimetro se mide en un test dataset representativo de las condiciones europeas (diferentes horas del día, condiciones meteorológicas, estaciones) con métricas precision, recall, F1 por cada clase.

La robustez cubre pruebas adversarias (adversarial) (imágenes preparadas para evadir detección o generar falsos positivos), evaluación del modelo en cada versión sobre casos límite (edge cases) (intrusos ocluidos, enmascaramiento térmico parcial, clima extremo), y detección de deriva en producción (auto-detección cuando el rendimiento por cada clase baja del umbral). Las métricas concretas están disponibles en Dataset Cards y Model Cards dentro del VRA Pack del cliente.

Ciberseguridad: TLS 1.3 con firma HMAC-SHA256 por dispositivo para la comunicación edge ↔ cloud (con protección anti-replay), claves de cifrado por tenant con Customer-Managed Keys opcional, cadena hash HMAC para el registro de eventos (inalterable — la modificación de una entrada del log es detectable criptográficamente), pruebas de penetración regulares por empresa externa (anuales más puntuales tras cambios materiales del sistema).

La detección de drift es automática. El sistema monitorea el rendimiento por cada clase en producción (precision en eventos confirmados por operador) y emite una alerta al equipo ML cuando baja del umbral configurable por cliente (default 5% de caída en 7 días). El disparador inicia un ciclo de reentrenamiento o reversión (roll-back) a la versión anterior del modelo, con la decisión del ML lead bajo revisión del compliance officer.

Los operadores de infraestructura crítica suelen estar cubiertos simultáneamente por NIS2, Reglamento de IA, RGPD y a menudo CER. Estos regímenes tienen requisitos solapados — registro de eventos (NIS2 Art. 21 más Reglamento IA Art. 12), gestión de riesgos (NIS2 Art. 21 más Reglamento IA Art. 9), notificación de incidentes (NIS2 Art. 23 más Reglamento IA Art. 73 para alto riesgo), cadena de suministro (NIS2 Art. 21(2)(d) más Reglamento IA Art. 25 para proveedores).

Perimetro Platform está diseñada para todos estos regímenes simultáneamente. El registro de eventos es inalterable (cadena hash HMAC) — satisface a la vez el requisito de auditoría NIS2 y el registro del Art. 12 del Reglamento de IA. El registro de riesgos cubre tanto riesgos operativos (enfoque NIS2) como riesgos del modelo ML (enfoque Reglamento IA). El NIS2 Reporter genera informes 24h/72h en el producto requerido por el CSIRT nacional, independientemente del camino regulatorio aplicado al componente IA del sistema.

El cliente implementador obtiene una plataforma de integración para ambos regímenes. El compliance officer no necesita mapear por separado a NIS2 y por separado al Reglamento de IA — Perimetro proporciona el mapeo en el VRA Pack (Vendor Risk Assessment Pack) como plantilla rellenada desde la perspectiva del cliente. Plantilla DPIA rellenada, análisis de cadena de suministro, ejemplo de registro de riesgos, especificación del registro de eventos — todo listo para revisión por el counsel del cliente en lugar de escribirse desde cero.

El análisis y mapeo completo de todos los artículos del Reglamento de IA (Art. 5 y 9-15) más modelo de amenazas IA más FRIA más vigilancia poscomercialización más AI Regulatory Sandbox más caso práctico de AI Act assessment están disponibles en el whitepaper «Perimetro AI Act Conformity Reference Architecture v2.0» (49 páginas, públicamente disponible bajo NDA para clientes enterprise con intención de compra).