Cómo demostrar que tu modelo de IA cumple: métricas de sesgo y evidencia para el regulador

Un modelo de inteligencia artificial puede alcanzar buenos niveles de desempeño, generar impacto en el negocio y estar técnicamente preparado para llegar a producción. Sin embargo, en sectores regulados, estos aspectos pueden no ser suficientes para cumplir con las exigencias de la normativa vigente.

Bancos, aseguradoras y otras organizaciones que trabajan con información sensible necesitan ir un paso más allá y contar con evidencia que permita demostrar cómo se comporta el modelo de IA frente a diferentes grupos, con qué información fue construido y qué recorrido siguieron los datos hasta llegar a un resultado. Esta capacidad de reconstrucción y trazabilidad resulta fundamental para responder con evidencia concreta ante un eventual requerimiento del organismo regulador.

La incorporación de inteligencia artificial amplía el alcance tradicional del gobierno de datos. Ya no se trata únicamente de asegurar que la información sea confiable, segura y de calidad antes de alimentar un modelo, también hay que gobernar el modelo, observar sus resultados y gestionar los nuevos datos y activos que genera.

En ese escenario, las métricas de sesgo adquieren un papel concreto: permiten transformar afirmaciones como “el modelo no discrimina” en evidencia susceptible de ser analizada. 

De hecho, las métricas de sesgo en IA para cumplimiento deben formar parte de una estructura mayor que incluya trazabilidad, documentación, responsabilidades y mecanismos de seguimiento durante todo el ciclo de vida.

En este artículo analizamos qué cambia cuando un modelo debe responder frente a un regulador, qué tipo de métricas permiten evaluar equidad y posibles sesgos, cómo acompañó a un cliente que necesitaba demostrar ante el BCRA el comportamiento de su modelo, y qué información conviene preparar antes de enfrentar una auditoría.

Por qué “está gobernado” ya no es suficiente para el BCRA

El gobierno de datos no nació con la inteligencia artificial. Las organizaciones reguladas vienen trabajando desde hace años sobre calidad, seguridad, privacidad, acceso, políticas, responsables y cumplimiento. Lo que cambia con la IA es que se amplió lo que necesita ser gobernado.

Podemos verlo en una transformación muy concreta: antes, gran parte del recorrido del dato podía finalizar en un reporte o un tablero utilizado por una persona para tomar una decisión, mientras que, al utilizar IA, ese dato puede alimentar un modelo que genera nuevos resultados, nuevos contenidos o nueva información, que posteriormente puede volver a ingresar al circuito.

La cadena se extiende, lo que lleva a tener que gobernar la información de entrada, pero también entender qué modelo la procesa, qué produce, bajo qué criterios y qué sucede con aquello que genera.

Esta exigencia resulta especialmente relevante en el sistema financiero. El texto ordenado vigente sobre ‘Requisitos Mínimos para la Gestión y Control de los Riesgos de Tecnología y Seguridad de la Información’, actualizado mediante la Comunicación “A” 8401 del BCRA, establece que las entidades alcanzadas deben implementar prácticas efectivas de control interno y gestión de riesgos tecnológicos, y demostrar comprensión de esos riesgos.

También contiene una sección específica sobre desarrollo, adquisición y mantenimiento de software, que comprende requisitos para sistemas y aplicaciones y gestión del ciclo de vida del software.

La Comunicación “A” 8398, por su parte, introdujo adecuaciones al régimen, extendió su alcance a los proveedores de servicios de pago registrados incluidos en el Registro de PSP del Banco Central de la República Argentina, y reforzó los requerimientos vinculados con terceras partes.

Esto implica que, en un entorno donde la tecnología forma parte de procesos regulados, decir que un modelo está gobernado necesita poder traducirse en controles, documentación y evidencia verificable. Es decir, una auditoría necesita demostrar qué ocurrió efectivamente.

Qué métricas de sesgo pide hoy un regulador

La primera precisión es importante: las comunicaciones del BCRA mencionadas en este artículo no establecen una lista cerrada de métricas de fairness que deban aplicarse a todos los modelos de inteligencia artificial.

No obstante, una organización puede necesitar presentar métricas de sesgo ante un requerimiento concreto del regulador. Lo cual lleva a una cuestión central: determinar aquello que deba medirse, dependerá del modelo, el caso de uso, los riesgos involucrados y aquello que sea necesario demostrar.

No es lo mismo evaluar un modelo que recomienda productos que otro que interviene en procesos de riesgo, contratación, evaluación de personas o decisiones que pueden generar consecuencias distintas para diferentes grupos.

Como referencia técnica, y no como un checklist normativo del BCRA, pueden utilizarse diferentes métricas para evaluar equidad según las características y riesgos de cada modelo.

