La IA ya no ayuda al atacante: empieza a dirigir la operación completa

La pregunta incómoda para un CISO en 2026 ya no es si un atacante utiliza inteligencia artificial. La respuesta es casi siempre afirmativa y, además, poco útil. La cuestión que empieza a importar es otra: ¿puede una entidad detectar que la IA está coordinando una campaña completa, desde el reconocimiento inicial hasta la explotación, el tratamiento de datos robados y la persistencia?

El informe publicado por Anthropic en septiembre de 2026 apunta precisamente ahí. Su equipo de Threat Intelligence documentó y desarticuló operaciones desarrolladas entre diciembre de 2025 y agosto de 2026 en siete áreas de abuso: operaciones cibernéticas, influencia, vigilancia, fraude y estafas, usos biológicos, armas convencionales y destilación ilícita de modelos. En las operaciones cibernéticas se utilizaron Claude Haiku, Sonnet y Opus. Anthropic afirma que no detectó actividad maliciosa con Claude Fable o modelos de la clase Mythos, salvo un caso de destilación ilícita.

El dato relevante no es que un modelo redacte código malicioso. Eso ya forma parte del catálogo conocido. Lo relevante es el desplazamiento de la IA desde la función de copiloto a la de orquestador: coordinar tareas, reducir la necesidad de especialistas, procesar información a escala y sostener campañas contra varias víctimas. La sofisticación deja de ser una señal fiable de quién está detrás. Un operador con claves API robadas puede parecerse demasiado a un grupo patrocinado por un Estado.

Para bancos, aseguradoras y proveedores tecnológicos críticos, esto convierte el informe en algo más que una publicación de threat intelligence. Obliga a revisar cómo se evalúan los terceros ICT, qué indicadores llegan al SOC, cómo se clasifican los incidentes y qué significa realmente tener supervisión humana sobre sistemas de IA. La regulación europea no exige esperar a que llegue el primer incidente para hacerse esas preguntas.

Tesis editorial

La IA ofensiva no está democratizando únicamente la generación de exploits. Está industrializando la coordinación. Esa diferencia cambia el diseño de los controles.

Durante años, los equipos de seguridad han buscado señales relativamente conocidas: malware nuevo, dominios de mando y control, movimientos laterales, picos de autenticación, exfiltración o comportamiento anómalo de una cuenta privilegiada. Siguen siendo señales válidas, pero la IA permite ensamblarlas con mayor rapidez y utilizar servicios legítimos para esconder la operación. El atacante no necesita que un modelo invente una técnica completamente nueva. Le basta con que le ayude a decidir qué objetivo merece la pena, qué credencial utilizar, qué herramienta adaptar y qué información extraer primero.

Anthropic describe este efecto mediante tres dimensiones de “uplift”: velocidad, escala y profundidad. La formulación resulta útil porque evita una obsesión bastante pobre con la pregunta de si la IA ha creado un exploit autónomo. En una campaña real, la ventaja puede aparecer antes: reconocimiento de activos, clasificación de documentos, traducción de comunicaciones, generación de scripts, depuración de herramientas y priorización de víctimas. Ninguna de esas tareas, tomada por separado, parece una revolución. Juntas reducen el coste operativo de atacar.

Mi tesis es directa: las entidades reguladas que sigan tratando el uso malicioso de IA como un problema exclusivo del proveedor del modelo se quedarán sin visibilidad sobre la parte decisiva de la cadena. El riesgo se reparte entre el modelo, el proveedor de nube, los agentes conectados, los repositorios de código, las identidades, los datos y los procesos internos. Un contrato con una cláusula genérica de “uso responsable de IA” no controla esa cadena. Tampoco lo hace un cuadro de mando lleno de porcentajes de cumplimiento que no registra qué herramientas pueden ejecutar acciones y con qué permisos.

El cambio operativo: del copiloto al orquestador

