Há uma versão da conformidade com a DORA com a qual a maioria das instituições financeiras tem vindo a conviver no último ano e meio — uma em que a preocupação principal era a implementação de quadros, a produção de documentação e o alinhamento de políticas internas com os cinco pilares do regulamento. Essa versão acabou. A 17 de janeiro de 2025, a DORA tornou-se aplicável, e os requisitos de QA de testes de resiliência da DORA seguiram-se. Em 2026, as autoridades competentes nacionais em toda a UE passaram da tolerância de supervisão para a revisão ativa. A questão que os supervisores estão agora a fazer não é se um banco tem um programa de conformidade com a DORA. É se esse programa produz evidências que se sustentam sob escrutínio.
Para as equipas de QA em bancos, seguradoras e instituições de pagamento, esta mudança altera a natureza do trabalho de uma forma que vale a pena ser precisa. Os requisitos de testes de resiliência da DORA — artigos 24.º a 27.º, e as Normas Técnicas Regulamentares que os acompanham — não pedem resultados de testes. Pedem uma cadeia documentada e auditável, desde os sistemas de TIC que suportam as funções críticas, passando pelos testes que verificaram a sua resiliência, até aos resultados que esses testes produziram. Isso é algo completamente diferente de executar um conjunto de testes e apontar para o painel verde.
Construir o Qualigentic — a nossa plataforma de QA com IA para indústrias regulamentadas — obrigou-nos a pensar cuidadosamente sobre como é a cadeia de evidências na prática e porque é que a infraestrutura de testes convencional, por mais madura que seja, tende a falhar no que a fase de supervisão da DORA realmente exige.
O que a mudança de supervisão significa realmente para as equipas de testes
José Manuel de Araluce, a escrever em Finanças de QA em março de 2026, faça a alteração diretamente: "Com os 'rodas de treino' agora removidas, 2026 marca o primeiro teste real da DORA, e tanto as instituições financeiras como os CTPP sentirão a diferença." A mudança que ele descreve é específica: os supervisores estão a afastar-se da avaliação de políticas e a aproximar-se da avaliação de evidências operacionais. Um procedimento de resposta a incidentes bem escrito não é o mesmo que prova de que o procedimento funciona quando ocorre um incidente real. Um plano de teste que descreve o que será testado não é o mesmo que um registo assinado que mostra o que foi testado, quando, em relação a qual requisito e qual foi o resultado.
Esta distinção — entre a documentação da intenção e a documentação da execução — é onde a maioria dos programas de testes em instituições financeiras se encontra atualmente exposta. A lacuna não é, geralmente, falta de testes. A maioria das equipas de engenharia maduras em bancos executa conjuntos de testes substanciais, com métricas de cobertura que parecem credíveis num dashboard. A lacuna reside na rastreabilidade desses testes aos requisitos regulamentares e no formato do output que produzem. Uma percentagem de cobertura, por mais elevada que seja, não é uma evidência auditável. Não informa um supervisor qual sistema específico de TIC foi testado, em que condições, por quem, com que resultado e se esse resultado foi revisto antes de o sistema ser promovido para produção.
Os supervisores já não avaliam se um banco tem um programa de testes. Avaliam se esse programa produz evidências que sobrevivem a um exame regulatório.
Os cinco pilares, e onde os testes se encaixam
A DORA estrutura os seus requisitos em cinco domínios. Vale a pena ser preciso sobre quais deles implicam diretamente a função de QA, porque a tentação de tratar a DORA como uma preocupação primordial de segurança ou governança ignora onde a pressão operacional sobre as equipas de teste realmente se situa.
Que evidências de testes de resiliência DORA QA exigem realmente
O conceito de uma cadeia de provas é simples em princípio e exigente na prática. Um supervisor a rever o seu programa de testes de resiliência DORA precisa de ser capaz de rastrear, para qualquer sistema TIC que suporte uma função crítica, o percurso desde o requisito que esse sistema deve cumprir, passando pelo caso de teste concebido para o verificar, até ao registo de execução que mostra o que aconteceu quando esse teste decorreu, até à aprovação que confirma que o resultado foi revisto por alguém com autoridade para o fazer. Cada elo dessa cadeia deve estar presente, com carimbo de data e hora, e ser imutável — não editável após o facto.
A maioria da infraestrutura de testes não foi concebida para isto. Ferramentas de gestão de testes registam resultados, mas não impõem rastreabilidade aos requisitos. Pipelines CI/CD executam testes, mas os registos são sobrescritos ou arquivados em formatos que não são estruturados para recuperação regulamentar. Relatórios de cobertura agregam resultados, mas descartam os registos de execução individuais que a revisão regulamentar realmente necessita. Nada disto é uma falha de conceção — estas ferramentas foram construídas para suportar a velocidade de desenvolvimento, não auditorias regulamentares. O problema é que a auditoria regulamentar é agora um requisito, e a lacuna entre as ferramentas de desenvolvimento e as provas prontas para auditoria é real.
O problema específico com as ferramentas de teste de IA e DORA
Em janeiro de 2026, a BaFin da Alemanha emitiu orientações não vinculativas confirmando que os sistemas de IA – incluindo ferramentas de IA generativa e modelos de linguagem de grande dimensão – não constituem um regime regulamentar separado ao abrigo do DORA, e devem ser incorporados nos quadros existentes de governação das TIC, testes e risco de terceiros. A consequência prática para as instituições financeiras que utilizam ferramentas de teste assistidas por IA é direta: essas ferramentas são, em si, sistemas de TIC ao abrigo do DORA. Se processarem dados de teste num ambiente de nuvem, criam uma dependência de um Fornecedor Crítico de Terceiros de TIC que requer gestão formal ao abrigo dos artigos 28.º a 31.º.
Isto não é uma preocupação teórica. Um banco que adote uma plataforma de testes de IA baseada na nuvem para melhorar o seu programa de testes de resiliência DORA pode, simultaneamente, criar a exposição ao risco de terceiros que a DORA visa gerir. A lógica institucional é sólida — utilizar IA para gerar mais testes, mais rapidamente e com melhor cobertura — mas a consequência arquitetónica, se a ferramenta depender da nuvem, é uma nova entrada no registo de riscos de terceiros DORA da instituição.
A implementação on-premise resolve isto. Quando a infraestrutura de testes corre dentro do perímetro da própria instituição, não existe uma relação com um fornecedor externo de TIC para gerir ao abrigo do DORA. Os dados não saem. Os registos de execução permanecem dentro da própria infraestrutura de auditoria da instituição. A cadeia de evidências é completa e autónoma.
A diferença entre testar mais e testar com evidências
Existe uma abordagem à preparação para o DORA que se centra no volume de testes — executar mais testes, abranger uma maior parte da base de código e gerar mais cenários. O volume não é irrelevante, mas não é isso que a fase de supervisão da DORA está a avaliar. Um conjunto de testes que executa 10 000 casos e produz um painel a mostrar uma taxa de aprovação de 94% não satisfaz, por si só, o requisito do artigo 25.º relativo à documentação que sustenta a revisão de supervisão. O que importa é saber se os testes correspondem aos sistemas e funções de TIC que a DORA identifica como estando no âmbito de aplicação e se os registos desses testes estão estruturados de forma a responder às perguntas que um supervisor irá colocar.
A pergunta que um supervisor da DORA coloca não é "quantos testes executou?". É "mostre-me a evidência de que o sistema TIC que suporta esta função crítica foi testado, quando, com que resultado e quem o aprovou"."
Esta reformulação muda a prioridade do trabalho de QA numa instituição regulamentada de uma forma que vale a pena considerar. A mudança não é de menos testes para mais testes. É de testes como atividade de garantia de qualidade para testes como atividade de geração de evidências com um propósito regulatório definido. O resultado do processo não é uma métrica de cobertura – é um registo estruturado que responde a questões regulatórias específicas e pode ser recuperado, intacto e inalterado, quando um supervisor o solicita.
O que a DORA não exige — e onde reside o risco de sobredirecionamento
Vale a pena ser preciso sobre o que os requisitos de testes de resiliência do DORA não exigem, pois a pressão regulamentar para demonstrar conformidade pode gerar respostas mais onerosas do que a regulamentação efetivamente exige.
A questão a fazer antes da sua próxima revisão de supervisão
A preparação mais útil para uma revisão de supervisão da DORA não é uma revisão de lista de verificação de conformidade. É uma simulação: se um supervisor pedisse à sua equipa, hoje, para produzir o registo de evidências completo para os testes de resiliência dos seus três sistemas de TIC mais críticos, o que é que conseguiria mostrar-lhes e quanto tempo demoraria a produzi-lo?
Se a resposta implicar a pesquisa em várias ferramentas, a compilação de registos de diferentes sistemas e a esperança de que os registos não tenham sido rodados, a lacuna é estrutural — não é uma questão de executar mais testes. Os testes já podem existir. O que falta é a infraestrutura para os produzir como prova sob demanda, no formato que um supervisor espera, com uma cadeia ininterrupta do requisito ao resultado.
É exatamente este o problema que a Qualigentic foi criada para resolver. Não para substituir o trabalho de teste que as equipas de QA já realizam bem, mas para produzir a camada de evidências que a fase de supervisão do DORA exige — com implementação on-premise que mantém os dados dentro do perímetro próprio da instituição, fluxos de aprovação controlados por RBAC e cadeias de evidências recuperáveis como registos estruturados, em vez de serem remontados a partir de logs de CI no dia em que um supervisor o pede.
2026 é o ano em que a distinção começa a importar na prática. As instituições que se prepararam para tal estão melhor posicionadas do que aquelas que se estão a preparar agora. Mas os preparados e os não preparados estão ambos numa posição melhor do que assumir que o conjunto de testes é a evidência.
