Sebastien Rousseau
Entrar em contato ›

Ingeniería agéntica para bancos: um blueprint 2026 para o COMEX e os ingenieros que lo construirán

La IA agéntica tem passado do piloto a a producción. El 70 % de os bancos ya a utiliza; solo uno de cada cinco dispone de um modelo de gobernanza maduro. Los adversarios operan a velocidade de máquina, o estate heredado foi escrito para as hipótesis batch de os anos 1960, e o prazo «alto riesgo» do Reglamento europeo de IA llega em doce semanas.

38 min read

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

La IA agéntica tem passado do piloto a a producción em ou setor bancário mundial. El setenta por ciento de as instituciones a utiliza em mayor ou menor grado; solo uma de cada cinco dispone de um modelo de gobernanza maduro. En paralelo, adversarios autónomos operan a velocidade de máquina, o estate heredado COBOL com o que os novos sistemas devem interoperar foi escrito para as hipótesis batch de os anos 1960, e o prazo «alto riesgo» do Reglamento europeo de IA está a doce semanas. He aqui a posição de ingeniería e gobernanza que um banco deve sostener.

TL;DR. La ingeniería agéntica é ya inevitable em banca: a adoção supera a gobernanza, os adversarios autónomos estão operativos, e a fecha do 2 de agosto de 2026 do Reglamento europeo de IA obliga a producir AIBOM, plano de control de agentes e disciplina de desenvolvimento guiado por especificación em doce semanas. La ventaja competitiva passa por interiorizar a capacidade institucionalmente, no por externalizarla a um proveedor.

Principais Conclusões

  • La adoção supera a a gobernanza: o 70 % de os bancos usa IA agéntica em algún grado; solo o 11 % a tem llevado a producción.
  • Tres vectores de riesgo tem-sen operacionalizado em 2026: o adversario autónomo (Anthropic GTG-1002, Step Finance), a regresión de qualidade do código generado por LLM, e a ancla do estate heredado.
  • El desenvolvimento guiado por especificación —no o vibe coding— é a disciplina compatible com SR 11-7, DORA, o Reglamento europeo de IA e SM&CR.
  • La arquitectura tem quatro capas: sustrato resistente a lo quântico, AIBOM e modelos, flujos agénticos, e plano de control de agentes (audit, kill switches, HITL/HOTL).
  • La pila normativa converge em o 2 de agosto de 2026: obligaciones «alto riesgo» do Reglamento europeo de IA + DORA + SR 11-7 + ISO 42001 + SM&CR/Consumer Duty.
  • El plan prático de 12 semanas —AIBOM, classificação HITL/HOTL, plano de control, revisión de contratos de proveedor, ensayo de avaliação de conformidad, sign-off do consejo— é o mínimo defendible antes do prazo.

El ano em que a ingeniería agéntica se volvió inevitable #

La conversación sobre a IA em os serviços financeiros tem estado, hasta faz muito poco, dominada por dois cosas adyacentes mas distintas: as interfaces conversacionales generativas (útiles mas acotadas) e os patrones de Retrieval-Augmented Generation aplicados a os dados de empresa (útiles também, mas acotados). Lo que cambió entre finales de 2025 e principios de 2026: a tercera categoría —agentes autónomos que planifican, ejecutan e completan workflows multietapa com supervisión humana limitada— pasó de a demostración técnica a a realidade operativa, e cruzó simultáneamente as fronteras de a empresa e de a amenaza.

Andrej Karpathy, que acuñó o término «vibe coding» em febrero de 2025 ⧉, pasó o ano seguinte observando a os ingenieros profesionales superarlo. Su revisión —«ingeniería agéntica»— é agora o término operativo em toda a industria. La sustancia do cambio é simple: em o trabalho de software serio em 2026, os ingenieros no escriben código directamente o 99 % do tempo. Orquestan agentes que lo fazem, enquanto ejercen supervisión. El trabalho ya no consiste em teclear caracteres em um editor; consiste em producir especificaciones que restringen lo que os agentes podem generar, diseñar as puertas de verificação que a saída deve passar e organizar as decisões arquitectónicas que os agentes implementan.

Este cambio parece uma conversación de equipe de ingeniería. En a banca, no lo é. Es uma conversación de consejo de administración, porque a mesma capacidade agéntica que reescribe a forma em que se produce o código interno também reescribe a forma em que operan os adversarios externos, a forma em que os reguladores esperan que se ejerza a supervisión e a forma em que se define o perímetro institucional. Um banco que no tome posição sobre a ingeniería agéntica antes de finales de 2026 no é um banco que tem evitado a questão. Es um banco cuyos proveedores, adversarios e reguladores têm respondido em seu lugar.

El estado de a adoção em a banca #

El cuadro agregado é inequívoco. Según as investigaciones recopiladas em várias encuestas de 2026, o 70 % de os directivos bancários ⧉ declara que seus instituciones ya utilizam IA agéntica em algún grado. Gartner prevé ⧉ que a finales de 2026 em torno do 40 % de todas as empresas de serviços financeiros harán funcionar agentes IA em alguna forma. El gasto IA de os serviços financeiros está em a trayectoria de os 67.000 millones de dólares em 2028 (IDC). McKinsey estima que a IA agéntica pode devolver de 10 a 12 horas por semana a os relationship managers em banca.

El cuadro de a execução é menos alentador. KPMG indica ⧉ que o 99 % de as empresas prevé colocar agentes autónomos em producción, mas solo o 11 % lo fez. EY constata que o 34 % de os directivos tem empezado a utilizar agentes IA e que solo o 14 % os tem implementado plenamente. Forrester observa que o 57 % de as organizações estima carecer de as capacidades internas para sacar partido de a IA agéntica. La brecha entre a intención e a execução no é um artefacto de marketing. Refleja o trabalho de ingeniería, gobernanza e cultura que ainda no tem-se realizado.

