BCRA Com. A 7724: lo que tu fintech debe documentar

La BCRA Comunicación “A” 7724 entró en vigor el 6 de septiembre de 2023 y desde entonces define el marco obligatorio para el uso de inteligencia artificial en entidades financieras y fintech argentinas. No es opcional ni voluntaria: es un requisito de cumplimiento. Sin embargo, después de casi tres años de vigencia, muchas fintech argentinas siguen sin tener inventario completo de sus modelos productivos, sin documentación auditable, y sin un plan claro para responder ante inspección. Esta nota es un repaso operativo de los siete puntos que la 7724 exige concretamente, con foco práctico en qué documentos preparar y qué errores evitar.

El estado actual de la Comunicación A 7724

La 7724 establece principios generales y exigencias operativas para sistemas que apliquen IA en procesos críticos de entidades reguladas. La autoridad de aplicación es la propia BCRA a través de la Superintendencia de Entidades Financieras y Cambiarias (SEFyC), con inspecciones tanto programadas como ad-hoc. Las inspecciones programadas suelen avisarse con anticipación; las ad-hoc, no.

Lo que la norma exige se puede resumir en siete áreas que cubren todo el ciclo de vida del modelo: identificación, inventario, datasets, métricas, análisis de riesgo, gobernanza y supervisión humana. A continuación los desgloso uno por uno con lo que concretamente tenés que tener preparado.

1 — Identificación y objetivo de cada modelo

Para cada modelo en producción tenés que poder responder en una hoja: cómo se llama, qué tipo de modelo es (regresión, clasificación, modelo de lenguaje, sistema de recomendación, agente), qué proceso interviene, qué decide o asiste a decidir, quién es el responsable interno del modelo, fecha de puesta en producción, y versión actual.

Suena obvio, pero el error más común en inspecciones es no poder responder esa hoja básica frente a un modelo específico que el inspector eligió al azar de un listado. “El modelo de scoring” no alcanza: tenés que poder identificar exactamente qué modelo, qué versión, qué objetivo concreto. Si hay varios modelos de scoring para distintos productos, cada uno requiere su ficha.

Esto se materializa en una ficha por modelo, no más de dos páginas, accesible para el equipo de cumplimiento sin pasar por el equipo técnico cada vez. La ficha es la puerta de entrada al modelo: si la ficha está mal, todo lo que sigue también lo está.

2 — Inventario de modelos en producción

El inventario es la lista completa de modelos que efectivamente están funcionando, no la lista de modelos planificados ni la lista de modelos que alguna vez se construyeron. Es la foto de hoy.

Tenés que tener el inventario centralizado, actualizado al menos mensualmente, accesible para auditores internos y externos. Si tu inventario se actualiza solo cuando hay inspección, no es inventario: es decoración.

Los errores típicos. Modelos de proveedores externos no inventariados, asumiendo que la responsabilidad es del proveedor. No lo es: si vos usás un modelo de un proveedor en tu producto, vos sos responsable de inventariarlo. Modelos de propósito general usados puntualmente para tareas internas sin registrar. Modelos en “shadow IT” usados por áreas operativas sin que el área de cumplimiento sepa. La BCRA puede pedirte el inventario y después preguntarle al área comercial si efectivamente todo lo que usan está en el inventario. Si no coincide, vas a tener un problema.

3 — Documentación de datasets de entrenamiento

Para cada modelo, la BCRA quiere saber con qué datos se entrenó. Origen de los datos (interno, externo, sintético), periodo cubierto, volumen, características demográficas y geográficas si aplica, criterios de inclusión y exclusión, tratamiento de datos faltantes, balance de clases si es clasificación, validación de calidad realizada.

Acá viene un punto incómodo para fintech argentinas que usan modelos de proveedores extranjeros. Si tu modelo es un fine-tuning sobre GPT, Claude o Gemini, no tenés acceso completo a los datos de entrenamiento del modelo base. Lo que sí tenés es la documentación que el proveedor publica (model card, technical report) y la documentación de tu propio dataset de fine-tuning si lo hubo. Eso es lo que tenés que presentar, con honestidad sobre los límites: “modelo base entrenado por OpenAI según ficha pública adjunta, fine-tuning realizado sobre 12.000 ejemplos internos descritos en anexo”.

La BCRA acepta esa estructura. Lo que no acepta es no tener documentación.

4 — Métricas de confiabilidad y robustez

Para cada modelo tenés que tener métricas de desempeño actualizadas. La elección de métricas depende del tipo de modelo. Para scoring crediticio: AUC-ROC, KS, tasa de aprobación por segmento, default rate observado vs predicho. Para modelos de detección de fraude: precision, recall, F1, falsos positivos por segmento. Para modelos de lenguaje aplicados a atención: tasa de resolución correcta, tasa de escalado a humano, satisfacción del cliente.

Lo importante no es solo medir: es medir continuamente. Las métricas evaluadas solo al cierre del entrenamiento no alcanzan. La 7724 exige monitoreo de deriva, lo que significa que tenés que tener tableros que muestren cómo evoluciona el desempeño del modelo a lo largo del tiempo, con alertas cuando las métricas se mueven más allá de umbrales definidos.

Errores típicos. Métricas calculadas sobre el set de validación original sin re-evaluar contra producción real. Métricas agregadas que esconden segmentos donde el modelo funciona mal. No tener umbrales de alerta definidos, lo que implica que nadie sabe cuándo el modelo se está degradando.

5 — Análisis de riesgo: la pieza más exigente

