Implementação de IA em empresas: do piloto que morre ao sistema que roda na operação

Quase toda empresa média brasileira já passou pela mesma cena: alguém apresenta uma demonstração de IA na reunião de diretoria, todo mundo se impressiona, um piloto é aprovado, e seis meses depois ninguém sabe dizer o que aconteceu com aquilo. A tecnologia funcionou. O projeto não. A distância entre essas duas coisas é o assunto deste guia.

O livro Inteligência Artificial para Negócios trata do primeiro degrau: como uma pessoa usa IA bem em Vendas, Marketing, Financeiro, RH e Gestão, com o método CRIAR para escrever prompts que produzem resultado. Este artigo é o degrau seguinte, e ele é de outra natureza. Implementação não é uma questão de saber usar a ferramenta — é uma questão de processo, dados, permissão e adoção. Empresa nenhuma fracassa em IA por falta de modelo bom.

Por que os projetos de IA param no piloto

Os motivos se repetem com uma regularidade quase entediante. Nenhum deles é técnico.

• O piloto nasceu de uma tecnologia procurando problema, e não de um problema procurando solução. A pergunta certa nunca é 'onde podemos usar IA?', é 'qual tarefa nos custa mais tempo e mais se repete?'.
• Ninguém mediu o antes. Sem linha de base, o projeto não tem como provar ganho, e o que não se prova não sobrevive ao próximo corte de orçamento.
• O piloto ficou fora do fluxo de trabalho. Se o time precisa sair do sistema onde trabalha, abrir outra ferramenta e colar contexto manualmente, o custo de uso supera o ganho.
• Não havia dono. Projeto de IA sem uma pessoa responsável por manter prompts, contexto e permissões degrada em semanas — é software vivo, não entrega única.
• A expectativa foi calibrada pela demonstração, não pela realidade. Demonstração é o melhor caso; operação é o caso médio com dado sujo, exceção e pressa.

Uso individual não é implementação

Essa confusão custa caro. Uma empresa contrata licenças corporativas de um assistente de IA, avisa o time e considera o projeto entregue. O que acontece na prática é que dois ou três entusiastas ganham muita produtividade, o restante experimenta e abandona, e o resultado agregado é indistinguível de zero.

O uso individual tem três limites estruturais. O conhecimento fica na cabeça de quem usa e vai embora com a pessoa. O resultado varia conforme quem escreveu o prompt naquele dia. E a IA não sabe nada sobre a empresa — ela responde bem sobre o mundo, e genericamente sobre a sua operação, porque não tem acesso à sua política comercial, ao seu histórico de atendimento nem ao seu contrato padrão.

Implementar é resolver exatamente esses três limites: transformar o prompt em ativo da empresa, tornar o resultado previsível, e dar à IA o contexto que só existe dentro de casa.

As quatro camadas de maturidade em IA

Vale enxergar a implementação como uma escada, não como um salto. Cada degrau exige mais preparo e entrega mais retorno, e pular degraus é uma das formas mais confiáveis de queimar orçamento. Uma empresa que ainda não padronizou prompts não tem base para operar agentes autônomos.

A camada 2 é a mais subestimada e a de melhor relação entre esforço e retorno. Ela não exige projeto de TI: exige disciplina. É onde o método CRIAR do livro deixa de ser técnica individual e vira padrão da empresa — cada prompt da biblioteca com contexto, regra, formato de saída e critério de qualidade explícitos.

Você é um especialista em engenharia de prompts para uso corporativo.

Abaixo está um prompt que um colaborador usa de forma informal. Reescreva-o como um prompt padrão da empresa, seguindo esta estrutura:

1. CONTEXTO — o que a IA precisa saber sobre a empresa e a situação (marque com [ ] o que deve ser preenchido pelo usuário)
2. PAPEL — que especialista a IA deve assumir
3. TAREFA — o que exatamente deve ser produzido
4. REGRAS — o que nunca fazer, incluindo: não inventar números e sinalizar quando faltar informação
5. FORMATO DE SAÍDA — estrutura exata da resposta
6. CRITÉRIO DE QUALIDADE — como saber se a resposta está boa

Ao final, liste as três formas mais prováveis de esse prompt falhar na prática e como o texto do prompt as previne.

PROMPT ATUAL:
[cole aqui]

Como escolher o primeiro caso de uso

Essa é a decisão que mais influencia o destino do projeto, e costuma ser tomada pelo critério errado: escolhe-se o caso mais estratégico, o mais visível para a diretoria ou o mais parecido com o que o concorrente anunciou. Um primeiro projeto tem uma função acima de todas as outras — provar valor rápido e criar confiança interna. Ele precisa ser escolhido com critérios objetivos.

