Explicabilidad y auditabilidad de la IA en finanzas

Por Jane Ha · Actualizado el 11 de octubre de 2026

La explicabilidad y la auditabilidad de la IA en finanzas implican dos promesas distintas: usted puede decir por qué el sistema produjo un resultado específico (explicabilidad) y puede demostrar después qué hizo el sistema, con qué datos de entrada, bajo qué versión y quién lo revisó (auditabilidad). Los reguladores, los auditores y los clientes se apoyan cada uno en una mitad diferente. Un solicitante de crédito quiere el motivo de un rechazo. Un auditor quiere el rastro de evidencia. Un equipo de riesgo de modelos quiere ambas cosas, además de la prueba de que alguien independiente cuestionó el modelo.

Esta guía está dirigida a CFOs, contralores (controller), responsables de riesgo y gerentes de finanzas que están incorporando IA en trabajos de crédito, fraude, pronósticos, cierre o reportes. Si busca la definición en lenguaje sencillo de la técnica en sí, lea ¿Qué es la IA explicable?. Este artículo trata la parte específica de finanzas: qué hay que explicar, a quién y qué debe tener archivado.

Datos clave

• La Regulation B exige que una declaración de motivos de una acción crediticia adversa «must be specific and indicate the principal reason(s)» (debe ser específica e indicar los motivos principales), y las declaraciones basadas en estándares internos o en un umbral fallido de puntuación crediticia no son suficientes (12 CFR 1002.9).
• La guía interinstitucional de riesgo de modelos de abril de 2026, SR 26-2, sustituye a SR 11-7 y se espera que sea más relevante para las organizaciones bancarias con más de 30 000 millones de dólares en activos totales (Federal Reserve).
• Esa guía deja fuera de su alcance los modelos de IA generativa y agéntica, mientras que sus principios se aplican a los modelos estadísticos tradicionales y a la IA no generativa ni agéntica (anexo de SR 26-2).
• La EU AI Act clasifica como de alto riesgo los sistemas de IA destinados a evaluar la solvencia de personas físicas o a establecer su puntuación crediticia, y exige que dichos sistemas permitan técnicamente el registro automático de eventos (logs) durante toda su vida útil (Anexo III, Artículo 12).
• NIST distingue ambas ideas: la explicabilidad es una representación de los mecanismos que subyacen al funcionamiento de un sistema, mientras que la interpretabilidad es el significado de su resultado en el contexto de su propósito de diseño (NIST AI RMF 1.0).

Por qué las finanzas exigen más a la IA

La mayoría de las funciones del negocio puede convivir con un modelo que funciona pero no puede decir por qué. Las finanzas, en general, no pueden, por tres razones.

Las decisiones conllevan obligaciones legales. Cuando un prestamista rechaza a un solicitante, las normas de Estados Unidos exigen un motivo específico. El motivo debe reflejar lo que realmente impulsó la decisión, no una etiqueta genérica.

Las cifras alimentan estados en los que la gente confía. Si un modelo fija una reserva, redacta una explicación de fluctuaciones (flux) o concilia partidas del libro mayor, alguien debe poder mostrar al auditor cómo llegó a existir esa cifra. El lado de los controles se trata en la IA y los controles internos. Este artículo cubre la capa subyacente: la documentación y los registros que hacen que un control sea verificable.

Los errores son costosos y lentos de encontrar. Un pronóstico con deriva o un modelo de puntuación sesgado pueden operar durante meses antes de que alguien lo note, y la única manera de reconstruir lo ocurrido es haber conservado los registros.

Qué esperan realmente los reguladores y los auditores

Las expectativas varían según la jurisdicción y el caso de uso, por lo que conviene separarlas.

Decisiones de crédito (EE. UU.). La Regulation B, que implementa la Equal Credit Opportunity Act, exige que un acreedor informe al solicitante rechazado los motivos principales en términos específicos. La norma otorga al acreedor 30 días tras recibir una solicitud completa para notificar al solicitante la acción tomada (12 CFR 1002.9). La consecuencia práctica para la IA: si su modelo no puede producir motivos que usted pueda respaldar, tiene un problema de cumplimiento, por muy preciso que sea el modelo. Las herramientas de explicación a posteriori aproximan un modelo en lugar de reproducirlo, de modo que el equipo debe poder comprobar que la aproximación es fiel.

Gestión del riesgo de modelos (bancos de EE. UU.). La guía de 2011, SR 11-7, fue sustituida por SR 26-2, que adopta un enfoque basado en riesgos y afirma que el cuestionamiento efectivo es un análisis crítico realizado por expertos objetivos, con la experiencia adecuada, suficiente independencia y la autoridad para lograr que se hagan cambios. También señala que un inventario de modelos eficaz contiene información suficiente para entender el riesgo de modelos a nivel individual y agregado, y que una documentación adecuada respalda una gestión eficaz del riesgo de modelos (SR 26-2). La guía excluye de su alcance la IA generativa y agéntica, pero también dice que las propias prácticas de gobierno de un banco deben orientar los controles de las herramientas que no cubre. Si usted es una institución más pequeña o un equipo de finanzas corporativas, trátela como una plantilla bien probada y no como un reglamento.

