La respuesta breve
El modelo de responsabilidad compartida no es solo un documento formal; es la línea que determina quién es responsable cuando algo sale mal. La regla simple: la plataforma es responsable de la seguridad del servicio en sí, y la organización es responsable de cada decisión sobre lo que el agente ve, lo que está autorizado a hacer y a quién responde.
El mayor riesgo no es una vulneración de la plataforma. Es un agente con demasiados permisos que expone información a una parte indebida o realiza una acción que no debería haber ejecutado —dos fallos que son enteramente responsabilidad de la organización.
Reparto efectivo de responsabilidades
| Área | Responsabilidad de la plataforma | Responsabilidad de la organización |
|---|---|---|
| Infraestructura | Cifrado, aislamiento, disponibilidad, gestión de vulnerabilidades | Selección del entorno y configuración de red aprobada |
| Datos | Almacenamiento y procesamiento según el acuerdo | Qué se indexa y qué se clasifica como sensible |
| Identidad y permisos | Mecanismos de autorización de la plataforma | Definición de quién puede ver y hacer qué |
| Comportamiento del agente | Capacidades del modelo y herramientas de control | Instrucciones, límites, puntos de aprobación |
| Acciones | Infraestructura de ejecución | Autorización de cada Action y validación dentro de esta |
| Monitoreo y auditoría | Registros (logs) de la plataforma | Registro de auditoría (audit trail) de negocio, muestreo y revisión |
Los nuevos riesgos que no existían en un CRM convencional
El primero es la exposición a través de la recuperación de información. En un sistema regular, el usuario ve lo que la pantalla le muestra; en un agente, un texto libre puede resultar en la extracción de un fragmento de un documento que no estaba destinado a él. Por lo tanto, la recuperación debe ejecutarse en el contexto de los permisos del usuario, y no en el contexto de una cuenta de integración amplia.
El segundo es el Prompt Injection. El contenido que el agente lee —un correo electrónico de un cliente, un campo de descripción, un documento adjunto— puede contener instrucciones que intentan alterar su comportamiento. No es posible protegerse de esto solo con formulaciones; la protección es arquitectónica.
El tercero es la fuga de contenido interno a un canal externo. Un artículo escrito para representantes con márgenes de descuento o argumentos de objeción no debería llegar al cliente, y la separación debe basarse en una lista de permitidos (whitelist), no en una lista de bloqueados (blacklist).
El cuarto es la ampliación silenciosa de la autoridad: la adición de una Action o un permiso para resolver un problema puntual, sin pasar por el proceso de aprobación.
Los cinco controles que soportan la mayor parte del peso
Recuperación de información en el contexto del usuario. Este es el único control que, si falla, hace inútiles todos los demás.
Permiso separado para cada Action, según el principio de privilegio mínimo. Un agente que recibe un perfil único y amplio impide cualquier control futuro.
Validación dentro de la operación y no en las instrucciones. Una instrucción es una dirección; una validación es un control. Una operación que realiza un reembolso debe verificar el monto, la elegibilidad y la autorización en su código, incluso si las instrucciones le dicen al agente que no la ejecute en ciertos casos.
Aprobación humana para una acción irreversible. Este es el control que convierte una posible falla en un incidente que se detiene a tiempo.
Registro de auditoría (audit trail) que vincula usuario, acción, origen y aprobador. Sin él, no hay respuesta a la pregunta de auditoría "¿con base en qué hizo esto el agente?".
Los principios generales del modelo de permisos en Salesforce se detallan en el modelo de permisos de Salesforce.
Qué verificar antes de entrar en producción (Go Live)
Pruebas de Persona: Se ejecutan diez a veinte preguntas con diferentes identidades —representante, gerente, usuario limitado, cliente externo— y se comparan las respuestas. Cualquier discrepancia que no se explique por un permiso es un hallazgo.
Red Teaming de contenido: Intentos deliberados de extraer información no autorizada, ejecutar una acción prohibida y eludir la escalada. Los escenarios se escriben una vez y se guardan para su ejecución repetida en cada versión.
Prueba del flujo de acciones: Para cada Action, se verifica que la validación funcione incluso cuando se activa directamente, no solo a través del agente.
Verificación de retención de datos: Qué se guarda, por cuánto tiempo, y quién puede acceder a los logs que contienen el contenido de la conversación con datos del cliente.
Cómo estas pruebas se integran en un marco de pruebas más amplio se explica en pruebas de Agentforce.
Escenario: Hallazgo en una prueba de Persona
Una empresa de salud preparó un agente interno para responder preguntas sobre procedimientos. En una prueba de Persona antes del lanzamiento, se descubrió que un usuario con un rol administrativo recibió una respuesta basada en un procedimiento clasificado solo para el personal médico.
La razón no fue un error en el agente. El índice fue construido por una cuenta de integración con acceso amplio, y la recuperación no se restringió según los permisos del usuario. La misma exposición existía potencialmente en cualquier pregunta relacionada con esa área.
La corrección incluyó dos acciones: trasladar la recuperación al contexto del usuario y marcar explícitamente los documentos clasificados para que no se incluyeran en el índice general. La prueba se agregó como un escenario fijo que se ejecuta antes de cada lanzamiento de versión.
Riesgos y acciones preventivas
| Riesgo | Cómo se detecta | Acción preventiva |
|---|---|---|
| Recuperación con permisos amplios | Exposición de un documento clasificado en una respuesta inocente | Recuperación en el contexto del usuario y pruebas de Persona |
| Prompt Injection | Acción ejecutada debido a contenido externo | Permisos restringidos, validación en la acción, aprobación humana |
| Mezcla de contenido interno y externo | Una formulación interna llega al cliente | Lista de permitidos (whitelist) en canal externo |
| Expansión silenciosa de la autoridad | El agente hace más de lo aprobado | Etiquetado de cambios significativos y reaprobación |
| Sin Audit trail | No hay respuesta para la auditoría | Registro de usuario, acción, origen y aprobador |
Métricas de seguridad
| Métrica | Qué revela | Frecuencia |
|---|---|---|
| Hallazgos de Persona | Brechas de permisos en la recuperación | En cada versión |
| Resultados de Red Teaming | Resistencia a intentos de elusión | En cada versión |
| Acciones sensibles sin aprobación | Fallos en el proceso de control | Mensual |
| Cambios que eludieron la aprobación | Disciplina del proceso de cambio | Trimestral |
| Cobertura del Audit trail | Porcentaje de acciones sensibles completamente documentadas | Trimestral |
El marco de aprobaciones dentro del cual se aplican los controles se detalla en Gobernanza de IA para Agentforce.
Cuando se requiere acompañamiento en la definición del modelo de responsabilidades y en las pruebas previas al lanzamiento, el servicio Agentforce e IA es el camino práctico a seguir.
Lista de verificación de seguridad previa al Go Live
- ☐ El documento de reparto de responsabilidades ha sido redactado y aprobado.
- ☐ Las condiciones de uso de los datos frente al modelo están documentadas por escrito.
- ☐ La recuperación de información se ejecuta en el contexto de los permisos del usuario.
- ☐ Se han realizado pruebas de Persona para cada nivel de permiso.
- ☐ Cada Action tiene un permiso separado y una validación interna.
- ☐ Las acciones irreversibles requieren aprobación humana.
- ☐ En el canal externo, funciona una lista de permitidos (whitelist) para el contenido.
- ☐ Se han escrito y ejecutado escenarios de Red Teaming de contenido.
- ☐ El Audit trail vincula usuario, acción, origen y aprobador.
- ☐ La política de retención de logs y contenido de conversación ha sido aprobada.