IA generativa en la banca: preparar el SDLC para squads agénticos

En banca, la conversación sobre IA generativa suele empezar por el chatbot de atención al cliente. Es comprensible: es lo visible. Pero el cambio más profundo no está en la ventanilla digital, sino en cómo construimos el software que sostiene al banco. Los asistentes de código ya escriben, prueban y documentan. El siguiente paso, los agentes que ejecutan tareas completas con cierta autonomía, obliga a repensar el ciclo de desarrollo (SDLC) de punta a punta.

Mi tesis es simple: los squads agénticos no se adoptan instalando una herramienta; se adoptan preparando el proceso para recibirlos. Un banco que no tiene claro quién aprueba qué, qué evidencia deja cada cambio y cómo se mide la calidad, solo conseguirá producir más rápido el mismo desorden.

De asistentes a agentes: qué cambia realmente

Un asistente sugiere; un agente actúa. Esa diferencia, que parece semántica, cambia la naturaleza del riesgo.

• Asistente: completa una función, propone una prueba, resume un documento. La persona decide si acepta cada sugerencia.
• Agente: recibe un objetivo ("implementa este endpoint con sus pruebas y abre la solicitud de cambio"), descompone el trabajo, usa herramientas, corrige sus propios errores y entrega un resultado.

Cuando el agente actúa, la pregunta ya no es "¿el código es correcto?", sino "¿el sistema que permitió a este agente actuar es gobernable?". En una institución regulada, esa segunda pregunta es la que importa.

Qué es un squad agéntico

Llamo squad agéntico a un equipo mixto en el que las personas definen intención, criterio y límites, y un conjunto de agentes especializados ejecuta partes acotadas del trabajo:

1. Agente de análisis: traduce una historia de usuario en criterios de aceptación verificables y señala ambigüedades.
2. Agente de implementación: escribe el código dentro de los patrones de arquitectura aprobados.
3. Agente de pruebas: genera y ejecuta pruebas unitarias, de contrato y de regresión.
4. Agente de revisión: contrasta el cambio con las reglas de seguridad, estilo y arquitectura.
5. Agente de documentación: actualiza la documentación técnica y la trazabilidad del cambio.

Las personas no desaparecen. Se desplazan hacia donde más valor aportan: decidir qué construir, fijar los límites y aprobar lo que entra a producción.

Cinco condiciones para preparar el SDLC

1. Requisitos que una máquina pueda verificar

Un agente es tan bueno como la instrucción que recibe. Las historias de usuario vagas ("mejorar la consulta de saldos") producen resultados vagos. Antes de pensar en agentes, conviene exigir criterios de aceptación concretos, ejemplos de entrada y salida, y reglas de negocio explícitas. Es una disciplina que mejora el trabajo incluso sin IA.

2. Arquitectura de referencia como "carril"

Los agentes necesitan carriles. Si el banco tiene patrones claros (cómo se expone un servicio, cómo se registra un evento, cómo se maneja un error), el agente puede moverse dentro de ellos. Si cada equipo resuelve lo mismo de forma distinta, el agente reproducirá esa dispersión a mayor velocidad.

Aquí la experiencia de construir una capa media gobernada con API Manager es útil: cuando la integración ya pasa por un punto con contratos, seguridad y observabilidad definidos, un agente puede generar un nuevo servicio sin inventar la forma de conectarlo.

3. Pruebas automatizadas como red de seguridad

No hay adopción responsable de agentes sin una batería de pruebas confiable. Si hoy la regresión depende de pruebas manuales al final del ciclo, ese es el primer cuello de botella a resolver. El agente puede escribir pruebas, pero el banco debe decidir qué nivel de cobertura y qué pruebas críticas son innegociables antes de aceptar cualquier cambio.

4. Trazabilidad y evidencia por defecto

El regulador y la auditoría interna no preguntarán si el código lo escribió una persona o un agente. Preguntarán quién lo aprobó, con qué evidencia y bajo qué control. Cada cambio debería dejar registro de:

• la instrucción o historia que lo originó,
• qué agente o persona produjo cada parte,
• qué pruebas y revisiones pasó,
• quién aprobó su paso a producción.

Diseñar esa trazabilidad desde el inicio es mucho más barato que reconstruirla después de un hallazgo.

5. Separación clara de permisos

Un agente no debería tener más permisos que los que necesita para su tarea. El agente de implementación no despliega a producción; el de pruebas no modifica datos reales; ninguno ve secretos en texto plano. Es el principio de mínimo privilegio aplicado a un nuevo tipo de "usuario".

Gobierno: el humano en el bucle no es opcional

En sectores regulados, la regla práctica que propongo es: la autonomía del agente es inversamente proporcional al impacto del cambio.

Tipo de cambio	Nivel de autonomía sugerido
Documentación, pruebas, refactor interno sin efecto funcional	Alta, con revisión por muestreo
Nuevas funcionalidades en canales digitales	Media, con revisión obligatoria por pares
Lógica de core, cálculos financieros, seguridad, datos de clientes	Baja: el agente propone, una persona decide

Marcos como COBIT ayudan a aterrizar esto: definir responsables, controles y métricas para un proceso que ahora tiene participantes no humanos. No hace falta inventar un gobierno nuevo; hace falta extender el que ya existe.

Riesgos que conviene nombrar

• Código plausible pero incorrecto. Los modelos generan soluciones que "se ven bien". Sin pruebas y revisión, el error llega a producción con apariencia de calidad.
• Fuga de información. Enviar código o datos sensibles a servicios externos sin acuerdos ni controles es un riesgo de cumplimiento. Esto empuja a evaluar modelos privados o desplegados en entornos controlados.
• Dependencia de proveedor. Atar todo el ciclo a una sola plataforma de agentes limita la capacidad de cambiar mañana.
• Erosión de conocimiento. Si el equipo deja de entender el código que mantiene, el banco pierde capacidad de respuesta ante incidentes.

Cómo empezaría

1. Elegir un dominio de bajo riesgo (documentación, pruebas, herramientas internas) y medir: tiempo de ciclo, defectos encontrados, retrabajo.
2. Definir la línea base antes del piloto. Sin medición previa, cualquier mejora es una opinión.
3. Escribir las reglas del juego: qué puede hacer un agente, qué no, quién aprueba y qué evidencia queda.
4. Escalar por niveles de riesgo, no por entusiasmo.
5. Formar a las personas en el nuevo rol: especificar, revisar y decidir.

Cierre

La IA generativa no va a reemplazar la disciplina de ingeniería en banca; va a exponer dónde falta. Los bancos que lleguen preparados a los squads agénticos serán los que ya tenían requisitos claros, arquitectura de referencia, pruebas automatizadas y trazabilidad. Para los demás, la IA será un amplificador de sus problemas actuales.

La buena noticia es que todo lo que prepara el terreno para los agentes también mejora el desarrollo hoy. Es una inversión que rinde aunque el futuro llegue más despacio de lo que anuncian.