Gobernanza de la IA en la banca: el modelo operativo para escalar IA bajo control

Executive Summary

1Por qué la gobernanza de la IA en banca es diferente

La inteligencia artificial en banca ya no es un tema futuro. Ya está entrando en riesgo de crédito, detección de fraude, AML, servicio al cliente, desarrollo de software, reporting regulatorio, ciberdefensa, resiliencia operativa y productividad interna. La European Banking Authority informó en 2025 que la adopción de IA en el sector bancario y de pagos de la UE había avanzado mucho más allá de la discusión: el 92% de los bancos de la UE ya despliega IA, mientras que el 8% restante está pilotando o discutiendo casos de uso de IA. Esto cambia por completo la cuestión de gobernanza. La gobernanza de la IA en banca ya no puede tratarse como un complemento ético, un apéndice de validación de modelos o una política propiedad de un equipo especializado. Se ha convertido en parte del sistema de gestión del banco.

El punto central es este: la gobernanza de la IA no trata de ralentizar la IA. Trata de hacerla escalable en una institución supervisada.

Muchos bancos aún enmarcan la gobernanza de la IA como un ejercicio de cumplimiento. Es comprensible, pero estratégicamente demasiado limitado. En Europa importan el EU AI Act, DORA, GDPR, las reglas de outsourcing, las expectativas de model risk management, los requisitos de internal governance y las prioridades de la ECB Banking Supervision. Pero el verdadero reto no es recopilar referencias regulatorias. El verdadero reto es traducirlas en un modelo operativo que permita al banco identificar, aprobar, desplegar, monitorizar y cuestionar sistemas de IA a través de business, technology, risk, compliance, data, cyber, legal, audit y board.

Ahí es donde fracasan muchos frameworks de gobernanza de IA. Parecen completos en papel, pero no cambian cómo se toman las decisiones.

Un banco puede publicar una política de IA. Puede crear un comité de IA. Puede nombrar un AI Officer. Puede exigir impact assessments, documentación de modelos, controles de calidad de datos y human oversight. Nada de eso es incorrecto. Pero si esos elementos no están conectados con decisiones de inversión, estándares de arquitectura, risk appetite, vendor onboarding, change governance, incident management y reporting al board, el banco no tiene gobernanza de IA. Tiene papeleo de IA.

La diferencia importa porque la banca no es un entorno tecnológico ordinario. Los bancos no simplemente procesan datos. Asignan crédito, gestionan depósitos, detectan criminalidad financiera, calculan capital, protegen pagos, manejan datos personales sensibles y operan infraestructura económica crítica. Cuando la IA se integra en esos procesos, se convierte en parte del entorno de control de la institución. Por tanto, la pregunta no es si la IA es innovadora. La pregunta es si está gobernada como parte del banco.

La gobernanza de IA en banca es diferente por cuatro razones.

1. 1Las consecuencias del fallo son diferentes. Un sistema de IA mal gobernado puede crear resultados de crédito sesgados, falsas alertas de fraude, daño al cliente, detección AML débil, clasificación de riesgo incorrecta, exposición cyber no gestionada, errores de reporting regulatorio o dependencia excesiva de un modelo tercero. En una aplicación de consumo, un output de IA deficiente puede crear riesgo reputacional. En un banco puede afectar a clientes, capital, conduct, resiliencia y confianza supervisora.
2. 2El stack regulatorio es diferente. El EU AI Act introduce reglas horizontales para sistemas de IA, incluidos requisitos para IA de alto riesgo. DORA introduce un marco vinculante para la resiliencia operativa digital en el sector financiero. GDPR sigue siendo central cuando hay datos personales, profiling o decisiones automatizadas. La regulación bancaria ya exige internal governance robusta, gestión de riesgos, outsourcing oversight y control de modelos. La IA no sustituye ninguno de esos marcos. Los intersecta todos.
3. 3El entorno operativo es diferente. La mayoría de los grandes bancos operan paisajes tecnológicos complejos con sistemas legacy, data ownership fragmentada, múltiples cloud providers, desarrollo externalizado, plataformas regionales, requisitos regulatorios locales y funciones de control superpuestas. La gobernanza de IA no puede diseñarse como un framework académico limpio. Debe funcionar dentro de una realidad empresarial compleja.
4. 4El modelo de accountability es diferente. En banca, nadie creíble debería decir: “El modelo tomó la decisión.” El management sigue siendo responsable. El board sigue siendo responsable del oversight. Risk y Compliance siguen siendo responsables del challenge. Technology sigue siendo responsable de la implementación segura y resiliente. El business sigue siendo responsable del caso de uso y sus resultados. La gobernanza de IA debe hacer visible esa accountability antes de que el modelo entre en producción, no después de que algo haya salido mal.

