Seguridad datos entrenamiento IA: qué deben revisar los CISO

Cuando un robot de seguridad pasa por alto a una persona, es un fallo de detección. Cuando marca por error a una persona como amenaza, es un fallo de proceso. Ambos fallos tienen la misma causa: los datos de entrenamiento. Este artículo explica para CISO y responsables de seguridad en operadores KRITIS de dónde proceden los datos, cómo se verifican y qué cláusulas contractuales deben quedar resueltas antes de firmar.

Seguridad datos entrenamiento IA: por qué la base de datos decide la calidad de detección

Los modelos de detección de personas y vehículos alcanzan en condiciones reales una tasa de falsos negativos por debajo del 2 por ciento solo cuando hay al menos 50.000 fotogramas anotados por clase de objeto. Por debajo, la tasa de error no aumenta de forma lineal sino desproporcionada en condiciones de borde: penumbra, lluvia, oclusión parcial.

Datos de entrenamiento deficientes producen el problema inverso. Cada falsa alarma consume de media 18 minutos de tiempo del centro de control para visualización, evaluación, escalado y documentación. Con una tasa de falsas alarmas del 12 por ciento en un emplazamiento con 200 eventos de detección nocturnos, surgen 7,2 horas-persona de carga de control por noche. Ese es el verdadero generador de costes, no el hardware.

Quarero separa por ello de forma estricta entre preentrenamiento en fábrica y adaptación al sitio en el emplazamiento. El preentrenamiento aporta la base de clases de objetos. La adaptación al sitio durante cuatro semanas calibra la detección de anomalías a la normalidad específica del emplazamiento. Ambos están versionados y son auditables por separado.

La procedencia de los datos de entrenamiento está sujeta a documentación según el artículo 10 del EU AI Act para sistemas de IA de alto riesgo. Fuentes, procedimientos de anotación, pruebas de sesgo y representatividad deben ser demostrables. Ningún modelo sale de nuestra fábrica sin una ficha técnica firmada sobre estos puntos. Quien no la reciba, tampoco debería comprar.

Siguiente paso: especificación técnica QR-2 patrulla exterior con detección térmica de personas.

Fuentes de datos: datasets públicos, generación sintética y datos de cliente

Los modelos base utilizan tres fuentes para clases de objetos generales: COCO para personas y vehículos, BDD100K para escenas exteriores con anotación de hora del día y meteorología, ImageNet para clases finas. Los datasets térmicos se licencian de FLIR. Estas fuentes públicas cubren alrededor del 40 por ciento de la base de entrenamiento.

El 60 por ciento restante procede de generación sintética. Pipelines de Unity y Unreal producen escenarios de visión nocturna, lluvia, niebla y contraluz en una cantidad y variabilidad que no sería alcanzable con grabaciones reales. Los datos sintéticos tienen la ventaja de etiquetas con precisión de píxel y casos límite ajustables. Tienen la desventaja de un desfase con la realidad, que debe cerrarse mediante datos reales de validación.

Los datos de cliente no entran en el entrenamiento base. Si un cliente lo consiente de forma expresa, los datos del sitio se utilizan únicamente seudonimizados y únicamente para el modelo de ese emplazamiento concreto. No pasan a un pool intersectorial. Es la objeción más frecuente de los CISO, y es legítima: no aplicamos Federated Learning más allá de los límites del cliente.

Las firmas de drones para QR-3 para KRITIS con LiDAR y detección de drones proceden de una campaña de medición propia de 14 meses con 47 modelos de dron. Los datos de entrenamiento de audio para detección de disparos y rotura de cristal se generan mediante grabaciones Foley en salas acústicamente controladas, no a partir de incidentes reales. Es una renuncia consciente a datos reales, porque las firmas reales de disparo y allanamiento no son obtenibles ética ni jurídicamente.

RGPD y Reglamento de IA: marco jurídico para datos de entrenamiento de robots de seguridad

La detección de personas no es identificación biométrica según el art. 9 del RGPD mientras no se produzca reidentificación entre sesiones. Los modelos de Quarero generan bounding boxes de persona con clasificación persona/no persona, sin atributos de identidad, sin rasgos faciales, sin reconocimiento de patrón de marcha. No existe reconocimiento facial en el sistema. Es una decisión de arquitectura, no una opción de configuración.

El EU AI Act clasifica la vigilancia perimetral como sistema de alto riesgo cuando cubre espacios públicos. Para terrenos industriales cercados, parques industriales y emplazamientos KRITIS esa clasificación no aplica automáticamente, porque no hay accesibilidad pública. La evaluación de riesgo debe documentarse por emplazamiento. En terrenos mixtos con zonas de acceso público (recepción, parking de visitas) las obligaciones de alto riesgo aplican a esas zonas.

