La mentalidad de logging no se traduce bien

La observabilidad tradicional tiene un valor por defecto bastante comprensible: recoger todo lo posible. El almacenamiento es barato, depurar es difícil, y nunca sabes qué log vas a necesitar dentro de seis meses.

Así que los equipos suelen retener telemetría durante 30, 90 o 365 días. A veces más.

Aplica exactamente la misma filosofía a trazas de IA y algo cambia. Puede que ya no estés almacenando solo:

POST /checkout — 200 — 183ms

Puede que estés almacenando:

Me llamo María García, vivo en [...], y he tenido problemas con...

durante meses.

El sistema de observabilidad se ha convertido, silenciosamente, en una base de datos de conversaciones de usuarios.

Al RGPD le importa la finalidad

El artículo 5 del RGPD establece, entre otros principios, la limitación del plazo de conservación. Los datos personales no deben permanecer identificables más tiempo del necesario para los fines para los que se tratan.

Eso convierte en un valor por defecto difícil de defender como estrategia general de retención:

lo guardamos todo por si algún día sirve para depurar

La solución no es simplemente «borrar logs más rápido». Distintas partes de una traza tienen distinto valor operativo y distintas implicaciones de privacidad.

Puede que quieras retener durante años estadísticas agregadas de latencia o coste. Puede que necesites trazas de ejecución detalladas durante semanas. El contenido de la conversación en bruto puede que solo sea útil durante días. Algunos valores sensibles puede que no necesiten llegar nunca al sistema de observabilidad.

Un buen modelo de datos debería permitir que cada una de esas cosas tenga un ciclo de vida distinto.

Los metadatos no son automáticamente anónimos

Hay otra simplificación fácil que conviene evitar. Es tentador dividir la telemetría en contenido = personal y metadatos = no personal. La realidad es más sutil.

Un recuento de tokens por sí solo no identifica a nadie. Tampoco lo hace una medida de latencia. Pero asocia esa medida a un identificador de usuario persistente, una sesión, una IP o una traza que se pueda conectar de vuelta a una persona identificable, y el registro conjunto puede seguir siendo un dato personal.

La pregunta importante no es si una columna de una base de datos parece sensible aislada. Es si la información se puede relacionar con una persona identificable. Ese es un límite mucho mejor sobre el que diseñar.

Y entonces alguien te pide que borres sus datos

El artículo 17 da a las personas un derecho de supresión en determinadas circunstancias. El derecho no es absoluto: el RGPD prevé motivos concretos para la supresión y también excepciones.

Pero cuando aplica una solicitud válida, el problema de ingeniería se vuelve muy concreto: ¿dónde están los datos de esta persona?

Imagina que la conversación original entró por tu API. Luego se copió en una traza de observabilidad. Luego parte de la traza se convirtió en un ejemplo de evaluación. Luego se generó un embedding. Luego un pipeline de analítica copió algunos campos a otra base de datos. Luego alguien exportó trazas para depurar un incidente.

Ahora llega la solicitud. Borra los datos de esta persona.

Aquí es donde la arquitectura empieza a importar mucho más que los documentos de política.

El borrado debería ser una consulta, no una investigación

Un sistema bien diseñado debería poder propagar un identificador de interesado por las partes relevantes del pipeline de datos. Entonces, un flujo de supresión puede localizar los registros asociados a ese interesado en los sistemas donde puedan existir datos personales.

Sin ese enlace, el borrado se convierte en trabajo forense. Buscar en prompts. Buscar en embeddings. Buscar en bases de datos analíticas. Buscar en exportaciones. Esperar haberlo encontrado todo.

Eso no escala.

El RGPD da a los responsables un plazo estándar de respuesta de un mes bajo el artículo 12.3, con la posibilidad de ampliarlo dos meses más para solicitudes complejas o numerosas, siempre que se informe al interesado. Eso puede sonar a tiempo de sobra. No es un buen motivo para dejar el borrado como un proceso manual.

Qué cambia si el backend nunca recibe el valor en bruto

Considera ahora una arquitectura distinta. Antes de que una traza de IA salga del entorno del cliente:

María García

se convierte en:

<PERSON_71C2>

y:

maria@example.com

se convierte en:

<EMAIL_B18F>

El backend de observabilidad nunca recibe los valores originales. Solo ve los tokens. Un almacén de mapeo controlado sabe qué representan esos tokens.

Esto no hace desaparecer mágicamente el RGPD. La tokenización y la seudonimización no son lo mismo que la anonimización. Si la información se puede reasociar a una persona usando información adicional, el RGPD puede seguir aplicando.

Pero la arquitectura cambia significativamente el problema. En lugar de distribuir información personal en bruto por cada sistema de observabilidad downstream, centralizas el mapeo sensible. Eso reduce la exposición. Reduce el número de sistemas que necesitan acceso a los valores originales. Y puede facilitar mucho el borrado.

Borra el mapeo y los tokens downstream pueden perder buena parte de su capacidad de identificar a la persona, dependiendo de qué otra información quede disponible.

Este es un punto de partida mucho más sólido que intentar descubrir y redactar cada copia del nombre de una persona después de los hechos.

Las trazas y los pesos de un modelo son problemas distintos

También hay una distinción importante entre borrar datos de un sistema de observabilidad y borrar información que pudo influir en un modelo entrenado. A veces estos problemas se mezclan en las discusiones sobre IA y RGPD. No deberían.

Una traza es un registro que decidiste almacenar deliberadamente. Sabes dónde está la base de datos. Controlas su retención. Puedes construir índices. Puedes borrar registros.

La información codificada en los parámetros de un modelo tras el entrenamiento es un problema mucho más difícil. Los reguladores europeos todavía están trabajando en preguntas sobre cuándo un modelo de IA que contiene o expone información sobre personas identificables debería considerarse en sí mismo como tratamiento de datos personales, y bajo qué circunstancias un modelo puede considerarse genuinamente anónimo.

Ese debate es importante. Pero no debería convertirse en una excusa para tener una mala arquitectura de trazas.

La privacidad debería ser visible en la arquitectura

Hay una tendencia a tratar el RGPD como documentación. Añadir una política de retención. Añadir un acuerdo de tratamiento de datos. Añadir un endpoint de borrado. Pasar la revisión de seguridad empresarial.

Pero las propiedades de privacidad más sólidas no viven en documentos. Viven en el diseño del sistema.

  • ¿Qué información sale del entorno del cliente?
  • ¿Dónde pueden existir valores en bruto?
  • ¿Cómo se representan los interesados?
  • ¿Qué sistemas reciben identificadores?
  • ¿Cuánto tiempo sobrevive cada tipo de información?
  • ¿Qué ocurre cuando hay que borrar a alguien?

¿Puede un ingeniero responder a esas preguntas mirando la arquitectura? Ese es el estándar al que creo que deberían aspirar los sistemas de observabilidad de IA.

Porque en cuanto los agentes empiezan a tocar correo, CRMs, documentos internos, tickets de soporte, información médica, datos financieros y conversaciones de usuario arbitrarias, la observabilidad deja de ser «solo logs». Se convierte en parte de la arquitectura de datos. Y la privacidad tiene que diseñarse en consecuencia.