El hack a modelos de OpenAI y Anthropic convierte la seguridad de la IA en un problema de consejo, no de laboratorio

La escena regulatoria se está complicando a una velocidad que ya no permite separar con comodidad la seguridad del modelo, la ciberseguridad clásica y el compliance documental. Ese compartimento estanco —el equipo de IA por un lado, seguridad por otro y legal cerrando contratos al final— empieza a parecer una reliquia. Y no por una obsesión académica de Bruselas, sino por algo mucho más incómodo: los modelos avanzados no solo generan texto o código; también pueden amplificar riesgos operativos, de acceso, de suplantación y de control interno que encajan de lleno en marcos ya vigentes.

Ese es el punto que muchas empresas siguen intentando esquivar. Hablan de “gobernanza de IA” como si fuera una capa adicional, casi decorativa, cuando en realidad varias de las obligaciones más serias ya existen bajo DORA, GDPR, NIS2 o incluso bajo marcos de control interno más viejos que la fiebre generativa. El AI Act añade un régimen propio, sí, pero el error práctico consiste en tratarlo como un silo. No lo es.

Si tu organización usa modelos fundacionales, asistentes internos de código, sistemas de automatización documental o agentes con capacidad de interactuar con sistemas corporativos, la pregunta útil no es si “la IA trae nuevos riesgos”. Claro que los trae. La pregunta útil es otra: ¿qué obligaciones actuales se activan cuando un sistema de IA afecta a la confidencialidad, la integridad, la disponibilidad, la trazabilidad o la toma de decisiones? Ahí empieza el trabajo serio.

El problema real: la IA no cae del cielo, cae dentro de sistemas regulados

Buena parte del debate público se atasca en escenarios espectaculares: modelos que engañan, agentes que buscan atajos, automatización de tareas sensibles. Hay motivos para preocuparse, pero conviene separar dos planos. Uno es el de la investigación y la evaluación de capacidades de modelos avanzados. Otro, mucho más prosaico y regulatoriamente explosivo, es el de su despliegue en organizaciones sujetas a obligaciones concretas.

En una entidad financiera europea, por ejemplo, no hace falta demostrar un escenario extremo para que salten las alarmas. Basta con algo más corriente: un sistema con acceso a repositorios internos, un copiloto que redacta respuestas regulatorias sin trazabilidad suficiente, un flujo automatizado que toca datos personales, o un proveedor cloud que integra IA en servicios críticos sin ajustar el contrato ni el mapa de terceros. Eso ya no es una discusión futurista. Eso entra en DORA art. 5 sobre marco de gestión del riesgo ICT, art. 9 sobre identificación y clasificación de funciones y activos, art. 11 sobre detección de actividades anómalas, y art. 28 sobre gestión del riesgo de terceros proveedores de servicios TIC.

Lo mismo ocurre fuera de finanzas. NIS2 art. 21 obliga a adoptar medidas técnicas, operativas y organizativas apropiadas para gestionar riesgos que afecten a la seguridad de redes y sistemas de información. La lista no es precisamente poética: análisis de riesgos, gestión de incidentes, continuidad del negocio, seguridad de la cadena de suministro, políticas de evaluación de la eficacia de las medidas, higiene básica y formación, criptografía cuando proceda, y seguridad de recursos humanos y control de accesos. Si un componente de IA toca cualquiera de esas piezas, deja de ser un experimento simpático del laboratorio.

Y si hay datos personales de por medio, el GDPR no necesita enterarse de que el problema era “de IA” para activarse. Lo que mira es si existe base jurídica, minimización, limitación de finalidad, medidas de seguridad adecuadas y, llegado el caso, notificación de brechas. Ahí están el art. 5, el art. 25 sobre protección de datos desde el diseño y por defecto, el art. 32 sobre seguridad del tratamiento, el art. 33 sobre notificación de violaciones de seguridad a la autoridad y el art. 35 sobre evaluaciones de impacto.

La etiqueta importa menos de lo que creen muchos equipos. A ojos del regulador, un riesgo material sigue siendo un riesgo material aunque venga envuelto en marketing generativo.

Donde se equivocan muchas empresas: confundir safety del modelo con compliance suficiente

