La verdadera trampa del AI Act en 2026: clasificar mal un sistema de alto riesgo ya no es un error jurídico, es un fallo operativo

La pregunta que de verdad importa no es si usas IA. A estas alturas, eso ya se da por hecho. La pregunta seria es otra: si mañana tu sistema pasa a influir en la admisión de un cliente, en la detección de fraude, en la fijación de precios o en la priorización de incidencias, ¿sabes con qué marco legal se va a examinar esa decisión? Ahí empieza el problema real del AI Act para el sector financiero: no en la retórica sobre innovación responsable, sino en la clasificación.

Porque el reglamento europeo no castiga la palabra “IA”. Castiga, prohíbe o condiciona usos concretos. Y en finanzas, donde casi todo modelo toca riesgo, identidad, acceso, vigilancia, prevención del fraude o decisiones con efecto económico, la frontera entre un sistema de riesgo limitado y uno de alto riesgo no siempre está donde el departamento comercial querría que estuviera.

Ese es el punto incómodo. Muchas entidades siguen abordando el AI Act como si fuera una extensión cosmética de su gobierno de modelos. No lo es. El reglamento introduce una lógica jurídica distinta: clasifica sistemas por función, por contexto de uso y por impacto potencial sobre derechos y seguridad. Si te equivocas en esa primera lectura, todo lo demás —documentación, controles, supervisión humana, gestión de datos, trazabilidad, relación con proveedores— nace torcido.

Y aquí conviene pinchar una pequeña burbuja corporativa: “como ya cumplimos con GDPR, NIS2 o DORA, estamos razonablemente cubiertos”. No exactamente. Hay solapes, sí. También huecos muy concretos. DORA se centra en resiliencia operativa digital; GDPR, en protección de datos personales; NIS2, en medidas de ciberseguridad y gobernanza; el AI Act añade obligaciones sobre diseño, uso, transparencia, supervisión y conformidad de sistemas de IA que no se resuelven con una política genérica de tecnología responsable pegada a un PowerPoint.

El núcleo del problema: clasificar mal sale caro, aunque no haya multa mañana

El AI Act estructura buena parte de sus obligaciones alrededor de varias categorías: prácticas prohibidas, sistemas de alto riesgo, determinados sistemas sujetos a obligaciones de transparencia y otros usos con menor carga regulatoria. La arquitectura no es decorativa; define qué cargas documentales, técnicas y organizativas se activan.

Para el sector financiero, el foco práctico está en dos bloques. El primero son los usos prohibidos del artículo 5, que vetan determinadas prácticas de IA por el riesgo que plantean para derechos fundamentales. El segundo son los sistemas de alto riesgo del artículo 6 y del Anexo III, donde aparecen supuestos especialmente delicados cuando la IA se utiliza para tomar o apoyar decisiones que afectan de forma significativa a personas.

La tentación habitual es leer el Anexo III como una lista lejana, casi administrativa. Error. En esa lista están varios gatillos que pueden tocar de lleno a bancos, aseguradoras, fintech y proveedores tecnológicos del sector. Por ejemplo, los sistemas destinados a evaluar la solvencia de personas físicas o establecer su puntuación crediticia entran en el radar de alto riesgo, salvo exclusiones específicas relacionadas con la detección de fraude financiero. Ese detalle importa mucho más de lo que parece: significa que no basta con decir “es un modelo financiero”; hay que mirar la finalidad concreta del sistema.

Ese matiz cambia la conversación interna. Un modelo entrenado para detectar transacciones sospechosas no plantea la misma calificación regulatoria que un sistema que decide si alguien accede a un crédito al consumo o en qué condiciones. Ambos pueden usar técnicas parecidas. Jurídicamente, no viven en el mismo barrio.

Y hay más. Si una entidad despliega IA en procesos de identificación, autenticación, atención automatizada, filtrado de clientes o monitorización de empleados, puede entrar en zonas donde el AI Act no solo exige clasificación fina, sino una lectura cruzada con GDPR y legislación laboral. La tecnología puede ser la misma; la consecuencia legal cambia con el caso de uso. Es menos sexy que hablar de “transformación”, pero bastante más útil.

Lo que sí dice el AI Act, sin adornos ni profecías regulatorias

