Sebastien Rousseau
ติดต่อ ›

Ingeniería agéntica para bancos: un blueprint 2026 para el COMEX y los ingenieros que lo construirán

La IA agéntica ha pasado del piloto a la producción. El 70 % de los bancos ya la utiliza; solo uno de cada cinco dispone de un modelo de gobernanza maduro. Los adversarios operan a velocidad de máquina, el estate heredado fue escrito para las hipótesis batch de los años 1960, y el plazo «alto riesgo» del Reglamento europeo de IA llega en doce semanas.

38 นาทีในการอ่าน

TL;DR. บทความนี้เป็น DRAFT แปลจากต้นฉบับภาษาสเปน รอการตรวจสอบโดยเจ้าของภาษา เนื้อหาหลัก ตัวอย่าง และการอ้างอิงยังคงเป็นภาษาสเปน เฉพาะ frontmatter เท่านั้นที่ถูกเปลี่ยนเป็นภาษาไทย

ประเด็นสำคัญ

Diagrama de arquitectura para la ingeniería agéntica en la banca.class="img-fluid clearfix"

La IA agéntica ha pasado del piloto a la producción en la banca mundial. El setenta por ciento de las instituciones la utiliza en mayor o menor grado; solo una de cada cinco dispone de un modelo de gobernanza maduro. En paralelo, adversarios autónomos operan a velocidad de máquina, el estate heredado COBOL con el que los nuevos sistemas deben interoperar fue escrito para las hipótesis batch de los años 1960, y el plazo «alto riesgo» del Reglamento europeo de IA está a doce semanas. He aquí la posición de ingeniería y gobernanza que un banco debe sostener.

TL;DR. La ingeniería agéntica es ya inevitable en banca: la adopción supera la gobernanza, los adversarios autónomos están operativos, y la fecha del 2 de agosto de 2026 del Reglamento europeo de IA obliga a producir AIBOM, plano de control de agentes y disciplina de desarrollo guiado por especificación en doce semanas. La ventaja competitiva pasa por interiorizar la capacidad institucionalmente, no por externalizarla a un proveedor.

Conclusiones clave

  • La adopción supera a la gobernanza: el 70 % de los bancos usa IA agéntica en algún grado; solo el 11 % la ha llevado a producción.
  • Tres vectores de riesgo se han operacionalizado en 2026: el adversario autónomo (Anthropic GTG-1002, Step Finance), la regresión de calidad del código generado por LLM, y la ancla del estate heredado.
  • El desarrollo guiado por especificación —no el vibe coding— es la disciplina compatible con SR 11-7, DORA, el Reglamento europeo de IA y SM&CR.
  • La arquitectura tiene cuatro capas: sustrato resistente a lo cuántico, AIBOM y modelos, flujos agénticos, y plano de control de agentes (audit, kill switches, HITL/HOTL).
  • La pila normativa converge en el 2 de agosto de 2026: obligaciones «alto riesgo» del Reglamento europeo de IA + DORA + SR 11-7 + ISO 42001 + SM&CR/Consumer Duty.
  • El plan práctico de 12 semanas —AIBOM, clasificación HITL/HOTL, plano de control, revisión de contratos de proveedor, ensayo de evaluación de conformidad, sign-off del consejo— es el mínimo defendible antes del plazo.

El año en que la ingeniería agéntica se volvió inevitable #

La conversación sobre la IA en los servicios financieros ha estado, hasta hace muy poco, dominada por dos cosas adyacentes pero distintas: las interfaces conversacionales generativas (útiles pero acotadas) y los patrones de Retrieval-Augmented Generation aplicados a los datos de empresa (útiles también, pero acotados). Lo que cambió entre finales de 2025 y principios de 2026: la tercera categoría —agentes autónomos que planifican, ejecutan y completan workflows multietapa con supervisión humana limitada— pasó de la demostración técnica a la realidad operativa, y cruzó simultáneamente las fronteras de la empresa y de la amenaza.

Andrej Karpathy, que acuñó el término «vibe coding» en febrero de 2025 ⧉, pasó el año siguiente observando a los ingenieros profesionales superarlo. Su revisión —«ingeniería agéntica»— es ahora el término operativo en toda la industria. La sustancia del cambio es simple: en el trabajo de software serio en 2026, los ingenieros no escriben código directamente el 99 % del tiempo. Orquestan agentes que lo hacen, mientras ejercen supervisión. El trabajo ya no consiste en teclear caracteres en un editor; consiste en producir especificaciones que restringen lo que los agentes pueden generar, diseñar las puertas de verificación que la salida debe pasar y organizar las decisiones arquitectónicas que los agentes implementan.

Este cambio parece una conversación de equipo de ingeniería. En la banca, no lo es. Es una conversación de consejo de administración, porque la misma capacidad agéntica que reescribe la forma en que se produce el código interno también reescribe la forma en que operan los adversarios externos, la forma en que los reguladores esperan que se ejerza la supervisión y la forma en que se define el perímetro institucional. Un banco que no tome posición sobre la ingeniería agéntica antes de finales de 2026 no es un banco que ha evitado la cuestión. Es un banco cuyos proveedores, adversarios y reguladores han respondido en su lugar.

El estado de la adopción en la banca #

El cuadro agregado es inequívoco. Según las investigaciones recopiladas en varias encuestas de 2026, el 70 % de los directivos bancarios ⧉ declara que sus instituciones ya utilizan IA agéntica en algún grado. Gartner prevé ⧉ que a finales de 2026 alrededor del 40 % de todas las compañías de servicios financieros harán funcionar agentes IA en alguna forma. El gasto IA de los servicios financieros está en la trayectoria de los 67.000 millones de dólares en 2028 (IDC). McKinsey estima que la IA agéntica puede devolver de 10 a 12 horas por semana a los relationship managers en banca.

