Un empleado ha subido datos de clientes a una IA. ¿Y ahora qué?

El problema no se resuelve borrando la conversación. Y tampoco enviando un correo a toda la plantilla para recordar que «eso estaba prohibido».

Imagina este supuesto ficticio: una persona de ventas copia en un asistente de IA una hoja con nombres, correos y observaciones sobre clientes. Quiere resumir oportunidades comerciales. Lo hace desde una cuenta personal, sin autorización y sin que la empresa haya revisado las condiciones del servicio.

No sabemos todavía si existe una brecha notificable. Sí sabemos que hay un incidente que exige hechos, contención y una decisión documentada. Estas son las preguntas que conviene resolver.

1. Detén la exposición, no la investigación

Interrumpe nuevas cargas de información y, si procede, desactiva enlaces compartidos o conectores afectados. Coordina cualquier retirada de acceso con IT para no perder evidencias ni interrumpir procesos innecesariamente.

Antes de borrar, recoge lo imprescindible: herramienta y tipo de cuenta, fecha, contenido enviado, archivos adjuntos, destinatarios o enlaces y configuración relevante. No conviertas la investigación en una segunda fuga distribuyendo capturas con datos personales por un grupo de mensajería.

Pide al proveedor información sobre acceso, conservación y posibilidades de eliminación. Borrar el historial visible no acredita por sí solo que hayan desaparecido todas las copias ni que nadie haya accedido a los datos.

2. Averigua qué datos salieron y bajo qué condiciones

No es lo mismo un listado de correos profesionales que información de salud, documentos identificativos o notas sobre personas vulnerables. Importan la naturaleza de los datos, el volumen, las personas afectadas, los posibles destinatarios y las consecuencias previsibles.

También importa la relación con el proveedor: ¿era un servicio aprobado? ¿Había un contrato adecuado? ¿Qué configuración estaba activa? ¿Se había compartido públicamente la conversación? Una política de IA que permita decidir y unos contratos con proveedores de IA revisados reducen la improvisación, pero no sustituyen el análisis del incidente concreto.

No des por hecho que toda herramienta usa los mensajes para entrenar modelos. Tampoco des por hecho lo contrario. Comprueba las condiciones aplicables a esa cuenta y a ese momento.

3. Distingue uso indebido, brecha y obligación de notificar

Usar una herramienta no autorizada puede incumplir una política interna sin que, por ese solo hecho, debamos concluir que hay una brecha notificable.

La AEPD explica que una brecha de datos personales es un incidente de seguridad que afecta a la confidencialidad, integridad o disponibilidad de datos personales. Si hay comunicación o acceso no autorizados, debemos analizar el caso como posible brecha.

Si se confirma una brecha, el responsable debe documentarla aunque no tenga que notificarla. La notificación a la autoridad de control competente procede salvo que sea improbable que entrañe un riesgo para los derechos y libertades de las personas. En caso de alto riesgo, también debe evaluarse la comunicación a los afectados conforme al artículo 34 del RGPD y sus excepciones.

No confundamos el riesgo reputacional de la empresa con el riesgo para las personas. La pregunta no es «¿quedaremos mal?», sino «¿qué daño puede causar esta exposición a quienes aparecen en esos datos?».

4. Las 72 horas no son un periodo para esperar

Cuando procede notificar, debe hacerse sin dilación indebida y, de ser posible, dentro de las 72 horas desde que el responsable tiene constancia de la brecha. No se trata de 72 horas laborables ni de un plazo que empiece cuando termina la investigación.

Si no dispones de todos los detalles, el RGPD permite facilitar información por fases sin dilación indebida. Esperar a tener un informe perfecto puede empeorar la respuesta.

El encargado, por su parte, debe informar al responsable sin dilación indebida cuando tenga conocimiento de una brecha. No conviene trasladar automáticamente al proveedor el plazo de 72 horas como si fuera una licencia para esperar.

5. Deja una decisión que otra persona pueda entender

Abre una ficha con estos campos:

• Momento de detección y de constancia de la brecha, con su justificación.
• Datos y personas potencialmente afectados.
• Herramienta, cuenta, accesos y destinatarios conocidos.
• Hechos confirmados, hipótesis y cuestiones pendientes.
• Medidas de contención y evidencias preservadas.
• Valoración del riesgo y motivos para notificar o no.
• Responsable de la decisión y siguiente revisión.

Esta ficha es una recomendación operativa, no un formulario legal obligatorio ni una garantía de cumplimiento. Lo importante es poder reconstruir qué ocurrió, qué se decidió y por qué. Una matriz clara de responsabilidades ayuda a evitar que IT, legal y negocio esperen unos a otros cuando el reloj ya está corriendo.

6. Corrige la causa, no solo el comportamiento

Quizá faltaba formación. Quizá la herramienta aprobada era inutilizable. Quizá nadie sabía dónde consultar una duda. Una prohibición que no ofrece alternativa puede desplazar el uso de IA hacia cuentas personales y hacerlo menos visible.

Tras contener y valorar el incidente, revisa los permisos, el catálogo de herramientas, los contratos y el canal de aviso. La reacción debe facilitar que el próximo error se comunique pronto, no que se esconda.

La madurez de una empresa no se mide por afirmar que nunca tendrá incidentes. Se mide por su capacidad para detectarlos, limitar sus efectos y justificar sus decisiones.

¿Tu empresa tiene una persona responsable y un procedimiento claro para estos casos? Si la respuesta depende de encontrar un correo antiguo, conviene revisar el proceso antes del siguiente incidente. Hablemos.

Contenido informativo general; cada incidente requiere una valoración específica.