La IA sin barreras ya ha roto el guion de la ciberseguridad

La ciberseguridad lleva años obsesionada con el malware sofisticado, los zero-days y las APT con nombre de animal mitológico. Mientras tanto, buena parte del daño real sigue entrando por la puerta de siempre: un correo creíble, una suplantación bien escrita, un proveedor con acceso excesivo o un proceso interno que nadie revisó porque “siempre se ha hecho así”. La novedad no es que eso exista. La novedad es que la automatización y las herramientas generativas reducen fricción, amplían escala y hacen más barata la ejecución de campañas oportunistas. No hace falta convertir esa intuición en profecía tecnológica para entender el problema. Basta con mirar dónde chocan las obligaciones regulatorias con la realidad operativa.

Ese choque importa porque muchas organizaciones siguen enfocando la conversación sobre IA y ciberseguridad como si el único riesgo serio fuera el modelo fundacional de última hornada. No lo es. El riesgo inmediato, para la mayoría, aparece cuando capacidades relativamente accesibles se combinan con fallos muy corrientes: inventarios incompletos, autenticación débil, segmentación pobre, monitorización irregular, formación ritualista y una gestión de terceros que solo funciona en PowerPoint. Ahí es donde las normas europeas dejan de ser retórica y se convierten en algo más incómodo: una lista de deberes que ya no admite excusas elegantes.

Si tu organización opera en sectores regulados, el mensaje de fondo es simple. No necesitas demostrar que un atacante ha usado “IA de frontera” para quedar expuesto. Te basta con no haber hecho lo básico que exige el marco aplicable cuando las campañas de fraude, suplantación o abuso de credenciales ganan velocidad y variedad. Y aquí está el detalle incómodo: varias normas clave no te piden adivinar la próxima técnica de moda; te piden gobernar, detectar, responder, documentar y aprender. Parece menos glamuroso. También es lo que luego mira el supervisor.

El verdadero cambio no es mágico: es económico y operativo

Conviene pinchar una burbuja retórica. Cuando se habla de IA aplicada al cibercrimen, la tentación habitual es exagerar su novedad y describir una ruptura total. No hace falta. El argumento sólido es bastante más terrenal: determinadas herramientas facilitan tareas que ya formaban parte del ciclo de ataque, sobre todo en la fase previa al compromiso o en el fraude apoyado en interacción humana. Redactar mejor, adaptar mensajes, mantener coherencia tonal, producir variantes y acelerar iteraciones reduce costes operativos para quien ataca. Esa conclusión puede formularse con prudencia sin inventar métricas milagrosas.

La consecuencia práctica es seria aunque menos cinematográfica. Si antes una campaña de suplantación caía por errores ortográficos, referencias culturales absurdas o una mala traducción, ahora ese filtro pierde valor. Si antes la personalización exigía más tiempo por objetivo, ahora el esfuerzo marginal puede bajar. Si antes una plantilla servía para un país y fracasaba en otro, ahora la localización lingüística resulta más sencilla. No hace falta afirmar un porcentaje exacto de mejora para aceptar que el trabajo del defensor empeora cuando la señal de alerta humana se difumina.

Eso afecta de forma especial a tres terrenos muy conocidos por compliance y seguridad. El primero es el BEC, donde la credibilidad del lenguaje, el tono ejecutivo y el contexto interno pesan más que el malware. El segundo es el robo de credenciales a través de páginas o flujos de autenticación falsos que se benefician de mensajes mejor construidos. El tercero es el pretexting por chat, correo o canales híbridos de atención al cliente, donde la consistencia narrativa importa más de lo que muchos comités de riesgo quisieran admitir. Ninguno de estos vectores nació con la IA. Lo que cambia es la facilidad de producción y ajuste.