El cuadro de la ejecución es menos alentador. KPMG indica ⧉ que el 99 % de las empresas prevé poner agentes autónomos en producción, pero solo el 11 % lo ha hecho. EY constata que el 34 % de los directivos ha empezado a utilizar agentes IA y que solo el 14 % los ha implementado plenamente. Forrester observa que el 57 % de las organizaciones estima carecer de las capacidades internas para sacar partido de la IA agéntica. La brecha entre la intención y la ejecución no es un artefacto de marketing. Refleja el trabajo de ingeniería, gobernanza y cultura que aún no se ha realizado.

La Financial Conduct Authority británica ha expresado públicamente sus inquietudes ⧉ sobre la velocidad de despliegue que supera la madurez de la gobernanza, una tensión que la Chief Data Officer Jessica Rasu encuadró como un riesgo a corto plazo para el consumidor minorista. McKinsey advirtió por separado que los bancos que no adapten su modelo de negocio ⧉ corren el riesgo de erosionar hasta 170.000 millones de dólares de beneficios mundiales para 2030. Las dos observaciones son simultáneamente correctas. La cuestión no es si hay que moverse; es cómo moverse con la integridad operativa y de gobernanza que la regulación financiera siempre ha exigido, y que los sistemas agénticos hacen más afilada.

Tres vectores de riesgo que los bancos deben interiorizar #

Antes de cualquier conversación arquitectónica, la atención del consejo debe centrarse en tres riesgos propios de los sistemas agénticos y que llegan antes de lo que la mayoría de bancos había previsto.

1. El adversario autónomo #

El desarrollo más desestabilizador de 2026 es la operacionalización de la IA agéntica del lado atacante. En agosto de 2025, Anthropic divulgó una categoría de actividad que llamó vibe hacking ⧉: cibercriminales utilizando IA agéntica para llevar a cabo ataques sofisticados a gran escala, con la IA integrada en la reconnaissance, la recolección de credenciales, la penetración de red y el análisis de los datos robados. En noviembre de 2025 ⧉, Anthropic divulgó la disrupción de una campaña llevada por un grupo patrocinado por el Estado chino (designado GTG-1002) que había desviado instancias de Claude Code para llevar a cabo espionaje autónomo contra unas treinta dianas en defensa, energía y tecnología, gestionando la IA del 80 al 90 % de las operaciones tácticas y operando a varios miles de peticiones por segundo, velocidades imposibles para operadores humanos.

En enero de 2026, Step Finance —un gestor de cartera DeFi en Solana— se vio comprometido de una manera que transformó una intrusión en dispositivo en una pérdida de 27 a 30 millones de dólares, porque los agentes IA de trading de la firma tenían los permisos para ejecutar grandes transferencias sin aprobación humana. El atacante engañó a la propia IA mediante ingeniería social, fingiendo ejecutar un programa de bug bounty autorizado. La lección ⧉ no era que la IA es intrínsecamente peligrosa; era que un agente IA que acepta una autorización reivindicada sin verificación es una debilidad de perímetro.

La tendencia agregada es lo que los bancos deben interiorizar. El Flashpoint 2026 Global Threat Intelligence Report identificó un aumento del 1.500 % en las discusiones ilícitas vinculadas a la IA ⧉ entre noviembre y diciembre de 2025, con atacantes desarrollando activamente sistemas autónomos que recopilan datos, gestionan la infraestructura, ajustan los mensajes y aprenden de los intentos fallidos sin supervisión humana continua. Jamie Dimon (JPMorgan) ha sido públicamente explícito ⧉: la ventaja inicial de esta tecnología va a la ofensiva, no a la defensa. La implicación es incómoda: un banco que hace funcionar operaciones de seguridad clásicas contra adversarios agénticos está, estructuralmente, en la posición de un jugador de ajedrez cuyo adversario dispone de un ordenador.

2. La regresión de calidad del código #

El segundo vector es interno y más discreto. El código generado por LLM, en ausencia de disciplina de especificación y verificación rigurosa, se entrega con defectos a una tasa claramente superior al código escrito por humanos. Un análisis SonarQube de cinco LLM punteros ⧉ generando código Java encontró que más del 70 % de las vulnerabilidades detectadas en la salida de Llama 3.2 90B se clasificaron como BLOCKER, y que alrededor de dos tercios de las vulnerabilidades de GPT-4o y OpenCoder-8B se clasificaron como BLOCKER o CRITICAL. Pearce y otros (IEEE S&P) encontraron que alrededor del 40 % de los programas generados por LLM en contextos sensibles a la seguridad contenían vulnerabilidades. Yan y otros (2025) sitúan el rango en el 9,8 al 42,1 % según sus benchmarks. Un catálogo separado de Fu y otros identifica 43 CWE en tres herramientas de generación de código IA.

Para una industria no regulada, es un impuesto a la productividad. Para un banco, es un riesgo regulatorio y operativo que se compone. Código entregado con una tasa elevada de vulnerabilidades en un sistema que gestiona pagos, liquidación o datos de clientes no es una cuestión de calidad de código en sentido abstracto; es la superficie que los adversarios de clase GTG-1002 sondearán en 2027 con las mismas herramientas agénticas que lo han producido. La defensa no es prohibir el código generado por LLM (comercialmente imposible), sino rodearlo de la infraestructura de verificación y especificación que garantiza que los defectos afloran antes del despliegue. Esa es la razón práctica por la que el desarrollo guiado por especificación está siendo adoptado a toda velocidad por las organizaciones de ingeniería de empresa que no son nativamente compañías de tecnología.

3. La ancla del legacy #

El tercer vector es el que los bancos ya comprenden mejor, y que la transición agéntica ha hecho simultáneamente más urgente y más tratable. Más del 70 % de las empresas del Fortune 500 todavía dependen de mainframes, señala el análisis de Computer Weekly ⧉, a menudo construidos sobre décadas de COBOL y RPG entrelazados con lógica de negocio a medida. En los servicios financieros específicamente, las tecnologías heredadas consumen del 70 al 75 % del gasto IT anual ⧉. Un estudio CIO citado en el análisis sectorial 2026 encontró que el 63 % de los bancos todavía se apoyan en código escrito antes de 2000, y que más del 75 % reporta tener solo una o dos personas internas con las competencias para mantenerlo.