Modelos de proveedores. La misma guía indica que la buena práctica incluye entender la solidez conceptual, el diseño, los datos de desarrollo y el desempeño de un modelo de proveedor, y monitorear sus resultados, incluso cuando el proveedor se niegue a entregar el código o los datos (SR 26-2). «El proveedor dice que es preciso» no es documentación.

UE. La puntuación crediticia de personas físicas es un uso de alto riesgo según el Anexo III de la AI Act, y los sistemas de alto riesgo deben permitir técnicamente el registro automático durante toda su vida útil (Anexo III, Artículo 12). El calendario de la ley se ha modificado, y el texto consolidado vigente indica el 2 de diciembre de 2027 como fecha de aplicación para los sistemas del Anexo III (Artículo 12). Los equipos legales deben confirmar la situación en su propio caso, pero la lección de ingeniería es la misma en ambos supuestos: construya el registro ahora, porque incorporarlo después es más difícil.

Auditores de información financiera. Los auditores externos no piden los detalles internos del modelo en abstracto. Quieren saber que el paso de IA es una parte conocida y con responsable de un proceso documentado, con evidencia de que alguien verificó el resultado.

Explicabilidad por función: qué significa «explicado» en la práctica

«Explicable» no es una sola cosa. La explicación adecuada depende de quién pregunta y de lo que está en juego.

El patrón de la tabla es el mismo en todas las filas. La explicación trata de los impulsores y la base; la auditabilidad trata del registro. Un modelo puede tener una sin la otra: un evaluador sencillo basado en reglas es fácil de explicar, pero sigue siendo inútil para un auditor si no deja ningún registro.

La caja de herramientas de explicación y sus límites

Dos técnicas aparecen constantemente en los modelos complejos. SHAP «assigns each feature an importance value for a particular prediction» (asigna a cada variable un valor de importancia para una predicción concreta) (Lundberg y Lee). LIME explica una predicción individual ajustando un modelo simple e interpretable en el entorno de esa predicción, tratando el modelo subyacente como una caja negra (Ribeiro et al.).

Ambas son útiles para la pregunta «por qué este resultado». Ninguna sustituye al gobierno del modelo, por tres razones:

• Explican una predicción, no la idoneidad del modelo. Una explicación limpia de una puntuación sesgada sigue siendo una puntuación sesgada.
• Son aproximaciones. Trate el resultado como evidencia que debe validarse, no como el razonamiento real del modelo.
• No producen por sí solas un motivo listo para el cliente. Alguien tiene que traducir las contribuciones de los factores a los motivos principales que una notificación pueda declarar con exactitud.

En las decisiones de alto riesgo, vale la pena comprobar si un modelo más simple cede poca precisión, porque un modelo que se puede inspeccionar directamente es más fácil de defender que uno que hay que aproximar.

Documentación que resiste el escrutinio: fichas de modelo e inventarios

Una ficha de modelo (model card) es un documento breve que acompaña a un modelo. La propuesta original describe las fichas como documentación del desempeño medido en distintas condiciones, el contexto de uso previsto y cómo se realizó la evaluación, para que los usuarios sepan dónde funciona el modelo y dónde no (Mitchell et al.). Los autores se centran en visión y lenguaje, y afirman que la idea se aplica a cualquier modelo entrenado. Para un equipo de finanzas, la idea es directamente trasladable. Consulte las fichas de modelo de IA para conocer el formato general.

Una versión para finanzas podría incluir:

1. Propósito y responsable. Qué decisión o proceso respalda y el responsable de negocio designado.
2. Uso previsto y uso fuera de alcance. Por ejemplo: «califica solicitudes de consumo sin garantía; no es para préstamos a pequeñas empresas».
3. Datos. Fuentes de entrenamiento, ventana de tiempo, brechas conocidas y las exclusiones que aplicó.
4. Método en un párrafo. Tipo de modelo, variables clave y cómo los resultados se convierten en decisiones.
5. Desempeño. Medidas de precisión, tolerancia, resultados por segmento y el backtest frente a los resultados reales.
6. Método de explicación. Cómo se producen los motivos o impulsores y qué tan fieles se demostró que son.
7. Límites y modos de falla conocidos. Dónde es débil y qué activa el manejo manual.
8. Controles. Revisor, umbrales, plan alterno si el modelo deja de funcionar e historial de cambios.
9. Validación. Quién lo cuestionó, cuándo y qué encontró.

Combine las fichas con un inventario: una lista única de todos los modelos y herramientas de IA en uso, con responsable, propósito, nivel y ubicación de la ficha. La propia SR 26-2 señala que un inventario eficaz contiene información suficiente para entender el riesgo de modelos, que es la prueba que debe aplicar al suyo. En el caso de las herramientas de proveedores, la ficha quedará parcialmente vacía. Déjelo por escrito en lugar de dejar el campo en blanco, y decida si las brechas son aceptables para el nivel de riesgo.

Pistas de auditoría: el registro de lo que realmente ocurrió