Por eso el debate útil no debería ser si “la IA lo cambia todo”, frase que suele sonar grandilocuente y aporta poco. La pregunta de verdad es otra: ¿qué controles dependen todavía de señales humanas débiles, de procesos manuales lentos o de supuestos que ya no aguantan bien la automatización? Si la respuesta incluye aprobación de pagos por correo, restablecimientos de acceso sin verificación robusta, privilegios acumulados de terceros o playbooks de incidente pensados para amenazas más lentas, ya tienes un problema regulatorio antes incluso de tener uno forense.

NIS2 no habla de modelos fundacionales. Habla de gobernanza, higiene y responsabilidad

Una de las trampas más comunes consiste en presentar NIS2 como si fuera una norma “sobre ciber” en abstracto y, acto seguido, derivar hacia futurismo. El texto va por otro lado. La Directiva (UE) 2022/2555 centra su núcleo operativo en medidas de gestión de riesgos y en responsabilidad de la alta dirección. El artículo 21 exige a las entidades esenciales e importantes adoptar medidas técnicas, operativas y organizativas apropiadas y proporcionadas para gestionar los riesgos que amenazan la seguridad de las redes y sistemas de información. No dice “instale una herramienta mágica de IA”. Dice algo bastante menos exótico y bastante más exigible.

Ese mismo artículo 21 enumera ámbitos muy concretos: políticas de análisis de riesgos y seguridad de sistemas de información; gestión de incidentes; continuidad de negocio, copia de seguridad y recuperación en caso de desastre; seguridad de la cadena de suministro, incluida la relación con proveedores y prestadores de servicios; seguridad en la adquisición, desarrollo y mantenimiento de redes y sistemas, incluida la gestión y divulgación de vulnerabilidades; políticas y procedimientos para evaluar la eficacia de las medidas de gestión del riesgo; prácticas básicas de ciberhigiene y formación; políticas y procedimientos relativos al uso de criptografía y, cuando proceda, cifrado; seguridad de recursos humanos, control de acceso y gestión de activos; y autenticación multifactor o continua, comunicaciones seguras y sistemas seguros de comunicación de emergencia cuando proceda.

Aquí está el quid. Casi todos esos bloques se vuelven más relevantes cuando aumenta la facilidad para ejecutar campañas de ingeniería social o abuso de identidad. No porque NIS2 regule la IA ofensiva como tal, sino porque sí regula la obligación de tener defensas y gobierno adecuados frente a riesgos plausibles. La norma no necesita nombrar cada táctica emergente para ser aplicable. Le basta con exigir medidas apropiadas, trazables y revisables.

Además, NIS2 endurece algo que durante años se trató como un deporte corporativo de evasión elegante: la responsabilidad de la dirección. El artículo 20 obliga a los órganos de dirección a aprobar y supervisar las medidas de gestión del riesgo de ciberseguridad y a seguir formación. Traducido a lenguaje menos ceremonial: el consejo ya no puede fingir que esto vive en un sótano técnico. Si el fraude por suplantación, la dependencia de terceros o la mala gestión de accesos generan exposición material, la conversación deja de ser “de IT”. Pasa a ser una cuestión de supervisión, presupuesto, apetito de riesgo y rendición de cuentas.

También importan las obligaciones de notificación. El artículo 23 establece un esquema escalonado: alerta temprana en 24 horas, notificación de incidente en 72 horas y un informe final en el plazo de un mes, salvo ajustes de la autoridad competente o el CSIRT. No todas las campañas de fraude o phishing acabarán encajando en el umbral de “incidente significativo”, pero si la organización no sabe detectar, escalar y clasificar con criterio, se arriesga a fallar en algo más embarazoso que el titular: incumplir plazos regulatorios por simple desorden interno.

DORA tampoco te pide adivinar el futuro. Te pide controlar el riesgo TIC de forma seria