Hay un malentendido bastante extendido. Como los desarrolladores de modelos hablan de red teaming, evaluaciones de seguridad, capacidades emergentes o alineamiento, algunas compañías asumen que consumir un modelo de un gran proveedor equivale a heredar una parte relevante del cumplimiento. No funciona así.

Primero, porque la seguridad del modelo y la seguridad del despliegue son cosas distintas. Un proveedor puede imponer límites al modelo, filtrar ciertas salidas o documentar pruebas internas; aun así, tu organización sigue siendo responsable de cómo integra ese sistema en procesos, datos, accesos y decisiones concretas. DORA no te exime porque el contrato lleve una marca conocida. Al revés: DORA art. 28 y siguientes endurecen precisamente la gestión de terceros TIC, con requisitos de estrategia, registro de información, evaluación previa y contenido contractual.

Segundo, porque el AI Act tampoco sustituye al resto del edificio. Aunque la aplicación temporal de sus obligaciones es escalonada, su lógica ya está condicionando compras, diseño de controles y due diligence. Y lo hace con una idea bastante menos glamurosa que los titulares sobre “IA existencial”: el proveedor, el desplegador, el importador y el distribuidor no juegan el mismo papel, y cada uno carga con obligaciones diferentes. Si eres deployer de un sistema de alto riesgo, no te bastará con pedir una ficha comercial y una promesa de “responsible AI”. Necesitarás instrucciones de uso, supervisión humana, calidad de datos en tu propio contexto y controles de registro adecuados. Si además modificas sustancialmente el sistema o su finalidad prevista, el perímetro de responsabilidad puede cambiar de forma nada cómoda.

Tercero, porque la trazabilidad sigue siendo el agujero favorito de casi todos. Los equipos implementan herramientas de IA para ganar velocidad y reducir fricción, pero luego no pueden reconstruir qué prompt activó qué acción, qué datos alimentaron la salida, qué versión del modelo estaba en producción, quién validó el resultado ni qué controles impidieron un acceso indebido o una respuesta incorrecta. Eso no es un detalle. Es exactamente el tipo de carencia que, bajo una inspección seria, convierte un programa de IA “innovador” en una colección cara de riesgos mal documentados.

La lección que sí puede extraerse de las pruebas de seguridad de modelos

Sobre sistemas avanzados de IA circulan a menudo afirmaciones muy concretas acerca de conductas observadas en pruebas de laboratorio o evaluaciones de seguridad. Cuando esas afirmaciones no pueden sostenerse con una fuente verificable, conviene hacer justo lo contrario de lo que suele hacer internet: bajar un cambio. No hace falta inflar un caso concreto para entender la implicación regulatoria.

La conclusión prudente, y suficiente para compliance, es esta: los ejercicios de evaluación de modelos avanzados exploran si un sistema puede producir comportamientos no deseados, buscar atajos, facilitar abuso, manipular flujos o incrementar la capacidad ofensiva de un usuario. Ese riesgo potencial basta para activar preguntas de control. ¿Qué permisos tiene el sistema? ¿Qué barreras técnicas le impiden ejecutar acciones sensibles? ¿Qué evidencias se conservan? ¿Hay revisión humana efectiva o solo una ilusión de supervisión?

Dicho de otro modo: no hace falta acreditar un episodio concreto, con fecha y empresa, para justificar una revisión interna de accesos, segregación de funciones y monitoring. Si tu organización espera a tener un titular perfecto para hacer lo obvio, ya va tarde.

DORA: el reglamento que muchos siguen leyendo como si solo fuera de continuidad tecnológica

DORA se está interpretando a menudo de forma demasiado estrecha, casi como un reglamento de resiliencia TIC centrado en disponibilidad y proveedores cloud. Eso es quedarse con la mitad del mapa.

El art. 5 exige a las entidades financieras un marco interno de gestión del riesgo TIC sólido, exhaustivo y bien documentado. No dice “excepto para sistemas de IA en piloto”. El art. 6 obliga a estrategias, políticas, procedimientos, protocolos y herramientas TIC adecuados. El art. 8 se mete en identificación de fuentes de riesgo. El art. 9 pide identificar y clasificar funciones empresariales, funciones de apoyo, activos de información y dependencias TIC. El art. 10 va a protección y prevención. El art. 11, a detección. El art. 12, a respuesta y recuperación. El art. 13, a copia de seguridad, restauración y métodos de recuperación. No hay ninguna grieta doctrinal por la que colar un agente interno con acceso a sistemas sensibles sin meterlo en este esquema.