Lo que cambió en febrero de 2026 fue la llegada de un instrumental agéntico creíble para la modernización del legacy. El anuncio de Anthropic de que Claude Code podía cartografiar las dependencias COBOL, documentar los workflows e identificar los riesgos ⧉ que llevaría meses a los analistas humanos hacer aflorar —combinado con capacidades similares de Microsoft (GitHub Copilot para COBOL, Watsonx Code Assistant) y AWS (Mainframe Modernization con IA agéntica)— comprimió materialmente la curva de coste de la modernización. La reacción de la cotización de IBM (caída del 13 % el día del anuncio) fue una señal de mercado inelegante pero precisa. La IA representa ahora alrededor de un tercio de la inversión de modernización de empresa, y más del 75 % de las empresas utiliza la IA en su estrategia de modernización. La ancla del legacy es, por primera vez, un problema de ingeniería tratable más que generacional.

Por qué el vibe coding no puede ser el valor por defecto en la banca #

Vale la pena ser preciso sobre por qué el vibe coding —prompt corto, observar la salida, iterar— fracasa como workflow por defecto en un estate regulado. El modo de fallo no es el más evidente (el LLM alucina de vez en cuando). El modo de fallo es estructural y aparece simultáneamente en cuatro lugares.

El primero es la ausencia de convenciones compartidas. Varios ingenieros trabajando por prompts producirán cinco maneras diferentes de hacer la misma cosa en la misma base de código en un solo trimestre. En un contexto no regulado, es deuda técnica. En un contexto regulado, es la superficie que se rompe ante un examen.

El segundo es la decadencia del contexto. Los agentes IA son sin estado. En un gran proyecto, las conversaciones exceden las ventanas de contexto, y el razonamiento detrás de las decisiones arquitectónicas anteriores se evapora. El mismo agente, dos semanas más tarde, tomará la decisión inversa en una nueva conversación porque nada persiste la justificación de la primera. Para sistemas que exigen una pista de auditoría para los reguladores, es estructuralmente incompatible.

El tercero es la acumulación invisible de defectos. Los resultados de Pearce, Yan y SonarQube citados antes no son casos marginales. Es la tasa base a la que los LLM generan código vulnerable en ausencia de disciplina de especificación y pruebas rigurosas. Un banco que hace funcionar workflows de vibe coding en producción acumula esos defectos al mismo ritmo, sin la visibilidad de superficie que permitiría saber qué se ha entregado.

El cuarto es el problema de trazabilidad regulatoria. El artículo 12 del Reglamento europeo de IA exige el registro automático de las entradas y salidas para los sistemas IA de alto riesgo. SR 11-7 exige roles documentados de propietario y validador de modelo, una gestión del cambio para las actualizaciones de modelo y un reporting al consejo sobre el riesgo modelo IA. DORA exige una gestión de los riesgos ICT exhaustiva con pruebas documentadas. Ninguna de estas obligaciones puede satisfacerse con un workflow cuyo artefacto principal es un historial de chat que nadie persiste.

La conclusión no es que los LLM sean impropios para la banca. La conclusión es que el workflow que los rodea debe producir especificaciones, pistas de auditoría y puertas de verificación como entregables de primera clase en lugar de como pensamiento ulterior. Eso es, operativamente, el desarrollo guiado por especificación.

Desarrollo guiado por especificación en un estate regulado #

El desarrollo guiado por especificación (SDD) invierte el orden del trabajo. En lugar de zambullirse en la implementación e iterar con un agente, el equipo produce primero una especificación —decisiones arquitectónicas, requisitos, contratos de interfaz, criterios de éxito, restricciones de seguridad— y el agente genera código que satisface la especificación. La verificación está estructurada: la especificación define lo que la salida debe hacer, y un proceso separado (generación de tests, revisión de código, verificación formal cuando es aplicable) verifica que se ha hecho.

El instrumental práctico se consolidó a finales de 2025 y principios de 2026. Spec Kit de GitHub ⧉ (lanzado a finales de 2025) formaliza la intención antes de la generación de código. AWS incorpora workflows spec-first directamente en su IDE Kiro. JetBrains y Cursor han introducido modos de planificación que estructuran la interacción con la IA. Frameworks como BMAD (Breakthrough Method for Agile AI-Driven Development) van más lejos con equipos de agentes IA especializados que reflejan los roles de analista, arquitecto, desarrollador y QA a lo largo del SDLC. Constitutional SDD, formalizado en un artículo arXiv en febrero de 2026, incorpora restricciones de seguridad explícitas con mapeos de vulnerabilidades CWE en la propia especificación.

Para un banco, la variante que importa es lo que el análisis de Augment Code llama desarrollo anclado en la especificación: las especificaciones vienen primero, la IA genera código restringido por ellas, y capas adicionales de gobernanza (restricciones constitucionales, puntos de supervisión, puertas de aprobación humana) se sitúan entre la generación y el merge. Es la única variante que produce la pista de auditoría que el artículo 12 del Reglamento europeo de IA espera, el rol documentado de validador que SR 11-7 exige, y la disciplina de gestión del cambio que DORA pide.

La inversión requerida es real, pero también es tratable. Las instituciones que lo hacen bien han desplazado el día a día de los ingenieros de teclear caracteres a producir dos artefactos: una especificación que el agente satisfará y un arnés de verificación que la salida debe pasar. La demanda cognitiva sobre el ingeniero es más alta en ciertos aspectos (la claridad de intención cuenta más que nunca) y más baja en otros (el trabajo mecánico de escribir boilerplate ha desaparecido). Las instituciones que aún no han hecho ese cambio operan todavía en un modo en el que el LLM es un mecanógrafo más rápido. Esa posición no es sostenible en un estate regulado más allá de los próximos doce meses.

La pila regulatoria que se aplica ahora #

