IA On-Premise para Banca: Satisfaciendo los Requisitos de Auditoría del Regulador

El CTO de tu banco quiere IA. Cumplimiento quiere rastros de auditoría. El CISO quiere los datos on-premise. El jefe de operaciones lo quiere desplegado antes del Q3.

Estos no son requisitos contradictorios. Son restricciones de diseño — y todas apuntan a la misma arquitectura: modelos ajustados ejecutándose on-premise, con registro de auditoría integral, controles de acceso y gestión de cambios incorporados en la infraestructura desde el primer día.

Esta guía cubre la arquitectura completa, desde el clúster GPU hasta la retención de registros de auditoría, que te permite desplegar IA y pasar la revisión del examinador.

Resumen de Arquitectura

El despliegue sigue un pipeline de cuatro etapas. Cada etapa tiene una puerta que produce artefactos auditables.

[Etapa 1: Entrenamiento]           Entorno GPU air-gapped
        |
    Puerta de Validación --------> Resultados de benchmark, auditoría de sesgo, tarjeta del modelo
        |
[Etapa 2: Validación]             Revisión independiente por equipo MRM
        |
    Puerta de Aprobación ----------> Documento de aprobación, clasificación de nivel de riesgo
        |
[Etapa 3: Inferencia en Producción]  Clúster de inferencia on-premise
        |
    Monitoreo Continuo ------------> Alertas de drift, seguimiento de precisión, registros de auditoría
        |
[Etapa 4: Registro de Auditoría]   Almacén de registros inmutable, retención de 7 años

Cada inferencia, cada cambio de modelo y cada evento de acceso produce un registro que fluye a la Etapa 4. Nada es opcional.

Requisitos de Infraestructura

La infraestructura de IA bancaria se divide en tres niveles funcionales.

Desglose por Niveles

Nivel de Entrenamiento

El fine-tuning ocurre con poca frecuencia — típicamente trimestral o cuando se incorpora un nuevo caso de uso. El entorno de entrenamiento debe ser:

• Air-gapped o estrictamente aislado. Los datos de entrenamiento incluyen documentos financieros sensibles. Sin acceso a internet. Sin infraestructura compartida.
• Equipado con GPU. Ajustar un modelo de 7B-8B parámetros con LoRA requiere 16-24GB de VRAM. Una sola A100 de 40GB lo maneja cómodamente. Un par de GPUs T4 de 16GB funciona con acumulación de gradientes.
• Temporal. Las ejecuciones de entrenamiento toman 1-4 horas. El entorno puede apagarse entre ejecuciones. Si se usan instancias GPU en la nube para entrenamiento (con controles de datos apropiados), el costo es de $5-20 por ejecución de entrenamiento.

Costo: $15,000-25,000 para un servidor de entrenamiento dedicado, o $5-20 por ejecución en instancias GPU reservadas en la nube (si el cumplimiento permite transferencia de datos controlada y cifrada).

Nivel de Inferencia

La inferencia en producción se ejecuta 24/7. Este es el nivel que maneja solicitudes reales de aplicaciones bancarias.

Alta disponibilidad: Ejecuta dos servidores de inferencia en modo activo-activo detrás de un balanceador de carga interno. Si uno falla, el otro maneja la carga completa a rendimiento reducido. RTO: cero (failover automático). RPO: cero (inferencia sin estado).

Costo por servidor: $8,000-12,000 (con GPU T4). Dos servidores para HA: $16,000-24,000.

Nivel de Almacenamiento y Registro

Almacenamiento total del primer año: 100-200GB. Un arreglo NVMe de 2TB maneja 7+ años de crecimiento.

Arquitectura de Rastro de Auditoría

Esta es la sección que más importa a los examinadores. Cada inferencia debe producir un registro de auditoría completo e inmutable.

Registro por Inferencia

Inmutabilidad de Registros

Los registros de auditoría deben ser a prueba de manipulación. Opciones:

1. Almacenamiento de escritura única: Volúmenes WORM (Write Once Read Many). NetApp SnapLock, snapshots inmutables de Dell PowerStore, o similar.
2. Base de datos solo-adición: PostgreSQL con seguridad a nivel de fila que previene UPDATE/DELETE en tablas de auditoría. Combinado con verificación regular de cadena de hash.
3. Reenvío de registros: Replicación en tiempo real a un SIEM separado (Splunk, Elastic, QRadar) con políticas de retención independientes.