Aquí está el quid para IA. Si un modelo participa en una función crítica o importante, o si se integra en un proceso que afecta a operaciones, clientes, reporting o ciberseguridad, entonces debes clasificarlo como parte de tu arquitectura de riesgo. Eso implica al menos cinco trabajos operativos:

• Inventariar el caso de uso, la dependencia técnica y el proveedor implicado.
• Determinar qué datos entran y salen del sistema, con qué base jurídica y con qué controles de minimización.
• Definir permisos, límites de acción y supervisión humana real, no cosmética.
• Configurar registros y evidencias suficientes para auditoría, investigación y respuesta a incidentes.
• Revisar el contrato del proveedor bajo DORA art. 30, incluyendo descripción de funciones y servicios, lugares de tratamiento, disponibilidad, integridad, confidencialidad, acceso, recuperación y derechos de terminación.

El problema es que muchas entidades han hecho algo parecido, pero a medias. Tienen inventario de proveedores; no de capacidades activadas. Tienen evaluación de cloud; no de la función de IA incrustada en el servicio. Tienen política de incidentes; no criterios para decidir cuándo una salida de IA defectuosa pasa de “error operativo” a incidente de seguridad o de cumplimiento.

Eso es lo que suele romperse primero en una inspección: la ficción de que la herramienta era marginal cuando en la práctica ya estaba tocando procesos relevantes.

NIS2: si la IA amplía la superficie de ataque, ya estás dentro del artículo 21

NIS2 tiene una virtud regulatoria poco literaria pero muy útil: obliga a hablar de medidas concretas. El art. 21 no pide entusiasmo; pide gestión de riesgos. Y varios de sus elementos encajan de forma directa con el despliegue de IA.

La seguridad de la cadena de suministro, por ejemplo. Muchas organizaciones consumen modelos, APIs, plugins, repositorios y servicios de ajuste fino de varios terceros a la vez. El resultado es una cadena más opaca de lo que aparenta la pantalla del contrato principal. NIS2 art. 21.2.d obliga a considerar vulnerabilidades específicas de cada proveedor y la calidad global de sus prácticas de ciberseguridad. Si tu herramienta de automatización documental se apoya en un modelo externo, en un proveedor de embeddings, en una base vectorial gestionada y en un repositorio de código de terceros, la superficie contractual y técnica no se reduce al logo que sale en la factura.

También importa el control de accesos. NIS2 art. 21.2.i menciona políticas y procedimientos relativos al uso de criptografía y, cuando proceda, cifrado; el mismo artículo, leído junto con las medidas de higiene, formación y seguridad de recursos humanos, empuja claramente a revisar permisos, autenticación, secretos y segregación. Un asistente de IA con acceso amplio a documentación interna puede convertirse en un problema aunque nunca “ataque” nada. Basta con que facilite exfiltración accidental, agregación indebida de información o ejecución de consultas que nadie habría autorizado a un usuario junior.

Y luego está la gestión de incidentes. Si un componente de IA altera disponibilidad, integridad o confidencialidad, la organización necesita criterios de detección y escalado previos. No durante la crisis. Antes. Porque si el incidente se descubre a través de una salida rara del modelo, ya has perdido tiempo valioso y seguramente contexto forense.

GDPR: el viejo conocido que vuelve cada vez que alguien mete datos en un prompt

El Reglamento General de Protección de Datos tiene una resistencia admirable: reaparece cada vez que un equipo piensa que está discutiendo otra cosa. Pasa con la IA constantemente.

El primer error suele ser de base: asumir que, si el tratamiento se produce en una herramienta corporativa contratada, la cuestión de protección de datos queda resuelta por el DPA del proveedor. No. El art. 5 sigue exigiendo licitud, lealtad, transparencia, minimización y limitación de finalidad. Si empleados introducen datos personales en prompts, documentos o flujos automatizados sin necesidad real o sin instrucciones claras, el problema ya es tuyo antes de que el proveedor responda un correo.

