La respuesta a un incidente de IA comienza antes de la investigación

 

Por Dave Russell, vicepresidente sénior y director de estrategia en Veeam

 

En julio, Hugging Face reveló una intrusión sin precedentes en el sector. Aproximadamente 1.200 agentes de IA escaparon de un entorno interno de evaluación de OpenAI y cerca de 700 llegaron a comprometer sus sistemas, generando más de 17.000 eventos registrados.

OpenAI atribuyó el comportamiento a una combinación de incentivos de entrenamiento que premiaban la manipulación de tareas, agentes que insistían en completar acciones para las que no estaban preparados y controles insuficientes sobre la comunicación entre ellos. El resultado fue una compleja labor de reconstrucción para determinar qué agente había hecho qué, en qué sistema y en qué momento.

Hace tiempo que defiendo la necesidad de más «fallos seguros» en el ámbito de la IA: incidentes que nos permitan aprender antes de que los riesgos sean mayores. El caso de Hugging Face ofrece una lección especialmente importante. La cuestión no es solo si una organización puede detener a un agente, sino si puede explicar rápidamente qué hizo.

No hay tiempo para ver quien causó el incidente

La mayoría de las normas aplicables a un incidente relacionado con la IA no son específicas de esta tecnología. Son leyes de notificación de incidentes que no distinguen entre una brecha causada por una persona y otra provocada por un agente.

Los plazos son exigentes. La directiva NIS2 de la Unión Europea establece una alerta temprana en un plazo de 24 horas desde que se tiene conocimiento de un incidente significativo y una notificación en un máximo de 72 horas. Las entidades financieras sujetas a DORA deben presentar una notificación inicial en un plazo de cuatro horas desde que clasifican un incidente como grave y, como máximo, 24 horas después de detectarlo. En Estados Unidos, las empresas cotizadas disponen de cuatro días hábiles para divulgar un ciberincidente una vez determinada su materialidad.

Estos plazos comienzan a correr mucho antes de que concluya el análisis de la causa raíz. Los reguladores no esperan a que termine la investigación: exigen una explicación mientras la organización todavía intenta reconstruir los hechos.

Confianza no es un sinónimo de capacidad.

Muchas organizaciones creen que podrían ofrecer esa explicación, pero los datos indican lo contrario.

Según el estudio global Data & AI Trust Gap de Veeam, realizado entre 600 altos ejecutivos, solo el 25 % de las organizaciones que utilizan IA podía identificar en cuestión de minutos las acciones realizadas por esta tecnología. Apenas el 22 % podía precisar qué datos se habían utilizado, mientras que el 47 % señaló como principal preocupación de cumplimiento la conservación de registros de auditoría sobre las decisiones de la IA.

 

Además, existe una brecha entre la percepción de los líderes y la realidad operativa. El 65 % de los CEO considera que su organización dispone de un inventario completo de sus sistemas de IA, frente a solo el 48 % de los responsables técnicos.

El problema no es únicamente la ausencia de registros. Es la falta de un registro completo, contextualizado y verificable.

¿Por qué no existe un registro?

Cuatro factores obstaculizan la situación.

El primero es que los controles de IA suelen aceptarse sobre la base de la confianza, no de la verificación. Las organizaciones configuran permisos, políticas y salvaguardas, pero no siempre pueden confirmar que funcionan como estaba previsto. De hecho, solo el 28 % confía en su capacidad para detectar si un sistema de IA opera fuera de los parámetros aprobados.

El segundo es la falta de contexto. Los logs muestran que una acción ocurrió, pero no necesariamente si debía ocurrir. La eliminación de un sistema puede registrarse como una tarea completada correctamente, aunque haya sido accidental o maliciosa. Del mismo modo, restaurar información en otra ubicación puede representar una recuperación rutinaria o una exfiltración de datos.

El tercero es la fragmentación. Los sistemas de IA acceden a lagos de datos, aplicaciones y plataformas que se encuentran fuera de la propia infraestructura de IA. A esto se suma el uso no autorizado de herramientas: el 95 % de las organizaciones encuestadas por Veeam detectó algún grado de IA no autorizada. Cuando un agente actúa en varios sistemas, no siempre existe un único lugar donde reconstruir la historia completa.

El cuarto es que las pruebas suelen reconstruirse después del incidente, en lugar de capturarse antes.

No se puede esperar

Un plazo de notificación que comienza cuando se detecta un incidente presupone que los hechos están disponibles. Si no lo están, la organización corre el riesgo de informar tarde, presentar información incorrecta o asumir responsabilidad por conclusiones que posteriormente resulten incompletas.

Para ofrecer un relato preciso dentro del plazo regulatorio, deben existir evidencias que permitan determinar qué agente intervino, qué datos utilizó, qué cambios realizó y quién autorizó la acción. Esa información debe registrarse antes del incidente, no reconstruirse a posteriori.

En la práctica, las organizaciones necesitan mantener registros inmutables y fechados de los datos con los que interactúa la IA; definir de antemano qué información podrán presentar durante las primeras horas de un incidente; extender la trazabilidad a todas las fuentes de datos accesibles para los agentes; añadir contexto a los logs; y asignar claramente la responsabilidad.

Este último punto es especialmente importante. El estudio de Veeam reveló que, cuando el CISO asume la responsabilidad del riesgo asociado a los agentes de IA, la probabilidad de detectar comportamientos anómalos aumenta un 24 %. Cuando la responsabilidad está distribuida, esa probabilidad disminuye un 47 %.

¿Qué implica en la práctica?

1)      Recopila pruebas antes de necesitarlas. Conserva registros inmutables y fechados que muestren el estado de los datos antes y después de cada cambio.

2)      Define qué información podrás presentar dentro del primer plazo: qué agente intervino, qué cambió, cuál era el estado previo y posterior, y quién autorizó la acción.

3)      Amplía la trazabilidad a todas las fuentes de datos accesibles para los agentes, no solo al modelo y sus herramientas.

4)      Añade contexto a los logs para poder interpretar cada acción, no solo confirmar que ocurrió.

5)      Asigna un responsable. Según Veeam, cuando el CISO asume esta función, la detección de anomalías aumenta un 24 %; cuando la responsabilidad es compartida, disminuye un 47 %.

Nunca dejes que una buena crisis se desperdicie.

Por último, considera cada incidente como un insumo para el siguiente mecanismo de control, y no simplemente como un informe que hay que archivar. La evidencia recopilada debe servir directamente para establecer permisos más estrictos, actualizar las salvaguardas, diseñar pruebas basadas en lo que realmente falló y renovar los protocolos de respuesta.

Es importante recordar que solo se puede aprender de un fallo que se es capaz de explicar. Las organizaciones que superen intactas su primer incidente grave relacionado con la IA no serán necesariamente aquellas que cuenten con las políticas mejor redactadas, sino aquellas que ya disponían de la evidencia necesaria desde el mismo momento en que surgió el problema.