La Financial Conduct Authority británica tem expresado públicamente seus inquietudes ⧉ sobre a velocidade de despliegue que supera a madurez de a gobernanza, uma tensión que a Chief Data Officer Jessica Rasu encuadró como um riesgo a curto prazo para o consumidor minorista. McKinsey advirtió por separado que os bancos que no adapten seu modelo de negocio ⧉ corren o riesgo de erosionar hasta 170.000 millones de dólares de beneficios mundiales para 2030. Las dois observaciones são simultáneamente correctas. La questão no é si há que moverse; é cómo moverse com a integridad operativa e de gobernanza que a regulação financeira sempre tem exigido, e que os sistemas agénticos fazem mais afilada.

Tres vectores de riesgo que os bancos devem interiorizar #

Antes de cualquier conversación arquitectónica, a atención do consejo deve centrarse em três riesgos próprios de os sistemas agénticos e que llegan antes de lo que a maioria de bancos havia previsto.

1. El adversario autónomo #

El desenvolvimento mais desestabilizador de 2026 é a operacionalización de a IA agéntica do lado atacante. En agosto de 2025, Anthropic divulgó uma categoría de atividade que llamó vibe hacking ⧉: cibercriminales utilizando IA agéntica para llevar a cabo ataques sofisticados a gran escala, com a IA integrada em a reconnaissance, a recolección de credenciales, a penetración de red e o análisis de os dados robados. En noviembre de 2025 ⧉, Anthropic divulgó a disrupción de uma campaña llevada por um grupo patrocinado por o Estado chino (designado GTG-1002) que havia desviado instancias de Claude Code para llevar a cabo espionaje autónomo contra umas treinta dianas em defensa, energía e tecnologia, gestionando a IA do 80 ao 90 % de as operações tácticas e operando a vários miles de peticiones por segundo, velocidades imposibles para operadores humanos.

En enero de 2026, Step Finance —um gestor de cartera DeFi em Solana— se vio comprometido de uma maneira que transformó uma intrusión em dispositivo em uma pérdida de 27 a 30 millones de dólares, porque os agentes IA de trading de a firma tinham os permisos para ejecutar grandes transferencias sem aprobación humana. El atacante engañó a a própria IA mediante ingeniería social, fingiendo ejecutar um programa de bug bounty autorizado. La lección ⧉ no era que a IA é intrínsecamente peligrosa; era que um agente IA que acepta uma autorização reivindicada sem verificação é uma debilidad de perímetro.

La tendencia agregada é lo que os bancos devem interiorizar. El Flashpoint 2026 Global Threat Intelligence Report identificó um aumento do 1.500 % em as discusiones ilícitas vinculadas a a IA ⧉ entre noviembre e diciembre de 2025, com atacantes desarrollando activamente sistemas autónomos que recopilan dados, gestionan a infraestrutura, ajustan os mensajes e aprenden de os intentos fallidos sem supervisión humana continua. Jamie Dimon (JPMorgan) foi públicamente explícito ⧉: a ventaja inicial de esta tecnologia va a a ofensiva, no a a defensa. La implicación é incómoda: um banco que faz funcionar operações de segurança clásicas contra adversarios agénticos está, estruturalmente, em a posição de um jugador de ajedrez cuyo adversario dispone de um computador.

2. La regresión de qualidade do código #

El segundo vector é interno e mais discreto. El código generado por LLM, em ausencia de disciplina de especificación e verificação rigurosa, se entrega com defectos a uma tasa claramente superior ao código escrito por humanos. Um análisis SonarQube de cinco LLM punteros ⧉ generando código Java encontrou que mais do 70 % de as vulnerabilidades detectadas em a saída de Llama 3.2 90B se clasificaron como BLOCKER, e que em torno de dois tercios de as vulnerabilidades de GPT-4ou e OpenCoder-8B se clasificaron como BLOCKER ou CRITICAL. Pearce e otros (IEEE S&P) encontraram que em torno do 40 % de os programas generados por LLM em contextos sensibles a a segurança contenían vulnerabilidades. Yan e otros (2025) sitúan o rango em o 9,8 ao 42,1 % conforme seus benchmarks. Um catálogo separado de Fu e otros identifica 43 CWE em três ferramentas de geração de código IA.

Para uma industria no regulada, é um impuesto a a produtividade. Para um banco, é um riesgo regulatório e operativo que se compone. Código entregado com uma tasa elevada de vulnerabilidades em um sistema que gestiona pagos, liquidação ou dados de clientes no é uma questão de qualidade de código em sentido abstracto; é a superficie que os adversarios de clase GTG-1002 sondearán em 2027 com as mesmas ferramentas agénticas que lo têm producido. La defensa no é prohibir o código generado por LLM (comercialmente imposible), mas sim rodearlo de a infraestrutura de verificação e especificación que garantiza que os defectos afloran antes do despliegue. Esa é a razão prática por a que o desenvolvimento guiado por especificación está siendo adotado a toda velocidade por as organizações de ingeniería de empresa que no são nativamente empresas de tecnologia.

3. La ancla do legacy #

El tercer vector é o que os bancos ya compreendem melhor, e que a transición agéntica fez simultáneamente mais urgente e mais tratable. Más do 70 % de as empresas do Fortune 500 ainda dependen de mainframes, señala o análisis de Computer Weekly ⧉, frequentemente construidos sobre décadas de COBOL e RPG entrelazados com lógica de negocio a medida. En os serviços financeiros específicamente, as tecnologias heredadas consumen do 70 ao 75 % do gasto IT anual ⧉. Um estudo CIO citado em o análisis sectorial 2026 encontrou que o 63 % de os bancos ainda se apoyan em código escrito antes de 2000, e que mais do 75 % reporta tener solo uma ou dois personas internas com as competencias para mantenerlo.