El art. 25 obliga a protección de datos desde el diseño y por defecto. Traducido a operaciones: no deberías desplegar un caso de uso que permita cargar categorías enteras de datos personales si el objetivo puede alcanzarse con datos seudonimizados, sintéticos o reducidos. El art. 32 exige medidas técnicas y organizativas apropiadas. Ahí entran controles de acceso, cifrado cuando proceda, capacidad de garantizar confidencialidad, integridad, disponibilidad y resiliencia, y procesos para verificar la eficacia de las medidas.

Cuando el riesgo sea alto para los derechos y libertades de las personas físicas, el art. 35 sobre evaluación de impacto deja de ser una opción elegante y pasa a ser una obligación. Esto puede ocurrir por volumen, sensibilidad, combinación de fuentes, evaluación sistemática o efectos significativos sobre personas. No todos los casos de IA requieren una EIPD, pero bastantes más de los que admiten los equipos de producto.

Y si hay una violación de seguridad de los datos personales, el reloj corre. El art. 33 fija la notificación 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. La parte incómoda es que, sin logs adecuados y sin claridad sobre qué datos salieron, muchas organizaciones ni siquiera sabrán cuándo han tenido “constancia” suficiente. La IA no complica el artículo; complica tu capacidad de cumplirlo.

AI Act: menos ciencia ficción y más reparto de responsabilidades

El AI Act ha sido presentado demasiadas veces como una gran ley filosófica sobre el futuro. Tiene algo de eso, sí, pero donde realmente va a doler es en lo administrativo y lo operativo. Documentación, gobernanza, transparencia, control humano, calidad de datos, registro, vigilancia post-comercialización, gestión del cambio. Nada glamuroso. Todo exigible.

Para las empresas, la utilidad práctica del reglamento no está solo en identificar si un sistema es de alto riesgo. Está en obligarlas a dejar de comprar IA como si compraran una licencia ofimática. ¿Quién es el proveedor? ¿Quién despliega? ¿Hay modificación sustancial? ¿Se usa conforme a la finalidad prevista? ¿Hay instrucciones suficientes? ¿Existen logs y supervisión humana? ¿Se informa a las personas cuando procede? ¿Qué pasa si el sistema se integra en un proceso ya regulado por otra norma sectorial?

Además, el AI Act no elimina las obligaciones preexistentes. Las duplica en algunos puntos y las aterriza en otros. Si un banco usa IA en onboarding, antifraude, scoring interno, atención al cliente o ciberdefensa, no podrá resolver el expediente con una “política de uso responsable” de doce páginas y una sesión de formación. Tendrá que demostrar trazabilidad, control del proveedor, validación del caso de uso y gobierno interno coherente con DORA, GDPR y, según actividad, otras exigencias sectoriales.

La ironía es bastante evidente: durante años se vendió la IA como una forma de simplificar procesos complejos; regulatoriamente, lo que hace es obligar a documentarlos mejor.

El punto ciego de los agentes: permisos, herramientas y acciones

Una cosa es pedirle a un modelo que resuma un documento. Otra muy distinta es darle herramientas para consultar sistemas, ejecutar acciones, mover información o encadenar tareas. Ahí aparece el verdadero salto de riesgo.

Los agentes y asistentes con capacidad operativa plantean un problema antiguo con una interfaz nueva: ¿qué puede hacer el sistema, con qué credenciales y con qué límites? Desde el punto de vista de control interno, esto se parece menos a “usar IA” y más a desplegar un usuario potente, rápido y opaco. Si además actúa a través de integraciones con tickets, repositorios, CRM, ERP o consolas cloud, el perímetro de revisión debe ser el mismo que aplicarías a cualquier cuenta privilegiada o automatización sensible.

Eso exige controles concretos:

• Principio de mínimo privilegio. Si el sistema solo necesita leer determinada base documental, no debería poder escribir, borrar o invocar otras herramientas.
• Credenciales segregadas. Nada de reutilizar cuentas genéricas de servicio sin trazabilidad individual por caso de uso.
• Aprobación humana previa para acciones de impacto material: cambios de configuración, comunicaciones externas, movimientos de datos, creación de usuarios, modificaciones contractuales o decisiones con efecto sobre clientes.
• Registro completo de prompts, contexto, herramientas invocadas y resultados, con protección frente a manipulación y retención acorde a necesidades legales y forenses.
• Pruebas de abuso orientadas no solo a exactitud, sino a escalado de privilegios, exfiltración, instrucciones indirectas, manipulación del contexto y uso indebido de conectores.

