Ninguna empresa que contrata un servicio de IA planea sufrir un incidente de seguridad, pero es precisamente la falta de planificación lo que convierte un problema técnico gestionable en una crisis de confianza con el cliente y de exposición legal. Entender qué se considera exactamente un incidente de seguridad en un sistema de IA, y qué obligaciones se activan cuando ocurre, es información que conviene tener clara antes de que llegue la llamada del proveedor avisando de que algo ha ido mal, no en ese mismo momento.
Qué es un incidente de seguridad en IA
Un incidente de seguridad es cualquier evento que compromete la confidencialidad, la integridad o la disponibilidad de los datos o del propio sistema de IA: desde un acceso no autorizado a los datos que procesa, hasta una manipulación deliberada del modelo para que revele información que no debería, pasando por un fallo técnico que expone datos de un cliente a otro por error de configuración.
Es útil distinguir, dentro de este concepto amplio, el caso concreto de la violación de datos personales (lo que el RGPD llama "brecha de seguridad"): cuando el incidente afecta específicamente a datos personales, activa obligaciones legales de notificación con plazos muy concretos, distintas de un incidente técnico que no involucra datos de personas identificables.
La analogía más clara es la de una alarma en un edificio de oficinas. Un incidente de seguridad no es solo que alguien entre por la puerta principal sin autorización: puede ser también una ventana mal cerrada que nadie detectó, un empleado que se lleva documentos por error a casa, o un sistema de videovigilancia que graba más de lo que debería y comparte esas grabaciones con quien no tiene que verlas. En un sistema de IA, los "incidentes" adoptan formas específicas de esta tecnología: desde ataques que buscan extraer datos de entrenamiento del modelo, hasta técnicas de manipulación de instrucciones (prompt injection) que consiguen que el sistema actúe fuera de los límites previstos.
Por qué importa para la decisión de negocio
El motivo legal es el más urgente en términos de plazos: si el incidente afecta a datos personales, el RGPD obliga a notificarlo a la autoridad de control en un plazo máximo de 72 horas desde que se tiene conocimiento de él, y en determinados casos también hay que informar directamente a las personas afectadas. Setenta y dos horas es muy poco tiempo si no existe ya un protocolo definido de quién decide, quién redacta la notificación y con qué información del proveedor se cuenta; es tiempo de sobra si ese protocolo ya está preparado de antemano.
El motivo reputacional es, en muchos casos, más costoso que la propia sanción administrativa. Cómo comunica una empresa un incidente de seguridad —con transparencia y rapidez, o intentando minimizarlo hasta que se hace público por otra vía— determina en gran medida si sus clientes mantienen la confianza o la pierden. Las empresas que gestionan bien un incidente, comunicando con claridad qué pasó y qué están haciendo al respecto, suelen salir del episodio con la confianza intacta; las que lo ocultan o lo gestionan mal, no.
El tercer motivo es contractual: si tu empresa es responsable del tratamiento y el incidente ocurre en los sistemas del proveedor de IA, la rapidez con la que ese proveedor te informa a ti determina si tu empresa puede cumplir sus propios plazos legales. Un DPA bien redactado debe fijar en qué plazo el proveedor está obligado a avisarte, y ese plazo tiene que dejar margen suficiente para que tú, a tu vez, puedas cumplir con el tuyo.
Existe además una dimensión de aprendizaje organizativo: las empresas que analizan a fondo cada incidente, por menor que parezca, suelen detectar patrones que permiten prevenir problemas mayores antes de que ocurran. Tratar cada aviso como una anécdota aislada, en lugar de como una señal a documentar y analizar, es una de las formas más comunes en que un riesgo pequeño se convierte en uno grave sin que nadie lo viera venir a tiempo.
Qué preguntas debe hacer tu empresa al proveedor
- ¿En qué plazo exacto se compromete el proveedor a notificarte si detecta un incidente que afecta a tus datos, y ese plazo está recogido por escrito en el contrato?
- ¿Qué información concreta incluirá esa notificación: naturaleza del incidente, datos afectados, medidas ya adoptadas?
- ¿Tiene el proveedor un protocolo documentado de respuesta a incidentes, o improvisa caso por caso?
- ¿Realiza simulacros o pruebas periódicas de su capacidad de respuesta ante incidentes de seguridad?
- ¿Qué apoyo ofrece durante la gestión del incidente, más allá de la notificación inicial (informes técnicos, asistencia para cumplir tus propias obligaciones de notificación)?
Qué NO es un incidente de seguridad en IA
Un error habitual es pensar que solo cuenta como incidente un ataque externo deliberado, como un robo de datos por parte de un tercero malicioso. La normativa considera incidente cualquier compromiso de la seguridad, incluidos los errores internos: una configuración incorrecta que deja datos accesibles sin autorización, o un empleado que comparte información por error, activan las mismas obligaciones que un ataque intencionado.
Tampoco es cierto que una alucinación del modelo o una respuesta incorrecta del sistema sea, por sí sola, un incidente de seguridad: son problemas distintos, aunque ambos afecten a la fiabilidad del sistema. Un incidente de seguridad implica un compromiso de la confidencialidad, integridad o disponibilidad de datos o del sistema, no simplemente que el sistema haya dado una respuesta de mala calidad.
Tampoco conviene asumir que un sistema de IA proporcionado por un proveedor de gran tamaño y buena reputación está exento de sufrir incidentes: el tamaño del proveedor reduce la probabilidad de algunos fallos, pero ningún proveedor está completamente a salvo, y la calidad real de su protocolo de respuesta importa tanto como su reputación de marca. Y, por último, no es cierto que la responsabilidad se traslade por completo al proveedor solo porque el incidente haya ocurrido técnicamente en sus sistemas. Como responsable del tratamiento, tu empresa mantiene obligaciones propias de notificación y de respuesta, incluso cuando el fallo de origen está fuera de su control directo, lo que refuerza la importancia de tener claro desde el principio el reparto de responsabilidades descrito en la seguridad y privacidad de los agentes de IA que contrata.
Conclusión
Un incidente de seguridad en un sistema de IA no se gestiona bien en el momento en que ocurre, se gestiona bien en las semanas anteriores, cuando el contrato con el proveedor y el protocolo interno ya están definidos con claridad. Esperar a que suceda para improvisar una respuesta es la forma más segura de convertir un problema técnico en una crisis de confianza evitable.
Si tu empresa quiere revisar si tiene un protocolo adecuado frente a incidentes de seguridad en sus proyectos de IA, pide un diagnóstico gratuito y lo repasamos juntos.