Uma regra prática que funciona bem: o primeiro caso deve ser interno, não voltado ao cliente final. Erros de um assistente interno viram aprendizado; erros de um bot de atendimento externo viram reclamação pública. Comece onde o custo de errar é baixo e a frequência de uso é alta.

Build ou buy: quando construir e quando comprar

A falsa escolha aqui é tratar isso como decisão binária. Na prática, quase toda implementação séria é híbrida: compra-se o modelo (ninguém treina o próprio modelo de linguagem do zero — é caro e desnecessário), compra-se o que é commodity, e constrói-se apenas a camada onde está a diferença da empresa.

• Comprar faz sentido quando o problema é genérico e bem resolvido pelo mercado: transcrição de reunião, assistente de escrita, ferramenta de suporte com base de conhecimento padrão.
• Construir faz sentido quando a lógica é específica da sua operação: um copiloto que conhece sua tabela de preços, sua política de crédito, seu contrato padrão e o histórico do seu cliente.
• Construir também faz sentido quando o dado não pode transitar por uma ferramenta de prateleira, ou quando a integração com o sistema legado é o coração do valor.
• Não construa quando o único motivo é custo de licença. Software feito internamente tem custo de manutenção contínuo que costuma superar a licença que se quis evitar.

Sobre escolha de modelo, o ponto prático é que ela é reversível e menos determinante do que parece. A família Claude, da Anthropic, tem hoje o Opus 5 e o Sonnet 5 para trabalho de raciocínio e escrita mais exigente, e o Haiku 4.5 para tarefas de alto volume e baixa latência. Uma arquitetura bem feita permite trocar de modelo — inclusive usar modelos diferentes para etapas diferentes do mesmo fluxo. Amarrar o projeto a um único fornecedor no nível do código é um erro evitável.

Requisitos de dados: o gargalo real

A boa notícia é que IA generativa é muito menos exigente com dados do que os projetos de machine learning da década passada. Não é necessário um data lake, nem milhares de exemplos rotulados, nem um projeto de BI concluído. A má notícia é que o que ela exige, quase nenhuma empresa tem: documentação atual, correta e organizada.

Um copiloto que consulta a base da empresa é tão bom quanto essa base. Se existem três versões da política comercial em pastas diferentes e a válida é a que está no e-mail de um gerente, a IA vai responder com confiança usando a versão errada. O modelo não sabe qual documento está desatualizado — só sabe que encontrou um documento.

1. 1Inventarie as fontes: onde estão os documentos que respondem às perguntas do caso de uso escolhido.
2. 2Elimine duplicidade e marque a versão oficial de cada documento. Esta etapa é chata e é a que mais melhora a qualidade da resposta.
3. 3Registre a data de atualização de cada fonte — permite que o sistema avise quando estiver citando material antigo.
4. 4Defina quem pode ver o quê. Permissão precisa existir na camada da IA, não apenas na pasta original.
5. 5Escolha um responsável por manter a base. Sem isso, a qualidade decai de forma silenciosa ao longo dos meses.

Segurança, LGPD e o que não pode sair da empresa

A objeção mais comum em reunião de diretoria é 'nossos dados vão treinar o modelo deles'. É uma preocupação legítima e resolvida com contrato, não com fé. Planos corporativos e o uso via API dos principais fornecedores preveem que o conteúdo enviado não é usado para treinar modelos. A obrigação da empresa é verificar isso no contrato específico que está assinando, incluindo prazo de retenção e região de processamento — e não confiar em uma declaração genérica de site.

Sob a LGPD, quatro pontos precisam estar resolvidos antes de qualquer projeto entrar em produção.

• Base legal: por que esse dado pessoal está sendo tratado nesse fluxo? A resposta precisa existir antes, não depois de uma fiscalização.
• Minimização: o fluxo deve enviar o mínimo necessário. Muitas vezes o CPF, o nome completo e o endereço não são necessários para a tarefa e podem ser mascarados na origem.
• Transferência internacional e subcontratação: onde o processamento ocorre e quem é o operador, formalizado em contrato.
• Rastreabilidade: registro de o que foi enviado, por quem e quando. É isso que transforma uma resposta a incidente em algo administrável.

Existe ainda a categoria de dado que simplesmente não deve sair do perímetro: informação sob sigilo legal, dado de saúde, segredo industrial, material sob acordo de confidencialidade que proíbe subprocessadores. Para esses casos, o desenho correto não é enviar o dado — é enviar uma versão anonimizada, ou manter a etapa sensível fora do fluxo de IA. Na maioria dos projetos, um recorte bem feito resolve sem exigir infraestrutura própria.

O custo real de um projeto de IA