Conviene limpiar el terreno de una mala costumbre que ya circula en bastantes presentaciones: rellenar los huecos interpretativos con cronologías épicas, supuestas guías decisivas o anuncios regulatorios que nadie ha leído de verdad. Si la base documental no los sostiene, sobran.

Lo verificable está en el propio reglamento. El artículo 5 recoge las prácticas prohibidas. El artículo 6 establece cuándo un sistema se considera de alto riesgo, incluyendo los supuestos cubiertos por el Anexo I y los del Anexo III. Los artículos 8 a 15 detallan requisitos para sistemas de alto riesgo: sistema de gestión de riesgos, gobernanza de datos, documentación técnica, registro de eventos, transparencia e información a desplegadores, supervisión humana, y requisitos de exactitud, robustez y ciberseguridad. Los artículos 16 y siguientes asignan obligaciones a proveedores, importadores, distribuidores y desplegadores. Y los artículos 26 y 27 son particularmente relevantes para entidades que usan sistemas de terceros, porque aterrizan deberes del desplegador en el uso real del sistema.

Ese mapa legal ya basta para una conclusión incómoda: una entidad financiera no puede permitirse esperar a que alguien publique una nota explicativa milagrosa para empezar a clasificar sus casos de uso. El trabajo serio sale del texto del reglamento, de su lógica y del encaje con los procesos de negocio. Lo demás ayuda, pero no sustituye el análisis.

Hay una ironía bastante europea en todo esto. Muchas organizaciones que presumen de “maturity” en cumplimiento siguen sin tener un inventario operativo que conecte modelo, finalidad, proveedor, base legal de datos, impacto en cliente y cadena de decisión. Es decir: tienen más política que cartografía. Y sin cartografía, el AI Act se convierte en una lotería cara.

Dónde se complica de verdad en banca, pagos y seguros

La dificultad no está solo en identificar un sistema de IA. Está en separar funciones que en la práctica aparecen mezcladas en una misma arquitectura. Un mismo stack tecnológico puede incluir un componente para verificación documental, otro para detección de anomalías, otro para scoring interno y otro para recomendación comercial. Si se analiza el paquete entero como si fuera un solo sistema homogéneo, la clasificación sale mal casi por diseño.

Pongamos un ejemplo frecuente. Una entidad despliega una plataforma de onboarding digital con verificación de identidad, análisis de riesgo de fraude, scoring de admisión y automatización de revisiones manuales. El proveedor la vende como una solución integral y la primera reacción del cliente suele ser tragarse esa etiqueta. Pero el reglamento no clasifica “plataformas integrales”; clasifica sistemas según función y uso. La verificación biométrica o documental puede activar un tipo de análisis; el scoring crediticio, otro; la detección de fraude financiero, otro distinto; la automatización de colas de revisión, otro que quizá no sea alto riesgo por sí mismo pero sí relevante para trazabilidad, transparencia o supervisión humana.

Aquí está el quid: el análisis jurídico no debe seguir la estructura comercial del proveedor, sino la lógica funcional del sistema. Si compras una caja negra con cuatro módulos y solo evalúas el contrato marco, probablemente dejarás fuera la parte regulatoriamente más delicada.

En seguros ocurre algo parecido con modelos de pricing, segmentación y prevención del fraude. No toda automatización actuarial o analítica cae de forma automática en alto riesgo por llevar IA. Pero cuando el sistema condiciona de manera significativa acceso, condiciones económicas o tratamiento individual del asegurado, la revisión debe hacerse con lupa. No por alarmismo, sino porque el AI Act conecta precisamente con esas zonas donde una decisión automatizada puede tener efectos materiales sobre personas.

En pagos y prevención del blanqueo, el problema es doble. Por un lado, hay modelos que la entidad considera “solo antifraude” y que, sin embargo, terminan afectando a bloqueos, escalados, revisiones reforzadas o exclusión de operaciones. Por otro, el perímetro de exclusiones o tratamientos diferenciados no debe leerse de forma expansiva porque a alguien le venga bien en el comité de producto. Si la finalidad efectiva del sistema se desplaza, la clasificación también puede cambiar.

El cruce con GDPR: donde muchos descubren que su DPIA no bastaba

