Construir ou contratar agentes de IA: a conta completa, depois do lançamento

O protótipo é a parte barata

Montar um agente que funciona numa demonstração ficou fácil. Existem frameworks abertos, exemplos prontos e modelos acessíveis por API. Um desenvolvedor curioso consegue, em poucos dias, um agente que lê um e-mail, consulta uma planilha e responde com algo sensato.

O problema é que a demonstração acontece em condições ideais. Os dados vêm limpos, ninguém manda um anexo corrompido, o sistema de gestão não está fora do ar e o cliente não escreve em três mensagens picotadas. Em produção, tudo isso acontece toda semana.

Por isso, comparar o custo de construir com o custo de contratar olhando só para o desenvolvimento inicial leva a uma decisão torta. O desenvolvimento costuma ser a menor fatia do custo total de um agente ao longo de um ano.

Os custos que ficam fora da planilha

Quando a empresa decide construir internamente, quatro custos costumam aparecer depois e raramente estavam no orçamento:

• Sustentação. Integrações mudam. A API do ERP ganha uma versão nova, o fornecedor de WhatsApp altera uma regra, o modelo de IA é descontinuado. Alguém precisa acompanhar e ajustar, sem prazo para acabar.
• Monitoramento. Um agente pode falhar sem dar erro. Ele responde, só que responde errado. Perceber isso exige registros, alertas e alguém olhando para eles com frequência.
• Auditoria. Se o agente aprovou um desconto, cancelou um pedido ou respondeu a um paciente, você precisa saber por quê. Isso pede histórico de decisões guardado de forma consultável, com atenção à LGPD quando há dados pessoais no caminho.
• Conhecimento concentrado. Muitas vezes o agente fica na cabeça de uma ou duas pessoas. Se elas saem ou mudam de função, o agente vira uma caixa-preta que ninguém tem coragem de mexer.

Nenhum desses custos é motivo para não construir. São motivos para colocar tudo na conta antes de decidir.

Quem responde quando quebra

Esta é a pergunta que mais diferencia os dois caminhos. Imagine uma operação de atendimento em que o agente para de responder numa sexta à noite porque um certificado expirou. Quem recebe o alerta? Quem tem acesso para corrigir? Quem avisa a equipe que vai precisar atender manualmente até segunda?

No modelo interno, a resposta precisa existir antes do lançamento: escala de plantão, documentação de como reiniciar cada peça, permissões de acesso definidas. Se a resposta for "o fulano que montou", você tem um risco operacional com nome e sobrenome.

No modelo contratado, a resposta precisa estar no contrato. Prazo de resposta, horário coberto, o que conta como incidente, como a comunicação acontece. Contratar quem constrói e não definir quem sustenta só troca o problema de lugar.

A pergunta certa é menos "quem constrói?" e mais "quem acorda quando o agente para?".

Quando construir internamente faz sentido

Há cenários em que construir com time próprio é a melhor escolha. Alguns sinais:

• Você já tem um time de engenharia com folga real, que não vai abandonar o agente na primeira prioridade nova do trimestre.
• O agente é parte central do seu produto e não só da sua operação interna. Nesse caso, o conhecimento precisa ficar dentro de casa.
• Existe gente com experiência em colocar sistemas em produção, com monitoramento, testes e controle de versão, e não só em escrever código.
• A empresa aceita investir algumas semanas em estrutura antes de ver o primeiro agente funcionando.

Se os quatro sinais estão presentes, construir costuma compensar. Se faltam dois ou mais, vale olhar com cuidado para o outro lado.

Quando contratar faz mais sentido

Contratar quem constrói e mantém tende a ser o melhor caminho quando o agente serve à operação: atendimento, financeiro, comercial, jurídico, logística, ou qualquer área com tarefa que se repete. Nesses casos, o que importa é o agente funcionando e alguém responsável por ele, não a propriedade do código.

Também faz sentido quando a empresa quer testar vários agentes em áreas diferentes antes de decidir onde investir mais. Um parceiro que já fez integrações parecidas encurta o caminho e evita erros que custam caro na primeira vez.

Para não trocar dependência técnica por dependência de fornecedor, algumas perguntas ajudam na hora de avaliar:

• O código, os prompts e as configurações ficam com a empresa ou com o fornecedor? E se o contrato acabar?
• Os registros de decisão do agente ficam acessíveis para o seu time, ou só por pedido?
• Como funciona a troca de modelo de IA se o atual ficar caro ou for descontinuado?
• Quem aprova mudanças no comportamento do agente antes de irem para produção?
• Qual é o tempo de resposta para incidente e o que está coberto fora do horário comercial?

Um jeito prático de comparar

Para comparar os dois caminhos de forma honesta, monte uma tabela simples com um horizonte de 12 a 24 meses. Em cada linha, coloque um item de custo. Em cada coluna, um caminho.

• Horas de desenvolvimento inicial, com o custo real da hora de quem vai fazer.
• Horas mensais de sustentação: ajustes, atualizações de integração, correções.
• Ferramentas de infraestrutura e monitoramento, incluindo armazenamento de registros.
• Custo de uso dos modelos de IA, que é parecido nos dois caminhos.
• Custo de oportunidade: o que o seu time deixa de fazer enquanto mantém o agente.
• Custo de uma parada: quanto custa para a operação ficar um dia sem o agente.

A última linha costuma mudar a conversa. Um agente que atende clientes ou processa pedidos tem custo de parada alto. Isso pesa a favor de quem tem estrutura para responder rápido, seja o seu time, seja um parceiro com compromisso formal.

Compare o custo de manter o agente por dois anos, não o custo de colocá-lo no ar.

O caminho híbrido

A escolha não precisa ser binária. Muitas empresas começam contratando a construção e a sustentação, aprendem com o primeiro agente em produção e, aos poucos, trazem parte do trabalho para dentro. Outras mantêm o time interno focado no produto e deixam os agentes da operação com um parceiro.

O que torna o caminho híbrido viável é a transparência desde o início: código acessível, documentação atualizada, registros que o seu time consegue ler. Com isso, a decisão de internalizar fica aberta para depois, quando você já tiver dados reais em vez de estimativas.