Los agentes de IA ya hackean durante las pruebas: en Europa eso activa algo más serio que un debate ético

El problema de los agentes de IA no es que “piensen”. El problema es bastante menos filosófico y bastante más incómodo: pueden acabar tocando datos, sistemas y procesos que ya están dentro del perímetro de cumplimiento de tu empresa, mientras media organización sigue tratándolos como si fueran una función simpática de productividad.

Ahí empieza el choque regulatorio. No porque exista hoy una ley única para “agentes de IA empresariales”, sino porque su uso puede activar a la vez obligaciones ya vigentes en privacidad, seguridad, resiliencia operativa, gestión de terceros, gobierno interno y trazabilidad. Si un sistema basado en IA accede a datos personales, entra GDPR. Si soporta procesos críticos en una entidad financiera, entra DORA. Si forma parte de medidas de ciberseguridad o afecta a la gestión de riesgos de una entidad esencial o importante, NIS2 deja de ser una lectura teórica. Y si el sistema encaja en la definición y categorías de riesgo del AI Act, aparece otra capa más. La fiesta regulatoria europea nunca desaprovecha una buena complejidad.

La cuestión seria no es si el término “agente” está de moda. Lo está. La cuestión seria es otra: cuando un sistema de IA deja de ser solo una interfaz de consulta y pasa a ejecutar acciones, acceder a entornos corporativos o influir en decisiones operativas, la conversación ya no va de innovación bonita, sino de control interno, base jurídica, minimización de datos, registro de actividades, gestión de proveedores, segregación de permisos y respuesta a incidentes.

Eso obliga a hacer algo que muchas empresas preferirían posponer: dejar de evaluar estas herramientas como si fueran solo software de apoyo genérico y empezar a analizarlas según lo que efectivamente pueden hacer, qué datos tocan, bajo qué permisos operan, qué proveedor las sostiene y qué rastro dejan. O no dejan.

El punto ciego: no importa cómo lo llames, importa qué hace

La etiqueta comercial confunde más de lo que aclara. “Copilot”, “assistant”, “agent”, “workspace AI”, “autonomous workflow”. Cada proveedor vende una promesa distinta, pero para compliance la pregunta relevante es otra y es bastante prosaica: ¿el sistema solo sugiere contenido o también consulta fuentes internas, invoca herramientas, modifica registros, lanza acciones, escala tickets o desencadena flujos posteriores?

Ese matiz cambia casi todo. Un sistema que se limita a generar un borrador con datos no sensibles plantea un perfil jurídico muy distinto de otro que consulta documentación interna, recupera información de clientes, interactúa con aplicaciones corporativas o produce salidas que se integran en decisiones con efecto material. No hace falta exagerar para ver el problema: basta con mirar las obligaciones existentes.

Bajo GDPR, por ejemplo, el análisis no empieza en la palabra “IA”, sino en los principios del artículo 5: licitud, lealtad y transparencia; limitación de la finalidad; minimización de datos; exactitud; limitación del plazo de conservación; integridad y confidencialidad; y responsabilidad proactiva. Si un sistema de IA personaliza respuestas usando datos personales accesibles a través de conectores internos, la empresa debe poder explicar para qué tratamiento usa esos datos, con qué base jurídica y con qué límites. Si además el proveedor utiliza entradas o salidas para entrenar, ajustar o monitorizar el servicio, el examen contractual y técnico se vuelve más delicado.

También entra en juego el artículo 25 de GDPR sobre protección de datos desde el diseño y por defecto. No es una cláusula ornamental. Significa que, antes de desplegar una herramienta con acceso a información corporativa, la organización debería decidir qué categorías de datos puede consultar, qué cuentas o perfiles pueden invocarla, qué retención aplica a prompts y logs, si hay transferencia internacional y qué controles evitan un acceso más amplio del necesario. Si nadie ha hecho ese trabajo y la herramienta ya está integrada en procesos internos, el problema no es la IA: es el gobierno.

Con DORA ocurre algo parecido. El reglamento no menciona “agentes de IA” como categoría autónoma, pero sí establece obligaciones muy concretas sobre gestión del riesgo TIC, clasificación de activos y funciones, resiliencia operativa, respuesta a incidentes y, sobre todo, terceros proveedores de servicios TIC. Los artículos 5 a 16 fijan el marco de gestión del riesgo TIC; los artículos 17 a 23 cubren la gestión, clasificación y notificación de incidentes; y los artículos 28 a 30 aterrizan la disciplina contractual sobre terceros TIC. Si una herramienta de IA soporta un proceso importante o crítico, o depende de un proveedor TIC relevante, no queda fuera del radar por tener una interfaz conversacional pulida.