Não existe preço de tabela para implementação de IA, e desconfie de quem apresenta um sem entender o processo. O que existe são fatores que determinam o custo, e eles são previsíveis o suficiente para uma conversa honesta na primeira reunião.

• Escopo do caso de uso: um assistente que responde perguntas sobre documentos custa uma fração de um agente que executa transações em sistema.
• Estado da documentação: base organizada acelera; base espalhada em vinte pastas e e-mails adiciona uma fase inteira de trabalho ao projeto.
• Número e complexidade das integrações: cada sistema conectado é esforço de desenvolvimento, teste e manutenção — e sistemas legados sem API são o item mais caro de qualquer orçamento.
• Volume de uso: o custo de inferência é recorrente e proporcional ao uso. Ele é gerenciável escolhendo modelos menores para etapas simples e reservando os maiores para o que exige raciocínio.
• Exigência de precisão: um fluxo que tolera revisão humana é barato; um que precisa de avaliação sistemática, testes automatizados e monitoramento contínuo custa mais e demora mais.
• Manutenção: prompts, base de conhecimento e integrações precisam de manutenção contínua. Projeto orçado sem essa linha estoura no segundo semestre.

Um erro de orçamento frequente é considerar apenas o custo de construção. Some sempre inferência recorrente, licenças, manutenção e o tempo do time interno envolvido — esse último é o custo mais invisível e muitas vezes o maior.

Como medir retorno de forma defensável

Medir ROI de IA tem uma armadilha clássica: contar horas economizadas que não viraram nada. Uma hora liberada só é ganho se foi realocada para trabalho de maior valor ou se evitou uma contratação. Um projeto bem medido tem sempre três camadas.

Registre a linha de base antes de ligar qualquer coisa. É a etapa mais barata e a mais esquecida do projeto inteiro — e sem ela nenhuma discussão sobre resultado sai do campo da impressão pessoal.

Roteiro de implementação em 8 semanas

Erros que matam projetos de IA

• Começar pela tecnologia. A pergunta inicial é sobre processo doloroso, nunca sobre qual modelo usar.
• Escopo aberto. 'Um assistente que responde qualquer coisa sobre a empresa' é a descrição de um projeto que nunca fica pronto.
• Tratar como projeto de TI. Sem a área de negócio como dona, a adoção não acontece e a ferramenta morre bonita.
• Ignorar a gestão de mudança. Parte do time vai temer pelo emprego. Não tratar isso abertamente gera resistência passiva, que é o tipo mais difícil de reverter.
• Automatizar um processo ruim. IA aplicada a um processo quebrado entrega o resultado ruim mais rápido e em maior volume.
• Não planejar falhas. Todo sistema de IA erra. O projeto precisa definir o que acontece quando erra: quem percebe, quem corrige, o que fica registrado.
• Confundir demonstração com produto. O que funciona em cinco exemplos escolhidos a dedo não sobrevive a quinhentos casos reais sem trabalho de avaliação.

Você é um consultor de implementação de IA, cético e direto. Sua função é evitar que a empresa invista em um caso de uso ruim.

Avalie o processo descrito abaixo como candidato a um primeiro projeto de IA.

PROCESSO: [descreva o processo, quem executa, com que frequência e quanto tempo consome]
DADOS DISPONÍVEIS: [onde está a informação necessária hoje]
CONSEQUÊNCIA DE UM ERRO: [o que acontece se a saída estiver errada e ninguém perceber]

Entregue:
1. Nota de 0 a 10 para cada critério: frequência, volume de texto, disponibilidade de dados, tolerância a erro, dono claro, mensurabilidade, escopo fechado
2. Os dois maiores riscos deste caso específico
3. O que precisa estar pronto ANTES de começar
4. Uma recomendação clara: seguir, ajustar o escopo ou escolher outro processo — com justificativa em uma linha
5. Se a recomendação for seguir, qual seria o menor piloto possível que já prova valor

Seja rigoroso. Se o caso for fraco, diga isso.

Do uso individual à operação: a sequência que funciona

A empresa que faz isso bem raramente começa por um grande projeto. Ela treina o time para usar IA no dia a dia, padroniza o que funcionou em uma biblioteca de prompts, escolhe um processo específico para receber um copiloto com o contexto real da casa e, só depois de ter confiança e histórico, coloca agentes para executar tarefas em sistemas. Cada degrau financia o próximo com resultado demonstrado.

“Você não será substituído por uma IA, mas por quem souber usar bem a IA.”

— Inteligência Artificial para Negócios

Vale para pessoas e vale para empresas. A vantagem competitiva não está em ter acesso ao modelo — todo mundo tem. Está em ter a operação desenhada para aproveitá-lo.