O que é um data contract, e como você aplica isso entre sistemas?

O que é um data contract?

Um data contract, ou contrato de dado, é um acordo explícito sobre o que um dado significa, quem o produz e as regras que ele sempre tem que obedecer, escrito antes do código em vez de descoberto depois dele. Para um CRM, o contrato é uma afirmação que sempre tem que valer para um cliente pagante, e é conferida por máquina todo dia. Escrever a regra primeiro vira o projeto do avesso: em vez de programar "faz isso, depois aquilo", você programa "como eu percebo e conserto no momento em que alguém fura a regra". E como a regra vive no repositório, não na cabeça de uma pessoa, ela continua valendo quando essa pessoa está longe.

Um data contract é uma regra que sempre tem que ser verdadeira, escrita antes do código e verificada por máquina todo dia. O trabalho deixa de ser automação e vira detecção e conserto: pegar o registro que viola a regra, e arrumar.

A ideia é antiga na engenharia de dados, mas importa mais agora que um agente, não um analista, lê o resultado e age sobre ele. Um contrato é a diferença entre um CRM em que se pode confiar para guiar um forecast e um que discorda de si mesmo em silêncio. O resto deste guia usa o CRM como exemplo trabalhado, porque é o ativo onde o contrato compensa primeiro.

Por que o dado do CRM apodrece?

Porque ele tem três donos e ninguém responsável pela consistência. Um único cliente é tocado por três times, cada um no seu sistema: Vendas fecha o negócio, Financeiro cobra o pagamento, e o Customer Success entrega o serviço. Cada um edita o próprio sistema sem olhar os outros, então o CRM ou passa fome (o negócio nunca vai para ganho, o registro de pós-venda nunca nasce) ou come demais (o mesmo cliente duplicado, com datas que discordam). A falha é uma venda de cada vez, sempre levemente fora de conformidade.

Isso não é um problema de gente; é um problema de dado. Juntar os quatro sistemas não é trabalho de Vendas, nem de Financeiro, nem de CS, então ninguém faz, e o registro vai se desviando. E o CRM é o pior lugar para isso acontecer, porque depois do produto ele é o ativo mais importante da empresa: forecast, atribuição, meta e comissão nascem todos dele. Quando ele perde a confiança, o estrago se acumula de um jeito específico. As pessoas param de conferir a comissão pelo CRM e passam a auditar direto pelo Financeiro, o que significa que a ferramenta mais importante da empresa é ignorada justo no número que mais importa. O padrão de cada ferramenta reportando a própria versão é o tema de por que agentes de IA dão respostas diferentes para o mesmo dado, e o mesmo CRM, confiando num campo inferido em vez do dado por baixo, é o que reporta menos leads pagos.

O que o contrato especifica de fato?

Ele especifica os lados que têm que existir juntos e a chave que os casa. No exemplo trabalhado, um cliente pagante tem que ter três coisas ao mesmo tempo: um pagamento, um negócio marcado como ganho, e um registro espelho no pós-venda. Os três, sempre, casados por uma chave, o workspace do cliente (em muitos negócios essa chave é o CNPJ). Sem essa chave, o pagamento, o negócio e o registro de pós-venda são três estranhos que nunca se encontram.

Responder se os três lados valem significa ler em quatro sistemas e doze tabelas, casadas por essa chave única.

Um cruzamento (join) é juntar duas tabelas pela chave que elas têm em comum. É fácil com duas. O contrato exige isso em doze tabelas de quatro sistemas, todo dia, sobre a base inteira, sem as APIs das fontes te bloquearem por excesso de chamada e sem cada execução trazer um número diferente. É por isso que ninguém faz na mão, e por que uma camada governada, não uma planilha, é o único lugar onde isso se sustenta. Uma verificação que antes levava pelo menos dez minutos por venda roda automaticamente.

Como você aplica um data contract?

Com um agente que roda a regra sobre cada registro e conserta o que consegue, construído como dois agentes que cobrem um ao outro. Um é ao vivo: acorda quando uma venda é anunciada e roda a regra naquela venda na hora. O outro roda diariamente sobre a base inteira, reconfere a regra em cada cliente, e produz um relatório do que furou hoje, do que está furado faz dias, e do que foi resolvido desde ontem. A varredura diária é a rede para o que o agente ao vivo não pegou, e é o que faz o "sem dono humano" ser real, porque roda agendada esteja alguém olhando ou não.

Na prática o agente transforma o contrato numa lista de verificação de dez itens objetivos rodada sobre cada venda: o negócio está em ganho, a data de fechamento está certa, a origem está preenchida, o espelho no pós-venda existe, a assinatura está casada com o workspace, e assim por diante. Cada item tem uma de três respostas: sim, não, ou dúvida. O que é claramente resolvível, o agente arruma. O que é dúvida, ele não chuta; pergunta para a pessoa certa e não larga a thread até fechar. Por baixo da lista estão cinco perguntas, cada uma morando num sistema diferente, que juntas decidem se um cliente de fato existe:

• Quem fechou, e quem é o cliente? O negócio e o dono dele. Reconhecer que o nome do negócio, a razão social e o nome fantasia são a mesma empresa é julgamento, não conta.
• Quando fechou, e quando o dinheiro entrou? Essa data vira comissão, então errar o dia mexe no bolso de alguém. Os erros de fuso moram aqui.
• Onde o cliente vive? A chave do workspace que casa todos os sistemas.
• O que, quanto e como ele paga? A assinatura e a cobrança que realmente caiu, que separa um cliente pagante de um negócio marcado como ganho por otimismo.
• Por que ainda não tem acompanhamento? Se existe um pagamento e um negócio em ganho mas não existe o espelho no pós-venda, o cliente está no limbo: pagando, e invisível para o time que deveria atendê-lo.

Onde a IA deve parar e o código determinístico assumir?

Trace a fronteira por capacidade: o modelo fica com linguagem e julgamento, o código fica com conta e verificação. Jogue tudo no modelo e ele carimba uma data errada, esquece um caso, e devolve um número que ele "decidiu", no qual você então confia. Jogue tudo em regras fixas e o mundo real tem mais variação que a sua lista, então vira um jogo sem fim de remendar exceções. O design durável separa os dois com clareza.

O mecanismo que mantém os dois separados é um selo estruturado. O modelo entende um caso bagunçado uma vez e grava uma marca estruturada, um veredito limpo; o código determinístico só lê essa marca e a aplica. O código nunca parseia linguagem natural, porque parsear intenção no código é exatamente o trabalho frágil que o modelo existe para fazer. Há uma regra de bolso útil: quando o sistema erra, a inteligência quase sempre está do lado errado da fronteira. Esse é o mesmo princípio de manter o significado de negócio no dado em vez do prompt, abordado em context engineering para agentes de IA, e é por isso que o código endereça os estágios do pipeline por ID, nunca por nome: o nome muda, o ID não.

O que torna a aplicação durável, não um script que apodrece?

Cinco coisas que ou existem, ou não existem. Rodar um agente sozinho na cloud não é a mesma coisa que rodar no terminal, onde memória, orquestração e contexto vêm de graça; na cloud o modelo chega cru e esse andaime é construído na mão. A parte que parece IA é a parte fácil. O que a segura em pé por baixo é o trabalho, e ele se resume a cinco requisitos.

• Versionado no Git, para qualquer pessoa do time abrir, não guardado num laptop só.
• Rodando na conta da empresa, não numa sessão pessoal de IA.
• Deployável por qualquer engenheiro, para uma etiqueta de versão subir ele, mesmo com o autor fora.
• Agendado, para rodar todo dia, inclusive nas férias.
• Reconhecido como um serviço de verdade pelo time de engenharia, não tratado como o script pessoal de alguém.

Sem isso é uma sessão, não um serviço. Um serviço tem dono coletivo, e é isso que faz o "roda sem mim" ser verdade em vez de aspiração.

Como a Nekt faz isso?

A Nekt é uma plataforma de dados que dá contexto governado para agentes de IA, e aplicar um data contract é um exemplo direto das três partes que ela cobre.

• Conectar. O CRM, o banco do produto, a cobrança e o suporte caem num lugar só por conectores prontos, para que uma mensagem de suporte que de outra forma morreria no celular de alguém entre como qualquer outra fonte.
• Governar. As fontes são unificadas pela chave comum, as doze tabelas casadas uma vez, e o próprio contrato é modelado na camada com o significado de negócio anotado por coluna, para a regra ser escrita no dado em vez de redescrita em cada consulta.
• Servir. O agente lê o resultado por um servidor MCP e confere cada registro contra o contrato, com o modelo cuidando do julgamento e o código determinístico cuidando da verificação. A mesma camada que lê o dado é a que deixa o agente consertá-lo.

O ganho é um registro que para de adoecer no escuro: o ativo mais importante depois do produto, aquele sobre o qual toda decisão é construída, é conferido contra o seu contrato todo dia. Veja como a Nekt funciona, ou crie uma conta gratuita e conecte sua primeira fonte.

Perguntas frequentes

O que é um data contract em termos simples?

É uma regra escrita sobre o que um dado sempre tem que parecer, acordada antes de o código ser construído e conferida automaticamente. Para um CRM, um contrato pode dizer que todo cliente pagante tem um pagamento, um negócio em ganho e um registro de pós-venda, todos casados por uma chave. Se algum lado falta, o contrato é violado e o registro precisa de conserto.

Data contract vs qualidade de dado: qual a diferença?

Qualidade de dado é o estado geral de o dado estar correto, completo e consistente. Um data contract é a regra específica e escrita que define o que "correto" significa para um conjunto de dados, e o mecanismo que a aplica. Qualidade é o objetivo; o contrato é o acordo e a conferência que te levam até lá, de um jeito que não depende de alguém lembrar da regra.

Um agente de IA deve consertar o dado do CRM automaticamente?

Para os casos claros, sim; para os ambíguos, não. O design durável deixa o agente consertar o que é objetivamente resolvível e escalar o que exige julgamento, em vez de chutar. A IA decide se um caso está claro e grava um veredito estruturado; o código determinístico aplica o conserto. Deixar o modelo inventar valores sobre os quais está em dúvida é como uma ferramenta de conserto vira uma nova fonte de erro.