El AI Act ya muerde: desde el 2 de agosto la IA deja de ser piloto y pasa a ser riesgo sancionador

No hay demasiadas dudas sobre el riesgo más tonto que está asumiendo ahora mismo buena parte del sector financiero: tratar la gobernanza de IA como un asunto de laboratorio, innovación o compras, cuando en realidad ya es un problema de cumplimiento transversal. Y no porque Bruselas haya descubierto de repente la pólvora regulatoria, sino porque el AI Act encaja mal con estructuras internas pensadas para tecnologías que entraban por una sola puerta. La IA, en cambio, se cuela por casi todas.

Ese es el punto que muchas entidades todavía están digiriendo. No basta con preguntarse si la organización “usa IA”. La pregunta útil es otra: dónde está, quién la decide, con qué datos opera, qué función cumple y bajo qué régimen jurídico cae cada caso. Si esa cartografía no existe, el debate sobre cumplimiento empieza tarde.

La tentación de leer el AI Act como una norma autónoma también conduce a errores bastante previsibles. El reglamento europeo no llega a un terreno vacío. Se superpone a obligaciones de protección de datos, gobierno interno, externalización, seguridad, documentación, supervisión de proveedores y control de riesgos. En fin: al catálogo de dolores habituales del sector regulado. La novedad no es que aparezca una obligación completamente alienígena. La novedad es que varias piezas que ya estaban dispersas empiezan a exigir una visión unificada.

Ahí está el verdadero problema operativo. La mayoría de organizaciones no fallan porque desconozcan que el AI Act distingue entre sistemas prohibidos, de alto riesgo, modelos de propósito general y usos con menores cargas. Fallan porque esa lógica jurídica no coincide con la forma en que compran software, despliegan analítica, documentan proveedores o escalan herramientas dentro del negocio. El derecho dibuja categorías. La empresa suele trabajar con proyectos, contratos, licencias, casos de uso y excepciones improvisadas en reuniones de una hora. Luego llega compliance a ordenar el incendio.

La pregunta correcta no es si usas IA, sino si sabes localizarla

El AI Act distribuye obligaciones según el papel que desempeñe cada actor y según el tipo de sistema de IA de que se trate. Esa arquitectura no es un matiz técnico: es la base de casi todo lo demás. El reglamento distingue, entre otros, a providers, deployers, importadores y distribuidores, y asigna responsabilidades distintas en función de ese rol. También establece regímenes diferentes para prácticas prohibidas, sistemas de alto riesgo, determinados sistemas con obligaciones de transparencia y modelos de IA de propósito general. Quien siga hablando de “la IA” en singular, a estas alturas, ya va tarde.

Esto importa especialmente en servicios financieros porque una misma entidad puede ocupar varios papeles a la vez. Puede desplegar internamente una herramienta adquirida a un tercero, integrar un modelo en un proceso propio, modificar de forma relevante un sistema externo o redistribuir soluciones dentro del grupo. En cada uno de esos escenarios cambian las obligaciones, la documentación exigible y el tipo de control que conviene exigir por contrato. No es una cuestión semántica. Es la diferencia entre heredar controles suficientes o descubrir, cuando ya hay supervisión o incidente, que nadie sabía quién debía responder por qué.

El AI Act, además, no funciona solo por la etiqueta “alto riesgo sí o no”. También obliga a leer con cuidado el uso concreto, el contexto y la posición de la entidad en la cadena de suministro. Si un equipo de compras contrata una funcionalidad basada en IA y la organización la despliega en un proceso que afecta a clientes, empleados o decisiones sensibles, el análisis no puede quedarse en la documentación comercial del proveedor. Tampoco basta con una cláusula contractual genérica asegurando conformidad normativa. Eso sirve para la presentación de PowerPoint; para gobernanza real, no tanto.

La consecuencia práctica es bastante menos glamourosa y mucho más útil: toda entidad financiera que quiera tomarse en serio el AI Act necesita un inventario operativo de sistemas y casos de uso. No un inventario decorativo. Operativo significa que permita tomar decisiones de cumplimiento, escalar incidencias, revisar contratos, asignar propietarios internos y activar controles cuando cambie el uso de una herramienta. Si no hace eso, es un Excel terapéutico.

