AI Act y fintech: qué cambia en la arquitectura del scoring crediticio desde agosto de 2026

En resumen: desde el 2 de agosto de 2026 entraron en vigor las obligaciones de “alto riesgo” del AI Act europeo para los sistemas de IA que evalúan solvencia crediticia (Anexo III, punto 5(b)). Si tu fintech usa IA para scoring, ya no alcanza con que el modelo funcione bien: tiene que poder demostrarlo, con arquitectura, no solo con un informe legal.

Qué cambió exactamente

El AI Act no es nuevo (entró en vigor en 2024), pero 2026 es el año en que el reglamento deja de ser una fecha en el calendario y se convierte en una obligación operativa. Para el scoring crediticio, el Anexo III lo clasifica directamente como sistema de alto riesgo, lo que activa un bloque completo del Capítulo III:

• Gestión de riesgo (Art. 9): un proceso continuo, no una auditoría única antes del lanzamiento.
• Gobernanza de datos (Art. 10): trazabilidad de qué datos entrenaron el modelo y por qué son representativos.
• Documentación técnica (Anexo IV): el equivalente regulatorio de un ADR, pero obligatorio y auditable.
• Registro de eventos (Art. 12): logging que permita reconstruir cada decisión del modelo, no solo el resultado final.
• Supervisión humana (Art. 14): un punto real donde una persona puede revisar o revertir la decisión, no un checkbox de cumplimiento.
• Evaluación de conformidad (Art. 43): certificación antes de sacar el sistema a producción.

El incumplimiento no es simbólico: hasta 15 millones de euros o el 3% de la facturación global, lo que sea mayor.

El detalle que se le escapa a la mayoría: proveedor vs. desplegador

Esto es lo más relevante para quien diseña el sistema, no solo para legal. Si tu fintech toma un modelo de terceros y lo usa tal cual, eres desplegador (obligaciones más livianas). Pero si lo fine-tuneas con tus propios datos (algo habitual para mejorar precisión en tu segmento de clientes), pasas a ser proveedor, con toda la carga de documentación técnica Anexo IV y evaluación de conformidad encima. Es una decisión de arquitectura (¿fine-tuning propio o modelo gestionado de un tercero?) que ahora tiene consecuencias regulatorias directas.

Qué significa esto en el código, no solo en el compliance

Un sistema de scoring conforme necesita, como mínimo, un puerto de dominio dedicado a la trazabilidad (agnóstico de qué motor de scoring haya detrás):

// El registro de decisión vive en el dominio, no pegado al modelo:
// cualquier motor de scoring (propio o de terceros) pasa por acá.
export interface CreditDecisionLog {
  record(decision: {
    subjectId: string;
    inputsHash: string; // no los datos crudos: su huella, para auditar sin exponer PII
    modelVersion: string;
    score: number;
    outcome: 'approved' | 'rejected' | 'review';
    reviewedBy?: string; // presente cuando pasó por supervisión humana (Art. 14)
  }): Promise<void>;
}

La clave arquitectónica: el logging y la supervisión humana no pueden ser un parche agregado después. Si el modelo de scoring vive detrás de un puerto bien definido desde el día uno, cumplir Art. 12 y Art. 14 es cablear un adaptador más. Si el modelo está mezclado con la lógica de negocio, cumplir en agosto de 2026 significa reescribir bajo presión.

Por qué importa para tu producto

Porque el AI Act ya no es una discusión de 2027. Si estás construyendo o modernizando un producto fintech con IA en el flujo de decisión, la arquitectura que elijas hoy (puertos claros, logging desde el diseño, un punto real de revisión humana) es la diferencia entre una adaptación de una semana y una migración de meses. Si estás en esa etapa y quieres que la arquitectura aguante la regulación sin frenar el producto, hablemos.