Lo que cambió em febrero de 2026 foi a llegada de um instrumental agéntico creíble para a modernización do legacy. El anuncio de Anthropic de que Claude Code podía cartografiar as dependencias COBOL, documentar os workflows e identificar os riesgos ⧉ que llevaría meses a os analistas humanos fazer aflorar —combinado com capacidades similares de Microsoft (GitHub Copilot para COBOL, Watsonx Code Assistant) e AWS (Mainframe Modernization com IA agéntica)— comprimió materialmente a curva de coste de a modernización. La reacción de a cotización de IBM (caída do 13 % o día do anuncio) foi uma señal de mercado inelegante mas precisa. La IA representa agora em torno de um tercio de a investimento de modernización de empresa, e mais do 75 % de as empresas utiliza a IA em seu estrategia de modernización. La ancla do legacy é, por primeira vez, um problema de ingeniería tratable mais que generacional.

Por que o vibe coding no pode ser o valor por defecto em a banca #

Vale a pena ser preciso sobre por que o vibe coding —prompt corto, observar a saída, iterar— fracasa como workflow por defecto em um estate regulado. El modo de fallo no é o mais evidente (o LLM alucina de vez em quando). El modo de fallo é estructural e aparece simultáneamente em quatro lugares.

El primeiro é a ausencia de convenciones compartidas. Varios ingenieros trabalhando por prompts producirán cinco maneras diferentes de fazer a mesma cosa em a mesma base de código em um solo trimestre. En um contexto no regulado, é deuda técnica. En um contexto regulado, é a superficie que se rompe ante um examen.

El segundo é a decadencia do contexto. Los agentes IA são sem estado. En um gran projeto, as conversaciones exceden as ventanas de contexto, e o razonamiento atrás de as decisões arquitectónicas anteriores se evapora. El mesmo agente, dois semanas mais tarde, tomará a decisão inversa em uma nova conversación porque nada persiste a justificación de a primeira. Para sistemas que exigen uma pista de auditoría para os reguladores, é estruturalmente incompatible.

El tercero é a acumulación invisible de defectos. Los resultados de Pearce, Yan e SonarQube citados antes no são casos marginales. Es a tasa base a a que os LLM generan código vulnerable em ausencia de disciplina de especificación e pruebas rigurosas. Um banco que faz funcionar workflows de vibe coding em producción acumula esses defectos ao mesmo ritmo, sem a visibilidade de superficie que permitiría saber que tem-se entregado.

El cuarto é o problema de rastreabilidade regulatória. El artigo 12 do Reglamento europeo de IA exige o registro automático de as entradas e saídas para os sistemas IA de alto riesgo. SR 11-7 exige roles documentados de propietario e validador de modelo, uma gestión do cambio para as actualizaciones de modelo e um reporting ao consejo sobre ou riesgo modelo IA. DORA exige uma gestión de os riesgos ICT exhaustiva com pruebas documentadas. Ninguna de estas obligaciones pode satisfacerse com um workflow cuyo artefacto principal é um historial de chat que nadie persiste.

La conclusão no é que os LLM sean impropios para a banca. La conclusão é que o workflow que os rodea deve producir especificaciones, pistas de auditoría e puertas de verificação como entregables de primeira clase em vez de como pensamento ulterior. Eso é, operativamente, o desenvolvimento guiado por especificación.

Desarrollo guiado por especificación em um estate regulado #

El desenvolvimento guiado por especificación (SDD) invierte o orden do trabalho. En lugar de zambullirse em a implementación e iterar com um agente, o equipe produce primeiro uma especificación —decisões arquitectónicas, requisitos, contratos de interfaz, criterios de éxito, restricciones de segurança— e o agente genera código que satisface a especificación. La verificação está estructurada: a especificación define lo que a saída deve fazer, e um proceso separado (geração de tests, revisión de código, verificação formal quando é aplicable) verifica que se fez.

El instrumental prático se consolidó a finales de 2025 e principios de 2026. Spec Kit de GitHub ⧉ (lanzado a finales de 2025) formaliza a intención antes de a geração de código. AWS incorpora workflows spec-first directamente em seu IDE Kiro. JetBrains e Cursor têm introducido modos de planificación que estructuran a interacción com a IA. Frameworks como BMAD (Breakthrough Method for Agile AI-Driven Development) van mais longe com equipes de agentes IA especializados que reflejan os roles de analista, arquitecto, desenvolvedor e QA ao longo do SDLC. Constitutional SDD, formalizado em um artigo arXiv em febrero de 2026, incorpora restricciones de segurança explícitas com mapeos de vulnerabilidades CWE em a própria especificación.

Para um banco, a variante que importa é lo que o análisis de Augment Code llama desenvolvimento anclado em a especificación: as especificaciones vienen primeiro, a IA genera código restringido por elas, e capas adicionales de gobernanza (restricciones constitucionales, pontos de supervisión, puertas de aprobación humana) se sitúan entre a geração e o merge. Es a única variante que produce a pista de auditoría que o artigo 12 do Reglamento europeo de IA espera, o rol documentado de validador que SR 11-7 exige, e a disciplina de gestión do cambio que DORA pide.

La investimento requerida é real, mas também é tratable. Las instituciones que lo fazem bien têm desplazado o día a día de os ingenieros de teclear caracteres a producir dois artefactos: uma especificación que o agente satisfará e um arnés de verificação que a saída deve passar. La demanda cognitiva sobre ou ingeniero é mais alta em ciertos aspectos (a claridad de intención cuenta mais que nunca) e mais baja em otros (o trabalho mecánico de escribir boilerplate tem desaparecido). Las instituciones que ainda no fizeram esse cambio operan ainda em um modo em o que o LLM é um mecanógrafo mais rápido. Esa posição no é sostenible em um estate regulado mais allá de os próximos doce meses.

La pila regulatória que se aplica agora #

