El 81% de las organizaciones reportó un ciberataque exitoso a medida que crecía la presión de la IA
Google News puso de relieve una cifra contundente: cerca del 80% de las organizaciones sufrió un ciberataque, mientras que la IA generaba nueva presión sobre programas de seguridad ya exigidos. El número parece demostrar que la inteligencia artificial ha roto de repente la seguridad empresarial. La investigación subyacente respalda una conclusión más compleja.
La cifra verificada más sólida procede del 2026 Cyberthreat Defense Report, promovido por Google Cloud y basado en respuestas de 1.200 profesionales de seguridad. El informe determinó que el 81% de las organizaciones experimentó al menos un ciberataque exitoso durante el año anterior. Por separado, el 80% de los profesionales de seguridad temía que la IA pudiera afectar sus empleos.
Estos hallazgos describen dos condiciones relacionadas, no una única categoría combinada de incidentes de IA. Los ciberataques siguen siendo generalizados, mientras que la IA cambia la forma en que operan los atacantes, responden los defensores y las empresas exponen datos. Tratar cada brecha como un evento de IA ocultaría los fallos que aún importan más.
Palo Alto Networks llegó a una conclusión similar tras responder a más de 750 incidentes importantes durante 2025. Sus investigadores descubrieron que brechas evitables contribuyeron de forma sustancial a más del 90% de las vulneraciones investigadas. La IA aceleró partes del proceso de ataque, pero la visibilidad deficiente, la confianza excesiva y los controles inconsistentes siguieron abriendo la puerta.
El conflicto real es, por tanto, confianza frente a control. Las empresas están desplegando asistentes, agentes autónomos y herramientas de desarrollo de IA más rápido de lo que los equipos de seguridad pueden inventariarlos. Al mismo tiempo, siguen sin resolverse debilidades conocidas en identidad, parcheo, configuración en la nube y respuesta a incidentes.
Lo que realmente mide el titular de Google News
La cifra del 80% indica una elevada tasa general de fallos de ciberseguridad, no demuestra que la IA causara cuatro de cada cinco incidentes.
El referente de ciberamenazas afirma que el 81% de las organizaciones experimentó un ciberataque exitoso durante el año anterior. CyberEdge encuestó a 1.200 profesionales de seguridad informática de 17 países y 19 sectores para el informe.
La misma investigación reveló que el 67% esperaba sufrir un ataque exitoso durante el año siguiente. También informó que el 64% se había enfrentado a ransomware, mientras que el 55% de los encuestados afectados pagó. Entre quienes pagaron, el 39% aun así no logró recuperar sus datos.
Estas cifras describen el entorno general de amenazas. Incluyen ransomware, compromiso de cuentas, robo de datos, ataques a la nube y otras clases de incidentes consolidadas. El resumen no afirma que la IA causara el 81% de esos ataques exitosos.
Esta distinción importa porque la agregación puede fusionar varias afirmaciones independientes en un titular dramático. Una publicación de Google News podría colocar la IA, la ciberseguridad y una estadística del 80% una junto a otra. Entonces, los lectores pueden inferir una relación causal que la investigación fuente no estableció.
El hallazgo del estudio sobre IA se refería a la fuerza laboral de seguridad. El ochenta por ciento de los encuestados temía que la IA pudiera afectar sus empleos, mientras que el 97% de los responsables de contratación buscaba candidatos con habilidades de IA. Esa combinación sugiere cambios en los roles y presión sobre las competencias, más que un simple reemplazo.
La IA sigue formando parte de la historia. Los atacantes la usan para acelerar la investigación, crear señuelos convincentes, resolver problemas de código malicioso y operar contra un mayor número de objetivos. Los defensores la usan para clasificar alertas, identificar comportamientos sospechosos y automatizar la contención.
Sin embargo, una campaña de phishing asistida por IA aún puede tener éxito porque un empleado entregó sus credenciales. Una brecha en una aplicación de IA puede comenzar con un plug-in vulnerable o una API expuesta. Una intrusión en la nube puede expandirse porque una cuenta de servicio tiene permisos excesivos.
Llamar a todos estos eventos “incidentes de IA” haría que la estadística fuera menos útil. Los responsables de seguridad necesitan saber si la IA fue el objetivo, la herramienta de ataque, la aplicación vulnerable o solo parte del entorno circundante.
La categoría también afecta la rendición de cuentas. Una empresa podría culpar a amenazas avanzadas de IA mientras ignora un sistema sin parchear o una política de identidad permisiva. Esa explicación hace que el incidente parezca inevitable, incluso cuando controles ya establecidos podrían haber reducido el daño.
Por tanto, los lectores de Google News deberían interpretar el titular como una advertencia sobre riesgos superpuestos. Los incidentes cibernéticos ya son frecuentes, y la IA se está añadiendo a sistemas que arrastran una deuda de seguridad persistente.
La cifra del 81% sigue siendo alarmante sin adornos. Muestra que los ataques exitosos se han convertido en una condición operativa normal para muchas organizaciones. No establece que la IA haya causado esos ataques de forma independiente.
Esta distinción ofrece la prueba central para cada nueva afirmación sobre seguridad de IA. Pregunte qué midió la encuesta, quién la respondió y cómo definieron los investigadores un incidente. Después, pregunte si la IA causó el fallo o amplificó una debilidad existente.
La adopción de IA avanza más rápido que la preparación de seguridad
Las empresas están llevando la IA a producción mientras la visibilidad, la responsabilidad y los procesos de investigación siguen incompletos.
El estudio 2026 AI and Human Risk Landscape de Proofpoint encuestó a más de 1.400 profesionales de seguridad de 12 países. Determinó que el 87% de las organizaciones había desplegado asistentes de IA más allá de la fase piloto. Otro 76% estaba probando o implementando agentes autónomos.
Un agente autónomo es software que puede perseguir un objetivo y realizar acciones en sistemas conectados con una dirección humana limitada. Esa capacidad distingue a los agentes de los chatbots que solo producen texto. También proporciona a los agentes acceso a credenciales, repositorios de datos, herramientas de colaboración y flujos de trabajo empresariales.
La encuesta sobre riesgos de IA reveló que el 42% de los encuestados había experimentado un incidente sospechoso o confirmado relacionado con IA. Solo un tercio afirmó estar plenamente preparado para investigar un incidente que abarque múltiples sistemas y canales de comunicación.
La cobertura de seguridad no garantizaba confianza. Aunque el 63% informó contar con cobertura de seguridad para IA, el 52% no confiaba plenamente en que esos controles detectaran un sistema de IA comprometido. Más de la mitad de las organizaciones con controles aún reportó un incidente relacionado con IA.
La exposición se extendía más allá de los productos de IA dedicados. Los encuestados identificaron el correo electrónico como el vector de amenaza más común, seguido por software de terceros, aplicaciones en la nube, plataformas sociales y sistemas de mensajería. Los asistentes y agentes de IA añadieron otra superficie conectada.
Esto importa porque la IA empresarial rara vez opera de forma aislada. Un asistente podría leer correo electrónico, buscar documentos, llamar a un modelo externo y publicar una respuesta en un canal de colaboración. Cada conexión crea otro lugar donde los permisos, la supervisión o el manejo de datos pueden fallar.
Cloud Security Alliance detectó un problema de visibilidad aún más marcado. Su encuesta de enero de 2026 abarcó a 418 profesionales de TI y seguridad de organizaciones de distintos tamaños y ubicaciones.
Según la encuesta sobre seguridad de agentes, el 82% de los encuestados había descubierto agentes de IA previamente desconocidos durante el año anterior. El cuarenta y uno por ciento había realizado ese descubrimiento varias veces.
Los agentes desconocidos aparecían con mayor frecuencia en automatización interna, entornos de scripting, plataformas de modelos de lenguaje, servicios de software con automatización integrada y flujos de trabajo de desarrolladores. Estos lugares suelen quedar fuera del proceso de compras que supervisan los equipos de seguridad.
El mismo estudio determinó que el 65% había experimentado al menos un incidente relacionado con agentes de IA. Entre las organizaciones afectadas, el 61% reportó exposición de datos, el 43% reportó interrupción operativa y el 35% reportó consecuencias financieras.
La encuesta fue encargada y financiada por Token Security, un proveedor de seguridad de identidad para IA. Esa relación no invalida los resultados, pero debería orientar la forma en que los lectores los ponderan. Las encuestas patrocinadas por proveedores suelen enfatizar problemas vinculados al mercado del patrocinador.
La metodología también se basa en informes de los encuestados, no en registros de incidentes verificados. Términos como “incidente relacionado con IA” pueden abarcar eventos con causas y gravedad distintas. Un encuestado podría contar experimentación no autorizada, mientras que otro cuenta robo de datos confirmado.
Incluso con esas salvedades, estudios independientes revelan un patrón coherente. La adopción de IA ha superado las pruebas aisladas, pero muchas organizaciones carecen de inventarios completos y procedimientos de investigación.
La presión recae sobre los directores de seguridad de la información, los equipos de nube, los desarrolladores y los gerentes de negocio. Deben respaldar un despliegue rápido mientras determinan a qué puede acceder cada sistema de IA y quién es responsable de su comportamiento.
Los trabajadores del conocimiento también configuran este riesgo. Los empleados pueden pegar material sensible en cuentas personales de IA o conectar asistentes no aprobados a servicios de la empresa. Una base de conocimientos de IA clara puede reducir la confusión sobre dónde pertenece la información aprobada, pero no puede reemplazar los controles de acceso.
Por tanto, los equipos de seguridad se enfrentan a dos rutas de adopción. La ruta oficial incluye herramientas aprobadas, evaluaciones de riesgos y despliegues supervisados. La ruta en la sombra comienza cuando los equipos crean agentes o integraciones sin revisión centralizada.
Ambas rutas pueden aportar valor empresarial. Solo una proporciona de forma fiable a los defensores el contexto necesario para investigar un incidente.
El conflicto real es confianza frente a control
Los responsables de seguridad suelen expresar confianza mientras sus entornos técnicos muestran vulnerabilidades sin resolver, credenciales expuestas y protecciones débiles para agentes.
Orca Security abordó el problema mediante telemetría de nube, en lugar de una encuesta de opinión. Su 2026 State of AI Security Report analizó datos del segundo trimestre de más de 1.200 organizaciones en producción en Amazon Web Services, Microsoft Azure y Google Cloud.
El análisis abarcó paquetes de IA, endpoints de modelos, infraestructura en la nube, credenciales y despliegues de agentes. Más de la mitad de las organizaciones observadas tenía IA en producción.
Orca determinó que el 81% de las organizaciones que ejecutaban paquetes de software de IA tenía al menos una vulnerabilidad conocida. La puntuación media de gravedad entre los paquetes afectados alcanzó 8,79 en el Common Vulnerability Scoring System de diez puntos.
Una puntuación de vulnerabilidad estima la gravedad técnica de un fallo de software. No demuestra explotación, pero una puntuación más alta generalmente indica un mayor impacto potencial o un abuso más fácil.
Los hallazgos de telemetría de nube también informaron que el 50,1% de las alertas de vulnerabilidades de IA tenía un exploit público disponible. Orca afirmó que la cifra correspondiente era del 0,2% en su informe de 2024.
De forma más llamativa, el 99,9% de las alertas de vulnerabilidades de IA con una corrección disponible permanecía sin parchear. Esa cifra describe alertas observadas a través de la plataforma de Orca, no todos los sistemas de IA del mundo. Aun así, muestra la rapidez con la que puede acumularse una exposición identificable.
El informe descubrió que el 29,5% de los adoptantes de IA almacenaba al menos una credencial de IA en una ubicación insegura. También determinó que el 56% había desplegado marcos de agentes en producción, a menudo sin controles de seguridad formales.
Las credenciales son especialmente importantes porque los agentes necesitan autorización para actuar. Un agente podría tener una clave de API, un token de nube, una contraseña de base de datos o una autorización de software. Si los atacantes capturan esa credencial, pueden heredar el acceso del agente.
El problema no consiste simplemente en si un modelo produce una respuesta insegura. El peligro mayor comienza cuando el software puede convertir una respuesta en una acción externa. Un agente podría enviar un mensaje, modificar un registro, recuperar datos confidenciales o ejecutar código.
Los sistemas de identidad tradicionales asumen que una persona tiene un trabajo relativamente estable y necesidades de acceso predecibles. Los agentes pueden crearse rápidamente, duplicarse entre flujos de trabajo y abandonarse después de un proyecto. Sus permisos pueden seguir activos una vez que su propósito original desaparece.
La Cloud Security Alliance denomina una parte de este problema “deuda de retirada”. Solo el 21% de las personas encuestadas en su estudio contaba con un proceso formal para retirar agentes. Un agente abandonado puede conservar credenciales y permisos mucho después de que alguien deje de supervisarlo activamente.
Aquí es donde la confianza se separa del control. Un responsable de seguridad puede creer que la organización tiene políticas sólidas de IA mientras agentes desconocidos siguen operando. Un equipo puede instalar un producto de análisis y, aun así, dejar sin resolver vulnerabilidades corregibles.
Por tanto, la inversión en seguridad no puede medirse solo por el número de herramientas desplegadas. Las preguntas más relevantes se refieren a la cobertura y los resultados.
¿Puede la organización identificar a cada agente en producción? ¿Puede asignar un responsable a cada uno? ¿Puede explicar qué fuentes de datos lee el agente y qué acciones puede realizar?
¿Pueden los defensores revocar el acceso del agente sin interrumpir sistemas no relacionados? ¿Pueden reconstruir sus acciones después de un incidente? ¿Pueden distinguir una instrucción maliciosa de una tarea empresarial aprobada?
Si la respuesta es no, la confianza se apoya en supuestos. Esos supuestos se vuelven peligrosos cuando los agentes operan entre recursos en la nube y documentos internos.
Una base de conocimiento técnico con capacidad de búsqueda puede ayudar a los equipos a conservar decisiones de arquitectura, registros de propiedad y evidencias de incidentes. Sin embargo, la documentación debe mantenerse conectada con datos en tiempo real de identidad y supervisión.
La disyuntiva central no es innovación frente a seguridad. Es velocidad de despliegue frente a control verificable. Las organizaciones pueden avanzar rápido, pero cada nueva conexión debe seguir siendo detectable y atribuible.
La IA amplifica fallos antiguos con más frecuencia de la que crea nuevos
Los fallos de seguridad de IA más dañinos suelen comenzar con debilidades conocidas en identidad, configuración, aplicación de parches y confianza humana.
Los datos de respuesta a incidentes de Unit 42 de Palo Alto Networks aportan un contrapunto importante a los titulares de las encuestas. Su informe de 2026 se basó en más de 750 incidentes graves en más de 50 países.
Los investigadores señalaron que los atacantes aún se encontraban en una fase temprana de adopción de técnicas habilitadas por IA. La IA ya reducía la fricción en reconocimiento, ingeniería social, creación de scripts, resolución de problemas y extorsión. Sin embargo, las intrusiones normalmente seguían rutas conocidas.
Según los datos de respuesta a incidentes, brechas prevenibles facilitaron de forma significativa más del 90% de las vulneraciones investigadas. Esas brechas incluían telemetría incompleta, controles inconsistentes, confianza excesiva en las identidades y conexiones de terceros no gestionadas.
Esta evidencia cuestiona la idea de que los defensores necesitan una arquitectura de seguridad completamente nueva para cada amenaza de IA. Algunos controles especializados son necesarios, especialmente para prompts, modelos, agentes e identidades de máquina. El trabajo básico de seguridad sigue determinando el resultado.
Gartner planteó un punto similar tras encuestar a 302 líderes de ciberseguridad de Norteamérica, Europa, Oriente Medio, África y Asia-Pacífico. La encuesta se realizó entre marzo y mayo de 2025.
El 62% de las personas encuestadas había sufrido un ataque de deepfake que implicaba ingeniería social o procesos automatizados. El 32% informó de un ataque contra una aplicación de IA, mientras que el 29% citó un ataque contra infraestructura de IA generativa.
Los deepfakes utilizan medios generados o manipulados para imitar a una persona real. Pueden hacer más convincentes el fraude y la suplantación de identidad, pero los atacantes aún necesitan un proceso que acepte la identidad falsa.
La encuesta sobre ataques de GenAI concluyó que el 67% de los líderes de ciberseguridad esperaba que los riesgos emergentes de IA exigieran cambios significativos. Gartner recomendó reforzar los controles básicos y añadir medidas específicas para las nuevas categorías de riesgo.
Ese enfoque equilibrado evita dos errores costosos. El primero es tratar la IA como software convencional e ignorar su capacidad para procesar instrucciones o actuar de forma autónoma. El segundo es culpar a la IA mientras se descuida la seguridad fundamental.
Pensemos en un empleado que recibe una llamada de voz generada por IA de alguien que suplanta a un ejecutivo. La síntesis de voz aumenta la credibilidad de la llamada. La pérdida sigue dependiendo de si los procedimientos financieros permiten que una sola solicitud por voz autorice una transferencia.
Pensemos en un asistente de programación que introduce una dependencia vulnerable. La IA podría acelerar el error, pero el análisis de composición de software y la revisión de código aún pueden detectarlo. El control subyacente sigue siendo conocido.
Pensemos en un agente con permiso para buscar archivos internos y enviar los resultados por correo electrónico. La manipulación de prompts podría influir en su comportamiento. El acceso excesivo determina cuánta información puede exponer.
La investigación Cost of a Data Breach 2026 de IBM añade contexto financiero. El informe examinó vulneraciones sufridas por 602 organizaciones entre marzo de 2025 y febrero de 2026.
IBM informó de que una de cada cuatro vulneraciones maliciosas utilizó IA y tuvo un coste medio de 6 millones de dólares. El promedio global entre las vulneraciones fue de 4,99 millones de dólares. Las vulneraciones habilitadas por IA incluyeron suplantación mediante deepfakes y malware asistido por IA.
Más del 20% de las organizaciones participantes informó de una vulneración dirigida a modelos o aplicaciones de IA. Las causas más comunes implicaban API, aplicaciones, complementos y configuraciones incorrectas de nube comprometidos en torno a cargas de trabajo de IA.
El estudio sobre el coste de las vulneraciones también concluyó que las organizaciones que utilizaban IA y automatización en las operaciones de seguridad redujeron los costes de las vulneraciones en casi 2 millones de dólares de media.
Ese resultado muestra a la IA operando en ambos lados de la contienda. Los atacantes pueden reducir el coste de atacar a las organizaciones. Los defensores pueden reducir el tiempo de investigación y automatizar la contención.
La pregunta importante no es si una empresa utiliza IA. Es si la organización aplica IA dentro de un sistema de seguridad disciplinado.
La automatización sin datos fiables puede acelerar malas decisiones. Una respuesta automatizada podría desactivar un servicio legítimo o pasar por alto actividad que ocurre fuera de los canales supervisados. Un modelo entrenado con alertas incompletas puede reproducir los puntos ciegos ya presentes en el programa de seguridad.
Los estudios subyacentes también presentan limitaciones. Las encuestas miden percepciones y eventos autoinformados. La telemetría de los proveedores cubre a clientes y entornos visibles para una plataforma concreta. Los informes de respuesta a incidentes se concentran en organizaciones con problemas lo suficientemente graves como para solicitar ayuda externa.
Esas muestras no deberían combinarse en una única tasa universal de incidentes. Miden poblaciones, definiciones y períodos distintos. Su valor reside en la dirección reiterada de los hallazgos.
En todas las investigaciones, las organizaciones están adoptando IA rápidamente. La visibilidad y la gobernanza suelen quedarse atrás. Los atacantes explotan tanto nuevas superficies de IA como debilidades conocidas.
La evidencia no respalda afirmar que la IA causó cada incidente del titular de Google News. Respaldan una conclusión más acotada y accionable: la IA aumenta la velocidad y la escala allí donde ya existen controles débiles.
Tres señales mostrarán si la brecha se está cerrando
La cobertura del inventario, la velocidad de corrección y la preparación para investigar revelarán más que otra encuesta de confianza.
La primera señal es si las organizaciones pueden elaborar un inventario completo de sistemas y agentes de IA. Ese inventario debería incluir responsables, credenciales, datos conectados, acciones aprobadas y fechas de retirada.
Las cifras de descubrimiento deberían aumentar inicialmente a medida que las empresas buscan con mayor cuidado. Encontrar más agentes en la sombra puede indicar una mejora de la visibilidad, en lugar de un empeoramiento del comportamiento. La prueba más sólida es si los despliegues desconocidos disminuyen después de ese primer ciclo de inventario.
Un programa creíble también debería distinguir los experimentos de los servicios de producción. Un prototipo temporal no conlleva el mismo riesgo que un agente que procesa registros de clientes. Ambos siguen necesitando un responsable y una política de caducidad.
La segunda señal es la velocidad de corrección. El hallazgo de Orca sobre alertas sin parches importa porque existía una solución para las vulnerabilidades medidas. Los informes futuros deberían mostrar si las organizaciones reducen el tiempo entre la divulgación, la priorización y el despliegue.
Los porcentajes brutos de parches pueden inducir a error cuando las alertas incluyen software inaccesible o sin uso. Los equipos de seguridad deberían priorizar las exposiciones según su explotabilidad, acceso a internet, privilegios y proximidad a datos sensibles. También deberían documentar por qué se aplaza cualquier corrección.
Una acumulación de tareas pendiente en descenso reforzaría la idea de que las operaciones de seguridad se están poniendo al día. Una acumulación creciente mostraría que el desarrollo de IA sigue añadiendo software más rápido de lo que los equipos pueden evaluarlo.
La tercera señal es la preparación para investigar. Proofpoint descubrió que solo un tercio de las personas encuestadas se sentía totalmente preparada para investigar un incidente de IA que abarcara múltiples sistemas. Esa cifra debería mejorar a medida que las organizaciones unifican los registros y establecen procedimientos de respuesta.
Un ejercicio útil debería rastrear un agente a lo largo de todo su flujo de trabajo. Los investigadores necesitan la instrucción original, los datos recuperados, la salida del modelo, las llamadas a herramientas, las decisiones de identidad y las acciones resultantes.
También necesitan autoridad para contener el problema. Registrar una acción insegura después de que ocurra no equivale a prevenirla. Las transacciones de alto riesgo deberían requerir aprobación o un límite de política aplicable.
Los reguladores y organismos de normalización influirán en estas señales, pero la evidencia interna debería llegar primero. Los consejos de administración no necesitan esperar a un nuevo mandato para preguntar si cada agente en producción tiene un responsable que rinda cuentas.
Los compradores de seguridad también deberían resistirse a las promesas simples. Un producto que “protege la IA” puede cubrir modelos, código, identidades, prompts o datos, pero rara vez todos ellos. Los compradores deben vincular cada herramienta con una exposición verificada.
Google News seguirá generando titulares alarmantes sobre la seguridad de la IA porque las condiciones que los sustentan siguen siendo reales. La mejor respuesta no es otra declaración amplia de confianza.
Pida a su organización tres evidencias: un inventario actual de IA, un informe de corrección de exposiciones y los resultados de un ejercicio de incidentes de IA. Si los equipos no pueden producirlos, la brecha de seguridad sigue siendo medible. Si pueden, compare de nuevo esos registros el próximo trimestre y busque menos agentes desconocidos, correcciones más rápidas e investigaciones más completas.