El enfoque más práctico para la mayoría de los bancos: tablas solo-adición de PostgreSQL con verificación nocturna de cadena de hash, replicadas al SIEM existente. Esto se integra con tu infraestructura de auditoría actual sin introducir nuevos sistemas.

Requisitos de Retención

La guía de examinación de OCC espera 5-7 años de registros para decisiones relacionadas con modelos. Para registros de auditoría de IA:

• Registros de inferencia: 7 años desde la fecha de la inferencia
• Versiones del modelo: Indefinido (necesitas la capacidad de cargar cualquier versión histórica para investigación)
• Artefactos de entrenamiento: Indefinido (procedencia de datos de entrenamiento, hiperparámetros, registros de entrenamiento)
• Informes de validación: Indefinido (vinculados a versiones del modelo)

Costo de almacenamiento para retención de 7 años: A 30GB/año de registros de auditoría, 7 años son 210GB. Comprimidos y archivados, esto cabe en un solo estante de NAS. El costo es trivial — menos de $500 por el hardware de almacenamiento.

Controles de Acceso

Modelo RBAC

Gestión de Claves API

Cada aplicación consumidora obtiene una clave API dedicada con permisos delimitados:

• Rotación de claves: Cada 90 días, automatizada. Las claves antiguas permanecen válidas por un período de gracia de 7 días.
• Limitación de tasa: Límites de tasa por clave basados en el caso de uso aprobado. Originación de préstamos: 500 solicitudes/día. Servicio al cliente: 2,000 solicitudes/día.
• Monitoreo de uso: Dashboards en tiempo real mostrando volumen por clave, latencia y tasas de error. Alertas sobre patrones anómalos (pico repentino de volumen, solicitudes fuera del horario laboral).

Monitoreo de Uso por Departamento

La inferencia on-premise tiene costo marginal cero por solicitud. El costo de infraestructura es fijo independientemente del volumen. Esto cambia la economía de la adopción de IA por completo — los departamentos pueden experimentar sin aprobación de presupuesto para cada nuevo caso de uso.

Flujo de Trabajo de Gestión de Cambios

Cada cambio de modelo sigue un flujo de trabajo documentado y auditable.

Proceso de Seis Pasos

1. PROPONER   --> Solicitud de cambio con justificación de negocio
                 Enviado por: Desarrollador de Modelos
                 Aprobado por: Propietario del caso de uso + Riesgo tecnológico

2. DESARROLLAR --> Ajustar o actualizar adaptador
                 Entorno: Nivel de entrenamiento air-gapped
                 Artefactos: Registros de entrenamiento, nueva tarjeta del modelo

3. VALIDAR    --> Ejecutar suite de benchmark + backtest + pruebas adversariales
                 Realizado por: Desarrollador de Modelos
                 Artefactos: Informe de evaluación

4. REVISAR    --> Validación independiente
                 Realizado por: Equipo MRM o validador externo
                 Artefactos: Informe de validación con hallazgos

5. APROBAR    --> Aprobación de despliegue
                 Aprobado por: Aprobador de Despliegue (comité de riesgo)
                 Artefactos: Aprobación firmada, clasificación de nivel de riesgo

6. DESPLEGAR  --> Despliegue escalonado a producción
                 Realizado por: Administrador de Infraestructura
                 Etapas: Canary (5%) → Parcial (25%) → Completo (100%)
                 Monitoreo: Observación de 48 horas en cada etapa

Procedimiento de Rollback

Si el monitoreo detecta degradación de calidad después del despliegue:

1. Disparador automático de rollback: La precisión cae por debajo del umbral durante 15 minutos consecutivos
2. Rollback manual: Cualquier operador autorizado puede revertir a la versión anterior del modelo en menos de 2 minutos
3. Documentación de incidentes: Cada rollback dispara un informe de incidente documentando qué cambió, qué falló y análisis de causa raíz

La versión anterior del modelo permanece cargada en memoria en el servidor de inferencia de respaldo. El rollback es un cambio de configuración del balanceador de carga — no una recarga del modelo.

Recuperación ante Desastres

Objetivos RTO y RPO

Failover a CPU

Si todas las GPUs fallan, la pila de inferencia recurre a operación solo CPU:

• El rendimiento cae de 30 tokens/seg a 5 tokens/seg por servidor
• Las solicitudes concurrentes máximas caen de 20 a 4
• Se activa cola de prioridad: solicitudes de Cumplimiento y riesgo primero, otros departamentos en cola
• Notificación automatizada a todas las aplicaciones consumidoras: "Sistema de IA operando en modo degradado, espere mayor latencia"

