IT 
EN 
El 2 de agosto de 2026 es una fecha relevante en el calendario regulatorio europeo de la inteligencia artificial. No porque la regulación empiece ese día, sino porque marca una fase de aplicación mucho más amplia del Reglamento de Inteligencia Artificial de la Unión Europea, conocido como AI Act.
Las primeras medidas del AI Act entraron en vigor en Agosto de 2024 y desde entonces se han ido aplicando de forma gradual. Las prácticas prohibidas y las obligaciones de alfabetización en IA fueron las primeras en aplicarse, en Febrero de 2025, seguidas por las obligaciones relacionadas con los modelos de IA de propósito general, la gobernanza y el régimen sancionador en Agosto de 2025. En tan solo unos días, a partir ya del 2 de agosto de 2026 comenzarán a aplicarse la mayoría de las reglas restantes, incluidas obligaciones de transparencia y buena parte del marco aplicable a los sistemas de alto riesgo. No obstante, el calendario no termina ahí: determinadas obligaciones para sistemas de alto riesgo quedan sujetas a fases posteriores de aplicación, con fechas que pueden extenderse hasta 2027 e incluso 2028 en algunos casos.
Para los bancos españoles y europeos, este calendario no debe interpretarse como una cuenta atrás puramente legal, sino como una ventana de preparación. La IA deja de ser una iniciativa aislada de innovación y pasa a formar parte del perímetro regulatorio, tecnológico y operativo de la entidad. La cuestión ya no es simplemente si un banco utiliza IA. La pregunta relevante es si sabe dónde la utiliza, qué procesos toca, qué decisiones influye, qué datos necesita, quién la controla y qué ocurre cuando falla o no es precisa.
La IA ya está dentro de la banca
La inteligencia artificial ya forma parte de numerosos procesos bancarios: Detección de fraude, evaluación de solvencia, scoring crediticio, onboarding digital, prevención de blanqueo de capitales, atención al cliente, operaciones de SOC, automatización interna, chatbots, copilotos internos y modelos de lenguaje. Pero no todos estos usos tienen el mismo impacto. Un sistema que resume documentación interna no plantea los mismos riesgos que un modelo que influye en la concesión de crédito. Una IA que ayuda a priorizar alertas de fraude no es lo mismo que un sistema que ejecuta acciones automáticas sobre una cuenta, una transacción o un cliente.
Por eso, la banca debe distinguir entre tres niveles de uso:
- IA que informa
- IA que recomienda
- IA que actúa
La IA puede acelerar el análisis, detectar patrones anómalos, reducir carga operativa y ayudar a tomar mejores decisiones. El riesgo aparece cuando sus resultados influyen en procesos relevantes sin suficiente trazabilidad, supervisión o capacidad de revisión.
No todo uso sensible está prohibido
Conviene evitar una lectura simplista del AI Act. La norma no prohíbe a los bancos utilizar IA en procesos sensibles. Lo que hace es clasificar los usos por nivel de riesgo y exigir controles proporcionales. Por ejemplo, la IA aplicada a la evaluación de solvencia o al scoring crediticio de personas físicas puede considerarse de alto riesgo. Eso no significa que esté prohibida, sino que debe cumplir requisitos estrictos de gestión de riesgos, documentación, trazabilidad, supervisión humana, robustez y ciberseguridad.
La detección de fraude también es crítica para la banca, aunque no plantea exactamente el mismo tratamiento regulatorio que el scoring crediticio. Un modelo puede ayudar a detectar patrones anómalos, priorizar alertas o apoyar a los equipos de fraude y seguridad. Lo importante es que las acciones de mayor impacto estén sujetas a controles adecuados, revisión, trazabilidad y mecanismos de escalado. El reto no es frenar la IA, sino evitar que se convierta en una caja negra descontrolada dentro de procesos que afectan a clientes, operaciones reguladas o funciones críticas del banco.
La IA como activo cibercrítico
Un sistema de IA no es solo un modelo. Es una combinación de código, datos, lógica de decisión, prompts, APIs, conectores, credenciales, registros, pipelines, herramientas internas, proveedores externos y decisiones de configuración y cada una de esas capas puede introducir riesgo. Un modelo puede ser manipulado mediante datos incorrectos. Un prompt puede filtrar información sensible. Una API puede conceder permisos excesivos. Un agente de IA puede acceder a herramientas internas sin suficiente control. Un proveedor externo puede generar dependencia tecnológica. Y un sistema de logging insuficiente puede impedir reconstruir qué ocurrió durante un incidente.
Uno de los ejemplos más claros es el envenenamiento de datos, o data poisoning. Si un modelo de detección de fraude o prevención de blanqueo se entrena o ajusta con datos manipulados, puede aprender patrones equivocados. Como consecuencia, comportamientos sospechosos podrían parecer normales, o comportamientos legítimos podrían marcarse erróneamente como fraudulentos. En banca, esto no es solo un problema técnico. Puede convertirse en riesgo operativo, regulatorio, financiero pero sobre todo reputacional.
AI Act y DORA: dos marcos distintos, un punto de encuentro
El AI Act y DORA deben leerse juntos en el entorno bancario, pero tienen ámbitos diferentes y por ello no deben confundirse. DORA no regula la inteligencia artificial como tal. Su foco está en la resiliencia operativa digital del sector financiero: gestión del riesgo TIC, incidentes, pruebas de resiliencia, continuidad operativa, recuperación y riesgo de terceros tecnológicos. El AI Act, en cambio, se centra en una IA fiable y basada en riesgos, con obligaciones relacionadas con gobernanza, transparencia, registro, supervisión humana, robustez, ciberseguridad y control durante el ciclo de vida del sistema.
La intersección entre ambos marcos es especialmente importante para la banca. Un sistema de IA utilizado por una entidad financiera puede ser, al mismo tiempo, un sistema sujeto a obligaciones de gobierno de IA y un activo TIC que soporta una función bancaria importante o crítica. Por eso, la IA crítica no debería gestionarse únicamente desde innovación, analítica o negocio sino desde el inventario tecnológico, el marco de riesgo operacional, el programa de ciberseguridad, la gestión de terceros, los procedimientos de incidentes y las pruebas de resiliencia.
De la política a la evidencia
La presión regulatoria no se resolverá solo redactando políticas. El verdadero reto será demostrar que el banco sigue teniendo el control de la IA que utiliza. Un banco deberá siempre poder aportar evidencias concretas en caso de que sea necesario: Inventario de sistemas de IA, clasificación de riesgos, responsables asignados, documentación técnica y funcional, trazabilidad de decisiones, controles de acceso, pruebas de robustez, monitorización, planes de contingencia, gestión de incidentes y evaluación de proveedores.
La pregunta clave que tendrá que hacerse cada entidad es sencilla: Si un sistema de IA falla, genera una recomendación errónea, actúa de forma inesperada o se ve comprometido…
¿Puede el banco reconstruir qué ocurrió y actuar a tiempo para corregirlo?
Si la respuesta no está documentada, probada y respaldada por evidencias, el sistema no está realmente bajo control.
La IA en banca debe poder controlarse
El 2 de agosto de 2026 debe verse como un punto de madurez para la banca europea porque es el momento exacto, si no lo ha sido ya, en el que la IA pasa a formar parte del mismo debate que ya existe alrededor de la ciberseguridad, la resiliencia operativa y el control de terceros tecnológicos.
La ventaja competitiva para las entidades bancarias no está en ser pioneros en adopción de la IA, sino en hacerlo mejor que el resto: Con seguridad, trazabilidad y capacidad de reacción para evitar cualquier situación errónea, alucinaciones con sistemas críticos o falsos positivos.
En banca no basta con declarar confianza, sino que hay que demostrarla, tanto para el marco regulatorio como para los propios clientes. AI Act, DORA y el resto de regulaciones que hemos visto en los últimos años respecto a la resiliencia operativa digital tengrán que asegurar que la inteligencia artificial también merece esa confianza.
En Resumen
¿Qué relación tienen AI Act y DORA en banca?
AI Act regula el uso fiable y basado en riesgos de la inteligencia artificial, mientras que DORA se centra en la resiliencia operativa digital del sector financiero. Cuando un sistema de IA soporta procesos críticos, ambos marcos se cruzan en gobierno, ciberseguridad, trazabilidad, incidentes, proveedores y continuidad operativa.
¿Puede un banco usar IA para scoring crediticio?
Sí, pero debe evaluar el nivel de riesgo y aplicar controles proporcionales. En determinados casos, la IA aplicada a solvencia o scoring crediticio de personas físicas puede considerarse de alto riesgo y requerir gestión de riesgos, documentación, supervisión humana, robustez y ciberseguridad.
¿Por qué la IA debe tratarse como activo crítico?
Porque un sistema de IA no es solo un modelo: incluye datos, APIs, prompts, credenciales, conectores, proveedores, registros y decisiones de configuración. Si falla o se manipula, puede generar riesgo operativo, regulatorio, financiero y reputacional.
¿Qué evidencias debería tener un banco sobre sus sistemas de IA?
Inventario de sistemas, clasificación de riesgos, responsables asignados, documentación técnica y funcional, trazabilidad de decisiones, controles de acceso, pruebas de robustez, monitorización, planes de contingencia, gestión de incidentes y evaluación de proveedores.
¿Qué es el data poisoning en banca?
Es la manipulación de datos usados para entrenar o ajustar un modelo de IA. En banca puede afectar a modelos de fraude, prevención de blanqueo o scoring, provocando falsos positivos, falsos negativos o decisiones difíciles de justificar.