PII / Compliance Redaction.
Detección y enmascaramiento de datos sensibles en tiempo real, con políticas diferenciadas por regulación y audit trail completo.
Un agente Agentforce que analiza cada contenido entrante (transcripciones de voz, chats, emails, archivos), detecta PII con regex + ML, aplica políticas de redacción diferenciadas por país y regulación, y mantiene un log de auditoría completo para inspecciones regulatorias. Para banca, salud, sector público, telco y cualquier industria regulada. Implementado por Solu en 14 a 18 semanas.
¿Qué hace el PII / Compliance Redaction Agent?
Reemplaza la gestión manual (o inexistente) de datos sensibles en transcripciones, logs y bases de conocimiento por un sistema automatizado que detecta, clasifica y enmascara PII en tiempo real. Si un cliente dicta su DNI en una llamada, el agente lo detecta antes de que quede expuesto en el CRM.
El problema: PII expuesta en transcripciones, logs de chat, artículos de KB. Multas regulatorias por LGPD, Ley 25326, LFPDPPP y normativas sectoriales. Equipos de compliance que revisan manualmente o, peor, no revisan.
Para: DPOs, equipos de compliance, CISOs, líderes de Service en banca, salud, sector público y telco.
Cómo funciona
6 pasos, desde el contenido entrante hasta el registro de auditoría.
Contenido entrante
El agente intercepta cada pieza de contenido que ingresa al CRM: transcripciones de voz en tiempo real, mensajes de chat y messaging, emails procesados por Email-to-Case, y archivos adjuntos vía OCR. Cada contenido se procesa antes de persistir en Salesforce.
Detección de PII (regex + ML con Presidio)
Dos capas de detección: primero regex para patrones conocidos (números de documento, tarjetas de crédito, CUIT/CUIL, CPF, RFC), luego ML vía Microsoft Presidio self-hosted para detección contextual de nombres, direcciones, datos de salud y otros PII no estructurados.
Desambiguación contextual
No todo número de 8 dígitos es un DNI. El agente analiza el contexto de la conversación para distinguir datos sensibles de datos operativos. "Mi DNI es 30456789" se detecta. "El pedido 30456789 está listo" no se enmascara. Esto reduce falsos positivos a menos del 3%.
Evaluación de política por regulación y rol
El agente cruza el país del cliente (Country_of_Residence), la regulación aplicable y el rol del usuario que accede. La misma PII puede tener tratamiento diferente según la regulación: enmascaramiento parcial, pseudonimización, bloqueo total o acceso con justificación.
Acción: mask / allow / block / pseudonymize
Según la política evaluada, el agente aplica la acción correspondiente: masking parcial (********1234), pseudonimización (reemplazo por token reversible), bloqueo completo (dato eliminado del campo visible) o allow con log (dato visible pero registrado en auditoría).
Audit log en Data Cloud
Cada decisión queda registrada en un DMO de Redaction_Audit: qué PII se detectó, qué política se aplicó, qué acción se tomó, quién accedió, cuándo, y con qué justificación. Este log es la base para responder a inspecciones regulatorias.
Ejemplo real de interacción
Cliente dicta su DNI durante una llamada de soporte. La transcripción en tiempo real captura: "Mi DNI es 30456789".
Detecta PII tipo documento nacional. Aplica política Argentina/Ley 25326: masking parcial. La transcripción muestra "Mi DNI es ********6789". El agente de servicio ve el dato enmascarado. Si necesita validar identidad, hace request explícito que queda logueado con justificación.
PII protegida en la transcripción. Acceso controlado con justificación. Audit trail completo disponible para el DPO. Si un regulador pide evidencia de protección de datos, el log muestra exactamente qué se detectó, cuándo y cómo se protegió.
Arquitectura técnica
Los 4 pilares del agente: datos, acciones, guardrails y canal de entrega.
Data
- Customer: Country_of_Residence, idioma, segmento regulatorio
- Consent_Record: consentimientos vigentes por tipo de dato y propósito
- Policy_Registry (Data Cloud): catálogo de políticas por regulación, país y tipo de PII
- Redaction_Audit (DMO): log de cada detección, acción y acceso con timestamp y justificación
Actions
- redactTranscript: detecta y enmascara PII en transcripciones de voz en tiempo real
- redactCaseEmail: procesa emails entrantes de Email-to-Case antes de persistir
- evaluatePolicy: evalúa la política aplicable según país, regulación y rol
- unredactForAuthorized: permite acceso controlado con justificación y log
- bulkClassifyDocuments: clasificación masiva de documentos y archivos adjuntos vía OCR
Guardrails
- Doble capa: Einstein Trust Layer + guardrails custom del agente
- Prompt defense anti-exfiltración: impide que un prompt malicioso extraiga PII a través del LLM
- Zero retention LLM: ningún dato sensible se retiene en el modelo
- Validación de justificación: accesos a datos desenmascarados requieren justificación válida
- Alertas de anomalía: patrones inusuales de acceso disparan alerta al DPO
Channel
- Voice transcripts: detección en tiempo real durante llamadas activas
- Chat / Messaging: procesamiento inline antes de persistir en el caso
- Email-to-Case: escaneo del cuerpo y adjuntos del email antes de crear el caso
- Files OCR: extracción y análisis de texto en imágenes y documentos adjuntos
Cómo se implementa
5 fases, 14-18 semanas. Equipo Solu + tu equipo de compliance, seguridad y datos.
Discovery regulatorio y mapeo de datos
Identificación de todas las regulaciones aplicables por país y sector. Mapeo de fuentes de PII en el CRM (transcripciones, emails, KB, archivos). Definición de la taxonomía de datos sensibles. Identificación del DPO y stakeholders de compliance.
Infraestructura y Presidio
Deployment de Microsoft Presidio self-hosted. Configuración de Shield Platform Encryption. Setup de Data Cloud para Policy Registry y Redaction Audit DMO. Entrenamiento de modelos ML para PII específica del sector (e.g., números de historia clínica, códigos de póliza).
Build del agente y políticas
Configuración del agente en Agent Builder: topics, actions, prompts, guardrails. Implementación de las 5 actions principales. Carga del Policy Registry con reglas por regulación, país y tipo de PII. Testing con datos sintéticos y transcripciones históricas anonimizadas.
Piloto controlado
Activación con un canal (e.g., chat) y un país. Medición de recall (PII detectada vs PII real), precisión (falsos positivos) y latencia. Ajuste de modelos y políticas. Validación con el DPO de que el audit trail cumple los requisitos regulatorios.
Rollout multicanal y optimización
Expansión a todos los canales (voz, email, messaging, files). Activación de países adicionales con sus políticas regulatorias. Tuning continuo de modelos ML con datos del piloto. Capacitación del equipo de compliance en el dashboard de auditoría.
Requisitos previos
Lo que necesitas tener (o que Solu te ayuda a configurar) antes de arrancar.
Service Cloud Enterprise+
Con Case Management activo y al menos un canal digital configurado (chat, email o messaging).
Shield Platform Encryption
Encriptación a nivel de plataforma para proteger datos en reposo. Base obligatoria para cualquier esquema de protección de PII en Salesforce.
Einstein Trust Layer
Capa de seguridad de Salesforce que garantiza PII masking, zero data retention y audit de cada interacción con el LLM.
DPO identificado
Un Data Protection Officer (o equivalente) que defina las políticas, valide el audit trail y sea punto de contacto para inspecciones regulatorias.
Data Cloud
Para centralizar el Policy Registry y el Redaction Audit en DMOs con capacidad de consulta cruzada y reportes de compliance.
Microsoft Presidio (self-hosted)
Motor de detección de PII basado en ML. Se despliega en la infraestructura del cliente para garantizar que los datos no salen del perímetro.
Mapping regulatorio por país
Documento que identifique las regulaciones aplicables por país donde opera la empresa: LGPD, Ley 25326, LFPDPPP, HIPAA, PCI-DSS, etc. Solu ayuda a construirlo si no existe.
KPIs Before / After
KPIs esperados al implementar este agente. Rangos referenciales para planificación; los resultados reales dependen del estado de los datos y la operación de cada empresa.
Riesgos y mitigaciones
Lo que puede salir mal y cómo lo prevenimos. Sin sorpresas.
Falsos negativos (PII no detectada)
El agente no detecta un dato sensible y este queda expuesto en el CRM. El peor escenario en compliance.
Mitigación: Doble capa de detección (regex + ML). Entrenamiento con datos específicos del sector. Recall objetivo >98%. Revisión periódica de muestras aleatorias por el equipo de compliance. Alertas automáticas cuando el confidence score de detección es bajo.
Falsos positivos (over-redaction)
El agente enmascara datos que no son sensibles, dificultando el trabajo de los agentes de servicio.
Mitigación: Desambiguación contextual que analiza el contexto de la conversación. Precisión objetivo menor al 3% de falsos positivos. Mecanismo de feedback para que los agentes reporten over-redaction. Tuning continuo con datos del piloto.
Latencia en voice stream
La detección en tiempo real agrega latencia a la transcripción de llamadas, afectando la experiencia del agente.
Mitigación: Procesamiento asíncrono con buffer de 2-3 segundos. Presidio self-hosted cerca del data center del cliente para minimizar latencia. Fallback a regex-only si la latencia supera el umbral. Medición continua de p95 de latencia.
Fuga al LLM provider
PII podría enviarse al LLM como parte del prompt si el pipeline de detección falla antes del Trust Layer.
Mitigación: Einstein Trust Layer como segunda barrera (PII masking antes del LLM). Zero data retention contractual con el provider. Prompt defense anti-exfiltración para prevenir ataques de inyección. Monitoreo de payloads enviados al LLM.
Insider threat y políticas desactualizadas
Un usuario con acceso privilegiado extrae PII masivamente, o las políticas no reflejan cambios regulatorios recientes.
Mitigación: Alertas de anomalía por volumen de acceso a datos desenmascarados. Revisión trimestral del Policy Registry. Versionado de políticas con audit trail de cambios. Integración con el calendario regulatorio del DPO.
Preguntas Frecuentes
Detecta documentos nacionales (DNI, CPF, CUIT, CUIL, RFC, RUT), números de tarjetas de crédito/débito (PAN), datos de salud, direcciones físicas, números de teléfono, emails personales, nombres completos en contexto sensible, y datos financieros. Los modelos ML se entrenan con datos específicos del sector para detectar PII no estructurada que los patrones regex no cubren.
Sí. El agente procesa el stream de transcripción con un buffer de 2-3 segundos. La PII se enmascara antes de que la transcripción se persista en Salesforce. El agente de servicio ve la transcripción ya protegida. La latencia típica es menor a 3 segundos después del tuning.
El agente puede solicitar acceso al dato original mediante un request explícito que queda logueado. Necesita seleccionar una justificación válida (validación de identidad, requerimiento legal, etc.), su rol debe tener permiso de unredact, y el acceso queda registrado en el audit trail con timestamp, usuario y justificación. El DPO puede revisar estos accesos en cualquier momento.
El Policy Registry permite definir reglas por país, regulación y tipo de PII. Si un cliente tiene residencia en Brasil (LGPD) pero la empresa también está sujeta a PCI-DSS, el agente aplica la política más restrictiva. Las políticas se pueden configurar con lógica de prioridad y override por sector.
No es obligatorio pero sí recomendado para detección contextual de PII no estructurada. Sin Presidio, el agente funciona con regex y las capacidades de detección del Einstein Trust Layer, lo que cubre bien los patrones conocidos (números de documento, tarjetas) pero es menos preciso con datos como direcciones, nombres en contexto o datos de salud en texto libre.
La action bulkClassifyDocuments permite escanear contenido histórico (casos cerrados, transcripciones, artículos de KB) e identificar PII expuesta. Se genera un reporte de hallazgos para que el equipo de compliance decida la acción: enmascarar retroactivamente, eliminar o mantener con justificación documentada.
14-18 semanas desde kick-off hasta el primer canal en producción. La complejidad depende del número de regulaciones aplicables, los canales a cubrir y si ya existe infraestructura de compliance. El piloto con un canal y un país es la forma más rápida de validar valor antes del rollout completo.
El Policy Registry tiene versionado y audit trail de cambios. Se recomienda una revisión trimestral alineada con el calendario regulatorio del DPO. Los cambios de política se propagan automáticamente a todas las detecciones nuevas. Para cambios retroactivos, se ejecuta un batch de reclasificación sobre el contenido existente.
Tu PII protegida, con audit trail, en 14 semanas.
Habla con un Compliance Architect de Solu. En una sesión de discovery mapeamos tus regulaciones y definimos la estrategia de protección de datos para tu operación.