Camada Semântica para IA Agêntica na AWS com Stardog e Amazon Bedrock AgentCore

O problema que a IA agêntica ainda não resolveu sozinha

A promessa dos agentes de IA para análise de dados é clara: em vez de esperar na fila por um relatório, o usuário faz a pergunta e o agente busca a resposta diretamente nos sistemas da empresa. Mas há um obstáculo que os modelos de linguagem, por mais capazes que sejam, não conseguem superar sozinhos: os dados corporativos são fragmentados, inconsistentes e cheios de definições conflitantes.

O “cliente” no sistema de CRM não é o mesmo registro que o “cliente” no sistema de faturamento. A “receita” calculada pelo time da América do Norte pode ser um número diferente do que o time europeu produziria. Um agente com acesso direto a esses dados fragmentados vai gerar respostas tecnicamente válidas, mas erradas ou contraditórias. A confiança no sistema se desfaz na primeira vez que dois agentes retornam números diferentes para a mesma pergunta.

É exatamente esse gap que a AWS endereça em um post técnico recente, mostrando como construir uma camada semântica sobre Amazon Aurora e Amazon Redshift usando o Stardog, e como executar um agente baseado em Strands Agents no Amazon Bedrock AgentCore para consultar essa camada.

RAG não é suficiente para análise de dados

A abordagem mais conhecida para conectar modelos de linguagem a dados corporativos é a Geração Aumentada por Recuperação (RAG): documentos são indexados no Amazon Bedrock Knowledge Bases e trechos relevantes são injetados no contexto do modelo na hora da consulta. RAG funciona bem quando a resposta está em um texto que a busca consegue encontrar.

O problema aparece nas perguntas analíticas: quando a resposta depende de cruzar registros ao vivo entre sistemas diferentes, aplicar uma regra de negócio de forma consistente e respeitar políticas de acesso por linha ou coluna. Nesses casos, o que está faltando não é texto — é contexto de negócio e definição de métricas.

Uma camada semântica não substitui o RAG. Ela o complementa. A maioria dos sistemas em produção precisa dos dois, acessíveis pelo mesmo agente.

O que é uma camada semântica baseada em grafo de conhecimento

Uma camada semântica é uma visão orientada a ontologia dos dados corporativos. A ontologia captura os conceitos, relacionamentos, atributos e regras que importam para o negócio. Mapeamentos declaram como esses conceitos correspondem a linhas nas fontes de dados reais. O agente consulta a camada; a camada traduz cada consulta em SQL contra os sistemas subjacentes em tempo de execução. Os dados permanecem onde estão. O significado é capturado uma vez e reutilizado.

Quando essa camada semântica é implementada como o Stardog faz — com uma ontologia, identificadores estáveis para cada entidade, regras que derivam novos fatos e restrições que validam os dados — o resultado é um grafo de conhecimento. Os dados são conectados como um grafo de entidades de negócio em vez de linhas em tabelas. Cada entidade recebe um identificador único no estilo URL chamado IRI, e as consultas percorrem essas conexões em uma linguagem padronizada pelo W3C chamada SPARQL.

Dois conceitos são centrais na arquitetura descrita:

Grafo nomeado: um subconjunto rotulado do grafo, identificado por seu próprio IRI. O Stardog usa grafos nomeados como unidade de controle de acesso — a mesma consulta retorna resultados diferentes para papéis diferentes, dependendo de quais grafos cada papel pode ler.
Grafo virtual: um grafo nomeado cujo conteúdo não fica armazenado no Stardog. Ele vive em um sistema externo (Aurora, Redshift, Athena) e o Stardog busca as linhas sob demanda usando os mapeamentos.

Para quem quiser se aprofundar, o glossário do Stardog define cada um desses termos, e a série de introdução ao Stardog coloca tudo em contexto.

As três camadas que um agente confiável precisa

O post descreve três camadas que precisam funcionar juntas para que um agente de IA entregue respostas confiáveis e com contexto de negócio:

Camada de modelo: um modelo de fundação capaz de planejar e escrever consultas. O Amazon Bedrock oferece acesso a múltiplas famílias de modelos via API única. No exemplo, é usado o Anthropic Claude Sonnet 4.6. O modelo conhece linguagem — não conhece o negócio da empresa.
Camada de significado: a camada semântica, que dá ao modelo acesso confiável e governado aos dados por trás das perguntas de negócio. A ontologia declara os conceitos e as regras que derivam novos fatos. A federação puxa linhas ao vivo de cada fonte na hora da consulta. É aqui que fica o Stardog federado sobre Aurora e Redshift.
Camada de runtime do agente: o ambiente que hospeda o agente, termina requisições de entrada, gerencia credenciais de ferramentas e fornece a superfície operacional para segurança e governança. O Amazon Bedrock AgentCore é usado neste exemplo por empacotar autenticação de entrada, hospedagem e credenciais de ferramentas em um único serviço gerenciado.

