Quase toda empresa média ou grande do Brasil já fez seu piloto de IA corporativa. Um assistente no atendimento, um resumo de contrato, um copiloto para o time de dados. A demonstração impressiona, o patrocinador aplaude e, três meses depois, o projeto está parado. Não porque o modelo era ruim — os modelos estão excelentes e ficam melhores sozinhos. Parou porque ninguém desenhou a arquitetura ao redor dele.

Na prática, o modelo é a peça mais barata e mais substituível do conjunto. O que custa caro é o resto: de onde vem o contexto, quem pode ver o quê, o que a IA tem permissão de fazer sozinha e como você prova que aquilo deu retorno. Por isso, neste artigo tratamos IA como problema de engenharia e de governança — e usamos a própria operação da Inove como estudo de caso.

Por que os pilotos de IA não viram produção

Quando abrimos um piloto travado, o diagnóstico costuma cair em três causas — e raramente é a qualidade do modelo.

Contexto pobre. O assistente responde bem sobre o mundo e mal sobre a sua empresa. Falta o histórico do cliente, o contrato vigente, o chamado da semana passada, a regra fiscal que só existe num anexo. Sem esse material, a IA é um estagiário brilhante no primeiro dia: rápido, educado e desinformado.

Dono indefinido. O piloto nasce numa área de negócio, roda num SaaS pago no cartão de alguém e nunca entra no ciclo de vida de TI. Não tem responsável por acesso, atualização ou incidente. Quando o entusiasta muda de time, o projeto morre de causas naturais.

ROI não medido. Ninguém mediu a linha de base antes. Quantos minutos levava atender um chamado? Quantos retrabalhos por mês? Sem esse número anterior, qualquer ganho vira opinião — e opinião não sobrevive ao corte de orçamento do trimestre seguinte.

As camadas: estruturado, não estruturado e memória viva

Contexto não é um balde só. Ele tem três camadas, com custo, risco e ciclo de atualização diferentes. Tratar tudo igual é o erro mais comum.

Dados estruturados são o que já mora no ERP, no CRM, no banco de dados, na ferramenta de chamados. São confiáveis, versionados e têm dono. A IA não deve “aprender” esses dados: ela deve consultá-los na hora, via consulta parametrizada, e citar a origem. Aqui o padrão certo é ferramenta, não texto.

Dados não estruturados são o acervo real da empresa: propostas, atas, e-mails, documentação de projeto, apresentação de kickoff, laudo técnico. É onde está o conhecimento que ninguém digitou em campo de formulário — e também onde mora o risco de vazamento e de informação desatualizada.

Memória viva é a camada que quase todo mundo esquece. É o resumo curado do que importa sobre um cliente, um ambiente, um projeto: decisões tomadas, restrições conhecidas, preferências, pendências. Não é o documento inteiro; é a ficha destilada. Ela precisa de data, de fonte e de expiração — memória sem validade envelhece e mente com confiança.

RAG, MCP e agentes: quando usar cada um

Existem três padrões de arquitetura que resolvem problemas diferentes. Escolher errado é o que produz aquele assistente caro que ninguém usa.

RAG (busca antes de responder). A IA procura trechos relevantes no seu acervo e responde citando a fonte. Use quando a pergunta é sobre conhecimento parado: política interna, documentação, histórico de projeto, manual de processo. É o padrão mais barato e o mais fácil de auditar, porque toda resposta aponta para um documento. Não use RAG para número que muda toda hora — saldo, estoque, status de chamado. Nesse caso ele devolve a foto de ontem com cara de verdade de hoje.

MCP (a IA usa suas ferramentas). Aqui você não copia dado para dentro da IA: você expõe uma porta padronizada para ela consultar o sistema em tempo real, com a credencial certa. É o padrão para dado vivo e para operação — abrir chamado, checar status de ambiente, ler um indicador. A vantagem de governança é grande: o acesso continua sendo do sistema de origem, com o mesmo controle de permissão que já existe, e não de uma cópia paralela que ninguém revoga.