Un copiloto responde a una petición. Un orquestador participa en una secuencia. La diferencia tiene consecuencias técnicas y regulatorias.

En el modelo tradicional, un atacante podía necesitar varios perfiles: alguien para identificar activos, otro para desarrollar o adaptar herramientas, otro para procesar los datos y otro para mantener la operación. La IA comprime esas funciones. No elimina necesariamente el conocimiento humano, pero reduce el número de personas, el tiempo de coordinación y el coste de repetir el proceso contra otra víctima.

Eso explica la afirmación central del informe: los ataques sofisticados ya no requieren atacantes sofisticados. La frase no significa que cualquier aficionado pueda replicar una operación estatal sin recursos. Significa que la sofisticación observada deja de permitir una atribución sencilla. La misma campaña puede combinar un actor con poca experiencia, credenciales obtenidas ilícitamente y servicios de IA con capacidad suficiente para producir resultados que antes exigían una estructura profesional.

La detección también se complica. Un modelo puede ayudar a redactar correos de phishing, pero el correo sigue siendo detectable con controles convencionales. Es más difícil detectar que un agente ha consultado cientos de expedientes, ha clasificado automáticamente los resultados, ha generado instrucciones para una herramienta externa y ha cambiado de estrategia después de observar las respuestas del entorno. El indicio no está en una única llamada al modelo; está en la secuencia.

Por eso los SOC necesitan pasar de vigilar únicamente eventos aislados a analizar cadenas de actividad. La telemetría debe unir, como mínimo, identidad, aplicación, modelo utilizado, herramienta invocada, datos consultados, acción ejecutada y resultado. Si el registro solo dice que “el usuario llamó a un servicio de IA”, la entidad no tiene una pista de auditoría útil. Tiene una línea más en un log.

Qué debería observar un SOC

La primera capa es la identidad. Hay que conocer qué usuario, servicio o agente está utilizando el modelo; con qué método de autenticación; desde qué dispositivo o entorno; y si la llamada utiliza una clave personal, una cuenta de servicio o un secreto compartido. Las claves API sin propietario claro son especialmente problemáticas: dificultan la revocación, la atribución y la investigación posterior.

La segunda es el contexto de la petición. No hace falta almacenar indiscriminadamente todos los prompts para mejorar la detección, pero sí registrar metadatos suficientes: modelo, aplicación, finalidad declarada, volumen, frecuencia, clasificación de los datos y herramientas a las que el modelo puede acceder. En sectores sometidos al secreto profesional o a obligaciones de privacidad, el diseño debe separar la trazabilidad de la captura innecesaria de contenido.

La tercera es la capacidad de acción. Un sistema que solo genera texto tiene un perfil de riesgo distinto de otro que puede consultar un repositorio, abrir una incidencia, enviar un correo, ejecutar código o modificar una configuración. La conexión entre el modelo y una herramienta externa debe recibir controles equivalentes a los de una cuenta privilegiada. Si el modelo puede hacer algo, el atacante que controle su contexto puede intentar inducirle a hacerlo.

La cuarta es la secuencia. Un volumen anómalo de consultas, el acceso a datos de varias clasificaciones, la generación de comandos, la llamada a un repositorio externo y una descarga masiva no deberían analizarse como eventos independientes. El patrón importa más que cada evento.

Lo que el informe de Anthropic permite afirmar y lo que no

El informe cubre operaciones identificadas por el equipo de Anthropic y explica que fueron interrumpidas, que las salvaguardas se reforzaron y que se compartió inteligencia con autoridades y socios cuando procedía. También aclara que los casos publicados no son una muestra estadística del abuso cotidiano, sino ejemplos de actividad especialmente notable o novedosa.

Esta cautela importa. No se puede convertir un conjunto de casos seleccionados en una estimación del porcentaje de ataques que utilizan IA, ni concluir que todos los modelos ofrecen el mismo riesgo. Tampoco sería serio atribuir automáticamente cada operación a un Estado, a un grupo criminal o a un proveedor concreto. La propia categoría de “Generative Threat Group” es un designador interno de Anthropic, no una taxonomía internacional ni una atribución judicial.

