Cómo usar IA con dato sensible sin sacar el dato de tu empresa.
Qué llama sensible la ley, qué cambia cuando ese dato entra en un flujo de IA, y la arquitectura que mantiene el identificador de la persona dentro de tu ambiente de principio a fin.
La respuesta corta.
Lo que cruza la frontera es el caso, no la persona. El identificador se cambia por una clave interna antes de que salga nada, la correspondencia entre clave y persona queda en una tabla dentro del ambiente del cliente, y el resultado del modelo vuelve y se reasocia ahí adentro. Del lado de afuera, nadie en ningún momento puede llegar a quién es.
Esto no es una restricción que estorba al proyecto: es lo que hace que el proyecto sea aprobable. En la mayoría de los casos en que la IA es útil —triaje, clasificación, priorización, resumen— el modelo no necesita saber de quién es el caso para acertar. Necesita los hechos del caso.
Este texto no es asesoramiento jurídico. Describe arquitectura y cita el texto de la LGPD brasileña con enlace a la fuente oficial. La lectura jurídica de tu caso es de tu área legal o de tu encargado de datos, y la arquitectura tiene que diseñarse junto con esa lectura.
Tres pasajes de la LGPD que deciden el proyecto.
Traducidos íntegros, sin parafrasear, porque la paráfrasis de un texto legal es por donde entra el error. La traducción al español es de trabajo: el texto oficial es el portugués de la Lei nº 13.709/2018, entera en el sitio del Planalto, con enlace al final de esta página.
"dato personal sensible: dato personal sobre origen racial o étnico, convicción religiosa, opinión política, afiliación a sindicato o a organización de carácter religioso, filosófico o político, dato referente a la salud o a la vida sexual, dato genético o biométrico, cuando esté vinculado a una persona natural"
Fíjate en el final de la frase: cuando esté vinculado a una persona natural. Es ese vínculo el que la arquitectura de frontera deshace antes de que el dato salga.
"Los datos anonimizados no serán considerados datos personales para los fines de esta Ley, salvo cuando el proceso de anonimización al que fueron sometidos sea revertido, utilizando exclusivamente medios propios, o cuando, con esfuerzos razonables, pueda ser revertido."
Es la parte que ningún proyecto lee hasta que hay un problema. La anonimización no es un sello: si se puede volver a la persona con esfuerzo razonable, el dato sigue siendo personal.
"Los agentes de tratamiento deben adoptar medidas de seguridad, técnicas y administrativas, aptas para proteger los datos personales de accesos no autorizados y de situaciones accidentales o ilícitas de destrucción, pérdida, alteración, comunicación o cualquier forma de tratamiento inadecuado o ilícito."
La ley obliga a la medida y no lista cuál. Quien escribe la lista es el proyecto, y por eso la frontera tiene que estar en un documento, no solo en el código.
La arquitectura de frontera, en cinco pasos.
Es la misma arquitectura que Moonxi opera en salud, donde el identificador del paciente no cruza la frontera del ambiente del hospital. El patrón vale para cualquier dato que no puede salir.
Clasifica antes de mover
Separa lo que es dato personal, lo que es dato personal sensible según la definición de la ley, y lo que no es ninguno de los dos. Sin esa separación escrita, toda decisión siguiente se vuelve opinión.
Dibuja la frontera en un diagrama
Una línea, dos lados: lo que se queda en el ambiente del cliente y lo que puede salir. El identificador de la persona se queda del lado de adentro. Ese diagrama es el documento que revisa el equipo de seguridad, no el código.
Cambia el identificador por una clave interna
Lo que cruza la frontera es el caso, no la persona. Una tabla espejo dentro del ambiente del cliente guarda la correspondencia entre la clave y el identificador real, y esa tabla nunca sale.
Aplica el permiso en la recuperación, no en el prompt
Quién puede ver qué se filtra antes de que cualquier fragmento llegue al modelo. Pedirle al modelo que no lo revele es control de acceso basado en buena voluntad.
Registra el acceso y prueba el camino de vuelta
Quién consultó, cuándo, sobre qué caso. Y prueba lo inverso: con el resultado en la mano y sin la tabla espejo, ¿se puede llegar a la persona? Si se puede, la frontera no existe.
La nube no transfiere la responsabilidad. La divide.
El modelo de responsabilidad compartida de AWS es explícito, y la mitad que suele tomar por sorpresa a las empresas es la de abajo.
La seguridad de la nube
Proteger la infraestructura que ejecuta los servicios: hardware, software, red y instalaciones físicas.
La seguridad dentro de la nube
Gestionar tus datos, incluidas las opciones de cifrado, clasificar tus activos y usar las herramientas de identidad y acceso para aplicar los permisos correctos.
Traducido al proyecto: ningún proveedor de nube clasifica tu dato, define quién puede ver qué ni decide qué puede salir de tu ambiente. Esas tres decisiones siguen siendo tuyas, y son exactamente de las que trata esta guía.
Preguntas sobre dato sensible y IA.
¿Qué llama la LGPD dato personal sensible?
El artículo 5º, inciso II, de la Lei nº 13.709/2018 define dato personal sensible como dato personal sobre origen racial o étnico, convicción religiosa, opinión política, afiliación a sindicato o a organización de carácter religioso, filosófico o político, dato referente a la salud o a la vida sexual, dato genético o biométrico, cuando esté vinculado a una persona natural.
¿Un dato anonimizado sigue siendo dato personal?
El artículo 12 dice que los datos anonimizados no se consideran datos personales para los fines de la ley, con una salvedad grande: salvo cuando el proceso de anonimización sea revertido usando exclusivamente medios propios, o cuando pueda ser revertido con esfuerzos razonables. Es decir, la anonimización no es un botón: es una propiedad que tiene que seguir siendo cierta después.
¿Se puede usar IA sin que el dato salga de mi empresa?
Se puede, y es la arquitectura estándar cuando el dato es sensible. Lo que cruza la frontera es el caso sin la persona: el identificador se cambia por una clave interna, la correspondencia queda en una tabla dentro de tu ambiente, y el resultado vuelve y se reasocia ahí adentro.
¿De quién es la responsabilidad por la seguridad cuando uso la nube?
Es compartida. AWS declara que responde por proteger la infraestructura que ejecuta los servicios: hardware, software, red y instalaciones. El cliente responde por la seguridad dentro de la nube: gestionar sus datos, incluidas las opciones de cifrado, clasificar sus activos y usar las herramientas de identidad y acceso para aplicar los permisos correctos.
¿Qué exige la ley en materia de seguridad?
El artículo 46 obliga a los agentes de tratamiento a adoptar medidas de seguridad, técnicas y administrativas, aptas para proteger los datos personales de accesos no autorizados y de situaciones accidentales o ilícitas de destrucción, pérdida, alteración, comunicación o cualquier tratamiento inadecuado o ilícito. La ley no lista las medidas: quien escribe la lista es el proyecto.
¿Esto es asesoramiento jurídico?
No. Esta guía describe arquitectura y cita el texto de la ley con enlace a la fuente oficial. La lectura jurídica de tu caso es de tu área legal o de tu encargado del tratamiento de datos, y la arquitectura tiene que diseñarse junto con esa lectura, no después de ella.
¿Tu proyecto de IA está detenido en legal?
La mayoría de las veces lo que falta no es un permiso: es un diagrama de frontera que alguien pueda revisar. El diagnóstico entrega ese diagrama junto con el plan y la cotización.
Fuentes
Los tres pasajes de ley se tomaron del texto oficial en el sitio del Planalto y se tradujeron al español; el modelo de responsabilidad compartida viene de la página de AWS. Ambos abiertos el 9 de agosto de 2026.