Fundamentos de dados antes da IA: as correções que se pagam em até dois trimestres

A maioria dos planos de IA parte do princípio de que os dados da empresa estão prontos e de que o trabalho está em escolher um modelo. Em empresas estabelecidas, os dados costumam estar nos sistemas certos e no formato errado: o mesmo cliente cadastrado de três maneiras, códigos de produto que significam coisas diferentes na loja e no armazém, uma receita que difere entre a propriedade de analytics e o livro contábil.

A forma mais rápida de descobrir o que precisa ser corrigido é acompanhar registros reais. Pegue uma amostra de pedidos, faturas e movimentações de estoque e rastreie cada um por todos os sistemas que o tocam, da loja ou da ferramenta de cotação, passando pelo provedor de pagamentos, pelo CRM e pelo armazém, até o sistema contábil e a camada de relatórios. Anote onde o registro é redigitado à mão, onde uma planilha o copia, onde seu identificador muda e onde ele desaparece. Esses pontos formam a lista de trabalho.

As correções a seguir são as que esperamos que se paguem em até dois trimestres. Cada uma elimina trabalho manual ou um erro de relatório que já custa dinheiro, e cada uma é pré-requisito para qualquer funcionalidade de IA que venha a ler os mesmos registros.

Todo uso posterior depende de vínculos. A receita por cliente exige que o sistema de pedidos e o livro contábil compartilhem uma chave de cliente. A margem por produto exige que a loja, o armazém e o livro de compras concordem sobre o que significa um código de produto. Um assistente de IA que responde a perguntas sobre pedidos ou produtos herda toda a ambiguidade que as chaves carregam.

A verificação é rápida. Para cada identificador, teste se ele está preenchido e se é único em toda a base, de modo que um código corresponda a um único produto. São testes distintos. Um campo de código de produto pode estar preenchido em todos os registros e ainda assim ser compartilhado por dois itens diferentes, o que basta para que um assistente descreva o produto errado com total segurança, ou para que um catálogo enviado a um parceiro comercial cote o item errado sob o código certo.

O retorno vem do trabalho que a correção elimina: notas de crédito por envios errados, horas gastas conciliando extratos de clientes e relatórios refeitos à mão todo mês porque dois sistemas não batem.

As propriedades padrão do Google Analytics 4 retêm dados no nível do usuário e do evento por 2 meses na configuração inicial e por no máximo 14 meses; uma retenção mais longa dos dados de eventos só está disponível no plano pago 360. Os relatórios padrão usam tabelas agregadas e continuam mostrando os totais antigos, de modo que a perda permanece invisível até que alguém monte uma exploração ou um funil ano contra ano e encontre o período anterior vazio. Aumentar a configuração de retenção protege apenas os dados que ainda não foram apagados.

A correção duradoura é a exportação para o BigQuery, que copia os eventos brutos para um data warehouse de propriedade da empresa. As propriedades padrão podem enviar até 1 milhão de eventos por dia pela exportação diária. A exportação por streaming não tem limite de volume e custa US$ 0,05 por gigabyte, o que, segundo o Google, equivale a cerca de 600.000 eventos. Com esses preços, a conta de armazenamento de uma empresa de porte médio é pequena diante do custo de planejar uma alta temporada sem os dados de comportamento do ano anterior.

Essa correção traz o prazo embutido. Cada mês de espera é um mês de histórico de eventos que não pode ser recuperado, e o ciclo de planejamento de 2027 vai precisar da alta temporada de 2026 completa.

A fatura eletrônica transforma o cadastro de clientes em uma dependência de compliance. Na Alemanha, as empresas cuja receita no ano anterior tenha superado € 800.000 devem emitir em formato eletrônico estruturado as faturas domésticas entre empresas (B2B) a partir de 1º de janeiro de 2027, e todas as demais seguem a partir de 1º de janeiro de 2028; o recebimento dessas faturas é obrigatório desde 1º de janeiro de 2025. No Reino Unido, o governo anunciou que todas as faturas com VAT terão de ser eletrônicas a partir de abril de 2029, confirmou o Peppol como rede de troca e informou que um roteiro detalhado de implementação viria com o Orçamento de 2026, previsto para 28 de outubro.

O trabalho que dá retorno é o mesmo nos dois países e começa bem antes de qualquer prazo. Complete e valide, no cadastro de clientes, os identificadores de VAT, os números fiscais e os endereços eletrônicos de roteamento. Padronize os códigos de produto e de tributação nas linhas das faturas. Elimine as etapas manuais entre o sistema de pedidos e a fatura. Uma fatura rejeitada atrasa o caixa, por isso um cadastro limpo encurta o prazo de recebimento, além de atender à regra, e um modelo de dados construído para uma entidade alemã neste trimestre pode ser reaproveitado depois para o Reino Unido.

A última correção é mais uma disciplina do que um sistema. Os relatórios gerenciais tiram a receita da loja ou do CRM, os custos do livro contábil e os resultados de marketing das plataformas de anúncios, e os três raramente batem. Quando o material do conselho e a contabilidade diferem em um valor que ninguém consegue explicar, todos os números do material perdem autoridade, e as decisões ficam mais lentas enquanto as pessoas discutem qual número está certo.

Uma ponte mensal resolve a questão. Depois do fechamento, cada número principal do pacote de relatórios gerenciais é conciliado com o livro contábil, e a diferença é decomposta em itens nomeados e recorrentes: defasagem temporal, reembolsos, tributos, operações entre empresas do grupo, pedidos de teste. A ponte é gerada a partir dos sistemas, e não montada à mão, e qualquer resíduo não explicado acima de um limite acordado é investigado antes que o pacote seja distribuído. Depois que os itens recorrentes ganham nome, o que sobra costuma ser uma lista curta de processos que ninguém havia documentado.

Essa é também a base de que qualquer assistente de IA para relatórios vai precisar. Um modelo questionado sobre por que a margem caiu em uma região só responde corretamente se os números que lê já tiverem sido conciliados. Construímos essas pontes do livro contábil para fora pela mesma razão pela qual começamos todo projeto pelos pedidos, pelos livros contábeis e pelos logs: o painel só é tão bom quanto os registros que o sustentam.

Em novembro de 2026, rastrear uma amostra de pedidos, faturas e movimentações de estoque reais por todos os sistemas e listar cada ponto em que um registro é redigitado, copiado ou recebe um novo identificador.

Antes do fim de novembro, configurar a retenção de eventos do GA4 em 14 meses em todas as propriedades e vincular cada propriedade ao BigQuery, para que a alta temporada de 2026 seja preservada por completo.

Até o fim de dezembro, executar verificações de unicidade e completude dos identificadores de clientes, produtos e pedidos em todos os sistemas e corrigir os códigos de produto duplicados antes que qualquer funcionalidade de IA ou catálogo comercial dependa deles.

Para qualquer entidade alemã, confirmar antes de 1º de janeiro de 2027 se ela está acima do limite de € 800.000 e se a emissão de faturas e o cadastro de clientes estão prontos, e planejar a obrigatoriedade britânica sobre o mesmo modelo de dados assim que o roteiro for publicado.

A partir do fechamento de janeiro de 2027, publicar todo mês uma ponte entre o pacote de relatórios gerenciais e o livro contábil, com itens de conciliação nomeados e um limite para o resíduo.

Até junho de 2027, escolher o primeiro caso de uso de IA a partir dos dados conciliados e medir sua linha de base com os mesmos registros.