En el sector financiero, la tentación de adornar DORA con grandes declaraciones tecnológicas también distrae de lo esencial. El Reglamento (UE) 2022/2554 no está escrito para premiar presentaciones brillantes. Está escrito para obligar a las entidades financieras a organizar la resiliencia operativa digital de una manera que resista supervisión, incidente y auditoría. Su arquitectura es clara: gestión del riesgo TIC, notificación de incidentes, pruebas de resiliencia operativa, gestión del riesgo de terceros prestadores de servicios TIC e intercambio de información en ciertos supuestos.

Si uno quiere una base jurídica concreta, no hace falta improvisar resúmenes dudosos. El artículo 5 obliga a disponer de un marco interno de gobernanza y control que garantice una gestión eficaz y prudente del riesgo TIC. El artículo 6 exige un marco sólido, exhaustivo y bien documentado de gestión del riesgo TIC como parte del sistema general de gestión del riesgo, con mecanismos que permitan abordar de manera rápida, eficiente y completa dicho riesgo y asegurar un alto nivel de resiliencia operativa digital. A partir de ahí, el capítulo II desglosa elementos sobre identificación, protección y prevención, detección, respuesta y recuperación, aprendizaje y evolución, y comunicación. Eso basta para entender por qué el fenómeno de la automatización ofensiva no es una curiosidad académica para compliance financiero.

La razón es operativa. Cuando aumenta la facilidad para generar intentos de suplantación convincentes o para adaptar campañas a procesos concretos de una entidad, el valor de DORA aparece justo en lo que muchas organizaciones tratan como burocracia: inventario de activos, clasificación de funciones, registros, capacidades de monitorización, planes de respuesta, restauración, comunicación interna y externa, y aprendizaje posterior al incidente. Si esas piezas están flojas, el problema no será si el atacante usó o no una herramienta generativa. El problema será que la entidad no puede demostrar resiliencia.

Hay otro punto donde DORA se vuelve especialmente incómodo: terceros TIC. El artículo 28 exige gestionar el riesgo derivado de terceros prestadores de servicios TIC como parte integrante del marco de gestión del riesgo TIC. Los artículos siguientes bajan al detalle contractual y de supervisión. Esto importa mucho porque la exposición a fraude, acceso indebido o fallos de seguridad rara vez termina en el perímetro propio. Un proveedor con acceso privilegiado, un servicio externalizado de atención, un integrador con credenciales permanentes o un SaaS mal gobernado pueden amplificar cualquier campaña de engaño o abuso. Y DORA no compra la excusa clásica de “el proveedor falló”. Si la dependencia era crítica y la gestión contractual o de supervisión era insuficiente, la pregunta vuelve a tu entidad.

El régimen de notificación también merece atención. DORA dedica el capítulo III a la gestión, clasificación y notificación de incidentes relacionados con las TIC. El núcleo no es solo reportar; es clasificar con criterios consistentes y mantener procesos que permitan escalado rápido y documentación utilizable. Quien todavía trate la respuesta a incidentes como un conjunto de correos sueltos, chats dispersos y memoria heroica del equipo técnico, va tarde.

GDPR entra por una puerta menos obvia: identidad, acceso y brechas de datos

Cuando se mezcla IA, fraude y ciberseguridad, GDPR suele aparecer tarde en la conversación, casi como invitado secundario. Error. Si una campaña de suplantación conduce a acceso no autorizado, exfiltración de datos personales o alteración de información, el Reglamento (UE) 2016/679 se vuelve central muy deprisa. El artículo 32 exige medidas técnicas y organizativas apropiadas para garantizar un nivel de seguridad adecuado al riesgo, incluyendo, entre otras, seudonimización y cifrado cuando proceda, capacidad de garantizar confidencialidad, integridad, disponibilidad y resiliencia permanentes de los sistemas y servicios, capacidad de restaurar la disponibilidad y el acceso de forma rápida en caso de incidente físico o técnico, y un proceso de verificación, evaluación y valoración regulares de la eficacia de las medidas.

