A promessa dos agentes de IA é convincente: faça uma pergunta em linguagem simples e obtenha a resposta; diga ao agente o que mudar e ele muda. As demonstrações parecem não exigir esforço porque os dados de demonstração estão limpos.
Os dados reais de uma empresa não estão. O CRM está meio configurado. O sistema de faturação e o CRM não concordam sobre quanto um cliente paga. A mesma conta existe três vezes com nomes ligeiramente diferentes. As datas de renovação vivem numa folha de cálculo que uma só pessoa mantém. A utilização do produto está numa base de dados que ninguém ligou à conta a que pertence.
Coloque um agente por cima disso e ele continuará a responder, com confiança. Só que estará errado de formas difíceis de detetar.
Porque é que o alicerce de dados tem de vir antes dos agentes de IA?
Porque um agente só pode reportar e agir sobre aquilo que os seus sistemas registam. Se os dados do CRM, da faturação e do produto não coincidem, as respostas do agente são palpites e as suas ações espalham os erros. Estruturar primeiro os dados dá a cada agente uma única versão acordada dos factos, para que os seus relatórios sejam fiáveis e as suas ações seguras.
A versão curta é a da nossa página inicial: sem dados, não há IA. Na nossa experiência, é também onde muitos projetos de IA param sem fazer barulho. O relatório de 2025 do MIT NANDA “The GenAI Divide” concluiu que apenas cerca de 5% dos pilotos de IA generativa chegam à produção com um retorno mensurável. Um piloto sobre uma amostra arrumada pode parecer excelente; a mesma ideia sobre os dados reais e desarrumados muitas vezes não sobrevive à mudança.
O que corre mal quando os agentes assentam em dados desarrumados
As falhas são previsíveis, e pioram quando o agente pode agir além de responder:
- Relatórios que não batem certo. Peça o ARR e o agente soma o que está no CRM. As finanças somam as faturas. A administração recebe dois números e não confia em nenhum.
- Duplicados que se multiplicam. Três registos para um cliente significam três pontuações de saúde, três lembretes de renovação e um gestor de conta que parece descuidado.
- Ações sobre os factos errados. Um agente encarregado de enviar lembretes de renovação envia-os com base nas datas que o CRM tiver. Se essas datas estiverem desatualizadas, os lembretes também estão, e agora já chegaram aos clientes.
- Respostas que ninguém consegue verificar. Quando os dados estão dispersos, ninguém consegue rastrear de onde veio um número, e por isso ninguém consegue dizer se está certo.
Obter dados de fontes más produz relatórios maus. Enviar dados para fontes más torna-as piores. As duas metades do que um agente faz dependem do alicerce que está por baixo.
O que é, de facto, um alicerce de dados
Um alicerce de dados não é um programa de data warehouse nem uma migração de um ano. Para uma empresa em crescimento, e sobretudo para uma empresa SaaS, resume-se a algumas coisas bem feitas:
- Um CRM configurado para a forma como vende, renova e fatura. Pipelines, fases, objetos e campos desenhados em torno da forma como a empresa realmente trabalha, e não em torno de um modelo predefinido.
- Cada facto registado uma única vez. Contas, contactos e contratos sem duplicados; produtos, preços e condições de renovação mantidos num só lugar.
- Os sistemas ligados. Faturas e pagamentos associados ao cliente certo, a utilização do produto ligada à conta a que pertence, e um cliente, um contrato e uma fatura a significar o mesmo em todos os sistemas.
- Algo que os mantenha coerentes. Os dados desalinham-se se nada os mantiver. Nos nossos projetos, esse papel cabe ao Processor, que executa os fluxos de trabalho entre sistemas, repete o que falha e mantém um registo de auditoria completo de cada passo.
Os pormenores estão na nossa página sobre o alicerce de dados.
Como saber se os seus dados estão prontos
Algumas perguntas dão uma resposta rápida e honesta. Se alguma delas demorar mais do que uns minutos, ou receber duas respostas diferentes de duas pessoas diferentes, o alicerce precisa de trabalho antes de se colocarem agentes por cima:
- O ARR do CRM coincide com o ARR das finanças?
- Cada cliente existe exatamente uma vez, em todos os sistemas?
- As datas e condições de renovação estão no CRM, e estão corretas?
- Consegue ver a utilização do produto por conta, ao lado do que essa conta paga?
- Quando um negócio é fechado, o resto da empresa fica a saber sem que alguém tenha de enviar uma mensagem?
Esta verificação faz parte da nossa Avaliação de Prontidão para IA: se o CRM e os sistemas financeiros estão suficientemente coerentes para a IA poder confiar neles, antes de se construir o que quer que seja.
A ordem que funciona: dados, depois a camada de IA, depois os agentes
Todos os projetos que realizamos constroem as mesmas três camadas, pela mesma ordem:
- 1. O alicerce de dados. O CRM e os sistemas à sua volta configurados, estruturados e mantidos coerentes.
- 2. A camada de IA. Esses dados ligados ao assistente de IA que a equipa já utiliza, através de MCP (Model Context Protocol), o padrão aberto para ligar a IA a sistemas reais. Quem tiver permissão pode obter dados, enviar dados e desencadear ações em linguagem simples.
- 3. Agentes por departamento. Agentes feitos à medida para finanças, vendas e customer success, cada um com os relatórios e as ações de que essa equipa precisa, dentro das suas permissões e com um registo de auditoria.
Saltar a primeira camada parece mais rápido. Raramente é. O tempo poupado no início gasta-se mais tarde a explicar porque é que os números do agente não batem certo com os das finanças, e a reparar registos que ele alterou. Construída pela ordem certa, cada camada torna a seguinte mais barata, e os agentes no topo são fiáveis desde o primeiro dia.
Construído assim, o alicerce também continua a ser seu, e na Europa. Os dados ficam em infraestrutura da UE durante a construção, o modelo de IA é escolha sua e, se mudar de modelo mais tarde, o alicerce e tudo o que foi construído sobre ele mantêm-se iguais.