Desafios

Garantia Finance-Grade para IA Agêntica: Risco de Monocultura e o Heterogeneity Score

Por Marc Molas·30 de março de 2026·12 min de leitura

A maioria da discussão sobre governança de IA trata a segurança como uma propriedade única de um sistema individual. Bancos e seguradoras não têm esse luxo. Quando a IA agêntica é entregue em fluxos financeiros — decisões de crédito, execução de trades, gestão de sinistros, revisão AML — a superfície de risco inclui não apenas o modo de falha por agente mas o modo de falha sistémico: muitos agentes em muitas instituições, todos a partilhar a mesma família de modelo, todos a tomar decisões correlacionadas más ao mesmo tempo, todos a reagir à mesma distribuição de prompt.

Isto não é hipotético. É o mesmo tipo de risco de falha correlacionada que levou os reguladores a preocupar-se com a monocultura de modelos na finança quantitativa há duas décadas. O paper actual Finance-Grade Assurance for Agentic AI (Fradelos, janeiro 2026) toma o padrão de governança verificável e estende-o explicitamente para fluxos financeiros de alto risco. As contribuições principais: um sistema de controlo em camadas que o paper chama FG-VGA, e uma métrica operacional chamada Heterogeneity Score (HS) que trata a monocultura de modelos como risco auditável de primeira classe.

Este é o paper a ler se és CTO numa instituição financeira a entregar agentes em qualquer coisa que importe aos reguladores. Também é útil bem além da finança, porque o padrão arquitectónico generaliza.

O Que Faz a Governança "Finance-Grade"

A garantia finance-grade não é apenas governança "mais rigorosa". É uma forma específica que os regimes de supervisão (gestão de risco de modelo, resiliência operacional, preocupações de risco sistémico ESRB/FSB) realmente requerem. O paper identifica quatro propriedades que as abordagens actuais de governança de IA tipicamente carecem:

Gating de policy verificável por máquina para acções agênticas — não "o modelo é suposto seguir esta política", mas "o runtime não pode executar a acção a menos que passe a verificação de política".
Evidence packets que ligam intenção, tool calls e resultados — cada acção produz um registo assinado que liga a intenção declarada do agente, o tool call real e o resultado observado. Reconstruível. À prova de manipulação.
Controlos de deployment ligados a atestação — os agentes só correm em ambientes de execução atestados. O evidence packet liga à atestação, por isso um auditor pode verificar que uma dada acção foi tomada pelo código esperado no hardware esperado.
Uma métrica operacional que trata o comportamento correlacionado de agentes como risco de primeira classe — não apenas risco por agente, mas o risco sistémico de muitos agentes a convergir na mesma resposta porque partilham o mesmo modelo subjacente.

Os primeiros três são extensões do padrão de arquitectura de governança verificável. O quarto é a contribuição genuinamente nova.

O Heterogeneity Score

O Heterogeneity Score (HS) é uma métrica aplicável e auditável de quanta diversificação de modelo e vendor existe num dado deployment agêntico. A intenção é operacionalizar o que tem sido uma preocupação no ar na discussão de risco de IA: o facto de que se a IA agêntica de cada banco para decisões de crédito é construída sobre os mesmos dois modelos de fundação, o modo de falha desses modelos torna-se sistémico.

O HS é calculado contra o deployment agêntico em scope e é gated como condição de autorização. Acima do limiar, o deployment é permitido. Abaixo do limiar, o deployment é bloqueado ou requer aceitação de risco explícita de um indivíduo sénior responsável.

Três coisas tornam o HS prático:

É mensurável

O HS é construído a partir de inputs concretos: o conjunto de famílias de modelos em uso, o conjunto de vendors, a correlação do comportamento de agente numa distribuição benchmark. Estas são quantidades auditáveis. Não são perfeitas — a correlação do comportamento do modelo é algo difícil de medir com rigor — mas são suficientemente concretas para fazer gating.

É um portão de deployment, não uma métrica de reporting

Esta é a diferença operacional. A maioria dos requisitos de "diversidade" nos frameworks de risco de IA são requisitos de reporting: descreves o que estás a fazer, o regulador revê, o deployment procede. O HS é um portão: o runtime de deployment verifica a pontuação e recusa proceder se estiver abaixo do limiar. A recusa é uma propriedade do sistema, não uma propriedade do julgamento humano.

Mapeia para preocupações de risco sistémico que os reguladores já estão a levantar

ESRB, FSB, FINMA e outros têm sinalizado preocupação sobre a monocultura de modelos na IA financeira. O HS é desenhado para ser a métrica concreta que os supervisores podem examinar, não apenas uma alegação vaga de que "usamos múltiplos vendors".

As Quatro Moedas Auditáveis

A movimentação arquitectónica mais profunda no paper é decompor a segurança em quatro "moedas" auditáveis:

Segurança probabilística: quão provável é o sistema violar limites de segurança, com prova quantitativa.
Segurança energética e de compute: o custo de recursos para operar o sistema, incluindo carga de pico e procura correlacionada.
Segurança epistémica: a integridade de conhecimento do sistema — sabe o que sabe, sinaliza incerteza, faz cross-check.
Segurança social e ambiental: as externalidades de operar o sistema — equidade, pegada ambiental, impacto social.

Cada moeda tem a sua própria metodologia de medição, formato de evidência e cadência de auditoria. O pipeline de governança remonta-as numa decisão de autorização de deployment.

