IA Agentic na empresa: como equilibrar autonomia com restrições

As equipes empresariais estão migrando de assistentes baseados em chat para sistemas que podem realizar ações. Vejo a mudança na forma como as pessoas descrevem o trabalho. Eles pedem um assistente que possa escrever código, arquivar tickets, atualizar registros de CRM, executar uma lista de verificação de conformidade, gerar uma solicitação pull e seguir para a próxima etapa. Essa forma de trabalho requer um sistema de agentes.

Defino um sistema agente como um software que transforma um objetivo do usuário em uma sequência de etapas, executa essas etapas por meio de ferramentas, acompanha o que aconteceu e produz um resultado auditável. O modelo contribui com planejamento e linguagem. O sistema circundante fornece autoridade, estado, verificação e controle.

(Veja também: “Como executar GenAI empresarial como um serviço de produção”)

A questão da engenharia permanece consistente em todos os domínios. Como você dá ao sistema autonomia suficiente para ser útil e, ao mesmo tempo, mantém os resultados previsíveis? Uma resposta de produção vem de restrições explícitas e impostas.

Defina o loop do agente

Um loop de agente é o ciclo repetido que o sistema segue para concluir o trabalho. Eu uso um loop simples e torno cada estágio observável.

1. Planejar: O agente escolhe a próxima ação com base na meta, no estado atual e na política.
2. Agir: O agente chama uma ferramenta com argumentos estruturados e depois registra o resultado.
3. Verificar: O sistema verifica o resultado em relação às expectativas da política e da tarefa.
4. Confirmar: o sistema grava a mudança de estado em um armazenamento durável e produz um evento de auditoria.

Essas palavras carregam significados específicos na implementação. O planejamento produz uma intenção estruturada. A ação usa uma interface limitada com um esquema definido. A verificação executa verificações determinísticas. Commit grava o estado versionado e o contexto de rastreamento.

Definir ferramentas e contratos de ferramentas

Uma ferramenta é qualquer recurso que pode ser chamado fora do modelo. Pode ser uma API, uma consulta de banco de dados, um mecanismo de fluxo de trabalho, uma ação de repositório de código ou uma etapa de automação do navegador. O uso de ferramentas domina o risco operacional porque as ferramentas podem alterar os sistemas de registro.

Um contrato de ferramenta é o limite que torna o uso da ferramenta seguro para operação. Eu escrevo isso como parte da revisão do design. Um contrato inclui o seguinte:

• Entradas: um esquema que rejeita parâmetros de formato livre e impõe tipos.
• Permissões: o contexto de identidade, os escopos e os limites dos dados.
• Idempotência: uma chave de solicitação e uma regra de repetição para que novas tentativas não criem alterações duplicadas.
• Limites de taxa: por usuário, por agente e por ferramenta para proteger sistemas compartilhados.
• Semântica de erro: códigos de erro estáveis ​​e orientação para novas tentativas.
• Campos de auditoria: ID da solicitação, ator, horário, registro de destino e referências antes/depois.

Este contrato transforma um agente em um cliente regular de sistema distribuído. Torna-se testável. Torna-se depurável. Torna-se algo que uma equipe de operações pode possuir.

Definir política como regras executáveis

Política em um sistema agente significa regras que o tempo de execução impõe em cada etapa. Eu trato a política como um módulo executável. Ele fica no caminho da solicitação. Está versionado. Emite um evento de auditoria nas decisões.

Os domínios de política comuns incluem acesso a dados, listas de permissões de ferramentas, destinos aprovados para gravações, citações obrigatórias para material recuperado e regras de recusa para solicitações restritas. A política começa simples e cresce com base no aprendizado de incidentes.

Trate o estado como um componente de primeira classe

Estado é o registro durável do que o agente sabe e do que fez. Eu mantenho o estado fora do modelo. Eu persisto com um esquema claro. Eu versão por etapa.

Eu armazeno pelo menos a meta, as etapas do plano, as entradas e saídas da ferramenta, os resultados da verificação e a decisão final. Também armazeno as fontes recuperadas quando a recuperação faz parte do loop. Este estado oferece suporte à reprodução durante incidentes e à avaliação posterior.

As equipes que mantêm o estado apenas em um buffer de conversa perdem a capacidade de raciocinar sobre o comportamento em grande escala. Um armazenamento de estado durável oferece suporte a novas tentativas, transferências e relatórios de governança.

Use a verificação como uma porta de entrada para a ação

A verificação é um conjunto de verificações executadas antes de uma gravação e depois de uma chamada de ferramenta. Eu uso verificações determinísticas sempre que possível. Trato a saída do modelo como uma entrada a ser validada.

Os exemplos incluem validação de esquema, verificações de permissão, verificações de integridade de referência e restrições em sistemas de destino. Para fluxos de trabalho de conteúdo, a verificação inclui cobertura de citações e verificações de dados restritos.