Lo que sí puede extraerse es una señal operacional: los proveedores de modelos están detectando intentos de uso malicioso que abarcan toda la cadena de ataque y proceden de actores muy distintos. El problema no está limitado al actor avanzado. Incluye grupos con motivación financiera, operadores políticos, proveedores de spyware y actores presuntamente patrocinados por Estados.

La consecuencia para una entidad financiera es sencilla, aunque no cómoda: no puede esperar a que exista una clasificación sectorial perfecta de la amenaza. Tiene que construir controles basados en capacidades y comportamientos. Si un agente puede investigar, decidir y ejecutar, su riesgo debe evaluarse como una combinación de riesgo de identidad, de terceros, de datos y de automatización.

Impacto regulatorio cruzado

DORA: el modelo es un tercero ICT, pero la responsabilidad no se externaliza

Para bancos, aseguradoras, empresas de inversión y otras entidades financieras europeas, el punto de partida es el Reglamento DORA. El artículo 6 exige un marco de gestión del riesgo de las TIC; los artículos 8 y 9 desarrollan, respectivamente, la identificación y clasificación de riesgos y la protección y prevención. El artículo 11 exige capacidades de respuesta y recuperación, mientras que el artículo 13 obliga a extraer lecciones de incidentes y vulnerabilidades.

La utilización de un modelo externo no queda resuelta con una evaluación de privacidad o una revisión de compras. El artículo 28 trata la gestión del riesgo de terceros proveedores de servicios TIC. Los artículos 29 y 30 añaden exigencias sobre la evaluación previa y los elementos contractuales de esos acuerdos. La entidad debe saber qué servicio presta el proveedor, qué subcontratistas intervienen, dónde se procesan los datos, cómo se comunica un incidente y cómo se termina la relación sin perder la capacidad operativa.

La IA orquestadora tensiona especialmente tres áreas. Primera: concentración. Una misma entidad puede utilizar un modelo mediante una nube, una plataforma de productividad y una herramienta de ciberseguridad. Tres contratos distintos pueden esconder una dependencia común. Segunda: subcontratación. El modelo puede depender de infraestructura, servicios de inferencia, repositorios y herramientas conectadas que no aparecen con claridad en el inventario interno. Tercera: reversibilidad. Si la entidad necesita retirar el acceso durante un incidente, debe poder revocar credenciales, aislar integraciones y conservar los registros sin depender de la cooperación informal del proveedor.

El artículo 19 de DORA establece el reporte de incidentes ICT importantes, después de su clasificación conforme al artículo 18. La existencia de IA en la cadena no cambia por sí sola la clasificación, pero puede alterar el alcance, la velocidad y el impacto del incidente. Un fallo de una aplicación que filtra datos es una cosa; un agente comprometido que consulta sistemas, adapta su comportamiento y repite la acción contra varias unidades es otra. La evaluación debe documentar esa dinámica.

NIS2: el proveedor que no es entidad financiera no desaparece del mapa

La Directiva NIS2 exige en su artículo 21 medidas de gestión de riesgos de ciberseguridad, incluyendo análisis de riesgos, seguridad de la cadena de suministro, gestión de incidentes, continuidad y uso de criptografía cuando proceda. El artículo 23 fija obligaciones de notificación: alerta temprana en 24 horas cuando corresponda, notificación del incidente en 72 horas y un informe final en el plazo de un mes, con los matices establecidos por la Directiva y su transposición nacional.

Las entidades financieras cubiertas por DORA tienen un régimen sectorial específico para buena parte de esas obligaciones. Eso no significa que NIS2 sea irrelevante. Un proveedor de IA, una empresa de software o un prestador tecnológico que no esté cubierto por DORA puede quedar dentro del perímetro de NIS2 según su actividad, tamaño y legislación nacional. Para la entidad financiera, el efecto práctico es que la due diligence debe mirar también la resiliencia regulatoria del proveedor, no solo su folleto comercial.