Un modelo práctico de gobernanza de IA debería comenzar con un principio simple: todo caso de uso material de IA debe tener un owner claramente responsable, un propósito documentado, una clasificación de riesgo definida, fuentes de datos aprobadas, controles técnicos y de negocio, human oversight cuando sea requerido, acuerdos de monitoring y una ruta clara de escalación.

Suena obvio. En la práctica es difícil.

La dificultad no es que los bancos carezcan de funciones de control. La dificultad es que la IA las atraviesa. Data Governance puede ser responsable de la calidad de datos. Technology puede ser responsable de las plataformas. Cyber puede ser responsable de controles de seguridad. Risk puede ser responsable del model risk. Compliance puede ser responsable de interpretación regulatoria. Legal puede ser responsable de contratos y responsabilidad. Procurement puede ser responsable del onboarding de terceros. Audit puede ser responsable de assurance independiente. El business puede ser responsable del use case. El board puede pedir progreso. Sin un modelo integrado de gobernanza de IA, cada función ve solo una parte del riesgo.

La gobernanza de IA es la disciplina que reúne esas partes.

ai-governance-in-banking-2.jpg16:9 · /insights/img/

2El EU AI Act: disparador de gobernanza, no framework autónomo

El EU AI Act se discute a menudo como si fuera toda la historia de la gobernanza de IA. No lo es. Es un disparador importante, pero no el framework completo.

Para los bancos, el AI Act es particularmente relevante porque determinados casos de uso de servicios financieros pueden entrar en la categoría de alto riesgo. El ejemplo más obvio es la evaluación de solvencia crediticia. Según el Anexo III del AI Act, los sistemas de IA utilizados para evaluar la solvencia de personas físicas o establecer su credit score se clasifican como de alto riesgo, excepto cuando el sistema se utiliza para detectar fraude financiero. Esa excepción es importante porque muestra que la clasificación depende no solo de la tecnología, sino también del propósito y del contexto de uso.

Aquí comienza la gobernanza práctica.

Un banco no puede simplemente preguntar si una herramienta es “IA”. Esa es solo la primera pregunta. Debe preguntar qué hace el sistema, quién se ve afectado, si apoya o toma una decisión, si la decisión produce efectos legales o similares significativos, si el caso de uso está ligado a categorías de alto riesgo, si se procesan datos personales, si el modelo se desarrolló internamente o fue proporcionado por un tercero, y si el sistema se utiliza en un proceso bancario regulado.

Un modelo utilizado para productividad interna puede requerir un camino de gobernanza. Un modelo utilizado para segmentación de clientes puede requerir otro. Un modelo utilizado para solvencia crediticia, collections, fraud detection, priorización de alertas AML o reporting regulatorio puede requerir un estándar de evidencia mucho más alto. La tecnología puede parecer similar. La obligación de gobernanza no lo es.

El AI Act refuerza requisitos que los bancos serios ya deberían reconocer: risk management, data governance, documentación técnica, record-keeping, transparencia, human oversight, precisión, robustez y cybersecurity. No son conceptos legales abstractos. Se mapean directamente a disciplinas de control bancario. Risk management se conecta con risk appetite y control assessment. Data governance se conecta con lineage, calidad y uso autorizado. Documentación se conecta con auditabilidad. Record-keeping se conecta con evidencia. Human oversight se conecta con accountability. Robustez y cybersecurity se conectan con resiliencia tecnológica.

Por eso el AI Act no debería implementarse como un silo de cumplimiento separado. Si un banco crea un proyecto AI Act autónomo, desconectado de technology governance, data governance, model risk management, DORA, GDPR y outsourcing oversight, creará duplicación y confusión. El enfoque más estratégico es usar el AI Act como mecanismo de presión para fortalecer el modelo de enterprise AI governance del banco.

El trabajo de mapping de la EBA sobre el AI Act es relevante aquí porque evaluó las implicaciones del AI Act para el sector bancario y de pagos de la UE, con particular atención a sistemas de IA de alto riesgo como solvencia crediticia y credit scoring. El mensaje importante para los bancos es que AI Act readiness no debe tratarse como un universo paralelo. Debe mapearse contra obligaciones sectoriales existentes y expectativas supervisoras.

En términos prácticos, todo banco debería construir un inventario de casos de uso de IA que haga más que listar herramientas. Debería clasificar propósito, grupo de usuarios, población afectada, impacto decisional, categoría de datos, tipo de modelo, fuente de desarrollo, dependencia de terceros, criticidad operacional, relevancia regulatoria y estado de controles. Sin ese inventario, el senior management no puede saber dónde está el riesgo de IA. Sin saber dónde está el riesgo, no puede gobernarlo.

3Actualización Digital Omnibus: cambió el calendario, no la responsabilidad