NIS2 tampoco necesita pronunciar la palabra de moda para resultar aplicable. El artículo 21 exige medidas técnicas, operativas y organizativas adecuadas y proporcionadas para gestionar riesgos de seguridad de redes y sistemas de información. Entre ellas incluye gestión de incidentes, continuidad, seguridad en la cadena de suministro, seguridad en adquisición, desarrollo y mantenimiento, evaluación de la eficacia de medidas y prácticas básicas de ciberhigiene. Si una entidad sujeta a NIS2 incorpora sistemas de IA conectados a su entorno tecnológico, la pregunta regulatoria vuelve a ser funcional: qué riesgo crean, qué dependencia introducen y cómo se controlan.

La trazabilidad no se pierde por arte de magia, pero sí puede degradarse muy deprisa

Conviene ser precisos. No todo sistema al que el mercado llama “agente” opera de la misma manera ni con el mismo grado de autonomía. Algunos solo encadenan instrucciones prediseñadas. Otros pueden invocar herramientas, recuperar contexto de varias fuentes y producir resultados que desencadenan acciones posteriores. En esos casos, el reto de control aumenta porque ya no basta con revisar una salida estática; hay que entender el flujo completo: entrada, contexto recuperado, permisos utilizados, herramienta llamada, resultado generado, validación humana y registro.

Ese punto importa mucho para auditoría interna, seguridad y defensa jurídica. Si no puedes reconstruir qué datos utilizó el sistema, qué instrucciones recibió, qué acción ejecutó y qué intervención humana existió, demostrar cumplimiento se vuelve más difícil. No imposible, pero más difícil. Y la diferencia entre ambas cosas suele aparecer el día del incidente, no el día de la demo.

GDPR vuelve a ofrecer una base muy clara. El principio de responsabilidad del artículo 5.2 obliga al responsable a poder demostrar el cumplimiento de los principios. El artículo 30 exige, en su caso, registros de actividades de tratamiento. El artículo 32 obliga a aplicar medidas técnicas y organizativas apropiadas para garantizar un nivel de seguridad adecuado al riesgo, incluyendo la capacidad de garantizar confidencialidad, integridad, disponibilidad y resiliencia permanentes. Si un sistema de IA introduce una capa adicional entre el usuario y la aplicación o entre el dato y la decisión, la empresa necesita evidencias suficientes para sostener ese deber de demostración.

En el terreno del AI Act, la trazabilidad tampoco es decorativa. Para los sistemas de alto riesgo, el reglamento exige requisitos de registro, documentación técnica, gobernanza de datos, supervisión humana, exactitud, robustez y ciberseguridad. El detalle importa porque el AI Act no se conforma con declaraciones de principios: pide procesos, controles y documentación. Aunque no todo agente empresarial encajará en alto riesgo, el estándar regulatorio europeo apunta en una dirección nítida: si el sistema influye materialmente en resultados relevantes, la opacidad deja de ser una excentricidad técnica y pasa a ser un problema de cumplimiento.

El riesgo no es “nuevo”; la novedad es cómo se combinan las obligaciones

Uno de los errores más comunes al hablar de IA en compliance consiste en presentarla como si hubiera creado una galaxia regulatoria separada. No exactamente. Lo que ocurre, más bien, es que un mismo despliegue puede concentrar exigencias que antes se evaluaban por carriles distintos.

Piensa en un sistema que accede a documentación interna, responde a empleados, consulta información de clientes y se apoya en un proveedor externo para inferencia o procesamiento. Sin necesidad de adornarlo, ahí ya conviven varias capas: acceso a datos personales y potencialmente confidenciales, seguridad del tratamiento, limitación de finalidad, gestión de identidades y permisos, dependencia tecnológica de terceros, logging suficiente para investigación interna y capacidad de suspender o contener el servicio si algo sale mal.

Eso no autoriza a afirmar reglas universales sobre todo “agente de IA”. Sí permite una conclusión más sobria y más útil: cuanto más conectado esté el sistema a datos, aplicaciones o decisiones operativas, más probable es que deje de ser un asunto exclusivo de innovación y pase a ser también un asunto de riesgo operacional, seguridad, privacidad y gobierno corporativo.

