La gestión del riesgo de modelo de IA en 2026

Por Jonas Mohamed Osman Abdelghafour.

La orientación supervisora para 2026 es inequívoca: adoptar inteligencia artificial no crea una exención de la gestión del riesgo de modelo. Crea obligaciones adicionales. Mientras que un scorecard de crédito tradicional podía documentarse en treinta páginas y validarse frente a una población estable, un sistema de IA puede reentrenarse semanalmente, depender de un modelo fundacional de terceros, ingerir texto no estructurado y producir resultados que ningún revisor puede rastrear hasta un coeficiente. Nada de eso cambia la pregunta subyacente que un banco debe poder responder: quién es propietario de este modelo, qué decisión impulsa, cómo sabemos que sigue funcionando, y qué ocurre cuando deja de hacerlo.

Empezar por el inventario, no por el algoritmo

La mayoría de los fallos de gestión del riesgo de modelo de IA en los bancos son, ante todo, fallos de inventario. Una herramienta construida dentro de una línea de negocio —un asistente de resumen de documentos en crédito, un clasificador de triaje en delitos financieros, un motor de sugerencia de precios en banca comercial— se despliega como "software de productividad" y nunca entra en el inventario de modelos. Entonces nunca se valida, nunca se supervisa y nunca se revisa cuando el proveedor cambia la versión subyacente del modelo.

El remedio es una definición de modelo basada en la materialidad que esté redactada para capturar sistemas que influyen en el juicio, no solo estimadores cuantitativos. Si un resultado cambia una decisión de préstamo, de tarificación, de provisión, de capital o de resultado del cliente, entra en el alcance, lo llame o no "modelo" el negocio. La clasificación por niveles hace entonces el trabajo: el nivel más alto atrae validación independiente completa, el nivel más bajo atrae registro, un propietario responsable y revisión periódica.

Propiedad y gestión del cambio

Los sistemas de IA rompen el ciclo de validación anual. Un modelo cuyos pesos, prompts, corpus de recuperación o versión de proveedor pueden cambiar entre reuniones de comité necesita una gestión del cambio continua, no dictada por el calendario. Tres controles soportan la mayor parte del peso:

• Fijación de versiones y puertas de lanzamiento (release gates). Ningún cambio en producción —incluida una actualización silenciosa del modelo por parte de un proveedor— sin una evaluación registrada del impacto frente al uso aprobado.
• Pruebas de regresión sobre un conjunto de referencia (golden set). Un conjunto de evaluación congelado y representativo, ejecutado en cada cambio, con umbrales de aprobación acordados de antemano por la segunda línea.
• Restricciones de uso documentadas. La aprobación establece para qué puede y no puede usarse el modelo, y el entorno de control lo hace cumplir.

Qué debería comprobar realmente la validación independiente

El cuestionamiento efectivo sobre un modelo de IA no es una repetición del desarrollo. Los revisores aportan más valor atacando los supuestos que los desarrolladores no pudieron probar por sí mismos: si la población de entrenamiento sigue pareciéndose a la población en vivo, si el linaje de datos es defendible, si el rendimiento se mantiene en segmentos protegidos y comercialmente sensibles, si el modelo se degrada de forma progresiva o catastrófica en el límite de su distribución de entrada, y si el humano en el bucle es realmente capaz de anular el resultado o simplemente lo sella sin más.

La explicabilidad merece un escepticismo particular. Los métodos de atribución a posteriori son diagnósticos útiles y evidencia débil. Un informe de validación que se apoya en un gráfico de importancia de variables, sin un análisis de estabilidad de ese gráfico, no ha demostrado que el modelo esté comprendido.

Riesgo de terceros y de concentración

Muy pocos bancos entrenan modelos de frontera. La mayoría los consumen, lo que convierte el riesgo de modelo en riesgo de terceros y de concentración. Si varios procesos críticos dependen de un único proveedor, el banco ha creado un punto único de fallo que su propia gobernanza de modelos no puede ver. Los derechos contractuales a la evidencia, la notificación de cambios materiales del modelo, los planes de salida y sustitución, y una visión documentada de qué ocurre si el servicio se retira o se degrada pertenecen a la evaluación de riesgo junto con las métricas de rendimiento.

Informes que un consejo pueda utilizar

Los consejos no necesitan recuentos de modelos. Necesitan saber qué decisiones están ahora materialmente influidas por la IA, cuánta exposición hay detrás, dónde está derivando el rendimiento, qué hallazgos siguen abiertos más allá de su fecha de remediación, y qué hará la dirección si falla un modelo o proveedor clave. Una página que responda a esas cinco preguntas vale más que un anexo de cincuenta páginas.

Lista de verificación práctica

• Definir los modelos por influencia en la decisión, no por técnica, y clasificarlos por materialidad.
• Registrar todo sistema de IA con un propietario responsable designado antes de su despliegue.
• Bloquear todo cambio —incluidas las actualizaciones de proveedor— tras pruebas de regresión.
• Validar supuestos, linaje de datos, rendimiento por segmento y modos de fallo; tratar la salida de explicabilidad como diagnóstico, no como prueba.
• Cartografiar la concentración de proveedores y mantener un plan de sustitución viable.
• Informar sobre la deriva, los hallazgos abiertos y las acciones de gestión en términos de decisión.

La ventaja competitiva en 2026 no es la sofisticación del modelo. Es la capacidad de demostrar, rápida y creíblemente, que un modelo sofisticado está bajo control —porque los modelos gobernados son los que reguladores, auditores y proveedores de capital dejarán realmente usar a un banco.

Fuentes principales: PRA SS1/23 (principios de gestión del riesgo de modelo para bancos); FSB, Sound Practices for the Responsible Adoption of AI, junio de 2026; Informe de Evaluación de Riesgos de la EBA, junio de 2026.