El perímetro regulatorio 2026 en torno a la IA en la banca ya no es una checklist; es una pila de obligaciones que se solapan y que deben razonarse juntas. La fecha más consecuente es el 2 de agosto de 2026, cuando las obligaciones «alto riesgo» del Reglamento europeo de IA se vuelven plenamente aplicables ⧉. El anexo III clasifica explícitamente el scoring crediticio, la evaluación de solvencia, la evaluación de riesgos en seguros de vida y salud, así como la evaluación o clasificación de la situación financiera de los individuos como de alto riesgo. Las obligaciones que se derivan de esta clasificación incluyen evaluaciones de conformidad, sistemas de gestión de la calidad, marcos de gestión del riesgo, documentación técnica, registro en la base de datos europea, una gobernanza de los datos robusta, la supervisión humana y protecciones de ciberseguridad. Las penalizaciones por incumplimiento de las obligaciones de alto riesgo alcanzan 35 millones de euros o el 7 % de la facturación mundial anual, el mayor de los dos.

Junto al Reglamento europeo de IA:

Tres modos de desarrollo asistido por IA comparados #

Dimensión Vibe Coding Desarrollo guiado por especificación Ingeniería agéntica
Entrada principal Prompt corto Especificación formal Especificación + plan de orquestación de agentes
Rol del ingeniero Iterador de prompts Autor de especificación Orquestador y verificador
Disciplina de salida Generación directa de código Código restringido por la spec Workflows multiagente que producen código, tests, docs
Pista de auditoría Historial de chat (no persistido) Spec + código generado + tests Spec + trazas de agente + artefactos de verificación
Tasa de defectos (solo LLM) 10 al 40 % de vulnerabilidades (base de la literatura) Sensiblemente reducida por las restricciones de spec Más baja con puertas de verificación
Trazabilidad regulatoria Insuficiente para la IA de alto riesgo Compatible con el artículo 12 del Reglamento europeo de IA Diseñado para Artículo 12 + SR 11-7 + DORA
¿Adaptado a la banca? No, para producción Sí, con gobernanza Sí, con gobernanza madura
Techo de capacidad Acotado por el prompting único Acotado por la calidad de la spec Acotado por la calidad de la orquestación

Fuente: síntesis de los comentarios de Karpathy (2026), análisis SDD de Augment Code ⧉, análisis CGI sobre el desarrollo guiado por especificación ⧉, y la literatura académica sobre las tasas de vulnerabilidad de la generación de código por LLM (Pearce y otros, Yan y otros, Fu y otros, 2023-2025).

Construir el banco agéntico: una vista de arquitectura #

La posición estratégica detrás de estos workflows es lo que el COMEX debe apropiarse explícitamente. La ingeniería agéntica en la banca no es una iniciativa de productividad de desarrollador. Es una capacidad institucional que afecta a los recorridos de cliente de extremo a extremo, al conjunto del ciclo de vida de la transacción, y al sustrato criptográfico y de auditoría que sustenta a ambos. Cuatro capas de esta capacidad merecen la atención ejecutiva directa, de arriba abajo:

Capa 4 — Plano de control de agentes Gobernanza, auditoría, kill switches, detección de anomalías de comportamiento, override humano. Configuraciones de supervisión HITL y HOTL por clase de agente.

Capa 3 — Workflows agénticos Recorridos de cliente, operaciones internas, pipeline de desarrollo. Pilotaje por especificación por defecto para los flujos de alto riesgo.

Capa 2 — Datos y modelos AIBOM (AI Bill of Materials), registro de modelos, sustrato de retrieval, versionado de prompt templates, linaje de los fine-tunes.

Capa 1 — Fundación resistente a lo cuántico ML-KEM, ML-DSA, PKI híbrida, agilidad criptográfica. El sustrato del que dependen las reivindicaciones de integridad de todas las capas superiores.

Capa 1 — La fundación resistente a lo cuántico. Cada capa por encima asume la integridad del sustrato criptográfico. Con la hoja de ruta del G7, el plan NCSC en tres fases y BIS Project Leap públicamente documentados, ya no es una preocupación de nicho. Los sistemas agénticos cuyas pistas de auditoría están firmadas bajo ECDSA clásico, o cuyo establecimiento de claves depende de RSA o ECDH, verán expirar sus reivindicaciones de integridad con la criptografía. Las instituciones que lo hacen bien suben el trabajo postcuántico aguas arriba y tratan ML-KEM, ML-DSA y la PKI híbrida como el sustrato sobre el que descansan las garantías de auditoría e integridad de todas las capas superiores.

Capa 2 — La capa de datos y modelos. Es ahí donde vive el AI Bill of Materials (AIBOM). Análogo al Cryptographic Bill of Materials utilizado en la planificación de la migración postcuántica, el AIBOM es el inventario de cada modelo, conjunto de datos, prompt template, índice de retrieval, fine-tune y dependencia IA de terceros que la institución opera. Es el artefacto que el artículo 49 del Reglamento europeo de IA exige de hecho, el inventario que los exámenes SR 11-7 reclaman ahora, y la fundación de toda postura de gobernanza creíble. La mayoría de instituciones no lo tienen. Lo necesitarán para agosto.

Capa 3 — Los workflows agénticos. Es la capa que la mayoría de instituciones está construyendo actualmente, a menudo sin atención suficiente a las capas 1, 2 y 4. Los workflows en sí van del interno (generación de código, redacción de documentos regulatorios, triaje de servicio al cliente) al cliente (copilotos para relationship managers, onboarding, orquestación KYC, supervisión de transacciones, optimización FX) hasta el plenamente autónomo (operaciones de tesorería, ciertas funciones de trading y de gestión del riesgo cuando la tolerancia del regulador lo permite). La disciplina estratégica en esta capa es tratarla como ingeniería de sistemas, no como desarrollo de aplicaciones —patrones de orquestación, reglas de escalado, puertas human-in-the-loop y emisión de auditoría son preocupaciones de diseño de primera clase.

Capa 4 — El plano de control de agentes. Es lo que Deloitte ha calificado de «sala de control de los agentes» ⧉: la auditoría en tiempo real, el logging de las acciones, la detección de anomalías de comportamiento, los kill switches y la infraestructura de override humano que rodean a cada agente en producción. La pérdida de Step Finance no fue, técnicamente, un fallo de IA. Fue un fallo del plano de control: los agentes tenían permisos que no deberían haber tenido, y la anomalía de comportamiento que debería haber desencadenado una parada no se desencadenó. Las instituciones que construyen el plano de control primero —antes de escalar más el despliegue de agentes— son las que no verán incidentes de clase Step Finance en 2027.

