O Que É Preciso Para Rodar Agentes de IA em um Ambiente Regulado

A maioria das demonstrações de agentes de IA termina onde a parte difícil começa. Um agente que lê um chamado, escreve um trecho de código e publica um resumo parece pronto em um vídeo de cinco minutos. Coloque esse mesmo agente dentro de uma empresa regulada de serviços financeiros e as perguntas mudam. Quem aprovou aquela ação? Onde está o registro? O que impede que ele faça a mesma coisa errada mil vezes antes de alguém perceber? Em um ambiente regulado, o modelo é a parte fácil. Os controles em volta dele são o trabalho.

Construímos agentes de IA que rodam em produção para empresas reguladas, então vivemos dentro dessas perguntas. Este texto apresenta o que aprendemos sobre a diferença entre um agente que demonstra e um agente que a sua área de compliance vai aprovar.

O que um agente em produção realmente é

Um agente em produção em um contexto regulado é um software que recebe uma instrução, decide uma ou mais ações e as executa contra sistemas reais. Ele pode triar uma fila de suporte, conciliar um razão, redigir uma comunicação regulada ou avançar um fluxo de entrega. A característica que o define é que ele age. Não é um chatbot que responde a uma pergunta e para. É exatamente por isso que um regulador, um auditor ou um conselho vão tratá-lo como um sistema que precisa de governança, e não como um gadget de produtividade.

Assim que um agente passa a agir, a empresa herda a responsabilidade por cada ação que ele toma. O Senior Managers and Certification Regime (SM&CR, o regime britânico de responsabilização de gestores) não tem exceção para software que tomou a decisão. Uma pessoa nomeada continua sendo dona do resultado. Então a pergunta prática para qualquer agente não é o quão inteligente ele é. É se a empresa consegue explicar, evidenciar e controlar o que ele faz.

Trilhas de auditoria: se não foi registrado, não aconteceu

A primeira coisa que construímos em um agente é o seu registro. Cada passo relevante é logado: a entrada que ele recebeu, o contexto que ele recuperou, a ação que ele escolheu, a ação que ele tomou e o resultado. Não uma anotação em texto livre depois do fato. Um registro estruturado, com data e hora, somente de acréscimo, que mapeia um para um o que aconteceu.

Projetamos esses registros para que um revisor consiga reconstruir uma única decisão de ponta a ponta sem ler o código. Isso significa capturar:

• O prompt exato e os dados que o agente viu, com dados pessoais tratados sob as regras de retenção da empresa.
• Qual modelo e versão produziram a saída, para que o comportamento possa ser amarrado a uma configuração específica.
• A saída validada com base na qual o agente agiu, separada do texto bruto do modelo.
• O efeito a jusante: a API chamada, o registro alterado, a mensagem enviada.

Tratamos a saída do modelo como não confiável até que ela seja validada. Em nossos próprios sistemas, as saídas dos agentes são analisadas contra um schema estrito antes que qualquer coisa chegue à lógica de negócio, então uma resposta malformada ou inesperada é rejeitada em vez de servir de base para uma ação. O passo de validação também é um ponto de controle: é onde o registro é escrito e onde uma saída ruim é interceptada.

Humano no circuito, posicionado onde importa

Supervisão humana não é um slogan. É um conjunto de decisões sobre quais ações um agente pode concluir sozinho e quais exigem que uma pessoa aprove antes que algo aconteça. A habilidade está em colocar o portão no lugar certo. Coloque um portão em tudo e você reconstruiu um processo manual com passos a mais. Não coloque portão em nada e você colocou um sistema sem supervisão dentro de uma empresa regulada.

Mapeamos cada ação que um agente pode tomar para um nível de risco e então ajustamos a supervisão para corresponder. Ações de baixo risco e reversíveis rodam sozinhas, com o registro disponível para revisão depois do fato. Ações que movimentam dinheiro, tocam um cliente ou alteram um registro regulado param em um checkpoint e esperam por uma pessoa. O Hermes, nosso sistema multiagente de codificação, segue esse padrão: ele planeja, escreve e testa software sozinho, mas uma pessoa aprova em portões de decisão definidos antes que as mudanças avancem. Os agentes fazem o trabalho; os portões mantêm um humano responsável pelo resultado.

Controle de mudanças para sistemas que mudam a si mesmos

Empresas reguladas já têm controle de mudanças para software: revisão, testes, aprovação e um registro do que foi entregue e quando. Os agentes esticam essa disciplina porque aquilo que governa o comportamento deles não é só o código. São também os prompts, as ferramentas que eles podem chamar, a versão do modelo e as políticas que decidem o que eles podem fazer sem supervisão.

Colocamos tudo isso sob o mesmo controle do código. Uma mudança de prompt passa por revisão. Uma nova ferramenta que um agente pode chamar é uma adição revisada, não uma edição silenciosa. Uma atualização de modelo é uma mudança versionada que é testada antes de chegar à produção, porque um modelo mais novo pode deslocar o comportamento mesmo quando nada mais mudou. O ponto é simples: se uma mudança pode alterar o que o agente faz, ela recebe o mesmo escrutínio de uma mudança no código, com o mesmo registro.

Os Scrum Master Agents, que rodamos dentro de uma insuretech regulada, atuam ao lado de times de engenharia humanos e gerenciam fluxos de entrega. Tratar a configuração deles como mudança controlada é o que permite que operem ao lado de pessoas em um contexto regulado, em vez de como um experimento isolado num canto.

Diligência de fornecedores: você responde por aquilo de que depende

Quase todo agente depende de um provedor de modelo, e esse provedor é um terceiro sujeito às obrigações de terceirização e de resiliência operacional da empresa. Escolher um modelo é uma decisão de aquisição com diligência associada, não um padrão num arquivo de configuração.

Quando selecionamos um provedor, olhamos onde os dados são processados, o que o provedor pode fazer com os prompts e as saídas, os termos de residência e retenção de dados e como a empresa seguiria operando se esse provedor tivesse uma indisponibilidade ou mudasse seus termos. Projetamos para que um modelo possa ser trocado sem reescrever o sistema: uma camada de provedor compartilhada, saídas validadas que não dependem das manias de um modelo específico, e registros de custo e uso por chamada para que a empresa possa ver quanto está gastando antes de a fatura chegar. Isso é tanto um requisito de resiliência quanto um requisito comercial.

Como abordamos o problema

Nosso ponto de partida é que os controles vêm primeiro e o agente é construído para se encaixar neles. Acordamos quais ações estão no escopo, o que cada uma pode fazer sem supervisão e onde uma pessoa precisa aprovar. Construímos o registro antes de construir o comportamento, para que nunca exista uma ação pela qual a empresa não consiga responder. Validamos cada saída, versionamos cada mudança e mantemos o modelo como uma dependência substituível, não como um alicerce.

Um agente que demonstra responde a uma pergunta: ele consegue fazer a tarefa? Um agente que entra em produção em uma empresa regulada responde a uma mais difícil: você consegue comprovar, controlar e responder por tudo o que ele fez?

Nada disso torna os agentes mais lentos de construir de nenhuma forma que importe. Torna-os o tipo de sistema que uma empresa regulada realmente consegue operar, porque a trilha de auditoria, a supervisão e o controle de mudanças fazem parte do projeto, em vez de serem algo acoplado quando uma revisão chega. Essa é a diferença entre um protótipo inteligente e um software que você pode colocar diante de um auditor.