Também utilizo uma política de confiança para ações de alto impacto. O sistema pode exigir uma etapa de aprovação humana para determinadas ferramentas ou destinos. A aprovação funciona melhor quando tem um escopo restrito a uma ação clara, com contexto e evidências.

Construa um sistema de avaliação em torno do ciclo

A avaliação para agentes concentra-se na conclusão da tarefa de ponta a ponta e nas propriedades de segurança. Defino os critérios de sucesso da tarefa como fatos observáveis. O bilhete existe. O registro foi atualizado com os campos corretos. A solicitação pull passa nas verificações. A solicitação de mudança tem as aprovações corretas.

Eu crio conjuntos de cenários que cobrem tarefas rotineiras e casos extremos. Eu os executo com sementes fixas sempre que possível e com simulações de ferramentas estáveis. Também executo um pequeno conjunto de testes ao vivo em um ambiente de teste com dados realistas.

Eu acompanho métricas que se conectam às operações. Taxa de conclusão de tarefas por cenário. Média de etapas por tarefa. Taxa de erro da ferramenta. Taxa de falha de verificação. Taxa de aprovação humana. Tempo médio de recuperação quando uma ferramenta retorna resultados parciais.

Um padrão de referência prático

Eu construo agentes de produção com padrão de supervisor. Um supervisor possui política, roteamento e estado. Trabalhadores especializados lidam com tarefas restritas, como recuperação, resumo de um ticket ou ação de repositório. Os trabalhadores funcionam com as permissões mínimas exigidas para seu contrato.

Um esboço simplificado fica assim:

def run_task(goal, user):
    ctx = start_context(goal, user)
    while ctx.open_steps:
        intent = planner.propose_next(ctx)
        intent = policy.enforce_intent(intent, ctx)
        call = tool_router.bind(intent, ctx)
        result = call.execute(idempotency_key=ctx.step_key)
        checks = verifier.run(intent, result, ctx)
        ctx = commit_step(ctx, intent, result, checks)
        if checks.requires_approval:
            ctx = wait_for_approval(ctx)
    return ctx.outcome

Essa estrutura mantém a autoridade no supervisor. Ele mantém as permissões da ferramenta restritas. Ele oferece às equipes de operações um local único para aplicar políticas e observar comportamentos.

Práticas operacionais que mantêm os agentes estáveis

Eu uso um pequeno conjunto de práticas quando as equipes desejam que os agentes operem com segurança na produção.

• Comece com fluxos de trabalho com raio de explosão baixo. Tarefas de leitura pesada e geração de rascunhos criam confiança e instrumentação.
• Envie com uma lista de permissões de ferramentas limitada. Expanda com base nos resultados medidos e na aprendizagem de incidentes.
• Use lançamentos graduais. Comece com usuários internos, depois com um pequeno grupo e depois com uma exposição mais ampla.
• Mantenha os esquemas de ferramentas rigorosos. Parâmetros de ferramenta de formato livre criam gravações imprevisíveis.
• Defina orçamentos. Imponha o máximo de etapas por tarefa, o máximo de chamadas de ferramentas e um teto de custo.
• Manter runbooks. Inclui reversão, desativação de switches por ferramenta e rotas de escalonamento para humanos.

Lista de verificação mínima viável

Procuro esses elementos antes que uma equipe execute fluxos de trabalho de agente em grande escala.

• Uma definição escrita do loop do agente, com rastreamentos em cada estágio.
• Contratos de ferramentas com esquemas, permissões, idempotência, limites de taxa e campos de auditoria.
• Módulo de política com controle de versão e aplicação no caminho da solicitação.
• Armazenamento de estado durável com registros em etapas para reprodução e relatórios de governança.
• Portas de verificação em gravações e ações de alto impacto.
• Conjunto de avaliação que mede a conclusão da tarefa e as propriedades de segurança.
• Controles operacionais, incluindo orçamentos, implementação gradual e opções de desativação por ferramenta.

Restrições são fundamentais

Os sistemas agentes são adequados ao trabalho empresarial porque conectam interfaces de linguagem aos sistemas de negócios. Os sistemas funcionam bem quando a autonomia está dentro de restrições explícitas. As restrições transformam o comportamento do agente em algo que as equipes podem medir, melhorar e confiar.

–

Fórum de Nova Tecnologia oferece um local para líderes de tecnologia — incluindo fornecedores e outros colaboradores externos — explorarem e discutirem tecnologias empresariais emergentes com profundidade e amplitude sem precedentes. A seleção é subjetiva, baseada na escolha das tecnologias que acreditamos serem importantes e de maior interesse para os leitores do InfoWorld. A InfoWorld não aceita material de marketing para publicação e reserva-se o direito de editar todo o conteúdo contribuído. Enviar tudo consultas para [email protected].