El perímetro regulatório 2026 em torno de a IA em ou setor bancário ya no é uma checklist; é uma pila de obligaciones que se solapan e que devem razonarse juntas. La fecha mais consecuente é o 2 de agosto de 2026, quando as obligaciones «alto riesgo» do Reglamento europeo de IA se vuelven plenamente aplicables ⧉. El anexo III clasifica explícitamente o scoring crediticio, a avaliação de solvencia, a avaliação de riesgos em seguros de vida e salud, assim como a avaliação ou classificação de a situación financeira de os individuos como de alto riesgo. Las obligaciones que se derivan de esta classificação incluem avaliações de conformidad, sistemas de gestión de a qualidade, marcos de gestión do riesgo, documentación técnica, registro em a banco de dados europea, uma gobernanza de os dados robusta, a supervisión humana e protecciones de ciberseguridad. Las penalizaciones por incumplimiento de as obligaciones de alto riesgo alcançam 35 millones de euros ou o 7 % de a facturación mundial anual, o mayor de os dois.

Junto ao Reglamento europeo de IA:

Tres modos de desenvolvimento 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 do ingeniero Iterador de prompts Autor de especificación Orquestador e verificador
Disciplina de saída Generación directa de código Código restringido por a 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 verificação
Tasa de defectos (solo LLM) 10 ao 40 % de vulnerabilidades (base de a literatura) Sensiblemente reducida por as restricciones de spec Más baja com puertas de verificação
Trazabilidad regulatória Insuficiente para a IA de alto riesgo Compatible com o artigo 12 do Reglamento europeo de IA Diseñado para Artículo 12 + SR 11-7 + DORA
Adaptado a a banca? No, para producción Sí, com gobernanza Sí, com gobernanza madura
Techo de capacidade Acotado por o prompting único Acotado por a qualidade de a spec Acotado por a qualidade de a orquestación

Fuente: síntesis de os comentarios de Karpathy (2026), análisis SDD de Augment Code ⧉, análisis CGI sobre ou desenvolvimento guiado por especificación ⧉, e a literatura acadêmica sobre as tasas de vulnerabilidad de a geração de código por LLM (Pearce e otros, Yan e otros, Fu e otros, 2023-2025).

Construir o banco agéntico: uma vista de arquitectura #

La posição estratégica atrás de estes workflows é lo que o COMEX deve apropiarse explícitamente. La ingeniería agéntica em ou setor bancário no é uma iniciativa de produtividade de desenvolvedor. Es uma capacidade institucional que afecta a os recorridos de cliente de extremo a extremo, ao conjunto do ciclo de vida de a transação, e ao sustrato criptográfico e de auditoría que sustenta a ambos. Cuatro capas de esta capacidade merecen a atención ejecutiva directa, de acima abaixo:

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 e HOTL por clase de agente.

Capa 3 — Workflows agénticos Recorridos de cliente, operações internas, pipeline de desenvolvimento. Pilotaje por especificación por defecto para os flujos de alto riesgo.

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

Capa 1 — Fundación resistente a lo quântico ML-KEM, ML-DSA, PKI híbrida, agilidade criptográfica. El sustrato do que dependen as reivindicaciones de integridad de todas as capas superiores.

Capa 1 — La fundación resistente a lo quântico. Cada capa por em cima asume a integridad do sustrato criptográfico. Con a folha de ruta do G7, o plan NCSC em três fases e BIS Project Leap públicamente documentados, ya no é uma preocupação de nicho. Los sistemas agénticos cuyas pistas de auditoría estão firmadas sob ECDSA clásico, ou cuyo establecimiento de claves depende de RSA ou ECDH, verán expirar seus reivindicaciones de integridad com a criptografia. Las instituciones que lo fazem bien suben o trabalho pós-quântico aguas acima e tratan ML-KEM, ML-DSA e a PKI híbrida como o sustrato sobre ou que descansan as garantías de auditoría e integridad de todas as capas superiores.

Capa 2 — La capa de dados e modelos. Es ali onde vive o AI Bill of Materials (AIBOM). Análogo ao Cryptographic Bill of Materials utilizado em a planificación de a migración pós-quântica, o AIBOM é o inventario de cada modelo, conjunto de dados, prompt template, índice de retrieval, fine-tune e dependencia IA de terceros que a institución opera. Es o artefacto que o artigo 49 do Reglamento europeo de IA exige de feito, o inventario que os exámenes SR 11-7 reclaman agora, e a fundación de toda postura de gobernanza creíble. A maioria de instituciones no lo têm. Lo necesitarán para agosto.

Capa 3 — Los workflows agénticos. Es a capa que a maioria de instituciones está construyendo atualmente, frequentemente sem atención suficiente a as capas 1, 2 e 4. Los workflows em sim van do interno (geração de código, redacción de documentos regulatórios, triaje de serviço ao cliente) ao cliente (copilotos para relationship managers, onboarding, orquestación KYC, supervisión de transações, otimização FX) até ou plenamente autónomo (operações de tesorería, ciertas funciones de trading e de gestión do riesgo quando a tolerancia do regulador lo permite). La disciplina estratégica em esta capa é tratarla como ingeniería de sistemas, no como desenvolvimento de aplicações —patrones de orquestación, reglas de escalado, puertas human-in-the-loop e emissão de auditoría são preocupações de diseño de primeira clase.

Capa 4 — El plano de control de agentes. Es lo que Deloitte tem qualificado de «sala de control de os agentes» ⧉: a auditoría em tempo real, o logging de as ações, a detección de anomalías de comportamiento, os kill switches e a infraestrutura de override humano que rodean a cada agente em producción. La pérdida de Step Finance no foi, técnicamente, um fallo de IA. Fue um fallo do plano de control: os agentes tinham permisos que no deveriam haver tenido, e a anomalía de comportamiento que deveria haver desencadenado uma parada no se desencadeou. Las instituciones que construyen o plano de control primeiro —antes de escalar mais o despliegue de agentes— são as que no verán incidentes de clase Step Finance em 2027.