El AI Act no llega solo. Llega montado sobre GDPR, seguridad, terceros y gobierno interno

Quien intente gestionar esta norma como una capa aislada va a duplicar trabajo y, peor aún, va a dejar huecos. El cruce más obvio es con GDPR. Si un sistema de IA trata datos personales, siguen vigentes los principios del artículo 5, la base jurídica del artículo 6, las reglas sobre categorías especiales del artículo 9 cuando proceda, la transparencia de los artículos 13 y 14, los derechos del interesado y, cuando el tratamiento entrañe alto riesgo, la evaluación de impacto del artículo 35. Nada de eso desaparece porque una herramienta venga envuelta en lenguaje de automatización inteligente.

También hay un cruce evidente con la seguridad. Si el despliegue de IA altera activos críticos, cadenas de acceso, tratamiento de logs, monitorización, dependencias en nube o exposición a proveedores, la conversación ya no es sólo de legal y compliance. Pasa por seguridad de la información, continuidad, gestión de terceros y control de cambios. En el mundo financiero europeo eso tiene una resonancia muy concreta: la gestión del riesgo asociado a proveedores TIC y a dependencias externas no es una cuestión ornamental. DORA dedica su Capítulo V a la gestión del riesgo de terceros TIC, y los artículos 28 a 30 desarrollan elementos centrales sobre la estrategia en materia de riesgo de terceros TIC, el registro de información y los requisitos contractuales clave. Conviene citar bien: usar “artículo 28” como atajo para todo el régimen de terceros TIC es jurídicamente pobre y, además, inexacto.

La comparación con DORA es útil por otra razón. En ambos casos, el regulador empuja a las entidades a mirar más allá del organigrama clásico. Si una función depende de un tercero, si hay subcontratación relevante, si el control técnico está fuera o si una modificación del servicio cambia el perfil de riesgo, la entidad regulada no puede fingir que el problema se ha externalizado junto con la factura. El proveedor presta el servicio. La responsabilidad regulatoria, sorpresa, no viaja tan fácilmente.

Lo mismo ocurre con NIS2 en aquellos operadores y entidades que entren en su ámbito. El artículo 21 exige medidas técnicas, operativas y organizativas adecuadas y proporcionadas para gestionar riesgos de ciberseguridad. Si la introducción de IA modifica esos riesgos —por ejemplo, por dependencia de terceros, ampliación de superficies de ataque, cambios en procesos de autenticación o nuevas rutas de acceso a datos— el análisis de cumplimiento no puede quedarse en la pregunta de si el sistema “usa IA”. Tiene que examinar qué cambia en el riesgo y qué controles se actualizan.

Dicho de otra forma: el AI Act no sustituye tus marcos de cumplimiento. Los estresa. Y obliga a comprobar si de verdad estaban integrados o sólo convivían en paz armada dentro del mismo comité.

El inventario útil no es una lista de herramientas; es un mapa de decisiones

Aquí suele aparecer el primer autoengaño corporativo. Alguien propone “hacer un inventario de IA” y media organización escucha “preparar una lista de aplicaciones”. Eso es mejor que nada, pero apenas resuelve el problema. Un inventario útil tiene que servir para decidir obligaciones, no para contar licencias.

Para que ese inventario sea accionable, cada entrada debería permitir responder, al menos, a un conjunto básico de cuestiones operativas: qué herramienta o sistema se utiliza, para qué proceso de negocio, qué área es su propietaria, si el proveedor actúa como desarrollador o la entidad ha introducido modificaciones relevantes, qué datos se usan, si hay datos personales o sensibles, qué impacto puede tener en clientes, empleados o decisiones internas, qué controles documentales existen y qué dependencia contractual o tecnológica genera. Esa estructura no es una lista oficial del AI Act ni un catecismo normativo cerrado. Es el mínimo razonable para convertir un inventario en una herramienta de gobierno.

La diferencia entre una lista y un mapa aparece enseguida. Si descubres una herramienta de análisis conversacional contratada por una unidad comercial, la cuestión no es sólo que exista. La cuestión es si graba interacciones, si alimenta decisiones comerciales, si perfila clientes, si reutiliza datos para entrenar o ajustar funcionalidades, si depende de subencargados fuera de la UE, si su salida se utiliza con supervisión humana real o meramente nominal y si el contrato permite entender qué hace exactamente el proveedor. Cuando esa información no está reunida, el cumplimiento se convierte en arqueología.

