Resumo Técnico: SARC – Um Framework de Governança por Arquitetura para Sistemas de IA Agêntica

1. Declaração do Problema

Sistemas de IA agêntica, que percebem, planejam e agem por meio de ferramentas e sub-agentes, estão entrando em ambientes regulamentados mais rapidamente do que a infraestrutura de governança amadureceu. Existe um desajuste estrutural crítico: as obrigações regulatórias (por exemplo, supervisão humana, gestão de riscos) são tipicamente avaliadas por meio de documentação post-hoc ou anexadas a prompts e painéis de controle. Isso cria um "desajuste estrutural" onde as restrições destinadas a limitar a execução são frequentemente avaliadas apenas após a ação ter ocorrido.

As abordagens atuais sofrem de modos de falha específicos:

• Guardrails de Prompt: Modelos podem ignorar, reinterpretar ou contornar instruções por meio de ferramentas.
• Filtragem de Saída: Não consegue capturar violações realizadas por meio de efeitos colaterais no mundo, em vez de texto visível.
• Auditoria Post-hoc: Documenta violações, mas não pode preveni-las.
• Regras de Fluxo de Trabalho: Frequentemente insuficientes em espaços de ação dinamicamente expansivos, a menos que vinculados a um registro completo e aplicados no despacho.

O artigo argumenta que os controles de governança devem passar de serem anexados a artefatos (prompts, logs) para serem anexados à execução dentro da arquitetura do sistema.

2. Metodologia: O Framework SARC

Os autores introduzem o SARC (Estado, Espaço de Ação, Recompensa, Restrições), um framework de governança por arquitetura. Embora $S$, $A$ e $R$ sejam primitivas padrão de Aprendizado por Reforço (RL), $C$ (Restrições) é a contribuição novel. Trata restrições como objetos de especificação de primeira classe, iguais ao estado e à recompensa, e as aplica em pontos declarados no tempo de execução do agente.

2.1 A Tupla de Especificação

Uma especificação SARC é definida como $\Sigma = \langle S, A, R, C \rangle$.

• Restrições ($C$): Particionadas em três classes:
  • $C_h$ (Duras): Violações não são permitidas sob nenhuma política.
  • $C_s$ (Suaves): Violações são admissíveis a um custo marginal declarado.
  • $C_e$ (Escalonamento): Condições que exigem transferência de controle para um operador humano.
• Estrutura da Restrição: Cada restrição $c \in C$ é uma quintupla $\langle src, class, pred, verif, resp \rangle$, onde:
  • $src$: Origem (regulatória, contratual, etc.).
  • $class$:$h$, $s$, ou $e$.
  • $pred$: Predicado sobre estado, ação e tempo.
  • $verif$: Mecanismo de verificação (pré-condição, monitor de tempo de execução, post-hoc).
  • $resp$: Protocolo de resposta (bloquear, registrar, escalar, abortar).

2.2 Arquitetura de Aplicação em Tempo de Execução

As restrições compilam-se em quatro locais de aplicação nomeados dentro do loop do agente:

1. Portão Pré-Ação (PAG): Avalia antes do despacho. Usado para restrições duras e escalonamentos preditivos decidíveis apenas a partir do estado e da ação.
2. Monitor no Tempo da Ação (ATM): Avalia durante a execução (por exemplo, envolvendo chamadas de ferramentas). Usado para restrições que dependem de saídas parciais (acumulação de custos, conteúdo em streaming).
3. Auditor Pós-Ação (PAA): Avalia após a conclusão. Usado para comparar o estado pós-ação com o estado pré-ação (deriva, verificação de efeitos colaterais).
4. Roteador de Escalonamento (ER): Roteia ações sinalizadas para operadores humanos com latência de fila limitada em relação à janela de reversibilidade da ação.

2.3 Extensão Multi-Agente

Para fluxos de trabalho multi-agente, o SARC introduz:

• Propagação de Restrições: As restrições herdam-se para baixo na cadeia de chamadas. Se uma restrição não for decidível na camada de um sub-agente, ela é avaliada na camada decidível mais profunda ("resgate de decidibilidade").
• Interseção de Autoridade: A autoridade é a interseção de todos os principais e agentes na cadeia de chamadas; é monotonicamente não crescente.
• Árvores de Rastreamento que Preservam Atribuição: O rastro de auditoria é uma árvore hierárquica, não uma sequência plana, preservando a cadeia completa de relações principal-agente para evitar a diluição da atribuição.

