Gestión de riesgo de modelos para LLMs ajustados: guía de cumplimiento SR 11-7

SR 11-7 de la OCC y la Reserva Federal gobierna la gestión de riesgo de modelos en todos los bancos de EE.UU. Escrita en 2011 para modelos de scoring crediticio y cálculos de VaR, ahora también aplica a LLMs ajustados. Si tu banco usa un modelo de IA para tomar o influenciar cualquier decisión de negocio, SR 11-7 aplica. No hay excepción para "es solo IA".

La buena noticia: SR 11-7 está basada en principios, no es prescriptiva. Te dice qué documentar y validar, no cómo. Esta guía mapea cada requisito de SR 11-7 a los artefactos y procesos específicos que necesitas para LLMs ajustados.

Lo que SR 11-7 requiere

SR 11-7 define el riesgo de modelo como "el potencial de consecuencias adversas por decisiones basadas en salidas de modelo incorrectas o mal utilizadas." Exige tres pilares:

Desarrollo e implementación del modelo — documentado, con metodología sólida
Validación del modelo — independiente, continua, con hallazgos claros
Gobernanza del modelo — supervisión de la junta, inventario de modelos, controles de uso

Para modelos cuantitativos tradicionales, estos requisitos están bien comprendidos. Para LLMs ajustados, requieren reinterpretación. Aquí está el mapeo.

Mapeando SR 11-7 a LLMs ajustados

Pilar 1: documentación de desarrollo

SR 11-7 requiere documentación del "propósito, diseño y metodología del modelo, incluyendo la especificación matemática y los supuestos."

Para un LLM ajustado, esto significa:

Requisito SR 11-7	Equivalente LLM	Qué documentar
Propósito del modelo	Definición del caso de uso	Tarea de negocio específica, formato de entrada/salida, impacto en decisiones
Especificación matemática	Arquitectura + config de entrenamiento	Modelo base (ej., Llama 3.1 8B), nivel de cuantización, rango LoRA, alpha, dropout
Datos	Procedencia de datos de entrenamiento	Sistemas fuente, rango de fechas, volumen, pasos de preprocesamiento, manejo de PII
Supuestos	Límites de rendimiento	Qué puede y no puede hacer el modelo, modos de fallo conocidos
Limitaciones	Restricciones de alcance	Límites de tokens, soporte de idiomas, límites de dominio, umbrales de confianza
Implementación	Arquitectura de despliegue	Infraestructura, stack de servicio, contratos API, puntos de integración

Detalle crítico: Documenta la justificación de la selección del modelo base. ¿Por qué Llama 3.1 8B y no Mistral 7B? ¿Por qué cuantización Q4 y no Q8? Los auditores preguntarán. "Era el predeterminado" no es una respuesta aceptable. Resultados de benchmark en tu tarea específica con tus datos específicos son la respuesta aceptable.

Procedencia de datos de entrenamiento

Para cada dataset de fine-tuning, documenta:

Sistemas fuente: Qué bases de datos internas, repositorios de documentos o aplicaciones generaron los ejemplos de entrenamiento
Rango de fechas: Cuándo se crearon los datos fuente (no cuándo los extrajiste)
Volumen: Número de ejemplos de entrenamiento, longitud promedio, conteo total de tokens
Preprocesamiento: Cada transformación aplicada — deduplicación, redacción de PII, conversión de formato, filtrado de calidad
Etiquetado: Quién creó las etiquetas de ground truth, qué instrucciones siguieron, acuerdo inter-anotador si aplica
Representación: Distribución entre categorías, departamentos, períodos de tiempo. Documenta cualquier brecha o sesgo conocido

Documentación de configuración LoRA

