Ontologias para agentes de IA: o contrato que falta entre modelo, memória e ferramentas

Um agente de IA recebe um pedido como “renove o contrato do cliente, mas não ultrapasse o orçamento aprovado”. Para um humano, isso esconde um monte de conhecimento: quem é o cliente, que documento vale como contrato, qual orçamento está vigente, o que significa renovar, quem pode aprovar uma exceção e qual sistema pode executar cada etapa.

Para um LLM, quase tudo isso chega como texto. Ele pode acertar muito. Mas também pode chamar a ferramenta errada, confundir dois identificadores parecidos, tratar uma sugestão como aprovação ou produzir uma resposta plausível que não pode ser executada com segurança.

É aqui que uma ontologia volta a ser interessante. Não como um projeto acadêmico para classificar o mundo inteiro, mas como o contrato semântico mínimo de um domínio: os tipos de coisas que existem, como se relacionam, quais estados importam e quais combinações são inválidas.

Quando agentes compartilham esse contrato, o modelo deixa de ser a única fonte de coerência. O LLM continua interpretando linguagem, planejando e lidando com ambiguidade; a ontologia passa a sustentar identidade, relações, regras e verificação.

O que uma ontologia acrescenta a um agente

Uma ontologia é um vocabulário formal de um domínio e das relações entre seus termos. A definição da W3C é especialmente útil: ela descreve ontologias como vocabulários formalizados de termos, normalmente para um domínio específico e uma comunidade, com definições expressas por relações entre os termos. OWL 2 traz classes, propriedades, indivíduos e valores de dados para representar isso.

Isso é diferente de quatro coisas que costumam ser misturadas:

• Prompt: instrução temporária para o modelo. Pode mencionar que uma fatura precisa de aprovação, mas não torna essa regra consultável nem verificável fora da conversa.
• Schema de API: contrato de forma. Diz que um campo é string ou que uma operação aceita certos parâmetros; em geral não diz que uma Renovacao está ligada a um Contrato vigente e depende de uma Aprovacao.
• Base vetorial: mecanismo ótimo para recuperar texto semelhante. Não é, por si só, uma fonte de identidade, tipagem e relações explícitas.
• Grafo de conhecimento: os fatos concretos: “este contrato pertence a esta conta”, “este orçamento expira em tal data”. A ontologia é a semântica que torna esses fatos comparáveis e interpretáveis.

Na prática, o agente precisa dos dois últimos. O grafo guarda instâncias e evidências; a ontologia define como elas podem ser entendidas. RDF modela esses fatos como triplas de sujeito, predicado e objeto. OWL acrescenta uma camada para expressar classes e relações com significado formal. Um reasoner pode então derivar consequências simples, como reconhecer que uma RenovacaoEnterprise também é uma Renovacao porque a primeira é subtipo da segunda.

O ganho não é “dar mais inteligência” ao modelo. É retirar do texto livre uma parte do conhecimento que precisa continuar estável entre sessões, ferramentas e agentes.

O teste: uma pergunta que precisa da mesma resposta amanhã

Uma boa maneira de decidir se algo merece entrar na ontologia é perguntar: se outro agente recebesse a mesma pergunta amanhã, ele precisaria chegar à mesma interpretação operacional?

“Qual tom devo usar neste e-mail?” provavelmente não. Isso pertence ao prompt, às preferências do usuário e ao contexto recuperado.

“Este pedido pode consumir o orçamento do centro de custo X?” provavelmente sim. Há entidades identificáveis, relações duráveis, estados e uma ação que pode causar efeito externo.

Para um agente de atendimento e operações, um recorte inicial pode ser pequeno:

Esse vocabulário é mais útil do que uma taxonomia enorme. Ele dá nomes estáveis ao que as ferramentas recebem e devolvem, à memória que os agentes registram e às regras que precisam ser testadas.

A arquitetura que funciona: LLM para linguagem, ontologia para compromisso

O erro comum é tentar substituir o LLM por um sistema simbólico, ou fingir que o LLM seguirá regras críticas apenas porque elas foram escritas no system prompt. O desenho mais robusto é híbrido:

pedido em linguagem natural
          |
          v
LLM: interpreta, pergunta o que falta e propõe um plano
          |
          v
resolver de entidades + grafo de conhecimento
          |
          v
ontologia + regras: tipos, relações e políticas aplicáveis
          |
          v
validador: aprova, bloqueia ou pede revisão humana
          |
          v
ferramenta estreita executa a ação e grava evidência

O LLM está no começo porque linguagem humana é vaga e contextual. Ele pode transformar “renove o contrato da Acme” em uma proposta estruturada, mas não deve inventar o ID do contrato nem decidir silenciosamente qual “Acme” é a correta.

O resolvedor de entidades procura candidatos no grafo e devolve identificadores, confiança e evidência. Se houver duas contas com o mesmo nome, o agente pergunta. Isso é uma melhora de produto: uma pergunta de desambiguação é melhor que uma automação errada com fluência impecável.

No fim, a ferramenta recebe uma intenção já tipada e validada. Em vez de expor execute_anything(payload), ela pode expor criar_renovacao(contrato_id, proposta_id, aprovacao_id). Ferramentas estreitas reduzem a superfície em que o modelo precisa improvisar.

OWL não é seu validador de produção

OWL é valioso para modelar vocabulário e inferir relações, mas seu modelo de mundo não é o mesmo de uma transação de negócios. Em particular, a semântica aberta não permite concluir que algo é falso só porque o grafo não o menciona. A ausência de uma aprovação no grafo não é automaticamente a prova formal de que ela não existe.