Hay otra consecuencia: los tiempos de notificación del cliente financiero y los del proveedor no siempre encajan de manera automática. Los contratos deben establecer quién detecta, quién califica, qué información se comparte y cuándo se activa la comunicación. Una cláusula que solo diga “notificar sin demora” no es un procedimiento. En un incidente con un modelo conectado a varios sistemas, puede ser la forma elegante de llegar tarde.

GDPR: la trazabilidad no autoriza a guardar todo

El artículo 32 del GDPR exige medidas técnicas y organizativas apropiadas al riesgo, incluyendo confidencialidad, integridad, disponibilidad y resiliencia de los sistemas. El artículo 33 fija, cuando procede, la notificación de una violación de datos personales a la autoridad de control en un plazo de 72 horas desde que se tenga constancia. El artículo 34 puede exigir comunicación a los afectados cuando exista un alto riesgo.

La detección de agentes de IA no debe traducirse en una captura indiscriminada de prompts, documentos y conversaciones. El principio de minimización del artículo 5.1.c obliga a justificar qué datos se recogen para seguridad, durante cuánto tiempo y con qué acceso. La entidad necesita suficiente telemetría para investigar, pero no una copia permanente de cada dato consultado por cada modelo.

El análisis de riesgo debe incluir instrucciones maliciosas, fuga de información, contaminación de bases de conocimiento y acceso indirecto a datos personales. También debe considerar la posibilidad de que un modelo devuelva información de otra sesión o de otro cliente por un fallo de aislamiento. En ese escenario, el incidente puede afectar simultáneamente a seguridad, privacidad, secreto bancario y continuidad operativa.

AI Act: supervisión humana no es mirar una pantalla

El artículo 4 del AI Act exige medidas de alfabetización en IA para proveedores y responsables del despliegue. El artículo 9 exige un sistema de gestión de riesgos para los sistemas de alto riesgo y el artículo 14 regula la supervisión humana en esos sistemas. La obligación no se satisface designando a una persona que pueda pulsar un botón de parada si no tiene autoridad, información ni tiempo para hacerlo.

En banca y seguros, la clasificación de un caso dependerá de la finalidad del sistema. Un asistente interno para resumir políticas no tiene el mismo perfil que una herramienta que influye en decisiones de crédito, selección de clientes, evaluación de riesgos o acceso a servicios esenciales. El uso defensivo de IA para detectar intrusiones tampoco queda automáticamente convertido en un sistema de alto riesgo por el mero hecho de utilizar un modelo avanzado.

La relación con el informe de Anthropic está en otro punto: el AI Act no sustituye a los controles de ciberseguridad. Aunque el proveedor ofrezca documentación de seguridad, la entidad debe gobernar los permisos, las instrucciones, los datos y la intervención humana en su propio entorno. Un modelo puede cumplir sus obligaciones y seguir estando mal integrado por el cliente.

CRA, NIST CSF 2.0 y los perímetros que se solapan

El Cyber Resilience Act introduce requisitos de ciberseguridad para productos con elementos digitales. Su relevancia crece cuando las entidades compran aplicaciones, dispositivos, agentes o componentes que incorporan capacidades de IA. El artículo 13 establece obligaciones para fabricantes, importadores y distribuidores; el artículo 14 regula la notificación de vulnerabilidades explotadas activamente e incidentes graves, con obligaciones y plazos que deben coordinarse con los desarrollos de aplicación.

La pregunta para compras no es únicamente si el producto “usa IA”. Hay que preguntar si permite ejecutar acciones, si integra componentes de terceros, cómo recibe actualizaciones, qué ocurre cuando termina el soporte y cómo se notifican vulnerabilidades explotadas. Un producto con una interfaz conversacional puede tener un riesgo operativo mayor que una aplicación tradicional si dispone de acceso de escritura a sistemas críticos.