La comparación pertinente para el COMEX no es «¿hacemos más IA que nuestros competidores?». Es si la institución posee las cuatro capas, o si una o más capas están silenciosamente delegadas a un proveedor sin capacidad contractual para satisfacer las exigencias de documentación del artículo 13 del Reglamento europeo de IA. Esta última es una posición que parece correcta hasta que un regulador abre la cuestión.

Supervisión humana en la práctica: HITL vs HOTL #

La distinción única dentro de la capa 4 sobre la que los reguladores concentran más su atención en 2026 es la que existe entre dos modelos de supervisión. Ambos son formas de supervisión humana; difieren en latencia, escala y en la hipótesis que el regulador acepta sobre el comportamiento del agente.

Human-in-the-Loop (HITL) es el modelo en el que un agente no puede ejecutar una acción consecuente sin aprobación humana explícita. El agente prepara la decisión, la presenta y espera. Un agente de remediación KYC que señala una cuenta para cierre pero no puede cerrarla sin la firma de un compliance officer es HITL. La compensación es operativa: HITL es más seguro y produce una pista de auditoría inequívoca para el artículo 14, pero no escala para los workflows de alto volumen y baja latencia.

Human-on-the-Loop (HOTL) es el modelo en el que un agente se ejecuta de manera autónoma en parámetros acotados, con humanos supervisando la telemetría en tiempo real y conservando la autoridad de detener al agente en cualquier momento. Un agente de filtrado de fraude en tiempo real que autobloquea las transacciones que coinciden con ciertos patrones de riesgo, con un equipo de operaciones humano que supervisa el volumen de alertas e interviene en las anomalías, es HOTL. La compensación es inversa: HOTL escala, pero depende de parámetros de agente correctamente ajustados y de una detección de anomalías de comportamiento que detecte la deriva antes de que los daños se acumulen.

El artículo 14 del Reglamento europeo de IA no prescribe HITL o HOTL; exige que la supervisión humana sea significativa. La implicación práctica es que cada agente de alto riesgo que el banco opere debe tener una posición explícita y documentada sobre el modelo que se aplica, por qué, y cuál es el camino de escalado cuando el agente encuentra situaciones fuera de sus parámetros acotados. La mayoría de bancos que hacían funcionar pilotos en 2025 no tenían esta documentación. La mayoría de bancos que harán funcionar agentes en producción en agosto de 2026 la necesitarán.

La regla de decisión no es compleja. Para las acciones consecuentes, de bajo volumen e irreversibles —denegación de crédito a una persona física, cierre de cuenta, autorización de transferencia de alto importe, presentación de declaración regulatoria— HITL es el valor por defecto defendible. Para las acciones de alto volumen, reversibles y con parámetros acotados —alertas de supervisión de transacciones, clasificación de documentos, triaje rutinario de servicio al cliente— HOTL es apropiado, a condición de que la detección de anomalías de comportamiento y la infraestructura de kill switch sean maduras. Los bancos que tratan cada workflow como HITL no capturarán la palanca operativa de los sistemas agénticos. Los bancos que tratan cada workflow como HOTL tendrán antes o después su momento Step Finance.

Comprar o construir: el problema de los agentes de terceros #

La realidad 2026 que ha alcanzado a la mayoría de los bancos es que no construirán, principalmente, la capacidad agéntica. La comprarán. El paisaje de proveedores —la plataforma banking agéntica de Oracle lanzada en febrero de 2026, Watsonx de IBM, la suite Copilot de Microsoft, AWS Bedrock Agents, Salesforce Agentforce, NowAssist de ServiceNow, y la ola de proveedores de agentes especialistas fintech— se mueve más rápido que la ingeniería interna de los bancos. La consecuencia estratégica es que la mayoría de agentes que operarán en un banco en 2027 habrán sido escritos por otro, y la cuestión de gobernanza ya no es «¿podemos confiar en nuestros agentes?» sino «¿podemos confiar en los agentes que hemos comprado, y podemos demostrarlo a un regulador?».

Es el desafío más ruidoso y menos reconocido bajo DORA. Los artículos 28 a 30 del reglamento hacen de la gestión del riesgo ICT de terceros un campo supervisor activo, con exigencias explícitas que cubren las cláusulas contractuales, el seguimiento continuo, la evaluación del riesgo de concentración y las estrategias de salida. Las Autoridades Europeas de Supervisión mantienen un registro de los proveedores ICT terceros críticos, con poderes de supervisión directa sobre los designados como tales. La nueva realidad operativa es que los proveedores IA de 2026 —proveedores de modelos punteros, proveedores de plataformas de agentes, SaaS IA-enabled— son, cada vez más, los terceros ICT para los que DORA fue escrito.

Para un banco en posición de compra, se aplican tres disciplinas prácticas:

Exija el AIBOM del proveedor. Todo producto agéntico comprado para workflows de alto riesgo debe acompañarse de una bill of materials documentada que cubra los modelos subyacentes, la procedencia y limitaciones de los datos de entrenamiento, los fine-tunes aplicados, los índices de retrieval accedidos, las versiones de prompt templates y la cadena de dependencias hacia los componentes agente aguas abajo. Es el artefacto que el banco necesitará para satisfacer las exigencias de documentación del artículo 13 del Reglamento europeo de IA. El banco no puede producirlo retrospectivamente de un proveedor que no se haya comprometido contractualmente.

Pruebe la caja negra, no el folleto. Las evaluaciones de procurement de proveedores se han centrado históricamente en la comparación de funcionalidades y las entrevistas con clientes de referencia. Para los sistemas agénticos, no basta. La institución debe realizar pruebas de comportamiento del agente en condiciones análogas a su despliegue de producción objetivo, incluido el probing adversarial para la inyección de prompt, la resistencia a la ingeniería social (el vector Step Finance), la deriva bajo cambio de distribución de datos, y los modos de latencia y fallo de los caminos de kill switch y override. La mayoría de contratos de proveedor actuales no autorizan esta profundidad de testing sin negociación específica; esa negociación debe tener lugar antes de la firma del contrato, no después.