El GDPR ya obligó a las entidades a pensar en decisiones automatizadas, minimización, base jurídica, transparencia y evaluaciones de impacto. Los artículos 13, 14, 22, 25, 32 y 35 siguen siendo imprescindibles. Pero creer que una evaluación de impacto en protección de datos resuelve por sí sola el problema del AI Act es confundir disciplinas vecinas con gemelas idénticas.

Una DPIA conforme al artículo 35 GDPR analiza riesgos para derechos y libertades derivados del tratamiento de datos personales. El AI Act, cuando trata sistemas de alto riesgo, añade una capa distinta: exige requisitos sobre gestión de riesgos del sistema, gobernanza del dataset, documentación técnica, logging, supervisión humana y desempeño técnico que no se agotan en la privacidad. Un sistema puede tener una DPIA impecable y seguir corto en controles exigibles por los artículos 9 a 15 del AI Act.

También ocurre al revés. Una organización puede documentar bastante bien su modelo desde la óptica de validación interna y, sin embargo, no haber resuelto cuestiones básicas de GDPR: información al interesado, justificación del tratamiento, retención, licitud del uso de datos para entrenamiento o límites del artículo 22 si existe una decisión basada únicamente en tratamiento automatizado con efectos jurídicos o significativamente similares.

La pregunta útil no es qué norma “manda más”, sino dónde están las brechas entre ambas. Si tu mapa de cumplimiento separa radicalmente privacidad, riesgo de modelo y compliance de IA, ya tienes una fuente casi garantizada de inconsistencias. Y el regulador, cuando mira un incidente o una reclamación, no suele premiar los organigramas internos por muy elegantes que sean.

DORA no te salva de clasificar, pero sí te obliga a tomarte en serio a los proveedores

En entidades financieras, el cruce con DORA merece atención específica por una razón simple: gran parte de la IA relevante se consume como servicio, se integra desde terceros o depende de cadenas de subcontratación que pocas organizaciones conocen de verdad.

DORA aprieta ahí con bastante claridad. El artículo 28 establece principios clave para la gestión del riesgo asociado a terceros proveedores de servicios de TIC. Los artículos 30 y 31 bajan al detalle contractual y al seguimiento de esos proveedores. Si el sistema de IA que usas para onboarding, detección de fraude, scoring o asistencia al cliente depende de un proveedor TIC, no basta con la típica due diligence de compras y una cláusula estándar de seguridad. Necesitas entender qué parte del cumplimiento AI Act recae en el proveedor como proveedor del sistema y qué parte te corresponde a ti como desplegador.

Ese reparto no siempre encaja limpiamente. El proveedor puede entregar documentación técnica genérica, prometer robustez y declarar controles. Muy bien. Pero quien decide el contexto de uso, los umbrales operativos, la interacción con decisiones de negocio y el impacto real sobre clientes suele ser la entidad financiera. Y ahí entran de lleno las obligaciones del desplegador recogidas en el AI Act, incluidas las relativas a uso conforme a instrucciones, supervisión humana, control de inputs cuando proceda y seguimiento del funcionamiento.

La lección práctica es poco glamurosa pero decisiva: junta en la misma mesa a compras, legal, privacidad, ciberseguridad, validación de modelos y negocio. Si cada uno revisa “su trozo” sin una taxonomía común del caso de uso, aparecerán lagunas. Luego llegarán los hallazgos de auditoría. O peor, llegarán después de un problema con clientes.

NIS2 entra por la puerta de la gobernanza, no por la de la clasificación

NIS2 tampoco sustituye al AI Act, pero sí sube el nivel de exigencia sobre gestión de riesgos, seguridad de la cadena de suministro y responsabilidad de la alta dirección. El artículo 21 exige medidas técnicas, operativas y organizativas apropiadas y proporcionadas para gestionar riesgos de ciberseguridad. El artículo 20 refuerza la responsabilidad de los órganos de dirección en la aprobación y supervisión de esas medidas.

¿Qué implica eso cuando hablamos de IA en finanzas? Que una entidad no puede tratar un sistema crítico de decisión automatizada como si fuera una simple herramienta analítica aislada del marco de seguridad corporativo. Si ese sistema depende de APIs externas, componentes open source, modelos fundacionales de terceros o proveedores cloud, el análisis de riesgo no puede quedarse en la exactitud del modelo. Debe incluir dependencia operativa, integridad de datos, control de cambios, exposición a manipulación y resiliencia del servicio.