Caso de uso: agente Customer 360 sobre Aurora e Redshift

O exemplo escolhido é um agente de Customer 360 (C360) para uma equipe de analytics de varejo. O agente aceita perguntas em linguagem natural de analistas de vendas, marketing ou fraude, executa as consultas nos dados da empresa e responde com uma narrativa curta mais os números de suporte. O usuário não vê SQL nem SPARQL, e o agente não acessa dados que não está autorizado a ver.

No cenário descrito, perfil de cliente, endereço, cartão de crédito e programa de recompensas ficam em um banco operacional no Amazon Aurora PostgreSQL. Pedidos, produtos, categorias e fornecedores ficam no Amazon Redshift para análise. Para responder “quem são nossos maiores compradores no Wisconsin?”, o agente precisa cruzar as duas fontes — e é exatamente isso que a camada semântica resolve.

O kit de partida utilizado é o C360 Knowledge Kit do Stardog, adaptado para federar sobre Aurora PostgreSQL (lado do cliente) e Amazon Redshift (lado de compras). O kit inclui ontologia, dados de exemplo e consultas prontas.

O que a camada semântica resolve nesse cenário

Três problemas concretos são resolvidos pela camada semântica nesse exemplo:

Joins entre sistemas por significado compartilhado: a camada mapeia registros de clientes do Aurora e do Redshift para uma identidade comum usando chaves de negócio compartilhadas. O join é expresso pelo modelo semântico, não por um pipeline de integração física que precisaria ser mantido sincronizado.
Fatos derivados como regras, não como queries: uma definição como “grande comprador” vive na ontologia como regra, não precisa ser reescrita em cada consulta. Quando o critério muda, muda em um lugar só. Sem isso, a definição se duplica em dashboards, notebooks e relatórios, e começa a divergir.
Controle de acesso no nível do grafo: a segurança por grafo nomeado controla o acesso em nível de grafo, de modo que papéis diferentes veem subconjuntos diferentes do grafo de conhecimento. Para proteção mais granular, propriedades sensíveis como :ssn e :cardNumber podem ser marcadas como protegidas — usuários com permissão veem os valores reais; os demais recebem valores mascarados por padrão.

Construindo a camada semântica: ontologia, mapeamentos e raciocínio

A ontologia

A ontologia C360 é criada no Stardog Designer, uma ferramenta visual de modelagem e mapeamento sem código. O modelador cria conceitos (:Customer, :Order, :Product), os conecta com relacionamentos e declara campos como :ssn e :cardNumber como propriedades sensíveis. Nenhum OWL ou RDF é escrito manualmente. O modelo C360 completo define aproximadamente dez classes e trinta propriedades.

O Designer também pode gerar um modelo inicial a partir de metadados de fontes existentes — como esquemas de tabelas, definições FHIR ou perguntas de competência — o que é um caminho mais rápido do que escrever o modelo do zero.

Uma vantagem de portabilidade do Designer é o uso do Turtle, a serialização padrão W3C para RDF (Framework de Descrição de Recursos) para persistir modelos. Isso evita aprisionamento tecnológico e suporta interoperabilidade: é possível importar ontologias de ferramentas como Protégé, exportar dados para serviços como Amazon Neptune e realizar fluxos de trabalho de ida e volta com outros utilitários compatíveis com RDF.

O trecho central da ontologia que sustenta a federação é simples:

:Customer a owl:Class .
:purchasedBy a owl:ObjectProperty ;
  so:domainIncludes :Order ;
  so:rangeIncludes :Customer .
:ssn a owl:DatatypeProperty, m:SensitiveProperty ;
  so:domainIncludes :Customer .

A ontologia completa está disponível no C360 Knowledge Kit.

Os mapeamentos: o bloco de construção da federação

No Designer, os mapeamentos são criados visualmente. O modelador mapeia a tabela customer do Aurora para o conceito :Customer e indica que id é a chave da entidade. O mesmo processo é feito no lado do Redshift: mapeia a tabela purchase e marca cid como chave do cliente.

A propriedade arquitetural fundamental é o template de IRI. Ambos os mapeamentos produzem o mesmo identificador para o mesmo cliente. Um cliente com cid=42 se torna urn:stardog:demos:c360:customer:42 independentemente de a linha ter vindo da tabela customer no Aurora ou da tabela purchase no Redshift. O agente vê uma entidade única. Os bancos permanecem inalterados. Nenhum SQL JOIN cruza os dois bancos — o “join” é o acordo de IRI.

Quando o Designer salva um mapeamento, ele emite o Stardog Mapping Syntax (SMS), um superconjunto do padrão W3C R2RML que usa sintaxe similar ao SPARQL. Os dois trechos que carregam o bloco de construção da federação são:

