antonino, Autor em Área de Trampo

1. Princípios Fundamentais das Ontologias na Governança de Dados

Ontologia resolve ambiguidade de significado: o maior desafio da governança de dados não é tecnológico, mas o significado atribuído ao dado — termos como “cliente ativo” podem ter interpretações diferentes entre áreas.
Ontologia não é apenas documentação: enquanto o glossário define termos, a ontologia mostra como os conceitos se conectam e se relacionam dentro do negócio.
Construção começa pelo negócio, não pela tecnologia: o erro mais comum é começar pelos dados ou sistemas; a ontologia deve representar como a organização compreende sua realidade.
Ontologia é a evolução de glossário e taxonomia: primeiro define-se o que o termo significa (glossário), depois organiza-se em grupos (taxonomia), para então representar relacionamentos e regras (ontologia).
Nem todo conceito merece uma ontologia: é preciso priorizar conceitos com relevância estratégica, amplamente utilizados e centrais para o negócio.
Relacionamentos usam verbos significativos: “cliente possui apólice”, “apólice gera sinistro”, “sinistro resulta em indenização” — os verbos tornam o modelo intuitivo e compreensível.
Ontologia é um ativo vivo: o negócio evolui, novos produtos surgem, regulamentações mudam — a ontologia precisa ser continuamente atualizada e governada.
Comece pequeno e evolua gradualmente: escolha um domínio específico, resolva um problema concreto e mostre valor antes de expandir.
Ferramenta não é a essência: é possível começar com PowerPoint, draw.io ou papel; a ferramenta especializada só se justifica quando o negócio demanda maior formalização.

2. O que é Ontologia e Por Que Ela Importa

A palavra “ontologia” vem da filosofia e estuda a natureza da existência. No contexto de dados, a ontologia representa formalmente conceitos, entidades, atributos e relacionamentos de um domínio de conhecimento. Seu objetivo é criar um modelo compartilhado que permita que pessoas e sistemas interpretem informações da mesma forma. É muito difícil ter inteligência artificial com bom desempenho se os dados estão desorganizados ou sem conexão entre termos e relacionamentos. A ontologia viabiliza essas conexões: padroniza conceitos e cria relacionamentos, permitindo que a IA seja mais assertiva. Em um exemplo de seguradora: um cliente possui uma apólice; uma apólice pode gerar sinistro; um sinistro pode resultar em pagamento de indenização. O valor da ontologia está em representar essas relações de forma explícita, reduzindo interpretações conflitantes.

3. Ontologia, Glossário e Taxonomia: Diferenças e Evolução

Os três conceitos são interligados, mas possuem objetivos e níveis de complexidade distintos. O glossário reúne termos e definições oficiais — diz o que o termo significa (ex.: o que é “cliente ativo”). A taxonomia organiza informações em grupos e hierarquias — indica a qual grupo o conceito pertence (ex.: “cliente” se ramifica em “pessoa física” e “pessoa jurídica”). A ontologia representa conceitos, relacionamentos, regras e dependências — mostra como o termo se relaciona com outros termos (ex.: “cliente possui apólice”, “apólice gera sinistro”). Em termos de maturidade, não é possível aplicar ontologia sem um glossário bem estabelecido e uma taxonomia bem trabalhada. A evolução natural é: glossário → taxonomia → ontologia.

4. Benefícios das Ontologias para o Negócio

As ontologias geram benefícios concretos: linguagem comum (reduz conflitos de interpretação e aumenta a consistência das decisões), integração entre sistemas (facilita a interoperabilidade entre soluções legadas e modernas), melhoria da qualidade dos dados (reduz inconsistências causadas por interpretações divergentes), apoio ao analytics (analistas localizam informações com mais facilidade e compreendem melhor os indicadores), base para inteligência artificial (fornece contexto e conhecimento estruturado para algoritmos) e fortalecimento da governança (apoia glossários, catálogos e metadados, unificando o entendimento de Data Stewards e Data Owners). Organizações maduras tratam seus modelos semânticos como ativos estratégicos mantidos e evoluídos ao longo do tempo.

5. Conceitos de Negócio: o Ponto de Partida

