Agentes de código en un banco: el control está en los permisos, no en los prompts, y la productividad aún hay que demostrarla

Por HackerNoon · 28 de octubre de 2026.

Lokesh Suri, vicepresidente de JPMorgan Chase, publica en HackerNoon una guía de cómo escalar asistentes de programación agénticos en una entidad regulada. Se basa, según él, en su experiencia apoyando a más de 600 ingenieros en una gran organización financiera. Conviene leerlo como testimonio de un profesional, no como un estudio independiente ni como una posición oficial del banco.

La propuesta es una arquitectura de cuatro capas. Gobernanza: reglas centrales que definen lo que nunca se permite, como leer ficheros de credenciales o saltarse la aprobación humana antes de un «push». Guardarraíles: «hooks», scripts que se ejecutan de forma determinista antes o después de cada acción del agente y bloquean patrones prohibidos. Conocimiento curado: «skills», procedimientos repetibles revisados como código. Integración: una lista cerrada de herramientas conectadas mediante el Model Context Protocol (MCP), el estándar abierto con el que los agentes acceden a sistemas externos. Debajo de todo, el pipeline de siempre: revisión de pull requests, tests y escaneo de seguridad. Los agentes no tienen un camino aparte a producción.

Los ejemplos de configuración usan Claude Code, de Anthropic, aunque el autor aclara que la arquitectura depende del tipo de control y no del producto. Los ingenieros de su entorno usan también GitHub Copilot, Windsurf y Codex.

El texto aporta un dato útil sobre la evidencia de productividad, que es contradictoria. Un ensayo aleatorizado citado por el autor midió una tarea nueva en JavaScript un 55,8% más rápida con asistente. Otro ensayo de 2025, con mantenedores experimentados trabajando en sus propios repositorios, encontró un 19% más de tiempo de finalización, aunque los participantes creían haber sido más rápidos. Sobre seguridad, un estudio citado indica que quienes usaban asistente escribían código menos seguro y confiaban más en él. Según el autor, la normativa tampoco ayuda: la guía de riesgo de modelos de la banca estadounidense, revisada en abril de 2026 (SR 26-2), deja fuera a la IA generativa y agéntica, y cada entidad debe aplicar sus propias prácticas.

El autor ilustra el diseño con un ataque hipotético de inyección de instrucciones. Un ticket contiene una orden oculta para leer el fichero .env y enviarlo a una URL externa. El modelo podría obedecer, pero la lectura la bloquea la política central, el «curl» saliente está denegado, el servidor MCP no autorizado es inalcanzable y cualquier «push» exige aprobación humana. Ninguna capa tiene que ser perfecta; el atacante debe vencerlas todas.

Nuestra lectura: lo más valioso del texto es un principio, «las reglas en código, no en prompts». Una instrucción en lenguaje natural es una sugerencia que el modelo puede ignorar o que alguien puede manipular. Un permiso denegado por configuración o un hook que devuelve error es una barrera. Es la misma lógica que vemos en la gobernanza de agentes empresariales: pasar de políticas escritas a controles verificables y registros auditables. En general, los reguladores y los equipos de riesgo acabarán pidiendo pruebas de que los controles funcionan, y quien tenga la política incorporada al código y cada acción registrada llegará a esa conversación con ventaja.

La parte más honesta del artículo es también la menos vistosa: medir. Un 55,8% de mejora en un caso y un 19% de pérdida en otro significan que la ganancia depende del contexto y de la madurez del código. El autor propone comparar cohortes de equipos que adoptan y que no adoptan, y mirar el tiempo de entrega y la tasa de fallos en cambios a la vez. Es la actitud correcta: una aceleración que sube los fallos no es una mejora. Cualquier banco que despliegue agentes por entusiasmo, sin esa línea base, no sabrá si ha ganado algo.

Hay límites que el propio autor reconoce. Los hooks basados en patrones de texto son una última línea de defensa y un usuario decidido puede esquivarlos, así que no sustituyen a un entorno aislado. Las skills se quedan obsoletas si nadie las mantiene. Y para equipos pequeños sin obligaciones regulatorias, la arquitectura es demasiado pesada. Añadimos una cautela propia: el artículo es una guía de práctica con experiencia personal, sin datos propios de resultados. No cuantifica cuánto mejoró la productividad ni cuántos incidentes evitó el diseño.

Para el largo plazo, el mensaje es esperanzador. Si los sectores más regulados consiguen que los agentes trabajen con controles verificables, la automatización del trabajo tedioso de ingeniería llegará sin sacrificar la confianza. A corto plazo, la transición pasa por equipos que dedican tanto esfuerzo a la gobernanza y la medición como al propio modelo. Ahí está, hoy, la parte difícil.