La comparación pertinente para o COMEX no é «fazemos mais IA que nossos competidores?». Es si a institución posee as quatro capas, ou si uma ou mais capas estão silenciosamente delegadas a um proveedor sem capacidade contractual para satisfacer as exigencias de documentación do artigo 13 do Reglamento europeo de IA. Esta última é uma posição que parece correcta hasta que um regulador abre a questão.

Supervisión humana em a prática: HITL vs HOTL #

La distinción única dentro de a capa 4 sobre a que os reguladores concentran mais seu atención em 2026 é a que existe entre dois modelos de supervisión. Ambos são formas de supervisión humana; difieren em latencia, escala e em a hipótesis que o regulador acepta sobre ou comportamiento do agente.

Human-in-the-Loop (HITL) é o modelo em o que um agente no pode ejecutar uma ação consecuente sem aprobación humana explícita. El agente prepara a decisão, a presenta e espera. Um agente de remediación KYC que señala uma cuenta para fechamento mas no pode cerrarla sem a firma de um compliance officer é HITL. La compensación é operativa: HITL é mais seguro e produce uma pista de auditoría inequívoca para o artigo 14, mas no escala para os workflows de alto volumen e baja latencia.

Human-on-the-Loop (HOTL) é o modelo em o que um agente se ejecuta de maneira autónoma em parámetros acotados, com humanos supervisando a telemetría em tempo real e conservando a autoridade de detener ao agente em cualquier momento. Um agente de filtrado de fraude em tempo real que autobloquea as transações que coinciden com ciertos patrones de riesgo, com um equipe de operações humano que supervisa o volumen de alertas e interviene em as anomalías, é HOTL. La compensación é inversa: HOTL escala, mas depende de parámetros de agente correctamente ajustados e de uma detección de anomalías de comportamiento que detecte a deriva antes de que os daños se acumulen.

El artigo 14 do Reglamento europeo de IA no prescribe HITL ou HOTL; exige que a supervisión humana sea significativa. La implicación prática é que cada agente de alto riesgo que o banco opere deve tener uma posição explícita e documentada sobre ou modelo que se aplica, por que, e qual é o camino de escalado quando o agente encontra situaciones fora de seus parámetros acotados. A maioria de bancos que hacían funcionar pilotos em 2025 no tinham esta documentación. A maioria de bancos que harán funcionar agentes em producción em agosto de 2026 a necesitarán.

La regla de decisão no é compleja. Para as ações consecuentes, de sob volumen e irreversibles —denegación de crédito a uma persona física, fechamento de cuenta, autorização de transferencia de alto importe, presentación de declaración regulatória— HITL é o valor por defecto defendible. Para as ações de alto volumen, reversibles e com parámetros acotados —alertas de supervisión de transações, classificação de documentos, triaje rutinario de serviço ao cliente— HOTL é apropiado, a condición de que a detección de anomalías de comportamiento e a infraestrutura de kill switch sean maduras. Los bancos que tratan cada workflow como HITL no capturarán a palanca operativa de os sistemas agénticos. Los bancos que tratan cada workflow como HOTL tendrán antes ou depois seu momento Step Finance.

Comprar ou construir: o problema de os agentes de terceros #

La realidade 2026 que alcançou a a maioria de os bancos é que no construirán, principalmente, a capacidade agéntica. La comprarán. El paisaje de proveedores —a plataforma banking agéntica de Oracle lanzada em febrero de 2026, Watsonx de IBM, a suite Copilot de Microsoft, AWS Bedrock Agents, Salesforce Agentforce, NowAssist de ServiceNow, e a ola de proveedores de agentes especialistas fintech— se mueve mais rápido que a ingeniería interna de os bancos. La consecuencia estratégica é que a maioria de agentes que operarán em um banco em 2027 haverão sido escritos por otro, e a questão de gobernanza ya no é «podemos confiar em nossos agentes?» mas sim «podemos confiar em os agentes que temos comprado, e podemos demostrarlo a um regulador?».

Es o desafío mais ruidoso e menos reconocido sob DORA. Los artigos 28 a 30 do reglamento fazem de a gestión do riesgo ICT de terceros um campo supervisor activo, com exigencias explícitas que cubren as cláusulas contractuales, o seguimiento continuo, a avaliação do riesgo de concentración e as estrategias de saída. Las Autoridades Europeas de Supervisión mantêm um registro de os proveedores ICT terceros críticos, com poderes de supervisión directa sobre os designados como tales. La nova realidade operativa é que os proveedores IA de 2026 —proveedores de modelos punteros, proveedores de plataformas de agentes, SaaS IA-enabled— são, cada vez mais, os terceros ICT para os que DORA foi escrito.

Para um banco em posição de compra, se aplican três disciplinas práticas:

Exija o AIBOM do proveedor. Todo producto agéntico comprado para workflows de alto riesgo deve acompañarse de uma bill of materials documentada que cubra os modelos subyacentes, a procedencia e limitaciones de os dados de entrenamiento, os fine-tunes aplicados, os índices de retrieval accedidos, as versiones de prompt templates e a cadena de dependencias rumo a os componentes agente aguas abaixo. Es o artefacto que o banco necesitará para satisfacer as exigencias de documentación do artigo 13 do Reglamento europeo de IA. El banco no pode producirlo retrospectivamente de um proveedor que no tem-seya comprometido contractualmente.

Pruebe a caja negra, no o folleto. Las avaliações de procurement de proveedores tem-sen centrado históricamente em a comparación de funcionalidades e as entrevistas com clientes de referencia. Para os sistemas agénticos, no basta. La institución deve realizar pruebas de comportamiento do agente em condiciones análogas a seu despliegue de producción objetivo, incluído o probing adversarial para a inyección de prompt, a resistencia a a ingeniería social (o vector Step Finance), a deriva sob cambio de distribución de dados, e os modos de latencia e fallo de os caminos de kill switch e override. A maioria de contratos de proveedor actuales no autorizan esta profundidad de testing sem negociación específica; essa negociación deve tener lugar antes de a firma do contrato, no depois.

