PII y gobernanza de datos: masking, retención, y el audit trail
En el momento en que un sistema de IA llega a un modelo, la data del cliente deja tu límite y aterriza adentro de un proveedor tercero. La gobernanza es la disciplina que acota lo que esa exposición te cuesta: masking de datos para que la PII nunca llegue al proveedor en claro, una garantía de retención cero para que lo que sí llega no quede guardado, y un audit trail para que puedas probar después qué pasó. El Einstein Trust Layer te da los tres por construcción para un agente en Agentforce — masking por entidad nombrada, acuerdos de retención cero con los proveedores de LLM, scoring de toxicidad, y un registro de auditoría con timestamp del prompt original, los scores de seguridad, y la respuesta original. Off-platform armás los mismos tres controles vos mismo: enmascarar antes de la llamada, firmar un acuerdo de retención cero con el proveedor, escribir tu propio audit log. Sin 'vs' — el mismo trabajo de gobernanza, por construcción en Agentforce o armado a mano off-platform. Y un matiz real por-feature: no toda feature de la API es elegible para retención cero (la Message Batches API de Anthropic no lo es), así que la garantía se chequea por feature, no se asume para el proveedor. El audit trail es lo que lee un auditor, y es el mismo registro de runtime que captura la observabilidad.
En el momento en que un sistema de IA llama a un modelo, la data de tu cliente cruza un límite. El prompt — que puede llevar un nombre, un email, un número de cuenta, el cuerpo de un caso de soporte — deja tu infraestructura y aterriza adentro de la de un proveedor tercero de LLM. Eso no es un bug a arreglar; es cómo funciona un modelo hosteado, y es verdad en el instante en que shipeás. La gobernanza de datos es la disciplina que acota lo que ese cruce te cuesta. Responde tres preguntas que un auditor, un regulador, o el pedido de un titular de datos te van a hacer tarde o temprano: ¿la data sensible tenía que llegar al proveedor siquiera, lo que llegó se está guardando, y podés probar después qué se mandó y qué volvió? Esta página es la respuesta a cada una — y, como en todo este catálogo, la respuesta es el mismo trabajo hecho de dos formas: por construcción en Agentforce, o armado a mano off-platform.
Esta es una referencia para la disciplina de gobernanza entre plataformas. La capa in-platform es el Einstein Trust Layer de Salesforce, que hace masking, retención cero, scoring de toxicidad, y el audit trail por construcción para un agente construido en Agentforce. Off-platform, sobre un stack de Claude API, construís los tres controles equivalentes vos mismo. Componen por dónde corre el sistema — el trabajo de gobernanza es idéntico, y la plataforma decide si heredás los controles o los armás. Esto vuelve operativo el principio 11, rastreá todo, del lado de los datos: el audit trail es el registro que lee un auditor.
El problema: la data sensible deja tu límite
Sostené la forma del problema antes que los controles, porque los controles solo tienen sentido contra ella. Cuando tu agente le manda un prompt a un modelo que no hostea, se abren tres riesgos distintos a la vez, y cada uno necesita un control diferente:
- Exposición. La PII del prompt ahora es visible para el sistema del proveedor. Hasta un proveedor confiable es un lugar más donde existe la data de tu cliente, un límite más que defender, un renglón más en un inventario de procesamiento de datos.
- Retención. Lo que llegó al proveedor podría quedar guardado — logueado, cacheado, o, en el peor caso, usado para entrenar un modelo futuro. La data que no podés borrar es data sobre la que no podés honrar un pedido de borrado.
- No repudio. Cuando algo sale mal — una respuesta equivocada sobre la que se actuó, una queja, una auditoría — la primera pregunta es "qué se mandó de verdad y qué volvió", y solo podés responderla si lo registraste en el momento. Sin registro, no hay defensa.
El masking ataca el primero. Una garantía de retención cero ataca el segundo. Un audit trail ataca el tercero. Un sistema de IA gobernado necesita los tres, y un sistema que tiene solo uno o dos tiene un hueco que un auditor va a encontrar.
Lo que el Einstein Trust Layer te da por construcción
Cuando el agente vive en Agentforce, esos tres controles — más el scoring de toxicidad — no son features que te acordás de agregar. Son propiedades de la plataforma, aplicadas a cada generación a medida que fluye por el Einstein Trust Layer, la capa de gobernanza que Salesforce corre entre Agentforce y el modelo. Acá está lo que hace cada capacidad:
| Capacidad | Qué hace |
|---|---|
| Masking de datos | La detección por entidad nombrada escanea el prompt buscando data sensible (nombres, emails, números de cuenta, números de seguro social) y reemplaza cada uno con un placeholder antes de que el prompt llegue al proveedor del modelo. El modelo razona sobre texto enmascarado; los valores se restauran en la respuesta a la vuelta. El proveedor nunca ve la PII en claro. |
| Retención cero de datos | Salesforce tiene acuerdos de retención cero con los proveedores de LLM, así que el proveedor no retiene tus prompts ni las respuestas generadas y no las usa para entrenar sus modelos. Lo que cruza el límite no queda guardado del otro lado. |
| Scoring de toxicidad | Cada respuesta generada recibe un score de toxicidad, adjuntando una señal sobre la que podés poner una compuerta antes de que el output llegue a una persona — el control de seguridad de salida cubierto en guardrails y seguridad, acá como una columna más de la misma capa. |
| Audit trail | La interacción se loguea con un timestamp: el prompt original, los scores de seguridad y de toxicidad, y la respuesta generada. Este es el registro que prueba qué pasó — la precondición para responder por lo que hizo el agente (principio 9). |
El audit trail es la fila que ata esta página al resto de producción. Tiene timestamp y captura el prompt original, los scores, y el output original — que es justo el artefacto que lee un auditor cuando pregunta "mostrame qué hizo este sistema en esta fecha". (Los mismos controles del Trust Layer, listados a la altitud de un build de Agentforce, están en agentes de Agentforce; las filas de masking y retención cero de ahí son las mismas filas de acá, enmarcadas para armar un agente en vez de para gobernar sus datos.)
Off-platform: armás los mismos tres controles
Esto no es un enfoque que compite — es el mismo trabajo de gobernanza, hecho a mano donde el agente corre off-platform. Sobre un stack de Claude API, los tres controles de la tabla se vuelven tres cosas que construís:
- Enmascarar antes de la llamada. Corré la detección por entidad nombrada sobre el prompt vos mismo y reemplazá la PII con placeholders antes de que el request deje tu infraestructura, restaurando los valores en la respuesta cuando vuelve. El mismo masking que el Trust Layer aplica por construcción, aplicado por tu código en cambio. El modelo razona sobre texto enmascarado de cualquier forma; la única diferencia es quién es dueño del paso de masking.
- Un acuerdo de retención cero con el proveedor. El proveedor tiene que no retener contractualmente tus prompts y outputs. Esto es una propiedad real y configurable de una relación de API — pero es la que tiene el filo más afilado, de lo que trata la próxima sección.
- Tu propio audit log. Registrá el prompt, los scores, y el output de cada llamada, con timestamp, en almacenamiento que vos controlás. Esta es la versión off-platform de la fila de auditoría del Trust Layer — y es el mismo log que tu capa de observabilidad ya quiere, que es por qué cuesta menos de lo que parece.
El hilo de todo el catálogo se sostiene también acá: la disciplina es idéntica entre superficies, y la plataforma solo decide si el control es tuyo de heredar o tuyo de armar. Un equipo que corre un agente adentro de Agentforce hereda los cuatro; un equipo en un stack externo construye los tres; un equipo que corre los dos hace cada uno donde tiene sentido.
El matiz: la retención cero es por-feature, no por-proveedor
Acá está el filo que agarra a los equipos, y es el único hecho de esta página que más vale llevarse: un acuerdo de retención cero no es una propiedad general de un proveedor — es una propiedad de las features específicas de la API que usás, y no toda feature califica. Firmás el acuerdo, asumís que tus llamadas están cubiertas, y una feature que agarraste para ahorrar costo silenciosamente no lo está.
La instancia concreta: la Message Batches API de Anthropic — el camino asincrónico de procesamiento en lote que corre los requests juntos a más o menos la mitad del costo por token — no es elegible para Retención Cero de Datos. En las propias palabras de Anthropic, "Esta feature no es elegible para Retención Cero de Datos (ZDR). La data se retiene según la política de retención estándar de la feature". Así que un pipeline que enmascara bien, corre bajo un acuerdo de retención cero, y después rutea sus jobs de evaluación en lote por la Batches API para ahorrar plata — sin que nadie lo decida — movió esa data fuera del camino de retención cero. La optimización de costo rompió silenciosamente la garantía de gobernanza.
La disciplina que lo previene es chica y absoluta: chequeá la elegibilidad de retención cero por feature, no por proveedor. Antes de que una feature entre a un pipeline gobernado, confirmá que está en el camino de retención cero; si no lo está, o la data tiene que estar enmascarada lo bastante fuerte como para que la retención sea aceptable, o esa feature queda afuera para esa data. El mismo cuidado aplica del lado de Salesforce — el Trust Layer gobierna el camino del LLM de la plataforma, y cualquier ruta de datos que no fluya por él no hereda sus garantías. La gobernanza es solo tan buena como su camino cubierto más angosto, y el camino sin cubrir suele ser el que alguien agregó por performance.
Compliance: el audit trail es lo que lee el auditor
Los tres controles existen por una razón que vive afuera de ingeniería: el compliance. Cuando un regulador examina un sistema de IA, o un cliente presenta un pedido de titular de datos, o el área legal necesita demostrar que la PII se manejó bien, lo que leen es el audit trail. El masking y la retención cero son los controles que limitan la exposición; el audit trail es el control que prueba que la limitaste. Un sistema que enmascara perfecto pero no loguea nada puede hacer lo correcto y no puede mostrar que lo hizo — y "confiá en nosotros" no es una respuesta para un auditor.
Este es el mismo artefacto, leído por un lector distinto, que la observabilidad captura para debuggear. El trace que tu runtime registra para dejarte reproducir una corrida mala — inputs, contexto recuperado, llamadas a tools, output — es, con los scores de seguridad adjuntos, el registro de auditoría que lee un revisor de compliance. Un solo log sirve para los dos: tracing y monitoreo es ese registro de runtime, construido para el ingeniero que persigue una degradación silenciosa; el audit trail es el mismo registro, leído por el auditor que pregunta qué pasó. Construilo una vez, a la más estricta de las dos varas, y responde las dos preguntas. El audit trail es donde la gobernanza y la observabilidad resultan ser el mismo instrumento apuntado a dos lectores.
El hilo
En el instante en que un sistema de IA llama a un modelo hosteado, la data del cliente deja tu límite, y la gobernanza es la disciplina que acota el costo: masking para que la PII nunca llegue al proveedor en claro, una garantía de retención cero para que lo que sí llega no quede guardado, y un audit trail para que puedas probar después qué pasó. El Einstein Trust Layer le da a un agente de Agentforce los tres por construcción — masking por entidad nombrada, acuerdos de retención cero con los proveedores, scoring de toxicidad, y un registro con timestamp del prompt, los scores, y el output. Off-platform armás los mismos tres a mano: enmascarar antes de la llamada, firmar un acuerdo de retención cero, escribir tu propio audit log. El mismo trabajo de gobernanza, heredado o armado — sin "vs". El filo que agarra a los equipos es que la retención cero es por-feature, no por-proveedor: la Batches API de Anthropic no es elegible para retención cero, así que una optimización de costo puede mover data silenciosamente fuera del camino cubierto, y la regla es chequear la elegibilidad por feature. Y el audit trail es la costura con el resto de producción — es lo que lee un auditor de compliance, y es el mismo registro de runtime que captura la observabilidad, construido una vez para los dos. La gobernanza no es una propiedad del modelo. Es el masking, la garantía de retención, y el registro que le ponés alrededor.
Related
- Qué es production readiness — la vara que una IA shipeada pasa; la gobernanza es una de sus columnas
- Production gotchas — los modos de falla que un sistema shipeado hereda, incluido un hueco de gobernanza que nadie poseía
- Costo y latencia — donde la Batches API te tienta a ahorrar plata y silenciosamente deja el camino de retención cero
- Guardrails y seguridad — el lado de scoring de toxicidad y screening de output del mismo Trust Layer
- Human in the loop y accountability — el audit trail es el registro desde el que responde el humano accountable (principio 9)
- Deployear a producción — poner el sistema gobernado en vivo y operable
- Production Style Guide — la vara que una IA de producción pasa antes de shipear
- Tracing y monitoreo — el registro de runtime que captura la observabilidad es el mismo log que lee el auditor
- Agentes de Agentforce — los controles del Trust Layer listados a la altitud de un build de Agentforce
- Tools y actions — el Trust Layer gobierna el camino del lenguaje; el radio de daño de una Action se gobierna aparte (principio 5)
- Principios de AI Engineering — rastreá todo (11), un humano es accountable (9), cada tool es un radio de daño (5)
- Einstein para Marketing Cloud — el Trust Layer enmarcado para la superficie de Marketing Cloud
- Arquitectura de datos de Data 360 — la data gobernada que la plataforma enmascara y sobre la que fundamenta vive en el modelo unificado
Reference: