La seguridad no se resuelve eligiendo un “modelo empresarial”. Hay que controlar el flujo completo: qué dato entra, para qué finalidad, qué proveedor lo procesa, quién puede recuperarlo, qué queda registrado, cuánto se conserva y qué acciones permite el sistema. Una buena arquitectura reduce datos y privilegios antes de pedir confianza al modelo.
El mismo modelo puede ser razonable para resumir documentación pública e inaceptable para otro caso si cambia el dato, la identidad o la consecuencia. Por eso diseñamos seguridad por capas: fuente, contexto, modelo, herramientas, logs y operación.
Antes de hablar de proveedor, documenta qué categorías de información entran en el caso, para qué se necesitan y cuál es el mínimo contexto útil. Separa información pública, interna, confidencial, datos personales y cualquier dato especialmente sensible para tu entorno.
La AEPD ha insistido en 2026 en exactitud, finalidad y minimización: más datos no equivalen automáticamente a mejor IA.
AEPD · calidad, exactitud y minimización.
Si un asistente sólo necesita una política general, no debería recibir expedientes. Si un copiloto prepara un seguimiento, quizá necesite nombre y oportunidad pero no toda la ficha. El diseño más seguro es que el dato innecesario nunca llegue a esa etapa.
Reducir contexto también baja coste y hace más fácil investigar qué vio el sistema cuando algo sale mal.
Revisa el servicio que realmente se contratará: tratamiento de datos, retención, ubicación, subencargados, controles administrativos, opciones de registro y compromisos contractuales. No extrapoles condiciones de un producto de consumo a una API o plan empresarial.
La respuesta puede ser cloud, local o híbrida; ninguna etiqueta elimina la necesidad de diseñar el flujo.
Un RAG interno no debería recuperar documentos que el usuario no podía leer en el repositorio original. La autorización se aplica antes de enviar contexto al modelo. En CRM o ERP, la herramienta debe respetar privilegio mínimo y limitar entidades/campos.
Ocultar una cita después de recuperar un documento prohibido no corrige la exposición.
Correo, web y documentos pueden contener texto malicioso o accidental que intente cambiar el comportamiento del modelo. OWASP recomienda separar contenido no confiable, aplicar privilegio mínimo y exigir aprobación para operaciones de mayor riesgo.
La mitigación importante está fuera del prompt: tools estrechas, validación en código y permisos que el contenido no pueda ampliar.
OWASP GenAI · Prompt Injection.
| Capacidad | Ejemplo | Control razonable |
|---|---|---|
| Leer | Consultar pedido o documento autorizado. | Identidad y ACL. |
| Proponer | Preparar una nota o clasificación. | Validación de formato y evidencia. |
| Escribir | Actualizar CRM. | Reglas de negocio, idempotencia, auditoría. |
| Acción sensible | Enviar, cancelar, modificar dinero. | Aprobación o política reforzada según riesgo. |
Necesitas trazabilidad: usuario, fuente, versión, herramienta, resultado y estado final. Pero prompts, respuestas y trazas pueden copiar información sensible. Define permisos, minimización y retención para observabilidad igual que para el producto.
Un error común es proteger muy bien el endpoint del modelo y después volcar todo el contenido en una herramienta de logs con acceso amplio.
Define cuánto tiempo necesita cada dato en conversaciones, índices, cachés, logs y copias de soporte. “Lo guardamos por si acaso” crea otra base de datos difícil de gobernar.
Verifica capacidades del proveedor y diseña tu propia política de ciclo de vida. El hecho de que una plataforma permita conservar algo no significa que el proceso lo necesite.
Este mapa evita reducir toda seguridad a “¿entrenan con mis datos?”.
Un piloto puede usar sólo fuentes no sensibles, un grupo reducido, lectura sin escritura o aprobación obligatoria. Si demuestra valor, amplía datos y acciones de forma explícita y vuelve a revisar riesgo.
Para sistemas conectados a negocio, la capa técnica de integración está en integraciones de IA; para conocimiento, RAG corporativo.
Respuestas directas para convertir la pregunta en una decisión de proyecto.
No debería asumirse. Hay que revisar clasificación del dato, servicio y plan, contrato, configuración, retención y finalidad.
No. La organización sigue teniendo que definir qué datos puede usar cada proceso, quién accede y qué acciones están autorizadas.
La identidad del usuario debe limitar la recuperación antes de enviar fragmentos al modelo; indexar un documento no debería eliminar sus ACL.
Una entrada intenta alterar el comportamiento del modelo de forma no prevista. Se mitiga con controles fuera del modelo, privilegio mínimo, separación de contenido y aprobación en acciones de riesgo.
Sí. Prompts, respuestas, errores y trazas pueden reproducir información del proceso y necesitan permisos y retención propios.
No. Reduce algunas exposiciones pero añade operación, acceso, actualización y seguridad de infraestructura. Se compara el sistema completo.
Diseñamos fuentes, permisos, tools, logs y niveles de autonomía para que el sistema vea y haga sólo lo necesario.