No hace falta forzar la interpretación para ver la conexión. Si las técnicas de engaño se vuelven más persuasivas o más escalables, eso afecta a la evaluación del riesgo y, por tanto, a la adecuación de las medidas del artículo 32. No porque el GDPR mencione la IA ofensiva, sino porque sí exige que la seguridad sea proporcional al riesgo real del tratamiento. Una organización que sabe que sus procesos críticos descansan en correo electrónico, atención distribuida, proveedores externos o identidades privilegiadas debería revisar controles con esa realidad en mente. Si no lo hace, luego cuesta sostener que el nivel de seguridad era “adecuado”.

Después llega el artículo 33: notificación de violaciones de seguridad de los datos personales a la autoridad de control sin dilación indebida y, de ser posible, a más tardar 72 horas después de haber tenido constancia de ellas, salvo que sea improbable que la violación constituya un riesgo para los derechos y libertades de las personas físicas. El artículo 34 añade la comunicación a los interesados cuando sea probable que la violación entrañe un alto riesgo. Otra vez, la calidad del gobierno interno decide casi todo. Sin trazabilidad, sin clasificación y sin coordinación entre seguridad, legal, privacidad y negocio, esas 72 horas se convierten en una invitación al caos.

Hay una ironía regulatoria aquí. Muchas empresas invierten mucho tiempo en debatir si un sistema concreto encaja en una categoría sofisticada del AI Act, pero siguen sin tener resuelto algo bastante más inmediato: quién puede ordenar un cambio bancario, cómo se valida una solicitud sensible, qué registros conserva el service desk, o qué proveedor mantiene acceso remoto persistente a datos personales. La ley avanzada siempre llama la atención. El fallo banal es el que termina en expediente.

NIST CSF 2.0 no es una ley, pero sí desmonta una coartada habitual

Conviene ser precisos: NIST CSF 2.0 no impone obligaciones legales generales en Europa. No es un reglamento de la UE ni una directiva. Pero citarlo no es irrelevante si se hace bien. Su utilidad está en otra parte: ofrece un lenguaje operativo maduro para gobernanza, identificación, protección, detección, respuesta y recuperación que muchas organizaciones usan para estructurar controles, medir madurez y traducir riesgo técnico a decisión ejecutiva. En esta conversación, su valor no es coercitivo, sino metodológico.

La versión 2.0 refuerza, además, la función Govern, que no estaba explícitamente destacada como función separada en la versión 1.1. Ese cambio no es cosmético. Subraya que la ciberseguridad no es solo una colección de controles; es una disciplina de dirección, priorización y supervisión. Y eso conecta de forma bastante limpia con el endurecimiento europeo en materia de responsabilidad del órgano de administración bajo NIS2 y con la lógica de gobernanza que atraviesa DORA.

Usado con sensatez, NIST CSF 2.0 sirve para algo muy concreto en organizaciones sometidas a varias normas a la vez: ordenar capacidades sin convertir el programa en una feria de siglas. Si tu equipo de seguridad habla en controles, privacidad en bases jurídicas, continuidad en RTO/RPO, compras en anexos contractuales y el consejo en exposición financiera, necesitas una taxonomía común. El framework puede ayudar. Lo que no conviene es invocarlo como si, por sí solo, “exigiera” algo al mismo nivel que un reglamento vinculante. No lo hace. La exigencia vendrá de la norma sectorial, del regulador, del contrato o del deber de diligencia interno.

La cadena de suministro es donde la retórica tecnológica se estrella con el Excel

Si hubiera que elegir un punto donde casi todas las grandes normas se dan la mano, sería este: terceros. NIS2 mete la seguridad de la cadena de suministro en el artículo 21. DORA dedica un bloque entero a terceros prestadores de servicios TIC desde el artículo 28. GDPR obliga a escoger encargados con garantías suficientes y a regular la relación en el artículo 28 del Reglamento. Tres marcos distintos, tres lógicas distintas, un mismo dolor de cabeza práctico.

