Seguridad y privacidad al implantar IA en empresa: cómo evitar fugas de datos en prompts, LLMs y RAG

La mayoría de las empresas con las que hablamos en Everglow tienen el mismo miedo de fondo cuando hablamos de implantar IA: que un día aparezca un cliente, un competidor o un regulador con datos suyos en la mano que no deberían tener. No es un miedo abstracto. Es lo que está bloqueando, ahora mismo, decenas de proyectos de IA en empresas españolas medianas y grandes. La buena noticia es que la seguridad y la privacidad al implantar IA en empresa son perfectamente tratables si se diseñan desde el principio. La mala es que casi nadie las diseña: las acaban parcheando cuando el piloto ya está en producción y alguien del comité de dirección pregunta por primera vez “¿y esto es legal?”.

Este post es una guía operativa, no un informe legal. Habla de cómo proteger datos cuando usas LLMs, RAG, agentes y copilotos internos en una empresa real, en España, con stack moderno y con personas que cometen errores. Si vienes buscando “cómo cumplir el AI Act párrafo por párrafo”, tenemos otro artículo sobre eso. Aquí vamos a lo otro: cómo construir un sistema de IA del que te puedas fiar, y por el que puedas firmar tú.

Qué se entiende por “fuga de datos” cuando usas IA en empresa

Hay tres tipos de fugas que se mezclan en las conversaciones y conviene separar, porque la mitigación es distinta en cada una.

La fuga hacia el proveedor del modelo ocurre cuando metes datos sensibles en un LLM y esos datos acaban viajando, registrándose o, en el peor de los casos, entrenando un modelo de un tercero. Esto preocupa al departamento legal y al CISO antes que cualquier otra cosa.

La fuga hacia el usuario equivocado ocurre dentro de tu propia organización: el copiloto interno responde a Marketing con datos de Finanzas porque nadie configuró bien los permisos del RAG, o un agente devuelve un cliente que el comercial que pregunta no debería ver. Es la fuga más frecuente y, normalmente, la peor castigada por inspección laboral o por el comité ético interno.

La fuga hacia el mundo exterior ocurre cuando un atacante logra que el modelo le suelte información a través de prompt injection, fuga por contexto, o porque el endpoint de tu agente está mal protegido. Es la menos visible hasta que aparece en prensa.

Las tres se previenen con cosas distintas. Mezclarlas en un único “plan de seguridad de IA” es el primer error.

El principio que ordena todo lo demás

La seguridad en IA empresarial no consiste en blindar el LLM. Consiste en que el LLM nunca vea datos que no debería ver, y en que lo que ve no pueda salir por donde no debe.

Si interiorizas esta frase, el 80% de las decisiones técnicas se ordenan solas. La pregunta deja de ser “¿este modelo es seguro?” y pasa a ser “¿qué datos entran, por qué, con qué permisos, dónde se quedan y quién puede recuperarlos después?”. Es un cambio de foco del modelo a los datos, que es donde está el riesgo real.

Capa 1: identidad y permisos antes que cualquier otra cosa

El primer error de casi todas las implantaciones que rescatamos es haber empezado por el modelo. La capa que debe estar primero es la de identidad y permisos. Si tu IA empresarial no sabe quién está preguntando, no puede saber qué tiene derecho a ver. Y si no lo sabe, dará por bueno cualquier acceso, porque los LLMs son entusiastas por defecto.

En la práctica esto significa:

• Cada interacción con cualquier sistema de IA debe ir asociada a un usuario autenticado (SSO con tu IdP corporativo: Azure AD, Google Workspace, Okta).
• Cada usuario debe tener un perfil de permisos heredado del sistema fuente, no inventado en la capa de IA. Si en Salesforce solo ve cuentas de Iberia, su copiloto solo debe ver cuentas de Iberia. Punto.
• El sistema de IA no debe tener un “superusuario” técnico que vea todo y filtre después. Eso es lo que se rompe al primer fallo.
• Cualquier acción del agente (no solo respuestas, también escrituras: crear ticket, enviar email, modificar registro) debe quedar trazada con el usuario que la solicitó.

Si tu implantador de IA no te pregunta por SSO, ACLs y herencia de permisos antes de hablarte de modelos, malo.

Capa 2: dónde corre el modelo y qué se queda donde

Aquí es donde más se confunde la gente. Hay tres modos de uso de LLMs en empresa, con perfiles de riesgo muy distintos.

Modelo SaaS público vía API empresarial. Es lo que usa el 90% de las empresas (OpenAI, Anthropic, Google) a través de sus tiers enterprise. Si está bien configurado (cuenta empresarial, retención cero o limitada, no opt-in de entrenamiento, residencia de datos en UE), es perfectamente válido para muchos casos. No es la opción más restrictiva, pero tampoco es “regalarle tus datos a un americano”. Hay que leer el contrato y configurar bien, no copiar el de la cuenta personal del CTO.

