Qué datos no deben ir a la IA sin una comprobación
Lo que haría si un empleado enviara un contrato a la IA y dijera: “Es solo texto”. Primero mapearía la ruta de los datos: dónde apareció el documento, quién verá el historial de ejecuciones, qué va a la nube y cuándo se borra todo.
El error que eliminaría primero: “Simplemente no enviamos el pasaporte completo” no es un control si el texto sigue teniendo email, número de contrato, dirección y una combinación rara de atributos que identifica a una persona con facilidad.
Qué preparar y qué resultado esperar
- Resultado: Tienes un conjunto mínimo de datos, permisos separados y una ruta clara ante entradas o acciones peligrosas.
- Crea un registro de escenarios de IA con campos para datos, proveedor, finalidad, retención, acceso, owner y riesgo.
- Guarda los datos de origen y los derechos de acceso aparte del resultado para poder verificar qué hizo la protección de datos en el proceso de IA.
- Prueba prompt injection, una instrucción maliciosa en un adjunto, un record_id ajeno y una respuesta vacía de la herramienta.
Haz imposible una acción peligrosa sin aprobación
- Construye un mapa de datos
Para cada paso de IA lista campos, fuente, finalidad, retención, región y el rol que puede verlos. No escribas “todos los datos del cliente”.
Проверьте: Cada campo tiene un motivo y se pueden quitar los sobrantes.
Если не сработало: Empieza con datos de prueba o desidentificados.
- Limita las credenciales
En Credentials/Permissions concede read en lugar de write, una carpeta en lugar de todo el drive, un proyecto en lugar de todo el CRM. Usa una clave distinta para cada workflow.
Проверьте: Revocar una clave no abre acceso al resto del sistema.
Если не сработало: Verifica los permisos en una cuenta sandbox.
- Filtra la entrada antes de la IA
Antes del modelo, elimina contraseñas, tokens, números de tarjeta completos y datos personales innecesarios. Coloca Human approval antes de send, refund, delete y update permissions.
Проверьте: El log no tiene secretos ni campos sensibles que la tarea no necesite.
Если не сработало: Sustituye el valor por una máscara o un id interno.
- Monta casos de ataque y de fallo
Prueba instrucciones en un adjunto, suplantación de record_id, un intento de leer la carpeta de otro, exceso de límites y una respuesta vacía. Cada comprobación debe acabar en stop, retry o handoff.
Проверьте: Un escenario peligroso nunca llega a una acción real.
Если не сработало: Revoca derechos de escritura hasta arreglar la causa raíz.
Un registro de datos antes de la primera solicitud
Crea una tabla con data_type, source, purpose, legal_basis, allowed_destination, retention_days, access_role y deletion_owner. Marca aparte pasaportes, datos bancarios, contratos, correspondencia y precios internos.
Minimizar no es solo enmascarar un nombre. Antes de la IA, elimina campos que la tarea no necesite, sustituye el resto por CLIENT_001 y mantén la tabla de mapeo aparte. La respuesta no debe permitir reconstruir los valores originales a través del prompt.
- No des a un workflow acceso a toda una carpeta por un solo documento.
- Revisa el contrato del proveedor, la región de almacenamiento, el entrenamiento con tus datos y el borrado.
Cómo verificar que el enmascaramiento funciona
Crea un documento de prueba con marcadores deliberados PASSPORT_TEST_001, CARD_TEST_002 y EMAIL_TEST_003. Inspecciona el payload antes del envío, el payload del proveedor y los logs. Si un marcador pasa más allá del paso local, el enmascaramiento está en el sitio equivocado o solo se aplica al texto visible.
Un registro de datos antes de la primera integración
Crea `data_type`, `source`, `purpose`, `legal_basis`, `allowed_destination`, `retention_days`, `access_role` y `deletion_owner`. Marca aparte pasaporte, contrato, datos bancarios, correspondencia y precios internos. La IA solo recibe los campos necesarios para la tarea concreta.
Guarda las API keys en `Credentials`, no en `Set`, `Code` ni en una URL. En n8n self-hosted configura una clave de cifrado aparte y limita el guardado de execution data a lo necesario para revisar incidentes.
N8N_ENCRYPTION_KEY=<long_secret_key>
EXECUTIONS_DATA_SAVE_ON_SUCCESS=none
EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=168Comprobaciones de enmascaramiento con marcadores de prueba
Crea un documento de prueba con `PASSPORT_TEST_001`, `CARD_TEST_002` y `EMAIL_TEST_003`. Revisa el payload antes del modelo, el payload del proveedor y los logs de error. Si un marcador pasa más allá del paso local, el enmascaramiento se aplica demasiado tarde.
El mismo valor de origen debe recibir el mismo token dentro de una ejecución, y la tabla de mapeo debe vivir aparte, cifrada y con TTL. No envíes datos en bruto a Slack o al email por la rama de error.
Qué dejar al modelo y qué quitar antes
| Criterio | Pregunta | Buena señal |
|---|---|---|
| Entrada | ¿Qué entra exactamente en la protección de datos del proceso de IA? | Crea un registro de escenarios de IA con campos para datos, proveedor, finalidad, retención, acceso, owner y riesgo. |
| Acción | ¿Qué puede hacer el sistema por su cuenta? | Solo acciones prelistadas, sin acceso a toda la cuenta |
| Verificación | ¿Cómo sabes que el resultado es aceptable? | Prueba prompt injection, una instrucción maliciosa en un adjunto, un record_id ajeno y una respuesta vacía de la herramienta. |
| Fallo | ¿Adónde van los casos poco claros? | Detén el workflow, revoca el acceso a la herramienta, guarda un log técnico sin secretos y revisa las últimas acciones. |
Qué debe cambiar después de la configuración
Tienes un conjunto mínimo de datos, permisos separados y una ruta clara ante entradas o acciones peligrosas.
Dónde se rompe la seguridad: en el acceso, no en el modelo
Tratar el system prompt como protección frente a entradas dañinas.
Registrar datos personales y secretos al completo.
Usar una sola clave de admin para todas las integraciones.
No tener un owner que revoque el acceso durante un incidente.
Cuándo hace falta una revisión de seguridad aparte
Necesitas un especialista cuando se procesan datos médicos, financieros o personales, intervienen varios proveedores o hay requisitos de un regulador.
Qué revisar antes de conectar datos reales
¿Se pueden enviar emails de clientes a la IA?
Solo después de revisar el contrato, la política de retención, la región y la necesidad de cada campo. Para pruebas, prefiere texto desidentificado.
¿Basta con no mostrar un secreto en la respuesta?
No. Un secreto no debe entrar en la entrada, el contexto, los logs ni en herramientas que no lo necesiten.
¿Y si la respuesta del agente parece sospechosa?
Detén el workflow, revoca el acceso, guarda un log técnico sin PII y revisa las últimas acciones.
¿Cuál es el primer control que hay que poner?
Least privilege y confirmación obligatoria antes de cualquier acción difícil de deshacer.
