Primero: ¿de verdad la detección de PII vuelve lentos a los agentes?

No necesariamente.

Pero no existe un número universal útil para «la latencia de la anonimización». Distintas capas de detección operan en escalas completamente diferentes.

Regex y las comprobaciones deterministas simples pueden ejecutarse en el rango de submilisegundos o milisegundos bajos. Un modelo NER local basado en transformers puede tardar decenas de milisegundos. Un servicio de PII remoto puede fácilmente empujar la operación a cientos de milisegundos en cuanto entra en juego la latencia de red.

Un análisis de pasarelas de 2026, por ejemplo, usa cifras ilustrativas de menos de 2 ms para regex y comprobaciones de entropía, unos 35 ms P50 para NER local y unos 180 ms P50 para una API de PII externa, advirtiendo explícitamente que los valores reales dependen mucho del hardware, el tamaño del modelo, el batching y las condiciones de red.

Por eso «la protección de PII añade 100 ms» es casi un dato vacío sin una arquitectura detrás.

La pregunta más útil es:

¿Dónde estás colocando los detectores caros?

Ejecutar una comprobación de privacidad basada en LLM antes de cada llamada al LLM obviamente va a perjudicar. Ejecutar reglas deterministas más un encoder compacto en local es una propuesta muy distinta.

Roblox ofrece una buena prueba de realidad sobre lo que puede lograr una inferencia optimizada. Su clasificador de PII basado en XLM-RoBERTa-Large soporta picos superiores a 200.000 consultas por segundo manteniéndose por debajo de 100 ms P90, aunque se trata de un sistema de producción muy optimizado y apoyado en GPU que resuelve el problema específico de clasificación de Roblox, no una garantía de latencia lista para usar.

Así que sí, la privacidad tiene un coste. No se deduce que ese coste tenga que dominar la petición.

Los agentes cambian el factor de multiplicación

El problema difícil es que los agentes no hacen una sola petición.

Una sola acción de usuario puede provocar:

  • una llamada al LLM para decidir qué herramienta usar,
  • una consulta a base de datos o API,
  • otra llamada al LLM para interpretar el resultado,
  • una operación de recuperación,
  • otra llamada a herramienta,
  • y finalmente una o varias llamadas de síntesis.

Ahora imagina que entra PII en el primer paso. Puede que el usuario escriba:

¿Puedes revisar qué pasó con la cuenta de maria@example.com?

Lo redactas antes de la primera llamada al modelo. Bien.

Pero el agente después consulta tu CRM, que devuelve el nombre completo de María, su dirección de facturación y su identificador de cliente. Vuelves a tener datos sensibles. El paso de saneado original no ha hecho nada por proteger esa nueva información.

Por eso un agente no puede tener un único límite de privacidad en la entrada del usuario. Necesita límites alrededor del movimiento de los datos.

La unidad importante es el salto

Cada vez que un dato se mueve de un dominio de confianza a otro, yo lo trataría como un posible límite de privacidad. Puede ser:

usuario → agente
herramienta → agente
recuperador → modelo
modelo → herramienta externa
agente → log
agente → plataforma de trazas
agente → proveedor del modelo

Los límites exactos dependen de la arquitectura. El principio no.

Un sistema que sanea cuidadosamente el prompt original pero luego envía la salida en bruto del CRM a un proveedor de modelo no ha resuelto el problema. Ha movido la fuga un paso más adentro en el grafo.

La observabilidad es uno de los sitios donde más fácil es equivocarse

Hay un efecto secundario incómodo al construir sistemas de agentes más sofisticados: registramos más de ellos. Prompts. Entradas de herramientas. Salidas de herramientas. Estado intermedio. Excepciones. Trazas. Spans de latencia. Respuestas del modelo.

Todo esto es increíblemente útil cuando un agente empieza a hacer algo inexplicable en producción. También es una forma muy eficaz de crear una segunda copia de cada valor sensible que el agente ha visto jamás.

Este es el tipo de problema de privacidad que no aparece en el diagrama de arquitectura si el diagrama solo contiene «Usuario → Agente → LLM». La pila de telemetría también forma parte del sistema. También la base de datos vectorial. También el sistema de replay usado para evaluaciones. También cualquier plataforma que tus ingenieros usen para inspeccionar trazas.

Si el PII en bruto puede llegar a cualquiera de ellos, pertenecen al modelo de amenazas.

Sanear pronto sigue siendo el mejor valor por defecto

Para los datos que no necesitan salir de un entorno de confianza en su forma original, prefiero transformarlos lo más cerca posible de la fuente. No porque todo sistema deba redactarlo absolutamente todo, sino porque el número de sitios donde hay que recordar proteger el dato baja drásticamente.

Si:

maria@example.com

se convierte en:

[EMAIL_17]

antes de entrar en el resto del grafo del agente, cada componente downstream hereda la representación más segura. Eso es mucho más fácil de razonar que pedirle a doce servicios independientes que recuerden que los correos son sensibles.

Pero la redacción simple crea sus propios problemas.

Los agentes a menudo necesitan identidad sin necesitar la identidad

Imagina un agente trabajando sobre esta petición:

Mueve la reunión de Alice con Bob y avisa a Alice de la nueva hora.

Sustituye ambos nombres por [PERSON] y habrás destruido información útil. El modelo no necesita saber que Alice es Alice. Sí necesita saber que Alice y Bob son personas distintas y que la primera es también quien recibe el aviso.

Eso sugiere una transformación mejor:

Mueve la reunión de [PERSON_1] con [PERSON_2] y avisa a [PERSON_1] de la nueva hora.

Has eliminado los nombres originales conservando la estructura relacional que el modelo necesita para razonar.