Modelo en tu cloud privado (Azure OpenAI, Bedrock, Vertex). El modelo es el mismo, pero corre dentro de tu tenant, con tu cifrado, tu residencia y tus logs. Para la mayoría de empresas medianas con datos sensibles, esto es el equilibrio correcto entre control y velocidad de implantación.

Modelo open source self-hosted (Llama, Mistral, Qwen, etc., en tu propia infraestructura). Máximo control, máximo coste operativo, peor rendimiento que el state of the art comercial. Solo tiene sentido cuando un contrato, una ley o un regulador concreto te lo impone, o cuando tu volumen es tan grande que el coste por token cambia la ecuación. La inmensa mayoría de empresas que se meten aquí por “seguridad” acaban volviendo a SaaS privado en 12 meses, después de quemar dinero.

La decisión correcta no es ideológica. Es por clase de dato: hay datos que pueden ir a un SaaS público enterprise, otros que solo pueden ir a tu cloud privado y otros que no pueden salir del datacenter. Lo primero que hace un buen implantador no es elegir modelo: es clasificar los datos.

Capa 3: cómo proteger los datos que entran en el prompt

Aquí está la parte que casi nadie hace bien. Los LLMs son funciones que reciben texto y devuelven texto. Todo lo que les metas en el contexto, lo verán. Y eso incluye el prompt del sistema, el historial de la conversación, los documentos recuperados por RAG, los outputs de las tools y cualquier metadato que decidas adjuntar.

Buenas prácticas operativas para evitar fugas de datos en prompts:

1. Minimiza por defecto. No metas en el contexto lo que no es estrictamente necesario para responder. Si el usuario pregunta por ventas de Iberia Q1, no le mandes el dataset entero confiando en que el modelo “se centrará en lo importante”. Filtra antes.
2. Redacta PII en tránsito cuando aplique. Hay middleware específico (Presidio de Microsoft, Nightfall, soluciones internas) que anonimiza nombres, emails, IBAN, DNI antes de que el texto llegue al modelo. Útil sobre todo cuando el modelo es externo.
3. Cuidado con los logs. El sitio donde más se filtra en la práctica no es el modelo: son los logs. Si guardas cada prompt y cada respuesta en un sistema accesible por el equipo técnico sin más, has creado una base de datos paralela de información sensible. Política clara de retención, cifrado en reposo y acceso auditado.
4. Separa el system prompt de los datos de usuario. Lo que va en el system prompt es público a efectos prácticos: asume que cualquier usuario suficientemente curioso lo va a poder extraer. No metas claves, no metas reglas de negocio sensibles, no metas instrucciones de “si pregunta por X, responde Y” que no querrías ver impresas.

Capa 4: RAG seguro de verdad, no RAG-con-permisos-mal-pegados

El RAG seguro en empresa es la pieza donde más se rompen las cosas. La promesa de RAG es preciosa: el modelo responde con tus datos, no inventa, las respuestas son rastreables. La realidad es que la mitad de las implantaciones de RAG que vemos tienen un fallo de fondo: indexan todos los documentos del Drive/Sharepoint/Confluence y luego intentan filtrar por permisos en la capa de recuperación. Y eso no escala.

El patrón correcto tiene tres reglas:

• Filtrado de permisos en el índice, no en la query. Cada chunk indexado lleva metadatos de a qué usuarios/roles pertenece, y la búsqueda se restringe a chunks autorizados para el usuario que pregunta. No se recuperan los 50 mejores y luego se filtran: se recuperan solo los autorizados.
• Sincronización continua con el sistema fuente. Cuando alguien cambia los permisos del documento original en Sharepoint, el índice debe enterarse en horas, no en semanas. Esto es trabajo aburrido pero crítico.
• Tiering por sensibilidad. Los documentos de Finanzas, Legal o RRHH no se indexan en el mismo store que el manual de onboarding. Mejor varios índices pequeños y bien gobernados que un único índice gigante que nadie controla del todo.

Si te están vendiendo RAG empresarial sin hablarte de ACLs en el índice y sincronización de permisos, lo que te están vendiendo no es seguro.

Capa 5: agentes, tools y el riesgo nuevo

Un copiloto que solo responde es un riesgo de lectura. Un agente que ejecuta acciones es un riesgo de escritura. La diferencia es enorme y a menudo se ignora porque “es la misma tecnología”.

Cuatro reglas para agentes en empresa:

