Los 9 Puntos Donde Tu Sistema de IA Filtra Datos (y Cómo Sellar Cada Uno)

Por Qué el Cifrado No Ayuda

La respuesta por defecto a "nuestro sistema de IA maneja datos sensibles" es "los cifraremos." El cifrado protege datos en reposo y en tránsito. No hace nada por los datos en uso. En el momento en que tu aplicación descifra datos de clientes para construir un prompt, esos datos quedan expuestos al proveedor del LLM, embebidos en vector stores, escritos en logs, pasados a través de llamadas a herramientas, almacenados en caché y guardados en reportes de errores.

Los sistemas de IA filtran datos de formas que las aplicaciones tradicionales no lo hacen. La superficie de ataque no es la red ni la base de datos. Es el pipeline: cada paso entre recibir la entrada del usuario y entregar una respuesta crea un punto potencial de filtración.

Mapeamos cada punto de filtración en los sistemas de IA que hemos construido y desplegado. Este artículo es el resultado. Para la solución arquitectónica (tokenización semántica, fronteras de confianza, restauración basada en políticas), consulta nuestra guía de cumplimiento RGPD. Este artículo se centra específicamente en dónde ocurren las filtraciones y cómo detectarlas.

Los 9 Puntos de Filtración

Entrada del Usuario (contiene PII)
    │
    ├──▶ 1. PROMPTS ────────────▶ El proveedor del LLM ve datos en bruto
    │
    ├──▶ 2. EMBEDDINGS ─────────▶ La Vector DB almacena PII permanentemente
    │
    ├──▶ 3. LOGS ───────────────▶ El agregador de logs indexa PII
    │
    ├──▶ 4. TOOL CALLS ─────────▶ APIs externas reciben PII en parámetros
    │
    ├──▶ 5. AGENT MEMORY ───────▶ El historial de conversación almacena PII
    │
    ├──▶ 6. ERROR MESSAGES ─────▶ El tracking de errores captura PII en stack traces
    │
    ├──▶ 7. CACHE ──────────────▶ La caché de respuestas almacena PII en respuestas cacheadas
    │
    ├──▶ 8. FINE-TUNING DATA ───▶ Los datos de entrenamiento contienen PII permanentemente
    │
    └──▶ 9. AGENT HANDOFFS ─────▶ PII cruza fronteras de confianza entre agentes

1. Prompts

El punto de filtración más obvio y el que la mayoría de equipos cree que ya resolvió. Cada prompt enviado a un proveedor externo de LLM contiene cualquier dato que pongas en él. Si incluyes el nombre de un cliente, su correo, historial de pedidos o texto de una reclamación en el prompt, el proveedor del LLM lo recibe.

Dónde se filtra:

• La API del proveedor del LLM recibe el prompt completo
• El proveedor puede registrar prompts para detección de abuso
• El proveedor puede usar prompts para mejorar modelos (depende de los términos de servicio y del tier API vs consumidor)

Cómo sellarlo: Reemplaza PII en bruto con tokens semánticos antes de que el prompt llegue al LLM. El modelo recibe {{person:p_001}} en lugar del nombre real. El token lleva metadatos (género, formalidad, idioma) para que el modelo pueda producir un output correcto.

// Antes: PII en el prompt
const prompt = `Write a reply to Sara Mustermann about order #12345`;

// Después: prompt tokenizado
const transformed = await guardai.transform(prompt);
// transformed.safe_text = "Write a reply to {{person:p_001}} about order {{order:o_001}}"
const response = await llm.generate(transformed.safe_text);
const final = await guardai.rehydrate(response, transformed.session_state);

2. Embeddings

Este es el punto de filtración que la mayoría de equipos pasa por alto completamente. Cuando embedes documentos para RAG, los vectores de embedding codifican información semántica sobre el contenido. Si el contenido contiene PII, los embeddings llevan una representación de esa PII en el vector store.

Dónde se filtra:

• La base de datos vectorial almacena embeddings derivados de documentos que contienen PII
• La búsqueda de documentos similares puede exponer PII de consultas no relacionadas
• Los backups de la base de datos vectorial contienen representaciones de PII

Cómo sellarlo:

Opción A: Tokeniza documentos antes de generar embeddings. Los embeddings se construyen sobre texto tokenizado. El vector store nunca contiene vectores derivados de PII.

Opción B: Embede documentos en bruto pero tokeniza en el momento de la consulta. El vector store está dentro de la zona de confianza. Solo los chunks recuperados cruzan hacia el LLM, y esos se tokenizan antes de cruzar.