Y sí, esto exige coordinación que a menudo nadie ha diseñado. Compras conoce al proveedor. Seguridad conoce parte de la arquitectura. Legal conoce algunas cláusulas. Protección de datos conoce los tratamientos declarados. El negocio conoce el uso real, o una parte. Tecnología conoce las integraciones. Riesgos conoce el apetito y los controles formales. Lo divertido —si uno tiene sentido del humor raro— es que la IA suele atravesar todas esas capas a la vez.

La obsesión por el “alto riesgo” puede dejarte ciego ante otros frentes

Buena parte de la conversación pública sobre el AI Act gira en torno a los sistemas de alto riesgo, y tiene lógica: es donde el reglamento concentra algunas de las obligaciones más exigentes. Pero centrar toda la gobernanza en esa etiqueta puede producir una distorsión bastante peligrosa.

Primero, porque hay prácticas prohibidas y obligaciones de transparencia que requieren atención propia. Segundo, porque incluso cuando un sistema no cae en la categoría de alto riesgo, puede generar obligaciones relevantes por la vía de datos personales, seguridad, protección del consumidor, gobernanza interna o gestión de proveedores. Tercero, porque el riesgo operativo de una herramienta mal comprendida no siempre coincide con la taxonomía jurídica más severa. Un sistema aparentemente periférico puede terminar influyendo en procesos sensibles de forma incremental y poco visible.

Eso obliga a una disciplina incómoda: revisar el uso real, no la etiqueta comercial. Muchos proveedores venderán automatización avanzada, inteligencia asistida, analítica aumentada o cualquier otro eufemismo vistoso. El nombre importa poco. Lo que importa es la funcionalidad, el contexto de despliegue y el efecto que produce dentro del proceso. Si una entidad se limita a aceptar la clasificación comercial del proveedor, está subcontratando también el juicio regulatorio. Mala idea.

Hay otro problema menos comentado. Las organizaciones tienden a pensar en sistemas completos, cuando muchas obligaciones y riesgos aparecen en componentes, módulos o funciones concretas. Una suite contratada para un fin legítimo y bien documentado puede incorporar una capacidad adicional activada meses después: resumen automatizado, priorización de expedientes, puntuación de leads, transcripción con extracción de entidades, ayuda a agentes o recomendaciones operativas. A veces nadie trata esa activación como un nuevo despliegue con impacto regulatorio. Luego llegan las sorpresas.

Gobernanza seria significa asignar dueño, no repartir culpa

Uno de los síntomas más fiables de inmadurez en este terreno es la creación de comités grandilocuentes sin responsabilidades claras. Se reúne todo el mundo, se habla de principios éticos, se aprueba una política con buenos modales y, al final, nadie sabe quién puede bloquear un uso, quién valida una clasificación, quién exige documentación al proveedor o quién autoriza cambios materiales. Gobernanza, así entendida, es sólo liturgia.

Una arquitectura útil necesita algo bastante más terrenal. Cada sistema o caso de uso relevante debería tener un propietario de negocio identificable, una función de control que revise el encaje normativo, criterios de escalado cuando cambie el uso o el proveedor, y puntos de conexión claros con seguridad, protección de datos, continuidad, compras y gestión de terceros. Si la organización no sabe quién aprueba una modificación funcional con impacto regulatorio, no tiene gobernanza; tiene esperanza.

El AI Act refuerza precisamente esa necesidad de atribución ordenada. Las obligaciones no recaen de forma abstracta sobre “la empresa”, sino sobre actores concretos en roles concretos y respecto de sistemas concretos. Esa lógica debería reflejarse internamente. De lo contrario, la entidad llegará a la fase de evidencias documentales con políticas elegantes y trazabilidad muy mediocre.

Aquí conviene una dosis de realismo. No todas las organizaciones necesitan un mastodonte burocrático nuevo. Muchas pueden integrar esta gobernanza en estructuras existentes de aprobación tecnológica, riesgo de modelos, protección de datos, terceros o cambios de arquitectura. Lo que no funciona es dejar la IA como subtema difuso entre innovación y compliance, confiando en que alguien “lo tenga visto”. Esa frase, por cierto, ha precedido a no pocos problemas regulatorios.

