Agentes de IA ou automação: como escolher o primeiro projeto da empresa

A escolha começa pelo processo, não pela tecnologia

O primeiro projeto de IA deve ser escolhido pela estrutura do trabalho. Liste uma solicitação real, as entradas recebidas, as decisões necessárias, os sistemas consultados e o resultado esperado. Depois pergunte quantas exceções existem e se o caminho para chegar ao resultado pode ser descrito antecipadamente.

Automação é a melhor candidata quando as regras são explícitas, as entradas são estruturadas e cada saída pode ser validada por código. Um workflow com modelo de linguagem serve quando há texto variável, mas as etapas continuam conhecidas. Um agente faz sentido quando o sistema precisa decidir quais etapas executar, em que ordem, usando ferramentas e resultados intermediários para prosseguir.

A recomendação editorial é começar pela solução mais simples que possa ser medida. Sistemas agentivos costumam acrescentar latência, custo operacional e pontos de falha. A referência da Anthropic também separa workflows, guiados por caminhos predefinidos, de agentes, que direcionam dinamicamente seu próprio processo. Ela recomenda aumentar a complexidade apenas quando isso demonstrar uma melhora no resultado.

Fontes e referências: [1]

Árvore de decisão para o primeiro projeto

Use esta árvore antes de escolher uma plataforma ou um modelo. Ela transforma uma discussão abstrata em um diagnóstico de processo.

• 1. O trabalho pode ser descrito como regras do tipo se, então, com poucos casos ambíguos? Se sim, comece com automação tradicional, integrações, validações e filas. Se não, avance.
• 2. O trabalho tem etapas fixas, como classificar, extrair campos, consultar um sistema e redigir uma resposta? Se sim, implemente um workflow. O modelo pode interpretar a linguagem, mas o código controla a sequência.
• 3. As categorias são claramente separadas e cada uma possui instruções ou ferramentas próprias? Se sim, use roteamento para encaminhar a solicitação a um fluxo especializado. Não transforme cada categoria em um agente separado sem evidência de que isso melhora o resultado.
• 4. A quantidade ou a ordem das etapas depende do conteúdo de cada solicitação? Se sim, considere um agente com ferramentas limitadas. Exija condições de parada, limites de iteração e registros das decisões.
• 5. O sistema pode alterar dados, enviar mensagens, conceder crédito, cancelar pedidos ou executar outra ação irreversível? Se sim, trate isso como um projeto de controle, não apenas de geração de texto. Separe leitura de escrita, valide argumentos e exija confirmação ou autorização no ponto de ação.
• 6. Você consegue definir o que significa resolver o caso? Se não, adie o projeto ou reduza seu escopo. Sem um resultado observável, fica difícil saber se a autonomia acrescentou valor ou apenas complexidade.

Fontes e referências: [1][3]

Exemplo hipotético: triagem de solicitações internas

Imagine uma empresa que recebe solicitações pelo e-mail e por um portal interno. Os pedidos incluem acesso a sistemas, dúvidas sobre reembolso, falhas técnicas e alterações cadastrais. O objetivo inicial não é responder tudo automaticamente. É identificar a categoria, extrair dados úteis, encaminhar ao time correto e informar ao solicitante o próximo passo.

A primeira versão recomendada seria um workflow. Um modelo classifica a solicitação em acesso, financeiro, suporte técnico, cadastro ou indefinida. Em seguida, outro passo extrai campos estruturados, como identificador do colaborador, sistema afetado, prazo e número do chamado. O código valida formatos, consulta regras existentes e envia o caso para a fila correspondente. Se a categoria for indefinida, faltar um campo obrigatório ou houver conflito entre os dados, o sistema encaminha para uma fila de exceção, sem tentar adivinhar.

Exemplo de entrada: “Preciso recuperar o acesso ao sistema de compras. Meu usuário é ana.silva e isso precisa estar resolvido antes do fechamento de hoje.” A saída estruturada poderia ser categoria acesso, sistema compras, usuário ana.silva, urgência solicitada hoje e ação abrir chamado de acesso. A resposta ao usuário apenas confirma o recebimento e o encaminhamento. Ela não concede acesso nem altera permissões.