Um conceito representa algo que possui significado para o negócio e não precisa corresponder a uma tabela, sistema ou relatório. Exemplos: cliente, produto, contrato, sinistro, pessoa colaboradora. Nem todo conceito é relevante — é preciso priorizar os que possuem relevância estratégica, são amplamente utilizados e representam elementos centrais do negócio. Os conceitos não precisam ser inventados: na maioria das organizações, eles já existem, distribuídos em documentos, processos, sistemas e no conhecimento de pessoas especialistas. O primeiro passo é conversar com as áreas, convidar Data Owners e Data Stewards e construir em conjunto. Cada conceito deve ter nome, definição, contexto, responsável e exemplos, preferencialmente documentados em um card padronizado.

6. Entidades, Atributos e Relacionamentos: a Estrutura da Ontologia

Uma entidade representa algo relevante para o negócio que pode ser identificado individualmente (cliente, produto, apólice). Para reconhecer uma entidade, pergunte: é importante para o negócio? Possui identidade própria? Possui características? Participa de processos? Os atributos descrevem características das entidades (nome, CPF, data de nascimento para cliente). Nem todo atributo tem a mesma importância — priorize os que geram valor para o negócio. Os relacionamentos descrevem como duas entidades se conectam dentro do domínio, usando verbos significativos: “cliente possui apólice”, “corretor vende produto”, “apólice contém cobertura”. A cardinalidade adiciona precisão: um cliente pode possuir quantas apólices? (um para N); uma apólice pertence a quantos clientes? (um para um); um sinistro pode gerar quantas indenizações? (um para N). Os tipos básicos são: um para um, um para N e muitos para muitos.

7. Estrutura Completa de uma Ontologia: Classes, Regras e Camadas

Uma ontologia completa combina: classes (organizam elementos semelhantes em grupos, como cliente → pessoa física/pessoa jurídica), entidades (elementos do domínio), atributos (características), relacionamentos (conexões) e regras (restrições e comportamentos: toda apólice deve possuir um cliente; todo sinistro deve estar associado a uma apólice; uma indenização depende de um sinistro aprovado). A ontologia também conecta camadas de conhecimento: camada de negócio (como a organização compreende sua realidade), camada semântica (representação estruturada dos conceitos e relações), camada lógica (entidades com atributos e relacionamentos) e camada tecnológica (sistemas, tabelas, APIs, aplicações). A ontologia não contém os modelos de dados nem os sistemas — ela fornece uma camada de significado que os conecta, aumentando a rastreabilidade e permitindo que negócio e tecnologia usem uma referência conceitual comum.

8. Boas Práticas e Erros Comuns na Modelagem de Ontologias

Boas práticas incluem: começar pequeno (escolha um domínio específico e resolva um problema concreto), falar a linguagem do negócio (evite termos técnicos ou acadêmicos), evitar complexidades desnecessárias (pergunte se cada elemento realmente ajuda a resolver o problema), colaborar com especialistas (validação contínua com o negócio), documentar definições (fonte única da verdade acessível a todos) e manter a ontologia viva (revisão contínua). Os erros mais comuns: tentar modelar a organização inteira; ignorar especialistas do negócio; criar modelos excessivamente complexos; confundir ontologia com modelo de dados; não definir responsáveis; e tratar a ontologia como um projeto com início e fim, em vez de processo contínuo. Uma ontologia mal elaborada continuará fraca mesmo com ferramentas avançadas — o mais importante é que o modelo represente corretamente o conhecimento do negócio.

9. Interoperabilidade Semântica: Conectando Significados

Interoperabilidade semântica é a capacidade de diferentes sistemas e áreas compreenderem e utilizarem informações de forma consistente. Não basta conectar sistemas tecnicamente — é preciso conectar significados. Duas aplicações podem trocar informações perfeitamente e, ainda assim, interpretar conceitos de maneiras diferentes (sistema A usa “cliente”, sistema B usa “consumidor”, sistema C usa “titular”). A ontologia atua como uma camada comum de conhecimento organizacional: em vez de cada sistema manter sua própria interpretação, todos passam a referenciar uma representação única do domínio. Isso reduz conflitos, melhora a qualidade dos dados, facilita a integração, dá coerência aos catálogos e aumenta a confiança nas informações. A inteligência artificial ampliou ainda mais essa importância: modelos de IA reproduzem resultados muito melhores quando recebem dados acompanhados de contexto e significado. Ontologias e grafos de conhecimento vêm sendo cada vez mais utilizados para enriquecer iniciativas de IA.

10. Governança e Manutenção: a Ontologia como Ativo Vivo

Uma ontologia não é uma entrega definitiva — assim como o negócio evolui, os conceitos organizacionais também evoluem. Uma ontologia sem responsáveis tende rapidamente à obsolescência. É preciso definir claramente quem cuida da ontologia (Data Owner do domínio), quem aprovará mudanças, validará conceitos e acompanhará a evolução do modelo. Mudanças devem seguir um processo formal: análise, aprovação, publicação e versionamento. O versionamento permite acompanhar a evolução, identificar alterações e compreender como o conhecimento organizacional foi refinado ao longo do tempo, facilitando auditorias e processos de governança. Indicadores de adoção e utilização ajudam a demonstrar valor e justificar investimentos. A ontologia deve ser disponibilizada com a maior acessibilidade possível para todas as áreas, promovendo adoção e geração de valor. O papel das ontologias tende a crescer com Data Fabric, Data Mesh e a ascensão da IA, que exigem estruturas capazes de descrever o conhecimento de forma organizada e compreensível.

1. Princípios Fundamentais dos Produtos de Dados

Dados como ativos de negócio: os dados deixam de ser apenas suporte transacional e passam a gerar valor por si mesmos para a organização.
Foco no uso e na geração de valor: o produto de dados existe para atender a casos de uso e gerar valor, não apenas para armazenar informação.
Abstração da complexidade técnica: a pessoa consumidora não deve se preocupar com sistemas de origem, tabelas ou acessos; a plataforma e a engenharia escondem essa complexidade.
Responsabilidade compartilhada: o negócio é o responsável primário pelos dados (Data Owner), a área técnica garante a proteção e o CDO responde em última instância.
Federalização das capacidades: as habilidades de dados se distribuem para as áreas de negócio, reduzindo o gargalo central e aproximando os dados de quem os utiliza.
Catálogo e marketplace como vitrine: produtos de dados precisam ser descobertos e acessados por meio de um catálogo semelhante a um marketplace.
Pensamento de produto aplicado ao dado: gestão de custos, melhoria contínua, casos de uso definidos e monetização fazem parte do ciclo de vida do produto de dados.
Qualidade e metadados completos: um produto de dados só gera valor se os dados forem confiáveis e os metadados forem ricos e autoexplicativos.
Alinhamento estratégico: implementar produtos de dados apenas por moda, sem alinhamento com a estratégia da empresa, tende ao fracasso.

2. A Transição do Valor dos Dados: do Transacional ao Produto

No passado, os dados eram usados exclusivamente por áreas técnicas para suportar processos transacionais. Com a percepção de que os dados geram valor por si mesmos, as áreas de negócio passaram a demandar cada vez mais dados, criando um gargalo na área técnica central. A resposta foi a diversificação de papéis (analistas, cientistas, engenheiros de dados) e a federalização das capacidades para as unidades de negócio. É nesse contexto que surge o conceito de produto de dados: os dados deixam de ser um ativo tecnológico e passam a ser um ativo da organização, orientado ao uso e à geração de valor.

3. Ownership e Responsabilidade: Quem Responde pelos Dados

A responsabilidade pelos dados é central para a governança. A resposta curta é: o negócio é o responsável pelos dados, representado pela figura do Data Owner. Em última instância, o Chief Data Officer (CDO) responde legalmente perante as autoridades. Mas a responsabilidade é compartilhada: a pessoa consumidora deve sinalizar erros e dados pessoais não marcados; a área técnica atua como garantidora da proteção, assegurando anonimização e capacidades de segurança. Com a federalização, a governança também se federaliza: as responsabilidades se distribuem entre as áreas de negócio e a plataforma central.

4. Dados como Produtos: As Três Esferas da Data Mesh

A Data Mesh propõe tratar dados como produtos por meio de três esferas: a esfera tecnológica (disponibilidade de acesso e qualidade dos dados), a esfera de domínio (definições de negócio, contexto e casos de uso) e a esfera de acesso (camada de delivery ou serving layer que facilita o consumo). Além disso, o pensamento de produto exige gestão de custos, melhoria contínua e definição de como monetizar os dados — não necessariamente vendê-los, mas criar capacidade para que outras áreas extraiam valor. O data marketplace funciona como a vitrine onde os produtos são publicados e avaliados pelas pessoas consumidoras.

5. Vantagens dos Produtos de Dados: Menos Complexidade, Mais Valor

