No lo frena la tecnología. Tampoco lo frena, en general, una persona con nombre. Lo frena una pregunta que nadie puede contestar con la información que tiene arriba de la mesa: ¿qué hay adentro del dato que ese modelo va a leer?
El consejo que circula es correcto, y por eso es peligroso
En todas partes se lee la misma recomendación para sacarle provecho a un modelo: darle todo el contexto posible. Y es cierta. Sin material propio adentro, un modelo responde genérico; con el material propio, acierta.
El problema no es el consejo. Es el paso que casi nunca viene con él.
Un manual de marca se pega sin pensarlo, y está bien: no hay una persona identificable adentro. Tampoco la hay en una plantilla en blanco, en una norma publicada ni en un organigrama por cargo. Pero un export del CRM se pega igual de rápido. Un contrato firmado, un caso de soporte, un correo reenviado con toda su cadena. Y ese es el momento exacto en que el dato salió del perímetro de la organización sin que nadie lo registre como lo que fue: un egreso de datos que no se siente como uno.
La distinción que importa no es entre dato sensible y dato inocente. Es entre haberle sacado la identificación al dato antes de que saliera, o haberle pedido al modelo que no la mire. Lo primero es un control. Lo segundo es una instrucción, y una instrucción se puede ignorar.
Lo que de verdad está trabado
Cuando el comité no aprueba, el diagnóstico suele escribirse como un problema de riesgo. Casi siempre es un problema de inventario.
Una empresa regulada mediana tiene el dato repartido entre el CRM, SharePoint, el ERP, un par de bases departamentales y planillas que alguien mantiene hace seis años. Ninguno de esos sistemas fue diseñado para contestar la pregunta que el área legal necesita: qué datos personales hay acá, de quién, para qué finalidad y con qué base de licitud.
Sin esa respuesta, la conversación queda en un lugar donde ninguna de las dos partes puede ganar. Legal no aprueba lo que no puede describir, y el equipo de datos no puede describir lo que nunca inventarió. Así es como un caso de uso que se pagaba solo queda esperando permiso durante un semestre entero, sin que nadie lo haya rechazado.
Ordenarlo tiene pasos, y ninguno es un modelo
El trabajo que destraba esto no es de inteligencia artificial. Es de ingeniería de datos, y es aburrido en el mejor sentido de la palabra.
- Conectar las fuentes donde el dato ya vive, sin moverlo de su lugar.
- Estructurar lo que hoy es texto libre: contratos, correos, actas, casos de soporte.
- Desidentificar en la capa de dato, antes de cualquier egreso. El original en claro queda aparte, bajo llave, y no entra en una sesión con un modelo.
- Entregar el inventario clasificado, con la procedencia de cada documento registrada.
El punto que cambia la economía del asunto está en el tercer paso, y conviene decirlo despacio: el enmascarado es código determinista, no una decisión del modelo. Corre siempre, corre igual, y su resultado se puede reproducir y auditar. No es un aviso que el modelo pueda pasar por alto.
Un trabajo, dos resultados
Acá está la parte que casi nunca se ve cuando esto se presenta como un proyecto de cumplimiento.
El inventario clasificado que deja soltar la IA sin exponer a las personas es el mismo con el que el oficial de datos arma su registro de actividades de tratamiento y su evaluación de impacto. No son dos proyectos que compiten por el mismo presupuesto: es un trabajo con dos salidas.
El mismo dato que hace rendir a su equipo es el que prueba que cumplió. Nadie tiene por qué hacerlo dos veces.
El borde, dicho
Una promesa sin borde declarado no se puede auditar, así que va el nuestro.
El identificador nacional de cada país —RUT, CUIT, DNI, RUC—, el correo electrónico y el teléfono los detecta código determinista, con reglas verificables. El nombre de una persona no: depende del contexto, y por eso va a cuarentena con revisión humana en lugar de resolverse solo. Hay además cuatro campos que son juicio legal —base de licitud, finalidad, responsable y confidencialidad sin regla— y esos los pone una persona, no un algoritmo.
Un proceso que no declara dónde termina su automatización no se puede auditar. El nuestro termina ahí.
Una precisión más, porque la diferencia importa: el entregable es el sustrato con el que el oficial de datos construye sus documentos. El documento emitible y firmable está en desarrollo, y no lo ofrecemos como disponible. Andin no certifica a nadie: produce la evidencia con la que otro decide.
Por dónde parte
Si hay un proyecto de IA detenido, la pregunta que lo destraba no es qué modelo usar. Es qué hay adentro del dato, y quién puede demostrarlo. Tres preguntas alcanzan para saber en qué punto está una organización:
- ¿Hay una persona identificable adentro de lo que se le va a pasar al modelo? Nombre, identificador nacional, correo, teléfono, dirección.
- Si la hay, ¿alguien le sacó la identificación antes de que saliera, o se confía en pedirle al modelo que no la mire?
- ¿Queda registro en alguna parte de que ese dato salió?
Si la tercera no tiene respuesta, las dos primeras ya se contestaron solas.