Arquiteto de banco: em teste da METR, IA aumentou em 19% o tempo das tarefas de desenvolvedores experientes

O responsável pela função de arquitetura em um banco russo publicou no Habr uma análise de como a IA generativa e os agentes baseados em LLM estão mudando a arquitetura corporativa. O principal argumento do autor se apoia em um teste randomizado da METR de 2025 (a METR é uma organização independente que avalia as capacidades de IA): desenvolvedores experientes que usaram IA em bases de código maduras gastaram 19% mais tempo nas tarefas do que sem ela. Mesmo assim, eles estavam convictos de que tinham ficado 20% mais rápidos, de modo que a distância entre a percepção e a realidade chegou a 39 pontos percentuais.

Para o autor, isso mostra que escrever código nunca foi o gargalo do ambiente corporativo. A dificuldade real é encaixar a nova lógica em um cenário com sistemas legados, regulação e restrições de segurança da informação.

A ilusão de aceleração e o preço do código barato

A rede neural elimina o medo da página em branco: o desenvolvedor recebe um trecho de código na hora. Mas aí começa a integração. O código gerado parece sintaticamente impecável, porém muitas vezes ignora dependências implícitas dos sistemas legados e falha em tempo de execução. O engenheiro gasta horas depurando algo que só parece funcionar.

Os dados da GitClear confirmam isso de forma indireta: o volume de código copiado superou o de código refatorado, e o churn rate (parcela de código recente reescrita logo após o commit) subiu de 3,3%, antes da adoção em massa de IA, para 7,1%. Os relatórios DORA mostram o mesmo quadro: o throughput aumenta, e a estabilidade das entregas cai.

A conclusão do autor é pragmática: não dá para depender de code review feito por pessoas. É preciso ter sensores determinísticos no pipeline, como fitness functions, linters e contratos, que impeçam código alucinado ou estruturalmente torto de chegar à branch master. Os documentos de arquitetura dão lugar ao guardrails-as-code.

Regulação russa e o modelo como ator

As notícias ocidentais sobre adiamento de prazos quase não significam nada para um banco russo. O EU AI Act Omnibus empurrou os requisitos para sistemas de alto risco para 2 de dezembro de 2027, e o Fed e o FDIC dos EUA, por meio do documento SR 26-2, tiraram a IA generativa e agêntica do gerenciamento padrão de risco de modelos. Na Rússia, a arquitetura é definida pela lei federal 187-FZ sobre infraestrutura crítica de informação (KII), pelo Regulamento 850-P sobre confiabilidade operacional e pelo prazo de migração dos objetos significativos da KII para uma stack nacional: 1º de janeiro de 2028.

Toda decisão passa pelo filtro do registro de software russo, da categoria de significância dos objetos da KII e da localização de dados pessoais conforme a lei 152-FZ.

O item 2.5 do documento 3-MR do Banco da Rússia, publicado em junho de 2026, recomenda a confirmação obrigatória da operação por um funcionário, que pode alterá-la. Isso vale para IA em processos críticos, como pagamentos em situações de alto risco de segurança da informação. Por isso, o human-in-the-loop se tornou uma camada obrigatória do design. Acima do LLM, o banco coloca uma abstração do tipo roteador, para que a troca de modelo motivada pela lei de IA (243-FZ) não paralise a operação.

A revisão de design começa com uma pergunta: o modelo é um componente ou um ator? Se ele está preso a um aplicativo e apenas exibe uma resposta na tela, basta o OWASP GenAI LLM Top 10. Se tem memória, acesso a API e chamada de funções, aplica-se o OWASP Agentic Top 10, no qual o risco de agência excessiva (Excessive Agency) subiu para o terceiro lugar. Para esses agentes, o banco constrói sandboxes de execução de código, limita rigidamente as chamadas de ferramentas e bloqueia o acesso direto aos bancos de dados.

Um agente não é uma conta de serviço. Uma chave de API estática com permissões amplas abre caminho para o ataque confused-deputy: um prompt malicioso leva o agente autorizado a executar uma ação nociva com privilégios máximos. Por isso, cada agente tem identidade própria, e as permissões são concedidas por tokens de delegação de curta duração, válidos para uma chamada específica. Nos logs de auditoria, dá para ver onde agiu uma pessoa e onde agiu um agente em nome dela.

O terceiro risco é a IA "herdada": fornecedores de SaaS, ERP e ITSM ativam Copilots embutidos por meio de atualizações e alteram o mapa de fluxos de dados, o que atinge o sigilo bancário (art. 26 da lei "Sobre Bancos e Atividade Bancária", art. 857 do Código Civil da Rússia). A política do banco é default-off para funções de IA externas: ativá-las equivale a uma mudança maior, e o controle é feito em um registro separado.

Documentação para máquinas, o fim do ARB e novos NFRs

A documentação de arquitetura (ADR, diagramas C4, descrições de API) fica no Git como Markdown, PlantUML e Structurizr. Os agentes leem o texto bruto do repositório melhor do que exportações de sistemas proprietários, por isso o repositório contém os arquivos de contexto RULES.md e ARCHITECTURE.md. Para o acesso, o banco escreveu uma camada interna sobre os repositórios, com suporte a MCP. Os comitês ARB foram dissolvidos: vale o advice process, em que a decisão cabe ao arquiteto de soluções (Solution Architect) no domínio, e os perímetros regulatórios continuam como restrições obrigatórias.

Os templates de ADR ganharam a fronteira entre a lógica determinística e a saída probabilística, a topologia dos fluxos de dados dentro do perímetro do banco, os gatilhos de transferência do controle para uma pessoa e um exit path para casos de degradação do fornecedor ou mudança de licença. Nos requisitos não funcionais surgiram métricas de comportamento em caso de falha: uma "recusa correta" vale mais que uma alucinação arriscada. No FinOps, foi definido um teto de custo em tokens para cada transação de negócio, e a latência é medida no ciclo completo, incluindo as chamadas do agente a sistemas externos.

O autor deixa em aberto a questão dos metamodelos: o ArchiMate não consegue descrever adequadamente um prompt, um limiar de validação ou uma cadeia dinâmica de delegação. A conclusão é esta: a planta promete como o sistema vai funcionar, e um componente probabilístico não dá esse tipo de promessa. Resta limitá-lo de antemão, interceptá-lo no momento da ação e provar depois com a autoridade de quem ele agiu.