// Opción A: embeder contenido tokenizado (más seguro, calidad de recuperación ligeramente menor)
const tokenized = await guardai.transform(documentText);
const embedding = await embedder.embed(tokenized.safe_text);
await vectorStore.upsert({ id: docId, embedding, metadata: { tokenized: true } });

// Opción B: embeder en bruto, tokenizar en el momento de la consulta (mejor recuperación, más complejo)
const embedding = await embedder.embed(documentText); // embedding en bruto
await vectorStore.upsert({ id: docId, embedding });
// En el momento de la consulta: recuperar chunks, luego tokenizar antes de enviar al LLM

Para más detalles sobre arquitectura de pipelines RAG, consulta nuestra guía de fiabilidad RAG y guía de búsqueda vectorial.

3. Logs

Tu infraestructura de logging se convierte en un almacén de PII en el momento en que registras prompts o respuestas en bruto. Tu cluster de Datadog, CloudWatch, Elasticsearch o Grafana Loki ahora procesa datos personales, cada uno requiriendo documentación RGPD, políticas de retención y procedimientos de acceso a datos del sujeto.

Dónde se filtra:

• Logs estructurados que contienen texto de prompts
• Middleware de logging de request/response
• Logs de debug durante desarrollo que llegan a producción
• SDKs de logging de terceros que capturan cuerpos de request

Cómo sellarlo: Registra IDs de tokens, nunca valores. Registra tipos de eventos, conteos de entidades, puntuaciones de confianza y nombres de políticas. Nunca registres el texto en bruto.

// Bien: log estructurado sin PII
logger.info('transform_complete', {
    session_id: 'ses_abc',
    entities_detected: 3,
    entity_types: ['person', 'email', 'phone'],
    policy: 'german-support',
    duration_ms: 12,
});

// Mal: PII en los logs
logger.info('Processing request', {
    input: 'Sara Mustermann wants to cancel order 12345...',
    // Esto ahora es PII en tu agregador de logs
});

4. Tool Calls

En sistemas agentic, el agente de IA llama a herramientas externas (APIs, bases de datos, servicios). Los parámetros de las llamadas a herramientas a menudo contienen PII extraída de la conversación. Una herramienta de búsqueda CRM recibe un nombre de cliente. Una herramienta de facturación recibe un número de cuenta. Una herramienta de email recibe una dirección de destinatario.

Dónde se filtra:

• Parámetros de llamadas a herramientas enviados a servicios externos
• Logging de llamadas a herramientas (los frameworks de agentes a menudo registran cada llamada)
• Datos de respuesta de herramientas cacheados en la memoria del agente

Cómo sellarlo: Intercepta las llamadas a herramientas en la frontera de confianza. El agente pasa parámetros tokenizados. El runtime resuelve los tokens a valores reales dentro de la zona de confianza, llama al servicio externo con datos reales y luego tokeniza la respuesta antes de devolvérsela al agente.

Agente: "Buscar cliente {{person:p_001}}"
  │
  ▼ (frontera de confianza)
Runtime: resuelve p_001 a "Sara Mustermann"
Runtime: llama a la API del CRM con el nombre real
Runtime: obtiene respuesta con datos reales
Runtime: tokeniza la respuesta
  │
  ▼
El agente recibe: "Cliente {{person:p_001}}, cuenta {{customer_id:cid_001}}"

El agente nunca ve ni almacena los valores en bruto. El servicio externo opera dentro de la zona de confianza. Para ver cómo implementamos esto en comercio agentic, consulta nuestra guía de protocolo de comercio agentic.

5. Memoria de Agentes

Los sistemas de IA agentic mantienen memoria de conversación a lo largo de los turnos. Esta memoria almacena todo el historial de la conversación, incluyendo cualquier PII que el usuario haya compartido. Si la memoria se persiste (Redis, base de datos), la PII se acumula con el tiempo.

Dónde se filtra:

• Historial de conversación en memoria durante la sesión
• Memoria persistida en bases de datos o key-value stores
• Memoria a largo plazo usada para personalización entre sesiones
• Memoria compartida entre agentes en sistemas multi-agente

Cómo sellarlo: Delimita la memoria por tenant, sesión e hilo. Tokeniza PII en la memoria de la misma forma que tokenizas prompts. Establece TTLs en la memoria persistida. Nunca compartas memoria entre fronteras de tenants.

// Delimitación de memoria: tenant + sesión + hilo
const memoryKey = `${tenantId}:${sessionId}:${threadId}`;

