Arthur Guttilla Head of Product Marketing, Strattum Com passagens na Amazon Web Services e no Google, Guttilla trabalhou diretamente com fundadores de startups e empresas de capital de risco, compreendendo as necessidades de empresas tecnológicas em estágio inicial na interseção entre tecnologia e negócios.
Em resumo
Um teste rápido para saber se a empresa tem um problema de definição é perguntar a três áreas o que é um cliente ativo. Vendas costuma responder que é quem tem contrato assinado. Finanças considera quem pagou a última fatura. Customer Success olha para quem usou o produto nos últimos trinta dias. As três respostas são razoáveis e produzem números diferentes para a mesma pergunta. A ontologia de dados é o registro que resolve essa diferença. Ela é um dos três componentes do Company Brain, a camada que conhece a empresa: quais dados existem, onde vivem, como se relacionam e quem pode ver o quê.
O termo vem da filosofia, onde descreve o estudo do que existe. Em computação, ganhou um sentido prático: uma especificação explícita dos conceitos de um domínio, dos atributos de cada conceito e das relações permitidas entre eles. Na Strattum, chamamos essa especificação de ontologia do negócio, porque ela descreve como uma empresa específica funciona.
Para cada termo, a ontologia de dados responde a quatro perguntas:
Cliente ativo passa a ter uma definição escrita, uma regra de cálculo, uma lista de sistemas onde aparece e uma área responsável.
Muitas empresas já têm um glossário de negócio ou um dicionário de dados. O glossário descreve termos em linguagem natural e serve para leitura humana. O dicionário descreve colunas e tabelas de um banco específico. A ontologia de dados liga as duas coisas: parte do conceito de negócio, aponta onde ele está representado em cada sistema e registra a regra que o calcula em um formato que uma máquina consegue aplicar.
Essa última característica é a que importa para a IA. Um glossário bem escrito ajuda uma pessoa nova a entender a empresa. Um agente de IA precisa da regra em forma executável para aplicar a mesma definição em todas as respostas. Padrões como a linguagem de ontologias publicada pelo W3C existem para expressar esse tipo de especificação de forma que sistemas diferentes consigam interpretá-la.
Manter uma ontologia de dados não exige que as áreas de negócio aprendam uma linguagem formal. A definição é escrita e validada por quem conhece o processo, e a equipe técnica a traduz para o formato que os sistemas conseguem aplicar. O conhecimento continua com a área, e a regra passa a valer em todos os lugares onde o termo aparece.
Quando um modelo de linguagem recebe a pergunta sobre quantos clientes ativos a empresa tem no Sul, alguma definição de cliente ativo vai ser aplicada. Sem uma definição registrada, o modelo segue a interpretação mais frequente no texto que recebeu, que pode ser a de vendas em uma resposta e a de finanças na seguinte. As duas respostas soam corretas, e a divergência só aparece quando alguém compara os números na reunião.
O problema cresce com agentes que executam ações. Uma política que libera desconto para clientes adimplentes depende da definição de adimplente. Se a cobrança considera o acordo de renegociação e o financeiro considera o vencimento original, dois agentes que consultam a mesma política chegam a resultados opostos para o mesmo cliente.
Uma ontologia de dados só funciona se as definições forem mantidas. Cada termo central precisa de uma área responsável, de uma data de revisão e de um histórico de versões. Quando finanças muda o critério de inadimplência, a mudança é registrada com data, e as respostas passam a indicar qual versão da definição foi usada.
A versão também protege a análise histórica. Um relatório do ano anterior continua explicável pela definição que valia na época, mesmo depois que o critério mudou, e a comparação entre períodos deixa claro quando a diferença vem do negócio e quando vem da regra.
Isso também desfaz um impasse comum. Nem sempre é preciso escolher uma única definição para a empresa inteira. Cliente ativo para vendas e cliente ativo para finanças podem coexistir como termos distintos, com nomes distintos, desde que cada pergunta seja ligada ao termo certo. O erro está em usar a mesma palavra para os dois sem registrar a diferença.
No Company Brain, os três componentes trabalham juntos. O grafo de conhecimento guarda as entidades e as relações entre elas. A ontologia de dados diz o que cada entidade e cada relação significam e quais regras se aplicam. A camada semântica usa esse vocabulário para traduzir uma pergunta em linguagem natural para a consulta correta, com a permissão de quem perguntou.
Quando alguém pergunta pelos clientes ativos da própria carteira, a camada semântica identifica o termo, consulta a ontologia para saber qual definição vale para aquela área e percorre o grafo com essa regra. A resposta, servida ao modelo via MCP, cita a definição aplicada e os sistemas de origem.
Tentar modelar todos os conceitos da empresa antes do primeiro caso de uso costuma produzir um documento extenso que ninguém consulta. O caminho mais curto é listar os termos que aparecem em relatórios de áreas diferentes com números que não batem. Cliente ativo, receita, churn, pedido entregue e chamado resolvido são candidatos frequentes.
Cada termo resolvido passa a valer para todos os agentes e relatórios que consultam o Company Brain. A ontologia de dados cresce junto com os casos de uso, e cada novo projeto herda as definições que os anteriores já acordaram.