Parámetro	Valor (ejemplo)	Justificación
Modelo base	Llama 3.1 8B Instruct	Mejor balance precisión/latencia en benchmark interno (ver Apéndice B)
Cuantización	Q4_K_M	Menor al 1% de pérdida de precisión vs FP16 en conjunto de evaluación; 4x de reducción de memoria
Rango LoRA	16	Validado vía barrido (rango 8/16/32); rango 16 óptimo en métrica de evaluación
Alpha LoRA	32	Ratio estándar 2x del rango; validado en barrido
Dropout LoRA	0.05	Redujo sobreajuste en conjunto de validación vs 0.0
Módulos objetivo	q_proj, v_proj, k_proj, o_proj	Objetivo en todas las capas de atención; apuntar a MLP no mostró mejora
Épocas de entrenamiento	3	Parada temprana en pérdida de validación; época 3 óptima
Tasa de aprendizaje	2e-4	Barrido de 1e-4 a 5e-4; 2e-4 minimizó pérdida de validación
Tamaño de lote	8	Máximo para memoria GPU con acumulación de gradientes
Ejemplos de entrenamiento	2,847	Dataset completo calificado después del filtrado

Este nivel de detalle es lo que los auditores esperan. Cada hiperparámetro debe tener una justificación documentada respaldada por resultados experimentales.

Pilar 2: marco de validación

SR 11-7 requiere "desafío efectivo" a través de validación independiente. Para LLMs ajustados, la validación significa un proceso estructurado de 5 pasos.

Paso 1: evaluación con benchmark

Ejecuta el modelo ajustado contra un conjunto de prueba reservado que nunca se usó durante el entrenamiento o la selección de hiperparámetros.

Métrica	Objetivo	Real	Estado
Precisión de tarea	mayor a 92%	94.1%	Aprobado
Precisión (clase positiva)	mayor a 90%	91.7%	Aprobado
Recall (clase positiva)	mayor a 88%	89.3%	Aprobado
Puntuación F1	mayor a 89%	90.5%	Aprobado
Tasa de alucinaciones	menor al 3%	1.8%	Aprobado
Tasa de rechazo (consultas en alcance)	menor al 2%	0.9%	Aprobado

Paso 2: backtesting

Aplica el modelo a casos históricos donde el resultado correcto es conocido. Compara las salidas del modelo con las decisiones reales.

Selecciona 200-500 casos históricos que abarquen al menos 12 meses
Ejecuta la inferencia sin ninguna revisión humana
Compara con los resultados reales o ground truth revisado por expertos
Documenta la tasa de acuerdo, patrones de desacuerdo y modos de fallo

Paso 3: pruebas adversariales

Intenta deliberadamente romper el modelo:

Inyección de prompts: Intenta anular las instrucciones mediante entradas manipuladas
Pruebas de límites: Entradas al borde del alcance documentado del modelo
Datos sin sentido/ruido: Verifica que el modelo rechace o señale entradas incoherentes
Fugas entre dominios: Verifica que el modelo no responda preguntas fuera de su dominio
Extracción de PII: Intenta extraer datos de entrenamiento del modelo

Documenta cada caso de prueba, comportamiento esperado, comportamiento real y estado de aprobación/rechazo.

Paso 4: auditoría de sesgo

Para cualquier modelo que influencie decisiones que afectan a clientes o empleados:

Prueba entre segmentos demográficos (edad, género, geografía, tipo de cuenta)
Mide las disparidades de precisión entre segmentos
Documenta cualquier diferencia estadísticamente significativa y planes de mitigación
Referencia el marco existente del banco de préstamos justos / trato justo

Paso 5: revisión independiente

La validación debe ser realizada por alguien que no estuvo involucrado en el desarrollo del modelo. En la mayoría de los bancos, esto es el equipo de Gestión de Riesgo de Modelos (MRM) o un tercero calificado.

El revisor independiente debe recibir:

Toda la documentación del Pilar 1
Acceso al modelo para pruebas
Los resultados de benchmark, backtest, pruebas adversariales y auditoría de sesgo
La autoridad para bloquear el despliegue si los hallazgos lo justifican

Plantilla de Model Card

Aquí hay un ejemplo completado para un modelo de análisis de documentos en un banco comercial.

MODEL CARD: Analizador de Documentos de Préstamos Comerciales v2.1
====================================================================