A 29 de junio de 2026, el Consejo de la Unión Europea dio su aprobación final a medidas específicas de simplificación del AI Act. Según la comunicación del Consejo, la aplicación de las obligaciones de alto riesgo se traslada al 2 de diciembre de 2027 para sistemas de IA stand-alone de alto riesgo y al 2 de agosto de 2028 para sistemas de IA integrados en productos. No puedo confirmar, con las fuentes disponibles aquí, si el reglamento modificativo final ya ha sido publicado en el Diario Oficial de la Unión Europea.

Para los bancos, esto cambia la planificación de implementación, pero no la lógica de gobernanza.

El tiempo adicional no debería usarse para posponer la gobernanza de IA. Debería usarse para construir el inventario, la lógica de clasificación, los controles de datos, el enfoque de model risk, la supervisión de terceros y el reporting al board que la IA escalable requiere de todos modos. La fecha límite puede moverse. La accountability no.

Esto importa porque la adopción de IA no espera a las fechas legales. Los bancos ya despliegan IA en interacción con clientes, detección de fraude, procesos de crédito, productividad interna, desarrollo de software y risk analytics. Si la gobernanza espera hasta la última fecha legal posible, el banco acumulará durante años exposición a IA no clasificada, no documentada y mal controlada.

Un banco serio debería utilizar el calendario modificado como ventaja de planificación, no como excusa para retrasar. La pregunta correcta no es: “¿Hasta cuándo podemos esperar para cumplir?” La pregunta correcta es: “¿Cuán pronto podemos construir un modelo de gobernanza reutilizable que facilite escalar de forma compliant?”

Esa es la diferencia estratégica entre gestionar plazos y ejecutar bajo control.

4DORA: la gobernanza de IA se encuentra con la resiliencia operativa

Las discusiones sobre gobernanza de IA a menudo se centran en fairness, explainability y model risk. Esos temas importan. Pero para los bancos no son suficientes.

DORA hace inevitable la realidad tecnológica. El Reglamento (UE) 2022/2554 establece un marco europeo para la resiliencia operativa digital del sector financiero, incluyendo ICT risk management, incident reporting, operational resilience testing y ICT third-party risk. Esto importa directamente para la IA porque los sistemas de IA dependen cada vez más de infraestructura cloud, APIs, servicios de modelos, proveedores externos de datos, desarrollo externalizado y vendors tecnológicos.

Un banco puede pensar que está implementando un chatbot de atención al cliente. Desde el punto de vista de gobernanza, puede estar introduciendo un nuevo flujo de datos, una nueva dependencia de proveedor, un nuevo problema de access control, un nuevo requisito de monitoring, un nuevo escenario de riesgo operacional y una nueva ruta de incident management. Si el chatbot usa IA generativa, el banco también debe considerar hallucination risk, prompt injection, fuga de información confidencial, logging inadecuado, baja explainability, model drift y dependencia de actualizaciones del modelo del proveedor.

Por eso la gobernanza de IA no puede estar fuera de la resiliencia operativa.

Un framework serio de gobernanza de IA en banca debe hacer preguntas tipo DORA desde el inicio. ¿El sistema de IA soporta un servicio de negocio importante? ¿Depende de un critical ICT third-party provider? ¿Qué ocurre si el servicio de modelo no está disponible? ¿Qué ocurre si los outputs se degradan? ¿Qué ocurre si el vendor cambia el modelo? ¿Qué ocurre si el sistema produce outputs dañinos o engañosos a escala? ¿Qué ocurre si datos sensibles se exponen mediante prompts, embeddings, logs u outputs? ¿Quién lo detecta? ¿Quién decide si es un incidente ICT, un incidente de datos, un problema de modelo, un conduct issue o todo ello?

Estas preguntas definen si la IA está lista para producción.

DORA también cambia la relación entre innovación de IA y third-party risk. Muchas capacidades de IA no serán construidas completamente dentro del banco. Llegarán a través de cloud providers, AI platforms, software vendors, data providers, analytics tools y specialist model services. Eso no es automáticamente un problema. Pero significa que la gobernanza de IA debe integrarse en procurement, outsourcing assessment, ICT risk classification, cláusulas contractuales, exit planning, service monitoring y análisis de concentration risk.

Un banco que trata la selección de vendor de IA como una compra normal de software pierde el punto. La cuestión no es solo si la herramienta funciona. La cuestión es si el banco puede controlar, monitorizar, explicar, desafiar, salir y evidenciar el uso de esa herramienta en un entorno regulado.

Aquí la gobernanza se vuelve práctica. El proceso de aprobación de IA no debería comenzar después de que Procurement seleccione al vendor. Debería comenzar antes de que el banco se comprometa con una arquitectura, un modelo de data-sharing o una dependencia contractual que luego sea difícil de deshacer.