La razón es sencilla. Muchas campañas exitosas no necesitan vulnerar directamente el corazón tecnológico de una organización si pueden explotar un acceso delegado, una cuenta compartida, un canal de soporte, una integración API mal gobernada o un proceso de escalado operado por un tercero. Cuando además resulta más fácil generar mensajes convincentes, mantener conversaciones verosímiles o adaptar una historia al lenguaje del proveedor, la superficie de confianza se vuelve más frágil. Eso no convierte a todos los terceros en una bomba de relojería, pero sí vuelve insuficiente la clásica debida diligencia de casilla marcada.

¿Qué falla más a menudo? Cuatro cosas muy poco glamurosas. Primera, inventarios de proveedores incompletos o desactualizados. Segunda, clasificación deficiente de criticidad y de accesos reales. Tercera, contratos que hablan mucho de seguridad “razonable” y muy poco de evidencias, subcontratación, notificación, registro, pruebas o derechos de auditoría. Cuarta, supervisión continua casi inexistente una vez firmado el acuerdo. Luego llega el incidente y todo el mundo descubre que la dependencia crítica no estaba ni bien documentada ni bien ensayada.

DORA, en particular, no deja demasiado margen para esa dejadez elegante. El régimen contractual del artículo 30 y la obligación de contar con una estrategia sobre riesgo de terceros TIC del artículo 28 obligan a aterrizar responsabilidades. No basta con tener un catálogo de proveedores. Hay que saber cuáles sostienen funciones críticas o importantes, qué acceso tienen, qué garantías ofrecen, cómo se monitoriza su desempeño y cómo se sale de ellos sin apagar media operativa. El compliance de escaparate aquí dura poco.

El punto ciego más común: procesos de negocio que siguen confiando demasiado en el lenguaje

Buena parte del discurso sobre ciberseguridad sigue poniendo el foco en infraestructura, endpoints y telemetría. Todo eso importa. Pero cuando el fraude o la intrusión se apoyan en interacción humana, el punto de fallo suele estar en el proceso de negocio. Un correo no roba dinero por ser persuasivo; lo roba porque alguien puede cambiar una cuenta bancaria, aprobar un pago, resetear un acceso, compartir un documento sensible o elevar privilegios con verificaciones flojas. La herramienta de generación de texto no crea esa debilidad. Solo la explota mejor.

Desde una perspectiva regulatoria, esto tiene una consecuencia práctica potente. El control no puede vivir solo en el SOC ni en la función de seguridad. Debe incrustarse en finanzas, operaciones, atención al cliente, RR. HH., compras y soporte. NIS2 artículo 21 habla de ciberhigiene, control de acceso, autenticación multifactor y seguridad de recursos humanos. GDPR artículo 32 habla de medidas apropiadas y verificación regular. DORA artículo 6 exige un marco documentado e integrado de gestión del riesgo TIC. Todos apuntan, desde ángulos distintos, a la misma idea: el riesgo se gestiona en el proceso, no solo en la alerta.

Eso obliga a revisar con lupa ciertos flujos, especialmente los que combinan urgencia, autoridad y cambio de datos. Pagos extraordinarios, modificación de IBAN, altas de proveedor, recuperación de cuentas privilegiadas, acceso remoto de soporte, exportaciones de datos, instrucciones ejecutivas fuera de canal, validación de identidad en contact centers. Si tu control depende demasiado de que un empleado “note algo raro” en el lenguaje, la organización ya está apostando a una señal cada vez menos fiable.

Qué sí se puede afirmar con solidez regulatoria

Hay una forma rigurosa de hablar de este fenómeno sin inflarlo. No hace falta asegurar que todas las campañas serán más eficaces ni poner cronómetros inventados al trabajo del atacante. Lo que sí puede sostenerse es algo más útil para el lector y más resistente al verificador de hechos: cuando las barreras de producción de contenido persuasivo bajan, aumenta la presión sobre controles de identidad, validación, segregación de funciones, monitorización y respuesta. Y esos controles no son opcionales en muchos sectores regulados.