La clasificación de alto riesgo bajo AI Act y las obligaciones de gestión de riesgos bajo NIS2 no son lo mismo. Pero ignorar una de las dos produce una fotografía falsa. Es perfectamente posible tener un sistema bien clasificado desde la óptica legal y mal defendido desde la óptica de ciberseguridad. También lo contrario. En ambos casos, el problema no desaparece porque el equipo de compliance tenga una matriz muy colorida.

La gran confusión: modelo, sistema y caso de uso no son sinónimos

Buena parte de los errores de cumplimiento nacen de una confusión semántica que parece menor y no lo es. Un modelo no es lo mismo que un sistema. Y un sistema no es lo mismo que un caso de uso concreto.

Un mismo modelo puede incorporarse a varios sistemas. Un mismo sistema puede utilizarse para finalidades distintas. Y un cambio aparentemente menor en el caso de uso puede mover la clasificación regulatoria. Esa es una de las razones por las que los inventarios de IA hechos a toda prisa suelen quedarse viejos en cuestión de meses: catalogan herramientas, no funciones reales.

Si una entidad anota “motor de IA conversacional” en su registro interno, eso dice muy poco. ¿Ese motor responde preguntas frecuentes sin efectos relevantes? ¿Asiste a agentes humanos? ¿Prioriza reclamaciones? ¿Redirige clientes vulnerables? ¿Sugiere decisiones sobre admisión, bloqueo o revisión reforzada? Según la respuesta, cambian las obligaciones de transparencia, la necesidad de supervisión humana y el nivel de escrutinio regulatorio.

El AI Act obliga, en la práctica, a inventariar por finalidad y por impacto. Menos catálogo de proveedores, más mapa funcional. Es más trabajo, sí. También es la única forma seria de saber qué te aplica.

Lo que debería estar haciendo ya una entidad financiera

Sin esperar a interpretaciones salvadoras, hay una secuencia de trabajo razonable y defendible. No hace falta dramatizar, pero sí dejar de improvisar.

• Primero, construir un inventario de sistemas de IA por caso de uso real, no por nombre comercial de la herramienta. Cada entrada debería identificar finalidad, unidad de negocio, proveedor, origen de datos, outputs, decisiones que influye y población afectada.
• Segundo, mapear cada caso contra el artículo 5, el artículo 6 y el Anexo III del AI Act. No para poner etiquetas deprisa, sino para documentar por qué un uso podría ser prohibido, de alto riesgo, sujeto a transparencia o quedar fuera de esas categorías más intensas.
• Tercero, cruzar ese mapa con GDPR, especialmente artículos 22 y 35, y con los controles de seguridad y terceros derivados de DORA y NIS2. Si un sistema es jurídicamente delicado y operativamente crítico, debe reflejarse en ambas capas.
• Cuarto, revisar contratos y anexos técnicos con proveedores. Si el proveedor no puede explicar con un mínimo de precisión el sistema, sus límites, sus datos, sus logs y sus controles, la entidad compradora no debería fingir que ya tiene resuelto el cumplimiento solo porque existe una cláusula de compliance de dos páginas.
• Quinto, definir supervisión humana real. No una firma formal al final del proceso, sino intervención significativa, escalado, criterios de revisión y capacidad efectiva para cuestionar el resultado del sistema.

Esto no es una lista ornamental. Es una secuencia porque el orden importa. Si empiezas por contratos sin haber clasificado el uso, revisarás mal. Si haces la DPIA antes de entender la finalidad exacta del sistema, la harás a medias. Si pides controles al proveedor sin saber si estás ante alto riesgo, pedirás poco o pedirás lo incorrecto.

La objeción habitual: “todavía hay incertidumbre interpretativa”

Es verdad. La hay. En un reglamento de este alcance sería absurdo negarlo. Hay zonas donde la interpretación fina exigirá práctica supervisora, criterios institucionales y, probablemente, litigio. Pero convertir esa incertidumbre en excusa para no hacer el trabajo básico sería bastante temerario.

La incertidumbre real no elimina lo que el texto ya dice con suficiente claridad. Si el Anexo III menciona determinados sistemas utilizados para evaluar la solvencia de personas físicas o establecer su puntuación crediticia, no hace falta esperar a una epifanía regulatoria para concluir que ese caso merece una revisión prioritaria. Si el artículo 9 exige un sistema de gestión de riesgos para sistemas de alto riesgo, no tiene sentido responder con una política corporativa de IA de tres principios bonitos y ningún control verificable.