// El contenido de la memoria está tokenizado
const memory = [
    { role: 'user', content: 'I am {{person:p_001}}, my order is {{order:o_001}}' },
    { role: 'assistant', content: 'Let me check order {{order:o_001}} for you, {{person:p_001}}.' },
];

// TTL: la memoria expira después de que termina la sesión
await memoryStore.set(memoryKey, memory, { ttl: SESSION_TTL });

Para patrones de aislamiento de memoria multi-tenant, consulta nuestra guía de diseño multi-tenant.

6. Mensajes de Error

Cuando algo falla, los mensajes de error y stack traces a menudo contienen los datos que causaron el fallo. Un error de parseo JSON incluye el JSON en bruto. Un error de validación incluye el valor del campo inválido. Un timeout de API incluye el payload del request.

Dónde se filtra:

• Servicios de tracking de errores (Sentry, Bugsnag, Datadog APM)
• Stack traces en respuestas del servidor
• Logs de errores con contexto del request
• Reportadores de excepciones no controladas

Cómo sellarlo: Sanitiza los payloads de error antes de enviarlos al tracking de errores. Elimina los cuerpos de request del contexto de error. Enmascara PII en mensajes de error. Nunca devuelvas detalles de error en bruto a los clientes.

// Middleware de sanitización de errores
function sanitizeError(error: Error, context: any): SanitizedError {
    return {
        message: error.message,
        code: error.code,
        // Eliminar PII del contexto
        context: {
            session_id: context.session_id,
            entity_types: context.entity_types,
            // NO incluir: context.input, context.prompt, context.customerData
        },
    };
}

7. Caché

El cacheo de respuestas almacena la respuesta completa, incluyendo cualquier PII en la respuesta generada. Si una respuesta cacheada contiene "El pedido de Sara Mustermann fue enviado ayer," cualquier usuario posterior que active la misma cache key ve los datos de Sara.

Dónde se filtra:

• Cachés de respuestas a nivel de aplicación (Redis, Memcached)
• Cachés CDN (si las respuestas de IA se cachean en el edge)
• Cachés semánticas (preguntas similares devuelven respuestas cacheadas con PII)

Cómo sellarlo: Cachea respuestas tokenizadas, no rehidratadas. La caché almacena El pedido de {{person:p_001}} fue enviado ayer. Cada request de usuario se rehidrata con su propio mapeo de sesión.

Alternativamente, incluye el ID de sesión o tenant en la cache key para que las respuestas personalizadas nunca se sirvan al usuario equivocado.

8. Datos de Fine-Tuning

Si haces fine-tuning de un modelo con datos de clientes, esos datos quedan permanentemente embebidos en los pesos del modelo. No puedes extraer registros específicos de un modelo fine-tuneado. No puedes cumplir con una solicitud de eliminación RGPD para datos que se han usado en entrenamiento.

Dónde se filtra:

• Datasets de entrenamiento que contienen PII
• Pesos del modelo (los datos están codificados, no son extraíbles pero influyen en los outputs)
• Datos de entrenamiento almacenados por el proveedor del modelo durante el fine-tuning

Cómo sellarlo: Tokeniza los datos de entrenamiento antes del fine-tuning. El modelo aprende patrones del texto tokenizado, no de PII real. Si necesitas usar datos reales para la calidad del fine-tuning, documenta la base legal, implementa políticas de retención de datos y prepárate para reentrenar el modelo si una solicitud de eliminación lo requiere.

9. Handoffs entre Agentes

En sistemas multi-agente, un agente puede transferir una conversación a otro agente. El handoff típicamente incluye contexto de conversación, que contiene PII de la interacción. Si los agentes operan a través de diferentes fronteras de confianza (diferentes servicios, diferentes proveedores), la PII cruza esas fronteras durante el handoff.

Dónde se filtra:

• Mensajes de handoff entre agentes
• Almacenes de contexto compartidos usados por múltiples agentes
• Llamadas API de agente a agente que llevan estado de conversación
• Servicios orquestadores que enrutan entre agentes

Cómo sellarlo: Tokeniza el contexto del handoff. El agente receptor obtiene historial de conversación tokenizado, no PII en bruto. Cada agente opera dentro del mismo modelo de frontera de confianza. Los handoffs entre fronteras pasan por la misma capa de tokenización que cualquier otro cruce de frontera de confianza.

Para cómo diseñamos arquitecturas multi-agente con aislamiento adecuado, esa guía cubre los patrones.

El Guardia de Output: Detectando lo que el Modelo Inventa