Renegocie los contratos en los términos del artículo 13. La mayoría de acuerdos de proveedor IA existentes no contienen ninguno de los derechos de documentación, auditoría, notificación de cambio de modelo, reporting de incidente o divulgación de subcontratistas que el Reglamento europeo de IA y DORA exigen conjuntamente. El análisis Regulativ de firmas británicas ⧉ fue explícito en este punto: la revisión jurídica de los acuerdos de proveedor lleva semanas, y la mayoría de instituciones no pueden satisfacer el artículo 13 para un modelo cuyo proveedor nunca se ha visto contractualmente obligado a revelar su funcionamiento interno. La obligación regulatoria recae en el desplegador, no en el proveedor. Los equipos de procurement deben saberlo antes del próximo ciclo de renovación, no después de una investigación regulatoria.

El resumen para el consejo es que la relación con el proveedor ha pasado del procurement a la transferencia de riesgo, y el riesgo no se transfiere, en realidad. El banco sigue siendo el desplegador. El banco sigue siendo responsable. El banco necesita los instrumentos contractuales y la disciplina de testing que hacen su responsabilidad tratable en lugar de meramente formal.

Lo que esto significa por tipo de banco #

La respuesta correcta varía. El patrón siguiente es una segmentación gruesa, no una prescripción.

Bancos universales de primer nivel #

Las instituciones con 1 billón de dólares de balance y una presencia mundial son simultáneamente las más expuestas (perímetro regulatorio más amplio, estate heredado más grande, diana de mayor valor para los adversarios autónomos) y las mejor dotadas. La prioridad estratégica es construir el plano de control primero —capa 4 de la arquitectura anterior— e introducir la disciplina del desarrollo guiado por especificación en la función de ingeniería interna antes de escalar más el despliegue de agentes. La consecuencia competitiva de hacerlo bien es significativa; la consecuencia de hacerlo mal es existencial, dada la exposición a las penalizaciones del Reglamento europeo de IA y la exposición operativa a los patrones de amenaza de clase GTG-1002.

Bancos de tamaño intermedio y regionales #

La cuestión competitiva para los bancos de segundo nivel es más afilada que para los de primer nivel. Afrontan el mismo perímetro regulatorio sin el mismo presupuesto de gobernanza, la misma superficie de amenaza sin los mismos recursos defensivos, y una base de clientes que se compara cada vez más con fintechs IA-nativas. La respuesta práctica es estandarizar fuertemente sobre un pequeño conjunto de proveedores verificados (con contratos que satisfagan las exigencias de documentación del artículo 13), invertir en la disciplina del desarrollo guiado por especificación más que en una ingeniería de plataforma a medida, y utilizar el instrumental agéntico para comprimir el calendario de modernización COBOL que ha sido una ancla estratégica durante dos décadas. Las instituciones que se mueven pronto aquí cerrarán, materialmente, la brecha tecnológica con los bancos de primer nivel por primera vez en una generación.

Fintechs, PSP e instituciones próximas al cripto #

El segmento fintech e instituciones de pago tiene el problema inverso: la agilidad es alta, la gobernanza es a menudo más débil que en los bancos pares, y la exposición a las penalizaciones del Reglamento europeo de IA es, para una fintech de tamaño medio, potencialmente existencial. La disciplina estratégica es tratar la gobernanza IA como una puerta de readiness de producto en lugar de una capa de cumplimiento, construyendo el AIBOM, el sustrato de auditoría y los workflows guiados por especificación en la cultura de ingeniería desde el principio en lugar de retrofittearlos bajo presión regulatoria. Para las instituciones cuya infraestructura de pago intersecta con el plazo SWIFT CBPR+ de direcciones estructuradas de noviembre de 2026, la inversión en ingeniería agéntica es también el mecanismo natural para industrializar el trabajo de remediación de direcciones estructuradas —las reglas de validación, la aplicación de la calidad de los datos y la integración en el pipeline CI son precisamente los patrones que los workflows guiados por especificación hacen tratables—.

Funciones de ingeniería interna #

Para los ingenieros e investigadores que leen este artículo, la disciplina de trabajo que importa es la cotidiana. Desplace el centro de gravedad del trabajo de teclear caracteres a producir especificaciones y arneses de verificación. Trate las trazas de agente, los planes intermedios y las puertas de aprobación como artefactos de primera clase en su gestión de versiones. Invierta en el instrumental —Spec Kit, Kiro, el modo plan de Cursor, Claude Code con skill files a nivel de proyecto— que hace de la especificación el artefacto duradero y del código generado lo desechable. El deslizamiento ergonómico es real. El beneficio profesional es que la disciplina adoptada en la frontera es también la disciplina que sobrevive al examen regulatorio.

El plan de acción de 12 semanas hacia agosto de 2026 #

Para el sponsor ejecutivo que pilota un programa de ingeniería agéntica entre ahora y la fecha de aplicación del Reglamento europeo de IA, el trabajo se comprime en una secuencia de doce semanas. El plan siguiente no es exhaustivo; es el mínimo que un consejo debería esperar de un programa creíble antes del 2 de agosto de 2026.

Semanas 1-2 — Producir el AIBOM. Poner en marcha el inventario centralizado de cada sistema IA, modelo, conjunto de datos, prompt template, índice de retrieval, fine-tune y dependencia IA de terceros en producción o desarrollo. Cartografiar cada entrada con la clasificación del anexo III del Reglamento europeo de IA. El entregable es una fuente única de verdad que el CRO, el CCO, el CISO y el CTO pueden consultar.

