Como implementar IA na empresa, entre construir, comprar e customizar

A decisão chega em três versões. O time técnico quer construir, porque conhece o negócio e já tem a infraestrutura. O financeiro quer comprar, porque tem preço fechado. E alguém sempre sugere começar com uma ferramenta barata para testar, que é a versão disfarçada de não decidir.

As três escolhas têm custo, prazo e risco diferentes, e a diferença entre elas não é ideológica. Este artigo compara os três caminhos, mostra como escolher o primeiro processo e lista o que exigir de qualquer fornecedor antes de assinar.

Quais são os três caminhos?

Comprar é assinar uma ferramenta pronta, genérica, que resolve um pedaço do trabalho para qualquer empresa. Construir é montar com time interno, do zero, em cima da infraestrutura que a empresa já tem. Customizar é usar uma camada pronta e desenhar em cima dela os agentes que seguem o processo daquela empresa.

O dado que mais pesa nessa escolha vem do estudo do MIT NANDA. Segundo a leitura publicada pelo VentureBeat em agosto de 2025, parceria com fornecedor externo chegou a 67% de sucesso na implantação, contra 33% de quem construiu por dentro. É o dobro, e a diferença não está na qualidade do time técnico. Está no tempo que ele leva reconstruindo o que já existe pronto.

Como escolher o primeiro processo?

Três critérios, e todos precisam ser verdade ao mesmo tempo. O processo precisa ter dono, alguém que responde pelo número hoje. Precisa ter volume, porque ganho em tarefa rara não aparece em trimestre. E precisa ter um número que já é acompanhado, senão a comparação vira discussão.

O erro clássico é escolher pelo entusiasmo, não pelo critério. A área que mais quer testar costuma ser a que tem mais tempo livre, que é a que tem menos gargalo. Comece pelo processo que dói, mesmo que a área esteja ocupada demais para conversar sobre ele.

O outro erro é começar por doze. O KPMG Global Tech Report 2026, com 2.500 executivos de tecnologia de 27 países e 150 líderes brasileiros, encontrou 45% deles com vários projetos de IA rodando de maneira desconectada. Doze pilotos pequenos consomem o mesmo orçamento de um projeto sério e não produzem nenhuma evidência.

Como comparar dois fornecedores sem cair na demonstração

Toda demonstração funciona, porque ela é montada com um caso que funciona. O jeito de sair desse teatro é levar o seu material: pegue cinco casos reais da sua operação, com os defeitos que eles têm, e peça para cada fornecedor rodar os mesmos cinco.

Escolha os cinco com critério: dois casos comuns, dois casos chatos e um caso que costuma dar errado. O acerto no caso fácil interessa pouco. O que decide é o comportamento no caso difícil. Fornecedor que erra e avisa que errou vale mais que fornecedor que erra com confiança.

Compare três coisas ao final: quanto trabalho humano sobrou em cada caso, quanto tempo levou para configurar o agente para o seu processo, e o que aconteceu quando você pediu uma mudança de regra no meio do teste. A terceira é a que mais separa os candidatos, porque o seu processo vai mudar.

E uma pergunta final que costuma ser reveladora. Peça para o fornecedor descrever um caso em que a solução dele não seria a indicada. Quem não tem essa resposta não conhece os limites do próprio produto, e você vai descobrir esses limites sozinho, depois de assinar.

O que exigir de qualquer fornecedor

1. Onde o agente vai morar. Se a resposta for uma tela nova, pergunte como o time vai lembrar de abrir essa tela na terça-feira cheia.
2. O que acontece com o contexto. Onde fica o que foi combinado, quem tem acesso, e o que sobra registrado de cada ação.
3. O que ele executa sozinho e o que ele leva para aprovação. Tudo que vira promessa ao cliente precisa passar por uma pessoa.
4. Qual número muda e em quanto tempo. Fornecedor que não pergunta a sua linha de base vai entregar uma demonstração, não um resultado.
5. O que acontece quando o processo mudar em seis meses. É a pergunta que separa parceiro de licença.
6. Como é a saída. Que dados você leva embora, em qual formato, e em quanto tempo.

Os quatro erros que matam a implantação

Eles aparecem sempre nos mesmos lugares, e nenhum deles é técnico.

1. Começar pela área que tem tempo, não pela que tem gargalo. A área com agenda livre costuma ser a que menos precisa, e o piloto prova pouco.
2. Não medir antes. Sem linha de base, o resultado vira discussão entre quem gostou e quem não gostou da ferramenta, e a decisão seguinte é política.
3. Colocar o agente em uma tela nova. O time precisa lembrar de abrir, e no terceiro mês não lembra mais. Onde o trabalho já acontece é o único lugar que sobrevive à rotina.
4. Automatizar a exceção. A tentação é resolver o caso difícil primeiro, porque ele dói mais. O caso difícil é o que precisa de gente, e ele consome todo o prazo do projeto.

Existe um quinto, mais silencioso. Não combinar o que acontece quando o agente errar. Todo projeto vai ter um erro visível nas primeiras semanas. Se não estiver combinado quem corrige, em quanto tempo e quem comunica o cliente, o primeiro erro vira motivo para desligar tudo.