El NIST AI Risk Management Framework recomienda seleccionar las métricas de acuerdo con el contexto, el propósito y las necesidades de la evaluación, mientras que el AI Metrology Center de NIST reúne métricas específicas para analizar posibles diferencias entre grupos, como las siguientes:

• Demographic Parity permite analizar si la probabilidad de obtener determinado resultado presenta diferencias entre los grupos considerados. Su análisis puede contribuir a identificar comportamientos que requieran una evaluación más profunda.
• Equalized Odds ofrece la posibilidad de comparar el desempeño del modelo entre grupos teniendo en cuenta sus resultados correctos e incorrectos. El objetivo es observar si el modelo presenta diferencias relevantes en la manera en que clasifica a las distintas poblaciones analizadas.

Estas métricas no deberían interpretarse de manera aislada ni como una prueba automática de cumplimiento. Una diferencia entre grupos puede constituir una señal que necesita ser analizada teniendo en cuenta los datos, el propósito del modelo y el contexto en el que se utiliza.

En una auditoría de modelos, el objetivo no debería ser acumular indicadores, sino construir evidencia que permita explicar qué riesgo se buscó evaluar, por qué se seleccionaron determinadas métricas, qué resultados se obtuvieron y cómo fueron interpretados.

Las métricas de sesgo, en definitiva, adquieren valor regulatorio cuando forman parte de una evidencia más amplia y trazable sobre el comportamiento del modelo.

Caso: cómo se armó la evidencia para una auditoría real

Bajemos la discusión a una necesidad concreta, a través de la experiencia reciente de uno de nuestros clientes, que necesitaba demostrar ante el BCRA que un modelo no estaba incurriendo en sesgos vinculados al género.

Su desafío no consistió solamente en afirmar que el modelo había sido correctamente desarrollado o que su performance general era buena, sino en obtener métricas y poner en evidencia su comportamiento.

Este caso muestra una diferencia fundamental entre desarrollar IA en general y hacerlo dentro de una organización regulada. Un modelo puede generar el impacto esperado sobre el negocio y, aun así, necesitar una capa adicional antes de consolidarse en producción: la capacidad de demostrar que opera dentro de los parámetros que la organización necesita garantizar.

Ese requerimiento modifica también el momento en que debería comenzar la conversación sobre compliance. Si las métricas se buscan recién cuando llega una auditoría, es posible que parte de la información necesaria esté dispersa, no haya sido conservada o resulte difícil reconstruir las condiciones exactas bajo las cuales se entrenó o ejecutó el modelo.

La clave está en anticiparse a ese escenario y evaluar, antes de que llegue un requerimiento, si la organización cuenta con la información y evidencia necesarias para explicar ante el BCRA cómo se comporta un modelo y respaldar los resultados que produce.

Incorporar la auditabilidad desde el inicio del ciclo de vida del modelo permite anticiparse a un eventual requerimiento mediante la definición sobre qué información debe conservarse, qué métricas necesitan monitorearse, y qué evidencia será necesaria para reconstruir y explicar su comportamiento cuando sea requerido.

Esa capacidad tampoco depende de una única herramienta ni puede quedar concentrada en un solo equipo. El desafío combina tecnología, procesos y personas, y requiere datos gobernados y de calidad, evaluación del modelo y responsabilidades definidas para transformar esa información en evidencia trazable y disponible.

Trazabilidad de punta a punta: qué tenés que poder mostrar

Las métricas de sesgo responden una parte del requerimiento. La otra parte reside en poder explicar de dónde proviene el resultado que estamos midiendo y ahí es donde entra la trazabilidad.

Las nuevas necesidades de gobierno extienden la cadena completa del dato. Si un sistema de IA genera una respuesta, un documento o cualquier otro activo que llega a un cliente, la organización necesita poder entender qué sucedió desde el origen hasta ese output.

En términos prácticos, una trazabilidad de punta a punta debería permitir reconstruir cuestiones como:

• Origen del dato: cuáles fueron las fuentes que alimentaron el modelo y quién era responsable de esa información.
• Calidad y transformaciones: qué controles se aplicaron, qué modificaciones sufrió la información y bajo qué reglas.
• Dataset utilizado: qué conjunto y versión de los datos se utilizaron para entrenar, validar o ejecutar el modelo, de manera que sea posible reconstruir con precisión qué información intervino en cada etapa.
• Versión del modelo: qué modelo produjo el resultado y bajo qué configuración.
• Métricas utilizadas: qué indicadores de performance, calidad y sesgo se analizaron y cuáles fueron sus resultados.
• Decisiones y aprobaciones: quién validó el modelo, bajo qué criterios y con qué documentación.
• Output generado: qué respuesta, dato, conversación, documento u otro activo surgió del modelo y qué tratamiento recibió posteriormente.
• Cambios posteriores: qué modificaciones tuvo la solución y qué nuevas validaciones se realizaron.