Semanas 3-4 — Clasificar el modelo de supervisión por sistema. Para cada agente de alto riesgo y consecuente, documentar explícitamente si el modelo de supervisión es HITL o HOTL, la justificación, el camino de escalado, y la persona responsable nominada bajo SM&CR (UK) o el régimen nacional equivalente. Cuando la respuesta no sea clara, por defecto HITL hasta que el análisis esté completo.

Semanas 5-6 — Construir o endurecer el plano de control de agentes. Logging de acciones en tiempo real, detección de anomalías de comportamiento, kill switches y caminos de override operativos sobre cada agente en producción. Cuando el plano de control aún no exista para un sistema, ese sistema pasa a estado de despliegue restringido hasta que exista.

Semanas 7-8 — Revisión de los contratos de proveedor. Lo jurídico y lo procurement recorren cada contrato activo de proveedor IA en busca de los derechos de documentación del artículo 13, notificación de cambio de modelo, reporting de incidente, derechos de auditoría y divulgación de subcontratistas. La salida es una lista por tiers: conforme, remediación requerida, reemplazo requerido. Las decisiones de reemplazo deben arrancar ahora para tener una oportunidad de culminar este año.

Semanas 9-10 — Ensayo general de la evaluación de conformidad. Para cada sistema de alto riesgo bajo el anexo III, completar el workflow de evaluación de conformidad como si un organismo notificado llegara la semana siguiente. Esto hará aflorar brechas que parecen menores sobre el papel y que son operacionalmente severas en el examen. Corrija lo que pueda corregirse; documente lo residual.

Semanas 11-12 — Validación previa al cambio y sign-off del consejo. Revisión final del AIBOM, de las clasificaciones HITL/HOTL, de las pruebas del plano de control, del estado de remediación de proveedores y de las salidas de evaluación de conformidad. Responsabilidad de senior manager nominada confirmada. Posición consignada en el acta del consejo. Notificar al regulador cuando el marco espere prenotificación.

Las instituciones que completen esta secuencia de doce semanas no habrán resuelto la ingeniería agéntica. Habrán establecido la base que un programa creíble exige. Las instituciones que no han empezado a la fecha de publicación de este artículo no son, como formuló el análisis Regulativ del lado SWIFT, solamente negligentes. Son la mayoría. La pregunta que cada CCO, CRO y CTO debe hacerse en los próximos quince días es si la firma actúa en mayo o entra en pánico en julio.

Conclusión #

La observación dura que se ha cristalizado a escala industrial en los últimos seis meses es que las viejas maneras de operar a escala de empresa están superadas no por una nueva tecnología sino por un nuevo patrón de trabajo. Las herramientas agénticas han revelado —a veces en producción, a veces en informes de incidente— fallos y brechas en los estates heredados que se acumulaban silenciosamente desde hacía años. Las mismas herramientas han dado a los actores maliciosos recursos que antes exigían apoyo estatal. Las mismas herramientas, usadas internamente con disciplina, constituyen el camino más creíble para que las instituciones cierren el retraso del legacy, satisfagan el plazo regulatorio de agosto de 2026 y alcancen el tempo operativo que las expectativas de los clientes y las realidades competitivas exigen ahora.

Las instituciones que se apropien de esta posición internamente —que traten la ingeniería agéntica como una capacidad estructural del banco en lugar de una capa de productividad comprada a un proveedor— pasarán los dos próximos años componiendo su ventaja. Las instituciones que no lo hagan pasarán los dos próximos años descubriendo, en informes de incidente y findings de regulador, lo que deberían haber construido. La elección entre estos dos resultados es una decisión de consejo de 2026, no una decisión tecnológica de 2028.

Para el contexto previo en este sitio, el artículo de abril de 2026 sobre los umbrales cuánticos cubrió la trayectoria material que sustenta la capa 1 de la arquitectura anterior, el artículo de mayo de 2026 sobre la migración postcuántica en finanzas corporativas cubrió el sustrato criptográfico en profundidad, el análisis de mayo de 2026 sobre el plazo pacs.008 de direcciones estructuradas cubrió la disciplina regulatoria y de ingeniería que la validación guiada por especificación hace tratable, y los trabajos Rust de código abierto sobre KyberLib, pain001 y pacs008 se inscriben en el esfuerzo más amplio por poner primitivas de calidad de producción —resistentes a lo cuántico, conformes con pagos, listas para auditoría— en manos de los equipos de ingeniería que construirán la banca agéntica. La conexión entre estas piezas no es fortuita. Es la forma del trabajo que los dos próximos años exigen.

Preguntas frecuentes #

¿Cuál es la diferencia entre IA generativa, IA agéntica e ingeniería agéntica?

La IA generativa produce contenido en respuesta a un prompt; es reactiva. La IA agéntica persigue objetivos definidos de manera autónoma, accediendo a los datos, utilizando herramientas y tomando acciones sobre workflows multietapa sin necesitar un prompt humano en cada paso. La ingeniería agéntica —el término adoptado por Karpathy en 2026 ⧉— es la disciplina de trabajo consistente en orquestar agentes contra especificaciones detalladas con supervisión humana. Para la banca, la distinción importa porque el perímetro regulatorio, el modelo de amenaza y la disciplina de ingeniería son diferentes para cada categoría. Una interfaz de chat y un agente de trading plenamente autónomo no están en la misma clase regulatoria, y tratarlos como si lo estuvieran crea exposición en los dos extremos.

¿Por qué es tan consecuente el plazo de agosto de 2026 del Reglamento europeo de IA para los bancos?

El anexo III del Reglamento europeo de IA clasifica explícitamente varios casos de uso IA bancarios centrales como de alto riesgo: la evaluación de solvencia y el scoring crediticio de personas físicas, la evaluación de riesgos y la tarificación en seguros de vida y salud, y la evaluación o clasificación de la situación financiera de los individuos. A partir del 2 de agosto de 2026, los desplegadores de estos sistemas deben demostrar el cumplimiento con sistemas de gestión de la calidad, marcos de gestión del riesgo, documentación técnica, evaluaciones de conformidad, registros en la base de datos europea, una gobernanza de los datos robusta, la supervisión humana y protecciones de ciberseguridad. El artículo 12 exige el registro automático de las entradas y salidas. El artículo 14 exige una supervisión humana significativa (HITL o HOTL, según el sistema). Las penalizaciones alcanzan 35 millones de euros o el 7 % de la facturación mundial anual. El trabajo para satisfacer estas obligaciones es trabajo de ingeniería —no trabajo documental— y es la razón práctica por la que la disciplina guiada por especificación se aceleró en el primer trimestre de 2026.