5GDPR y decisiones automatizadas

La gobernanza de IA en banca es imposible sin gobernanza de protección de datos.

GDPR sigue siendo central porque muchos casos de uso de IA bancaria implican datos personales, profiling o decisiones que pueden afectar significativamente a personas. El artículo 22 de GDPR otorga a los individuos el derecho a no ser sujetos a una decisión basada únicamente en tratamiento automatizado, incluido profiling, cuando esa decisión produce efectos legales o similares significativos, sujeto a excepciones y garantías específicas. Esto es directamente relevante cuando la IA se utiliza en crédito, pricing, collections, customer vulnerability, fraud controls u otros procesos decisionales que afectan a clientes.

Pero GDPR no trata solo de decisiones automatizadas. También trata de base jurídica, limitación de finalidad, minimización de datos, transparencia, exactitud, limitación de conservación, integridad, confidencialidad y accountability. Estos principios no son obstáculos a la gobernanza de IA. Son parte de ella.

La Opinión 28/2024 del EDPB es importante porque aborda aspectos de protección de datos relacionados con modelos de IA, incluyendo cuándo y cómo un modelo de IA puede considerarse anónimo, cómo puede evaluarse el interés legítimo como base jurídica en desarrollo y deployment, y qué consecuencias pueden derivarse del tratamiento ilícito en la fase de desarrollo. Para los bancos, esto es especialmente relevante porque data lineage y uso lícito de datos no son preguntas abstractas de privacidad. Determinan si el banco puede defender el ciclo de vida del modelo.

La implicación práctica es clara: la gobernanza de IA debe conectar la aprobación del modelo con la aprobación de datos.

Un modelo no debería aprobarse simplemente porque funciona bien estadísticamente. También debe quedar claro qué datos se usaron, si el banco tiene derecho a usarlos para la finalidad prevista, si hay datos personales, si existen características sensibles o protegidas directa o indirectamente, si proxies pueden crear bias, si la calidad de datos es suficiente, si los periodos de retención están definidos y si el uso de outputs es transparente para los afectados cuando sea requerido.

Esto es especialmente importante para IA generativa y large language models. Muchos bancos comenzaron con casos de uso de productividad interna porque parecían de menor riesgo. Pero incluso herramientas internas pueden procesar información confidencial, datos personales, datos de clientes, código, registros de incidentes, material de RRHH, informes de riesgo o documentos supervisores. Si los empleados pegan información sensible en una herramienta de IA sin controles adecuados, el banco puede crear problemas de privacidad, confidencialidad, propiedad intelectual, seguridad y regulación antes de que exista cualquier caso de uso externo con clientes.

Por eso las acceptable-use policies no son suficientes. Los bancos necesitan guardrails técnicos, logging, access controls, data-loss prevention, training, monitoring y consecuencias claras ante el mal uso. Más importante aún, necesitan alternativas aprobadas y utilizables. Si el entorno oficial de IA es demasiado lento, restrictivo o desconectado de cómo trabajan los empleados, aparecerá shadow AI.

Shadow AI no es una estrategia de innovación. Es un fallo de control.

6Model Risk Management e IA generativa

La gobernanza de IA en banca debe construirse sobre model risk management, pero no puede limitarse al model risk management tradicional.

Los bancos ya entienden la gobernanza de modelos en áreas como credit risk, market risk, liquidity risk, capital models, stress testing e IFRS 9. Conocen la importancia de validation, documentation, monitoring, limitations, change control e independent challenge. Pero la IA introduce complejidad adicional: comportamiento no lineal de modelos, dependencia de datos, menor interpretabilidad, posibilidades de aprendizaje continuo, dependencia de proveedores externos de modelos y nuevas formas de output risk.

El follow-up report de la EBA sobre machine learning para modelos IRB es útil porque muestra cómo se cruzan requisitos prudenciales, GDPR y AI Act cuando se usa machine learning en modelos de riesgo de crédito. La guía revisada de la BCE sobre modelos internos también clarifica expectativas supervisoras sobre el uso de técnicas de machine learning en modelos internos. No son documentos genéricos de ética de IA. Son materiales supervisores específicos de banca que importan para una gobernanza de IA seria.

La lección práctica es que los bancos necesitan un enfoque escalonado de model governance. No todo sistema de IA debería pasar por el mismo proceso de validación que un modelo IRB. Sería inviable. Pero no todo sistema de IA puede tratarse como una simple funcionalidad de software. El framework de gobernanza debe clasificar modelos según materialidad, caso de uso, relevancia regulatoria, impacto decisional, complejidad, sensibilidad de datos, necesidad de explainability, dependencia operacional y daño potencial.