El acuerdo de encargado del tratamiento con Quarero regula de forma explícita cualquier uso de datos del sitio para mejora del modelo como opt-in. La configuración por defecto es: los datos permanecen en el emplazamiento, nada entra en nuestra pipeline de entrenamiento. Quien desee mejora del modelo con datos propios lo activa contractualmente y puede revocarlo en cualquier momento.

Los plazos de borrado están impuestos técnicamente: datos de vídeo en bruto 72 horas en el robot, metadatos de eventos de alarma 90 días, datos estadísticos anonimizados 24 meses. Las actualizaciones de modelo se retiran de la pipeline activa de entrenamiento tras 30 días. El Reglamento de Máquinas EU 2023/1230 regula adicionalmente los requisitos de seguridad para sistemas autónomos asistidos por IA. EN ISO 13482 especifica requisitos de seguridad para robótica de servicio móvil como marco de referencia (ISO 13482).

Para profundizar en las obligaciones: Checklist KRITIS-Dachgesetz 2026.

Anotación y aseguramiento de calidad: cómo etiqueta Quarero los datos de entrenamiento

La anotación se realiza en Alemania por personal con verificación de seguridad. No utilizamos plataformas de crowdsourcing como Mechanical Turk o Scale AI para datos de entrenamiento en contextos de seguridad. La razón es trivial: quien ve imágenes de terrenos industriales, rutas de patrulla e infraestructura de seguridad debe estar verificado. Eso cuesta aproximadamente factor 4 frente a anotación offshore y no es negociable.

Cada anotación se realiza con principio de cuatro ojos. Los casos límite (personas con equipaje inusual, personal de mantenimiento en EPI, obreros con herramienta) pasan a una tercera instancia revisora que define semanalmente nuevas categorías de caso límite. La tasa de error de anotación se mide semanalmente, valor objetivo por debajo del 0,8 por ciento. Si se supera, la pipeline se detiene hasta el análisis de causa raíz.

Las pruebas de sesgo son obligatorias antes de cada release de modelo. La tasa de detección debe situarse dentro del 3 por ciento entre todas las clases demográficas (sexo, grupo de edad estimado, tono de piel según escala Fitzpatrick). Si la dispersión es mayor, se reequilibra el dataset y se repite el entrenamiento. Es costoso y retrasa releases, pero es exigible tanto jurídicamente (AI Act art. 10) como operativamente.

El Adversarial Testing verifica escenarios de camuflaje y oclusión generados sintéticamente antes de la liberación productiva. Incluye patrones anti-detección en ropa, oclusiones múltiples y efectos meteorológicos que distorsionan contornos humanos.

Inferencia edge en lugar de nube: minimización de datos como principio de arquitectura

La inferencia se ejecuta íntegramente en el robot. NVIDIA Jetson Orin con 275 TOPS en QR-2 y QR-3 basta para detección RGB simultánea, evaluación térmica y clasificación de anomalías en tiempo real. Ningún flujo de vídeo abandona el emplazamiento. Solo metadatos (clasificación, sello de tiempo, posición) y fotogramas de alarma se transmiten al centro de control del cliente.

Esta decisión de arquitectura tiene consecuencias. Impide la analítica basada en nube con flujos continuos, lo que algunos competidores usan como argumento de venta. A cambio reduce considerablemente el vector de ataque sobre protección de datos: lo que no se sube, no se puede sustraer. Para operadores KRITIS bajo conformidad NIS-2 es la evaluación de riesgo más sencilla.

Las actualizaciones de modelo se distribuyen firmadas como delta-update. El robot verifica la cadena de firma antes de aplicarla. Las actualizaciones no firmadas o manipuladas se rechazan y notifican. No hay Federated Learning, cada emplazamiento permanece aislado en lo relativo a datos. El almacenamiento local está cifrado con AES-256, rotación de claves automática cada 90 días.

Adaptación al sitio: cuatro semanas de site-training tras la entrega

Fase 1 (semana 1) es basada en reglas, sin entrenamiento ML. Se configura el geofencing, se aprenden las rutas de patrulla, se definen zonas de exclusión. En esta fase el robot opera con ajustes de fábrica y registra todas las detecciones para la fase 2.

Fase 2 (semana 2 a 3) es el site-training propiamente dicho. El sistema aprende patrones de movimiento esperados: rutas de carretilla, cambios de turno, tráfico regular de proveedores, personal de limpieza, prestadores externos con sus franjas horarias. No es un reentrenamiento de la detección de personas, sino calibración de la clasificación de anomalías sobre la base de las detecciones existentes.