DORA ilustra bien esa convergencia. El artículo 6 obliga a las entidades financieras a disponer de un marco interno de gobernanza y control que garantice una gestión eficaz y prudente del riesgo TIC. El artículo 8 exige identificar, clasificar y documentar adecuadamente todas las funciones, roles y activos de información TIC que respalden funciones empresariales y servicios. Si una herramienta de IA soporta una actividad relevante y ni siquiera aparece correctamente inventariada, la entidad ya tiene un problema anterior a cualquier ataque: no sabe bien qué está gobernando.

NIS2 aprieta desde otro ángulo. El artículo 20 atribuye responsabilidad a los órganos de dirección en la aprobación de medidas de gestión del riesgo de ciberseguridad y en la supervisión de su aplicación. El artículo 21 baja al terreno operativo. Traducido al castellano llano: el consejo no puede refugiarse eternamente detrás del “eso lo lleva tecnología” si el sistema abre nuevas dependencias, nuevas superficies de ataque o nuevas rutas de acceso a información sensible.

Terceros, subprocesadores y esa cadena de dependencia que nadie quiere mirar demasiado

La conversación sobre IA suele girar en torno al modelo. El dinero regulatorio, sin embargo, sigue la cadena contractual. Ahí es donde empiezan muchas sorpresas desagradables.

Si un proveedor de IA trata datos personales por cuenta de la empresa, entra el artículo 28 de GDPR: el responsable solo puede recurrir a encargados que ofrezcan garantías suficientes y debe regular la relación mediante contrato u otro acto jurídico vinculante con las cláusulas exigidas por la norma. Si ese proveedor, a su vez, recurre a otros subencargados, el artículo 28.2 y 28.4 obligan a controlar esa cascada. El problema práctico no es teórico: cuanto más compleja sea la prestación, más relevante es saber quién procesa qué, dónde, con qué fines auxiliares, qué logs conserva y qué soporte remoto puede existir.

En entidades financieras sujetas a DORA, el foco es todavía más intenso. El artículo 28 establece principios clave para la gestión del riesgo derivado de terceros proveedores de servicios TIC. El artículo 30 detalla elementos contractuales que deben cubrirse, incluyendo descripción de funciones y servicios, lugares de prestación, disponibilidad, integridad, confidencialidad, acceso, recuperación y retorno de datos, niveles de servicio, asistencia en incidentes, derechos de acceso, inspección y auditoría, y condiciones de terminación. Si el proveedor comercializa una “capa inteligente” sobre servicios propios o ajenos, el departamento de compras no debería quedarse en la presentación comercial: necesita saber qué dependencia real está contratando y con qué capacidad de salida.

Aquí aparece una incomodidad recurrente. En muchos despliegues tecnológicos complejos, el cliente percibe un único servicio visible mientras la prestación se apoya en infraestructura, modelos, APIs, herramientas de observabilidad, almacenamiento o soporte adicional. No hace falta convertir eso en una afirmación absoluta sobre todos los agentes de IA para ver la consecuencia regulatoria: la diligencia sobre terceros ya no puede limitarse a leer la portada del contrato. Hay que mirar la estructura de prestación y las restricciones efectivas de auditoría, portabilidad, suspensión y borrado.

NIS2 vuelve a coincidir. El artículo 21.2.d menciona expresamente la seguridad de la cadena de suministro, incluidas las relaciones entre cada entidad y sus proveedores o prestadores de servicios directos. Nada especialmente glamuroso. Muy importante. Porque una organización puede tener excelentes políticas internas y, aun así, introducir riesgo material si no entiende bien la dependencia técnica y contractual del servicio que incorpora.

Clasificación del sistema: el error empieza cuando compras antes de encuadrar

Antes de discutir controles, conviene resolver una pregunta previa: qué demonios es el sistema desde el punto de vista regulatorio y de control interno. No en el folleto del proveedor; en tu marco de cumplimiento.

Hay al menos cinco clasificaciones que conviene hacer desde el primer día, y ninguna debería delegarse por completo al equipo comercial o al área usuaria.

• Clasificación por datos: ¿trata datos personales, secretos empresariales, información financiera, código fuente, datos de salud, credenciales o documentación regulada?
• Clasificación por criticidad: ¿soporta una función de negocio importante o crítica? En DORA, esta distinción altera la intensidad de obligaciones sobre terceros TIC y resiliencia.
• Clasificación por rol jurídico: ¿el proveedor actúa como encargado del tratamiento, corresponsable, proveedor independiente o combinación de varios roles según la funcionalidad?
• Clasificación por nivel de intervención: ¿solo asiste al usuario, o consulta, transforma, recomienda o desencadena acciones con impacto posterior?
• Clasificación por régimen sectorial: ¿el uso cae dentro de un perímetro adicional como servicios financieros, salud, empleo, infraestructuras críticas o identidad digital?

