Respuesta directa
En pocas palabras
Para prevenir la divulgación de información sensible en un AI Sales Copilot, decide antes de cada ejecución qué usuario, tenant, finalidad y destino están autorizados; recupera solo los campos necesarios; excluye secretos; tokeniza o redacta identificadores cuando el dato exacto no sea indispensable; limita retención y telemetría; y valida la salida antes de mostrarla, registrarla o enviarla. Prueba aislamiento entre cuentas, RAG, memoria, cachés, exportaciones y herramientas con datos señuelo. Una instrucción como «no reveles datos» o un filtro posterior no sustituyen autorización, minimización ni separación de tenants.
Entiende LLM02 como una falla de confidencialidad de extremo a extremo
OWASP LLM02:2025 cubre información personal, financiera, médica, legal, credenciales, datos empresariales confidenciales y propiedad intelectual que un modelo o su aplicación podrían exponer. En ventas B2B también entran listas de contactos, descuentos, márgenes, precios negociados, contratos, notas de discovery, transcripciones, estrategias de cuenta y documentos de compradores. La fuga puede aparecer en una respuesta visible, pero también en logs, trazas, cachés, evaluaciones, archivos exportados, webhooks o datos enviados a un proveedor.
La pregunta útil no es si el modelo conoce un dato, sino si ese dato debía llegar a ese contexto, bajo esa identidad y para ese destino. Una respuesta puede ser correcta y seguir siendo una violación de confidencialidad. Define el evento como acceso, uso, transmisión o revelación fuera de la finalidad y autorización previstas; después localiza la causa concreta: retrieval sin filtro, caché compartida, permiso excesivo, log detallado, herramienta abierta o salida enviada al destinatario equivocado.
Inventaría y clasifica la información antes de conectarla con IA
Construye un inventario que una fuente, campo, propietario, tenant, finalidad, sensibilidad, residencia, plazo, destinatarios y base de acceso. Incluye CRM, correo, calendarios, call recordings, catálogos, propuestas, Buyer Rooms, archivos adjuntos, embeddings, índices, prompts, feedback, evaluaciones, soporte y observabilidad. Distingue dato original, derivado y generado: un resumen de llamada puede conservar nombres, objeciones y compromisos aunque no replique la transcripción completa.
Usa niveles que produzcan decisiones operativas, por ejemplo público, interno, confidencial y restringido. NIST SP 800-122 propone evaluar el daño posible y el contexto de uso, porque los mismos campos pueden tener impactos distintos al combinarse o pertenecer a otra población. Añade reglas por clase: fuentes permitidas, si puede entrar al modelo, transformaciones obligatorias, destinos, retención, logging y aprobación. Una etiqueta sin enforcement solo decora el riesgo.
Reduce el contexto antes de intentar limpiarlo
La defensa más fuerte es no enviar lo que la tarea no necesita. Convierte cada función en un contrato de datos: para redactar un seguimiento quizá basten nombre de la empresa, acuerdos confirmados y siguiente paso; no hacen falta el historial completo, la lista de todos los contactos ni credenciales de integración. Recupera fragmentos pequeños, limita campos y rango temporal, y elimina adjuntos o notas que no participan en el resultado.
Minimizar también reduce superficie de prompt injection, errores de mezcla y costo. Evita el patrón «carga toda la cuenta y pide al modelo que elija». La selección debe ocurrir antes, con filtros deterministas y una política que conozca tarea, usuario y destino. Registra qué clases se excluyeron y por qué, sin copiar su contenido al log. Si el equipo no puede explicar la necesidad de un campo, ese campo no entra al contexto por defecto.
Tokeniza, redacta o generaliza sin perder la utilidad comercial
Cuando el texto necesita estructura pero no identidad exacta, reemplaza nombres, correos, teléfonos, identificadores fiscales, cuentas y referencias internas por tokens estables dentro de la ejecución. Mantén el mapa de reidentificación fuera del proveedor y con acceso separado. Para análisis agregados, usa rangos, categorías o métricas en vez de registros individuales. La transformación debe aplicarse antes de prompt, embedding, evaluación o soporte, no después de que el dato ya salió de la frontera.
No confíes solo en expresiones regulares: la información sensible puede aparecer en lenguaje libre, imágenes, tablas, combinaciones de campos o referencias indirectas. Combina detectores, diccionarios del negocio, reglas de esquema y revisión para clases de alto impacto. Mide falsos positivos y negativos por idioma y formato. Redacción no equivale siempre a anonimización; si el token, contexto o datos auxiliares permiten volver a identificar a una persona, conserva el tratamiento de dato protegido.
| Criterio | Uso adecuado | Límite |
|---|---|---|
| Enmascarado | Ocultar parte del valor en UI o logs | El dato original puede seguir existiendo aguas arriba |
| Tokenización | Separar identidad y contenido procesable | El mapa de tokens se vuelve un activo sensible |
| Pseudonimización | Reducir exposición durante análisis | Puede ser reversible o reidentificable |
| Agregación | Analizar tendencias y métricas | Grupos pequeños pueden revelar individuos |
Autoriza antes de retrieval y vuelve a comprobar antes de entregar
Aplica identidad, tenant, rol, pertenencia a cuenta, finalidad y clasificación en la consulta original. En RAG, el filtro de autorización debe restringir documentos y fragmentos antes de compararlos o ensamblar el prompt. No recuperes contenido global y confíes en que el modelo ignorará lo prohibido. Usa identificadores de tenant derivados de la sesión autenticada, nunca aceptados sin validación desde el texto del usuario o una instrucción del modelo.
Revalida al momento de la respuesta porque la audiencia puede diferir del solicitante: un vendedor prepara un correo para un comprador externo, comparte una Buyer Room o exporta un documento. Define una matriz sujeto–recurso–acción–destino y aplica deny by default. Si cambia el destinatario, la cuenta o el canal, vuelve a calcular la política. Cachea solo decisiones acotadas y revócalas cuando cambian permisos, equipos o relación comercial.
Aísla tenants, conversaciones, memoria, embeddings y cachés
Propaga un contexto de seguridad firmado o derivado del servidor a cada búsqueda, tool call, cola y evento. Separa índices, namespaces, claves y rutas cuando el impacto lo justifique; si compartes infraestructura, exige filtros obligatorios en una capa que el agente no pueda retirar. Evita que IDs secuenciales, metadatos o mensajes de error permitan enumerar recursos. Verifica backups, réplicas y entornos de prueba con la misma disciplina.
La memoria conversacional y las cachés semánticas merecen controles propios. Una respuesta generada para un tenant no debe reutilizarse porque otra pregunta se parece. Incluye autorización y versión de política en la clave o desactiva caché para contenido sensible. Limita la memoria al caso y a la duración necesarios, elimina referencias revocadas y prueba conversaciones paralelas. El aislamiento se demuestra intentando cruzar fronteras, no revisando solamente el diagrama.
Mantén secretos y credenciales fuera del contexto del modelo
El modelo no necesita recibir API keys, tokens, contraseñas, cookies, llaves privadas ni cadenas de conexión. Guarda secretos en un gestor dedicado y entrega a cada herramienta credenciales breves, específicas y con el menor privilegio posible. El orquestador ejecuta la acción y devuelve solo el resultado necesario. Nunca pegues secretos en prompts, archivos de instrucciones, ejemplos, tickets, datasets de evaluación o trazas para facilitar una depuración.
Instala detección de secretos en repositorios, cargas, logs y salidas, pero asume que alguna señal escapará. Prepara revocación y rotación, inventario de alcance, bloqueo de egress y alertas por uso anómalo. Si un secreto aparece en una conversación, trátalo como comprometido aunque la interfaz se cierre: puede persistir en logs, snapshots, colas o sistemas del proveedor. Borrar el mensaje visible no demuestra eliminación en todos los sistemas.
Verifica qué conserva el proveedor y para qué lo utiliza
Documenta por servicio qué entradas, salidas, adjuntos, feedback y telemetría salen de tu control; región, subprocesadores, cifrado, plazo, acceso de soporte, borrado, exportación e incidentes. Revisa la configuración efectiva del plan y del endpoint, no una frase comercial genérica. La opción «no se usa para entrenamiento» no significa necesariamente cero retención, cero abuso monitoring o cero acceso operativo.
Conecta el contrato con una prueba técnica: egress permitido solo a endpoints aprobados, cuentas separadas por ambiente, claves con alcance mínimo, configuración versionada y verificaciones periódicas. Define qué cambio de proveedor, modelo, región, términos o subprocesador reabre la evaluación. Mantén una alternativa de salida para datos y operación. Si una condición no puede verificarse, regístrala como dependencia declarada y limita la sensibilidad que puede cruzar esa frontera.
Controla la salida según su destino, no solo según su contenido
Clasifica cada salida y conserva procedencia de los fragmentos que la sustentan. Antes de mostrar, exportar o enviar, revisa autorización del destinatario, campos sensibles, combinaciones reveladoras, archivos adjuntos, enlaces y metadatos. Un texto apropiado para una nota interna puede ser inaceptable en una propuesta externa. Renderiza texto como texto, no como instrucciones ejecutables, y separa la validación de seguridad de la revisión comercial.
Los detectores de PII y secretos sirven como red secundaria, no como permiso. Bloquea o escala salidas de alto impacto y muestra al revisor por qué. Evita copiar contenido completo a la alerta. Para documentos y Buyer Rooms, verifica que el artefacto final y todos sus assets respeten la política; una vista previa correcta no garantiza que el PDF, DOCX, URL pública o correo lleven los mismos campos y permisos.
Diseña observabilidad útil sin crear una segunda base de datos sensible
Registra identidad técnica, decisión de política, clases de datos, fuente, destino, hashes o IDs de correlación, modelo, versión y resultado, pero evita prompts y respuestas completas por defecto. Usa muestreo, redacción y acceso just-in-time para depuración. Separa logs de seguridad, producto y proveedor; define propietarios, retención y borrado. Protege dashboards, exports y alertas, porque suelen reunir información de muchos tenants en un solo lugar.
Los conjuntos de evaluación y feedback también requieren minimización. Prefiere casos sintéticos o desidentificados, conserva consentimiento y finalidad cuando uses casos reales, y bloquea la copia automática de conversaciones de producción. Limita quién puede descargar resultados de evaluación. Cuando un fallo necesita evidencia, guarda el mínimo reproducible en una bóveda con acceso y vencimiento, no en el issue tracker general.
Prueba la confidencialidad con canarios y ataques reproducibles
Crea datos señuelo únicos por tenant, fuente y capa: contactos ficticios, códigos canario, precios de prueba y documentos sintéticos. Intenta extraerlos mediante búsqueda directa, inferencia, prompt injection, conversación larga, cambio de idioma, resumen, exportación, herramienta, error y caché. El canario demuestra una ruta de exposición cuando aparece; su ausencia no demuestra que todas las rutas estén cubiertas.
Mantén una suite por release con pruebas positivas y negativas: el usuario autorizado obtiene lo necesario y el no autorizado recibe una respuesta uniforme sin confirmar existencia. Mide cruces de tenant, datos sensibles enviados al proveedor, salidas bloqueadas, falsos negativos, campos por tarea, retención efectiva y tiempo de revocación. Repite ante cambios de modelo, RAG, parser, permisos, prompts, herramientas, logging y exportación.
Responde a una divulgación como incidente de datos, no como fallo de copy
Contén la ruta: desactiva la función o fuente, revoca sesiones y credenciales, bloquea destinos y congela borrados que destruyan evidencia. Determina qué datos, personas, tenants, prompts, herramientas, proveedores, logs, caches, exports y periodos están implicados. Conserva decisiones y artefactos con acceso controlado. Corregir el texto de una respuesta no elimina copias ya enviadas ni revoca enlaces compartidos.
Después elimina o restringe el origen, rota secretos, purga caches y artefactos conforme al procedimiento, valida la corrección y monitoriza recurrencia. Coordina evaluación legal y notificaciones según jurisdicción, contrato y tipo de dato; esta guía no sustituye asesoría legal. Cierra con causa técnica, fallo de control, alcance, incertidumbre, acciones, dueño y fecha. Busca el error que permitió el acceso, no solo el prompt que lo hizo visible.
Implementa una arquitectura donde cada frontera pueda negar
Una ruta robusta autentica al usuario; resuelve tenant, rol y finalidad; aplica política al retrieval; minimiza y transforma campos; construye un contexto con etiquetas de procedencia; llama al modelo mediante egress controlado; valida la salida para el destino; solicita revisión cuando corresponde; y registra decisiones sin contenido innecesario. Las herramientas reciben capacidades limitadas, no la identidad general del modelo ni credenciales maestras.
Aplica defense in depth, pero asigna responsabilidad clara a cada control. El prompt orienta comportamiento; el gateway limita proveedores y volumen; el policy engine autoriza recursos; el almacén aísla datos; el renderer neutraliza contenido; y el flujo de aprobación controla consecuencias. Prueba qué ocurre si cada capa falla. Si la confidencialidad depende de que todas las instrucciones se obedezcan perfectamente, la arquitectura ya concedió demasiado acceso.
Aplica los controles al alcance verificable de Cerravi
OWASP LLM02 aporta la taxonomía técnica de divulgación; NIST AI 600-1 organiza riesgos y acciones para sistemas generativos; NIST SP 800-122 ayuda a valorar contexto e impacto de PII; y MITRE CWE-200 explica que la pérdida de confidencialidad suele ser consecuencia de fallas más concretas. Estas referencias orientan diseño y prueba: no constituyen certificación de Cerravi ni reemplazan el análisis legal aplicable en México o cada país de Latinoamérica.
En Cerravi, Copilot organiza contexto y propone borradores para revisión humana; los recorridos públicos no envían mensajes ni cambian etapas automáticamente. Las propuestas usan productos y precios conocidos, y un importe faltante se marca para confirmación. Las monedas permanecen separadas salvo conversión aprobada. Buyer Room aporta señales sin probar identidad, aceptación, firma, pago o intención. Forecast usa reglas transparentes del CRM y no es un modelo predictivo entrenado. La empresa debe configurar usuarios, fuentes, permisos, destinatarios y políticas según sus propias obligaciones.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿Qué información se considera sensible en un AI Sales Copilot?
Incluye PII, datos financieros, legales y de salud, credenciales, secretos técnicos, contratos, precios negociados, márgenes, notas de clientes, transcripciones, documentos y estrategia comercial. La sensibilidad depende también de la combinación, finalidad, tenant y destino: un dato interno permitido puede convertirse en una divulgación al incluirlo en un correo externo.
¿Basta con pedir al modelo que no revele datos confidenciales?
No. La instrucción puede reducir algunos errores, pero puede ignorarse, interpretarse mal o ser alterada por prompt injection. Autoriza y minimiza antes de retrieval, excluye secretos, aísla tenants y valida la salida de forma determinista. El modelo no debe recibir datos que la tarea o el destinatario no están autorizados a conocer.
¿Cómo se evita que RAG mezcle información de dos clientes?
Deriva el tenant de la sesión autenticada, aplica filtros obligatorios antes de recuperar fragmentos, separa namespaces o índices según el riesgo, incluye autorización en cachés y tool calls, y prueba búsquedas cruzadas con datos canario. No aceptes el tenant desde el prompt ni recuperes globalmente para filtrar después con el modelo.
¿La opción no training de un proveedor elimina el riesgo?
No por sí sola. Todavía debes verificar retención, logs, revisión de abuso, soporte, región, subprocesadores, borrado, telemetría y configuración efectiva del plan. «No se usa para entrenamiento» responde una finalidad concreta; no demuestra que el proveedor no conserve o procese datos para otras finalidades permitidas.
¿Qué hacer si una respuesta contiene una API key o datos de otro cliente?
Detén la ruta afectada, revoca la credencial, restringe sesiones y enlaces, preserva evidencia con acceso limitado y localiza copias en logs, caches, exports, herramientas y proveedores. Determina alcance y obligaciones de notificación, corrige la causa de autorización o manejo de datos, prueba la remediación y monitoriza recurrencia.