A fase de fiscalização da DORA quer evidências, não PDFs de política
Durante quase toda a sua vida inicial, o compliance do setor financeiro premiou boa documentação. Escrevia-se a política, mapeavam-se os controlos, mantinha-se o dossiê atualizado, e quando o supervisor aparecia entregava-se um conjunto bem organizado de PDFs. O documento era a entrega. Uma organização que conseguisse descrever a sua resiliência de forma convincente era, para efeitos regulatórios, resiliente.
Só que essa era está a fechar. A DORA, o Regulamento europeu da Resiliência Operacional Digital, está em vigor desde 17 de janeiro de 2025 e, em 2026, entrou na fase de fiscalização. Como reporta a análise da Dawiso sobre agentes de IA na banca ao abrigo da DORA, e como ecoam as coberturas da Auriga e do ATM Marketplace sobre governação de IA em instituições financeiras, os supervisores mudaram o que aceitam. Passaram de tomar documentos de política pelo seu valor facial a esperar evidência de resiliência baseada em dados. O dossiê deixou de ser a entrega. A prova é.
Essa viragem cai com mais força precisamente sobre os sistemas que os bancos correm agora a implementar. Porque um PDF de política que descreve como os seus agentes se comportam e um trilho de evidências que prova como se comportaram são dois artefactos completamente diferentes, e o segundo é o único que sobrevive a uma revisão em fase de fiscalização.
A lacuna que a fase de fiscalização expõe
Uma política é uma descrição do comportamento pretendido. A evidência é um registo do comportamento efetivo. No mundo anterior à fiscalização, uma podia substituir a outra, porque ninguém estava a confrontar a segunda com a primeira. A fase de fiscalização acaba com essa substituição.
A razão por que isto importa agora, e não há cinco anos, é o que os bancos estão a implementar. A cobertura da Dawiso projeta que cerca de 44% das equipas financeiras estarão a usar IA agêntica em 2026, um salto grande. É essa a colisão no centro desta história. Um regime de supervisão que acabou de começar a exigir evidência de comportamento efetivo encontra uma vaga de sistemas cujo comportamento efetivo é probabilístico, muda a cada atualização de modelo e, na maioria dos deployments, mal chega a ser registado.
Os riscos nomeados nessa cobertura são específicos, e não são abstratos. Acesso não controlado dos agentes a sistemas internos. Registo inadequado, que torna impossível reconstruir um incidente. Leia os dois em conjunto e tem o modo de falha exato que a fase de fiscalização da DORA foi construída para apanhar: um sistema que consegue atuar sobre as suas plataformas centrais e não consegue depois dizer o que fez nem porquê. O PDF de política dizia que estava governado. A revisão pede-lhe que o prove, e não há nada para mostrar.
Um agente que não consegue reconstruir o que fez não passa numa revisão DORA
É esta a frase a interiorizar, porque converte uma ansiedade vaga de compliance num requisito arquitetural concreto.
As expectativas de resiliência da DORA pressupõem que, quando algo corre mal, consegue reconstruí-lo. O reporte de incidentes, a análise de causa-raiz e toda a postura de resiliência operacional assentam na capacidade de responder, depois do facto, ao que aconteceu, por que ordem e com que fundamento. Para software determinístico, é um problema resolvido: os registos são a história, e o código que os produziu não muda entre o incidente e a investigação.
Um agente quebra esse pressuposto de duas maneiras. Primeiro, atua sobre contexto em tempo real e raciocina de forma probabilística, por isso "o que teria feito" não se recupera voltando a correr o código. Segundo, se o registo for inadequado, como a cobertura nomeia explicitamente, então nem sequer "o que fez de facto" é recuperável. Um agente que leu um dossiê, raciocinou sobre ele e lançou uma decisão, mas não deixou registo inspecionável dos dados que viu, da política que aplicou e do veredicto a que chegou, produziu um resultado que ninguém consegue reconstruir.
No regime anterior isso era sobrevivível, porque se podia apontar para a política. Em fiscalização, é eliminatório. Um agente cujas decisões não podem ser reconstruídas não pode ser demonstrado como resiliente, e um sistema que não pode ser demonstrado como resiliente não passa. A ausência de evidência não é uma falha de documentação que se corrige depois. É um buraco permanente, porque não se registam retroativamente decisões que o sistema já tomou sem as ter captado.
Compliance como política executável, evidência como subproduto
A saída não é escrever um PDF de política melhor. É construir uma arquitetura em que a política é executável e a evidência é produzida automaticamente, como condição para o sistema sequer funcionar.
Duas propriedades fazem o trabalho, e correspondem diretamente ao que "evidências, não políticas" exige.
Compliance como política executável. Em vez de um documento que descreve as regras, as regras são código de que a sua equipa de compliance é dona, que versiona e assina, avaliado no momento de cada decisão. Cada ação com consequência passa por um ponto de decisão de políticas que devolve um veredicto legível por máquina: permitir, permitir com condições documentadas, negar, ou exigir uma pessoa. O peso regulatório que não pode ser delegado resolve-se numa pessoa, por política; o agente apenas analisa. A política deixa de ser uma afirmação sobre comportamento. É o mecanismo que produz o comportamento, e pode ser testada, reaprovada e provada.
Um trilho de evidências append-only, encadeado por hash. Cada decisão escreve um registo imutável, antes de a decisão se concretizar, dos dados que o agente viu, da versão da política contra a qual correu, e do veredicto a que chegou. Encadear as entradas por hash torna o trilho resistente a adulteração: consegue provar não só o que aconteceu mas que o registo não foi alterado depois. E falha fechado. Sem armazenamento de evidência, não há decisão. O sistema não consegue fisicamente atuar sem deixar o registo que um supervisor vai pedir.
Junte as duas e a reconstrução deixa de ser uma esperança e passa a ser uma consulta. Quando chega a pergunta da fase de fiscalização — o que fez este agente, com que fundamento, e consegue provar que o registo está intacto — a resposta é um relatório que corre, e não uma investigação que lança. A evidência existe porque a arquitetura não podia ter produzido a decisão sem a criar.
É essa a diferença entre descrever resiliência e demonstrá-la, e é exatamente a diferença que a fase de fiscalização da DORA foi construída para testar.
O reenquadramento
A pergunta que os bancos continuam a fazer, a que produz mais um dossiê, é "temos uma política que cubra os nossos agentes de IA?". Na fase de fiscalização, essa pergunta responde a um teste que já ninguém faz. Ter a política é o mínimo. Provar o comportamento é o exame.
A pergunta melhor é esta. Quando um supervisor nos pedir que reconstruamos exatamente o que um dos nossos agentes fez, sobre que dados, ao abrigo de que regra, e que provemos que o registo não foi tocado, conseguimos correr isso como um relatório, ou temos de admitir que não o captámos? Se a resposta honesta for a segunda, nenhum PDF de política fecha a lacuna, porque a lacuna não está na sua documentação. Está na sua arquitetura, e a fase de fiscalização lê arquitetura, não intenções.
Os supervisores mudaram o que aceitam. Os sistemas que estão a ser implementados tornaram a mudança urgente. E as organizações que constroem o trilho de evidências dentro do agente, em vez de escreverem uma política sobre ele, são as únicas que passarão na revisão que agora é certo que vão enfrentar.
Se quiser testar se os seus processos agênticos conseguiriam produzir uma reconstrução que um supervisor DORA aceitasse, marque uma reunião e traga-nos aquele que toca em mais sistemas internos.