Cómo estructuré la agentización con IA en un fintech regulado

Cuando asumí el rol de Technical Lead en la Tribu B2C de LIGO, me encontré frente a una plataforma de más de 40 microservicios corriendo en AWS EKS, con equipos distribuidos en tres squads y la presión regulatoria del BCRP sobre cada decisión de arquitectura. El mandato era claro: incorporar IA de forma real, no cosmética.

El problema de la IA en entornos regulados

La mayoría de los artículos sobre IA asumen que puedes llamar a cualquier API externa libremente. En fintech regulada, eso no es así. Cada dato que sale de tu VPC es un vector de riesgo. Cada modelo externo que toca información de usuario necesita pasar por un análisis de impacto de datos y, dependiendo del tipo de información, por una revisión de cumplimiento normativo.

Esto elimina automáticamente las soluciones más populares de “conecta ChatGPT a tu app”. El stack tiene que vivir dentro de tu perímetro o en un servicio con garantías contractuales claras.

La decisión: AWS Bedrock como plataforma base

Elegí Bedrock por tres razones no negociables en fintech:

1. Residencia de datos en región: Los modelos en Bedrock pueden ejecutarse sin que tus prompts salgan de us-east-1 o us-east-2. Los datos de entrenamiento de las invocaciones no se usan para mejorar los modelos fundacionales.
2. Integración nativa con IAM: Puedes controlar qué microservicio puede invocar qué modelo con políticas IAM granulares, lo mismo que ya haces con S3 o DynamoDB.
3. Auditoría en CloudTrail: Cada invocación queda registrada. Para un regulador, esto es la diferencia entre “usamos IA” y “usamos IA y podemos demostrarlo”.

Arquitectura: tres capas de agentización

El roadmap que diseñé tiene tres capas progresivas:

Capa 1 — Automatización de tareas internas (en producción)

El primer agente que desplegué fue agente principal de operaciones, corriendo en NestJS como parte del AgentCore de TSL. Su trabajo: revisar pull requests automáticamente, ejecutar análisis de calidad de código, y hacer seguimiento de épicas en Jira.

La razón de empezar aquí es estratégica: el riesgo regulatorio es mínimo (código interno, no datos de clientes) pero el impacto en productividad es inmediato. Los squads recuperaron entre 40 y 60 minutos por PR al eliminar el ciclo de review manual para checks repetibles.

El agente funciona así:

• Webhook de GitHub dispara un job en NestJS
• El job construye el contexto: diff del PR, historial de tickets, estándares del equipo
• Bedrock Claude analiza y retorna observaciones estructuradas en JSON
• El agente comenta en el PR y actualiza el ticket de Jira

// Ejemplo simplificado del flujo del agente
async function reviewPullRequest(prContext: PrContext): Promise<ReviewResult> {
  const prompt = buildReviewPrompt(prContext);
  
  const response = await bedrockClient.invokeModel({
    modelId: 'us.anthropic.claude-sonnet-4-5-20250929-v1:0',
    body: JSON.stringify({
      messages: [{ role: 'user', content: prompt }],
      max_tokens: 4096,
    }),
  });
  
  return parseStructuredReview(response.body);
}

Capa 2 — Procesamiento de documentos (en staging)

La segunda capa apunta a automatizar la ingesta de documentos regulatorios y recibos financieros usando Bedrock con visión. El caso de uso: un usuario sube una foto de un comprobante, el modelo extrae monto, fecha, comercio y categoría, y los persiste en DynamoDB.

El desafío técnico aquí no es la extracción en sí (Bedrock lo hace bien), sino la validación posterior. En fintech, una transacción mal extraída puede impactar el balance del usuario. Diseñamos un pipeline de validación con tres pasos:

1. Extracción por Bedrock (Claude Vision)
2. Validación de rangos y consistencia en Lambda
3. Confirmación explícita del usuario en la app

Capa 3 — Amazon Q Business para equipos internos (en roadmap)

El objetivo final es dar a los squads una interface de lenguaje natural sobre la documentación técnica interna: ADRs, runbooks, playbooks de incidentes. Amazon Q Business indexa esos documentos (almacenados en S3) y permite que cualquier ingeniero pregunte “¿cuál es el procedimiento de rollback para el servicio de wallet?” sin necesidad de buscar en Confluence.

Gestión del riesgo regulatorio

El BCRP tiene expectativas claras sobre el uso de tecnologías emergentes en infraestructura crítica. El framework que usamos:

• Clasificación de datos antes de cada integración IA: ¿El prompt contiene datos personales? ¿Datos financieros? ¿Solo metadatos técnicos?
• Sandboxing por entorno: Los agentes en producción solo tienen acceso a los datos mínimos necesarios. En dev pueden experimentar más libremente.
• Circuit breakers: Si el agente retorna errores por más de N invocaciones, el servicio cae a comportamiento determinístico tradicional.

Resultado y métricas

Después de seis meses del roadmap de agentización:

• -65% en tiempo de review de código para checks repetibles
• +30% en velocidad de detección de errores de configuración
• 0 incidentes regulatorios asociados al uso de IA en producción

La clave no fue la tecnología, fue el diseño defensivo: cada agente tiene un fallback, cada dato que toca está clasificado, y cada invocación es auditable.

Conclusión

Integrar IA en fintech regulada no es difícil por la tecnología. Es difícil por el diseño. Si empiezas por los casos de bajo riesgo y construyes los controles desde el principio, en 12 meses tienes una plataforma de agentización que tus ingenieros usan todos los días y que tus auditores pueden revisar con tranquilidad.