¿Cuál es la diferencia práctica entre HITL y HOTL, y cuándo se aplica cada modelo?

HITL (Human-in-the-Loop) significa que el agente no puede ejecutar acciones consecuentes sin aprobación humana explícita. HOTL (Human-on-the-Loop) significa que el agente se ejecuta de manera autónoma en parámetros acotados, con humanos supervisando la telemetría y conservando la autoridad de detención en cualquier momento. El artículo 14 del Reglamento europeo de IA exige que la supervisión sea significativa pero no prescribe qué modelo. La regla de decisión consiste en aplicar HITL cuando la acción es consecuente, de bajo volumen e irreversible (denegación de crédito, cierre de cuenta, autorización de transferencia de alto importe, presentación de declaración regulatoria), y HOTL cuando la acción es de alto volumen, reversible y con parámetros acotados (alertas de supervisión de transacciones, clasificación de documentos, triaje rutinario de servicio al cliente). Ambos exigen que la infraestructura de kill switch y override sea operativa y esté probada; la diferencia es si el humano está aguas arriba de la ejecución (HITL) o al lado (HOTL).

La mayoría de nuestros agentes vendrán de proveedores. ¿Cómo satisfacer DORA y el Reglamento europeo de IA para sistemas que no hemos construido?

La obligación regulatoria recae en el desplegador, no en el proveedor. La respuesta práctica es triple. Primero, exija al proveedor un AIBOM documentado antes de la firma: linaje de los modelos, procedencia de los datos de entrenamiento, fine-tunes, prompt templates, índices de retrieval, cadena de dependencias. Segundo, realice un testing de comportamiento del agente en condiciones análogas a la producción, incluido el probing adversarial para la inyección de prompt y la resistencia a la ingeniería social. Tercero, renegocie los contratos de proveedor para incluir los derechos de documentación del artículo 13, notificación de cambio de modelo, reporting de incidente, derechos de auditoría y divulgación de subcontratistas; la mayoría de contratos existentes no incluye nada de eso. Los artículos 28 a 30 de DORA cubren la gestión del riesgo ICT de terceros y constituyen el ancla regulatoria pertinente del lado europeo; la guía FFIEC es el equivalente del lado estadounidense. El trabajo es significativo; no puede aplazarse.

¿Hasta qué punto deben preocuparse realmente los bancos por los adversarios agénticos?

La respuesta honesta es que la amenaza es real y operacionalmente distinta de las amenazas cibernéticas anteriores. La divulgación por Anthropic de GTG-1002 en noviembre de 2025 es el ejemplo canónico: IA agéntica gestionando del 80 al 90 % de las operaciones tácticas en una campaña de espionaje patrocinada por un Estado, contra unas treinta dianas en defensa, energía y tecnología, operando a varios miles de peticiones por segundo. El incidente Step Finance en enero de 2026 —pérdida de 27 a 30 millones de dólares debido a agentes IA de trading con autoridad sobrepermitida— es el ejemplo canónico de cómo un despliegue IA interno puede convertirse en una superficie de ataque. El Flashpoint 2026 GTIR observó un aumento del 1.500 % en las discusiones ilícitas vinculadas a la IA en un solo mes. No son escenarios hipotéticos; es material de informe de incidente 2025-2026. Los bancos que hacen funcionar operaciones defensivas clásicas contra adversarios agénticos están, estructuralmente, asimétricamente expuestos, y la respuesta correcta es construir una capacidad defensiva IA-contra-IA en lugar de ralentizar la transición agéntica del lado ofensivo.

¿Es la IA agéntica solo «ChatGPT más servidores MCP»?

No, y es una de las ideas equivocadas más consecuentes del mercado actual. Una interfaz de chat aumentada con servidores MCP es un patrón útil para recuperar y actuar sobre datos en una sesión acotada. La ingeniería agéntica es una capacidad estructural de la institución —el AIBOM, el plano de control de agentes, el pipeline de desarrollo guiado por especificación, el sustrato de auditoría, la fundación criptográfica resistente a lo cuántico, los patrones de orquestación sobre los recorridos de cliente de extremo a extremo—. No son funcionalidades compradas a un proveedor; es una posición de propiedad institucional. Los bancos que tratan la cuestión como una decisión de procurement acaban con despliegues superficiales que fracasan en el examen. Los bancos que la tratan como una cuestión de propiedad de ingeniería y gobernanza acaban con un activo que se compone.

¿Cuál es la cosa más importante que un banco debería hacer en las próximas doce semanas?

Tres cosas, secuenciadas. Primero, producir el AI Bill of Materials —el inventario completo de cada sistema IA, modelo, conjunto de datos, prompt template, índice de retrieval y dependencia IA de terceros en producción o desarrollo, con cada entrada clasificada respecto al anexo III del Reglamento europeo de IA—. La institución que no puede producirlo cuando un regulador lo pide es la institución que recibirá findings. Segundo, construir el plano de control de agentes para todo sistema IA que tome o influya materialmente en decisiones que afecten al cliente —logging de auditoría, detección de anomalías de comportamiento, override humano y kill switches como infraestructura por defecto, no como ítem de hoja de ruta futura—. Tercero, desplazar la cultura de ingeniería interna del vibe coding hacia el desarrollo guiado por especificación en los trabajos que más importan: sistemas de alto riesgo, workflows regulados y pipeline de modernización del legacy. Los dos primeros son trabajo de cumplimiento; el tercero es trabajo competitivo. Las instituciones que hagan las tres estarán materialmente en una posición más fuerte que las que hagan solo una o ninguna. La secuencia completa de doce semanas se expone en la sección plan de acción anterior.

Referencias #

ทบทวนล่าสุด .