Riesgos de Seguridad de la IA: Cómo Proteger los Sistemas de IA de tu Empresa

En el estudio de brechas de IBM de 2025, el 97% de las organizaciones que notificaron un incidente de seguridad relacionado con IA carecía de controles de acceso adecuados, mientras que el 63% no tenía una política de gobernanza de IA o aún la estaba desarrollando. Las organizaciones con un uso elevado de shadow AI registraron costes de brecha 670.000 USD superiores de media a las que tenían poco o ningún uso de shadow AI. En uno de los casos más costosos documentados, la firma de ingeniería Arup perdió unos 25,6 millones de USD después de que un empleado se uniera a una videollamada donde los demás "compañeros", incluido el CFO, eran deepfakes generados por IA.

Esta distancia entre la velocidad de adopción de la IA y el nivel de seguridad con el que se despliega define el momento actual. Esta guía repasa los diez riesgos que toda empresa debería conocer, los incidentes reales que los confirman, los marcos que estructuran una defensa y un plan de acción práctico para cerrar esa brecha — con especial atención a lo que cambia cuando la IA deja de ser un copiloto y se convierte en un agente con acceso a sistemas propios.

Riesgos de Seguridad y Alucinaciones de la IA: Dos Problemas Distintos

Los riesgos de seguridad de la IA y las alucinaciones se confunden con frecuencia, pero describen fallos distintos. Los riesgos de seguridad afectan a la confidencialidad, integridad, disponibilidad o control del sistema. Muchos implican un atacante; otros empiezan con permisos excesivos, divulgación accidental o un diseño inseguro. Las alucinaciones son fallos de fiabilidad: el modelo genera información falsa sin necesitar una entrada maliciosa. Una alucinación también puede provocar un incidente de seguridad si una persona o un sistema automatizado actúa sobre ella. Para entender por qué los modelos alucinan y cómo gestionarlo, consulta nuestra guía sobre alucinaciones de la IA.

Ambas categorías se cruzan de una forma muy concreta: una alucinación se convierte en riesgo de seguridad en el momento en que un atacante puede actuar sobre ella. Cuando un asistente de código inventa un paquete de software que no existe, un atacante puede registrar exactamente ese nombre y cargarlo con malware — un patrón conocido como slopsquatting. Un estudio de USENIX Security 2025 que analizó 576.000 muestras de código generadas por 16 modelos encontró tasas de paquetes inexistentes de al menos el 5,2% en modelos comerciales y el 21,7% en modelos open source, con más de 205.000 nombres de paquetes falsos identificados (Spracklen et al., USENIX Security 2025). La alucinación es la puerta de entrada; la acción del atacante es lo que la convierte en una brecha real.

El Panorama de Amenazas: 10 Riesgos que Toda Empresa Debería Conocer

El OWASP Top 10 for LLM Applications (edición 2025) es la taxonomía de referencia para estructurar el riesgo de seguridad de la IA. Así se traduce cada riesgo a la práctica empresarial:

1. Prompt injection. El riesgo principal dos ediciones seguidas. Los LLM procesan instrucciones y datos no confiables por el mismo canal, así que un atacante puede diseñar una entrada que el modelo interprete como una nueva orden. La inyección directa escribe instrucciones maliciosas directamente en el chat; la inyección indirecta las esconde en documentos, correos, páginas web o imágenes que la IA procesa automáticamente — el atacante nunca interactúa con el sistema directamente. El NCSC del Reino Unido advirtió en diciembre de 2025 de que este problema puede no tener solución definitiva, porque nace de cómo los modelos de lenguaje interpretan el texto. Conviene distinguirlo de un jailbreak: un jailbreak intenta superar las restricciones de comportamiento del modelo; una prompt injection manipula la jerarquía de instrucciones de la aplicación completa.

2. Divulgación de información sensible. Los LLM pueden memorizar y reproducir fragmentos de los datos con los que fueron entrenados o ajustados — código propietario, contratos, datos personales. Este riesgo pasó del sexto puesto en la edición anterior de OWASP al segundo en 2025. También ocurre por prompts descuidados, sistemas RAG y bases de datos vectoriales expuestas.

3. Cadena de suministro. Vulnerabilidades heredadas de modelos de terceros, plugins, APIs, componentes open source y herramientas de desarrollo comprometidas. En una encuesta de proveedor realizada en 2026 a 500 CISO de Estados Unidos, el 99% expresó preocupación por una brecha de SaaS o de la cadena de suministro de IA (Vorlon 2026 CISO Report).