Este punto resulta especialmente relevante porque la IA incorpora tipos de activos que no siempre estaban presentes en los esquemas tradicionales de gobierno.

Por ejemplo, un chatbot puede generar un documento para un cliente que no existía previamente en una base de datos tradicional, pero ahora es un activo generado por la compañía y puede necesitar ser conservado, trazado y auditado. 

Lo mismo ocurre con las conversaciones. Ya no alcanza únicamente con gobernar tablas y registros estructurados. Puede ser necesario entender qué preguntó una persona, qué respondió un agente de IA, en qué información se basó y qué contenido salió de la organización como consecuencia de esa interacción.

Guía para armar tu carpeta de evidencia

El objetivo de una carpeta de evidencia es que la organización pueda reconstruir, con información verificable, cómo fue desarrollado, validado, puesto en producción y monitoreado un modelo. Para lograrlo, es necesario reunir y organizar la información que permita documentar las distintas etapas de su ciclo de vida, las decisiones adoptadas y los controles aplicados. 

Estos son algunos de los principales aspectos que debería contemplar:

1. Descripción y propósito del modelo. Detallar qué necesidad resuelve, en qué proceso interviene, cuál es su alcance y qué decisiones toma o contribuye a tomar.

2. Responsables. Identificar quiénes son responsables del modelo, los datos y su operación, así como la participación de las áreas de negocio, tecnología, riesgo, seguridad y compliance.

3. Datos y linaje. Documentar las fuentes de información, su origen y recorrido, las reglas de calidad aplicadas, las transformaciones realizadas y las versiones utilizadas.

4. Documentación del modelo. Registrar la versión del modelo, su metodología, las variables utilizadas, el proceso de entrenamiento y los criterios definidos para su validación y aprobación.

5. Métricas de desempeño. Conservar los indicadores utilizados para evaluar el funcionamiento del modelo y demostrar si alcanza los resultados esperados para el caso de uso.

6. Métricas de sesgo y fairness. Documentar qué grupos y posibles sesgos fueron evaluados, qué métricas se utilizaron, por qué fueron seleccionadas y cuáles fueron los resultados obtenidos.

7. Evidencia de validación. Reunir las pruebas y controles realizados, sus resultados, las observaciones identificadas y las aprobaciones necesarias antes de la puesta en producción.

8. Outputs y activos generados. Registrar, cuando corresponda, las respuestas, conversaciones, documentos u otros contenidos producidos por el modelo que necesiten ser trazados o auditados.

9. Monitoreo. Definir qué aspectos del modelo se controlan una vez en producción, con qué frecuencia, mediante qué indicadores y cómo se gestionan posibles desvíos.

10. Historial de cambios. Mantener un registro de las actualizaciones, nuevas versiones y modificaciones realizadas, junto con las validaciones efectuadas después de cada cambio.

La lógica es sencilla: si un regulador formula una pregunta, la respuesta no debería depender de reconstruir retrospectivamente información distribuida entre equipos, herramientas y proveedores. Tendría existir una cadena de evidencia.

Gobernar IA implica ampliar la frontera del gobierno de datos

La inteligencia artificial no reemplaza la necesidad de gobierno de datos, la vuelve más amplia.

Los modelos necesitan información limpia, segura, trazable y con suficiente calidad. Pero una vez que comienzan a operar, también generan nuevos resultados, contenidos y datos que ingresan nuevamente al ecosistema. Ese ciclo obliga a extender el gobierno.

El desafío es especialmente relevante para organizaciones que ya están llevando modelos a producción, porque cuanto mayor es el impacto de la IA sobre clientes, procesos o decisiones sensibles, mayor es también la necesidad de saber qué está ocurriendo y poder demostrarlo.

La IA agrega una nueva capa y ya no alcanza con saber que los datos están gobernados. Hay que poder demostrar cómo esos datos alimentaron un modelo, qué produjo ese modelo, cómo se evaluó su comportamiento y qué evidencia existe para justificarlo.

Ese es el punto donde las métricas de sesgo dejan de ser únicamente una discusión técnica y pasan a convertirse en una herramienta de cumplimiento, transparencia algorítmica y gestión del riesgo. Para las organizaciones reguladas, prepararlas antes de que llegue la auditoría puede hacer una diferencia considerable.

Prepará tu carpeta de evidencia antes del próximo requerimiento

Si tu organización necesita conocer qué tan preparada está para responder frente a una auditoría, también podés agendar una sesión de trabajo privada con el equipo de Data & IA de IT Patagonia para identificar brechas y prioridades de evolución