# Mapeamento Aurora (customer)
BIND(TEMPLATE("urn:stardog:demos:c360:customer:{cid}") AS ?iri)

# Mapeamento Redshift (order)
BIND(TEMPLATE("urn:stardog:demos:c360:customer:{cid}") AS ?cust_iri)

Os arquivos de mapeamento completos para todas as tabelas C360 estão no kit.

Raciocínio sobre o grafo

O Stardog suporta raciocínio OWL e regras definidas pelo usuário escritas em Stardog Rule Syntax (SRS) ou SWRL. Raciocínio é o processo de inferir novos fatos a partir de dados existentes usando o esquema.

O kit define classes derivadas como Big_Spender (um cliente que fez pelo menos um pedido acima de um limite) e Large_Order. Com o raciocínio habilitado em tempo de consulta, perguntar “quantos grandes compradores há por estado?” funciona sem precisar pré-computar ou materializar esses fatos. As regras são definidas uma vez no modelo semântico e avaliadas sobre dados ao vivo quando a consulta é executada.

Governança de acesso com segurança por grafo nomeado

Dados de Customer 360 são regulados. Dois requisitos aparecem cedo: alguns usuários (RH, fraude) precisam ver informações de identificação pessoal (PII) como CPF e número completo de cartão; a maioria dos usuários (marketing, analytics) não pode. E o controle não deve exigir mudanças nos bancos subjacentes.

O mecanismo do Stardog para isso é a segurança por grafo nomeado. No exemplo, o mapeamento do Aurora é dividido em dois grafos virtuais:

aurora_c360_safe: perfil do cliente sem PII (tudo exceto :ssn e :cardNumber).
aurora_c360_pii: apenas os triplos de PII, vinculados ao mesmo IRI de cliente.

O mapeamento do Redshift é um único grafo: redshift_c360. Dois papéis são criados: hr_user com leitura nos três grafos virtuais, e marketing_user com leitura apenas em aurora_c360_safe e redshift_c360.

Quando o marketing_user executa uma consulta SPARQL pedindo ?c :ssn ?ssn, o planejador do Stardog trata aurora_c360_pii como se não existisse para aquele usuário. O pushdown JDBC para a coluna SSN simplesmente não acontece. Mesma consulta SPARQL, dois papéis, dois conjuntos de resultados diferentes — sem filtro no nível da aplicação, sem mudança no banco, sem risco de vazamento por uma ferramenta de BI mal configurada.

Para casos em que campos sensíveis estão espalhados por muitas entidades, o Stardog também suporta marcar propriedades individuais como sensíveis na ontologia, com a marcação acionando mascaramento em nível de coluna em tempo de consulta. Veja a documentação de segurança granular do Stardog para os passos de configuração.

Executando o agente e os dois caminhos de integração com o Stardog

O agente é construído com o Strands Agents: um script Python curto conecta o Claude Sonnet 4.6 (no Amazon Bedrock) a uma ferramenta que executa SPARQL contra o Stardog. Um resumo da ontologia é carregado no prompt de sistema do agente. O modelo escreve SPARQL, a ferramenta retorna linhas, o modelo resume os resultados.

Para produção, a recomendação é implantar no Amazon Bedrock AgentCore, que empacota o scaffolding operacional em um serviço gerenciado: o AgentCore Runtime hospeda o agente e gerencia concorrência e estado de sessão; o AgentCore Gateway é a superfície de entrada que valida o Token Web JSON (JWT) do provedor de identidade e roteia a chamada para o Runtime; o AgentCore Identity mantém o token do Stardog como provedor de credencial, de modo que a credencial não fica no código do agente.

Dois caminhos de integração são descritos:

Caminho A — ferramenta SPARQL direta: uma pequena ferramenta Python envolve o cliente pystardog e é exposta ao agente via decorator de ferramenta do Strands. O agente escreve SPARQL, a ferramenta executa, a ferramenta retorna linhas. Funciona em instâncias Stardog acessíveis via HTTPS, incluindo o nível gratuito do Stardog Cloud. Este foi o caminho usado no POC porque não exige habilitação especial na conta Stardog.
Caminho B — servidor MCP do Stardog Cloud como alvo de ferramenta no Gateway: o Stardog publica um servidor MCP oficial, stardog-union/stardog-cloud-mcp, que expõe o Voicebox (camada de consulta em linguagem natural do Stardog) como três ferramentas: voicebox_ask, voicebox_generate_query e voicebox_settings. O AgentCore Gateway pode registrar esse servidor MCP como alvo de ferramenta, o que significa que o agente dentro do Runtime enxerga o Voicebox como uma ferramenta sem código de cola, e o AgentCore Identity injeta o token no salto do Gateway. O modo local do servidor MCP é estável; o modo remoto está em beta. O Caminho B também exige um token de API do Voicebox, que é restrito a contas específicas.