Una herramienta interna de summarisation de bajo riesgo puede requerir acceso controlado, restricciones de datos, logging y acceptable-use monitoring. Un modelo usado para priorización de alertas AML puede requerir validación más fuerte, explainability, bias assessment, performance monitoring y operational back-testing. Un modelo de solvencia crediticia puede requerir un camino de gobernanza mucho más formal porque puede afectar directamente el acceso a recursos financieros y puede caer en una categoría de IA de alto riesgo.

Model risk management también debe evolucionar para IA generativa. La validación tradicional pregunta si el modelo funciona contra métricas definidas sobre datos definidos. La IA generativa añade preguntas más difíciles de reducir a un solo score. ¿El sistema hallucina? ¿Produce outputs plausibles pero incorrectos? ¿Filtra información confidencial? ¿Es vulnerable a prompt injection? ¿Genera respuestas discriminatorias o engañosas? ¿Se comporta de forma diferente entre idiomas? ¿Se degrada cuando el proveedor actualiza el modelo? ¿Puede el banco reproducir outputs? ¿Puede explicar por qué se generó una respuesta? ¿El caso de uso requiere comportamiento determinista o es aceptable un output probabilístico?

Estas preguntas deben responderse antes del deployment, no después de un incidente.

La gobernanza de IA debe definir qué significa “good enough” para cada clase de caso de uso de IA. Si el banco no puede definir criterios de aceptación, no puede gobernar el sistema. Si no puede gobernar el sistema, no debería escalarlo.

ai-governance-in-banking-3.jpg16:9 · /insights/img/

7El inventario de IA: la herramienta de gobernanza más infravalorada

El artefacto más importante de gobernanza de IA en un banco no es la política. Es el inventario.

Sin un inventario de IA, el banco no conoce su exposición. Sin conocer su exposición, no puede clasificar el riesgo. Sin clasificación de riesgo, no puede aplicar controles proporcionales. Sin controles proporcionales, sobrecontrola casos de bajo riesgo o subcontrola casos materiales.

Un inventario de IA serio debería incluir al menos estas dimensiones: use-case owner, proceso de negocio, entidad legal, jurisdicción, grupo de usuarios, población afectada, tipo de modelo, proveedor, fuentes de datos, implicación de datos personales, impacto decisional, materialidad, clasificación AI Act, relevancia GDPR, relevancia DORA, relevancia outsourcing, clasificación model risk, estado de validación, métricas de monitoring, incidentes, limitaciones, riesgo residual y estado de retiro.

El inventario también debe capturar IA integrada en productos de vendors. Esto es fácil de pasar por alto. Los bancos pueden no pensar que están desplegando IA cuando compran software con funcionalidad de IA incorporada. Pero desde una perspectiva de gobernanza, embedded AI puede afectar procesos, decisiones, flujos de datos y dependencias operacionales. La IA del vendor no está fuera de la responsabilidad del banco simplemente porque el modelo esté dentro de un producto tercero.

El inventario también debería separar experimentación de producción. Un proof of concept en una sandbox no es lo mismo que una herramienta usada por cientos de empleados o un modelo que afecta resultados de clientes. Pero los pilotos también necesitan gobernanza. Necesitan límites: datos aprobados, entornos aprobados, límites de tiempo, exit criteria y reglas para pasar a producción.

El movimiento de piloto a producción es uno de los momentos de mayor riesgo en la gobernanza de IA. Muchos fallos ocurren porque un caso de uso que empezó informalmente se vuelve operacional sin pasar por un control gate adecuado. Una demo se convierte en workflow. Un workflow se convierte en dependencia. Una dependencia se convierte en problema de control.

La gobernanza de IA debe hacer visible esa transición.

8Human Oversight más allá de la checkbox

Human oversight es uno de los conceptos más repetidos en la gobernanza de IA. También es uno de los más malinterpretados.

Un banco no debería afirmar que tiene meaningful human oversight simplemente porque una persona aparece en alguna parte del proceso. Human oversight debe diseñarse. El revisor humano debe entender el propósito del sistema de IA, las limitaciones del modelo, el contexto decisional, los criterios de escalación y las circunstancias bajo las cuales el output de IA debe ser cuestionado o anulado.

Esto es especialmente importante en banca porque los empleados pueden confiar excesivamente en outputs de IA cuando parecen precisos, técnicos o seguros. Una recomendación de crédito, un fraud score, una priorización AML, un customer-risk summary o una anomalía de reporting regulatorio puede parecer objetiva porque fue generada por un modelo. Pero el output del modelo no es verdad. Es una estimación estructurada producida bajo supuestos, limitaciones de datos y decisiones de diseño.