Fase 3 (semana 4) finaliza la detección de anomalías. La tasa de falsas alarmas baja típicamente del 12 por ciento (entrega de fábrica) al 1,8 por ciento (calibrada). Es la razón principal por la que un piloto de menos de 30 días no aporta una afirmación sólida sobre la calidad de detección. Quien ofrece un piloto de 7 días muestra la máquina sin calibrar.

Los datos del sitio permanecen físicamente en el robot y en el NAS del cliente. Nunca entran en una nube de Quarero. Al finalizar el contrato, todos los pesos de modelo específicos del sitio se borran de forma verificable, el protocolo de borrado se entrega al cliente. En el modelo Robotics-as-a-Service esta cláusula es parte del contrato, no punto de negociación.

Complementario: Protección perimetral en parque industrial.

Riesgos: Data Poisoning, robo de modelo y ataques adversariales

Data Poisoning es el intento de degradar deliberadamente el comportamiento del modelo mediante datos de entrenamiento o adaptación manipulados. Protección frente a ello: el servidor de actualizaciones firma cada modelo con un módulo de seguridad hardware. El robot rechaza actualizaciones no firmadas o con firma inválida. La entrada de datos de entrenamiento en la pipeline central pasa por varias etapas de validación con pruebas estadísticas de drift.

El robo de modelo se aborda mediante Trusted Execution Environment en el Jetson Orin. Los pesos del modelo se mantienen en el área cifrada y no se desempaquetan en la memoria principal normal. El acceso físico al robot no permite extraer los pesos sin romper el TEE, lo que según el estado actual no es comercialmente rentable.

Los Adversarial Patches son el escenario de ataque prácticamente más relevante. Camisetas con patrones anti-detección pueden engañar a determinadas generaciones de modelo. Probamos esta clase de ataque cada trimestre con patches comercialmente disponibles y publicados académicamente. Las contramedidas (capa de detección para los propios patches, clasificación por ensemble) se despliegan en actualizaciones regulares de modelo.

La pipeline de datos de entrenamiento está auditada según BSI IT-Grundschutz con verificación externa anual (BSI/BBK). La respuesta a incidentes ante sospecha de Data Poisoning está definida: rollback al último modelo verificado en menos de 4 horas, en paralelo análisis forense de la pipeline de entrenamiento de los últimos 30 días.

Lo que los responsables de seguridad deben revisar antes de firmar

Seis puntos forman parte de toda due diligence antes de firmar un contrato RaaS para robots de seguridad.

Primero: solicitar la ficha técnica de datos de entrenamiento. Debe contener fuentes, ubicación de la anotación, procedimiento de anotación y resultados de pruebas de sesgo. Quien no entrega una ficha técnica, o no la tiene o no quiere mostrarla. Ambas cosas son criterio de exclusión.

Segundo: revisar el anexo AVV. ¿El uso de datos del sitio para mejora del modelo es opt-in u opt-out? En caso de opt-out, la cuestión es qué ocurre con el silencio. El estándar debe ser opt-in.

Tercero: aclarar si los datos de vídeo en bruto abandonan alguna vez el emplazamiento. La respuesta debe ser no. Si lo hacen (para casos de soporte, diagnóstico de modelo), bajo qué condiciones, con qué conservación y con qué anonimización.

Cuarto: garantizar contractualmente el justificante de borrado al finalizar el contrato. El protocolo de borrado debe abarcar todos los pesos de modelo específicos del sitio, los datos del sitio y las configuraciones.

Quinto: acordar un piloto con medición definida de falsos positivos y falsos negativos durante 30 días. Pilotos más cortos miden la máquina sin calibrar y producen cifras mejores o peores que el funcionamiento regular posterior. Una medición honesta requiere la adaptación completa al sitio más dos semanas de operación regular.

Sexto: consultar a clientes de referencia del mismo sector sobre calidad de detección, no solo sobre el proceso comercial. La pregunta operativamente relevante es: ¿cuántas falsas alarmas por noche tras el mes 3? ¿Cuántas detecciones confirmadas al mes? ¿Qué casos límite causaron problemas?

Para la valoración económica frente al servicio clásico de vigilancia humana ayuda la comparativa TCO del servicio de vigilancia. Para una especificación concreta de su emplazamiento y un modelo de ficha técnica concierte una reunión técnica previa a través de la página de contacto. Enviamos por adelantado el anexo AVV estándar y un ejemplo de ficha técnica de datos de entrenamiento, para que su departamento de protección de datos y jurídico pueda revisarlos en paralelo antes de la reunión.