Sin esa taxonomía, el debate sobre “gobernanza de IA” se convierte en una tertulia abstracta. Con ella, en cambio, ya puedes decidir si hace falta una evaluación de impacto relativa a la protección de datos conforme al artículo 35 de GDPR, si el servicio entra en inventario TIC relevante a efectos de DORA, si requiere una evaluación reforzada de terceros o si debe limitarse a un entorno segregado.

La evaluación de impacto merece un párrafo propio porque se menciona mucho y se usa poco bien. El artículo 35 de GDPR la exige cuando un tipo de tratamiento, en particular si utiliza nuevas tecnologías y teniendo en cuenta su naturaleza, alcance, contexto y fines, es probable que entrañe un alto riesgo para los derechos y libertades de las personas físicas. No toda herramienta de IA obliga automáticamente a realizar una EIPD. Pero si hay tratamiento a escala, combinación de fuentes, posible inferencia sobre personas, evaluación sistemática o uso en decisiones sensibles, descartarla sin análisis documentado es una temeridad regulatoria con traje informal.

Permisos: donde de verdad se decide si el sistema es tolerable o temerario

La mayor parte del riesgo práctico no nace del modelo, sino de los permisos. Qué puede ver, qué puede hacer, desde qué cuenta, con qué segmentación y con qué límites. Parece obvio. Precisamente por eso se subestima con una regularidad deprimente.

Si el sistema opera con privilegios amplios por comodidad de integración, el cumplimiento se deteriora desde el minuto uno. GDPR, en su artículo 25, empuja hacia configuraciones por defecto que limiten el tratamiento al mínimo necesario. El artículo 32 exige seguridad adecuada al riesgo. En términos operativos, eso se traduce en principios bastante poco exóticos: mínimo privilegio, segmentación por casos de uso, separación de entornos, control de credenciales, revisión periódica de accesos, registro de acciones y revocación rápida.

DORA refuerza la idea desde la resiliencia operativa. El artículo 9 obliga a proteger adecuadamente todos los sistemas TIC y a organizar medios para minimizar el impacto del riesgo TIC, incluyendo políticas de seguridad, procedimientos, protocolos y herramientas. Si una entidad despliega una herramienta con acceso sobredimensionado a repositorios, buzones o aplicaciones de negocio, luego no podrá fingir sorpresa si una incidencia obliga a revisar por qué no se aplicaron restricciones ex ante.

La pregunta útil para cualquier comité de riesgos no es “tenemos IA sí o no”, sino algo mucho menos cinematográfico: ¿qué permisos concretos tiene cada caso de uso y quién los ha aprobado? Si no puedes responder en una tabla simple y defendible, todavía no estás gobernando el sistema; estás conviviendo con él.

Supervisión humana: no basta con poner a alguien “en el loop” en una diapositiva

La supervisión humana es una de esas expresiones que sobreviven a casi cualquier presentación ejecutiva. El problema llega cuando se intenta convertir el eslogan en control real.

En el AI Act, la supervisión humana es un requisito explícito para sistemas de alto riesgo. Pero incluso fuera de ese perímetro, la lógica regulatoria es sólida: si una herramienta puede influir en decisiones, generar acciones o producir salidas que otros ejecutan sin revisión suficiente, la empresa necesita diseñar puntos de control materiales, no ceremoniales.

¿Qué significa “materiales”? Tres cosas muy concretas. Primera: que la persona revisora tenga contexto suficiente para detectar errores o resultados inapropiados. Segunda: que exista capacidad real de detener, corregir o desautorizar la salida antes de que produzca efectos. Tercera: que quede rastro de esa intervención. Si falta una de las tres, la supervisión humana corre el riesgo de ser más decorado que salvaguarda.

Esto también conecta con GDPR artículo 22 cuando se adoptan decisiones basadas únicamente en tratamiento automatizado que produzcan efectos jurídicos o afecten significativamente de modo similar a una persona. No todo agente empresarial caerá ahí, ni mucho menos. Pero en procesos de recursos humanos, scoring, atención al cliente con impacto contractual, prevención del fraude o priorización de casos, conviene no jugar a las adivinanzas. Hay que mapear dónde la automatización se queda en apoyo y dónde empieza a rozar una decisión jurídicamente sensible.

