¿Quién responde si un incidente con IA ocurre un domingo?
Un empleado descubre un domingo que ha subido por error un archivo de clientes a la cuenta personal de un asistente de inteligencia artificial.
Lo comunica. Pero ¿a quién?
El responsable habitual no contesta. IT no sabe si puede bloquear la cuenta. Legal desconoce qué datos se enviaron. Nadie tiene claro si debe avisarse al proveedor, conservar capturas o esperar al lunes.
La empresa puede tener una política de uso de IA perfectamente redactada y, aun así, perder las primeras horas intentando localizar a la persona adecuada.
El problema no es que el incidente ocurra en domingo. El problema es que la respuesta dependa de la casualidad.
Una política describe; un ensayo comprueba
Muchas políticas internas indican qué herramientas están autorizadas, qué datos no deben compartirse y qué usos requieren revisión humana. Es necesario, pero no suficiente.
Cuando algo falla, aparecen preguntas más concretas:
- ¿Dónde se comunica el incidente?
- ¿Quién recibe el aviso fuera del horario habitual?
- ¿Quién sustituye al responsable si no está disponible?
- ¿Quién puede ordenar una medida técnica de contención?
- ¿Quién valora el impacto jurídico y contractual?
- ¿Dónde se registran los hechos y las decisiones?
Estas preguntas no se resuelven añadiendo una frase genérica como «comuníquese inmediatamente al responsable». Hay que convertir la política en un circuito que pueda funcionar con personas reales, permisos reales y tiempos reales.
Tampoco se trata de imponer disponibilidad permanente a toda la plantilla. Se trata de definir un sistema proporcionado al riesgo: un canal conocido, una persona de guardia cuando sea necesario, sustituciones expresas y criterios claros para escalar.
No todo incidente con IA es una brecha de datos
Conviene evitar dos errores opuestos.
El primero es minimizar cualquier problema porque «solo era una prueba con IA». El segundo es tratar cada salida incorrecta o cada uso no autorizado como si fuera automáticamente una brecha notificable.
Un incidente con IA puede consistir, entre otros supuestos, en:
- introducir información confidencial o datos personales en una herramienta no autorizada;
- conceder a un asistente permisos excesivos sobre correo, documentos o CRM;
- generar y utilizar una salida incorrecta con impacto sobre una persona;
- revelar información mediante una respuesta, un registro o una integración;
- ejecutar una acción no prevista a través de un agente o automatización;
- perder trazabilidad sobre el proveedor, el modelo o los datos tratados.
Solo algunos de esos supuestos constituirán una violación de la seguridad de los datos personales. Si la hay, el artículo 33 del RGPD establece que el responsable debe notificarla a la autoridad de control sin dilación indebida y, cuando sea posible, dentro de las 72 horas desde que tenga constancia, salvo que sea improbable que suponga un riesgo para los derechos y libertades de las personas.
La consecuencia práctica es importante: el primer aviso debe activar una evaluación, no una conclusión precipitada. Para decidir bien hacen falta hechos, responsables y evidencias.
Un simulacro sencillo: «archivo de clientes en una cuenta personal»
La empresa puede probar su capacidad de respuesta sin utilizar datos reales ni tocar sistemas de producción.
Plantea este supuesto ficticio:
El domingo a las 10:15, una persona comunica que ha subido un archivo de clientes a la cuenta personal de un asistente de IA. No sabe si el archivo se conserva, si se utilizó para entrenar el servicio ni si puede eliminarlo completamente.
El ejercicio no consiste en encontrar culpables ni en recitar la política. Consiste en comprobar si la organización puede empezar a actuar.
1. Activar el canal
La persona que detecta el problema debe saber dónde avisar. Un correo genérico que nadie revisa durante el fin de semana no es un canal operativo para un supuesto urgente.
El simulacro debe comprobar:
- si el canal es conocido;
- si genera acuse de recibo;
- si llega a alguien con capacidad para escalar;
- si existe una alternativa cuando el canal principal falla.
2. Identificar al responsable y a su sustituto
El procedimiento debe asignar funciones, no solo nombres. Las personas cambian, enferman, viajan o dejan la empresa.
Como mínimo, conviene definir quién coordina el incidente y quién asume esa función en su ausencia. Según el caso, también deberán intervenir IT o seguridad, protección de datos, legal, negocio y comunicación.
Una matriz breve puede bastar:
- Recibe: confirma el aviso y abre el registro.
- Coordina: reparte tareas y mantiene una visión común.
- Contiene: aplica las medidas técnicas autorizadas.
- Evalúa: analiza datos, personas afectadas y obligaciones.
- Decide: aprueba comunicaciones o medidas de mayor impacto.
- Sustituye: asume cada función si el titular no está disponible.
3. Contener sin destruir evidencias
La urgencia no justifica actuar a ciegas. Borrar conversaciones, cerrar cuentas o modificar registros puede dificultar la investigación posterior.
El equipo debe saber qué medidas puede adoptar de inmediato y cuáles requieren autorización. Por ejemplo:
- interrumpir una integración o automatización;
- revocar temporalmente un permiso o una sesión;
- impedir nuevas cargas de información;
- solicitar al proveedor la supresión o restricción del contenido;
- conservar identificadores, horas, capturas y comunicaciones relevantes.
La medida adecuada dependerá del servicio y del riesgo. La regla útil es contener lo necesario, preservar lo relevante y registrar quién decidió cada actuación.
4. Reunir los hechos mínimos
Antes de discutir sobre responsabilidades jurídicas, el equipo necesita una ficha inicial fiable:
- qué herramienta y qué tipo de cuenta se utilizaron;
- qué archivo o información se compartió;
- cuándo ocurrió y cuándo se detectó;
- quién podía acceder a los datos;
- qué permisos tenía la herramienta;
- qué dice el proveedor sobre conservación, uso y eliminación;
- qué medidas se han aplicado;
- qué información sigue sin confirmarse.
No hace falta resolverlo todo en la primera llamada. Sí hace falta separar lo confirmado de las hipótesis.
5. Evaluar obligaciones sin automatismos
Con los hechos iniciales, la empresa puede valorar si existen datos personales, información confidencial, compromisos contractuales o riesgos para terceros.
Si puede haber una violación de datos personales, debe iniciarse cuanto antes la evaluación prevista en el RGPD. El plazo de 72 horas no convierte toda incidencia en notificable, pero sí hace peligrosa una organización que espera al siguiente día laborable para empezar a investigar.
También puede ser necesario revisar contratos con clientes y proveedores, obligaciones sectoriales, pólizas de seguro o compromisos internos de comunicación. No todos los avisos deben salir de inmediato; todos deben tener un responsable y un criterio de decisión.
6. Cerrar el ejercicio con mejoras concretas
El valor del simulacro no está en que todo salga bien. Está en encontrar fallos sin sufrir un incidente real.
Al terminar, deberían quedar acciones concretas, con responsable y fecha:
- actualizar el canal de aviso;
- nombrar sustitutos;
- revisar permisos del asistente;
- documentar cómo solicitar la eliminación al proveedor;
- añadir una plantilla de registro;
- aclarar quién puede bloquear una integración;
- formar a las personas que reciben el primer aviso.
Si la conclusión es «ya nos llamaríamos», el ejercicio ha identificado una carencia real.
Qué debería poder demostrar la empresa
Una respuesta madura no exige un manual interminable. Exige poder demostrar, de forma proporcionada, que:
- existe un canal de aviso conocido;
- cada función crítica tiene titular y sustituto;
- las medidas de contención están autorizadas de antemano;
- se conservan hechos y decisiones relevantes;
- hay criterios para involucrar a IT, legal y protección de datos;
- se revisan los proveedores y sus mecanismos de eliminación, retención y soporte;
- el procedimiento se ha probado y mejorado.
Este enfoque conecta la gobernanza de IA con la gestión ordinaria de incidentes. La IA no necesita un universo paralelo de cumplimiento, pero sí obliga a adaptar el procedimiento a nuevas preguntas: qué modelo intervino, qué datos recibió, qué permisos tenía, qué acciones podía ejecutar y qué conserva el proveedor.
La pregunta no es si ocurrirá en domingo
Puede ocurrir un domingo, un martes por la noche o durante las vacaciones de la única persona que conoce la herramienta.
La fecha es lo de menos. La cuestión es si la empresa puede iniciar la respuesta sin improvisar el canal, las funciones y las autorizaciones.
Una política interna explica lo que debería hacerse. Un simulacro revela si puede hacerse de verdad.
Si tu empresa ya utiliza asistentes, conectores o agentes de IA, prueba un escenario ficticio de treinta minutos. No utilices datos reales. Comprueba quién recibe el aviso, quién sustituye a quién, quién puede contener y dónde se registran las decisiones.
El primer resultado del ejercicio no será un informe jurídico. Será algo más básico y más valioso: saber si, cuando llegue el aviso, alguien podrá empezar a actuar.
---
Lecturas relacionadas
- Qué hacer si se han enviado datos de clientes a una IA
- Política interna de uso de IA generativa
- Auditoría legal de IA para empresas
- Contacto