Si esto te suena más a PAM, IAM y control de automatizaciones que a “ética de IA”, vas bien encaminado. Porque el riesgo material suele aparecer ahí, no en los manifiestos.

Terceros TIC: donde DORA y la IA se dan la mano de forma menos amable

El despliegue de IA corporativa está creando una nueva versión del viejo problema de terceros: dependencia técnica profunda sin visibilidad suficiente. Bajo DORA, ese terreno ya no admite mucha improvisación.

El art. 28 obliga a gestionar el riesgo derivado de terceros proveedores de servicios TIC como parte integrante del marco de gestión del riesgo TIC. No como anexo comercial. El art. 29 exige una evaluación previa antes de concluir acuerdos contractuales para el uso de servicios TIC que apoyen funciones críticas o importantes. El art. 30 fija elementos contractuales que deben cubrirse. Y el art. 31 se centra en acuerdos sobre funciones críticas o importantes.

Aplicado a IA, eso significa que la entidad no debería limitarse a preguntar por certificaciones genéricas o por una política pública de seguridad. Tendría que revisar, como mínimo, estas preguntas incómodas:

• ¿Qué subencargados o subprocesadores intervienen en el servicio y para qué funciones concretas?
• ¿Dónde se alojan y tratan prompts, archivos, embeddings, logs y metadatos?
• ¿Se usan datos del cliente para entrenar, ajustar o evaluar modelos, y con qué opt-outs reales?
• ¿Qué garantías ofrece el proveedor sobre segregación lógica entre clientes?
• ¿Qué telemetría y evidencias entregará en caso de incidente?
• ¿Permite auditoría, revisión de controles o al menos acceso a informes suficientemente detallados?
• ¿Qué ocurre al terminar el contrato con los datos, artefactos derivados y registros?

La respuesta habitual del mercado sigue siendo decepcionante: mucho PDF brillante, poca granularidad contractual. Y aquí el regulador no suele aplaudir el esfuerzo estético.

Control interno y SOX: la IA también puede romper reporting sin tocar un firewall

No toda la exposición regulatoria de la IA pasa por ciberseguridad o privacidad. En empresas cotizadas o grupos con controles de reporting exigentes, el problema puede aparecer en algo menos vistoso: la fiabilidad de la información financiera y el control interno asociado.

Si una herramienta de IA interviene en conciliaciones, clasificación documental, apoyo a cierres, elaboración de narrativas financieras, revisión de contratos relevantes o priorización de alertas de cumplimiento, entonces su uso puede afectar al diseño y la eficacia operativa de controles SOX. No hace falta que el sistema “decida” una cifra por sí solo. Basta con que altere evidencias, reduzca revisión efectiva o introduzca una dependencia no documentada.

La pregunta que un auditor interno sensato hará no es si la herramienta ahorra tiempo. Preguntará quién valida la salida, cómo se gestiona el cambio de versión, qué evidencias quedan, qué errores se han observado, cómo se limita el acceso y qué control compensatorio existe si el modelo falla. Si la respuesta es “el usuario aplica criterio profesional”, lo que has dicho en realidad es “no tenemos control diseñado”.

Qué hacer ahora: una hoja de ruta útil y nada heroica

No hace falta reinventar el compliance. Hace falta dejar de tratar la IA como un objeto exótico. La vía práctica consiste en meterla, con nombre y apellidos, dentro de marcos que ya existen y funcionan cuando se aplican en serio.

1. Inventario por caso de uso, no por proveedor

Haz un registro de casos de uso de IA que identifique finalidad, unidad responsable, proveedor, sistemas conectados, datos tratados, decisiones afectadas, nivel de autonomía y criticidad operativa. Si solo tienes una lista de licencias contratadas, no tienes visibilidad real.

2. Clasificación regulatoria cruzada

Para cada caso de uso, cruza cuatro ejes: criticidad para negocio, impacto en datos personales, dependencia de tercero TIC y posible encaje en AI Act. Esto evita que el análisis se quede en un solo departamento. Un asistente de atención al cliente, por ejemplo, puede disparar a la vez obligaciones de privacidad, riesgo operativo, outsourcing tecnológico y transparencia.