También puede afirmarse, con base normativa clara, que la dirección ya no puede tratar estas exposiciones como una materia puramente técnica. NIS2 artículo 20 coloca al órgano de dirección dentro de la ecuación de aprobación y supervisión. DORA artículo 5 hace lo propio al exigir un marco interno de gobernanza y control para la gestión del riesgo TIC. GDPR artículo 24 obliga al responsable del tratamiento a aplicar medidas técnicas y organizativas apropiadas y a poder demostrar que el tratamiento es conforme con el Reglamento. Tres textos, un mismo mensaje: la gobernanza tiene que bajar a tierra.

Y hay otra afirmación perfectamente defendible: la velocidad regulatoria de notificación no perdona la desorganización. NIS2 artículo 23, GDPR artículo 33 y el régimen de incidentes de DORA presuponen capacidades reales de detección, clasificación, escalado y documentación. Quien no tenga claro qué constituye un incidente, qué equipo decide, qué datos se recogen y qué canal activa la comunicación regulatoria, está dejando el cumplimiento en manos de la improvisación. Mala idea en cualquier circunstancia. Peor todavía cuando los vectores de engaño se diversifican.

La objeción clásica: “esto es más concienciación que regulación”

La frase suena razonable hasta que uno mira el detalle. Sí, una parte del problema se combate con formación y concienciación. NIS2 lo reconoce expresamente en el artículo 21 al incluir prácticas básicas de ciberhigiene y formación. Pero reducir el debate a awareness es una forma bastante eficiente de no tocar los controles incómodos. La regulación no se agota en pedir a la gente que sospeche. Pide gestión de incidentes, continuidad, cadena de suministro, control de acceso, autenticación robusta, supervisión de la eficacia y gobierno de dirección.

La experiencia de mercado lo confirma de manera bastante menos noble que los folletos corporativos. Los programas basados casi exclusivamente en simulaciones de phishing y cursos anuales generan métricas presentables, pero no corrigen por sí solos la aprobación débil de pagos, la proliferación de privilegios, las excepciones eternas de MFA, el acceso remoto opaco de terceros o la ausencia de doble validación fuera de banda. Dicho de otro modo: formar ayuda; rediseñar el proceso protege.

Además, la objeción pierde fuerza en financiero. DORA no fue redactada para premiar cultura general de seguridad, sino para exigir resiliencia operativa demostrable. Si una entidad sabe que sus flujos críticos pueden ser objeto de suplantación creíble y aun así mantiene controles blandos porque “tenemos formación”, el supervisor puede preguntarse, con razón, por la proporcionalidad real del marco de gestión del riesgo TIC.

Lo que deberían hacer ahora las organizaciones, sin esperar a la próxima moda semántica

La respuesta sensata no es montar un programa nuevo con etiqueta futurista. Es revisar dónde la organización sigue confiando en supuestos que ya no aguantan bien. Hay cinco frentes que merecen prioridad.