El análisis de riesgo es la pieza que más distingue a una fintech preparada de una que no lo está. No es un documento de tres páginas: es un proceso vivo que evalúa, para cada modelo, todas las formas en que puede fallar y todas las consecuencias posibles.

Las categorías de riesgo que la BCRA espera ver cubiertas. Riesgo de sesgo (¿el modelo trata distinto a grupos protegidos de forma injustificada?). Riesgo de deriva (¿el modelo va a degradarse con el tiempo, y cómo lo vas a detectar?). Riesgo técnico (¿qué pasa si el servicio del proveedor se cae, si hay latencia anormal, si la API cambia?). Riesgo de datos (¿qué pasa si los datos de entrada cambian de distribución?). Riesgo regulatorio (¿el uso del modelo se mantiene dentro del marco normativo si la regulación cambia?). Riesgo reputacional (¿qué pasaría si una decisión específica del modelo se hace pública?).

Para cada riesgo identificado, cuatro columnas: descripción, probabilidad estimada, impacto, mitigación implementada. Si una columna está vacía, el análisis está incompleto. La mitigación tiene que ser concreta: “supervisión humana” no es mitigación; “todo caso por encima de X monto requiere aprobación manual antes de ejecución” sí lo es.

6 — Gobernanza y supervisión humana

La BCRA exige que para cada modelo crítico haya humanos en el loop con capacidad real de intervenir. Eso se traduce en tres piezas concretas.

Roles definidos por modelo. Quién es el dueño del modelo (responsable funcional), quién es el responsable técnico (responsable de la implementación y mantenimiento), quién supervisa la operación (revisión de outputs en cierta frecuencia), quién audita (revisión independiente).

Procedimientos de intervención. Qué ocurre cuando un cliente impugna una decisión asistida por IA. Qué ocurre cuando se detecta deriva. Qué ocurre cuando hay un incidente operativo. Quién decide apagar el modelo si es necesario, y en qué tiempo.

Registros de intervención. Cada vez que un humano interviene sobre una decisión del modelo (la modifica, la revierte, la confirma con justificación), eso queda registrado y trazado. Esos registros son lo primero que pide un inspector, porque demuestran que la supervisión humana no es ficticia.

Para profundizar en cómo se estructura esta gobernanza dentro de una fintech, implementación de cumplimiento trabaja sobre la arquitectura completa de roles y procedimientos. Para entender cómo se conecta con el marco europeo (que es el que va a influir en la futura ley argentina), EU AI Act para empresas argentinas cubre la parte europea.

7 — Plan de incidentes y trazabilidad

La 7724 exige plan de incidentes documentado: qué constituye un incidente (no toda anomalía es incidente reportable, pero los criterios deben estar escritos), a quién se reporta, en qué plazos, qué información mínima debe contener el reporte, qué acciones correctivas se toman, cómo se documenta la resolución.

Trazabilidad significa que para cualquier decisión específica que el modelo tomó o asistió, podés reconstruir: con qué inputs operó, qué versión del modelo lo procesó, qué output produjo, si hubo intervención humana, qué resultado final tuvo, cuándo fue todo eso. La BCRA puede pedir una traza de un caso específico y esperar que la tengas disponible en horas, no en semanas.

Eso requiere arquitectura de logging pensada desde el inicio. Si tu sistema no fue diseñado con trazabilidad como requisito, agregarla después es caro pero no opcional.

Errores que ve la BCRA en la práctica

Cerrando con lo que efectivamente se observa en inspecciones reales según colegas que trabajan con auditorías y según comentarios de la propia Superintendencia.

Primero, documentación armada para la inspección, no como práctica continua. Se nota: las fechas de actualización están todas concentradas dos semanas antes de la fecha de inspección. La BCRA no se ríe, pero lo registra.

Segundo, inventarios incompletos. Falta el modelo que un área usa con herramienta de catálogo, falta el modelo del proveedor externo, falta el modelo experimental que en realidad ya está en producción.

Tercero, métricas medidas pero no monitoreadas. El modelo se evaluó cuando se subió a producción y no se volvió a evaluar después. Para una norma que enfatiza monitoreo continuo, esto es una bandera roja inmediata.

Cuarto, análisis de riesgo plantilla. El mismo documento de riesgo se copia para todos los modelos cambiando el nombre. La BCRA lo detecta cuando compara entre modelos y los riesgos son idénticos aunque los modelos sean radicalmente distintos.

Quinto, supervisión humana documentada pero no operativa. El procedimiento dice que un analista revisa cada caso de alta dudosa, pero en la práctica el modelo procesa miles de casos por día y no hay tiempo de revisión real. Eso, en inspección, equivale a no tener supervisión.

Si querés revisar qué tenés y qué te falta para estar listo ante inspección, auditoría previa a inspección cubre exactamente eso: una revisión externa que identifica brechas antes de que las identifique la BCRA. La comunicación oficial de la BCRA y el contexto sectorial de la Cámara Argentina Fintech son las dos referencias de partida. Para articulación con marcos internacionales, la norma ISO/IEC 42001 ofrece controles complementarios.

Para asesoramiento legal complementario sobre temas de IA aplicados específicamente a fintech argentinas, Josefina Strano, asesora legal IA trabaja la dimensión jurídica que se cruza con esta dimensión regulatoria-técnica. Si tu fintech está en proceso de prepararse para inspección o querés saber si tu documentación actual resistiría una revisión, escribime a r@patron.ar con el contexto.