Agentes com guarda-rails. Um agente encadeia passos: consulta, decide, executa, verifica. Só faz sentido quando o processo é repetitivo, tem regra clara e um custo de erro que você consegue conter. E “conter” tem nome técnico: escopo de credencial mínimo, ambiente separado, aprovação humana para qualquer passo irreversível e log completo de cada ação. Sem isso, você automatizou o erro — que é exatamente o que boas práticas de cibersegurança mandam evitar.

Governança e LGPD: personalização sem invasão

Personalizar atendimento com IA é legítimo. O que separa personalização de invasão são três decisões escritas antes da primeira linha de código.

Finalidade. Cada dado no contexto precisa responder “para quê”. Registro técnico de um ambiente serve para atender melhor aquele ambiente — não para perfilar pessoas. Se você não consegue escrever a finalidade em uma frase, aquele dado não entra.

Retenção. Memória sem prazo vira passivo. Defina quanto tempo cada tipo de registro vive e o que acontece no fim do contrato. É a mesma disciplina de descarte que aplicamos em gestão de volume de dados: guardar tudo para sempre é caro e é risco.

O que nunca entra no contexto. Credencial, chave de API, dado pessoal sensível, informação de terceiro sem base legal. Essa lista precisa ser explícita e verificada por filtro automático, não por boa vontade de quem escreve o prompt. Some a isso o básico de sempre: acesso por perfil, registro de quem consultou o quê e revisão periódica de permissões.

O caso da própria Inove

Aplicamos isso na nossa operação de atendimento, e o desenho tem quatro estágios.

Primeiro, captura: tudo que acontece num atendimento vira registro — chamado, diagnóstico, decisão técnica, documentação de ambiente. Depois, memória: em vez de empilhar transcrição, destilamos fichas por cliente e por ambiente, com fonte e data. Em seguida, contexto: quando um consultor abre um assunto, o material relevante é montado na hora, filtrado pela permissão daquela pessoa. Por fim, ação assistida: a IA prepara o rascunho do informe, sugere a causa raiz provável, monta o roteiro de verificação — e um especialista aprova antes de qualquer coisa tocar o ambiente do cliente.

O ganho não é mágico, é acumulativo. O consultor que assume um chamado às duas da manhã já começa sabendo o que foi tentado antes. E, do lado do cliente, o efeito prático é ser atendido por quem lembra do contexto — sem que ninguém precise repetir a história toda de novo. Vale para suporte de TI tanto quanto para projeto.

Adoção por ondas e o que medir

Nunca começamos por automatizar. A ordem que funciona é: onda 1, IA lê e resume (risco quase zero, ganho imediato); onda 2, IA consulta sistemas e responde com fonte; onda 3, IA rascunha entregáveis com revisão obrigatória; onda 4, agente executa tarefas reversíveis e bem delimitadas. Cada onda só abre quando a anterior tem indicador estável.

E meça quatro coisas desde o dia zero: tempo de ciclo da tarefa (com a linha de base de antes), taxa de retrabalho no que a IA produziu, cobertura de fonte — quantas respostas citam origem verificável — e custo por tarefa, incluindo o consumo de tokens. Esse último tem disciplina idêntica à de FinOps: sem visibilidade de consumo por caso de uso, a conta cresce sem que ninguém saiba de onde veio.

Para ir mais fundo, vale combinar este material com os conteúdos da Inove Academy — em especial o e-book de Cibersegurança e LGPD, que trata da governança de acesso que sustenta qualquer projeto de IA, e a calculadora FinOps, útil para modelar o custo recorrente antes de escalar.

No fim, a pergunta que separa piloto de produção não é “qual modelo usar”. É outra, bem mais chata e bem mais útil: de onde vem o contexto, quem autorizou esse acesso, o que a IA pode fazer sem pedir licença e como saberemos, em números, se valeu a pena. Quem responde essas quatro tem um sistema; quem não responde tem uma demonstração.