El proveedor no te va a regalar la trazabilidad que no le hayas exigido

La parte contractual merece más atención de la que suele recibir. Muchas entidades descubrirán que los contratos vigentes no les dan la información mínima para sostener una evaluación seria. No está claro qué modelo o funcionalidad se usa, qué cambios puede introducir el proveedor, qué subproveedores intervienen, qué datos se reutilizan, qué medidas de seguridad aplican a esa función concreta o qué asistencia ofrecerá ante requerimientos regulatorios. Y cuando el contrato es genérico, la respuesta comercial acostumbra a ser cordial pero insuficiente.

Aquí el cruce con DORA vuelve a ser útil como disciplina mental. Los requisitos contractuales y de registro asociados a terceros TIC obligan a profesionalizar el seguimiento de dependencias críticas. En IA, aunque el encaje jurídico exacto dependa del servicio y del rol de cada parte, la lógica es parecida: si no has pedido información específica sobre la funcionalidad, el entrenamiento, las modificaciones, las limitaciones de uso, la asistencia documental y el régimen de incidentes, luego no podrás improvisarla con una llamada de última hora al gestor de cuenta.

Eso afecta especialmente a productos empaquetados en suites amplias. La entidad contrata una plataforma legítima por una necesidad concreta y, con el tiempo, activa funciones adicionales basadas en IA sin renegociar los anexos de cumplimiento ni revisar en serio la evaluación inicial. El resultado es un desfase clásico entre uso real y documentación formal. Los supervisores rara vez admiran ese tipo de creatividad.

La pregunta práctica para cualquier entidad es simple: si mañana tuvieras que explicar a un regulador, a auditoría interna o a tu comité de riesgos qué hace exactamente ese proveedor con esa función de IA, podrías hacerlo con documentos en la mano? Si la respuesta depende de una demo comercial o de una FAQ en la web, ya sabes el problema.

La coordinación entre privacidad, seguridad y cumplimiento ya no es opcional

Durante años, muchas organizaciones han tolerado una división cómoda del trabajo: privacidad revisa tratamientos, seguridad revisa controles técnicos, legal revisa contratos y compliance mira el conjunto cuando hay norma nueva o inspección. Con IA, ese reparto empieza a hacer agua con demasiada facilidad.

Un ejemplo sencillo lo ilustra. Una herramienta puede superar una revisión de protección de datos razonable en cuanto a base jurídica y transparencia, pero generar una dependencia técnica o contractual mal resuelta. Otra puede estar bien gestionada desde compras y seguridad, pero apoyarse en flujos de datos secundarios no documentados del todo. Otra puede parecer inocua hasta que su salida se utiliza para priorizar clientes, apoyar decisiones laborales o escalar alertas de fraude. El problema no está en una sola función de control. Está en la costura entre varias.

Por eso la gobernanza de IA no debería diseñarse como un silo adicional, sino como un mecanismo de orquestación entre disciplinas que ya existen. GDPR ofrece criterios sobre tratamiento y derechos. DORA ordena la conversación sobre terceros TIC y resiliencia operativa. NIS2 empuja a revisar medidas de gestión de riesgos y gobernanza de ciberseguridad. El AI Act añade una capa específica sobre sistemas, roles, usos prohibidos, alto riesgo, transparencia y obligaciones de cadena de valor. Separarlo todo en compartimentos puede ser políticamente cómodo. Operativamente, es una forma elegante de fabricar lagunas.

La ironía es evidente: muchas entidades llevan años invirtiendo en marcos integrados de riesgo no financiero, pero cuando la IA entra por contratos, módulos y funciones dispersas, reaparece el viejo reflejo de parcelar el problema. Sale caro en tiempo, en duplicidades y, a veces, en ángulos muertos.

Lo que sí conviene hacer ahora, sin esperar a la perfección

No hace falta tener cerrado un programa ideal para empezar bien. De hecho, esperar al diseño perfecto suele ser la forma más eficiente de no hacer nada durante meses. Hay medidas bastante concretas que sí tienen sentido inmediato.