Propósito:       Extraer términos clave de documentos de préstamos comerciales
                 (covenants, tasas, vencimientos, descripciones de colateral)

Modelo base:     Llama 3.1 8B Instruct (Q4_K_M)
Adaptador:       LoRA rango 16, entrenado con 2,847 documentos internos
Fecha de entrenamiento: 2026-01-15
Desplegado:      2026-02-01

Entrada:         Texto de PDF (extraído), máximo 4,096 tokens
Salida:          JSON estructurado con campos extraídos + puntuaciones de confianza

Rendimiento:
  - Precisión de extracción de campos: 94.1% (conjunto de prueba, n=412)
  - Tasa de alucinaciones: 1.8% (términos fabricados no presentes en la fuente)
  - Latencia: 1.2s mediana (GPU T4)

Limitaciones:
  - No maneja PDFs escaneados/basados en imagen (se requiere OCR previo)
  - La precisión cae por debajo del 85% para documentos de más de 3,500 tokens
  - No validado para documentos en idiomas distintos al inglés
  - No reemplaza la revisión legal — las salidas requieren verificación humana

Evaluación de sesgo: Sin variación de precisión estadísticamente significativa entre
                     tipos de préstamo (a plazo, rotativo, construcción) o regiones

Propietario:     Tecnología de Banca Comercial
Validador:       Gestión de Riesgo de Modelos (MRM-2026-0142)
Próxima revisión: 2026-08-01 (ciclo de 6 meses)

10 preguntas comunes de auditores (y respuestas)

Los auditores de la OCC, la Reserva Federal o auditoría interna harán preguntas puntuales. Aquí están las 10 más comunes y cómo responderlas.

1. "¿Cómo saben que este modelo es preciso?" Señala la evaluación de benchmark con los resultados del conjunto de prueba reservado. Muestra métricas de precisión, recall y F1. Muestra los resultados de backtesting contra casos históricos.

2. "¿Quién validó este modelo?" Nombra al validador independiente (equipo MRM o parte externa). Muestra el informe de validación con hallazgos y firma.

3. "¿Qué pasa cuando el modelo se equivoca?" Describe el flujo de trabajo con humano en el circuito. Cada salida del modelo es revisada por un humano calificado antes de cualquier decisión de negocio. Muestra el proceso de escalamiento de errores.

4. "¿Cómo monitorean el rendimiento continuo?" Muestra el dashboard de monitoreo: métricas de precisión rastreadas semanalmente, alertas de detección de deriva, tendencias de volumen y latencia. Muestra el umbral que activa la re-validación.

5. "¿Pueden reproducir una salida específica de hace 6 meses?" Sí. Muestra el registro de auditoría con versión del modelo, versión del adaptador, hash de entrada y hash de salida. Demuestra que cargar la misma versión del modelo con la misma entrada produce la misma salida (inferencia determinística con temperature=0).

6. "¿Qué datos de entrenamiento se usaron?" Proporciona la documentación de procedencia de datos. Sistemas fuente, rangos de fechas, volúmenes, pasos de preprocesamiento, metodología de etiquetado.

7. "¿Cómo previenen que el modelo use datos de clientes inapropiadamente?" Describe el manejo de PII en los datos de entrenamiento (redacción o reemplazo sintético). Muestra que el modelo se ejecuta on-premise sin transmisión de datos externa. Muestra los controles de acceso y la gestión de claves API.

8. "¿Cuál es su proceso de gestión de cambios?" Recorre el flujo de trabajo: proponer cambio, reentrenar, validar en benchmark, revisión independiente, despliegue escalonado, monitoreo. Muestra la cadena de aprobación.

9. "¿Este modelo está en su inventario de modelos?" Sí. Muestra la entrada del inventario de modelos con: nombre del modelo, versión, propietario, caso de uso, nivel de riesgo, fecha de validación, próxima fecha de revisión. Cada modelo ajustado y cada versión de adaptador es una entrada separada del inventario.

