Australia: cuándo un prompt de IA se convierte en una brecha notificable

Un lunes por la mañana, una responsable de recursos humanos en Melbourne pega una hoja de cálculo en un asistente de IA de uso público para preparar un resumen: nombres, salarios, bajas por enfermedad, números de identificación fiscal. Se da cuenta de su error una hora después. La pregunta que llega entonces a la mesa del responsable de cumplimiento es sencilla: ¿es una brecha de datos que hay que notificar?

En Australia, la respuesta pasa por el régimen de notificación de brechas de datos, el Notifiable Data Breaches scheme. Fija pasos precisos y un plazo de evaluación de 30 días. Lo difícil es saber cómo aplicarlo a un incidente relacionado con la IA.

El régimen NDB en pocas palabras

El régimen figura en la parte IIIC de la Privacy Act 1988 y se aplica desde el 22 de febrero de 2018. Afecta a las entidades sujetas a los Australian Privacy Principles: los organismos del Gobierno federal y la mayoría de las organizaciones con una facturación anual superior a 3 millones de dólares australianos, además de algunas pequeñas empresas, como los proveedores de servicios de salud.

Una brecha es "elegible" cuando se cumplen tres condiciones:

• hay un acceso no autorizado, una divulgación no autorizada o una pérdida de información personal;

• es probable que cause un daño grave a una o varias personas;

• la entidad no ha podido evitar ese riesgo con medidas correctoras.

En ese caso, la entidad debe notificarlo a la Office of the Australian Information Commissioner (OAIC) y a las personas afectadas lo antes posible. Las cifras muestran que no es algo teórico: la OAIC recibió 1.113 notificaciones en 2024, un récord para el régimen.

Cuándo un prompt se convierte en una brecha elegible

Pegar información personal en una herramienta de IA externa no es automáticamente una brecha notificable. Pero puede constituir una divulgación no autorizada, sobre todo si la organización no ha aprobado la herramienta, si ningún contrato cubre los datos o si el proveedor puede conservar las conversaciones o usarlas para entrenar sus modelos.

Todo depende después del daño grave. Un nombre de pila y la fecha de una reunión pesan poco. Los números de identificación fiscal (TFN), los números de Medicare, la información de salud, los datos bancarios o los documentos de identidad cambian las cosas. En su guía de octubre de 2024 sobre productos de IA comerciales, la propia OAIC recomienda no introducir información personal, en particular sensible, en herramientas de IA generativa de acceso público. Presentamos esa guía en nuestro artículo sobre la Privacy Act, la OAIC y la IA generativa.

Los 30 días de evaluación

Cuando una entidad tiene motivos razonables para sospechar una brecha elegible, la ley le exige una evaluación razonable y rápida, y le pide tomar medidas razonables para terminarla en 30 días. En un incidente con IA, esa evaluación debe responder a preguntas concretas:

1. ¿Qué herramienta se usó y con qué tipo de cuenta: personal, gratuita o empresarial con contrato?

2. ¿Qué datos se enviaron, de cuántas personas y con qué grado de sensibilidad?

3. ¿El proveedor conserva las conversaciones y durante cuánto tiempo?

4. ¿Se puede obtener una eliminación confirmada por escrito?

5. ¿Pudieron los datos reutilizarse, compartirse o quedar expuestos a otros usuarios?

Sin un registro de lo que se envió, la segunda pregunta es muy difícil de responder. Ahí es donde muchas evaluaciones se atascan.

Un protocolo de respuesta en cuatro pasos

La OAIC propone un enfoque en cuatro pasos: contener, evaluar, notificar y revisar. Aplicado a la IA, queda así:

• Contener: borrar la conversación, desactivar el historial, pedir al proveedor que elimine los datos y suspender el acceso a la herramienta si hace falta.

• Evaluar: reconstruir los datos enviados, medir el riesgo de daño grave y documentar cada decisión.

• Notificar: si la brecha es elegible, preparar la declaración a la OAIC e informar a las personas afectadas con consejos prácticos.

• Revisar: corregir la causa, ajustar las reglas de uso de la IA y comprobar que el mismo gesto no pueda repetirse.

Las medidas correctoras son clave. Si la entidad actúa lo bastante rápido como para que el daño grave deje de ser probable, puede que no haga falta notificar. Pero tiene que poder demostrarlo.

Lo que cuesta gestionarlo mal

Desde la reforma de 2022, una injerencia grave o reiterada en la privacidad puede sancionarse con hasta 50 millones de dólares australianos, tres veces el beneficio obtenido o el 30 % de la facturación ajustada del periodo, la cifra que sea mayor. La reforma de 2024 añadió sanciones intermedias y avisos de infracción. Más allá de la multa, una notificación tardía o mal preparada daña la confianza de los clientes. Nuestro artículo sobre el coste real de la IA en la sombra analiza estos efectos.

Prevenir mejor que notificar

El mejor incidente es el que no ocurre. Un control en el momento en que el empleado pega o sube datos puede detectar un TFN, un número de Medicare o un historial médico, y después anonimizar, avisar o bloquear. Cada evento queda registrado, lo que alimenta directamente la evaluación de 30 días si, pese a todo, se produce un incidente. Para entender cómo se produce una fuga paso a paso, lea nuestro artículo sobre la anatomía de una fuga de datos por IA y, para el despliegue, nuestro manual de despliegue en 90 días.

En resumen

En Australia, un prompt con información personal puede convertirse en una brecha elegible según el régimen NDB. Las entidades deben entonces evaluar el incidente en 30 días y notificar a la OAIC y a las personas afectadas si es probable un daño grave. Un protocolo listo para usar, registros fiables y un control en el momento de pegar marcan la diferencia.

ZeusLock detecta y anonimiza TFN, números de Medicare y otros datos sensibles antes de que lleguen a un asistente de IA, y conserva el registro que necesita para una evaluación NDB. Solicite una demo de ZeusLock para preparar su respuesta a incidentes.