A razão pela qual esta decomposição importa é que as quatro moedas não trocam limpamente. Um sistema pode ser probabilisticamente seguro e energeticamente esbanjador. Pode ser epistemicamente rigoroso e socialmente prejudicial. Tratar a "segurança de IA" como uma métrica escalar única obscurece esses trade-offs. Tratá-la como quatro moedas contabilizadas em separado torna os trade-offs explícitos e auditáveis.

O Que um Evidence Packet Realmente Contém

O evidence packet é a unidade de registo auditável. Para cada acção de agente com significância regulatória, o packet deve ligar:

Intenção: o objectivo declarado do agente para a acção, derivado do seu reasoning trace.
Contexto de autorização: as decisões de política avaliadas, a antiguidade do agente, as assinaturas multi-parte (se houver).
Tool call: a invocação precisa da ferramenta, parâmetros, sistema alvo.
Estado pré-acção: o que era verdade antes da acção.
Resultado: o que a ferramenta devolveu e que estado mudou.
Estado pós-acção: o que é verdade depois.
Apontador de atestação: uma referência criptográfica à atestação do runtime (o agente correu neste código neste hardware nesta configuração).

Estes packets são assinados pelo Watchdog, armazenados num evidence store imutável, e disponibilizados a auditores internos e externos sob pedido. Tornam-se o substrato da conformidade: não "confiamos que o agente se comportará bem", mas "aqui está o registo criptograficamente assinado do que o agente realmente fez".

Porque a Gestão de Risco de Modelo Precisa de Actualização

Os frameworks de gestão de risco de modelo (MRM) existentes foram desenhados para modelos preditivos. O modelo é um artefacto fixo; validas-lo, monitorizas-lo para drift, revalidas-lo periodicamente. A IA agêntica quebra este padrão de duas formas:

O comportamento do agente muda com o contexto. O mesmo modelo pode tomar acções diferentes consoante o prompt, o histórico de conversa, as ferramentas disponíveis, o papel do utilizador. MRM que valida "o modelo" não te diz o que o agente fará.
A superfície de risco tem forma de acção, não forma de predição. Os modelos preditivos produzem saídas sobre as quais os humanos depois agem. Os agentes produzem acções directamente. O risco dos agentes é risco de acção, não risco de predição. Os frameworks MRM desenhados para risco de predição estão a perder a unidade relevante.

O padrão FG-VGA aborda ambos: a validação é a nível de política e autorização, não a nível de modelo; a monitorização é em distribuições de acção, não distribuições de saída; o evidence store imutável fornece o registo por acção que a gestão de risco a nível de acção requer.

O Que os CTOs em Instituições Financeiras Devem Fazer

Três acções concretas para qualquer instituição financeira que está activamente a desplegar IA agêntica:

1. Adopta evidence packets a nível de acção agora

Independentemente de o teu regulador o requerer actualmente, constrói a geração do evidence packet no runtime do agente. O custo de retrofitar mais tarde é dramaticamente mais alto do que construir desde o início. O valor interno por si só — debugging, análise de incidentes, avaliação de capacidade — normalmente justifica o custo.

2. Mede o teu Heterogeneity Score mesmo informalmente

Mesmo que não formalizes o cálculo do HS, audita a tua diversificação de modelos. Se o teu agente de detecção de fraude, o teu agente AML, o teu agente KYC e o teu agente de atendimento ao cliente estão todos no mesmo modelo de fundação do mesmo vendor, tens um risco de monocultura não medido. A diversificação entre famílias de modelos é a mitigação prática.

3. Planeia para a atestação

O compute confidencial e a atestação remota ainda não são mainstream em deployments de IA em produção, mas a direcção regulatória é clara. A IA agêntica em fluxos regulados precisará de execução atestável nos próximos anos. Construir para um deployment pronto para atestação agora é muito mais barato do que retrofitar.

O Que Significa Fora da Finança

O padrão generaliza bem além da finança. Qualquer sector com:

Acções irreversíveis de alto risco (saúde, legal, infraestrutura)
Requisitos de responsabilidade regulatória (utilities, seguros, serviços públicos)
Preocupações de falha correlacionada sistémica (qualquer lugar onde um erro de IA à escala cria dano em cascata)

…beneficia da mesma arquitectura. O conceito de Heterogeneity Score aplica-se a qualquer deployment onde muitos operadores independentes possam convergir no mesmo modelo. O padrão de evidence packet aplica-se a qualquer deployment onde a reconstrução pós-incidente importe. A decomposição em quatro moedas aplica-se onde quer que a segurança não seja escalar.

A garantia finance-grade é, com efeito, a versão high-bar da governança de IA agêntica. As versões mid-bar parecem muito semelhantes com cadências de auditoria relaxadas e requisitos de atestação mais leves. Os CTOs que constroem para a versão high-bar acabam com infraestrutura que funciona para a versão mid-bar automaticamente. Construir só para mid-bar tipicamente requer um rebuild quando a barra se move.

A barra está a mover-se. A finança é apenas um dos primeiros a mover-se.

Fonte: Fradelos, G. Finance-Grade Assurance for Agentic AI: Verifiable Governance, Systemic Risk Mitigation, and Sustainability/Compute Accounting Architecture for banks, insurers, and major financial services providers (Genebra, 11 de janeiro de 2026). SSRN 6306980.

A entregar IA agêntica num ambiente regulado e precisas de capacidade de engenharia que já constrói com atestação, evidence packets e deployment consciente da heterogeneidade? Fala com um CTO sobre desplegar um squad nearshore com a disciplina que o trabalho finance-grade requer.