NIST CSF 2.0 ofrece una forma práctica de ordenar la respuesta sin confundir marco de referencia con obligación legal. Govern debe asignar responsabilidades y apetito de riesgo; Identify debe inventariar modelos, agentes, datos e integraciones; Protect debe limitar permisos y proteger secretos; Detect debe correlacionar secuencias de uso; Respond debe contener y preservar evidencias; Recover debe restaurar servicios y revisar qué automatizaciones quedan deshabilitadas.

EIDAS 2.0, CSRD y HIPAA entran en juego de forma más condicionada. eIDAS 2.0 es relevante cuando la IA interviene en identidad digital, credenciales o servicios de confianza; no convierte cualquier chatbot en una infraestructura de identidad. CSRD puede hacer visible la gobernanza de riesgos digitales y tecnológicos en la información corporativa de sostenibilidad, pero no reemplaza un control de seguridad. HIPAA importa para grupos multinacionales que procesan información sanitaria protegida; sus obligaciones de salvaguardas y notificación deben coordinarse con GDPR, no confundirse con él.

Riesgos concretos para banca y seguros

El primer riesgo es el acceso a datos. Un asistente conectado a expedientes de clientes puede ser inducido a revelar información, indexar documentos que no debería consultar o combinar datos de varios perímetros. En una aseguradora, el problema puede afectar historiales médicos, partes de siniestros, datos financieros y modelos de tarificación. La IA no necesita “robar” una base de datos completa para crear un incidente grave; basta con devolver información a un usuario que no debía verla.

El segundo es la ejecución. Un agente que puede crear beneficiarios, modificar límites, generar pagos, abrir reclamaciones o cambiar reglas de detección necesita segregación de funciones y confirmaciones independientes. La aprobación humana debe ser significativa. Si la persona solo valida cientos de recomendaciones generadas por segundo, el control es decorativo.

El tercero es la dependencia de un proveedor. Una interrupción del servicio, un cambio de modelo, una modificación de límites de uso o una actualización que altere el comportamiento puede afectar procesos regulados. El artículo 12 de DORA sobre políticas y procedimientos de backup resulta especialmente relevante cuando el servicio de IA no puede reconstruirse internamente. Una copia de datos no equivale a una alternativa funcional si la entidad ha perdido el modelo, las instrucciones, la configuración o los conectores.

El cuarto es el fraude. La IA puede mejorar la creación de identidades sintéticas, conversaciones de ingeniería social, documentos falsificados y redes de perfiles. Los controles antifraude deben observar la coherencia temporal y contextual, no solo la gramática o la calidad visual. El hecho de que un mensaje parezca perfecto ya no aporta mucha información.

El quinto es el riesgo de modelo. Un sistema puede clasificar mal un evento de seguridad, priorizar una falsa amenaza o no reconocer una campaña porque el atacante utiliza herramientas legítimas. La validación debe incluir escenarios adversariales, cambios de distribución y degradación del rendimiento. No basta con medir precisión en un conjunto de prueba estático.

Qué controles deberían cambiar ya

El primer control es un inventario de capacidades, no solo de proveedores. Debe registrar modelos, versiones, cuentas, aplicaciones, agentes, conectores, repositorios, fuentes de datos y permisos de ejecución. El propietario del servicio debe ser identificable. Si nadie sabe quién puede revocar una clave API durante un incidente, la organización no controla el servicio.

El segundo es la gestión de secretos. Las claves deben estar en un gestor centralizado, tener alcance limitado, rotación, expiración y trazabilidad. No deben viajar en repositorios de código ni compartirse entre entornos. La autenticación de agentes debe separar identidad humana y no humana. Una cuenta de servicio que puede leer datos de clientes y ejecutar acciones administrativas necesita controles equivalentes a una identidad privilegiada.