• Catálogo cerrado de tools. El agente solo puede usar las tools que tú le defines, con esquemas estrictos. No “acceso a la API de Salesforce”, sino “puede llamar a esta función concreta con estos parámetros, sobre estas cuentas”.
• Permisos heredados del usuario, no del agente. Si el agente actúa en nombre de un comercial, los permisos efectivos son los del comercial, no los de un service account técnico con privilegios de admin.
• Confirmación humana para acciones de alto impacto. Crear un lead es automatizable. Enviar un email a 5.000 clientes, no. La frontera la decides tú, pero existe.
• Rate limiting y kill switch. Toda acción de agente debe poder ser cortada en segundos, y debe haber alguien (humano) que sepa cómo hacerlo y tenga el botón a mano.

Capa 6: el factor humano, que es el que rompe casi todo

La mayoría de fugas reales de datos en empresas que están usando IA no vienen del modelo. Vienen de un empleado que pegó un contrato confidencial en ChatGPT personal el viernes a las siete porque “iba con prisa”. Esto es prevenible, pero no con tecnología sola.

Lo que funciona:

• Política clara y corta de qué se puede pegar dónde, escrita en lenguaje humano, no en jerga legal.
• Acceso a herramientas corporativas decentes. Si tu plantilla no tiene acceso a un ChatGPT empresarial bien configurado, usará el suyo personal. Garantizado.
• Formación operativa, no charlas inspiracionales. Que cada equipo sepa qué puede y qué no puede hacer en su flujo concreto. Es trabajo paciente y va por departamentos.
• DLP en endpoints si tu nivel de riesgo lo justifica, pero asumiendo que no es una bala de plata.

Cómo se ordena todo esto en una implantación real

Cuando en Everglow entramos en una empresa a implantar IA, el orden por el que abordamos seguridad y privacidad es siempre el mismo, y no es negociable:

1. Clasificación de datos. Qué hay, dónde está, quién accede, qué nivel de sensibilidad. Sin esto, todo lo demás es ruido.
2. Decisión de hosting por clase de dato. Qué casos pueden usar SaaS público enterprise, cuáles cloud privado, cuáles on-prem.
3. Identidad y permisos integrados con el IdP corporativo, antes de tocar el primer modelo.
4. RAG con ACLs reales, no RAG abierto con filtros post hoc.
5. Catálogo de tools cerrado para agentes, con permisos heredados y kill switch.
6. Política de uso y formación por departamento, con la herramienta corporativa funcionando.
7. Monitorización y auditoría continua, no informe trimestral.

Cuando este orden se respeta, la conversación con Legal y con el CISO deja de ser un bloqueo y se convierte en una validación rápida. Cuando no se respeta, el piloto se atasca seis meses en revisiones y al final no entra en producción.

Errores frecuentes que vemos cada semana

• Empezar por elegir modelo antes de clasificar datos.
• Indexar “todo el Drive” sin pensar en permisos por documento.
• Dar a un agente credenciales de admin “para que pueda hacer todo”.
• Confiar en que el LLM “no recordará” lo que le pasas. Lo recuerda mientras dura el contexto y, si tu proveedor no es enterprise, también después.
• No tener un único equipo responsable de la seguridad de la IA. Si la responsabilidad se reparte entre IT, Legal e Innovación sin un dueño claro, no se hace.
• Asumir que cumplir el AI Act es lo mismo que tener un sistema seguro. Es necesario, no suficiente.

Qué hacer esta semana si tienes IA corriendo en tu empresa

Sin esperar a nada más, tres acciones que puedes hacer en cinco días:

• Pide a tu equipo un listado de los sistemas de IA que están corriendo (oficiales y no oficiales) y a qué datos acceden cada uno.
• Audita los permisos de los índices RAG existentes: ¿se sincronizan con la fuente? ¿hay metadatos de ACL por chunk?
• Revisa las cuentas de LLM en uso: ¿son enterprise? ¿qué política de retención y entrenamiento tienen? ¿están en UE?

Con esos tres puntos sobre la mesa, ya sabes si tienes un problema pequeño y solucionable o un problema serio que conviene atajar antes de seguir escalando.

Cómo te puede ayudar Everglow

En Everglow somos implantadora de IA para empresas, no consultora ni agencia. Eso significa que no entregamos un PDF con recomendaciones: entramos en tu stack, clasificamos datos contigo, configuramos identidad y permisos, montamos el RAG con ACLs reales, definimos el catálogo de tools de tus agentes y dejamos el sistema funcionando, auditado y con alguien dentro de tu casa capaz de mantenerlo cuando nos vamos.

Si estás en el punto de “queremos escalar IA pero seguridad nos está frenando”, o en el de “ya tenemos IA corriendo y necesitamos auditarla antes de que se nos vaya de las manos”, ese es exactamente el momento de hablar. Cuéntanos por dónde estás en contacto y te decimos sin rodeos si tiene sentido que entremos, qué haríamos primero y qué impacto puedes esperar en 90 días.