Para sistemas agénticos, este tipo de consistencia referencial es extremadamente importante. Es una de las razones por las que la seudonimización reversible o la sustitución por surrogates se está volviendo más interesante que la redacción simple de caja negra. La sustitución por valores coherentes por tipo conserva más estructura semántica para el modelo y deja el PII original en local, que es exactamente el reparto que interesa.

Hay una trampa. El mapeo:

[PERSON_1] → Alice Smith

es en sí mismo un dato sensible. No has hecho desaparecer el problema de privacidad. Lo has concentrado en un componente más pequeño y controlable. Eso sigue siendo útil, pero necesita cifrado, control de acceso, una retención sensata y un alcance estricto.

Y aquí «anonimización» se vuelve una palabra peligrosa

Si el sistema puede restaurar [PERSON_1] a Alice Smith, el dato está generalmente seudonimizado, no verdaderamente anónimo. La distinción no es académica.

El Comité Europeo de Protección de Datos distingue explícitamente la seudonimización —reducir la capacidad de vincular un dato con una persona conservando esa posibilidad bajo condiciones controladas— de la anonimización, donde el vínculo se elimina de forma efectiva.

Eso significa que los identificadores reversibles no sacan mágicamente un pipeline del alcance del RGPD. Son una medida de seguridad y protección de datos dentro de él.

Esto importa porque a veces los equipos describen como «anónimo» cualquier valor que ya no contiene un nombre legible. Un UUID puede seguir representando a una persona. Un hash estable puede seguir representando a una persona. CUSTOMER_82371 puede seguir representando a una persona. La pregunta importante es si el dato se puede vincular razonablemente de vuelta a esa persona.

El AI Act no sustituye ese problema, y la multa titular se malinterpreta

También hay una tendencia a meter cualquier pregunta de cumplimiento relacionada con IA bajo el AI Act europeo. Para esta arquitectura en concreto, creo que eso es engañoso. El problema de privacidad del que hablamos sigue siendo principalmente un problema de protección de datos. El RGPD se aplica al tratamiento de datos personales exista o no un LLM de por medio en el software.

El AI Act añade un conjunto de obligaciones separado. Y el calendario es particularmente interesante ahora mismo. Las obligaciones de transparencia del artículo 50 empezaron a aplicarse el 2 de agosto de 2026. Incluyen requisitos de transparencia sobre ciertas interacciones humano-IA y contenido generado o manipulado por IA.

Al mismo tiempo, el AI Omnibus que entró en vigor el 27 de julio de 2026 retrasó los principales plazos de los sistemas de alto riesgo. Para los sistemas de alto riesgo del anexo III, las reglas relevantes ahora empiezan a aplicarse el 2 de diciembre de 2027. Para la IA de alto riesgo integrada en productos cubiertos por el anexo I, la fecha es el 2 de agosto de 2028.

Así que dos cosas pueden ser ciertas a la vez: algunas obligaciones del AI Act ya son muy reales, y algunas de las obligaciones que la gente asocia más con «cumplir el AI Act» todavía no aplican.

El titular que todo el mundo recuerda es: 35 millones de euros o el 7% de la facturación mundial anual. Ese número es real, pero se aplica a la categoría más grave: las violaciones de las prácticas prohibidas del artículo 5. Hay un detalle importante que a menudo se afirma mal. Para una empresa, el artículo 99 fija ese máximo en el mayor de 35 millones de euros o el 7%. Para las pymes, incluidas las startups, el reglamento en cambio limita la multa al menor de la cantidad fija y el porcentaje.

Otras infracciones tienen techos más bajos. Por ejemplo, las infracciones de transparencia del artículo 50 caen en la categoría cuyo techo es 15 millones de euros o el 3% de la facturación mundial para empresas, sujeto de nuevo a la regla de pyme. La ley también exige que las sanciones sean proporcionadas, y la autoridad considera factores como el tamaño de la empresa, la cooperación, la mitigación, la responsabilidad y si la infracción fue intencionada o negligente.

Así que la versión de redes sociales —«un error y a tu startup le cae una multa de 35M€»— no es un buen modelo de cómo funciona realmente el reglamento. Tampoco lo es fingir que las multas no importan.

La arquitectura que optimizaría no es, por tanto, «cumplir el AI Act»

Optimizaría por algo más duradero: saber dónde existen datos personales y controlar cada transición que hacen.

En la práctica eso es saber qué eventos contienen datos personales, qué herramientas pueden introducir datos nuevos, qué identificadores necesitan mantenerse estables para que el modelo razone, dónde viven los mapeos reversibles, qué acaba llegando a modelos de terceros, qué se escribe en los logs, cuánto sobrevive cada representación y en qué puntos se puede reconstruir el valor original.

Esto es menos vistoso que añadir una llamada a redact_pii() al principio de un agente. También está mucho más cerca del problema de ingeniería real.

La parte interesante de la privacidad en agentes no es el filtro

El filtro se está volviendo la parte fácil. Tenemos regex. Tenemos NER. Tenemos encoders específicos de PII cada vez más fuertes. Podemos usar varios detectores. Podemos seudonimizar. Podemos generar surrogates.

La pregunta difícil es qué pasa después de la primera detección. Los agentes mueven información entre componentes sin parar, así que los controles de privacidad tienen que dejar de ser una función de preprocesado y pasar a formar parte de la arquitectura de ejecución.

En cuanto lo miras así, el diseño cambia. Dejas de preguntar: «¿anonimizamos el prompt del usuario?» y empiezas a preguntar: «¿puede algún camino a través de este agente mover datos personales a un sitio donde no deberían estar?»

Esa es una pregunta mucho más difícil. También es la que merece la pena resolver.