O que muda quando o processo muda

Essa é a diferença mais cara entre os três caminhos, e ela só aparece no sexto mês. Processo de empresa muda: entra um cliente grande com regra própria, muda a legislação do setor, a área é reorganizada. A pergunta não é se vai mudar. É quanto vai custar quando mudar.

Na ferramenta pronta, você não muda nada. Adapta o seu processo ao que ela faz, ou para de usar. Na construção interna, a mudança entra na fila do time técnico, atrás do roadmap de produto. Na camada customizada, é ajuste de regra, e o prazo é de dias.

Vale perguntar isso ao fornecedor com um caso concreto seu, não em abstrato. Descreva uma mudança que aconteceu de verdade no último ano e peça para ele dizer o que teria sido preciso fazer. A resposta separa quem conhece o próprio produto de quem conhece a demonstração dele.

Quem precisa estar na sala

Três papéis, e a falta de qualquer um explica a maior parte dos projetos que não saem do lugar. O primeiro é o dono do processo, que responde pelo número e decide a regra quando houver dúvida. Sem ele, cada exceção vira uma reunião.

O segundo é quem executa a tarefa hoje. É essa pessoa que conhece as exceções que não estão escritas em lugar nenhum, e é ela que vai usar o que for construído. Projeto desenhado sem quem executa produz um fluxo bonito que não sobrevive à primeira semana real.

O terceiro é quem responde por acesso e segurança. Ele não precisa estar em todas as conversas, precisa estar na primeira, para dizer o que pode ser conectado, com qual credencial e com qual registro. Descobrir a restrição no fim do piloto é a forma mais cara de descobrir.

Um erro comum de governança é montar um comitê de seis pessoas para decidir um piloto de quatro semanas. Comitê é útil para escolher o processo e para ler o resultado. No meio, ele transforma cada ajuste de regra em pauta de reunião quinzenal, e o piloto perde o prazo por decisão, não por tecnologia.

Como fica o piloto de 30 dias

Um piloto honesto tem quatro semanas e um formato previsível. Na primeira, mede-se a linha de base e escreve-se a regra do processo, que é o trabalho que a empresa nunca fez. Na segunda, o agente entra em paralelo: ele prepara, e o time continua fazendo como sempre fez, para comparar sem risco.

Na terceira semana o time passa a usar o que o agente preparou, corrigindo o que vier errado, e essas correções são o que ensina o desenho. Na quarta, mede-se de novo, com as mesmas medidas da primeira, na mesma semana do mês, e a decisão de seguir ou parar é tomada com os dois números lado a lado.

O que não cabe em quatro semanas: mudar dois processos, trocar sistema, redesenhar o fluxo inteiro da área. Se o escopo do piloto exige qualquer uma dessas três coisas, ele deixou de ser piloto e virou projeto, e precisa ser tratado como tal desde o começo.

Quando construir por dentro é a resposta certa

• Quando o processo é o produto. Se a IA vai dentro do que você vende, ela é engenharia de produto e não ferramenta de operação.
• Quando existe restrição regulatória que impede o dado de sair do seu ambiente, e isso está escrito em contrato com cliente.
• Quando o time técnico tem capacidade ociosa de verdade, não capacidade prometida para depois do próximo release.
• Quando o diferencial competitivo está no modelo, não no processo. É raro, e vale checar se é o seu caso antes de assumir que é.

Fora desses casos, o tempo do time técnico rende mais desenhando a regra do processo do que reconstruindo camada. E vale lembrar do contexto brasileiro. Segundo a 16ª edição da pesquisa TIC Empresas do Cetic.br, com coleta entre fevereiro de 2025 e janeiro de 2026, o uso de IA nas empresas brasileiras saiu de 13% para 17% em um ano. A maior parte do mercado está começando agora, e pode começar pelo caminho que já se mostrou mais curto.

Hendu LabsSeu processo precisa de um agente feito para a sua operação?A Hendu Labs mapeia o processo, define contexto, permissões e revisão humana e constrói agentes de IA conectados às ferramentas que sua equipe já usa.Falar com a Hendu LabsFalar com a Hendu Labs

Onde a Hendu entra

A Hendu é a terceira opção da tabela. Uma camada de contexto operacional pronta, com agentes desenhados sobre o processo que a empresa já tem. Ela se conecta aos sistemas e canais em uso, guarda o que foi combinado e executa enquanto a pessoa aprova o que tem consequência.

O trabalho começa pelo levantamento do processo e pela linha de base, que está detalhada em como calcular o ROI de IA. O Hendu Labs é o braço que entra na operação para desenhar os agentes, e os casos de uso por área mostram o formato de pré-vendas a cobrança.

Se a pergunta ainda é se vale a pena, por que projetos de IA falham tem os números do estudo do MIT com as ressalvas, e IA para CEO trata da decisão do ponto de vista de quem assina. A plataforma de inteligência artificial da Hendu explica a camada, e o hub IA nas empresas reúne o resto.