La documentación dice lo que se supone que hace un sistema. Una pista de auditoría muestra lo que hizo en un día determinado. El principio de registro de la norma de la UE es un buen estándar general: registrar los eventos durante la vida útil del sistema, de modo que se apoyen el monitoreo y la investigación (Artículo 12). Para un tratamiento más profundo de las pistas cuando la IA ejecuta acciones dentro de los sistemas, consulte las pistas de auditoría de las acciones de IA.

Una pista de auditoría financiera útil captura, para cada partida material influida por la IA:

• Datos de entrada: los datos o el documento que recibió el sistema, o un puntero a ellos
• Versión: el modelo, el prompt o el conjunto de reglas, y la configuración vigente en ese momento
• Resultado: la puntuación, el asiento, la alerta o el texto producido
• Explicación: los impulsores o motivos generados junto con el resultado
• Acción humana: quién lo revisó, qué cambió o anuló y cuándo
• Resultado posterior: la decisión, la contabilización o la notificación que siguió

La retención debe corresponder al registro que respalda. Pregunte a sus equipos de registros y legal por cuánto tiempo deben conservarse los expedientes de crédito, el soporte de asientos y los papeles de trabajo, y asegúrese de que los logs de IA no se eliminen antes. El manejo de datos de estos logs es un tema aparte, tratado en la seguridad de los datos financieros con IA.

Cómo construir explicabilidad y auditabilidad, paso a paso

1. Haga un inventario de cada modelo y herramienta de IA en finanzas. Incluya las funciones de proveedores activadas dentro de los sistemas existentes. No se puede documentar lo que no se ha encontrado.

   

2. Clasifique por niveles según las consecuencias. Un modelo que define el resultado crediticio de un cliente o una reserva pertenece a un nivel más estricto que una herramienta que redacta un resumen interno.

3. Fije el requisito de explicación por nivel. Indique quién debe poder obtener una explicación, con qué rapidez y en qué forma (notificación al cliente, vista del analista, papel de trabajo del auditor).

4. Elija modelos pensando en el requisito. Para los usos de nivel superior, compruebe si un modelo más transparente es casi igual de preciso antes de aceptar una caja negra.

5. Redacte la ficha del modelo antes de la puesta en marcha. Condicione la aprobación del lanzamiento a una ficha completa y a un responsable designado.

6. Obtenga un cuestionamiento independiente. Alguien con la experiencia y la independencia adecuadas revisa el modelo y su método de explicación, y puede exigir cambios.

7. Active el registro desde el primer día. Capture datos de entrada, versiones, resultados, explicaciones y acciones humanas. Compruebe que puede reconstruir una decisión individual de principio a fin a partir de los logs.

8. Haga un simulacro de reconstrucción. Elija diez decisiones pasadas al azar y pida a alguien ajeno al equipo de desarrollo que explique cada una solo con los registros. Las brechas salen a la luz rápidamente.

9. Monitoree y vuelva a documentar. Dé seguimiento a la precisión, la deriva y las tasas de anulación. Actualice la ficha y vuelva a cuestionar el modelo cuando cambien el modelo, los datos o el uso. Consulte los controles de precisión de la IA en finanzas para ideas de monitoreo.

Errores comunes

• Explicar el modelo pero no la decisión. La importancia global de las variables no responde por qué se rechazó a este solicitante o por qué se marcó este asiento.
• Motivos genéricos. Enviar el motivo de la lista de verificación más cercano cuando el verdadero impulsor es otro no supera la prueba de especificidad de la Regulation B.
• Confiar ciegamente en la herramienta de explicación. Los métodos a posteriori aproximan el comportamiento. Pruébelos con casos conocidos.
• La ficha del modelo como un PDF de una sola vez. Una ficha que no cambia cuando cambia el modelo se convierte en un registro falso.
• Logs sin versiones. Saber cuál fue el resultado no sirve si no puede saber qué modelo o prompt lo produjo.
• Aceptar por defecto la opacidad del proveedor. «Propietario» es una razón para monitorear los resultados con más rigor, no para omitir la documentación.
• Revisión sin evidencia. Un revisor que aprueba pero no deja constancia de lo que verificó no le da nada al auditor para probar.
• Explicabilidad construida después del lanzamiento. Incorporar a posteriori los logs y la documentación cuesta mucho más que diseñarlos desde el inicio.

Qué medir

• Cobertura: proporción de modelos y herramientas de IA con responsable, nivel y ficha vigente
• Tasa de reconstrucción: proporción de las decisiones muestreadas que pueden explicarse por completo solo a partir de los logs
• Calidad de la explicación: con qué frecuencia los revisores o validadores rechazan los motivos generados por inexactos o demasiado vagos
• Tasa de anulación: con qué frecuencia las personas cambian el resultado y por qué
• Actualización: tiempo transcurrido desde la última actualización de cada ficha y validación, frente al historial de cambios
• Cierre de hallazgos: tiempo para resolver los hallazgos de validación y auditoría

Siguientes pasos

Comience con el inventario y la clasificación por niveles, luego redacte fichas para su nivel superior y haga un simulacro de reconstrucción. Si todavía está identificando dónde encaja la IA, la IA en finanzas y contabilidad ofrece una visión más amplia.