Bounded Autonomy for Enterprise AI: Typed Action Contracts and Consumer-Side Execution

Título: Autonomia Limitada para IA Empresarial: Contratos de Ação Tipados e Execução no Lado do Consumidor

Autores: Sarmad Sohail e Ghufran Haider

1. O Problema

O uso de Grandes Modelos de Linguagem (LLMs) como interfaces de linguagem natural para software empresarial está crescendo, mas sua utilização direta como operadores de sistemas permanece insegura.

• Riscos Críticos: Erros do modelo (alucinações, seleção de entidades erradas, argumentos malformados) podem propagar-se para ações não autorizadas, corrupção de dados, execução entre espaços de trabalho (cross-workspace) e falhas operacionais custosas.
• Falha das Abordagens Atuais: Muitas soluções dependem de prompting, monitoramento post hoc ou da suposição de que modelos mais fortes resolverão o problema. Essas abordagens deixam o modelo muito próximo da execução "crua" do backend.
• A Hipótese Central: A segurança da IA empresarial é primariamente um problema de arquitetura de execução, e não de qualidade do modelo. O objetivo não é a autonomia irrestrita, mas uma autonomia contida.

2. Metodologia e Arquitetura Proposta

Os autores propõem uma arquitetura chamada Bounded Autonomy Layer (BAL) (Camada de Autonomia Limitada). O princípio fundamental é que o modelo pode interpretar intenções e propor ações, mas toda a execução é mediada por contratos estritos.

Componentes Principais da Arquitetura:

1. Contratos de Ação Tipados (Typed Action Contracts):
   • As operações empresariais não são expostas como APIs brutas, mas como contratos estruturados contendo: esquema de entrada (JSON Schema), lógica de validação, requisitos de permissão, callbacks de execução e semântica de resultado.
   • O modelo só vê um "manifesto de ações" publicado e filtrado, não o backend inteiro.
2. Exposição de Capacidade Consciente de Permissão:
   • O BAL calcula dinamicamente o subconjunto de ações que o usuário atual tem permissão para executar, baseado no modelo de autorização real da aplicação. O planejador (LLM) só "vê" o que o usuário pode fazer.
3. Validação Antes de Efeitos Colaterais (Validation Before Side Effects):
   • Uma barreira de validação ocorre antes de qualquer mutação de dados. O sistema verifica campos obrigatórios, validação de domínio e integridade do esquema. Falhas retornam erros estruturados para auto-correção do modelo.
4. Execução no Lado do Consumidor (Consumer-Side Execution):
   • O BAL não tem acesso direto ao banco de dados ou serviços de backend. Ele roteia ações aprovadas através dos serviços e APIs do próprio aplicativo consumidor. Isso garante que as regras de negócio e limites de segurança existentes do aplicativo sejam mantidos.
5. Portões de Aprovação Humana (Human Approval Gates):
   • Fluxos de trabalho de alto impacto ou multi-etapa exigem confirmação explícita do usuário antes da execução, degradando a autonomia para execução supervisionada quando o risco é elevado.
6. Tratamento de Ambiguidade:
   • Se houver múltiplas entidades correspondentes (ex: três clientes chamados "John"), o sistema não adivinha. Ele retorna um estado de esclarecimento estruturado, forçando a desambiguação antes de qualquer mutação.

3. Contribuições Chave

1. Definição de Autonomia Limitada: Estabelece um regime operacional onde o modelo é um planejador/interpretador, mas não um operador direto de sistemas de backend.
2. BAL (Bounded Autonomy Layer): Uma camada de mediação portátil que qualquer aplicação empresarial pode integrar, impondo filtragem de permissões, validação tipada e governança de manifesto.
3. Implementação e Implantação: O design foi implementado e testado em uma aplicação empresarial multi-tenant real (CRM/Gestão de Clientes).
4. Avaliação Empírica Rigorosa: Comparação de três condições em 25 cenários de teste, demonstrando que a arquitetura previne danos organizacionais sem sacrificar a utilidade.

4. Resultados da Avaliação

A avaliação comparou três condições:

• A (Manual): Operador humano (baseline de segurança e velocidade).
• B (IA Desconstrita): O mesmo sistema com as camadas de segurança do BAL desativadas (apenas validação de backend nativa).
• C (Autonomia Limitada): O sistema completo com todas as camadas de segurança do BAL ativas.

Principais Métricas:

• Segurança (Execuções Inseguras):
  • Condição C (BAL Ativo): 0% de execuções inseguras. Todas as falhas foram contidas nas camadas do BAL (D1-D3).
  • Condição B (Sem BAL): 8% de execuções inseguras (2 de 25 tarefas). As falhas incluíam mutações em entidades erradas que escaparam de todas as verificações de backend do consumidor.
• Utilidade (Taxa de Conclusão de Tarefas):
  • Condição C: 92% (23/25 tarefas concluídas).
  • Condição B: 68% (17/25 tarefas concluídas).
  • Descoberta Contra-intuitiva: Remover as camadas de segurança reduziu a utilidade. O feedback estruturado do BAL (erros de validação detalhados) guiou o modelo a corrigir erros em menos tentativas. Sem o BAL, o modelo recebeu erros genéricos, alucinou sucesso ou falhou repetidamente.
• Velocidade:
  • Ambas as condições de IA foram 13x a 18x mais rápidas que a operação manual.
  • A Condição C foi ligeiramente mais lenta por ação (~6s vs ~4.5s) devido às verificações de segurança, mas a taxa de sucesso compensou o tempo.

Análise de Falhas Específicas:

• O BAL interceptou 100% das violações de permissão e isolamento de espaço de trabalho (garantias determinísticas).
• A camada de desambiguação do BAL foi crucial para prevenir mutações em entidades erradas, um tipo de falha que as verificações de backend do consumidor (que validam permissão e payload) não conseguem detectar, pois o payload era válido e o usuário tinha permissão, apenas a entidade alvo estava errada.

5. Significado e Conclusão

• Mudança de Paradigma: A segurança da IA empresarial deve ser tratada como um problema de arquitetura de execução, não apenas de alinhamento de modelo.
• Segurança e Utilidade não são Opostas: O estudo demonstra que restrições arquitetônicas (fricção intencional) podem aumentar a utilidade do sistema ao fornecer feedback estruturado que permite a auto-correção do modelo, em vez de erros genéricos que levam a loops de falha.
• Defesa em Profundidade: A arquitetura cria múltiplas camadas de segurança. O BAL atua como a primeira linha de defesa portátil, enquanto o aplicativo consumidor fornece uma segunda linha de defesa (backend). Juntas, elas garantem que falhas não se tornem danos organizacionais.
• Viabilidade Prática: A arquitetura é agnóstica ao modelo (funciona com diferentes LLMs) e pode ser integrada incrementalmente em sistemas existentes, transformando operações empresariais em contratos governáveis e auditáveis.

Em resumo, o artigo prova que é possível tornar modelos de linguagem imperfeitos operacionalmente úteis em sistemas empresariais críticos, contendo sua instabilidade através de contratos tipados e limites de execução rigorosos, sem sacrificar a eficiência ou a segurança.