Human oversight debe conectarse con training, diseño de procesos, derechos de decisión y accountability. ¿Quién puede overrular el sistema de IA? ¿Cuándo debe hacerlo? ¿Qué evidencia se requiere? ¿Se monitorizan los overrides? ¿Se revisan patrones de overrides? ¿El revisor humano es suficientemente independiente? ¿Existe automation bias? ¿El proceso permite suficiente tiempo para una revisión real, o el humano solo rubrica el output del modelo?

Es fácil escribir “human in the loop” en una política. Es mucho más difícil diseñar un proceso donde el humano tenga realmente competencia, autoridad y tiempo para desafiar a la máquina.

Para casos de uso bancarios de alto impacto, esa diferencia es decisiva.

9Explainability: no todos los modelos necesitan la misma explicación

Explainability es otra área donde los bancos necesitan disciplina práctica.

No todo sistema de IA requiere el mismo nivel de explicación. Un modelo usado para enrutar tickets internos no requiere la misma explainability que un modelo usado para apoyar una evaluación de solvencia crediticia. Un asistente de IA generativa que resume políticas internas no requiere el mismo estándar de explicación que un modelo usado en clasificación de riesgos. Pero todo sistema de IA material necesita un estándar de explicación adecuado a su uso.

Explainability debería definirse por audiencia y propósito. Un data scientist puede necesitar explicación técnica. Un model validator puede necesitar drivers de performance, limitaciones y sensitivity analysis. Un business user puede necesitar reason codes y lógica decisional. Un cliente puede necesitar información comprensible sobre cómo se tomó una decisión que le afecta. Un supervisor puede necesitar evidencia de que el banco entiende, controla y monitoriza el sistema.

Un único método de explicación no satisfará todas estas necesidades.

Para los bancos, explainability debe conectarse con accountability. Si nadie puede explicar el modelo suficientemente bien para desafiarlo, el banco debería ser prudente al desplegarlo en procesos decisionales materiales. Eso no significa que solo puedan usarse modelos simples. Significa que el banco debe poder justificar por qué un modelo es adecuado para el caso de uso, cómo se controlan sus limitaciones, cómo se monitorizan outputs y cómo se protege a los stakeholders afectados.

El BIS Financial Stability Institute ha identificado la regulación de IA en servicios financieros como un área activa de desarrollo supervisor, incluyendo model risk, data privacy, explainability y riesgos específicos de IA generativa como hallucination.

La pregunta correcta no es: “¿Podemos explicar el modelo perfectamente?” La pregunta correcta es: “¿Podemos explicarlo suficientemente para la decisión que apoya y el riesgo que crea?”

10Third-Party AI y Embedded Vendor AI

La third-party AI será uno de los retos de gobernanza más difíciles para los bancos.

Muchos bancos dependerán de proveedores externos para foundation models, cloud infrastructure, AI platforms, vendor applications, data services, monitoring tools y analytics especializados. Es racional. Ningún banco debería asumir que puede construir internamente toda capacidad de IA. Pero el uso de terceros no transfiere accountability fuera del banco.

El Financial Stability Board ha identificado third-party dependencies, market correlations, cyber risks y desafíos en model risk y governance como vulnerabilidades relacionadas con IA con potenciales implicaciones para la estabilidad financiera. Esto es muy relevante para bancos porque la adopción de IA puede concentrar dependencias en un pequeño número de proveedores tecnológicos y cloud.

Desde una perspectiva de gobernanza, third-party AI crea varias preguntas.

¿Sabe el banco si el producto del vendor incluye IA? ¿Permite el contrato al banco entender el rol, las limitaciones y el ciclo de actualización del modelo? ¿Puede el banco restringir el uso de datos? ¿Puede impedir que el vendor use datos del banco para entrenamiento? ¿Hay logs disponibles? ¿Puede el banco testear outputs? ¿Proporciona el vendor documentación suficiente? ¿Qué ocurre cuando el vendor cambia el modelo? ¿Qué ocurre si el proveedor retira el servicio? ¿Existe un exit plan? ¿Hay concentration risks en todo el banco? ¿Varios procesos críticos dependen del mismo proveedor?

Estas preguntas no deberían hacerse solo para critical outsourcing arrangements. Deberían formar parte de la AI vendor governance de forma más amplia, con proporcionalidad según materialidad.

Los equipos de Procurement necesitan AI literacy. Los equipos Legal necesitan posiciones contractuales específicas para IA. Los equipos Technology necesitan estándares de arquitectura. Los equipos Risk necesitan clasificación de vendor risk. Los equipos business deben entender que comprar IA no es lo mismo que comprar software ordinario.

El riesgo de vendor AI más peligroso no siempre es el más visible. A veces es la funcionalidad de IA oculta dentro de una plataforma que el banco ya utiliza. Un vendor introduce una nueva función de IA. Un equipo business la activa. Los datos comienzan a moverse. Los outputs entran en un workflow. Nadie actualiza el inventario. Nadie evalúa el riesgo. Nadie informa al board.