Más allá de los 9 puntos de filtración en la entrada, hay un décimo problema: el modelo puede alucinar PII que no estaba en la entrada original. Si le pides al modelo que escriba una respuesta para {{person:p_001}}, puede inventar un número de teléfono, una dirección o un nombre de empresa de sus datos de entrenamiento.

Esta PII alucinada no está protegida por tu tokenización porque nunca fue tokenizada. La solución es una detección de segundo paso en el output del modelo:

async function outputGuard(response: string, sessionTokens: Set<string>): GuardResult {
    // Ejecutar detección de PII en la respuesta del modelo
    const detected = await detector.detect(response);

    // Verificar cada entidad detectada contra los tokens de sesión conocidos
    const unknown = detected.filter(entity => !sessionTokens.has(entity.tokenId));

    if (unknown.length > 0) {
        return {
            safe: false,
            flagged: unknown,
            action: 'remove_or_flag', // Eliminar PII desconocida o marcar para revisión
        };
    }

    return { safe: true };
}

El guardia de output detecta: números de teléfono inventados, direcciones alucinadas, nombres reales de empresas de los datos de entrenamiento, y cualquier otra PII que el modelo genere que no estaba en la entrada original.

Para más información sobre modos de fallo de la IA incluyendo alucinación, esa guía cubre los patrones más amplios.

Prioridad de Detección

No todos los puntos de filtración son igualmente peligrosos. Prioriza según la superficie de exposición y la sensibilidad de los datos:

Empieza con P0 (prompts y logs). Son los de mayor volumen y los más fáciles de corregir. Luego aborda P1 (tool calls, memoria, errores). P2 y P3 son importantes pero menos urgentes.

Errores Comunes

1. Creer que el cifrado resuelve el problema. El cifrado protege el tránsito y el almacenamiento. No hace nada cuando los datos se descifran para procesarlos, que es exactamente lo que hace un LLM.

2. Solo proteger la llamada final al LLM. Un workflow de agente de 5 pasos tiene 5 superficies de filtración. Proteger solo el paso de generación deja 4 sin proteger.

3. Registrar prompts para debugging. Cada prompt que registras es PII en tu agregador de logs. Registra IDs de tokens, tipos de entidades y metadatos en su lugar.

4. Sin guardia de output. El modelo alucina PII de los datos de entrenamiento. Sin una detección de segundo paso en el output, la PII alucinada llega al usuario final.

5. Cachear respuestas rehidratadas. Si la caché almacena "El pedido de Sara Mustermann fue enviado," cualquier usuario que active la misma cache key ve los datos de Sara.

6. Fine-tuning con datos en bruto de clientes. Una vez que la PII está en los pesos del modelo, no se puede extraer ni eliminar. Tokeniza los datos de entrenamiento.

7. Ignorar el tracking de errores. Sentry y Bugsnag capturan contexto del request por defecto. Ese contexto contiene PII si tus requests contienen PII.

8. Memoria de agente compartida entre tenants. El agente A en un tenant no debe tener acceso a la conversación del agente B en otro tenant.

Conclusiones Clave

• Los sistemas de IA tienen 9 puntos de filtración distintos. Prompts, embeddings, logs, tool calls, memoria de agentes, mensajes de error, caché, datos de fine-tuning y handoffs entre agentes. Cada uno necesita su propia estrategia de protección.

• El cifrado no ayuda en tiempo de procesamiento. Los datos deben descifrarse antes de que el LLM pueda procesarlos. La protección debe ocurrir en la capa de aplicación, no en la capa de transporte.

• La tokenización semántica es la solución arquitectónica. Reemplaza valores en bruto con tokens que llevan metadatos. El LLM procesa tokens. Los valores reales permanecen dentro de la zona de confianza.

• El guardia de output detecta PII alucinada. El modelo inventa datos de su set de entrenamiento. Una detección de segundo paso en el output captura entidades que no estaban en el mapeo de tokens de la sesión.

• Empieza con prompts y logs (P0). Son los de mayor volumen y los más fáciles de corregir. Luego aborda tool calls, memoria y errores (P1).

• Cada punto de filtración necesita monitoreo. Rastra cuántas entidades de PII se detectan, cuántas se tokenizan, cuántas se escapan. Genera alertas ante anomalías.

Aplicamos estos patrones en todos nuestros sistemas de IA a través de OGuardAI, nuestro runtime open-source de protección semántica de datos. Si estás construyendo sistemas de IA que manejan datos sensibles, habla con nuestro equipo o solicita un presupuesto. Consulta nuestros servicios de IA y nuestra página de confianza para más contexto sobre cómo abordamos la protección de datos.