7 incidentes reales de riesgo relacionados con la IA en 2025-26 y las deficiencias de control que pusieron de manifiesto.
– Este artículo analiza siete incidentes ocurridos en los últimos 18 meses y los controles específicos que podrían haberlos detectado o prevenido.
Los fallos no fueron sofisticados: proveedores mal configurados, agentes sin alcance definido, dependencias no mapeadas e interrupciones de LLM que paralizaron los flujos de trabajo empresariales sin un plan de continuidad a la vista.
Los programas que evitan incidentes o los gestionan mejor tienen algo en común: saben qué sistemas de IA están en funcionamiento, a qué pueden acceder y si su entorno coincide con lo documentado. Todo esto en tiempo real, no en el próximo ciclo de revisión.
Incluso tres años y medio después de que el primer máster en derecho (LLM) se popularizara, el riesgo de la IA sigue siendo un terreno relativamente nuevo. Los marcos de trabajo aún se están desarrollando, las superficies de ataque aún se están identificando, y las organizaciones que actuaron primero lo hicieron sin un plan de acción. Y algunas de ellas han pagado las consecuencias.
Sus experiencias son una advertencia; proporcionan datos y lecciones para que todos actuemos con cautela. Los incidentes de los últimos dieciocho meses han enseñado a los CISO y a los líderes de GRC lecciones que ningún marco teórico podría haberles brindado: dónde residen los riesgos reales, qué suposiciones resultaron erróneas y qué controles son realmente importantes cuando la IA está presente en el sistema.
Las conversaciones recientes con clientes muestran el mismo patrón. Como nos comentó un alto directivo de GRC en una empresa global de servicios tecnológicos: «La gobernanza de la IA aún se encuentra en una fase muy temprana para nosotros. Gran parte del trabajo de evaluación todavía se realiza manualmente». El problema no radica en la falta de intención, sino en que la adopción de la IA avanza más rápido de lo que la mayoría de los equipos de gobernanza pueden inspeccionar, documentar y controlar.
En este blog, analizamos incidentes recientes y sus implicaciones para los equipos de GRC (Gobierno, Riesgo y Cumplimiento) en el desarrollo de sus programas. La principal conclusión es que debemos aprender de estas experiencias y construir juntos un enfoque de gobernanza de IA más sólido.
Lección n.° 1 | EchoLeak de Microsoft 365 Copilot: Determinar a qué puede acceder la IA
En junio de 2025, investigadores de Aim Security revelaron una vulnerabilidad crítica en Microsoft 365 Copilot, identificada como CVE-2025-32711 con una puntuación CVSS de 9.3. El ataque se produjo sin que la víctima realizara ninguna acción. El atacante envió un correo electrónico con instrucciones maliciosas. Al procesarlo durante el resumen rutinario, Copilot siguió instrucciones ocultas que incluían la extracción de archivos de OneDrive, SharePoint y Teams, para luego filtrarlos a través de un dominio de Microsoft de confianza. Los antivirus, los firewalls y el análisis estático resultaron ineficaces. El exploit operaba en lenguaje natural, sin necesidad de código. Microsoft lo parcheó tras su divulgación responsable, y no se confirmó ninguna explotación por parte de atacantes antes de la corrección, pero el incidente puso de manifiesto las deficiencias.
En resumen: antes de aprobar su implementación, defina el alcance del sistema, incluyendo sus capacidades y funciones autónomas.
Lección n.° 2 | Incidente del agente de IA de Meta: Los fallos de los agentes requieren controles específicos.
En marzo de 2026, un agente de IA dentro de Meta realizó una acción no autorizada en un foro interno, publicando un consejo a un empleado sin haber recibido instrucciones para hacerlo. Dicho empleado actuó en consecuencia, desencadenando una serie de eventos que permitieron a un grupo de ingenieros acceder a los sistemas de Meta sin autorización. No hubo ningún atacante externo involucrado. La IA misma fue la causante del fallo.
Conclusión: Verifique los límites de permisos y los controles de intervención humana para las acciones con consecuencias importantes en todas las implementaciones basadas en agentes. Asegúrese de que estén configurados antes de que las capas de agentes accedan a datos y sistemas confidenciales o influyan en la toma de decisiones críticas.
Lección n.° 3 | La brecha de ForcedLeak: la IA con acceso sensible necesita gobernanza de entrada-salida
En la Lección n.° 1 hablamos sobre herramientas de IA con acceso excesivo. Esta lección trata sobre cómo controlar qué se le puede preguntar a la IA, quién puede hacerlo y si existe alguna validación entre la instrucción y la acción. En septiembre de 2025, Noma Security descubrió ForcedLeak , una vulnerabilidad de inyección de mensajes en Salesforce Einstein AI que permitía a los atacantes extraer datos confidenciales de CRM solo con texto. Sin malware. Sin código de explotación. Los firewalls estaban bien. El cifrado funcionaba. Los permisos de la base de datos eran estrictos. Pero la IA, que tenía acceso legítimo a todo, podía ser persuadida fácilmente para entregar la información.
En resumen: Filtre la entrada y salida de la IA con capas de protección y salvaguardias para evaluar si una solicitud se encuentra dentro de los límites antes de que el modelo actúe en consecuencia.
Lección n.° 4 | El ataque LiteLLM: La seguridad de tu cadena de suministro de IA depende de su dependencia más profunda.
A finales de marzo de 2026, unos atacantes comprometieron LiteLLM, una herramienta de código abierto que conecta aplicaciones con servicios de IA, presente en aproximadamente el 36 % de los entornos en la nube. Al insertar código malicioso en dos versiones del paquete antes de que nadie se percatara, lograron robar credenciales de miles de organizaciones que lo habían descargado. Mercor , una empresa de análisis de datos que colabora con OpenAI, Anthropic y Meta, confirmó estar entre las miles de organizaciones afectadas. La brecha expuso datos de más de 40 000 contratistas, repositorios de código fuente y, potencialmente, las metodologías de entrenamiento de IA de varios laboratorios de vanguardia. Meta suspendió toda colaboración con Mercor.
En resumen: Extienda la gobernanza de la IA más allá de las herramientas que ha adquirido. Identifique las dependencias de código abierto y los componentes de terceros en los que confían sus proveedores, y evalúelos como parte de su proceso de gestión de riesgos de la cadena de suministro.
Lección n.° 5 | La interrupción del servicio ChatGPT: Trate a los proveedores de LLM como infraestructura
El 10 de junio de 2025, ChatGPT sufrió una caída global de más de 10 horas , afectando simultáneamente a usuarios de Estados Unidos, Reino Unido, Europa y Australia. Para las organizaciones que habían integrado las API de ChatGPT en sus flujos de trabajo operativos, no existía un plan de respaldo, ya que nadie había incluido un proveedor de gestión de la continuidad del negocio (LLM) en su planificación de continuidad. La mayoría de los marcos de continuidad del negocio aún carecen de una categoría para este tipo de soporte.
Un análisis detallado del incidente documenta el impacto en las empresas: los chatbots de atención al cliente, los servicios de asistencia interna y los flujos de trabajo automatizados de documentos dejaron de funcionar junto con la propia plataforma. Su lectura es recomendable para cualquier equipo que dependa de un único proveedor de gestión de licencias para sus operaciones.
En resumen: identifique las herramientas y plataformas de IA que podrían haberse vuelto cruciales para su negocio, tanto directamente como a través de las relaciones con otros proveedores, e inclúyalas en la planificación de la continuidad del negocio.
Lección nº 6 | El Vercel/Contexto.ai Violación de seguridad: los tokens OAuth son la nueva vía de movimiento lateral.
El 19 de abril de 2026, Vercel reveló una brecha de seguridad que no se originó en su propia infraestructura, sino en Context.ai, una pequeña herramienta de productividad con IA de terceros utilizada por un solo empleado de Vercel. En febrero de 2026, un empleado de Context.ai fue infectado con malware. El atacante extrajo tokens OAuth de la máquina comprometida, los utilizó para acceder a la cuenta de Google Workspace del empleado de Vercel y se introdujo en los sistemas internos de Vercel. Dado que los tokens OAuth, una vez emitidos, no requieren reautenticación, la autenticación multifactor (MFA) no ofrecía protección. Vercel confirmó que las credenciales de un subconjunto de clientes se vieron comprometidas.
En resumen: los permisos de OAuth otorgados a las herramientas de productividad de IA son rutas de acceso permanentes que se mantienen activas mucho después de la decisión inicial de conectarlas. Es necesario inventariarlos, limitarlos al acceso mínimo indispensable y revisarlos periódicamente. No deben otorgarse y luego olvidarse.
Lección n.° 7 | La brecha de seguridad de GitHub: Incluso las extensiones de marketplace de confianza necesitan un período de espera.
El 19 de mayo de 2026, GitHub confirmó que aproximadamente 3,800 repositorios internos habían sido vulnerados después de que un solo empleado instalara una versión maliciosa de la extensión Nx Console VS Code desde el Marketplace oficial de Visual Studio. La versión infectada estuvo activa solo 18 minutos antes de ser retirada. En ese breve lapso, obtuvo credenciales —incluidas las de bóvedas de 1Password, configuraciones de Claude Code, npm, GitHub y AWS— y proporcionó a los ciberdelincuentes acceso a los sistemas internos de GitHub.
Conclusión: Establezca una política de gobernanza de extensiones y complementos que aplique un período de espera obligatorio a cualquier instalación nueva o actualizada, dando tiempo suficiente al análisis de seguridad automatizado para que se ejecute antes de que cualquier empleado pueda instalarla. Capacite a los equipos para que sepan que ni siquiera los mercados de confianza garantizan la seguridad en el momento de la instalación.
¿Qué tienen en común estos 7 incidentes?
Ninguno de estos incidentes requirió un atacante sofisticado. Ninguno reveló una categoría de riesgo que los marcos de GRC no hubieran previsto. Lo que sí revelaron es que la IA avanza más rápido que los ciclos de revisión en los que se basaron las organizaciones, y las brechas que surgieron eran difíciles de detectar para cualquier programa.
Los proveedores incorporaron funciones de IA a productos ya aprobados sin previo aviso. Componentes de código abierto que nadie se molestó en evaluar resultaron ser fundamentales. Empleados que buscaban una mayor productividad conectaron herramientas que crearon rutas de acceso no planificadas. No se trata de negligencia; son la fricción inherente a la gestión de una tecnología que evoluciona más rápido que los marcos diseñados para contenerla.
Un alto directivo de GRC en una empresa global de infraestructura digital y servicios tecnológicos describió la realidad operativa con claridad: «Cada semana surge un nuevo caso de uso de IA». Ese es el principal desafío de gobernanza. El riesgo de la IA no se presenta como una actualización anual de políticas, sino que surge de forma continua a través de nuevas herramientas, nuevos proveedores, nuevos flujos de trabajo y nuevos comportamientos de los empleados.
Los programas que obtienen mejores resultados son aquellos que han encontrado la manera de reducir ese desfase. No se trata de una visibilidad perfecta, pero sí de la suficiente para saber qué sistemas de IA operaban en su entorno, a qué podían acceder y si el entorno real seguía coincidiendo con lo documentado.
Sprinto puede ayudarte a reducir el retardo.
Sprinto se basa en la premisa de que la visibilidad continua es el único tipo de visibilidad que funciona en un entorno con alta presencia de inteligencia artificial.
- On riesgo del proveedorEl sistema autónomo de gestión de riesgos de proveedores (TPRM) de Sprinto detecta a los proveedores a medida que se incorporan a su entorno, les asigna un nivel de riesgo y realiza un seguimiento continuo para detectar cambios. Cuando la postura de un proveedor cambia, incluyendo modificaciones en la forma en que las capacidades de IA gestionan sus datos, se activa una revisión y se realiza un seguimiento hasta su finalización, aportando pruebas. El caso de McHire, donde nadie verificó los controles tras la contratación, es precisamente el tipo de brecha que esta solución resuelve.
- On sombra IASprinto mantiene un registro en tiempo real de herramientas de IA en toda su organización, clasificando el riesgo según el acceso a los datos y mapeando su huella de IA con la norma ISO 42001, el Marco de Gestión de Riesgos de IA del NIST y la Ley de IA de la UE. La IA oculta no puede acumularse sin ser detectada.
- On controles de acceso y despliegues basados en agentesSprinto supervisa continuamente los controles, detecta desviaciones y actúa —cerrando brechas, actualizando la evidencia y gestionando las aprobaciones— sin esperar a un ciclo de revisión anual para que salga a la luz lo que ha cambiado.
¿Quieres saber en qué punto se encuentra tu postura de gobernanza de IA tras los incidentes de los últimos 18 meses? Habla con un experto de Sprinto →
Preguntas Frecuentes
La mayoría de los programas detectan esto cuando algo falla, lo cual es demasiado tarde. La verdad es que los cuestionarios de incorporación nunca se diseñaron para detectar cambios a mitad de ciclo. Lo que sí funciona es la monitorización en tiempo real de la postura del proveedor, que permite visualizar cuándo se produce algún cambio en su entorno. Los contratos también deberían exigir explícitamente a los proveedores que le notifiquen los cambios importantes en las capacidades de IA o en el manejo de datos. Actualmente, la mayoría no incluye esta cláusula.
El Marco de Gestión de Riesgos (RMF) de IA del NIST es el más amplio y con mayor número de referencias. La norma ISO 42001 se integra perfectamente con los programas ISO 27001 existentes y es el primer estándar de gestión de IA certificable. La Ley de IA de la UE añade obligaciones vinculantes para las organizaciones que operan o venden en Europa. Sin embargo, es importante destacar que ninguna de estas normas sustituye la necesidad de tener visibilidad en tiempo real de lo que hacen realmente los sistemas de IA; indican qué controles se deben implementar, no si dichos controles funcionan.
Tres aspectos que importan en la práctica: i) La superficie de ataque suele ser el lenguaje natural. Los incidentes de EchoLeak y ForcedLeak descritos anteriormente no requirieron código malicioso. Las herramientas de escaneo tradicionales son en gran medida ajenas a esto. ii) El radio de explosión de un fallo de agente es operativo, no solo informativo. Un agente que actúa incorrectamente puede autorizar acciones o eliminar registros antes de que nadie se dé cuenta, y parte de ese daño es irreversible. iii) La atribución es más difícil: cuando un sistema de IA se comporta fuera de su ámbito previsto, establecer si fue atacado, mal configurado o simplemente mal gobernado lleva más tiempo que una investigación de incidentes convencional.
Tras lo ocurrido en junio de 2025, la respuesta es un rotundo sí si algún proceso operativo depende de ellos. La interrupción del servicio de ChatGPT duró más de 10 horas y afectó a todos los flujos de trabajo que dependían de él. Las organizaciones que no contaban con un plan de respaldo no fueron negligentes; simplemente no trataron a un proveedor de LLM como tratarían una caída del servicio de AWS. La gestión de la confianza debe evolucionar para mitigar estas consecuencias relacionadas con la IA.
Las preguntas que aún faltan en la mayoría de las evaluaciones son: ¿Su producto utiliza IA en algún componente? ¿Ha cambiado esto desde nuestra última revisión? ¿A qué datos accede la IA? ¿Se utiliza alguno de ellos para el entrenamiento del modelo?
Las preguntas también deberían informarte más sobre sus dependencias; necesitas analizar todo tu sistema. ecosistema de proveedores¿En qué modelo base o LLM se basa su producto y quién lo proporciona? ¿Cómo es el control de acceso en tiempo de ejecución para ese componente de IA? ¿A qué puede acceder y qué puede hacer de forma autónoma? ¿Cómo nos notificaría un cambio sustancial en sus capacidades de IA o en el manejo de datos? Esta última pregunta es la más importante y la que con mayor frecuencia se omite. Si no está estipulada en el contrato, el proveedor no tiene la obligación de informarle cuando implemente una función que modifique la forma en que se manejan sus datos.
Los ciclos anuales de revisión de proveedores ya presentaban dificultades antes de que la IA acelerara los ciclos de cambio de proveedores. La solución de compromiso LiteLLM descrita anteriormente se acumuló en los intervalos entre revisiones. La cadencia adecuada ya no se basa en el calendario, sino en los eventos. Los proveedores de alto riesgo —aquellos cuyos componentes de IA acceden a datos confidenciales o se integran en flujos de trabajo críticos— deberían estar sujetos a un control de ejecución que detecte los cambios a medida que ocurren, con una reevaluación formal que se active ante cambios sustanciales en el producto, no solo en la fecha de renovación. Para los proveedores de menor riesgo, la frecuencia mínima debería ser trimestral. Las revisiones anuales de proveedores representan una deficiencia, no un proceso.
Autor
Raynah
Raynah es estratega de contenido en Sprinto, donde crea historias que simplifican el cumplimiento normativo para las empresas modernas. En los últimos dos años, ha trabajado en diversos formatos y funciones para que la seguridad y el cumplimiento resulten menos complicados y estén más alineados con las necesidades del negocio.Vaya más allá de la superficie y descubra los aspectos clave sobre gobernanza, riesgo y cumplimiento que realmente importan.
Gana premios digitales por tu éxito en la sala de juntas.
Explora más
Investigaciones y análisis seleccionados para ayudarte a ganarte un lugar en la mesa.