Esse caso não exige um agente no início porque as etapas são conhecidas. Um agente poderia ser considerado mais tarde se solicitações complexas exigissem consultar vários sistemas, descobrir quais informações faltam, comparar políticas e escolher uma sequência variável de consultas. Mesmo nesse cenário, as ferramentas deveriam ser estreitas, com argumentos validados e permissões mínimas.

Fontes e referências: [1][3]

Quando promover o workflow a agente

A promoção deve ser uma decisão baseada em casos observados, não em uma preferência arquitetural. Colete solicitações representativas, inclusive textos curtos, erros de digitação, múltiplas intenções, anexos e pedidos que misturam assuntos. Registre onde o workflow falha: classificação ambígua, falta de dados, consulta insuficiente ou necessidade de uma ordem variável de ações.

Um agente é justificável quando o caminho não pode ser antecipado sem criar uma grande árvore de regras e quando existe feedback verificável a cada etapa. Por exemplo, uma ferramenta retorna que o sistema consultado está indisponível, então o agente tenta uma fonte autorizada alternativa ou interrompe o caso com uma explicação. Isso é diferente de permitir que o modelo improvise ações sem observação do ambiente.

Mantenha o agente pequeno. Dê acesso somente às ferramentas necessárias, descreva com precisão seus parâmetros, inclua exemplos de entradas válidas e torne operações perigosas difíceis de chamar por engano. Textos externos, como mensagens recebidas, podem conter instruções maliciosas. Dados não confiáveis devem ser isolados, transformados em campos estruturados quando possível e impedidos de controlar diretamente ferramentas privilegiadas.

Fontes e referências: [1][3]

Como avaliar antes de colocar em produção

Não avalie o projeto com a impressão de que as respostas parecem boas. Monte um conjunto de casos históricos ou sintéticos que represente o tráfego esperado. Inclua exemplos normais, fronteiras entre categorias, solicitações incompletas, múltiplas intenções, tentativas de induzir o sistema ao erro e retornos inesperados das ferramentas.

Para a triagem hipotética, meça pelo menos: categoria correta, extração correta dos campos, fila escolhida, ausência de ação indevida, tratamento de dados ausentes e clareza da mensagem enviada. Em um agente, acrescente seleção da ferramenta, precisão dos argumentos, número de etapas, respeito aos limites e encerramento apropriado. A orientação de avaliação da OpenAI recomenda testes específicos para a tarefa, registro dos casos e avaliação contínua a cada mudança.

Compare também o custo da falha. Errar a fila de uma dúvida comum não tem o mesmo impacto que liberar acesso, alterar cadastro ou enviar dados privados. A arquitetura inicial deve ser mais conservadora onde a consequência for maior. Um bom teste pode exigir que o sistema devolva “não classificado” em vez de produzir uma decisão confiante sem base.

Fontes e referências: [2]

Checklist de decisão e implementação

Use este checklist em uma reunião de escopo. Se várias respostas forem negativas, reduza o projeto antes de adicionar autonomia.

• Definir uma única solicitação ou família estreita de solicitações.
• Descrever o resultado esperado em termos observáveis.
• Separar tarefas de leitura, classificação, consulta e escrita.
• Verificar se as etapas são fixas ou se realmente dependem do caso.
• Escolher automação, workflow ou agente com base nessa diferença.
• Definir categorias, campos obrigatórios, estados de exceção e condições de parada.
• Limitar ferramentas por função e validar todos os argumentos antes da execução.

Perguntas que evitam um primeiro projeto ruim

O processo precisa interpretar linguagem ou apenas transportar dados entre sistemas? Se a resposta for transporte de dados, uma integração convencional provavelmente é suficiente.

Qual é a ação mais grave que o sistema poderia executar por engano? Essa resposta define permissões, confirmações, testes e o limite de autonomia.

Que evidência mostrará que a nova versão é melhor que a atual? Se não houver métrica, casos de teste ou critério de encerramento, o projeto ainda não está pronto para implementação.