Enmascaramiento de PII para agentes de IA — Clasificación de sensibilidad a nivel de campo
En la ruta de resultados del agente, FutrixData sustituye los valores sensibles por hashes seudonímicos derivados de un secreto y con sal añadida antes de devolver la fila a quienes invocan por MCP, Skill o CLI. La sustitución usa un algoritmo de hash determinista respaldado por un secreto, con la clave derivada de un secreto local almacenado en el almacenamiento de secretos a nivel del sistema operativo. El determinismo es lo importante: los agentes pueden seguir haciendo joins, agrupando y contando sin ver jamás los valores en bruto.
Qué significa enmascaramiento de PII en un contexto de IA
El enmascaramiento tradicional reescribe un valor antes de almacenarlo o antes de mostrarlo en una UI. El enmascaramiento de PII para agentes de IA traslada la reescritura al salida de datos — el momento en que una fila sale de tu base de datos hacia el contexto de un LLM. El agente sigue obteniendo una fila con formato correcto, los joins correctos y semántica de igualdad estable; sólo recibe masked:v1:8f3a1c9b72e04d11 en lugar de alice@example.com.
Esto importa porque, una vez que los datos entran en el contexto de un agente, pueden fluir hacia modelos externos, plugins, sistemas de logs, capturas de depuración y servicios de retransmisión de tokens — lugares donde la gobernanza de la empresa no llega.
Clasificación de sensibilidad de cinco niveles (extensible)
FutrixData incluye un modelo de clasificación de sensibilidad L1–L5. Los niveles son configurables; los valores predeterminados son los siguientes.
| Nivel | Significado | Ejemplos |
|---|---|---|
| L1 Público | Datos de negocio no sensibles | id, status, created_at |
| L2 Interno | Identificadores y metadatos internos | user_id, session_id, request_id |
| L3 Confidencial | Información personal indirecta, comportamiento, ubicación | ip_address, user_agent, device_id |
| L4 Sensible | Información personal directa, financiera, médica | email, phone, salary, date_of_birth |
| L5 Crítico | Credenciales, instrumentos de pago, PII de alta sensibilidad | password, credit_card, api_secret, home_address |
Por defecto, los agentes reciben L1–L3 en claro. L4 y L5 se sustituyen por hashes estables antes de llegar al agente. El rango accesible al agente es editable, y puedes personalizar a qué niveles (L1-L2) permites acceder al agente.
Cómo enmascara FutrixData en la ruta de resultados del agente
El enmascaramiento se calcula de forma determinista por valor:
- Convertir el valor del campo en bruto a una cadena.
- Derivar una clave HMAC por cada (fuente de datos, campo) a partir de un secreto local guardado en el almacenamiento de secretos a nivel del sistema operativo. El secreto local se genera en el primer arranque, permanece en el host y nunca lo abandona; el mismo valor en bruto en otra fuente de datos u otro campo produce un hash distinto.
- Calcular HMAC-SHA256 sobre el valor en bruto con esa clave derivada.
- Tomar los primeros 16 caracteres hexadecimales.
- Anteponer
masked:v1:y devolver el dato enmascarado al agente.
La misma entrada produce la misma clave dentro de una instalación, por lo que los agentes pueden hacer joins, group by, count distinct y razonar sobre la igualdad sin ver jamás el valor en bruto. La correspondencia es unidireccional sin el secreto local. El enmascaramiento determinista reduce la superficie de filtración — no es anonimización completa. Consulta limitaciones del enmascaramiento para el caso inverso.
Dos rutas de clasificación
FutrixData soporta dos formas de asignar niveles de sensibilidad — ambas escriben en el mismo almacén de clasificación.
- Clasificación por agente externo. Claude Code, Cursor o cualquier cliente MCP/Skill lee el esquema, clasifica los campos y devuelve el reporte mediante llamadas a herramientas. No se envían datos de filas — sólo nombres y tipos de columnas.
- Escaneo IA integrado para clasificación. La aplicación de escritorio lee el esquema, envía nombres y tipos de columnas (nunca valores de filas) al modelo personalizado que tú configures y presenta el resultado para una segunda confirmación humana. Las correcciones manuales y las escrituras de agentes externos se preservan entre re-escaneos.
Ángulo de cumplimiento
El artículo 5(1)(c) del RGPD exige minimización de datos — procesar sólo lo necesario. El Comité Europeo de Protección de Datos ha aclarado que los datos seudonimizados siguen siendo datos personales cuando aún pueden vincularse mediante información adicional. El enmascaramiento de PII no "hace desaparecer el cumplimiento"; reduce la superficie de filtración y facilita auditar y gobernar el salida de datos. El registro de auditoría guarda qué columnas se enmascararon en cada consulta, lo que da al equipo de seguridad algo concreto que atestiguar.
Ejemplos
// Raw row from PostgreSQL
{ "id": 1042, "email": "alice@example.com", "phone": "+14155550123", "status": "active" }
// Row delivered to the agent (default L1–L3 access)
{ "id": 1042, "email": "masked:v1:8f3a1c9b72e04d11", "phone": "masked:v1:b219ac74e1d908f2", "status": "active" }{
"data_source": "prod-postgres",
"table": "users",
"fields": [
{ "name": "id", "type": "bigint" },
{ "name": "email", "type": "varchar(254)" },
{ "name": "phone", "type": "varchar(20)" },
{ "name": "status", "type": "varchar(16)" }
]
}Preguntas frecuentes
¿Qué campos se enmascaran por defecto?
L4 (email, phone, salary, date_of_birth, etc.) y L5 (password, credit_card, api_secret, home_address) se enmascaran antes de llegar al agente. L1–L3 se devuelven en claro. Puedes editar el rango accesible por agente.
¿Los valores enmascarados son reversibles?
No sin la clave local. El enmascaramiento es un HMAC-SHA256 determinista respaldado por secreto; la clave HMAC se deriva por cada (fuente de datos, campo) a partir de un secreto local almacenado en el almacenamiento de secretos a nivel del sistema operativo y nunca abandona el host. La misma entrada produce el mismo hash dentro de una instalación, pero invertir un hash requiere la clave local; además, FutrixData sólo conserva los primeros 16 caracteres del hash, lo que hace la probabilidad de colisión extremadamente baja y prácticamente irreversible. Una salvedad importante: los espacios de entrada de baja cardinalidad (booleanos, género, edad en años, enumerados pequeños) siguen siendo vulnerables a la enumeración — cualquiera que pueda enviar entradas conocidas a través de la pasarela, o que posea el secreto local, puede construir una tabla de búsqueda para tales campos. La ruta de la Consola (humano autorizado) devuelve filas en bruto por defecto; sólo la ruta de resultados del agente está enmascarada. Consulta limitations — el enmascaramiento determinista reduce la superficie de filtración, no anonimiza un conjunto de datos para divulgación pública.
¿El enmascaramiento rompe los joins y las agregaciones?
No. La misma entrada produce la misma salida enmascarada, así que joins, group-bys, count-distinct y predicados de igualdad siguen funcionando sobre columnas enmascaradas. Pierdes ordenación y operaciones de subcadena en campos enmascarados — esas deben ejecutarse dentro del proxy, no en el agente.
¿Puedo personalizar los niveles de sensibilidad?
Sí. Los nombres de los niveles, descripciones, campos de ejemplo y el rango accesible para el agente son editables. También puedes añadir anulaciones por fuente o por tabla — por ejemplo, clasificar orders.notes como L4 en producción y L1 en la copia de staging.
¿Los datos hasheados siguen siendo datos personales según el RGPD?
En general, sí. El Comité Europeo de Protección de Datos trata los datos seudonimizados como datos personales cuando pueden vincularse de vuelta mediante información adicional. El enmascaramiento es una reducción de la superficie de filtración, no un interruptor mágico de cumplimiento — pero es una medida técnica defendible bajo el artículo 32 del RGPD.
¿Cuál es el sobrecoste de rendimiento?
El enmascaramiento por fila es un HMAC respaldado por secreto por cada campo sensible — sub-milisegundo para tamaños de fila típicos. El coste dominante en la mayoría de consultas es la propia base de datos y el round-trip al LLM, no el paso de enmascaramiento.
¿FutrixData envía metadatos de esquema a proveedores de LLM?
Puede hacerlo, en las rutas de AI Chat / conocimiento de esquema / asistencia para mapear relaciones de tablas — y es una ruta separada de las filas de resultados de consultas. Los metadatos de esquema pueden incluir nombres de tablas, nombres de columnas, tipos, índices y comentarios. El enmascaramiento de resultados no cubre automáticamente los metadatos de esquema, porque el esquema es la estructura que la IA necesita comprender, no los datos. La aplicación de escritorio expone un conmutador por fuente de datos para la transmisión de esquema al LLM, y cada transmisión se registra para que puedas auditarla. Si tu propio esquema codifica secretos comerciales (tablas KYC, códigos regulatorios, nombres de productos internos), desactiva el conmutador para esa fuente de datos. Consulta trust para el mapa completo de rutas de datos.
¿El enmascaramiento aplica a la Consola de escritorio?
No — por diseño. La Consola es la ruta de consulta del humano autorizado. El ingeniero al teclado es el inspector. El enmascaramiento aplica en la ruta de resultados del agente (MCP, Skill, CLI del agente). Si no quieres que un usuario dado vea valores en bruto, controla el acceso en la propia fuente de datos, no en la Consola.
Prueba FutrixData con tu propia base de datos
Aplicación de escritorio gratuita para macOS, Windows y Linux. Enterprise Edition autoalojada para despliegues en producción.