La inteligencia artificial ya no está aislada en laboratorios ni pilotos controlados. Hoy responde en chatbots, busca en documentación interna, ayuda a desarrollar código, automatiza tareas y se conecta a APIs, bases de datos y herramientas corporativas. Y ahí aparece el problema: cuanto más útil es la IA, más cerca está de la información que una empresa no puede permitirse filtrar.
Durante mucho tiempo, la principal preocupación fue si los prompts podían usarse para entrenar modelos. Pero el riesgo actual es mucho más amplio. Una IA puede exponer información sensible por los datos con los que fue entrenada, por el contexto que recupera, por los permisos que hereda, por los conectores que utiliza o por los registros que deja en logs, embeddings y plataformas de terceros.
La fuga de información en IA no siempre ocurre porque el modelo “revele” un secreto. Muchas veces ocurre porque la arquitectura le ha dado acceso a datos, herramientas o procesos que nunca deberían estar disponibles para ese caso de uso.
Por eso, la seguridad en IA ya no puede limitarse a revisar el modelo. Hay que analizar todo el ecosistema: aplicaciones, integraciones, proveedores, permisos, datos, flujos de automatización y controles de gobierno. Un chatbot mal diseñado, incorrecta segmentación de un RAG (técnica de IA que permite a los modelos de lenguaje consultar bases de datos o documentos externos), un copiloto conectado a repositorios internos o un agente con acceso excesivo a APIs pueden convertirse en nuevas vías de exposición para la organización.
El segundo grupo de riesgos aparece cuando la IA se conecta a la infraestructura de la empresa. Esta es, probablemente, la zona donde se están materializando los incidentes más preocupantes. La IA ya no responde solo con conocimiento general: ahora consulta bases documentales, resume expedientes, abre tickets, accede a CRMs, interactúa con repositorios de código, invoca herramientas, procesa ficheros de clientes y se integra con APIs internas.
No basta con preguntar “¿qué modelo vamos a usar?”. La pregunta crítica es: “¿qué puede ver, recuperar, registrar y ejecutar este sistema de IA dentro de mi organización?”.
Cuando una organización conecta un chatbot a una web, un asistente interno a una base documental o un agente a herramientas corporativas, la superficie de ataque se desplaza. El atacante ya no necesita comprometer directamente la base de datos si puede manipular el contexto que consume el modelo, forzar una recuperación indebida, abusar de un conector o provocar que el agente ejecute una acción no prevista.
Algunos vectores especialmente relevantes son:
▪️RAG sin control de permisos: El sistema recupera documentos que el usuario no debería poder ver, porque el índice vectorial no replica correctamente la autorización del repositorio original.
▪️Prompt injection indirecta: Un documento, una página web, un correo o una incidencia contiene instrucciones ocultas que el modelo interpreta como órdenes y no como datos no confiables.
▪️Fuga de contexto: El modelo revela información de su prompt de sistema, instrucciones internas, políticas, datos de otros usuarios o fragmentos recuperados del contexto.
▪️Abuso de herramientas: El agente usa conectores con permisos excesivos para consultar, modificar, reenviar o exportar información.
▪️Logs y telemetría sobredimensionados: Prompts, respuestas, documentos adjuntos, identificadores personales, secretos o resultados de herramientas quedan almacenados en plataformas de observabilidad o proveedores externos.
▪️Conectores y MCPs inseguros: Plugins, tools o servidores MCP introducen vulnerabilidades clásicas -SSRF, inyección, deserialización, escalada de privilegios- en un flujo ahora gobernado por lenguaje natural.
El riesgo de fuga en IA no debe presentarse como ciencia ficción. Ya existen casos públicos que ilustran patrones reales: errores de aislamiento, credenciales con permisos excesivos, bases de datos de logs expuestas, secretos comprometidos, integraciones con herramientas de desarrollo y prompt injection en asistentes conectados al entorno del usuario.
| Caso público | Qué ocurrió | Lectura para la empresa |
| OpenAI / ChatGPT, 2023 | Un fallo relacionado con Redis provocó exposición de títulos de conversaciones y, durante una ventana concreta, información de pago de una parte de suscriptores Plus. | Incluso plataformas maduras pueden sufrir fugas en componentes de infraestructura, caché o sesiones. |
| Microsoft AI Research, 2023 | Un fallo relacionado con Redis provocó exposición de títulos de conversaciones y, durante una ventana concreta, información de pago de una parte de suscriptores Plus. | Compartir datasets o artefactos de IA con permisos mal configurados puede convertirse en una brecha masiva. |
| Hugging Face Spaces, 2024 | La compañía informó de acceso no autorizado a secretos de Spaces y rotó tokens afectados. | Los secretos asociados a entornos de IA deben tratarse como activos críticos, no como simple configuración de desarrollo. |
| SAP AI Core, 2024 | Investigadores reportaron fallos de aislamiento y exposición de artefactos y secretos en una plataforma multi-tenant de IA. | El aislamiento entre clientes, workloads, modelos y artefactos es esencial en plataformas MLOps/AI Cloud. |
| DeepSeek, 2025 | Se reportó una base ClickHouse expuesta con logs, historial de chat, claves API y detalles backend. | Los logs de IA pueden contener datos extremadamente sensibles y deben protegerse como información de alto impacto. |
| GitHub Copilot / VS Code, 2025 | Se documentaron escenarios de prompt injection y command injection capaces de impactar el entorno local del desarrollador. | Los copilotos y agentes de desarrollo pueden tocar código, tokens, repositorios y comandos; deben aislarse y auditarse. |
En un proyecto empresarial, la fuga rara vez aparece de forma aislada. Normalmente es el resultado de varias decisiones razonables tomadas por equipos distintos: innovación quiere acelerar el chatbot, IT conecta repositorios documentales, negocio pide trazabilidad, desarrollo habilita herramientas, y seguridad entra demasiado tarde. El resultado puede ser un sistema funcional, pero con rutas de exposición difíciles de detectar en una revisión tradicional.
Chatbot de atención al cliente conectado a documentación interna
El asistente responde correctamente a preguntas públicas, pero el índice RAG contiene documentos de procedimientos internos, argumentarios comerciales, incidencias o datos de clientes que no deberían estar disponibles para usuarios externos.
Asistente interno con permisos heredados
Un empleado con pocos privilegios pregunta al asistente por una política, pero el agente consulta una fuente documental usando una cuenta de servicio con acceso global y devuelve contenido restringido.
Copiloto de desarrollo con acceso a repositorios y terminal
Una instrucción maliciosa escondida en un README, un issue o un fragmento de código puede inducir al agente a revelar tokens, rutas internas, variables de entorno o ejecutar comandos no previstos.
Fine-tuning con tickets reales de soporte
El dataset contiene números de cliente, credenciales temporales, trazas de errores, tokens, mensajes de usuarios o información contractual. Si no se anonimiza, el modelo ajustado puede aprender patrones que después aparecen en respuestas.
Logs de prompts tratados como logs técnicos normales
Las conversaciones con IA incluyen documentos, datos personales, decisiones de negocio y extractos de código. Si se almacenan sin minimización, cifrado ni retención limitada, el sistema de observabilidad se convierte en un repositorio sensible.
Muchas empresas intentan encajar la IA dentro de controles ya conocidos: pentest web, revisión de API, hardening cloud, gestión de proveedores o cumplimiento RGPD. Todos siguen siendo necesarios, pero no cubren por sí solos la complejidad de un ecosistema de IA. La razón es que los sistemas basados en LLM mezclan tres elementos que en seguridad clásica intentamos mantener separados: instrucciones, datos y acciones.
Una aplicación tradicional recibe datos y ejecuta lógica definida por el programador. Un sistema con IA interpreta lenguaje natural, recupera contexto externo y puede decidir qué herramienta utilizar para alcanzar un objetivo. Esa flexibilidad aporta valor, pero también hace que el límite entre “contenido que hay que procesar” e “instrucción que hay que obedecer” sea menos nítido. Por eso la prompt injection no debe entenderse como una simple variante de SQL injection: en muchos casos no hay una sanitización perfecta, y la defensa depende de arquitectura, permisos, validaciones, monitorización y control humano.
Antes de desplegar o escalar un sistema de IA conectado a datos corporativos, las organizaciones deberían realizar una revisión específica de seguridad y gobierno. No basta con aceptar las condiciones del proveedor o confiar en que el modelo base sea seguro: hay que evaluar el caso de uso, la arquitectura, los datos, los permisos y los controles operativos.
| Área | Preguntas clave | Controles recomendados |
| Datos y entrenamiento | ¿Qué datos se usan para entrenar, ajustar o evaluar el sistema? ¿Hay datos personales, secretos o propiedad intelectual? | Minimización, anonimización/pseudonimización, revisión de datasets, control de origen, documentación y evaluación de impacto. |
| RAG y bases documentales | ¿El índice respeta permisos? ¿Se mezclan documentos públicos, internos y confidenciales? | Segmentación por sensibilidad, ACLs por usuario, validación de fuentes, eliminación controlada y pruebas de fuga de contexto. |
| Agentes y herramientas | ¿Qué APIs puede invocar el agente? ¿Puede leer, escribir, borrar, enviar o ejecutar? | Least privilege, cuentas de servicio dedicadas, sandboxing, aprobaciones humanas, límites de acción y auditoría. |
| Proveedores y SaaS | ¿Se reutilizan prompts para entrenamiento? ¿Dónde se almacenan logs? ¿Qué subencargados participan? | Revisión contractual, retención limitada, cláusulas de no entrenamiento, ubicación de datos, evidencias y derecho de auditoría. |
| Logs y telemetría | ¿Qué queda registrado de prompts, respuestas, documentos y llamadas a herramientas? | Minimización de logs, cifrado, mascarado de secretos, retención definida, acceso restringido y alertas de exposición. |
| Pruebas ofensivas | ¿Se ha probado prompt injection, jailbreak, fuga de contexto, abuso de herramientas y extracción de secretos? | Red-teaming específico de IA, pruebas sobre integraciones reales, fuzzing de conectores, revisión de MCPs y validación de mitigaciones. |
Si su organización ya está conectando IA a datos internos, sistemas de clientes o herramientas corporativas, el momento de revisar la seguridad no es después del incidente: es antes de que el asistente, el RAG o el agente pasen a producción.
En este contexto, una Auditoría Integral de Seguridad para Ecosistemas de IA permite evaluar de forma modular los componentes realmente desplegados por la organización: plataformas de IA y MLOps, integraciones con aplicaciones tradicionales, modelos LLM y su orquestación, así como conectores, plugins o tools que habilitan capacidades de agente frente a servicios externos.
Este enfoque es especialmente relevante para empresas que ya utilizan IA en producción o están escalando casos de uso con datos sensibles, sistemas internos, interacción con clientes o requisitos regulatorios. La ventaja de auditar antes de escalar es doble: se reduce el riesgo de fuga de información y se obtienen evidencias técnicas para tomar decisiones de gobierno, cumplimiento y priorización de controles.
Antes de conectar un chatbot a su documentación interna, desplegar un RAG corporativo o permitir que un agente interactúe con APIs de negocio, conviene verificar qué puede ver, qué puede hacer y qué podría filtrar. Una auditoría específica de seguridad en IA ayuda a identificar vulnerabilidades, desviaciones de buenas prácticas y riesgos operativos antes de que impacten en clientes, datos o reputación.
En Internet Security Auditors damos un Servicio integral y modular orientado a evaluar la seguridad de los componentes de IA de una organización, tanto a nivel de Plataforma, como de Integraciones con sistemas tradicionales, Modelos LLM y su Orquestación y Conectores/Plugins/Tools que habilitan capacidades de agente frente a servicios externos. El alcance se configura “a medida” según el contexto del cliente.
Referencias
Fuentes regulatorias y marcos de referencia
AEPD - Política general para el uso de IA generativa.
https://www.aepd.es/documento/politica-iag-aepd.pdf
AEPD - Orientaciones sobre inteligencia artificial agéntica.
https://www.aepd.es/guias/orientaciones-ia-agentica.pdf
CNIL - AI system development: recommendations to comply with GDPR.
Guía sobre desarrollo de sistemas de IA conforme al RGPD, minimización, privacidad y medidas de seguridad. https://www.cnil.fr/en/ai-system-development-cnils-recommendations-to-comply-gdpr
EDPB - Opinion on AI models and GDPR principles.
Referencia sobre anonimización de modelos, interés legítimo y efectos del tratamiento ilícito de datos en entrenamiento. https://www.edpb.europa.eu/news/news/2024/edpb-opinion-ai-models-gdpr-principles-support-responsible-ai_en
EDPB - AI privacy risks and mitigations in LLMs.
https://www.edpb.europa.eu/system/files/2025-04/ai-privacy-risks-and-mitigations-in-llms.pdf
ENISA - Securing Machine Learning Algorithms.
Taxonomía y amenazas sobre seguridad en machine learning. https://www.enisa.europa.eu/publications/securing-machine-learning-algorithms
NIST - Adversarial Machine Learning:
A Taxonomy and Terminology. https://csrc.nist.gov/pubs/ai/100/2/e2025/final
NIST - AI RMF Generative AI Profile.
Marco para gestión de riesgos de IA generativa. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
OWASP - LLM01 Prompt Injection.
https://genai.owasp.org/llmrisk/llm01-prompt-injection/
OWASP - Training Data Poisoning.
https://genai.owasp.org/llmrisk2023-24/llm03-training-data-poisoning/
Casos públicos citados
OpenAI - March 20 ChatGPT outage.
Incidente de exposición de títulos de conversaciones y datos de pago durante una ventana limitada. https://openai.com/index/march-20-chatgpt-outage/
Wiz - Microsoft AI Research data exposure.
Caso de exposición asociada a SAS token demasiado permisivo y datos de investigación en IA. https://www.wiz.io/blog/38-terabytes-of-private-data-accidentally-exposed-by-microsoft-ai-researchers
Microsoft MSRC - mitigated exposure due to overly permissive SAS token.
Confirmación y medidas adoptadas por Microsoft en relación con la exposición. https://www.microsoft.com/en-us/msrc/blog/2023/09/microsoft-mitigated-exposure-of-internal-information-in-a-storage-account-due-to-overly-permissive-sas-token
Hugging Face - Spaces secrets disclosure.
Disclosure sobre acceso no autorizado a secretos de Spaces y rotación de tokens. https://huggingface.co/blog/space-secrets-disclosure
Wiz - SAPwned: SAP AI Core vulnerabilities.
Investigación sobre fallos de aislamiento y exposición de artefactos/secretos en plataforma de IA. https://www.wiz.io/blog/sapwned-sap-ai-vulnerabilities-ai-security
Wiz - DeepSeek database leak.
Caso de base ClickHouse expuesta con logs, historial de chat, claves API y detalles backend. https://www.wiz.io/blog/wiz-research-uncovers-exposed-deepseek-database-leak
GitHub - Safeguarding VS Code against prompt injections.
Análisis sobre prompt injection en entornos de desarrollo asistidos por IA. https://github.blog/security/vulnerability-research/safeguarding-vs-code-against-prompt-injections/
AWS - Security Bulletin AWS-2025-015.
Caso sobre Amazon Q Developer para VS Code y medidas de mitigación. https://aws.amazon.com/security/security-bulletins/AWS-2025-015/