Renegocie os contratos em os términos do artigo 13. A maioria de acuerdos de proveedor IA existentes no contienen ninguno de os derechos de documentación, auditoría, notificação de cambio de modelo, reporting de incidente ou divulgación de subcontratistas que o Reglamento europeo de IA e DORA exigen conjuntamente. El análisis Regulativ de firmas británicas ⧉ foi explícito em este ponto: a revisión jurídica de os acuerdos de proveedor lleva semanas, e a maioria de instituciones no podem satisfacer o artigo 13 para um modelo cuyo proveedor nunca tem-se visto contractualmente obligado a revelar seu funcionamiento interno. La obligación regulatória recae em o desplegador, no em o proveedor. Los equipes de procurement devem saberlo antes do próximo ciclo de renovación, no depois de uma investigación regulatória.

El resumen para o consejo é que a relação com o proveedor tem passado do procurement a a transferencia de riesgo, e o riesgo no se transfiere, em realidade. El banco segue siendo o desplegador. El banco segue siendo responsable. El banco precisa os instrumentos contractuales e a disciplina de testing que fazem seu responsabilidade tratable em vez de meramente formal.

Lo que esto significa por tipo de banco #

La resposta correcta varía. El patrón seguinte é uma segmentación gruesa, no uma prescripción.

Bancos universales de primer nivel #

Las instituciones com 1 billón de dólares de balance e uma presencia mundial são simultáneamente as mais expuestas (perímetro regulatório mais amplio, estate heredado mais grande, diana de mayor valor para os adversarios autónomos) e as melhor dotadas. La prioridad estratégica é construir o plano de control primeiro —capa 4 de a arquitectura anterior— e introduzir a disciplina do desenvolvimento guiado por especificación em a función de ingeniería interna antes de escalar mais o despliegue de agentes. La consecuencia competitiva de hacerlo bien é significativa; a consecuencia de hacerlo mal é existencial, dada a exposición a as penalizaciones do Reglamento europeo de IA e a exposición operativa a os patrones de amenaza de clase GTG-1002.

Bancos de tamaño intermedio e regionales #

La questão competitiva para os bancos de segundo nivel é mais afilada que para os de primer nivel. Afrontan o mesmo perímetro regulatório sem o mesmo presupuesto de gobernanza, a mesma superficie de amenaza sem os mesmos recursos defensivos, e uma base de clientes que se compara cada vez mais com fintechs IA-nativas. La resposta prática é estandarizar fuertemente sobre um pequeño conjunto de proveedores verificados (com contratos que satisfagan as exigencias de documentación do artigo 13), invertir em a disciplina do desenvolvimento guiado por especificación mais que em uma ingeniería de plataforma a medida, e utilizar o instrumental agéntico para comprimir o calendario de modernización COBOL que foi uma ancla estratégica durante dois décadas. Las instituciones que se mueven pronto aqui cerrarán, materialmente, a brecha tecnológica com os bancos de primer nivel por primeira vez em uma geração.

Fintechs, PSP e instituciones próximas ao cripto #

El segmento fintech e instituciones de pago tem o problema inverso: a agilidade é alta, a gobernanza é frequentemente mais débil que em os bancos pares, e a exposición a as penalizaciones do Reglamento europeo de IA é, para uma fintech de tamaño meio, potencialmente existencial. La disciplina estratégica é tratar a gobernanza IA como uma puerta de readiness de producto em vez de uma capa de cumplimiento, construyendo o AIBOM, o sustrato de auditoría e os workflows guiados por especificación em a cultura de ingeniería desde ou principio em vez de retrofittearlos sob presión regulatória. Para as instituciones cuya infraestrutura de pago intersecta com o prazo SWIFT CBPR+ de direções estructuradas de noviembre de 2026, a investimento em ingeniería agéntica é também o mecanismo natural para industrializar o trabalho de remediación de direções estructuradas —as reglas de validação, a aplicação de a qualidade de os dados e a integração em o pipeline CI são precisamente os patrones que os workflows guiados por especificación fazem tratables—.

Funciones de ingeniería interna #

Para os ingenieros e investigadores que leen este artigo, a disciplina de trabalho que importa é a cotidiana. Desplace o centro de gravedad do trabalho de teclear caracteres a producir especificaciones e arneses de verificação. Trate as trazas de agente, os planes intermedios e as puertas de aprobación como artefactos de primeira clase em seu gestión de versiones. Invierta em o instrumental —Spec Kit, Kiro, o modo plan de Cursor, Claude Code com skill files a nivel de projeto— que faz de a especificación o artefacto duradero e do código generado lo desechable. El deslizamiento ergonómico é real. El beneficio profesional é que a disciplina adotada em a frontera é também a disciplina que sobrevive ao examen regulatório.

El plan de ação de 12 semanas rumo a agosto de 2026 #

Para o sponsor ejecutivo que pilota um programa de ingeniería agéntica entre agora e a fecha de aplicação do Reglamento europeo de IA, o trabalho se comprime em uma secuencia de doce semanas. El plan seguinte no é exhaustivo; é o mínimo que um consejo deveria esperar de um programa creíble antes do 2 de agosto de 2026.

Semanas 1-2 — Producir o AIBOM. Colocar em marcha o inventario centralizado de cada sistema IA, modelo, conjunto de dados, prompt template, índice de retrieval, fine-tune e dependencia IA de terceros em producción ou desenvolvimento. Cartografiar cada entrada com a classificação do anexo III do Reglamento europeo de IA. El entregable é uma fuente única de verdad que o CRO, o CCO, o CISO e o CTO podem consultar.

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

