Enmascaramiento de datos en la AI Gateway: Lo que realmente funciona

Qué es realmente el enmascaramiento de datos

El enmascaramiento de datos reemplaza un valor sensible por un sustituto que sea seguro de exponer, manteniendo utilizables los datos circundantes. Proviene del mundo de las bases de datos: dar a QA una copia de producción donde cada número de tarjeta sea 4111-****-****-1234 para que puedan probar estructuras realistas sin tener PII real. Dirija eso a una gateway de LLM y la situación cambia: está enmascarando texto libre, en camino hacia un tercero, dentro de una conversación que debe seguir teniendo sentido.

Estos términos se utilizan como sinónimos constantemente. No lo son.

Reversible vs irreversible es la distinción que importa. La tokenización, el FPE y el cifrado permiten viajes de ida y vuelta: alguien posee un vault o una clave, un nuevo activo a proteger. El enmascaramiento, la redacción y la anonimización son unidireccionales: más simples, más seguros e inútiles en el momento en que algo aguas abajo necesita el valor real.

La seudonimización no es anonimización. Bajo el GDPR, los datos seudonimizados siguen siendo datos personales y están dentro del alcance; solo los datos verdaderamente anonimizados quedan fuera de la regulación (Recital 26). Reemplazar cada nombre con un User-8812 estable es seudonimización, y llamarlo esto último no superará una auditoría.

Es fácil pasar por alto un tercer eje: la consistencia es independiente de la reversibilidad. Un enmascarador puede ser determinista —la misma entrada siempre produce el mismo sustituto— sin ser reversible, y el determinismo es lo que permite a un modelo razonar sobre "la misma persona" a lo largo de una conversación.

Qué se rompe al enmascarar tráfico LLM

Esta es la parte que la mayoría de las publicaciones omiten, y decide si su diseño sobrevive.

La calidad de la salida del modelo se degrada, de manera desigual. Convierta Llame a nuestra oficina al 312-555-1234 en Llame a nuestra oficina al ************ y el modelo ya no sabrá que eso era un número de teléfono; los asteriscos no aportan información de tipo. Los sustitutos etiquetados como [PHONE_NUMBER] mantienen el tipo, a costa de decir a cualquiera que vea el prompt lo que había allí. El resumen apenas se percibe afectado; la extracción falla estrepitosamente; correlacionar dos entidades falla silenciosamente, lo cual es peor.

Las llamadas a herramientas necesitan el valor real. El fallo más drástico. Un agente que enmascara cliente@acme.com al entrar no puede luego llamar a lookup_account(email=...). Enmascarar la ruta del modelo y dejar abierta la ruta de la herramienta crea el agujero opuesto: el modelo nunca vio la dirección, pero los argumentos de la herramienta la llevan a un servidor MCP de terceros. Decida, por herramienta, cuál es de mayor confianza.

La salida estructurada y los esquemas JSON se rompen. Si está utilizando estructuras de salida estructuradas con JSON Schema, el enmascaramiento puede producir un valor que ya no satisfaga su propio campo: un campo format: email no puede contener [REDACTED EMAIL], y un campo entero no puede contener asteriscos. El enmascaramiento que conserva la longitud es más favorable porque mantiene la forma. Enmascarar la etapa de salida es peor: el modelo produjo JSON válido, el enmascarador reescribió un valor dentro de él y su parser lanza un error ante una respuesta que el modelo generó correctamente.

Consistencia multiturno. Turno uno: "Priya Raman es la propietaria de la cuenta." Turno cuatro: "¿sigue siendo la propietaria?" Si el turno uno se convirtió en asteriscos, el modelo no tiene un hilo que seguir. La seudonimización determinista soluciona esto, pero solo si el enmascarador mantiene el estado entre turnos, algo que un guardrail sin estado no hace.

Recuperación RAG sobre texto enmascarado. Enmascare los documentos antes de indexar y el embedding ya no contendrá la entidad, por lo que una consulta sobre ella no recuperará el fragmento (chunk). Indexe sin enmascarar y enmascare en el momento de la recuperación, y su vector store contendrá el corpus sin enmascarar, precisamente lo que estaba evitando.