No modelo clássico, acessar dados exige solicitar acesso ao sistema, à base e à tabela — um processo lento e frustrante, especialmente em empresas com dezenas de sistemas de origem. Com produtos de dados, a pessoa cliente não precisa saber em qual sistema o dado está, quem é o responsável pelo acesso ou como combiná-lo com dados de outras áreas. A preocupação muda para questões de valor e conformidade: estes são os dados de que precisamos? Que uso queremos dar? Esse uso está de acordo com as regras da instituição e as regulamentações? O produto de dados abstrai a complexidade técnica e direciona o foco para a geração de valor.

6. Definição e Características de um Produto de Dados

Um produto de dados é uma forma de entregar diferentes capacidades relacionadas a dados, com foco nas possibilidades de uso e geração de valor, abstraindo questões técnicas para a pessoa consumidora final por meio de um catálogo semelhante a um marketplace. Suas características técnicas incluem completude e qualidade de metadados, monitoramento da qualidade dos dados, capacidade de adaptação às necessidades do negócio e SLAs/contratos de dados. Sob a perspectiva de negócio, destacam-se a documentação dos casos de uso, a definição clara de atores, as definições de negócio relevantes (termos, contexto, categorias) e a integração dos contratos de dados. A diferença entre um produto com e sem definições de negócio é enorme — como o rótulo de um alimento que orienta o consumo.

7. Tipos de Produtos de Dados: Agregação e Níveis de Análise

Os produtos de dados podem ser classificados por nível de agregação (quanto maior a agregação, mais específico o uso) e por tipo de análise: descritivo (mostra o que ocorreu), diagnóstico (busca causa e efeito), preditivo (prevê resultados futuros) e prescritivo (recomenda ações). Quanto mais avançado o nível, maior a complexidade técnica e a dependência de outros produtos de dados. A maturidade organizacional deve evoluir gradualmente: primeiro a boa qualidade no descritivo, depois o diagnóstico, o preditivo e, por fim, o prescritivo. O valor não está no nível de agregação em si, mas na importância do caso de uso para o qual o produto gera valor.

8. IA como Produto de Dados: Semelhanças e Cuidados Específicos

Soluções de IA podem e devem ser tratadas como produtos de dados, permitindo que sejam consumidas com abstração da complexidade técnica, atores bem definidos, controle de casos de uso e SLAs. Exemplos incluem verificação de identidade por foto e tokenização de palavras. No entanto, há cuidados específicos: explicabilidade do modelo (especialmente em setores regulados, como crédito), controle de viés, documentação dos tipos de entrada e saída, idiomas suportados e melhores práticas para evitar alucinações em IA generativa. O enfoque de produto aproveita todas as capacidades da plataforma de dados para incluir iniciativas de IA no catálogo organizacional.

9. Criando e Enriquecendo um Produto de Dados na Prática

O processo começa pela escolha dos dados de origem e pela definição do objetivo de negócio. No exemplo do curso, a equipe de vendas de uma empresa de eletrônicos criou um produto que combina a base de compras com a base mestra de produtos para analisar o peso das compras — testando hipóteses sobre limites de peso que impedem compras em lojas físicas. O enriquecimento envolve documentar responsabilidades (Data Owner), definir nome e descrição claros, mapear casos de uso pretendidos, identificar prováveis consumidores, definir filtros técnicos, palavras-chave e indicadores de qualidade. O contexto de negócio — termos relevantes, domínio, definição de “compra”, granularidade — é essencial para reduzir ambiguidades. Produtos de dados são vivos: é com o uso que o contexto evolui e o produto se aprimora.

10. Avaliação de Maturidade com o DATSYS

O DATSYS é um padrão surgido no contexto da Data Mesh para avaliar a qualidade de um produto de dados em cinco dimensões: discoverable (localizável — é fácil encontrar o produto no marketplace?), addressable (endereçável — existe um ponto de acesso único, claro e bem definido? Há contato claro em caso de necessidade?), trustworthy (confiável — podemos confiar na qualidade dos dados e dos metadados?), self-describing (autodescritivo — a documentação é suficiente para usar o produto sem depender do criador?) e interoperable (interoperável — é simples combinar esse produto com outros dados da organização, usando IDs únicos e dados mestres?). A avaliação responde a perguntas práticas sobre acesso, proteção de dados pessoais e integração, permitindo medir o quão maduro é o produto de dados criado.

Ontologias e Governança de Dados: Modelagem e Interoperabilidade Semântica