4. Envenenamiento de datos y modelos. Los atacantes introducen datos maliciosos durante el entrenamiento, el fine-tuning o la generación de embeddings para plantar puertas traseras, degradar la precisión o sesgar las respuestas. La actualización OWASP 2025 amplió este riesgo más allá de los datos de pre-entrenamiento para incluir también fine-tuning y manipulación de embeddings.

5. Manejo inadecuado de las salidas. Cuando la salida de una IA alimenta directamente a otro sistema — un comando de shell, una consulta a base de datos, una página web — sin validación, el resultado puede ser ejecución remota de código, inyección SQL o cross-site scripting. La vulnerabilidad de LangChain CVE-2023-29374 (CVSS 9,8, crítica) permitió que un prompt injection ejecutara código arbitrario a través del método exec() de Python en las versiones afectadas hasta la 0.0.131. Trata cada salida de IA como una entrada no confiable, igual que tratarías un formulario enviado por un usuario anónimo.

6. Agencia excesiva. Este riesgo determina cuánto daño puede causar cualquier otro riesgo de la lista — y es la razón por la que los agentes de IA elevan tanto las apuestas. Surge de dar a un sistema de IA más herramientas, permisos o autonomía de la que la tarea requiere. Uno de cada tres participantes en la encuesta de Vorlon a 500 CISO de Estados Unidos notificó un incidente de seguridad relacionado con agentes de IA en 2025. La solución es arquitectónica, no un ajuste de prompt: mínimo privilegio, credenciales acotadas y aprobación humana para acciones de alto impacto, aplicadas fuera del modelo — nunca delegadas a la decisión de la IA.

7. Fuga del system prompt. Nuevo en la edición 2025. Los system prompts a veces contienen lógica de negocio o secretos incrustados; si un atacante los extrae, esa lógica queda expuesta. Los secretos deben vivir en un gestor de secretos, nunca en un prompt.

8. Debilidades de vectores y embeddings. Nuevo en 2025 y específico de sistemas RAG. Un aislamiento deficiente puede mostrar datos de un cliente en las respuestas de otro, mientras que los ataques contra embeddings pueden revelar información sobre los datos de origen. Los atacantes también pueden envenenar los documentos que recupera la IA. La investigación ConfusedPilot demostró cómo el contenido malicioso introducido en documentos usados por sistemas RAG podía manipular respuestas y perjudicar la confidencialidad y la integridad.

9. Desinformación. Confiar ciegamente en información generada por IA — el punto donde fiabilidad y seguridad se tocan, como se explicó antes.

10. Consumo sin límites. Uso de recursos sin control que provoca denegación de servicio o "denegación de cartera" (denial of wallet) — atacantes que inflan tus costes de nube mediante consultas excesivas. Rate limiting y monitorización de uso son la defensa estándar.

El OWASP Top 10 for Agentic Applications, publicado en diciembre de 2025 como edición 2026, extiende esta taxonomía a sistemas capaces de actuar, no solo de responder. La AEPD ha señalado que la IA agéntica combina autonomía, información del entorno digital y capacidad de ejecutar tareas complejas. Avisos de INCIBE-CERT publicados en 2026 documentan vulnerabilidades donde una prompt injection podía desembocar en ejecución remota de código.

Ataques Reales, Pérdidas Reales: Incidentes de Seguridad de IA que Fueron Noticia

El fraude con deepfakes de Arup — 25,6 millones de USD (Hong Kong, 2024). Un empleado de finanzas de la firma británica de ingeniería recibió un correo de spear-phishing y después se unió a una videollamada donde el "CFO" y varios "compañeros" eran deepfakes generados por IA. Convencido de que las instrucciones eran legítimas, transfirió unos 200 millones de HKD mediante 15 operaciones. Ningún sistema interno se vio comprometido — fue ingeniería social amplificada por IA.

La fuga de código fuente de Samsung en ChatGPT (2023). Según la información publicada, en apenas 20 días tras levantar una prohibición interna, empleados de Samsung pegaron código fuente de semiconductores y notas de reuniones confidenciales en ChatGPT en tres ocasiones distintas. Samsung restringió el uso de IA generativa por sus empleados y empezó a preparar herramientas internas. El incidente sigue siendo un ejemplo ampliamente citado de fuga de datos por shadow AI.