Incidentes: el reloj regulatorio corre aunque el proveedor tarde en explicarse

Cuando un sistema de IA participa en un incidente, la discusión interna suele atascarse rápido: quién responde, quién investiga, qué logs existen, qué parte corresponde al proveedor y si ha habido o no acceso indebido a datos personales. El regulador, mientras tanto, no espera a que la llamada con soporte termine bien.

Si hay una violación de seguridad de los datos personales, el artículo 33 de GDPR obliga a notificarla a la autoridad de control competente sin dilación indebida y, de ser posible, a más tardar 72 horas después de haber tenido constancia de ella, salvo que sea improbable que dicha 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 entrañe un alto riesgo. La dificultad práctica con sistemas de IA no cambia esa obligación; la complica. Sobre todo si parte de la evidencia está en manos del proveedor.

DORA añade su propio marco para la notificación de incidentes graves relacionados con las TIC. Los artículos 17 a 19 obligan a establecer procesos para gestionar, registrar, clasificar y notificar incidentes. Aquí el detalle clave es organizativo: si el servicio de IA está incrustado en procesos relevantes, debe entrar en el circuito corporativo de detección, escalado, clasificación y reporte. No vale tratarlo como una excepción experimental permanente.

NIS2, por su parte, impone un régimen de notificación escalonado en los incidentes significativos, con una alerta temprana, una notificación del incidente y un informe final, conforme al artículo 23. La forma exacta dependerá de la transposición nacional y de la autoridad competente, pero la lección es clara: si no has preparado la coordinación entre seguridad, legal, privacidad, compras y negocio antes del incidente, vas tarde.

Documentación: la diferencia entre tener control y tener fe

Hay organizaciones que creen estar razonablemente cubiertas porque han aprobado una política general de uso de IA. Mejor que nada, sin duda. Suficiente, casi nunca.

La documentación que importa es la que permite reconstruir el caso de uso y defenderlo ante auditoría, autoridad supervisora, comité de riesgos o litigio. Eso exige, como mínimo, inventario de casos de uso, descripción funcional, categorías de datos tratadas, base jurídica cuando aplique, rol del proveedor, evaluación de terceros, permisos asignados, controles de salida, retención de logs, restricciones de entrenamiento, medidas de seguridad, proceso de revisión y condiciones de retirada del servicio.

En GDPR esto enlaza con el artículo 24 sobre responsabilidad del responsable, el artículo 30 sobre registros de actividades, el artículo 32 sobre seguridad del tratamiento y el artículo 35 si procede EIPD. En DORA conecta con los requisitos de gobernanza del riesgo TIC y con la documentación contractual y operativa sobre terceros. En el AI Act, cuando aplique, se suma la necesidad de documentación técnica, instrucciones de uso y registros.

La pregunta incómoda, pero correcta, para cualquier responsable de cumplimiento es muy simple: si mañana tuvieras que explicar a un supervisor cómo funciona un caso de uso concreto, qué datos toca, qué límites tiene y cómo lo paras, ¿podrías hacerlo sin depender de una llamada urgente al proveedor? Si la respuesta es no, lo que falta no es un comité nuevo. Falta documentación útil.

Qué sí puede decir hoy una empresa prudente sobre agentes de IA

Conviene escapar de dos caricaturas. La primera: “esto no tiene regulación, así que ya veremos”. Falso. La segunda: “toda IA autónoma está prohibida o es intrínsecamente incompatible con compliance”. También falso.

Lo que sí puede sostenerse con base jurídica razonable es algo más matizado.

• Si un sistema de IA trata datos personales, se aplican los principios y obligaciones de GDPR, con especial atención a los artículos 5, 25, 28, 30, 32, 33, 34 y 35, según el caso.
• Si una entidad financiera usa ese sistema en su entorno operativo, debe analizarlo dentro del marco de riesgo TIC y terceros de DORA, especialmente artículos 5 a 16 y 28 a 30.
• Si la entidad está sujeta a NIS2, deberá incorporar el riesgo del sistema en sus medidas de gestión de ciberseguridad y cadena de suministro conforme a los artículos 20, 21 y 23.
• Si el caso de uso entra en el ámbito del AI Act, habrá que determinar si es una práctica prohibida, un sistema de alto riesgo o un uso sujeto a obligaciones de transparencia u otras exigencias específicas.
• Si la herramienta influye en decisiones sobre personas o en procesos materialmente sensibles, la supervisión humana, la trazabilidad y la documentación dejan de ser recomendables para pasar a ser decisivas.