2.4 Propriedades Formais

• Limitação da Moldagem de Recompensa: O artigo fornece um contraexemplo formal (Proposição 1) mostrando que penalidades de recompensa finitas não podem geralmente garantir a satisfação de restrições duras para violações de baixa probabilidade e alto retorno. Assim, restrições duras devem ser predicados arquitetônicos, não termos de recompensa.
• Correspondência Especificação-Rastreamento: Um sistema é "conforme ao SARC" se satisfizer oito invariantes (por exemplo, admissibilidade pré-ação, derivação de rastreamento, completude da aplicação). Isso garante que, para cada ação em um rastreamento, um auditor possa verificar mecanicamente quais restrições se aplicaram e qual resposta foi tomada, sem acessar o modelo ou os prompts.

3. Contribuições Principais

1. Modelo de Especificação de Restrições: Um modelo tipado por classe ($\langle src, class, pred, verif, resp \rangle$) que é agnóstico à implementação, mas requer metadados específicos para executabilidade e auditabilidade.
2. Arquitetura de Aplicação no Loop do Agente: Uma disciplina que mapeia classes de restrições para pontos de aplicação específicos (PAG, ATM, PAA, ER), convertendo governança de documentação para controle de execução.
3. Auditabilidade Verificável: Uma definição formal de "auditable por construção" e um verificador protótipo que verifica rastros de tempo de execução contra especificações em tempo $O(|T| \cdot |C|)$.
4. Extensão Multi-Agente: Mecanismos para propagação de restrições, interseção de autoridade e árvores de rastreamento para lidar com topologias empresariais complexas.
5. Caminho de Compilação Regulatória: Um método para mapear cláusulas regulatórias (por exemplo, Artigo 14 do Ato de IA da UE) em predicados executáveis e verificações de tempo de execução.

4. Avaliação Empírica

Os autores conduziram uma avaliação sintética reproduzível em uma tarefa de compras ($H=1.000$ pedidos, 50 sementes), comparando o SARC contra quatro baselines: Auditoria Post-hoc, Filtragem de Saída, Regras de Fluxo de Trabalho e apenas Política como Código (PaC).

Resultados:

• Violações Duras: O SARC executou zero violações de restrições duras sob predicados exatos, igualando a baseline de Política como Código, mas superando a Filtragem de Saída e a Auditoria Post-hoc.
• Restrições Suaves: O SARC reduziu excessos da janela suave em 89,5% em comparação com a baseline apenas de Política como Código. Isso foi atribuído à colocação explícita de uma resposta de limitação de taxa no Auditor Pós-Ação (PAA), em vez de depender de desempenho intrínseco.
• Violações Residuais: Sob aplicação imperfeita (ruído de predicado ou falha de aplicação), as violações residuais escalonaram com o erro da pilha de aplicação ($\epsilon_{pred} + \epsilon_{exec}$) em vez da taxa de oportunidade de violação ambiental.
• Compromisso de Latência: O SARC incorreu em uma latência por etapa de ~21ms (vs. 0ms para post-hoc), demonstrando o custo explícito da governança em tempo de execução.

5. Significado e Alegações

O artigo posiciona o SARC não como uma garantia de segurança ou uma certificação de conformidade legal, mas como um substrato arquitetônico que torna as obrigações executáveis, inspecionáveis e auditáveis em tempo de execução.

• Mudança de Artefato para Execução: A contribuição principal é a mudança de anexar restrições a artefatos (prompts, logs) para anexá-las a caminhos de execução.
• Auditable por Construção: O SARC permite "auditable por construção", onde o rastro de auditoria é gerado pela adesão do sistema à sua especificação, em vez de ser reconstruído a partir de logs após o fato.
• Regime B: O framework é projetado para implantações do "Regime B" (regulamentadas, irreversíveis ou com perdas assimétricas) onde omitir o componente de restrição $C$ torna uma especificação incompleta.
• Clareza Econômica: Ao forçar a declaração explícita de pontos de operação e janelas de reversibilidade, o SARC torna as compensações entre falsos positivos, falsos negativos e capacidade do operador visíveis como decisões de alocação de capital.

Os autores concluem que o SARC não torna os sistemas seguros por si só; em vez disso, fornece a disciplina estrutural necessária para projetar segurança e conformidade, separando otimização ($R$), capacidade ($A$) e admissibilidade ($C$) para evitar que os sistemas falhem como anomalias não observáveis.