• Lanzar un ejercicio de identificación centrado en herramientas y funcionalidades ya desplegadas, no sólo en proyectos futuros. El objetivo es detectar uso real, también en áreas de negocio que no se autodefinen como “equipos de IA”.
• Vincular ese inventario a roles y procesos: propietario de negocio, proveedor, datos implicados, proceso afectado, base documental disponible, nivel de revisión exigido y criterio de escalado si cambia el uso.
• Revisar contratos y cuestionarios de terceros para comprobar si recogen información suficiente sobre funcionalidades de IA, subproveedores, cambios materiales, soporte documental, seguridad y asistencia ante obligaciones regulatorias.
• Conectar la revisión de IA con marcos ya existentes, en particular protección de datos, seguridad, continuidad, gestión de terceros, riesgo operativo y aprobación de cambios tecnológicos.
• Definir una regla de revaluación cuando una herramienta cambie de finalidad, se active una nueva función o se reutilice en un proceso distinto. Muchos problemas no nacen con la compra inicial; aparecen cuando el uso se expande sin nueva revisión.

No es una receta heroica. Precisamente por eso funciona mejor que los manifiestos solemnes. La mayoría de fallos de cumplimiento en esta materia no nacen de no entender el concepto abstracto de IA. Nacen de no ver una función concreta, de no actualizar una revisión antigua o de suponer que otro equipo ya validó algo que nadie validó de verdad.

La objeción habitual: “todavía es pronto para montar todo esto”

Es una objeción comprensible. Hay organizaciones que temen sobrerreaccionar, cargar de burocracia casos de uso modestos o anticipar controles antes de tener desplegada una estrategia más madura. El argumento merece atención porque no todo requiere la misma intensidad de gobierno.

Ahora bien, confundir proporcionalidad con pasividad es un error bastante clásico. Nadie está diciendo que cada herramienta exija el mismo nivel de análisis. Lo que sí exige el entorno regulatorio es saber distinguir unas de otras con un criterio defendible. Y para eso hace falta visibilidad mínima, roles claros y capacidad de escalar revisiones cuando el uso lo justifique.

Además, el coste de empezar tarde no siempre se mide en sanciones inmediatas ni en titulares. A veces se mide en proyectos frenados de golpe porque falta documentación, en renegociaciones contractuales precipitadas, en retrabajo interno, en respuestas torpes a auditoría o en semanas perdidas reconstruyendo qué hace exactamente una herramienta que ya estaba integrada en procesos críticos. Eso no suele salir en la memoria anual, pero lo sufre bastante gente dentro de la organización.

La cuestión, por tanto, no es si conviene actuar con prudencia. Claro que sí. La cuestión es qué significa prudencia. Y, en este caso, prudencia no equivale a esperar con los brazos cruzados. Equivale a crear visibilidad suficiente para decidir bien, con intensidad variable según el riesgo y el uso.

El verdadero error es tratar el AI Act como una pieza aislada

Ese es el núcleo del asunto. El AI Act no debería leerse como una vitrina normativa separada del resto del edificio. Leído así, parece un tema especializado para juristas de innovación o para un grupo técnico reducido. Leído junto a GDPR, DORA, NIS2 y los marcos internos de terceros, seguridad y riesgo operativo, revela otra cosa: un test bastante serio de madurez organizativa.

Si tu entidad no sabe localizar sistemas y funciones de IA, distinguir roles, revisar proveedores, conectar controles y revaluar cambios de uso, el problema no es sólo el AI Act. El problema es que la organización sigue gestionando tecnología crítica con una visión fragmentada, propia de una época en la que el software entraba por canales más previsibles y hacía cosas menos opacas.

La buena noticia —si queremos concederle una— es que el trabajo útil aquí no consiste en adivinar el futuro de la inteligencia artificial ni en montar un comité con nombre épico. Consiste en algo mucho menos fotogénico y bastante más valioso: saber qué tienes, quién responde, qué dependencia genera y qué régimen legal activa cada caso. El resto, con paciencia y documentos sólidos, se ordena.

Lo contrario también es posible, desde luego. Siempre se puede seguir diciendo que la IA está controlada porque hay una política corporativa, un proveedor conocido y una diapositiva bonita sobre innovación responsable. Hasta que alguien pida pruebas más concretas. Ahí suele terminar el teatro y empezar el trabajo de verdad.