Eso ya es bastante. Y, para muchas empresas, bastante más de lo que han formalizado hasta ahora.

La gobernanza útil no empieza con un manifiesto; empieza con una puerta de entrada

La tentación corporativa habitual consiste en redactar una gran política de IA, convocar dos comités y confiar en que el orden emergerá por generación espontánea. No suele funcionar. La gobernanza útil empieza antes y de forma más pedestre: con una puerta de entrada obligatoria para cualquier caso de uso que quiera conectarse a datos, identidades, repositorios o aplicaciones corporativas.

Esa puerta de entrada debería exigir, como mínimo, cinco decisiones documentadas antes del despliegue.

• Propósito y alcance: qué problema resuelve exactamente y qué acciones puede o no puede realizar.
• Datos: qué categorías de información utilizará, con qué restricciones y si hay datos personales o confidenciales.
• Permisos: qué accesos necesita de verdad, con qué cuenta técnica o usuario delegado y bajo qué controles.
• Terceros: quién presta el servicio, si hay subencargados o subproveedores relevantes y qué garantías contractuales existen.
• Control y salida: cómo se supervisa, qué logs se conservan, cómo se desactiva y qué plan existe si falla.

No hace falta adornarlo con jerga futurista. Es gestión de cambios, evaluación de riesgos y control de proveedores aplicada a una tecnología nueva. La novedad técnica no elimina las disciplinas viejas; las vuelve más necesarias.

A falta de datos verificables sobre el nivel de madurez de “muchas organizaciones”, lo prudente es decir esto: cualquier empresa que no haya definido un proceso claro para autorizar casos de uso, clasificar datos, limitar permisos y revisar proveedores corre un riesgo previsible de desplegar estas herramientas por delante de sus controles. No es una profecía. Es la consecuencia normal de introducir capacidades nuevas sin un carril formal de aprobación.

La pregunta que debería estar haciendo ahora el consejo

No “qué estrategia de IA tenemos”, al menos no solo eso. La pregunta más útil es otra: ¿tenemos identificado dónde estos sistemas tocan datos, procesos o proveedores que ya están sometidos a obligaciones regulatorias específicas?

Si el consejo de administración de una entidad regulada no puede obtener una respuesta clara, tiene un problema de supervisión. DORA y NIS2 no convierten a los consejeros en ingenieros, pero sí les asignan responsabilidad sobre la aprobación y vigilancia del marco de riesgo. Y eso incluye preguntar por inventario, clasificación, terceros, incidentes y capacidad de intervención.

La ironía es que muchas organizaciones llevan años perfeccionando controles exhaustivos para software tradicional, externalización TIC y tratamiento de datos personales, y podrían reaprovechar buena parte de ese músculo. El error sería pensar que la IA merece un circuito paralelo completamente separado o, peor todavía, un trato indulgente porque “aún estamos explorando”. Los reguladores suelen tolerar la novedad bastante menos de lo que toleran las presentaciones estratégicas.

La conclusión incómoda: el riesgo no está en el nombre, sino en el acceso

Discutir si una herramienta merece o no la etiqueta de “agente” puede entretener a marketing, a producto y a media LinkedIn durante meses. Para legal, seguridad y compliance, la discusión relevante es más seca y bastante más productiva: qué ve, qué hace, con qué permisos, con qué proveedor, bajo qué registro y con qué capacidad real de parada.

Si la respuesta es vaga, el problema no es terminológico. Es de control interno.

Y ese control ya no puede construirse solo con políticas aspiracionales. Necesita inventario, clasificación, base jurídica, due diligence de terceros, restricciones de acceso, logging, supervisión humana efectiva y un plan de incidente que funcione sin pedirle fe al proveedor. Todo eso puede sonar menos glamuroso que hablar de “autonomía”, pero aquí está el quid: los reguladores no sancionan la falta de épica. Sancionan, o supervisan con dureza, la falta de control demostrable.

La buena noticia es que no hace falta esperar a una norma milagrosa sobre agentes de IA para empezar a hacer las cosas bien. Las piezas jurídicas ya están sobre la mesa. GDPR, DORA, NIS2 y, cuando corresponda, AI Act, ofrecen un mapa suficientemente claro para distinguir entre un uso tolerable y un despliegue temerario.

La mala noticia es que ese mapa obliga a trabajar. Bastante. Y cuanto más integrada esté la herramienta en datos y sistemas corporativos, menos creíble resulta seguir tratándola como una simple ayuda de oficina con esteroides.