También conviene desconfiar del discurso tranquilizador según el cual “ya habrá orientaciones que aclaren todo”. Puede que lleguen materiales útiles desde instituciones y autoridades. Perfecto. Pero ninguna entidad sensata debería basar su estrategia de cumplimiento en documentos futuros cuya función, alcance o calendario no conviene dar por supuestos. El reglamento ya ofrece suficiente sustancia para empezar. Lo contrario suele ser una manera elegante de aplazar decisiones incómodas.

Mi lectura: el AI Act va a separar a las entidades que gobiernan tecnología de las que solo la compran

Esta es, en el fondo, la línea divisoria más interesante. No entre grandes y pequeñas. No entre incumbentes y fintech. Entre quienes entienden cómo se usa realmente la IA en sus procesos y quienes solo agregan proveedores con la esperanza de que el cumplimiento venga preinstalado.

Las primeras tienen una ventaja decisiva: pueden traducir el reglamento a controles operativos. Saben qué sistema afecta a qué decisión, qué datos usa, quién interviene, qué proveedor responde, dónde se registran eventos, qué umbrales disparan revisión humana y qué documentación puede enseñarse a auditoría o supervisor sin sonrojo.

Las segundas suelen vivir en una ficción cara. Tienen contratos, comités y presentaciones. Pero si preguntas qué sistema influye en una decisión de admisión concreta, qué base legal soporta el tratamiento asociado, qué parte del proceso puede revisar un humano y qué evidencia existe de que el proveedor cumple lo que promete, empiezan los silencios estratégicos. Muy corporativos. Muy poco tranquilizadores.

El AI Act no convierte de repente a todas las entidades en fabricantes de tecnología. Pero sí les quita una coartada bastante cómoda: la idea de que, por usar soluciones de terceros, la responsabilidad esencial reside fuera. No. En especial en finanzas, donde el impacto sobre clientes, acceso a servicios y riesgo operativo es directo, el uso importa tanto como el diseño.

Lo que no conviene hacer ahora

Hay tres errores que ya se repiten demasiado.

El primero es intentar resolver la clasificación con una sola etiqueta por proveedor o producto. Eso sirve para tener un Excel ordenado, no para cumplir.

El segundo es delegar la lectura del AI Act exclusivamente en legal sin involucrar a quienes entienden el flujo real de decisiones, datos y arquitectura. El resultado suele ser un análisis jurídicamente correcto en abstracto y operativamente inservible.

El tercero es tratar la IA como un apéndice del gobierno de modelos tradicional. Parte del trabajo se parece, claro. Validación, documentación, control de cambios, monitorización. Pero el AI Act añade una dimensión de derechos, transparencia, supervisión humana y responsabilidades en cadena que no encaja del todo en la vieja plantilla de model risk management.

Si quieres una señal simple para saber si tu entidad va tarde, aquí la tienes: intenta localizar, para un solo caso de uso crítico, el expediente completo que una auditoría seria pediría. Finalidad exacta del sistema, clasificación razonada bajo AI Act, evaluación de privacidad, controles de seguridad, contrato con proveedor, instrucciones de uso, evidencias de supervisión humana y logs o registros relevantes. Si reunir eso lleva semanas, el problema no es documental. El problema es de gobierno.

Conclusión: menos esperar, más clasificar bien

El debate sobre IA en finanzas se ha llenado de ruido futurista y de promesas de simplificación. A veces da la impresión de que siempre falta “la siguiente pieza” para poder empezar en serio. No comparto esa lectura. La pieza decisiva ya existe: entender que la clasificación no es un trámite, sino el mecanismo que determina casi todo lo demás.

Quien clasifique mal, construirá controles inadecuados, pedirá mal a sus proveedores, documentará a destiempo y dejará huecos entre privacidad, seguridad y negocio. Quien clasifique bien tendrá trabajo, sí, pero al menos trabajará sobre una base defendible.

En regulación tecnológica, eso ya es media victoria. La otra media consiste en algo bastante menos heroico y mucho más útil: conocer tus sistemas mejor de lo que los conoce el comercial que te los vendió.