El tercero es el control de herramientas. Cada integración debe declarar qué operaciones permite, sobre qué datos y con qué nivel de autorización. Las operaciones de lectura y escritura no deben recibir el mismo tratamiento. Para pagos, cambios de beneficiarios, borrados, cambios de configuración o exportaciones masivas, la entidad debe exigir confirmación independiente, límites de volumen y registro inalterable.

El cuarto es la segmentación de datos. Los datos de producción, pruebas y entrenamiento deben separarse. Las instrucciones del sistema, los documentos recuperados y la entrada del usuario deben tratarse como fuentes con distintos niveles de confianza. Un documento almacenado en una base de conocimiento no debe poder cambiar silenciosamente las reglas de autorización de un agente.

El quinto es la detección de comportamiento. Las reglas deben buscar consultas anómalas, acceso transversal a clientes, uso simultáneo de varias herramientas, generación y ejecución de código, extracción en lotes, cambios de estrategia y actividad fuera de horario. Los indicadores de compromiso publicados por Anthropic pueden incorporarse a los sistemas de detección, pero no sustituyen al análisis de conducta. Los IOC envejecen; las capacidades permanecen.

El sexto es la respuesta. Hay que probar una contención que incluya revocar credenciales del modelo, desconectar herramientas, conservar registros, congelar cambios y cambiar a procedimientos manuales. El ejercicio debe incluir al proveedor. DORA exige pruebas de resiliencia digital en su capítulo IV y, para determinadas entidades, pruebas avanzadas con penetración basada en amenazas conforme a los artículos 26 a 27. Una prueba que solo comprueba si el modelo responde no examina el riesgo real.

Qué debe exigir compliance a proveedores y equipos internos

Compliance debería abandonar los cuestionarios que preguntan si el proveedor “cumple con la IA responsable” y pedir evidencias operativas. Entre ellas: inventario de subencargados y subcontratistas, ubicación y segregación de datos, retención de prompts y salidas, control de versiones, gestión de vulnerabilidades, procedimiento de incidentes, registros de acceso, pruebas de recuperación y mecanismo de terminación.

También debe exigir claridad sobre el uso de datos del cliente para entrenamiento o mejora del servicio. La respuesta contractual debe distinguir entre datos de entrada, metadatos, logs, salidas y telemetría de seguridad. Cada categoría puede tener una finalidad, una retención y una base jurídica distinta.

Para los sistemas conectados a funciones críticas, el contrato debería definir umbrales de notificación, contenido mínimo y cooperación forense. “Notificar un incidente” no significa enviar un correo de tres líneas. La entidad necesita saber qué modelos, cuentas, regiones, datos, herramientas y clientes han podido verse afectados, además de qué medidas de contención se han aplicado.

Los equipos internos deben aplicar el mismo rigor a las herramientas adquiridas por departamentos. Muchas exposiciones no nacen en el proyecto tecnológico central, sino en una extensión instalada por operaciones, marketing, recursos humanos o un equipo de desarrollo que conecta un servicio externo a un repositorio corporativo. La política debe permitir experimentar, pero no confundir experimentación con acceso ilimitado.

La evidencia que demostrará si el control existe

Cuando llegue una auditoría o una inspección, la entidad no podrá demostrar control enseñando una política de dos páginas. Necesitará evidencias que conecten riesgo, decisión y operación.

La primera evidencia es el inventario actualizado, con propietario, finalidad, clasificación de riesgo, datos tratados, permisos y dependencia contractual. La segunda es el registro de autorizaciones y revisiones periódicas. La tercera son los logs de uso y las pruebas de que se detectan llamadas anómalas. La cuarta son los resultados de ejercicios de respuesta: cuánto tardó la entidad en revocar el acceso, aislar el agente y activar el procedimiento alternativo. La quinta es la documentación de cambios de modelo y de evaluaciones posteriores.