10. "¿Cuál es su plan de sucesión si el propietario del modelo se va?" La documentación es el plan de sucesión. Todos los artefactos de desarrollo, resultados de validación y procedimientos operacionales están almacenados en el registro de modelos. Cualquier ingeniero calificado puede operar el modelo usando la documentación existente.

Checklist de documentación

Para cada modelo ajustado, mantén estos artefactos:

Artefactos de desarrollo

Especificación del caso de uso (problema de negocio, criterios de éxito, stakeholders)
Justificación de selección de modelo base con comparación de benchmark
Documentación de procedencia de datos de entrenamiento
Configuración de hiperparámetros con resultados de barrido
Registros de entrenamiento (curvas de pérdida, métricas de validación por época)
Model card final

Artefactos de validación

Informe de evaluación de benchmark (métricas del conjunto de prueba)
Informe de backtesting (comparación con casos históricos)
Informe de pruebas adversariales (escenarios de ataque y resultados)
Informe de auditoría de sesgo (análisis por segmento demográfico)
Informe de validación independiente con firma
Seguimiento de hallazgos y remediación

Artefactos operacionales

Diagrama de arquitectura de despliegue
Especificación de API y documentación de integración
Configuración de dashboard de monitoreo
Umbrales de alerta y procedimientos de escalamiento
Flujo de trabajo de gestión de cambios
Manual de respuesta a incidentes
Política de retención de registros de auditoría

Artefactos de gobernanza

Entrada en inventario de modelos
Clasificación de nivel de riesgo
Aprobación de junta/comité (para modelos de Nivel 1)
Calendario de revisión (típicamente semestral o anual)
Política de uso (quién puede usar el modelo, para qué, con qué salvaguardas)

Ship AI that runs on your users' devices.

Ertas early bird pricing starts at $14.50/mo — locked in for life. Plans for builders and agencies.

View early bird pricing or join the waitlist →

Por qué el despliegue on-premise simplifica el cumplimiento de SR 11-7

Cada requisito de SR 11-7 se vuelve más fácil cuando el modelo se ejecuta en tu propia infraestructura.

Dimensión de cumplimiento	On-premise	API en la nube
Procedencia de datos	Control total — los datos de entrenamiento nunca salen de tus sistemas	Debes documentar flujos de datos hacia proveedor tercero
Reproducibilidad	Fija la versión del modelo, versión del adaptador y parámetros de inferencia	El proveedor puede actualizar modelos sin aviso
Registro de auditoría	Registros completos en tu SIEM	Dependiente del registro y retención del proveedor
Control de acceso	Integrado con IAM existente	Gestión separada de claves API, menor visibilidad
Gestión de cambios	Tú controlas cada actualización	El proveedor controla las actualizaciones del modelo en su cronograma
Inventario de modelos	Eres dueño del artefacto del modelo	Tienes una clave API para un modelo que no controlas
Validación independiente	Valida en cualquier momento contra tus conjuntos de prueba	No puedes ejecutar suites de validación personalizadas contra modelos alojados
Respuesta a incidentes	Capacidad forense completa	Limitado a los informes de incidentes del proveedor

El problema fundamental: con una API en la nube, estás documentando el modelo de alguien más. Con modelos ajustados on-premise, estás documentando el tuyo propio. Lo segundo es para lo que SR 11-7 fue diseñada.

Los bancos que despliegan modelos ajustados on-premise consistentemente reportan ciclos de validación más rápidos, hallazgos de auditoría más limpios y menor sobrecarga de cumplimiento que aquellos que dependen de APIs en la nube con evaluaciones de riesgo de proveedores adicionales.

Lectura adicional

Fine-tuning de IA para servicios financieros — Guía completa de marcos de cumplimiento y casos de uso en producción en banca
Cómo evaluar un modelo ajustado — Construye pipelines de evaluación con suites de benchmark y pruebas automatizadas
Checklist de calidad de fine-tuning — Puertas de calidad pre-despliegue para modelos ajustados en producción