Enmascara tus registros, no tus indicaciones
Enmascara tus registros, no tus indicaciones
Casi cada guía de "asegura tu aplicación LLM" da el mismo consejo: antes de que una indicación llegue
al modelo, elimina los datos personales de ella — intercambia nombres, correos electrónicos y números de cuenta por
[REDACTED] o <PERSON>, luego llama al modelo.
Suena obviamente correcto. Yo también asumí que lo era. Luego fui y leí la investigación sobre lo que realmente hace el enmascaramiento a un modelo, y los documentos apuntan en la dirección opuesta. La versión corta: enmascara tus registros, no tus indicaciones.
Primero, ¿qué estamos protegiendo?
PII es información de identificación personal — un nombre, un correo electrónico, un número de teléfono, un ID de cuenta o gubernamental. Datos que apuntan a una persona específica.
Cuando las personas recurren al enmascaramiento previo a la llamada, generalmente están combinando dos preocupaciones diferentes en una:
- "No quiero enviar datos sensibles a quien ejecute el modelo."
- "No quiero almacenar datos sensibles en mis registros."
El enmascaramiento previo a la llamada está dirigido a #1. Mantén eso — resulta que es importante.
Problema 1: una indicación enmascarada es un modelo confundido
Aquí está el fallo más simple. Pon a tres personas en una indicación y enmascara a todas ellas como
[REDACTED], y el modelo ya no puede diferenciarlas. ¿Quién firmó el contrato? ¿Quién
fue copiado? Las palabras que llevaban esas relaciones han desaparecido, por lo que la respuesta se degrada.
Esto no es solo intuición. Un benchmark de 2026 llamado RedacBench midió el compromiso directamente, a través de 514 textos y 187 políticas. Incluso cuando un modelo capaz hace el enmascaramiento, subir el dial de seguridad a ~81% de contenido sensible eliminado te deja conservando solo 37.6% del significado no sensible del texto. Descartas aproximadamente 60% de lo que hacía útil la indicación para obtener esa privacidad.
"Pero yo uso tokenización inteligente" — aún así duele
La solución obvia es dejar de usar marcadores tontos. La tokenización determinista asigna el
mismo valor al mismo token cada vez — "John Smith" siempre se convierte en PERSON_42,
"Jane Doe" siempre en PERSON_17 — así que el modelo aún puede rastrear quién hizo qué. Eso es genuinamente
mejor.
Pero tampoco es gratis. Un ingeniero realizó 109 pruebas de enmascaramiento en flujos de trabajo de salud, legales, financieros y de desarrollo y escribió dónde falló. (Divulgación completa: él también vende una herramienta de tokenización, así que toma su marco con un grano de sal — pero los fallos que registró son concretos y fáciles de reproducir.)
- Rechazos por frases de contexto. Tokeniza un SSN en
GOV_ID_8x3m, pero deja las palabras "número de seguro social" al lado, y el filtro de seguridad del modelo puede rechazar toda la solicitud — ve una etiqueta sensible junto a un token opaco y lo marca. - Falsos positivos. La palabra "Will" en "esto actualizará el registro" fue atrapada por el detector de nombres.
- Faltantes. Un nombre corto como "Li" en una fila de tabla, o un SSN enterrado en comentarios de código, pasó desapercibido por el detector cuando no había suficiente contexto circundante.
- Corrupción en streaming. Un nombre o SSN puede dividirse en dos o tres fragmentos de streaming; procesarlos uno a la vez y estropeas la entidad.
Su detección general resultó en 89% — y su punto más agudo fue que el 11% que falta es donde duele: estás forzado a bloquear una solicitud legítima o filtrar. No hay un valor predeterminado cómodo.
Por qué nada de esto es sorprendente (mi lectura, no una prueba)
Retrocede y encaja en un patrón que la investigación sigue encontrando: los modelos son frágiles a cómo se formula una indicación.
- "Sobre el peor rendimiento de indicaciones de LLMs" tomó la misma pregunta, la reformuló de maneras semánticamente idénticas, y observó que la precisión de un modelo oscilaba en 45 puntos (en el peor de los casos, 9.38%).
- El marco DETAIL encontró que las indicaciones más específicas razonan mejor, especialmente en modelos más pequeños y tareas paso a paso.
Ninguno de esos documentos probó el enmascaramiento de PII — así que este siguiente paso es mi inferencia, no su afirmación — pero el enmascaramiento es una edición de indicación. Hace que la indicación sea menos específica y cambia su redacción, que es exactamente la palanca a la que estos documentos muestran que los modelos son sensibles. Estás tirando dados que no necesitas tirar.
La factura oculta
El enmascaramiento también cuesta dinero de una manera que es fácil de pasar por alto, porque cambia la indicación en cada llamada. Eso rompe silenciosamente el almacenamiento en caché de indicaciones — el descuento que obtienes cuando la apertura de una indicación es idéntica a una anterior.
Ambos proveedores principales almacenan en caché por prefijo, y ambos dicen que un cambio al principio lo invalida:
- OpenAI: "Los aciertos de caché solo son posibles para coincidencias exactas de prefijo… un cambio antes del punto de ruptura evitará un acierto de caché."
- Anthropic: "Los cambios en cada nivel invalidan ese nivel y todos los niveles subsiguientes."
Una lectura de caché cuesta aproximadamente 10% del precio normal de tokens de entrada. Así que cada indicación enmascarada
que no acierta en la caché paga cerca de diez veces más por esos tokens, y también renuncia al
primer token más rápido. Además, cuando un marcador enmascarado como PERSON_42 se filtra
en una llamada a la herramienta, la herramienta lo rechaza y el agente vuelve a intentarlo — y un estudio de agentes de codificación
encontró que pequeños cambios en la redacción de la indicación pueden multiplicar el uso de tokens 2.4–7.4× sin ganancia en
éxito. (De nuevo: no específicamente enmascaramiento, pero el mismo mecanismo.)
El replanteamiento: el modelo nunca fue el riesgo
Aquí está la parte que tenía al revés. El problema nunca fue que el modelo vea los datos. Un modelo que lee tu indicación para responderla simplemente está haciendo su trabajo — ese paso de inferencia no es donde se filtran los datos. La verdadera pregunta es retención: qué se almacena, y dónde.
Una vez que lo ves de esa manera, la solución es obvia. Coloca el enmascaramiento donde realmente ocurre el almacenamiento y donde tienes control: tus registros.
Enmascara tus registros, no tus indicaciones
El patrón — a menudo llamado solo registro — es simple:
- La indicación cruda llega al modelo, por lo que el razonamiento se mantiene intacto, la caché aún acierta, y nada se rechaza.
- Tu enmascaramiento de PII se ejecuta solo en el camino hacia el almacenamiento — los registros de solicitud/respuesta y trazas que escribe tu puerta de enlace.
Piensa en ello como tres peldaños, de peor a mejor:
- Enmascaramiento tonto (
[REDACTED]) — destruye las relaciones de entidad. - Tokenización (
PERSON_42) — mantiene identidades, pero aún activa rechazos y faltantes. - Solo registro — el modelo lee el texto real; el enmascaramiento ocurre donde descansan los datos.
Una advertencia honesta: sea cual sea el proveedor al que envíes indicaciones, vale la pena conocer su política de retención — esa es una pregunta separada de lo que lee el modelo, y es el lugar correcto para poner esa preocupación.
Si ejecutas tu propia puerta de enlace
La parte agradable: esto es una configuración, no una reescritura. Si ya has desplegado una puerta de enlace en una instancia WEC, la barrera funciona en modo solo registro — indicación limpia hacia el modelo, copia enmascarada en los registros. Un tutorial de seguimiento lo conectará de extremo a extremo.
Enmascarar una indicación antes del modelo te compra un checkbox de cumplimiento y vende silenciosamente la inteligencia de tu modelo. Coloca el trabajo de privacidad donde los datos realmente descansan — en los registros — y deja que el modelo lea lo real.
Fuentes
- RedacBench: ¿Puede la IA borrar tus secretos? — arXiv 2603.20208 — 80.9% de seguridad / 37.6% de utilidad con redacción agresiva
- Sobre el peor rendimiento de indicaciones de modelos de lenguaje grande — arXiv 2406.10248 — oscilación de 45.48%, 9.38% en el peor de los casos
- DETAIL importa: Especificidad de indicaciones y razonamiento — arXiv 2512.02246
- Desperdicio inducido por indicaciones en agentes de codificación — arXiv 2608.01347 — multiplicación de tokens de 2.4–7.4×
- Tokenización determinista vs. enmascaramiento para PII: 109 pruebas — r/LLMDevs — informe de un practicante (el autor vende una herramienta de tokenización)
- OpenAI — Almacenamiento en caché de indicaciones
- Anthropic — Almacenamiento en caché de indicaciones