EchoLeak, Microsoft 365 Copilot (CVE-2025-32711, divulgada en 2025). Investigadores de seguridad demostraron una vía de prompt injection indirecta zero-click que podía divulgar datos mediante un único correo diseñado para ello, sin interacción del usuario. La investigación superó el clasificador de Microsoft contra prompt injection. Microsoft corrigió el servicio alojado antes de la publicación y el registro de la CVE no recoge explotación conocida contra clientes.

El caso PyTorch/torchtriton (diciembre de 2022). Una dependencia maliciosa publicada en PyPI aprovechó dependency confusion y afectó a instalaciones nightly de PyTorch para Linux realizadas entre el 25 y el 30 de diciembre, con capacidad para exfiltrar información del sistema y archivos sensibles. Las versiones estables no se vieron afectadas, pero el caso demuestra que los pipelines de IA heredan el riesgo del ecosistema de paquetes con el que se construyen.

Token SAS excesivamente permisivo en un repositorio de investigación de Microsoft (2023). Investigadores de Wiz localizaron un token de acceso mal configurado cuyo alcance estimaron en unos 38 TB. Microsoft confirmó que el token expuso información interna relacionada con dos exempleados, pero señaló que no se expusieron datos de clientes ni quedaron en riesgo otros servicios internos. El caso demuestra que un secreto mal configurado puede resultar más peligroso que un ataque sofisticado contra el modelo.

Estos casos comparten un patrón importante: la seguridad de la IA es multiplicativa. Rara vez un ataque depende de romper el modelo por sí solo — encadena una prompt injection con un agente con privilegios excesivos, o un token expuesto con una dependencia envenenada. Evaluar cada riesgo por separado tiende a infravalorar lo que un atacante decidido puede lograr combinando varias debilidades pequeñas.

Los Marcos que Definen la Seguridad de la IA Hoy

Ningún marco lo cubre todo. Los programas de seguridad maduros combinan varios:

Una precisión necesaria: el AI Act no es una ley "futura" en sentido simple, ni todas sus obligaciones de alto riesgo son exigibles por igual todavía. La aplicación general comenzó el 2 de agosto de 2026, y las obligaciones para modelos de IA de propósito general empezaron antes, en agosto de 2025. Pero el AI Act Omnibus, en vigor desde el 27 de julio de 2026, aplazó las reglas de determinados sistemas de alto riesgo del Anexo III hasta el 2 de diciembre de 2027, y las de sistemas de alto riesgo integrados en productos regulados hasta el 2 de agosto de 2028. Antes de comprar o construir un sistema de alto riesgo, clasifícalo junto con tu rol contractual, y exige a cualquier proveedor evidencias proporcionales a sus obligaciones vigentes en cada fecha — no una suposición genérica de que "el AI Act todavía no aplica."

Cómo Proteger los Sistemas de IA de tu Empresa: Un Plan de 4 Pasos

La madurez de seguridad en IA sigue una secuencia. Saltar directamente a defensas sofisticadas sin resolver antes lo básico suele dejar abiertos los vectores de mayor impacto.

Cumplimiento de Seguridad de la IA: Qué Exigen España, El Salvador, Colombia y Estados Unidos

La situación jurídica cambia mucho según el mercado: la UE ya cuenta con un marco vinculante basado en riesgos; El Salvador combina una ley de fomento con reglas de registro; Colombia suma orientación de política pública y sanciones penales específicas; y Estados Unidos mantiene un mapa de cumplimiento estatal.

España y la UE. España designó a AESIA (Agencia Española de Supervisión de la Inteligencia Artificial) como autoridad de vigilancia del mercado del AI Act. AESIA supervisa las normas aplicables del Reglamento, mientras que el proyecto nacional que distribuye el régimen más amplio de gobernanza y sanciones seguía en tramitación parlamentaria en agosto de 2026. El artículo 15 del AI Act exige que los sistemas de alto riesgo alcancen "un nivel adecuado de exactitud, solidez y ciberseguridad" y aborda explícitamente el envenenamiento de datos y modelos, los ejemplos adversariales y los ataques contra la confidencialidad — el calendario ajustado por el Omnibus se detalla en la sección de marcos anterior. Para la mayoría de empresas de la UE, la seguridad de la IA convive con el RGPD, que exige notificar las brechas de datos personales sujetas a notificación en un máximo de 72 horas cuando sea posible, NIS2 para entidades esenciales e importantes y, en sectores regulados, DORA o la Cyber Resilience Act. Nuestra guía del EU AI Act cubre el panorama de cumplimiento completo. La AEPD ha publicado además materiales específicos sobre exactitud, idoneidad y minimización de datos personales en tratamientos que usan IA, e INCIBE-CERT recomienda controlar los datos compartidos y las condiciones contractuales al consumir modelos de frontera.