Aplicado de forma acotada, el enmascaramiento merece la pena. Aplicado de forma global, empeora silenciosamente el producto y nadie conecta ambas cosas.

Dónde se equivocan los equipos

Asumir que el enmascaramiento es de ida y vuelta. Un equipo enmascara PII de camino al modelo, asume que algo lo desenmascara al volver y construye sobre esa premisa. A menos que haya elegido un esquema reversible y algo mantenga las claves, quien realiza la llamada también ve el valor enmascarado.

Enmascarar el prompt y olvidar la ruta de la herramienta. Los datos se mueven en cuatro lugares: hacia el modelo, desde el modelo, hacia una herramienta y desde una herramienta. Cubrir uno es común. La fuga ocurre entonces a través del resultado de una herramienta que nadie estaba inspeccionando.

Tratar la redacción de registros como un control de flujo de datos. Redactar los registros almacenados limita quién dentro de su empresa lee los prompts. El proveedor siguió recibiendo el texto original.

Elegir enmascaramiento irreversible para un problema reversible. Si algo aguas abajo necesita recuperar el valor, el enmascaramiento es la técnica equivocada. Necesita tokenización o FPE, lo que implica un vault o una clave.

Cómo funciona el enmascaramiento en TrueFoundry

El enmascaramiento no es un producto independiente aquí. Cada guardrail tiene dos configuraciones: Operation Mode y Enforcement Strategy; el enmascaramiento es un valor del primero.

Mutate vs Validate

La prioridad es todo el modelo de ordenación para el enmascaramiento. Tres guardrails de tipo mutate en un mismo hook se ejecutan en orden, viendo cada uno la salida del anterior: un enmascarador de secretos en 1 y un enmascarador de regex en 2 significa que el guardrail de regex coincide con texto que ya se lee como ***REDACTED***.

La mutación de entrada es bloqueante y se ejecuta primero: la solicitud al modelo no puede comenzar hasta que el prompt sea final. La validación de entrada se ejecuta en segundo plano junto a ella, y si la validación falla a mitad del proceso, la gateway cancela la solicitud al modelo para que no pague por ella. La mutación y la validación de salida se ejecutan de forma síncrona después de que llega la respuesta, momento en el cual ya se ha incurrido en el coste del modelo.

Las llamadas a herramientas MCP añaden dos hooks síncronos: pre-invoke, donde un fallo significa que la herramienta nunca se ejecuta, y post-invoke, donde un fallo retiene el resultado. Los guardrails se ejecutan en cada llamada a herramienta por separado: cinco herramientas, cinco conjuntos de comprobaciones.

Enforce vs Enforce But Ignore On Error

La segunda configuración separa dos fallos: el guardrail encontró algo frente al guardrail se rompió.

Strategy

Ante una violación

Ante un error del guardrail

Enforce

Bloquear

Bloquear (fail-closed)

Enforce But Ignore On Error

Bloquear

Dejar pasar (degradación grácil)

Audit

Dejar pasar, solo registrar

Dejar pasar

La documentación llama a Enforce But Ignore On Error "la opción por defecto más segura" y recomienda la escala Audit → Enforce But Ignore On Error → Enforce.

Qué funciones integradas pueden enmascarar realmente

"Tenemos un guardrail de PII" no dice nada sobre si puede enmascarar.

PII / PHI Detection es la excepción: no puede bloquear, solo enmascarar. Si el requisito es "rechazar cualquier solicitud que contenga un SSN", este no es el guardrail adecuado.

Sus opciones de estrategia de aplicación documentadas son únicamente enforce y enforce_but_ignore_on_error —audit no figura en la lista, a diferencia de Secrets, Regex y SQL Sanitizer. El despliegue progresivo empezando por Audit no es uniforme en todas las funciones integradas. [VERIFY] si es una restricción real o una omisión en la documentación.

Regex Pattern Matching ofrece sustitutos etiquetados en lugar de asteriscos. Incluye 46 valores predefinidos —SSN, tarjetas de crédito, pasaportes de diez países, claves de cloud, tokens de GitHub y Slack, IPs— además de patrones personalizados, como EMP-\d{6} → [REDACTED EMPLOYEE ID].