Así es como shadow AI se convierte en riesgo institucional.

11Business Value y el kill mechanism

La gobernanza de IA no debería diseñarse solo alrededor del riesgo. Eso sería incompleto.

Los bancos necesitan IA porque necesitan mayor productividad, mejor customer experience, detección de fraude más fuerte, desarrollo de software más rápido, risk analytics mejorado, controles más eficientes y mejor uso de datos. Un modelo de gobernanza que solo bloquea IA fracasará. Empujará la innovación a canales informales o hará al banco estratégicamente más lento.

El modelo correcto de gobernanza debe conectar control de riesgo con creación de valor.

Todo caso de uso material de IA debería tener un business case. ¿Qué problema resuelve? ¿Qué proceso mejora? ¿Qué coste reduce? ¿Qué riesgo mitiga? ¿Qué resultado de cliente mejora? ¿Qué debilidad de control aborda? ¿Qué métrica probará que el caso de uso funciona?

Sin esa disciplina, la IA se convierte en teatro.

Los bancos son especialmente vulnerables al AI theatre porque la presión ejecutiva es alta. Toda institución quiere mostrar que está activa en IA. Toda función quiere un caso de uso. Todo vendor afirma tener capacidad de IA. Toda presentación estratégica incluye una slide sobre IA generativa. Pero actividad no es transformación.

Un banco con cincuenta pilotos y sin modelo de control escalable no está adelantado. Está expuesto.

Un banco con menos casos de uso, pero una plataforma clara, data pipelines gobernados, approval paths reutilizables, beneficios medibles y deployment de producción controlado puede estar en una posición mucho más fuerte. El objetivo no es maximizar el número de experimentos de IA. El objetivo es operacionalizar IA donde crea valor y puede controlarse.

Por eso la gobernanza de IA debería incluir un kill mechanism. No todo caso de uso de IA debería sobrevivir. Si un caso de uso no crea valor medible, no puede controlarse, duplica capacidades existentes, aumenta complejidad o crea riesgo desproporcionado, debería detenerse. La gobernanza madura no trata solo de aprobación. También trata de terminación.

ai-governance-in-banking-4.jpg16:9 · /insights/img/

12La gobernanza de IA como enterprise capability

Los bancos que escalen IA con éxito tratarán la gobernanza de IA como enterprise capability.

Eso significa que el banco tiene una taxonomía común de IA. Sabe qué cuenta como IA, qué cuenta como IA generativa, qué cuenta como modelo, qué cuenta como high impact, qué cuenta como uso en producción y qué cuenta como uso prohibido o restringido.

Significa que el banco tiene un inventario controlado. No diez hojas de cálculo. No registros dispersos en Risk, Technology, Data y Compliance. Una vista fiable de adopción de IA y riesgo.

Significa que el banco tiene approval pathways basados en riesgo. Las herramientas de productividad de bajo riesgo pasan por un proceso proporcional. Los sistemas decisionales de alto impacto reciben revisión más profunda. La third-party AI se evalúa antes de la adopción. Los cambios materiales disparan re-approval.

Significa que el banco tiene una AI control library. Data controls, access controls, logging, monitoring, bias testing, explainability, cyber testing, vendor controls, incident triggers y human oversight no se reinventan para cada caso de uso.

Significa que el banco tiene AI literacy a múltiples niveles. Los miembros del board necesitan suficiente comprensión para desafiar al management. Los senior executives necesitan suficiente comprensión para asumir decisiones. Las funciones de control necesitan suficiente comprensión para evaluar riesgo. Los empleados necesitan suficiente comprensión para usar herramientas de forma segura.

Significa que el banco tiene métricas. La gobernanza de IA sin métricas se convierte en narrativa. El banco debería rastrear casos de uso de IA por estado, clase de riesgo, business line, entidad legal, proveedor, madurez de control, issues, incidentes, valor entregado y hallazgos de auditoría.

Significa que el banco tiene assurance. Internal audit no debería esperar hasta que la IA ya haya escalado informalmente. Debería testear el governance framework, la completitud del inventario, el diseño de controles, la evidencia de aprobación, el monitoring y la issue remediation.

Significa que el banco tiene un management rhythm. La gobernanza de IA debería revisarse regularmente en el foro ejecutivo adecuado, escalarse al board cuando sea material y conectarse con estrategia, inversión tecnológica y risk appetite.

Los frameworks externos pueden apoyar este trabajo. ISO/IEC 42001:2023 especifica requisitos y guía para establecer, implementar, mantener y mejorar continuamente un AI management system. El NIST AI Risk Management Framework y el Generative AI Profile proporcionan una referencia estructurada para AI risk management, incluidos riesgos de IA generativa.