El Salvador. El Decreto 234 (Ley de Fomento a la Inteligencia Artificial y Tecnologías, promulgado en febrero de 2025) nombra "seguridad y privacidad" como principio central y creó ANIA, la agencia nacional de IA. La Resolución 0001/2025 de ANIA exige registro para sistemas de IA que tomen "decisiones consecuenciales" en áreas como crédito, seguros o identificación biométrica en tiempo real en espacios públicos.

Colombia. El CONPES 4144 (febrero de 2025) establece una hoja de ruta nacional de IA hasta 2030 con un eje explícito de mitigación de riesgos, aunque es orientación de política pública, no ley vinculante. La Ley 2502 de 2025 ya tiene efecto práctico: modificó el código penal para añadir un agravante — hasta un tercio más de pena — al fraude de identidad cometido mediante IA, incluidos los deepfakes. Sigue en trámite legislación vinculante más amplia.

Estados Unidos. En agosto de 2026 no existía una única ley federal de seguridad de la IA que sustituyera al creciente conjunto de normas estatales. La TRAIGA de Texas, vigente desde el 1 de enero de 2026, establece varias defensas frente a responsabilidad. Entre ellas figuran descubrir una infracción mediante pruebas adversariales o red teaming, o cumplir sustancialmente el perfil de IA generativa del NIST u otro marco reconocido y mantener un proceso de revisión interna; la ley las presenta como alternativas, no como una única lista acumulativa. Colorado derogó su AI Act original antes de que entrara en vigor y lo sustituyó por la SB 26-189, una ley de decisiones automatizadas más limitada que entra en vigor el 1 de enero de 2027 junto con la Chatbot Safety Act estatal. La California AI Transparency Act (SB 942) comenzó a aplicarse el 1 de enero de 2026. Otra ley distinta, la Transparency in Frontier Artificial Intelligence Act (SB 53), regula a los grandes desarrolladores de modelos frontera. Los requisitos de decisiones automatizadas de la CCPA llegan en enero de 2027. A nivel federal, la Orden Ejecutiva 14365 ordenó actuaciones contra las leyes estatales que la Administración consideraba excesivas, y el National AI Legislative Framework de marzo de 2026 pidió que actuara el Congreso; ninguno de esos documentos sustituye por sí mismo las leyes estatales. Las cifras económicas siguen siendo altas: IBM notificó un coste medio de brecha de 10,22 millones de USD en Estados Unidos en 2025, mientras que Deloitte proyectó que las pérdidas estadounidenses por fraude habilitado por IA generativa podrían alcanzar los 40.000 millones de USD en 2027.

Cómo Protegen tus Datos las Principales Plataformas de IA

La comparación cubre productos empresariales. Los planes de consumo pueden aplicar condiciones distintas de entrenamiento, retención y revisión humana, así que confirma las condiciones del producto exacto que compra tu organización.

Las plataformas de IA que las empresas ya utilizan ofrecen controles empresariales, pero las condiciones exactas dependen del producto y del contrato. Anthropic no entrena por defecto con las entradas o salidas de sus productos comerciales, y los clientes empresariales de API que reciban aprobación pueden negociar la retención cero de datos; este acuerdo no cubre automáticamente Claude for Work ni otros productos con estado. Anthropic cuenta con certificaciones SOC 2 Type II, ISO/IEC 27001 e ISO/IEC 42001. OpenAI excluye por defecto los datos de negocio del entrenamiento y ofrece controles de retención personalizados para los productos y organizaciones que cumplan los requisitos. Microsoft 365 Copilot no usa los datos del cliente para entrenar modelos fundacionales y permite gobernar las interacciones almacenadas mediante políticas de retención de Microsoft Purview. Google aplica defensas por capas contra la prompt injection indirecta en Gemini, entre ellas clasificadores de contenido, endurecimiento del modelo, eliminación de URLs sospechosas y confirmación del usuario para acciones sensibles.

La brecha que enfrenta la mayoría de las empresas no es la ausencia de estos controles — es que rara vez están bien configurados, monitorizados o conectados con el resto del stack de seguridad. Esa parte requiere ingeniería deliberada, no la configuración por defecto del proveedor.

Preguntas Frecuentes