3. Controles de acceso y acción

Diferencia entre sistemas que solo generan contenido y sistemas que actúan sobre entornos corporativos. En los segundos, aplica controles equivalentes a automatizaciones privilegiadas: mínimo privilegio, segregación, aprobación, registros, revocación y pruebas periódicas.

4. Revisión contractual de terceros

Si el caso de uso depende de un proveedor TIC, revisa contrato, anejos de tratamiento, subprocesadores, localización, retención, uso secundario de datos, auditoría, soporte en incidentes y salida. Bajo DORA, este trabajo no es burocracia opcional; es parte del control exigible.

5. Criterios de incidente y escalado

Define por adelantado cuándo un fallo o uso indebido de IA se trata como incidente TIC, como brecha de datos, como problema de calidad, como evento de modelo o como combinación de varios. Sin esa taxonomía, el primer incidente serio acabará rebotando entre equipos mientras el reloj regulatorio avanza.

6. Logging y evidencia

Conserva evidencias suficientes para reconstruir entradas, salidas, herramientas invocadas, versión del sistema, validaciones humanas y efectos en procesos aguas abajo. Sin eso, ni auditas, ni investigas, ni notificas con criterio.

7. Evaluación de impacto cuando proceda

Si el caso de uso implica datos sensibles, evaluación sistemática, decisiones con efectos relevantes o combinaciones intensivas de datos, analiza si procede una EIPD bajo GDPR art. 35. Y documenta por qué sí o por qué no. La ausencia total de análisis suele ser peor que una conclusión discutible pero razonada.

La objeción típica: “todavía estamos pilotando”

Es la frase favorita de muchas organizaciones cuando se les pregunta por controles. El problema es que un piloto con datos reales, usuarios reales, integraciones reales y efectos reales deja de ser un piloto en el único sentido que le interesa al regulador.

Si el sistema ya procesa información corporativa, ya influye en decisiones o ya está conectado a herramientas de trabajo, la etiqueta interna importa poco. DORA no contiene una exención emocional para pruebas prometedoras. GDPR tampoco. NIS2, menos aún. Lo que importa es el riesgo efectivo y la medida en que el sistema participa en operaciones, tratamiento de datos o seguridad de redes y sistemas.

La defensa del “pilotaje” solo funciona si el alcance está de verdad limitado: entornos segregados, datos controlados, permisos restringidos, ausencia de impacto operativo y reglas claras de salida. En cualquier otro caso, es más marketing interno que realidad de control.

Mi lectura: el mercado va por detrás, no por falta de normas sino por comodidad organizativa

A estas alturas no faltan marcos regulatorios. Lo que falta es disciplina para aplicarlos de forma integrada. Muchas empresas siguen esperando una norma mágica que les diga exactamente qué hacer con cada modelo, cada plugin y cada agente. No va a llegar así. Lo que ya existe obliga bastante más de lo que algunos quieren admitir.

Mi impresión es que el mayor riesgo no está en un escenario extremo de laboratorio, sino en el despliegue banal y desordenado: herramientas adoptadas por equipos de negocio sin inventario central, proveedores añadidos por procurement con revisión superficial, datos personales volcados en flujos mal entendidos, conectores activados sin análisis de permisos y controles redactados después para que todo parezca razonable en retrospectiva. Ese patrón sí es creíble. Y sí encaja con lo que suelen encontrar auditores y supervisores cuando rascan debajo de la demo.

La buena noticia —si quieres llamarla así— es que no hace falta inventar un sistema de gobierno desde cero. Los artículos relevantes ya están escritos: DORA art. 5 y art. 28 para marco y terceros TIC; NIS2 art. 21 para medidas de gestión del riesgo; GDPR art. 25, 32, 33 y 35 para diseño, seguridad, brechas y evaluación de impacto. El trabajo serio consiste en conectarlos con tus casos de uso reales.

Y ahí se separan dos tipos de organizaciones. Las que siguen tratando la IA como un escaparate de innovación con una política genérica colgada en la intranet. Y las que han entendido que, cuando un sistema puede tocar datos, procesos, accesos o decisiones, deja de ser un juguete y pasa a ser infraestructura regulada. Las primeras aún tienen tiempo. Pero no tanto como creen.