Mapa de riesgos en el ciclo de vida de datos con IA

Cada dato que entra a un sistema de inteligencia artificial recorre un camino largo y, muchas veces, invisible. Saber exactamente dónde está ese dato, quién lo tocó y qué transformación sufrió es lo que separa a un proyecto responsable de uno que acumula riesgos en silencio. Aquí se presenta un método práctico para trazar ese recorrido completo, asignar responsables humanos a cada punto y detectar los momentos exactos donde la privacidad y la ética están en juego.

¿Qué es un mapa de ciclo de vida de datos y por qué importa?

Un mapa de ciclo de vida de datos traza el recorrido completo de un dato, desde que entra al sistema hasta que se elimina [0:27]. La analogía es directa: pensalo como un paquete postal. Querés saber quién lo tocó, a dónde fue y si alguien lo abrió. Sin ese mapa, los riesgos se esconden entre equipos, entre sistemas o entre contratos.

El problema real es que un equipo puede recolectar datos personales sin saberlo, mientras otro los cruza con otra tabla y, sin darse cuenta, genera información personal identificable [1:00]. El mapa fuerza claridad.

¿Cuáles son los 10 pasos del recorrido de datos en IA?

Para cualquier sistema con IA, el recorrido tiene 10 pasos mínimos, cada uno funcionando como punto de control técnico y ético [1:13]:

• Recolección: dónde entran los datos, con qué base legal y si el usuario lo sabe. Una ciudad con cámaras de tráfico debe responder esto antes de encenderlas [1:26].
• Clasificación: etiquetar qué es público, privado o sensible. Si combinás desempeño laboral con nombre y número de identificación, ya es información personal identificable [1:48].
• Limpieza y preparación: no solo se corrigen errores, también se detectan sesgos históricos. Un modelo que predice deserción escolar usando datos de barrios desatendidos va a castigar a esos mismos barrios si nadie atrapa el sesgo aquí [2:06].
• Anonimización o seudonimización: enmascarar identificadores cuando no son estrictamente necesarios [2:28].
• Almacenamiento y control de acceso: quién puede ver qué, por cuánto tiempo, con registro de cada acceso [2:36].
• Entrenamiento del modelo: qué versión de datos se usó y quién lo aprobó. Sin este registro, no podés rastrear la causa de un fallo [2:47].
• Validación y prueba de equidad: un scoring crediticio puede funcionar bien en promedio pero negar préstamos a ciertos códigos postales. Las métricas de equidad detectan eso antes de producción [3:02].
• Despliegue y monitoreo: los datos cambian con el tiempo, fenómeno conocido como deriva de datos, y el rendimiento se degrada. Un sistema médico con IA necesita un doctor humano revisando sus sugerencias [3:19].
• Registro de salidas y explicabilidad: cada decisión debe poder explicarse a una persona no técnica, lo que se conoce como IA explicable [3:36].
• Retención y eliminación: los datos tienen fecha de vencimiento. Regulaciones como el GDPR otorgan derecho a solicitar un borrado [3:50].

¿Dónde se pierde el control: las cuatro zonas de frontera?

Estos 10 pasos se organizan en cuatro zonas donde normalmente se pierde el control [4:03]:

• Zona de producto: lo que el usuario ve. ¿Sabe realmente qué datos está entregando?
• Zona de datos: la materia prima. ¿Fueron escrapeados, proporcionados o comprados? En América Latina, la ley 25.326 de Argentina o la LGPD de Brasil definen qué se permite [4:24].
• Zona de modelo: donde los datos se convierten en inteligencia. Si usás un modelo externo como Llama o DeepSeek, ¿con qué datos fueron entrenados? [4:37]
• Zona de proveedores: cada proveedor es un punto donde los datos salen de tu control. Si un hospital usa un chatbot externo y un paciente comparte síntomas, ¿a dónde van esos datos? [4:49]

Cada vez que los datos cruzan una de estas zonas, debería existir una regla explícita.

¿Por qué el join es el paso más peligroso para la privacidad?

El join, es decir, combinar dos conjuntos de datos, es probablemente el momento de mayor riesgo [5:10]. Un dataset hospitalario tiene IDs y condiciones de salud sin nombres. Un registro gubernamental tiene IDs y nombres. Al unirlos, cada condición de salud tiene nombre y apellido. El dato personal no existía hasta que se hizo el join.

La investigación muestra que tan solo tres atributos, código postal, fecha de nacimiento y género, pueden ser suficientes para identificar a una persona [5:42]. Incluso las inferencias cuentan: si alguien pide recetas bajas en azúcar y el sistema infiere una condición de salud, eso ya es un dato personal aunque nunca se haya declarado [5:55].

¿Cómo hacer auditable cada punto del mapa?

Cada punto necesita metadatos, que son la etiqueta del paquete, no el contenido [6:12]. Como mínimo deben incluir:

• Identificador único.
• Marca de tiempo.
• Base legal.
• Actor responsable con nombre y apellido.
• Clasificación del dato.
• Destino de transferencias.
• Transformaciones aplicadas.

Sin esto, no podés responder tres preguntas básicas: ¿quién recolectó esto? ¿Por qué se compartió? ¿Dónde está ahora? Y algo clave: si todos somos responsables, nadie lo es [6:50].

¿Cómo se aplica esto a un bot de soporte real?

Un bot que procesa tickets de cliente ilustra perfectamente los tres puntos de riesgo principales [7:22]:

• Captura de entrada: el usuario puede compartir datos personales sin darse cuenta. Controles: filtrado de datos personales, consentimiento activo y retención limitada.
• Procesamiento del modelo: las conversaciones pueden usarse para entrenamiento. Controles: barreras de seguridad, permisos por rol y revisión humana.
• Almacenamiento y proveedores: cuando los datos salen, perdés el control. Controles: minimización, límite de retención y auditoría de proveedores.

Si alguien escribe "me llamo María, tarjeta termina en 4567", eso nunca debería llegar en texto plano a un modelo externo [7:47]. Se debe detectar, reemplazar por marcadores y recién entonces enviar.

La diferencia entre evidencia vaga y evidencia real es enorme. No sirve "se verificó el sesgo". Lo que buscás es algo como: "encontramos una brecha del 12% en los códigos postales X, Y y Z, evaluado el 10 de mayo" [9:00].

Ahora pensá en el caso de Juan, de Colombia, que trabaja en una fintech que quiere usar IA para aprobar créditos combinando historial financiero, ubicación geográfica y comportamiento digital [9:26]. ¿En qué paso aparece un riesgo de privacidad? ¿Dónde hay un join peligroso? ¿Qué control propondrías? Dejá tu análisis o un caso real en los comentarios.