• Primero, procesos de alto impacto. Identifica qué decisiones sensibles pueden activarse por correo, chat, ticket o llamada: pagos, cambios de datos bancarios, restablecimientos de acceso, exportaciones de datos, altas de proveedor, soporte privilegiado. Si la verificación no es robusta y fuera de banda cuando toca, el control es débil aunque el mensaje te parezca “raro”.
• Segundo, identidad y acceso. NIS2 artículo 21 menciona control de acceso y autenticación multifactor o continua cuando proceda. GDPR artículo 32 exige medidas adecuadas al riesgo. DORA integra la protección y prevención dentro del marco de gestión del riesgo TIC. Tradúcelo a decisiones concretas: MFA sin excepciones decorativas, cuentas privilegiadas bajo control estricto, revisión de accesos de terceros y eliminación de credenciales compartidas donde sigan existiendo.
• Tercero, terceros críticos. Revisa inventario, criticidad, accesos, subencargados o subcontratistas, cláusulas de notificación, evidencias de control y planes de salida. Si un proveedor puede tocar funciones críticas o datos sensibles, la diligencia ex ante no basta. Hace falta supervisión viva.
• Cuarto, respuesta y notificación. Ensaya la clasificación de incidentes que mezclan fraude, compromiso de cuentas y datos personales. Muchas organizaciones tropiezan aquí porque seguridad, fraude, legal y privacidad usan taxonomías distintas. El regulador no va a premiar esa descoordinación creativa.
• Quinto, gobierno real. Lleva al comité y al consejo escenarios concretos, no eslóganes sobre IA. Qué proceso puede fallar, qué control lo mitiga, qué dependencia externa existe, qué evidencia falta y qué obligación regulatoria concreta está en juego. Eso sí mueve presupuesto y responsabilidad.

No son medidas exóticas. Precisamente por eso importan. El riesgo serio rara vez entra disfrazado de paper técnico; suele entrar por una excepción tolerada, un flujo heredado o un proveedor demasiado cómodo.

La lección incómoda para compliance: menos fascinación tecnológica, más prueba de control

Hay una pulsión muy humana —y muy corporativa— a perseguir la novedad conceptual porque suena estratégica. “IA ofensiva”, “amenazas emergentes”, “nueva era del fraude”. Todo eso puede tener valor descriptivo, pero no sustituye la pregunta que realmente separa a las organizaciones maduras de las que solo hablan bien en comité: ¿puedes probar que tus controles clave funcionan frente a este tipo de presión?

Prueba, no declaración. Evidencia de doble verificación. Evidencia de revisión de accesos. Evidencia de retirada de privilegios. Evidencia de ejercicios de incidente. Evidencia de cláusulas contractuales útiles. Evidencia de tiempos de escalado internos. Evidencia de coordinación entre seguridad, privacidad, fraude y negocio. Esa es la sustancia que conecta con NIS2, DORA y GDPR. Lo demás corre el riesgo de convertirse en una discusión elegante sobre tecnologías mientras el proceso inseguro sigue intacto.

La ironía final es bastante cruel. Muchas organizaciones temen quedarse atrás por no adoptar suficientemente deprisa herramientas avanzadas de IA para defenderse. Puede ser una preocupación legítima. Pero el regulador, cuando llegue, probablemente empezará por algo bastante menos futurista: quién aprobó el marco, cómo se gestionó el tercero, por qué falló la autenticación, cuándo se detectó el incidente, qué se notificó y qué cambió después. No es una conversación emocionante. Es peor: es la que cuenta.

Conclusión: el problema no es si la IA “cambia las reglas”; el problema es si tus controles ya iban tarde

La tesis más útil no necesita exageración. Las capacidades generativas y de automatización no convierten de repente toda amenaza en invencible ni vuelven obsoleta la regulación existente. Lo que hacen, en muchos casos, es aumentar la presión sobre debilidades de siempre: identidad, procesos, terceros, clasificación de incidentes y gobierno. Y justo ahí es donde NIS2, DORA y GDPR ya contienen obligaciones concretas que no dependen de modas semánticas.

Si diriges seguridad, compliance, privacidad o riesgo operacional, la pregunta no es si debes abrir una línea de trabajo grandilocuente sobre “IA ofensiva”. La pregunta es más seca y más útil: ¿qué control crítico de mi organización descansaba demasiado en señales humanas, validaciones blandas o confianza heredada? ¿Y qué exige, en ese punto exacto, la norma que me aplica?

Empieza por ahí. Porque cuando el incidente llegue, el debate filosófico sobre la frontera entre automatización e inteligencia artificial importará bastante menos que algo mucho más prosaico: si hiciste los deberes que la regulación ya te estaba pidiendo.