Semanas 5-6 — Construir ou endurecer o plano de control de agentes. Logging de ações em tempo real, detección de anomalías de comportamiento, kill switches e caminos de override operativos sobre cada agente em producción. Cuando o plano de control ainda no exista para um sistema, esse sistema passa a estado de despliegue restringido hasta que exista.

Semanas 7-8 — Revisión de os contratos de proveedor. Lo jurídico e lo procurement recorren cada contrato activo de proveedor IA em busca de os derechos de documentación do artigo 13, notificação de cambio de modelo, reporting de incidente, derechos de auditoría e divulgación de subcontratistas. La saída é uma lista por tiers: conforme, remediación requerida, reemplazo requerido. Las decisões de reemplazo devem arrancar agora para tener uma oportunidade de culminar este ano.

Semanas 9-10 — Ensayo general de a avaliação de conformidad. Para cada sistema de alto riesgo sob o anexo III, completar o workflow de avaliação de conformidad como si um organismo notificado llegara a semana seguinte. Esto hará aflorar brechas que parecen menores sobre ou papel e que são operacionalmente severas em o examen. Corrijao que pueda corregirse; documente lo residual.

Semanas 11-12 — Validación previa ao cambio e sign-off do consejo. Revisión final do AIBOM, de as clasificaciones HITL/HOTL, de as pruebas do plano de control, do estado de remediación de proveedores e de as saídas de avaliação de conformidad. Responsabilidad de senior manager nominada confirmada. Posición consignada em o acta do consejo. Notificar ao regulador quando o marco espere prenotificación.

Las instituciones que completen esta secuencia de doce semanas no haverão resuelto a ingeniería agéntica. Habrán establecido a base que um programa creíble exige. Las instituciones que no têm empezado a a fecha de publicación de este artigo no são, como formuló o análisis Regulativ do lado SWIFT, somente negligentes. Son a maioria. La pergunta que cada CCO, CRO e CTO deve hacerse em os próximos quince días é si a firma actúa em mayo ou entra em pánico em julio.

Conclusión #

La observación dura que tem-se cristalizado a escala industrial em os últimos seis meses é que as viejas maneras de operar a escala de empresa estão superadas no por uma nova tecnologia mas sim por um novo patrón de trabalho. Las ferramentas agénticas têm revelado —às vezes em producción, às vezes em informes de incidente— fallos e brechas em os estates heredados que se acumulaban silenciosamente desde hacía anos. Las mesmas ferramentas têm dado a os actores maliciosos recursos que antes exigían apoyo estatal. Las mesmas ferramentas, usadas internamente com disciplina, constituyen o camino mais creíble para que as instituciones cierren o retraso do legacy, satisfagan o prazo regulatório de agosto de 2026 e alcancen o tempo operativo que as expectativas de os clientes e as realidades competitivas exigen agora.

Las instituciones que se apropien de esta posição internamente —que traten a ingeniería agéntica como uma capacidade estructural do banco em vez de uma capa de produtividade comprada a um proveedor— pasarán os dois próximos anos componiendo seu ventaja. Las instituciones que no lo hagan pasarán os dois próximos anos descubriendo, em informes de incidente e findings de regulador, lo que deveriam haver construido. La elección entre estes dois resultados é uma decisão de consejo de 2026, no uma decisão tecnológica de 2028.

Para o contexto previo em este sitio, o artigo de abril de 2026 sobre os umbrales quânticos cubrió a trayectoria material que sustenta a capa 1 de a arquitectura anterior, o artigo de mayo de 2026 sobre a migración pós-quântica em finanzas corporativas cubrió o sustrato criptográfico em profundidad, o análisis de mayo de 2026 sobre ou prazo pacs.008 de direções estructuradas cubrió a disciplina regulatória e de ingeniería que a validação guiada por especificación faz tratable, e os trabalhos Rust de código aberto sobre KyberLib, pain001 e pacs008 se inscriben em o esfuerzo mais amplio por colocar primitivas de qualidade de producción —resistentes a lo quântico, conformes com pagos, listas para auditoría— em manos de os equipes de ingeniería que construirán ou setor bancário agéntica. La conexão entre estas piezas no é fortuita. Es a forma do trabalho que os dois próximos anos exigen.

Preguntas frecuentes #

Cuál é a diferença entre IA generativa, IA agéntica e ingeniería agéntica?

La IA generativa produce contenido em resposta a um prompt; é reactiva. La IA agéntica persigue objetivos definidos de maneira autónoma, accediendo a os dados, utilizando ferramentas e tomando ações sobre workflows multietapa sem precisar um prompt humano em cada paso. La ingeniería agéntica —o término adotado por Karpathy em 2026 ⧉— é a disciplina de trabalho consistente em orquestar agentes contra especificaciones detalladas com supervisión humana. Para a banca, a distinción importa porque o perímetro regulatório, o modelo de amenaza e a disciplina de ingeniería são diferentes para cada categoría. Una interfaz de chat e um agente de trading plenamente autónomo no estão em a mesma clase regulatória, e tratarlos como si lo estuvieran crea exposición em os dois extremos.

Por que é tão consecuente o prazo de agosto de 2026 do Reglamento europeo de IA para os bancos?

El anexo III do Reglamento europeo de IA clasifica explícitamente vários casos de uso IA bancários centrales como de alto riesgo: a avaliação de solvencia e o scoring crediticio de personas físicas, a avaliação de riesgos e a tarificación em seguros de vida e salud, e a avaliação ou classificação de a situación financeira de os individuos. A partir do 2 de agosto de 2026, os desplegadores de estes sistemas devem demostrar o cumplimiento com sistemas de gestión de a qualidade, marcos de gestión do riesgo, documentación técnica, avaliações de conformidad, registros em a banco de dados europea, uma gobernanza de os dados robusta, a supervisión humana e protecciones de ciberseguridad. El artigo 12 exige o registro automático de as entradas e saídas. El artigo 14 exige uma supervisión humana significativa (HITL ou HOTL, conforme ou sistema). Las penalizaciones alcançam 35 millones de euros ou o 7 % de a facturación mundial anual. El trabalho para satisfacer estas obligaciones é trabalho de ingeniería —no trabalho documental— e é a razão prática por a que a disciplina guiada por especificación se aceleró em o primer trimestre de 2026.