A recomendação é usar o Caminho A quando não há acesso à API ou quando se quer controle total sobre a geração de SPARQL. Usar o Caminho B quando há acesso à API e se quer a cadeia de raciocínio e proveniência do Voicebox.

Para implantações em produção, também é recomendado habilitar o cache de prompts do Amazon Bedrock. O agente reutiliza o mesmo prompt de sistema extenso — o resumo da ontologia C360 — em cada chamada. O cache de prompts mantém essa porção aquecida entre chamadas, reduzindo o custo de tokens de entrada em invocações repetidas.

Consultas de verificação e extensibilidade

Para confirmar que a federação funcionou como projetado, três categorias de perguntas foram executadas contra a implantação ao vivo:

Somente Aurora: “Liste dez clientes e seus estados.” O Stardog emite uma consulta SQL contra as tabelas do Aurora e retorna as linhas. O grafo virtual do Redshift não é tocado.
Somente Redshift: “Top dez produtos por unidades vendidas.” O Stardog emite uma agregação contra a tabela de compras do Redshift. O Aurora não é tocado.
Federado: “Top dez maiores compradores, com seus estados.” Essa consulta precisa cruzar clientes do Aurora com pedidos do Redshift pelo IRI compartilhado de cliente. O Stardog emite uma consulta SQL para cada fonte, recebe os dois conjuntos de resultados e os une pela variável ?cust — o IRI mapeado a partir do cid em cada lado.

O caso de raciocínio também foi verificado: “quantos grandes compradores há por estado?” com raciocínio habilitado. O Stardog aplicou a regra Big_Spender sobre o grafo federado em tempo de consulta e retornou contagens por estado sem pré-computar ou materializar a classe derivada.

Para governança, a mesma consulta SPARQL foi executada duas vezes — uma como hr_user e outra como marketing_user. O papel de RH viu o valor do SSN vinculado. O papel de marketing recebeu a mesma estrutura de linha com o binding ?ssn vazio, sem mudança no texto da consulta e sem filtro no lado do banco.

Extensibilidade: além do Aurora e Redshift

O mecanismo de grafo virtual do Stardog não é específico para Aurora ou Redshift. Para adicionar uma nova fonte, o modelador trabalha no Stardog Designer e gera o mapeamento SMS. Enquanto os novos mapeamentos produzirem IRIs que correspondam aos existentes para a mesma entidade lógica, a nova fonte passa a participar do grafo federado sem alterar a ontologia ou as consultas existentes.

Na AWS, isso inclui Amazon Athena (data lake no Amazon S3) e engines do Amazon RDS que fornecem driver JDBC. Fora da AWS, inclui Snowflake, Google BigQuery, MongoDB e SAP HANA. A lista completa está na página de fontes de dados suportadas pelo Stardog.

Quanto à implantação do próprio Stardog, há dois formatos: Stardog Cloud (SaaS), operado pela Stardog com SLAs de 99,9% e conformidade SOC 2, indicado para quem quer pular a operação; e autogerenciado no Amazon EKS, com imagens de container e Helm charts fornecidos pelo Stardog, indicado para quem precisa manter o tráfego do plano de dados dentro da VPC ou controlar o ciclo de atualizações. Em ambos os casos, os grupos de segurança das fontes de dados precisam permitir conexões de entrada a partir do intervalo de IPs de saída do Stardog Cloud. A documentação de allowlist de chamadas de grafo virtual do Stardog Cloud traz os valores atuais e os passos de configuração.

Por onde começar

A maioria das equipes que consegue colocar essa arquitetura em produção começa com um único fluxo de trabalho, não com uma implantação ampla. A sequência prática sugerida é:

Escolher um fluxo de trabalho que hoje é respondido lentamente porque os dados estão em dois ou três sistemas. Quanto mais estreito, melhor.
Escrever de três a cinco perguntas de competência que o fluxo precisa responder. Essas são as consultas que a camada semântica precisa suportar no primeiro dia.
Inicializar a ontologia a partir dos esquemas de fonte no Designer e refiná-la contra as perguntas de competência até que cada uma retorne uma resposta coerente.
Configurar a federação como grafos virtuais sobre as fontes ao vivo. Sem ETL, sem terceira cópia dos dados.
Conectar o agente à camada pelo Caminho A ou B, dependendo do acesso à API do Voicebox.

O Stardog C360 Knowledge Kit é um ponto de partida útil — é o mesmo kit adaptado no post original.

Fonte

Build a semantic layer for agentic AI on AWS with Stardog and Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/build-a-semantic-layer-for-agentic-ai-on-aws-with-stardog-and-amazon-bedrock-agentcore/)