Prevención de pérdida de datos para tráfico de LLM: dónde debe situarse

Inspeccionar y controlar los datos sensibles antes de que salgan de su perímetro en un prompt, una llamada a herramienta o una respuesta del modelo. Se diferencia del DLP clásico en que no hay archivo ni destino no autorizado: la carga útil es JSON dentro de una sesión TLS hacia una API por la que usted paga. Los controles deben entender el esquema de la solicitud y situarse en un punto de control de salida autenticado.

Se suman tres razones. El destino está en la lista de permitidos por diseño, así que las reglas de destino nunca se activan. El contenido está en un array de conversación anidado en lugar de en un archivo o un campo de formulario, algo que los motores orientados a documentos analizan mal. Y sin inspección TLS no hay nada que analizar, mientras que ni siquiera un proxy con inspección puede saber qué llamante envió la solicitud.

Depende del detector. La detección de PII / PHI integrada de TrueFoundry es solo de mutación: siempre redacta, nunca rechaza. Para un bloqueo estricto necesita una integración con capacidad de validación, como AWS Bedrock Guardrails, Azure PII o CrowdStrike. «Detección de PII» en una lista de funciones nunca le dice si el resultado es una redacción o un 400.

Sí. TrueFoundry se ejecuta en su VPC, on-prem, en entornos air-gapped o híbridos, de modo que los prompts y las respuestas nunca salen de su dominio, incluso cuando enruta entre muchos proveedores.

Sí. Incluye un MCP Gateway, un Agent Gateway y un MCP & Agents Registry con control de acceso a nivel de herramienta. Los agentes creados con LangGraph, CrewAI, AutoGen o un framework propio pueden gobernarse de forma centralizada.

Sí. La pasarela es compatible con OpenTelemetry y se integra con Grafana, Datadog, Prometheus o tu pila preferida. Rastrea cada solicitud desde la instrucción (prompt) hasta la ejecución de la herramienta y el modelo, así obtienes un registro unificado sin tener que reemplazar lo que ya tienes en funcionamiento.