Pero un banco no debería confundir framework alignment con regulatory readiness. ISO y NIST pueden apoyar el sistema de gestión, pero no sustituyen el EU AI Act, DORA, GDPR, expectativas EBA, supervisión BCE, obligaciones de internal governance o requisitos regulatorios locales.

El mejor enfoque es usar frameworks externos como andamiaje, no como el edificio en sí.

13Qué deberían preguntar ahora los boards

Boards y senior executives no deberían esperar un framework perfecto de gobernanza de IA antes de hacer mejores preguntas. Pueden empezar ahora.

• Deberían preguntar: ¿tenemos un inventario completo de IA, incluyendo third-party y embedded AI?
• Deberían preguntar: ¿qué casos de uso de IA podrían afectar materialmente a clientes, empleados, decisiones de riesgo, financial crime controls, reporting regulatorio, capital o resiliencia operativa?
• Deberían preguntar: ¿qué sistemas de IA podrían caer en categorías de alto riesgo bajo el EU AI Act, y qué evidencia respalda esa clasificación?
• Deberían preguntar: ¿cómo se conecta la gobernanza de IA con DORA, GDPR, outsourcing, model risk management e internal governance?
• Deberían preguntar: ¿quién es owner end to end de cada sistema material de IA?
• Deberían preguntar: ¿puede el management evidenciar calidad de datos, uso lícito de datos, performance del modelo, human oversight, monitoring e issue management?
• Deberían preguntar: ¿qué dependencias de third-party AI están emergiendo, y dónde podría aparecer concentration risk?
• Deberían preguntar: ¿dónde se utiliza ya IA generativa por parte de empleados, y cómo se previene shadow AI?
• Deberían preguntar: ¿qué valor medible ha entregado la IA, y qué casos de uso deberían detenerse?
• Deberían preguntar: ¿cuándo revisará internal audit el framework de gobernanza de IA?

Estas preguntas no están diseñadas para ralentizar la IA. Están diseñadas para hacerla real.

14Conclusión

La gobernanza de IA en banca se malinterpreta a menudo. Se trata como carga regulatoria, checklist de cumplimiento o capa defensiva de control. Esa visión es demasiado limitada.

En un banco europeo, la gobernanza de IA es el mecanismo que permite escalar IA sin socavar accountability, resiliencia, protección de datos, control de modelos o confianza supervisora.

Las instituciones que fallen no serán necesariamente las que se muevan lentamente. Algunas se moverán rápido, pero sin control. Otras construirán documentos complejos de gobernanza que no cambian la toma de decisiones. Ambos enfoques se atascarán.

Las instituciones que tengan éxito harán algo más difícil. Conectarán la estrategia de IA con el modelo operativo del banco. Sabrán dónde se usa la IA. Clasificarán el riesgo de forma coherente. Gobernarán datos y modelos juntos. Controlarán dependencias de terceros. Harán significativo el human oversight. Proporcionarán al board evidencia, no slogans. Detendrán casos de uso débiles y escalarán los fuertes.

Esa es la diferencia entre experimentación de IA y transformación de IA.

Un banco puede comprar herramientas de IA. Puede comprar plataformas cloud. Puede comprar acceso a modelos. Puede comprar apoyo de consultoría. Pero no puede comprar accountability. No puede externalizar juicio. No puede delegar confianza.

La gobernanza de IA en banca no es, por tanto, el lado administrativo de la IA. Es la disciplina de liderazgo que determina si la IA se convierte en una enterprise capability controlada o en otra capa de complejidad no gestionada.

La próxima división competitiva en la banca europea no será entre bancos que usan IA y bancos que no la usan. Casi todas las instituciones serias la usarán. La división será entre bancos que pueden gobernar IA a escala y bancos que siguen atrapados entre innovation theatre e incomodidad supervisora.

La gobernanza de IA es donde esa división se hará visible.

15Fuentes

La base factual y regulatoria de este artículo incluye: el EU AI Act y su lógica de clasificación de alto riesgo, incluido el Anexo III; la comunicación del Consejo del 29 de junio de 2026 sobre la simplificación del AI Act y los calendarios ajustados para obligaciones de alto riesgo; DORA y su marco de ICT risk y third-party risk; GDPR, incluidas decisiones automatizadas bajo el artículo 22; la Opinión 28/2024 del EDPB sobre modelos de IA y datos personales; material de la EBA sobre adopción de IA e implicaciones del AI Act para banca y pagos; material de la BCE sobre modelos internos y machine learning; material del FSB sobre vulnerabilidades de IA para la estabilidad financiera; trabajos BIS/FSI sobre regulación de IA en servicios financieros; ISO/IEC 42001:2023; y el NIST AI Risk Management Framework junto con el Generative AI Profile.