Tero, um agent harness que viabiliza o DORA em bancos

Em janeiro de 2025, uma falha de software interrompeu os pagamentos do banco britânico Barclays justamente no dia do prazo final de impostos do Reino Unido: clientes ficaram sem conseguir pagar nos supermercados, e famílias não conseguiram concluir a compra de suas casas.

Meses depois, uma investigação do Parlamento do Reino Unido revelou que os principais bancos e sociedades de crédito imobiliário (building societies) do país acumularam mais de 800 horas de interrupções tecnológicas não planejadas em apenas dois anos, o equivalente a 33 dias consecutivos de sistemas fora do ar.

É exatamente esse o cenário que o Digital Operational Resilience Act (DORA) da União Europeia busca evitar. O R de DORA significa resiliência, e o verdadeiro desafio para um banco é construir essa resiliência sem sacrificar a velocidade de entrega. Uma das formas mais diretas de conseguir isso é usar agentes de IA para acelerar a qualidade de software, como o Tero faz.

O que é o DORA e por que ele importa para o seu software¶

O DORA passou a ser aplicável em 17 de janeiro de 2025 a bancos, seguradoras, empresas de investimento e seus fornecedores externos de tecnologia. Seu objetivo vai além da cibersegurança tradicional. Ele foca na resiliência operacional digital, ou seja, as entidades financeiras devem ser capazes de resistir, responder e se recuperar de qualquer interrupção relacionada às TIC, seja um ciberataque ou uma falha técnica interna.

A regulamentação se organiza em torno de cinco pilares:

1. Gestão de riscos de TIC: framework de governança, identificação de ativos críticos e avaliação contínua de riscos, com responsabilidade direta do órgão de administração.
2. Gestão e notificação de incidentes: classificar, registrar e notificar os incidentes de TIC relevantes dentro de prazos rigorosos.
3. Testes de resiliência operacional digital: um programa de testes que inclui testes anuais de todos os sistemas críticos e, para as entidades mais significativas, Threat-Led Penetration Testing (TLPT) a cada três anos.
4. Gestão de riscos de terceiros de TIC: mapear as dependências de fornecedores e exigir deles o mesmo nível de controle.
5. Compartilhamento de informações: compartilhar inteligência sobre ameaças e vulnerabilidades entre as entidades do setor.

O terceiro pilar é o que quase nunca aparece na conversa sobre IA em QA, e é justamente o mais relacionado ao que uma equipe de qualidade de software faz todos os dias.

A IA nos testes viola o DORA?¶

Quando um banco considera incorporar agentes de IA aos seus processos de entrega, a primeira reação das áreas de Risco e Compliance costuma ser defensiva: isso adiciona uma nova fonte de risco tecnológico? É uma pergunta razoável, mas está formulada ao contrário.

O DORA não proíbe o uso de IA. Pela sua regulamentação (Regulamento (UE) 2022/2554), qualquer componente tecnológico, incluindo a IA, deve ser governado, rastreável e fazer parte de um framework documentado de gestão de riscos de TIC, com controles proporcionais ao porte e à criticidade da entidade. Por isso, é essencial que os agentes de IA usados na qualidade de software sejam projetados para operar dentro desse framework de governança.

É aqui que o Tero atua como um facilitador da conformidade com o DORA, já que constrói ativamente o framework de governança exigido pela regulamentação.

O Tero é um agent harness da Abstracta, ou seja, uma camada de software que transforma modelos de IA de uso geral em agentes especializados e governados para fluxos de trabalho de QA.

O modelo fornece o raciocínio (interpreta informações e gera respostas), enquanto o Tero fornece o contexto, as permissões, a supervisão humana e as evidências de que esses agentes precisam para operar de forma controlada dentro de processos reais de qualidade de software.

Como os princípios do Tero se conectam ao DORA¶

O Tero se organiza em torno de quatro pilares: contexto de negócio, confiança, visibilidade e governança. Eles foram pensados para empresas reguladas. Cada um responde, quase ponto por ponto, a um requisito específico do DORA:

No nível técnico, isso se apoia nos cinco componentes do Tero: orquestração, integração, observabilidade, governança e segurança. O componente de observabilidade é especialmente relevante para o DORA, porque registra cada conversa, cada chamada de ferramenta e cada decisão tomada por cada agente. Essas ações geram a rastreabilidade de que o Compliance precisa para demonstrar controle.

Menos defeitos em produção significam mais resiliência operacional¶

O objetivo do DORA é que os sistemas financeiros consigam resistir, responder e se recuperar de qualquer falha. Os incidentes bancários dos últimos dois anos mostram um padrão: grande parte das falhas operacionais graves não se origina em ciberataques, mas em erros de software que chegam à produção.

Alguns exemplos recentes deixam isso claro:

• O Barclays confirmou ao Comitê do Tesouro do Reino Unido que a interrupção de janeiro de 2025 foi causada por um problema de software no seu mainframe, e não por um ciberataque, e informou que destinaria entre £ 5 milhões e £ 7,5 milhões apenas para indenizar os clientes afetados por esse incidente (Parlamento do Reino Unido).
• Em outubro de 2025, o Commonwealth Bank sofreu uma interrupção de quase três horas que afetou simultaneamente pagamentos, banco digital e caixas eletrônicos em toda a Austrália. O banco restabeleceu os serviços, mas não divulgou a causa do incidente (ABC News).
• O regulador de valores mobiliários dos EUA (FINRA) multou uma corretora em US$ 2,25 milhões depois que uma falha de design em seu sistema de supervisão automatizada deixou de detectar mais de 4 milhões de operações irregulares ao longo de sete anos, um problema originado em uma lacuna de cobertura do próprio sistema, e não em um ataque externo (FinanceFeeds).

O DORA exige testes rigorosos justamente porque os reguladores europeus entendem essa relação: sem um programa de testes sólido, a resiliência operacional é uma promessa sem fundamento.

É aqui que o Tero entra: ao implantar agentes colaborativos para regressão, análise de impacto, geração de dados de teste e detecção de falhas de lógica, ampliamos a cobertura e a velocidade das práticas de QA sem substituir o julgamento humano de que o Compliance ainda precisa.

Em outras palavras: cada bug, vulnerabilidade ou falha de lógica que um agente do Tero ajuda a detectar antes de um release é um incidente operacional que o banco não precisa notificar ao regulador.

Como construir resiliência sem sacrificar a velocidade de entrega¶

Adicionar o Tero aos processos de qualidade de um banco que já está investindo no DORA é uma forma concreta de construir resiliência sem sacrificar a velocidade de entrega. Ele fortalece três áreas ao mesmo tempo:

• Para compliance e risco: evidências concretas e rastreabilidade de como os sistemas críticos são testados, com aprovação humana para cada decisão sensível.
• Para tecnologia e engenharia: maior cobertura de testes em sistemas complexos e legados, sem exigir um rip-and-replace da stack existente.
• Para o órgão de administração: um caso mensurável para apresentar ao supervisor, mostrando que a gestão de riscos de TIC inclui ativamente a prevenção de defeitos antes da produção.

Isto não é uma promessa de zero incidentes: nenhum framework de qualidade, seja humano ou assistido por IA, pode garantir isso. O foco deve estar em reduzir de forma consistente a probabilidade de que uma falha de software se torne um incidente que o banco precise explicar a um regulador.