Para guardrails operacionais, use validação explícita. SHACL 1.2 descreve shapes que definem a estrutura esperada de grafos RDF e podem ser usados para validação, inferência, integração e geração de código. É exatamente a separação útil aqui:

• ontologia: “o que significa ser uma Renovação e quais relações existem”;
• shapes: “para executar uma Renovação, preciso de exatamente um contrato, uma aprovação e uma evidência válida”;
• política de aplicação: “quem pode aprovar, em qual limite, e em qual sistema”.

Um exemplo reduzido, em Turtle, poderia declarar a forma da ação:

@prefix ex: <https://empresa.example/agent#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .

ex:RenovacaoProntaParaExecucao
  a sh:NodeShape ;
  sh:targetClass ex:Renovacao ;
  sh:property [
    sh:path ex:renovaContrato ;
    sh:class ex:ContratoVigente ;
    sh:minCount 1 ; sh:maxCount 1
  ] ;
  sh:property [
    sh:path ex:temAprovacao ;
    sh:class ex:AprovacaoValida ;
    sh:minCount 1 ; sh:maxCount 1
  ] .

Essa validação não decide se o preço é bom. Ela impede que a camada de execução trate uma renovação incompleta como uma operação pronta. O resultado da validação deve voltar ao agente como dados estruturados, com mensagens adequadas para ele pedir o item que falta ou encaminhar o caso.

Comece pelos pontos de atrito, não pelos substantivos

Construir ontologia não é fazer uma lista bonita de entidades. O caminho mais seguro começa onde um agente realmente falha ou onde errar custa caro:

1. Escolha uma decisão ou ação externa específica, por exemplo, aprovar reembolso, provisionar acesso ou alterar uma assinatura.
2. Reúna exemplos reais, inclusive exceções. Quais nomes eram ambíguos? Que aprovação faltou? Qual estado tornou a ação inválida?
3. Modele apenas as classes, propriedades e estados que explicam essas decisões.
4. Defina identificadores canônicos e mapeamentos para os sistemas de origem. “Cliente” sem uma estratégia de identidade continua sendo um rótulo.
5. Escreva shapes e políticas antes de conectar a ação de escrita.
6. Rode casos positivos, negativos e de ambiguidade. Meça não só a taxa de sucesso, mas a taxa de bloqueios corretos e de perguntas de esclarecimento úteis.

O passo seis é onde muitos projetos param cedo demais. Um agente que executa uma ação válida não prova nada sozinho. A avaliação precisa conter também fatos faltando, entidades homônimas, relações conflitantes, dados desatualizados e tentativas de fazer a ferramenta aceitar um objeto fora do contrato.

Memória de agente não deveria ser apenas um diário em texto

Memória em texto é flexível e indispensável para raciocínio qualitativo: contexto de uma reunião, uma decisão ainda incerta, uma explicação do usuário. Mas, quando memória contém fatos operacionais, ela precisa de proveniência.

Em vez de guardar apenas “o cliente aceitou a renovação”, o agente pode registrar algo equivalente a:

Renovacao 123 --temAprovacao--> Aprovacao 456
Aprovacao 456 --extraidaDe--> Documento 789
Documento 789 --publicadoEm--> 2026-07-30

Isso permite responder “por que você fez isso?” com uma cadeia verificável, não com uma reconstrução provável do raciocínio. Também permite invalidar fatos derivados de uma fonte revogada sem apagar toda a memória do agente.

O ponto é governança, não apenas recuperação. Todo fato que afeta uma ação deve carregar, quando possível, origem, horário de observação, escopo e nível de confiança. Se o LLM extraiu o dado de um PDF, isso é diferente de um estado consultado diretamente na API financeira.

Quando não usar ontologia

Não transforme todo assistente em um projeto de web semântica.

Ontologias são custo de produto: alguém precisa decidir termos, versionar mudanças, mapear fontes, documentar exceções e manter compatibilidade. Para tarefas abertas, como resumir uma conversa, explorar ideias, gerar rascunhos ou responder sobre documentos não estruturados, RAG e bons prompts costumam bastar.

O investimento começa a pagar quando há pelo menos um destes sinais:

• mais de um agente, time ou ferramenta precisa usar os mesmos conceitos;
• ações têm autorização, dinheiro, acesso, segurança ou conformidade envolvidos;
• a entidade correta é mais importante do que a frase mais parecida;
• é preciso explicar, reproduzir ou auditar uma decisão;
• regras de negócio aparecem repetidas em prompts, código de integração e planilhas.

Mesmo nesse cenário, comece pequeno. Uma ontologia que cobre um fluxo crítico e é realmente aplicada é melhor que um grafo “universal” que ninguém consulta.

O objetivo é tornar a incerteza visível

Agentes de IA não precisam de uma enciclopédia do mundo para serem úteis. Precisam saber com precisão suficiente sobre o que estão falando, de onde veio cada fato e quando devem parar de agir.

Essa é a contribuição mais concreta de uma ontologia. Ela troca parte da confiança implícita no texto gerado por um contrato explícito entre modelos, memória, ferramentas e pessoas. O LLM continua sendo a interface adaptável; o grafo fornece estado; as regras fornecem limites; e a auditoria transforma a automação em algo que pode ser operado.

Em sistemas que só sugerem, isso pode parecer excesso. Em sistemas que decidem, escrevem e movimentam recursos, é infraestrutura de confiabilidade.