Entre las integraciones de guardrails de terceros, las capaces de realizar mutaciones incluyen Google Model Armor, CrowdStrike AIDR, F5 AI Security, TrojAI, Enkrypt AI, Pillar Security, Lasso (classifix), HiddenLayer (/redact-*), DeepKeep y Noma —estas dos últimas requieren Mutate. Solo de validación: Cisco AI Defense, Gray Swan Cygnal, Patronus, NVIDIA NeMo, Guardrails AI, Arthur AI. Pedir a un proveedor de solo validación que enmascare es un camino sin salida.

Google Model Armor tiene un detalle importante en su configuración: Mutate necesita tanto una plantilla de inspección SDP como una plantilla de desidentificación en Google Cloud, vinculadas a la plantilla de Model Armor, con la transformación establecida en "Replace with infoType name". Sin ambas, la mutación falla.

La cuestión del desenmascaramiento, respondida con claridad

Los guardrails de enmascaramiento propios de TrueFoundry son unidireccionales. El modelo ve el valor enmascarado y también quien realiza la llamada. PII / PHI Detection, Secrets Detection y Regex Pattern Matching no documentan ninguna forma de restaurar el original, y no existe un vault de tokens a nivel de gateway ni un paso de rehidratación en la documentación a fecha de septiembre de 2026.

Existe exactamente un proceso de ida y vuelta documentado, y pertenece a un tercero. CrowdStrike AIDR admite cifrado con conservación de formato: cuando Operation es Mutate y la etapa de entrada cifró los valores con FPE, la gateway devuelve el fpe_context resultante a AIDR en la etapa de salida como input_fpe_context y llama a POST {baseUrl}/v1/unredact, de modo que se utilizan las mismas claves de principio a fin. Una ruta reversible real, pero necesita CrowdStrike, modo Mutate y un fpe_context de la etapa de entrada.

Por tanto, si su aplicación necesita recuperar el valor real, no planifique obtenerlo de la gateway. Manténgalo en su aplicación, envíe la versión enmascarada a través de la gateway y vuelva a vincular los datos mediante un identificador que usted controle. Un comportamiento relacionado de AIDR sorprende a muchos: una vez que genera una violación, Mutate no la suaviza convirtiéndola en redacción; la solicitud sigue devolviendo un error 400.

Un ejemplo práctico: un copiloto de soporte interno

Un copiloto de soporte lee el texto de los tickets y busca registros de cuentas a través de un servidor MCP. Los tickets contienen habitualmente correos electrónicos de clientes, números de teléfono e IDs de empleados internos.

Decida qué no debe llegar nunca al proveedor. Correos electrónicos y números de teléfono: enmascarar. IDs de empleados: enmascarar con una etiqueta, para que el modelo pueda seguir distinguiendo a dos empleados en un mismo ticket. Credenciales pegadas por error: enmascarar también a la salida.

Seleccione modos y prioridades. PII / PHI Detection en LLM Input, Mutate (su único modo), prioridad 1. Regex Pattern Matching en LLM Input, Mutate, prioridad 2, patrón personalizado EMP-\d{6} → [REDACTED EMPLOYEE ID]. Secrets Detection en LLM Output, Mutate. Inicie cada uno con la estrategia más flexible que admita.

Decida la ruta de las herramientas deliberadamente. La búsqueda de la cuenta necesita el correo electrónico real, por lo que la regla de enmascaramiento se dirige al modelo, no al servidor MCP; Secrets Detection se ejecuta en cambio en MCP Post-Invoke, capturando las credenciales que regresen en el resultado de una herramienta. Justifique el motivo: el servidor MCP está dentro de su VPC y el proveedor del modelo no. Esa justificación constituye el control real.

Vincúlelo con una política. Registrar un guardrail no lo aplica al tráfico. Vaya a AI Gateway → Policies → Guardrails → Add Rule y limite su alcance por objetivos (modelos, servidores MCP, opcionalmente por herramienta), sujetos (usuarios, equipos, cuentas virtuales con IN / NOT IN), metadatos y hooks. Las reglas coincidentes se combinan por hook.

Obsérvelo antes de confiar en él. Cada guardrail es su propio span en Monitor → Request Traces, mostrando tiempo de ejecución, resultado, alcance, entrada, salida y mutaciones. Una tasa de mutación cercana a cero en un hook concurrido significa que sus patrones son incorrectos; cercana al 100% significa que está a punto de descubrir cómo afecta el enmascaramiento a la calidad de la respuesta.