Operación en Modo Degradado

Cuando la IA no está disponible en absoluto:

• Todas las aplicaciones consumidoras deben tener una ruta alternativa sin IA
• Análisis de documentos de préstamo: Revisión manual (flujo de trabajo pre-IA existente)
• Clasificación de clientes: Enrutamiento basado en reglas (flujo de trabajo pre-IA existente)
• Redacción de SAR: Redacción manual por analistas de cumplimiento

Esto es un requisito regulatorio, no solo buena práctica. Los examinadores preguntarán: "¿Qué pasa si este sistema se cae?" La respuesta debe ser: "Revertimos a nuestro proceso pre-IA, que está documentado y probado trimestralmente."

Preparación para Examen del Regulador

Cuando los examinadores de OCC o FINRA lleguen, presenta el siguiente paquete.

Paquete de Información para el Examinador

1. Inventario de modelos: Lista completa de todos los modelos de IA en producción, con nivel de riesgo, propietario, fecha de validación y próxima fecha de revisión
2. Diagrama de arquitectura: El pipeline de cuatro etapas desde entrenamiento hasta registro de auditoría
3. Ejemplo de rastro de auditoría: Extrae 5 registros de inferencia del mes anterior, mostrando la cadena completa de registro desde solicitud hasta respuesta
4. Informe de validación: Validación independiente más reciente para cada modelo, incluyendo hallazgos y remediación
5. Registro de cambios: Todos los cambios de modelo en los últimos 12 meses, con documentación de aprobación
6. Registro de incidentes: Cualquier incidente relacionado con modelos, incluyendo rollbacks, con análisis de causa raíz
7. Documentación de control de acceso: Configuración RBAC, inventario de claves API, informes de uso por departamento
8. Resultados de prueba de recuperación ante desastres: Prueba de DR más reciente, incluyendo tiempo de failover y verificación de integridad de datos

Preocupaciones Comunes del Examinador (y Respuestas Preventivas)

"¿Se están enviando datos de clientes a terceros?" No. Toda la inferencia se ejecuta on-premise. Ningún dato de cliente sale de la red del banco. Muestra el diagrama de arquitectura de red con aislamiento VLAN.

"¿Pueden reproducir una salida histórica del modelo?" Sí. Muestra el registro de versiones del modelo, demuestra cargar una versión histórica y reproduce una salida del registro de auditoría usando el hash de entrada registrado.

"¿Cómo detectan el drift del modelo?" Monitoreo semanal de precisión contra un conjunto de benchmark. Alertas automatizadas cuando la precisión cae por debajo del umbral. Re-validación completa trimestral. Muestra el dashboard de monitoreo.

"¿Cuál es la participación de la junta directiva?" Los informes de gobernanza de riesgo de modelos se reportan al comité de riesgo de la junta trimestralmente. El comité aprueba la declaración de apetito de riesgo de modelos y revisa los despliegues de modelos de Nivel 1. Muestra el último informe trimestral.

Comparación de Cumplimiento: On-Premise vs Nube

Así es como los despliegues on-premise y en la nube se comparan en 10 dimensiones de auditoría.

Esta no es una comparación cerrada. On-premise gana en cada dimensión que importa a los reguladores. La única dimensión donde las APIs en la nube tienen ventaja es tiempo-a-primera-inferencia — puedes empezar a usar una API en la nube en horas, mientras que on-premise toma semanas para configurar.

Pero el tiempo de configuración es un costo único. El cumplimiento de auditoría es continuo, cada trimestre, durante la vida del modelo. Invierte las semanas por adelantado.

Costo Total de Propiedad

Comparación a 3 Años (Banco Mediano, 4 Casos de Uso)

Las matemáticas no son sutiles. On-premise cuesta 75-85% menos en tres años para un banco ejecutando cuatro casos de uso de IA a volúmenes típicos (1,000-2,000 inferencias/día en total).

Más importante aún, la postura de cumplimiento es categóricamente mejor. No estás documentando la infraestructura de alguien más — estás documentando la tuya propia.

Lectura Adicional

• IA On-Premise para Bufetes de Abogados: Lista de Verificación de Cumplimiento — Marco de cumplimiento similar aplicado a requisitos de la industria legal
• Comparación de Costos de GPU para Self-Hosting de IA en 2026 — Benchmarks detallados de hardware y precios para cargas de trabajo de inferencia y entrenamiento
• Fine-Tuning de IA para Servicios Financieros — Guía completa de cumplimiento, casos de uso y despliegue en banca y finanzas