Respuesta directa
En pocas palabras
Para proteger datos personales en un CRM con IA, mapea input, contexto RAG, memoria, embeddings, herramientas, output y telemetría; aplica finalidad, necesidad y permisos antes de construir el prompt; filtra cada recuperación con la identidad efectiva; trata documentos recuperados como contenido no confiable; separa memorias por organización y propósito; limita proveedores, entrenamiento y retención; valida salidas y llamadas a herramientas; y prueba derechos y eliminación en cada copia. Un system prompt no sustituye autorización. Un embedding tampoco es anónimo por defecto y debe permanecer dentro del inventario y ciclo de vida aplicables.
Diseña una frontera de datos, no solo un buen prompt
Una asistencia de IA puede recibir texto escrito por la persona usuaria, campos del CRM, documentos recuperados, memoria de conversaciones, resultados de herramientas, instrucciones del sistema y metadatos del proveedor. Después puede crear una salida, llamar una función, guardar feedback y generar logs. La protección debe seguir ese recorrido completo; revisar únicamente la caja de texto deja fuera la mayor parte del tratamiento.
Escribe primero qué decisión apoya el sistema, qué personas y datos necesita, quién puede verla, qué fuentes puede consultar, qué acción puede proponer y qué nunca ejecuta. Relaciona cada propósito con una población, permiso, plazo y evidencia. El objetivo no es impedir todo uso de datos personales, sino evitar que una función legítima amplíe audiencia, finalidad, memoria o destino sin una decisión autorizada.
Separa principios mexicanos de patrones técnicos voluntarios
La LFPDPPP vigente exige observar licitud, finalidad, lealtad, consentimiento, calidad, proporcionalidad, información y responsabilidad. También exige medidas administrativas, técnicas y físicas para proteger datos personales. Su Reglamento desarrolla proporcionalidad, responsabilidad, seguridad, inventario, análisis de riesgo, revisión de controles y trazabilidad. Esos deberes aplican al tratamiento real; la ley no prescribe una arquitectura RAG, un formato de vector ni una lista universal de filtros.
NIST AI 600-1 es un perfil voluntario para riesgos de IA generativa y menciona fuentes de grounding y retrieval-augmented generation dentro del contexto de uso. OWASP GenAI describe prompt injection y divulgación de información sensible como riesgos técnicos. Usa estas referencias para diseñar y probar, no para afirmar certificación o reemplazar el análisis de finalidad, consentimiento, contrato, sector y relación con la persona.
| Criterio | Pregunta | Evidencia esperada |
|---|---|---|
| Finalidad y necesidad | ¿Por qué se trata este dato? | Actividad, aviso, criterio y minimización |
| Autorización técnica | ¿Esta identidad puede recuperarlo ahora? | Permiso, filtro, tenant, política y prueba negativa |
| Comportamiento del modelo | ¿Cómo debe responder ante el contexto? | Instrucción versionada, evaluación y fallback |
Mapea cada artefacto y transformación de la cadena
Distingue instrucción de sistema, prompt del usuario, plantilla, variables, historial, documento, fragmento, metadato, embedding, índice, caché, memoria, llamada a herramienta, respuesta, borrador, evaluación, feedback y telemetría. Para cada artefacto registra origen, personas, categorías, finalidad, sistema, proveedor, región, acceso, transformación, plazo, eliminación y método para localizarlo. Un nombre genérico como datos de IA oculta copias con riesgos muy distintos.
Conecta artefactos mediante identificadores y referencias, no copiando el contenido completo en cada inventario o log. Marca qué se envía al proveedor y qué permanece local. Documenta truncamiento, resumen, redacción, tokenización y chunking: transformar el formato no elimina automáticamente el carácter personal. Reabre el mapa cuando cambien fuente, modelo, memoria, herramienta, región, proveedor o uso secundario.
Minimiza antes de construir el prompt
Selecciona campos por tarea y evita enviar el objeto completo del CRM por comodidad. Para resumir una oportunidad quizá basten etapa, último acuerdo, próximos pasos y referencias comerciales; no necesitas credenciales, notas privadas, datos financieros no relacionados ni todas las conversaciones. Aplica listas permitidas, límites de longitud, clasificación, redacción y sustitución por identificadores antes de llamar al modelo.
Advierte a la persona usuaria qué no debe pegar y bloquea patrones de alto riesgo cuando sea viable, pero no descargues toda la responsabilidad en capacitación. Trata archivos, imágenes, HTML y texto libre como entradas activas. Separa datos operativos de secretos. Si el sistema necesita un valor para ejecutar una herramienta, entrégalo directamente a la función autorizada en lugar de insertarlo en lenguaje natural dentro del prompt.
Filtra RAG en el momento de la consulta
El índice no debe decidir acceso por similitud. Antes de recuperar, resuelve identidad, organización, rol, relación con la cuenta, finalidad, sensibilidad y restricciones vigentes. Aplica esos filtros en el almacén o capa de recuperación, no después de mostrar fragmentos al modelo. Un documento cercano semánticamente puede pertenecer a otro workspace, caso, equipo o finalidad.
Propaga metadatos de procedencia, versión, dueño, vigencia, clasificación y permiso a cada fragmento. Limita top-k, longitud y categorías; evita mezclar fuentes autorizadas y abiertas sin señal visible. Registra referencias recuperadas y descartadas sin duplicar el contenido. Prueba ausencia de resultados, permisos revocados, documento sustituido, cuenta reasignada, homónimos y consultas diseñadas para saltar filtros.
Trata el contexto recuperado como contenido no confiable
Un documento, página, correo o nota puede contener instrucciones directas o indirectas para ignorar reglas, revelar contexto o invocar herramientas. Delimita datos e instrucciones con estructura, marca procedencia, reduce privilegios y no permitas que el contenido recuperado cambie políticas, identidad o destinos. La instrucción del sistema ayuda, pero OWASP advierte que prompt injection puede alterar el comportamiento y provocar divulgación o acciones no autorizadas.
Analiza entradas y salidas, bloquea URLs o esquemas peligrosos, controla renderizado y exige confirmación para acciones materiales. Prueba instrucciones ocultas en texto, HTML, metadatos, PDFs e imágenes si el sistema es multimodal. Diseña contención: sin herramienta, con respuesta parcial o con revisión humana. No presentes un detector como garantía; combina aislamiento, privilegio mínimo, allowlists, observación y pruebas recurrentes.
Separa contexto de sesión, memoria operativa y perfil duradero
Define qué olvida al terminar una solicitud, qué permanece durante una sesión, qué se convierte en hecho estructurado del CRM y qué podría formar un perfil persistente. No guardes automáticamente cada conversación como memoria. Un resumen puede perder negaciones, mezclar personas o convertir una inferencia en hecho. Exige procedencia, fecha, confianza, dueño y posibilidad de corrección para cualquier elemento duradero.
Aísla memoria por organización, usuario, cuenta, finalidad y entorno. Aplica permisos al escribir y al leer; una persona que perdió acceso no debe seguir recibiendo memoria histórica. Establece caducidad, revisión, conflictos, sobrescritura y eliminación. Mantén preferencias y restricciones como controles estructurados fuera de la memoria del modelo para que una frase ambigua no reabra un uso bloqueado.
Mantén embeddings e índices dentro del ciclo de vida
Un embedding representa características matemáticas, pero puede seguir vinculado con una persona mediante el documento, identificador, metadatos, vecinos o consultas. No lo declares anónimo por cambiar de formato. Registra modelo de embedding, versión, fuente, chunking, namespace, metadatos, región, proveedor, controles de acceso, uso permitido y dependencia para reconstrucción o supresión.
Separa namespaces por tenant y propósito, cifra y limita acceso administrativo, y evita que datos de producción entren en índices de prueba. Cuando cambia un documento, define si actualizas, invalidas o reconstruyes sus vectores y cachés. Para eliminar, localiza chunks, embeddings, metadatos, índices derivados, réplicas y respaldos. Prueba que el contenido no reaparezca por una restauración, reindexación o fuente que quedó activa.
Autoriza cada herramienta fuera del modelo
El modelo puede proponer buscar, exportar, enviar, actualizar o borrar, pero una capa determinista debe verificar identidad, organización, permiso, objeto, finalidad, parámetros, destino y estado vigente. Usa esquemas estrictos, allowlists y límites de volumen. Rechaza campos adicionales y rutas no esperadas. Nunca pongas llaves, tokens o cadenas de conexión en system prompts o contexto recuperable.
Separa lectura de escritura y acciones reversibles de irreversibles. Exige vista previa o aprobación humana para comunicaciones y cambios materiales. Registra solicitud, autorización, llamada, resultado y reversión. Limita salida de red y renderizado de enlaces o imágenes: una respuesta aparentemente visual puede convertirse en canal de exfiltración si permite solicitudes externas con datos en la URL.
Valida la salida antes de mostrarla, guardarla o ejecutarla
Compara la salida con audiencia, permisos, finalidad y fuentes. Detecta datos sensibles, secretos, identificadores de otra cuenta, instrucciones ocultas y contenido que no puede sustentarse. Usa formatos estructurados cuando el resultado alimenta una función. Escapa HTML, Markdown y fórmulas según el destino. Una respuesta del modelo es contenido no confiable hasta que la aplicación la valida para ese canal.
Distingue borrador, recomendación, dato extraído y decisión humana. No guardes una inferencia como hecho del CRM sin procedencia y revisión. Para comunicaciones, muestra fuentes, incertidumbre y destinatario antes de enviar. Si el filtro bloquea, ofrece una ruta segura y registra el motivo sin copiar el dato completo. Evalúa también sobrebloqueo: ocultar información autorizada puede dañar derechos y operación.
Configura proveedor, región, entrenamiento y conservación
Documenta qué recibe cada proveedor, bajo qué función, en qué región, con qué subencargados, cifrado, soporte, telemetría, retención, eliminación, entrenamiento y uso para mejorar servicios. Contrasta contrato, configuración y comportamiento observado. Una opción de no entrenar no significa automáticamente cero logs, cero abuso monitoring o eliminación inmediata; registra cada capa y su plazo.
Usa cuentas empresariales y proyectos separados, restringe llaves, rota secretos y aplica límites. Evalúa cambios de modelo, endpoint, región, términos y subencargados. Define salida: exportación, migración, eliminación y evidencia. Para datos de mayor riesgo considera redacción, procesamiento local o un flujo sin modelo externo. La selección del proveedor no sustituye la decisión del responsable sobre finalidad y proporcionalidad.
Controla logs, evaluaciones, feedback y datos de prueba
La observabilidad puede volver a copiar prompts, documentos, salidas, errores y cabeceras. Define un esquema mínimo con identificadores, versiones, categorías, resultado y métricas; excluye secretos y cargas completas por defecto. Separa logs operativos, investigaciones restringidas y datasets de evaluación. Limita quién puede buscar, exportar o etiquetar y registra esas acciones.
Construye evaluaciones con casos sintéticos o redactados siempre que permitan probar el riesgo. Si necesitas muestras reales, define población, justificación, acceso, plazo, revisión y eliminación. No conviertas feedback en entrenamiento sin una decisión separada. Versiona conjuntos, etiquetas y transformaciones, y prueba fugas entre train, test, demo y producción. La telemetría también debe responder al inventario y retención.
Ejecuta derechos, retención y eliminación en todas las capas
Define cómo localizar datos dentro de prompts conservados, memoria, historial, documentos, fragmentos, embeddings, cachés, salidas, feedback, evaluaciones, logs y proveedores. Relaciona cada copia con la persona sin crear un índice paralelo excesivo. Distingue acceso, rectificación, cancelación, oposición, restricción operativa y preservación justificada según el caso aplicable.
Al corregir, decide si se actualiza el hecho fuente, la memoria, el índice y los derivados. Al eliminar, detén reingesta, invalida cachés, borra vectores y coordina proveedores y respaldos. Después prueba no reaparición mediante búsqueda, recuperación y una restauración controlada. Conserva evidencia mínima del cumplimiento sin guardar otra vez el contenido eliminado.
Prueba las fronteras y mantén claros los límites de Cerravi
Crea una matriz por capa con caso autorizado, otro tenant, permiso revocado, dato sensible, prompt directo, instrucción indirecta, memoria cruzada, vector obsoleto, herramienta no permitida, URL externa, proveedor caído y eliminación pendiente. Verifica resultado, logs mínimos, bloqueo, fallback y revisión. Repite cuando cambien modelo, prompt, retrieval, embedding, memoria, herramienta, proveedor, permiso o política.
Cerravi organiza información comercial y ofrece asistencia de Copilot para revisión humana; no envía mensajes ni cambia etapas automáticamente desde los recorridos públicos. Puede aportar contexto y controles dentro de su alcance, pero no descubre todas las copias de una empresa, no define su base jurídica ni garantiza la configuración de terceros. Esta guía es un método operativo basado en fuentes públicas, no asesoría legal, auditoría o certificación.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿Un system prompt puede proteger datos personales por sí solo?
No. Puede orientar el comportamiento, pero no sustituye identidad, autorización, filtros de recuperación, aislamiento por organización, validación de herramientas, control de salida ni pruebas. Además puede ser extraído o ignorado mediante prompt injection. La seguridad material debe operar fuera del modelo.
¿Los embeddings de datos personales son anónimos?
No por defecto. Pueden seguir vinculados con documentos, personas, metadatos, vecinos o consultas. Deben inventariarse con fuente, propósito, modelo, namespace, acceso, proveedor, región, plazo y eliminación. La organización necesita evaluar si existe una anonimización real, no asumirla por el cambio de formato.
¿Cómo se evita que RAG muestre datos de otra empresa?
Resuelve identidad, tenant, rol, relación con el objeto, finalidad y restricciones antes de la búsqueda; aplica esos filtros en el almacén o retrieval; separa namespaces; propaga metadatos; y prueba consultas cruzadas, permisos revocados, reasignaciones y documentos sustituidos. Filtrar la respuesta después de recuperar es demasiado tarde.
¿Conviene guardar prompts y respuestas completos en logs?
No por defecto. Prefiere identificadores, versiones, categorías, métricas, referencias y resultados. Si un propósito legítimo exige contenido real para soporte, evaluación o investigación, define población, minimización, enmascaramiento, acceso, plazo y eliminación. Nunca registres contraseñas, tokens o secretos.
¿Cómo se elimina un dato personal usado por una función de IA?
Detén la reingesta y localiza fuente, prompts conservados, memoria, fragmentos, embeddings, índices, cachés, salidas, feedback, evaluaciones, logs y copias del proveedor. Elimina o restringe según corresponda, coordina respaldos y después prueba búsquedas, recuperación y una restauración controlada para verificar que no reaparezca.