En privacidad, habrá que conservar el razonamiento sobre minimización, retención, evaluación de impacto cuando proceda y gestión de derechos. En DORA, la evidencia debe enlazar el servicio con el marco de riesgo ICT, la evaluación del tercero, las cláusulas contractuales, las pruebas y el reporte de incidentes. En NIST CSF 2.0, el valor está en mostrar cómo las funciones Govern, Identify, Protect, Detect, Respond y Recover se traducen en controles verificables, no en pegar sus nombres en una presentación.

Un auditor también preguntará algo menos técnico y más incómodo: quién puede detener el sistema. La respuesta debe incluir un nombre, una función, un procedimiento y una prueba. “El proveedor lo gestiona” no es una respuesta suficiente para una entidad responsable ante su supervisor, sus clientes y sus accionistas.

La perspectiva que falta: los indicadores de riesgo

Las métricas tradicionales pueden dar una imagen engañosa. Contar el número de modelos aprobados no revela cuántos agentes tienen acceso de escritura. Medir el porcentaje de empleados formados no dice cuántas claves carecen de propietario. Registrar el número de incidentes notificados no muestra cuántos eventos fueron descartados porque el SOC no pudo unir las señales.

Las entidades deberían seguir indicadores más cercanos al riesgo: porcentaje de integraciones con inventario de permisos; porcentaje de claves API con propietario y fecha de expiración; tiempo medio para revocar el acceso de un agente; número de servicios que pueden operar sobre datos de varias clasificaciones; cobertura de logs de prompts y herramientas; porcentaje de proveedores con procedimiento probado de notificación; y número de procesos críticos con alternativa manual probada.

No se trata de convertir la gobernanza de IA en otra colección de indicadores cosméticos. Cada métrica debe responder a una pregunta de control. ¿Podemos saber qué hizo el agente? ¿Podemos impedir que repita la acción? ¿Podemos demostrar qué datos consultó? ¿Podemos continuar el proceso si el proveedor desaparece durante cuatro horas? Si la respuesta es no, el porcentaje de cumplimiento sirve de poco.

Conclusión: vigilar la cadena, no solo el modelo

El informe de Anthropic no demuestra que todos los ataques vayan a ser autónomos ni que los modelos sustituyan a los operadores humanos. Demuestra algo más útil: la IA ya se está incorporando a operaciones que combinan reconocimiento, desarrollo, procesamiento y coordinación. La ventaja no tiene que aparecer en un exploit espectacular. Puede aparecer en la velocidad con la que se repite una campaña y en la cantidad de objetivos que un grupo puede gestionar.

La respuesta regulatoria tampoco será una nueva casilla llamada “IA segura”. DORA exigirá gobernar el riesgo ICT y los terceros; GDPR obligará a equilibrar trazabilidad y minimización; NIS2 presionará sobre la cadena de suministro y los plazos de notificación; AI Act exigirá gestión de riesgos, alfabetización y supervisión cuando corresponda; CRA elevará las exigencias sobre productos digitales; NIST CSF 2.0 ofrecerá una estructura para convertir todo ello en controles.

El punto de convergencia es operativo: inventario, identidad, permisos, telemetría, segmentación, respuesta y recuperación. El banco o la aseguradora que solo prohíba herramientas de IA en los equipos de trabajo tendrá una falsa sensación de control. El uso malicioso no necesita pasar por la aplicación oficial aprobada. Puede llegar a través de una cuenta comprometida, un proveedor, una integración olvidada o una herramienta con acceso excesivo.

La pregunta que debería quedar en la agenda del comité de riesgos es concreta: si mañana un agente comprometido empieza a coordinar acciones contra nuestros sistemas, ¿podemos detectar la secuencia, cortar sus permisos y demostrar después qué ocurrió? Si la respuesta depende de llamar al proveedor y esperar un informe, la entidad no tiene todavía resiliencia frente a la IA. Tiene esperanza. Y la esperanza sigue sin ser un control compensatorio.