¿Listo para probarlo en una ruta?

Registre un guardrail de PII, vincule una política a un modelo y analice los spans de mutación.

Empiece gratis

Detalles importantes que conviene saber

El enmascaramiento no se ejecuta en la salida en streaming. Los guardrails de salida se omiten por completo cuando "stream": true, porque evaluar una respuesta requiere el texto completo. Los guardrails de entrada no se ven afectados. La mayoría de las interfaces de chat utilizan streaming por defecto, por lo que el enmascaramiento del lado de la salida no está activo en la interfaz que ven realmente los usuarios.

Los system prompts nunca se enmascaran. La gateway los elimina antes de enviar el contenido a cualquier guardrail, por lo que nunca se inspeccionan, bloquean ni redactan. La única excepción es CrowdStrike AIDR, que ve el system prompt pero nunca lo modifica. Si incluye una clave en un system prompt, ningún guardrail de enmascaramiento le protegerá.

La redacción de registros es un control diferente a Mutate. La configuración de registros basada en reglas de TrueFoundry redacta patrones de los cuerpos almacenados con lógica de denegación prioritaria: una regla coincidente con Log desactivado suprime el cuerpo por completo. Pero la documentación es explícita: "La redacción se aplica solo a la copia registrada... La solicitud en vivo reenviada al proveedor del modelo nunca se modifica." Gobierna quién dentro de su empresa lee los prompts, no lo que sale de ella. Nuestra publicación complementaria sobre prevención de pérdida de datos para tráfico LLM cubre la salida (egress).

El orden puede convertir un bloqueo en una aprobación. DeepKeep documenta esto concretamente: aplica la precedencia del primero en la lista entre las reglas que se activaron, no la acción más severa. "Si PII figura antes que Adversarial, un jailbreak que también active PII se redacta y se permite en lugar de bloquearse." Esto se generaliza a cualquier cadena de mutación: coloque las reglas que deben bloquear antes de las reglas que enmascaran.

PII / PHI Detection solo está disponible en la versión alojada por TrueFoundry. Se ejecuta en Azure AI Language y no está disponible en despliegues autoalojados o híbridos ("Gateway Plane only"). Utilice Azure PII con su propia clave, o CrowdStrike.

Lecturas relacionadas

• Prevención de pérdida de datos para tráfico LLM — la perspectiva de detección y salida
• Redacción de PII: Gateway vs Aplicación — dónde debe residir el control
• Guardrails de TrueFoundry AI Gateway explicados — el modelo completo de guardrails
• Estructuras de salida en LLM y JSON Schema — por qué colisionan el enmascaramiento y los esquemas
• Construyendo un marco de gobernanza de IA — la capa de políticas superior

Conclusión

El enmascaramiento de datos es un buen control que se aplica mal con más frecuencia de la que se aplica bien. El fallo rara vez es del enmascarador: suele estar en las suposiciones a su alrededor: que el enmascaramiento es de ida y vuelta, que la ruta de la herramienta está cubierta, que la redacción de registros es lo mismo, que el modelo razona igual de bien sobre asteriscos.

Vale la pena documentar cuatro decisiones primero. Qué tipos de entidades no deben salir bajo ninguna circunstancia. En cuál de los cuatro hooks se ejecuta cada regla. Si algo aguas abajo necesita recuperar el valor, ya que solo esa respuesta determina si se usa enmascaramiento o tokenización. Y qué nivel de calidad está dispuesto a aceptar en la salida, medido en lugar de asumido.

A continuación, construya de forma acotada: comience en Audit donde el guardrail lo permita, analice una semana de trazas, promueva a Enforce But Ignore On Error y mantenga Enforce completo para las rutas donde el bloqueo ante fallos (fail-closed) sea lo adecuado. Una gateway es el lugar idóneo para este trabajo: el punto único por el que pasan todos los modelos, equipos y agentes. Pero una regla de enmascaramiento que no ha observado es una regla que no comprende.

Aplique enmascaramiento en una ruta y analice las trazas

Empiece gratis