Cuál é a diferença prática entre HITL e HOTL, e cuándo se aplica cada modelo?

HITL (Human-in-the-Loop) significa que o agente no pode ejecutar ações consecuentes sem aprobación humana explícita. HOTL (Human-on-the-Loop) significa que o agente se ejecuta de maneira autónoma em parámetros acotados, com humanos supervisando a telemetría e conservando a autoridade de detención em cualquier momento. El artigo 14 do Reglamento europeo de IA exige que a supervisión sea significativa mas no prescribe que modelo. La regla de decisão consiste em aplicar HITL quando a ação é consecuente, de sob volumen e irreversible (denegación de crédito, fechamento de cuenta, autorização de transferencia de alto importe, presentación de declaración regulatória), e HOTL quando a ação é de alto volumen, reversible e com parámetros acotados (alertas de supervisión de transações, classificação de documentos, triaje rutinario de serviço ao cliente). Ambos exigen que a infraestrutura de kill switch e override sea operativa e esté probada; a diferença é si o humano está aguas acima de a execução (HITL) ou ao lado (HOTL).

A maioria de nossos agentes vendrán de proveedores. Cómo satisfacer DORA e o Reglamento europeo de IA para sistemas que no temos construido?

La obligación regulatória recae em o desplegador, no em o proveedor. La resposta prática é triple. Primero, exija ao proveedor um AIBOM documentado antes de a firma: linaje de os modelos, procedencia de os dados de entrenamiento, fine-tunes, prompt templates, índices de retrieval, cadena de dependencias. Segundo, realice um testing de comportamiento do agente em condiciones análogas a a producción, incluído o probing adversarial para a inyección de prompt e a resistencia a a ingeniería social. Tercero, renegocie os contratos de proveedor para incluir os derechos de documentación do artigo 13, notificação de cambio de modelo, reporting de incidente, derechos de auditoría e divulgación de subcontratistas; a maioria de contratos existentes no inclui nada de eso. Los artigos 28 a 30 de DORA cubren a gestión do riesgo ICT de terceros e constituyen o ancla regulatória pertinente do lado europeo; a guía FFIEC é o equivalente do lado estadounidense. El trabalho é significativo; no pode aplazarse.

Hasta que ponto devem preocuparse realmente os bancos por os adversarios agénticos?

La resposta honesta é que a amenaza é real e operacionalmente distinta de as amenazas cibernéticas anteriores. La divulgación por Anthropic de GTG-1002 em noviembre de 2025 é o exemplo canónico: IA agéntica gestionando do 80 ao 90 % de as operações tácticas em uma campaña de espionaje patrocinada por um Estado, contra umas treinta dianas em defensa, energía e tecnologia, operando a vários miles de peticiones por segundo. El incidente Step Finance em enero de 2026 —pérdida de 27 a 30 millones de dólares devido a agentes IA de trading com autoridade sobrepermitida— é o exemplo canónico de cómo um despliegue IA interno pode convertirse em uma superficie de ataque. El Flashpoint 2026 GTIR observó um aumento do 1.500 % em as discusiones ilícitas vinculadas a a IA em um solo mes. No são escenarios hipotéticos; é material de informe de incidente 2025-2026. Los bancos que fazem funcionar operações defensivas clásicas contra adversarios agénticos estão, estruturalmente, asimétricamente expuestos, e a resposta correcta é construir uma capacidade defensiva IA-contra-IA em vez de ralentizar a transición agéntica do lado ofensivo.

Es a IA agéntica solo «ChatGPT mais servidores MCP»?

No, e é uma de as ideias equivocadas mais consecuentes do mercado actual. Una interfaz de chat aumentada com servidores MCP é um patrón útil para recuperar e actuar sobre dados em uma sesión acotada. La ingeniería agéntica é uma capacidade estructural de a institución —o AIBOM, o plano de control de agentes, o pipeline de desenvolvimento guiado por especificación, o sustrato de auditoría, a fundación criptográfica resistente a lo quântico, os patrones de orquestación sobre os recorridos de cliente de extremo a extremo—. No são funcionalidades compradas a um proveedor; é uma posição de propriedade institucional. Los bancos que tratan a questão como uma decisão de procurement acaban com despliegues superficiales que fracasan em o examen. Los bancos que a tratan como uma questão de propriedade de ingeniería e gobernanza acaban com um activo que se compone.

Cuál é a cosa mais importante que um banco deveria fazer em as próximas doce semanas?

Tres cosas, secuenciadas. Primero, producir o AI Bill of Materials —o inventario completo de cada sistema IA, modelo, conjunto de dados, prompt template, índice de retrieval e dependencia IA de terceros em producción ou desenvolvimento, com cada entrada clasificada respecto ao anexo III do Reglamento europeo de IA—. La institución que no pode producirlo quando um regulador lo pide é a institución que recibirá findings. Segundo, construir o plano de control de agentes para tudo sistema IA que tome ou influya materialmente em decisões que afecten ao cliente —logging de auditoría, detección de anomalías de comportamiento, override humano e kill switches como infraestrutura por defecto, no como ítem de folha de ruta futura—. Tercero, desplazar a cultura de ingeniería interna do vibe coding rumo a o desenvolvimento guiado por especificación em os trabalhos que mais importan: sistemas de alto riesgo, workflows regulados e pipeline de modernización do legacy. Los dois primeiros são trabalho de cumplimiento; o tercero é trabalho competitivo. Las instituciones que hagan as três estarán materialmente em uma posição mais fuerte que as que hagan solo uma ou ninguna. La secuencia completa de doce semanas se expone em a sección plan de ação anterior.

Referencias #

Última revisão .