Quando uma equipa de garantia de qualidade (QA) num banco avalia ferramentas de teste de IA, a conversa tende a começar com o mesmo conjunto de questões que qualquer equipa de engenharia colocaria: quantos casos de teste gera, quão precisa é a geração, quão bem lida com a manutenção de testes, que frameworks suporta. Estas são questões legítimas. São, no entanto, o ponto de partida errado, porque tratam o problema de QA assistido por IA numa instituição financeira regulamentada como se fosse o mesmo problema de QA assistido por IA numa startup SaaS. Não é.
A diferença não está no código a ser testado. Está no que acontece depois de os testes serem executados. Para a equipa de QA de uma startup, saber se o software funciona é suficiente. Para um banco, a mesma questão acarreta um requisito adicional — prová-lo, aos supervisores, aos auditores e, na fase de aplicação do DORA, que começou em 2026, às autoridades competentes nacionais que estão ativamente a analisar se os programas de testes de resiliência produzem evidências que se sustentam sob escrutínio regulamentar.
Essa distinção é o alicerce sobre o qual a Qualigentic foi construída. Não como uma ferramenta genérica de testes de IA com um módulo de conformidade adicionado, mas como uma plataforma concebida desde o início para as restrições específicas de garantia de qualidade em indústrias regulamentadas. Compreender o que isso significa exige precisão sobre o que as ferramentas genéricas de testes de IA realmente fazem, onde funcionam bem e onde a arquitetura de uma instituição regulamentada cria requisitos para os quais nunca foram concebidas.
Seria impreciso e inútil descartar ferramentas como GitHub Copilot, Testim, ou as funcionalidades de teste com IA em plataformas de desenvolvimento de propósito geral. Elas resolvem problemas reais para as equipas de engenharia e fazem-no bem em contextos onde esses problemas são a principal preocupação.
Geração e manutenção de testes
A capacidade central da maioria das ferramentas de teste de IA é a geração de testes a partir de código ou especificação. Dada uma assinatura de função, uma estrutura de classe ou uma descrição em linguagem natural do comportamento esperado, estas ferramentas podem gerar casos de teste de forma mais rápida e sistemática do que um engenheiro humano que escreve testes do zero. Cobrem condições de limite que são fáceis de ignorar, produzem padrões de teste consistentes em uma base de código e reduzem o tempo necessário para atingir um nível de cobertura basal. Para equipas que estão a fazer testes insuficientes — o que descreve a maioria das equipas de engenharia — esta é, portanto, uma melhoria genuína e material.
Uma capacidade secundária é a assistência na manutenção de testes: detetar quando uma alteração no código tornou um teste obsoleto, sugerir atualizações, assinalar testes que podem já não estar a testar o que parecem testar. A Capgemini Relatório Mundial de Qualidade 2025–26 observa que, na maioria das organizações, 60–70% do esforço dedicado ao controlo de qualidade é canalizado para a manutenção de testes existentes, em vez de para a criação de novos testes. Consequentemente, qualquer ferramenta que reduza essa carga liberta uma capacidade significativa de engenharia, e várias ferramentas de teste baseadas em IA fazem isso razoavelmente bem.
O que estas ferramentas não foram concebidas para fazer, no entanto, é produzir um registo estruturado, rastreável e auditável que conecte cada teste ao requisito regulamentar específico que aborda, com registos de execução assinados, controlos de acesso baseados em funções sobre quem pode aprovar resultados e políticas de retenção configuráveis que correspondam às obrigações regulamentares da instituição. Não se trata de uma funcionalidade em falta. É uma categoria de produto completamente diferente.
Onde a arquitetura das instituições reguladas altera os requisitos
Existem dois constrangimentos estruturais em instituições financeiras reguladas que reformulam a maneira como a infraestrutura de teste de IA deve ser. O primeiro é o perímetro de dados. O segundo é o formato da evidência.
O problema do risco de terceiros que as ferramentas de QA baseadas na nuvem criam ao abrigo do DORA
Em janeiro de 2026, a BaFin, a autoridade de supervisão financeira da Alemanha, confirmou, através de orientações não vinculativas, que os sistemas de IA utilizados em instituições financeiras - incluindo ferramentas usadas em testes e garantia de qualidade - se enquadram no quadro de governação das TIC da DORA. Isto tem uma consequência direta para qualquer banco ou seguradora que esteja a avaliar uma plataforma de testes de IA baseada na cloud como parte do seu programa de testes de resiliência DORA.
Sob os Artigos 28.º-31.º da DORA, os prestadores de serviços terceirizados de TIC que suportam funções críticas devem ser geridos formalmente: avaliados quanto à criticidade, sujeitos a requisitos contratuais que cumpram as especificações do regulamento e monitorizados continuamente. Consequentemente, uma ferramenta de teste de IA baseada na nuvem que processa dados relacionados com testes de sistemas que suportam funções críticas é, ao abrigo deste quadro, um prestador terceirizado de TIC que requer gestão formal. A instituição que adotou a ferramenta para melhorar a sua conformidade com a DORA criou simultaneamente uma nova entrada de risco de terceiros sob a DORA para gerir.
A implementação no local não resolve apenas o problema do perímetro de dados. Remove uma dependência de terceiros de TIC que, de outra forma, teria de ser gerida, contratada e monitorizada ao abrigo dos Artigos 28.º a 31.º do DORA.
Isto não é uma preocupação hipotética para futuras revisões de supervisão. É uma falha de governação que existe desde o momento em que a ferramenta é adotada e que os supervisores estão agora em posição de identificar durante uma revisão ativa. As instituições que descobriram esta falha em 2026, durante o seu primeiro contacto de supervisão substantivo, estão a trabalhar na remediação sob pressão de tempo. Aquelas que a identificaram antes da adoção não estão.
Como a comparação se parece na prática
Em vez de uma comparação característica a característica que abstrai de como estas ferramentas são realmente utilizadas, é mais útil descrever os cenários específicos em que a escolha entre uma ferramenta de teste de IA genérica e uma orientada para a conformidade produz resultados diferentes.
No cenário de revisão de supervisão, uma equipa que utiliza uma ferramenta genérica de teste de IA enfrenta um problema de montagem: extrair registos dos registos de CI/CD, correlacioná-los com os requisitos de um sistema separado, confirmar a aprovação de um fluxo de trabalho de aprovação separado e apresentar o resultado num formato que responda à questão específica do supervisor. A informação pode existir. Ela existe, no entanto, em múltiplos sistemas, em formatos concebidos para operações de desenvolvimento em vez de submissão regulatória. A própria montagem é um risco — evidências incompletas, atrasadas ou formatadas de forma inconsistente constituem uma lacuna de conformidade, independentemente de os testes subjacentes terem sido sólidos.
O problema de classificação de incidentes
No cenário de classificação de incidentes, a janela de notificação inicial de 4 horas, de acordo com os requisitos de reporte de incidentes da DORA, pressupõe que a instituição consegue determinar rapidamente a natureza e o âmbito do incidente, incluindo se o sistema afetado foi testado recentemente e o que esse teste revelou. Uma equipa cujos registos de testes estão distribuídos por ferramentas de desenvolvimento e requerem montagem manual não dispõe de 4 horas para recuperação.
O que a Qualigentic não é
A precisão sobre o que uma ferramenta faz exige igual precisão sobre o que ela não faz. Qualigentic não substitui o julgamento de engenharia que a garantia de qualidade em sistemas complexos requer. Ela não sabe quais modos de falha são mais importantes para o perfil de risco de uma instituição específica. Ela não interpreta os requisitos regulamentares nem determina quais sistemas de TIC se qualificam como suporte a funções críticas ao abrigo do DORA. Ela não substitui a experiência de domínio das equipas de QA que compreendem como os sistemas da sua instituição se comportam em condições que nenhum sistema automatizado foi treinado para antecipar.
A questão que clarifica a escolha
Quando falamos com os líderes de QA e CTOs de instituições reguladas sobre a Qualigentic, a conversa que gera mais clareza não é uma comparação de funcionalidades. É esta: quando a sua próxima revisão supervisionada pedir a evidência de testes de resiliência para os seus três sistemas de TIC mais críticos, o que será capaz de produzir e quanto tempo levará para o fazer?
A lacuna de infraestruturas por trás da lacuna de testes
Se a resposta envolver confiança — um registo estruturado, recuperável em minutos, com uma cadeia ininterrupta desde o requisito até ao registo de execução assinado — então a infraestrutura atual é provavelmente adequada. No entanto, se a resposta envolver incerteza sobre onde se encontram os registos, se estão completos ou se satisfazem o formato que um supervisor espera, então a falha não está nos testes em si. Está na infraestrutura construída em torno dos testes — a camada que transforma registos de qualidade de desenvolvimento em provas de qualidade regulamentar.
Essa não é uma lacuna que uma ferramenta genérica de teste de IA melhorada resolve. Em vez disso, requer infraestrutura concebida para os requisitos específicos de uma instituição regulamentada — com implementação on-premise, cadeias de evidências orientadas para a conformidade e fluxos de trabalho de aprovação controlados por RBAC integrados na arquitetura, em vez de adicionados posteriormente.
A escolha entre ferramentas não se trata de qual gera mais casos de teste. Trata-se de qual produz evidências que sobrevivem a uma revisão de supervisão. Em indústrias regulamentadas, esses são produtos diferentes.
