Interoperabilidade não é apenas conectar APIs

Em 30 segundos

• Conectividade (HTTP, API, JSON válido) é uma camada da interoperabilidade — não o todo.
• Campos com o mesmo nome podem ter significados diferentes; campos com nomes diferentes podem ser a mesma coisa.
• A ciência estuda esse problema há 25 anos (schema matching, ontology matching) e ele continua aberto — inclusive com IA.
• Interoperabilidade de verdade exige contrato + semântica + contexto + governança + evidência, em dose proporcional ao risco.

1. A integração que “funciona” — e mesmo assim está errada

Imagine uma integração aparentemente perfeita.

O Sistema A envia:

{
  "customer_id": "123",
  "status": "ACTIVE",
  "amount": 100.0,
  "currency": "BRL"
}

O Sistema B recebe e trabalha com:

{
  "client_code": "123",
  "situation": 1,
  "total": 100.0,
  "currency": "BRL"
}

A chamada HTTP funcionou. A autenticação funcionou. O JSON foi lido. O schema passou na validação. O log mostra 200 OK.

Então está tudo certo?

Ainda não. Precisamos responder perguntas que o protocolo, sozinho, não resolve:

• customer_id e client_code identificam a mesma entidade?
• ACTIVE significa exatamente o mesmo que situation = 1?
• amount e total representam valor bruto, líquido, autorizado, faturado ou pago?
• BRL resolve apenas a moeda — ou também precisamos saber data de referência, arredondamento e regra contábil?
• Quem definiu essas equivalências?
• O que acontece se um dos sistemas mudar sua regra amanhã?

2. Conectividade é uma camada da interoperabilidade — não o todo

A palavra interoperabilidade costuma ser reduzida a “sistemas que se conectam”. Essa visão é útil, mas incompleta.

Uma forma didática de enxergar o problema é subir uma escada. Cada degrau responde a uma pergunta diferente — e nenhum substitui o anterior.

A pergunta muda em cada degrau

Essa escada é uma síntese didática, não uma nova taxonomia normativa. O European Interoperability Framework, por exemplo, trabalha formalmente com quatro camadas — técnica, semântica, organizacional e legal — além de elementos de governança. Voltaremos a ele na seção 7.

3. Então para que servem as APIs? Para muita coisa — e elas continuam essenciais

Dizer que interoperabilidade não é apenas conectar APIs não significa diminuir a importância das APIs.

APIs resolvem uma parte crítica do problema: criam uma interface previsível entre sistemas.

A OpenAPI Specification 3.2.0, publicada em 19 de setembro de 2025 e ainda a versão mais recente publicada, define uma descrição padronizada e independente de linguagem para HTTP APIs. Isso ajuda pessoas e ferramentas a descobrir operações, parâmetros, mensagens e capacidades sem precisar inspecionar o código-fonte.

O JSON Schema 2020-12 é igualmente valioso: permite declarar e validar restrições estruturais de dados. Podemos exigir que um campo seja string, número, obrigatório, pertença a um conjunto, siga determinado padrão e assim por diante.

4. Os campos podem ter o mesmo nome e significados diferentes

O problema não acontece apenas quando os nomes são diferentes. Veja a palavra status.

O texto é igual. O significado não é.

O inverso também acontece: palavras diferentes podem representar a mesma coisa. customer, client, consumer, citizen ou insured_person podem ou não apontar para o mesmo conceito dependendo do domínio.

Cinco ambiguidades escondidas em dados aparentemente simples

5. A ciência estuda esse problema há décadas

A dificuldade de fazer sistemas heterogêneos “entenderem a mesma coisa” não surgiu com microsserviços, APIs REST ou agentes de IA.

Schema matching

Em 2001, Erhard Rahm e Philip Bernstein publicaram um survey clássico sobre schema matching, mostrando que relacionar estruturas heterogêneas envolve abordagens em nível de schema e de instância, de elemento e de estrutura, de linguagem e de restrições. O artigo se tornou uma das principais referências da área de integração de dados. Rahm & Bernstein, 2001

Conflitos semânticos

Em 2004, Jinsoo Park e Sudha Ram estudaram o que existe “por baixo” da interoperabilidade entre sistemas de informação heterogêneos. O trabalho destaca a importância de identificar conflitos semânticos e construir conhecimento de mapping entre schemas e ontologias. Park & Ram, 2004

Sintaxe não é semântica

Shvaiko e Euzenat organizaram técnicas de matching distinguindo abordagens sintáticas, semânticas e baseadas em conhecimento externo. Isso é importante porque comparar strings, nomes de colunas e formatos é apenas uma parte do problema. Shvaiko & Euzenat, 2005

O contexto frequentemente está fora do schema

Um survey de Portisch, Hladik e Paulheim mostra que schemas e ontologias frequentemente são incompletos do ponto de vista semântico porque foram construídos dentro de contextos que não aparecem explicitamente no modelo. Por isso, conhecimento externo pode ser necessário para descobrir correspondências. Portisch, Hladik & Paulheim, 2022

6. Um caso real: saúde, FHIR e o desafio de “falar a mesma língua”

Saúde é um ótimo domínio para perceber a diferença entre padrão de troca e significado compartilhado.

O FHIR (Fast Healthcare Interoperability Resources) padroniza formas de representar e trocar recursos clínicos. Isso é uma enorme evolução para interoperabilidade técnica e estrutural.

Mas a existência do padrão não elimina automaticamente diferenças em terminologias clínicas, códigos, unidades, perfis, classificações e modelos locais.

Uma revisão sistemática de mapeamento publicada em 2024 analisou estudos sobre problemas semânticos envolvendo FHIR. A busca utilizou 10 bases eletrônicas e resultou em 70 estudos selecionados. Entre 126 ocorrências de abordagens semânticas, os autores encontraram mapping, RDF/OWL, ML/NLP, serviços terminológicos, annotations e ontologias. Amar, April & Abran, 2024

O que esse gráfico ensina?

Se apenas “usar FHIR” resolvesse toda a interoperabilidade semântica, não seria necessário manter uma diversidade tão grande de técnicas complementares.

7. Interoperabilidade também acontece entre organizações — não apenas entre softwares

Imagine dois órgãos públicos que usam a mesma API, os mesmos campos e a mesma terminologia. Ainda pode existir um bloqueio:

• um órgão considera determinado evento oficial apenas após assinatura; o outro considera o evento válido na criação;
• um pode legalmente compartilhar determinado dado; o outro só pode processá-lo para finalidades específicas;
• as responsabilidades de atualização podem ser diferentes.

Nesse ponto, o problema deixou de ser apenas técnico.

O European Interoperability Framework (EIF) organiza o tema em quatro camadas formais — legal, organizacional, semântica e técnica — envolvidas por uma governança de interoperabilidade. O EIF define interoperabilidade semântica como a preservação e compreensão do formato e do significado precisos da informação durante a troca: aquilo que é enviado deve ser compreendido pelas partes. EIF — Interoperability layers

E no Brasil?

A ePING — Padrões de Interoperabilidade de Governo Eletrônico também considera explicitamente dimensões técnica, semântica e organizacional. Na dimensão semântica, a orientação envolve organização e intercâmbio de informações e o uso de instrumentos como vocabulários, taxonomias e ontologias. ePING — Governo Digital

8. O custo de não interoperar pode ser enorme

Interoperabilidade não é apenas uma preocupação elegante de arquitetura. Ela afeta retrabalho, tempo, integração manual, qualidade dos serviços e capacidade de cooperação.

Na avaliação de impacto que embasou a política europeia de interoperabilidade, a Comissão Europeia ressaltou que o impacto direto é difícil de quantificar. Ainda assim, um estudo do Joint Research Centre estimou um grande potencial de economia associado a melhorias de interoperabilidade.

Fonte: European Commission — Impact Assessment SWD(2022) 722.

9. O que usamos para construir interoperabilidade semântica?

Não existe uma única tecnologia mágica. Normalmente usamos um conjunto de instrumentos complementares.

O ponto não é adotar todos esses padrões em toda integração. É identificar qual problema de interoperabilidade realmente existe antes de escolher a ferramenta.

10. Um mapping é mais do que “renomear colunas”

Considere:

Sistema A                 Sistema B
--------------------      --------------------
status = "ACTIVE"   →     situation = 1

Esse mapping parece trivial. Mas um mapping governado deveria responder, pelo menos:

origem:              Sistema A / schema v3
alvo:                Sistema B / schema v7
conceito:            situação cadastral do cliente
regra:               ACTIVE ↔ 1
válido a partir de:  2026-01-01
responsável:         domínio de cadastro
condição:            somente clientes pessoa física
versão do mapping:   4

Agora imagine o Sistema B lançar situation = 3.

Sem versionamento e governança, alguém pode apenas “ajustar o código” e seguir em frente. Com interoperabilidade tratada como ativo, a mudança pode disparar revisão de mapping, teste, análise de impacto e evidência.

11. E a inteligência artificial? Ela ajuda bastante — mas não elimina o problema

Embeddings e modelos de linguagem tornaram muito mais poderosa a descoberta automática de correspondências. Um modelo pode perceber que:

• customer_name se aproxima de nome_cliente;
• postal_code se aproxima de CEP;
• gross_amount provavelmente está relacionado a valor_bruto.

Isso reduz muito trabalho manual. Mas a IA também pode ser enganada por similaridades superficiais: total, amount, value e balance podem estar linguisticamente próximos e representar conceitos distintos.

Um survey de 2026 no ACM Computing Surveys sobre embeddings aplicados a ontology matching destaca justamente desafios envolvendo profundidade semântica, nuances contextuais, escala e heterogeneidade. Sousa, Lima & Trojahn, 2026

No KDD 2026, o trabalho SemStruct mostrou por que a estrutura também importa. Muitos métodos transformam tabelas em sequências de texto, perdendo relações entre colunas e valores. O SemStruct combina embeddings semânticos com informação estrutural e obteve resultados de estado da arte nos benchmarks avaliados pelos autores. Kang et al., KDD 2026

12. Uma arquitetura mental simples para interoperabilidade de verdade

Em vez de pensar apenas em Sistema A → API → Sistema B, pense em camadas que respondem a perguntas diferentes:

Essa separação também é útil para sistemas com agentes de IA. Protocolos podem permitir que agentes descubram ferramentas e troquem mensagens, mas o fato de um agente conseguir chamar uma capability não garante que ele entenda corretamente seu significado, possua autorização adequada ou produza uma ação auditável.

13. “Mas meu sistema é pequeno. Preciso de ontologia?”

Provavelmente não. Interoperabilidade deve ser proporcional ao problema.

🟢 Para uma integração pequena

Pode bastar: OpenAPI bem descrita; JSON Schema; enums explícitos; tabela de mapping versionada; documentação de unidades; testes de contrato.

🟡 Para muitos sistemas ou domínios heterogêneos

Pode ser necessário acrescentar: modelo canônico; vocabulário compartilhado; serviços terminológicos; ontologias; catálogo de mappings; provenance; detecção de drift; governança de mudança.

🔴 Para ecossistemas críticos ou regulados

Também podem entrar: identidade e delegação; policies; trilhas de auditoria; evidências verificáveis; aprovação humana para casos incertos; requisitos legais e organizacionais.

14. Checklist: sua integração está apenas conectada ou realmente interoperável?

Use estas perguntas em uma integração real:

Se várias respostas forem “não”, talvez você tenha uma integração técnica funcional, mas ainda não uma interoperabilidade robusta.

15. A mudança de mentalidade

Durante muito tempo, projetos de integração foram tratados principalmente como problemas de transporte:

“Como conectar o sistema A ao sistema B?”

A pergunta mais útil é:

“Como garantir que A e B preservem o mesmo significado ao trocar e usar informação?”

A mudança parece pequena, mas altera todo o desenho da solução. Você deixa de pensar apenas em endpoints e começa a pensar também em significado, contexto, autoridade, versões, correspondências, regras e evidência.

16. Onde o InteroperaX entra nessa discussão?

Esta é justamente uma das perguntas que orientam a linha de pesquisa em interoperabilidade semântica do InteroperaX. A ideia geral é separar preocupações que frequentemente aparecem misturadas:

protocolos e APIs   →  conectividade
schemas             →  estrutura
semântica           →  significado e correspondência
governança          →  autoridade e políticas
evidência           →  reconstrução e auditabilidade

O objetivo deste artigo não é apresentar uma arquitetura proprietária, mas mostrar o princípio que motiva a pesquisa: a infraestrutura de conexão é essencial, porém o valor aparece quando sistemas e agentes conseguem interpretar, governar e comprovar o que trocaram.

17. Conclusão: a API é a porta, não o destino

APIs são fundamentais. OpenAPI, schemas, protocolos e contratos técnicos reduziram enormemente o custo de integração.

Mas sistemas não interoperam apenas porque conseguem trocar bytes. Eles interoperam quando conseguem preservar estrutura, significado e contexto, alinhar processos e responsabilidades e aplicar governança suficiente para que a informação possa ser usada com confiança.

É por isso que a próxima geração de integração — especialmente em ecossistemas distribuídos, governo digital e sistemas de agentes de IA — precisa tratar semântica como parte da arquitetura, e não apenas como documentação ao lado da API.

Glossário rápido

Referências e leituras recomendadas

1. Rahm, E.; Bernstein, P. A. A survey of approaches to automatic schema matching. The VLDB Journal, 2001. DOI 10.1007/s007780100057
2. Park, J.; Ram, S. Information systems interoperability: What lies beneath? ACM Transactions on Information Systems, 2004. DOI 10.1145/1028099.1028103
3. Shvaiko, P.; Euzenat, J. A Survey of Schema-Based Matching Approaches. Journal on Data Semantics IV (LNCS), 2005. DOI 10.1007/11603412_5
4. Portisch, J.; Hladik, M.; Paulheim, H. Background knowledge in ontology matching: A survey. Semantic Web, 2022. DOI 10.3233/SW-223085
5. Sousa, G. S.; Lima, R.; Trojahn, C. Survey on Embedding Methods Applied to Ontology Matching. ACM Computing Surveys, 2026. DOI 10.1145/3805799
6. Kang, I. et al. SemStruct: Contextualizing Semantic Embeddings with Structural Information for Schema Matching. KDD 2026. DOI 10.1145/3770855.3817963
7. Amar, F.; April, A.; Abran, A. Electronic Health Record and Semantic Issues Using Fast Healthcare Interoperability Resources: Systematic Mapping Review. Journal of Medical Internet Research, 2024. DOI 10.2196/45209
8. OpenAPI Initiative. OpenAPI Specification v3.2.0. Especificação oficial
9. JSON Schema. Draft 2020-12. Especificação oficial
10. European Commission. European Interoperability Framework. Interoperability layers
11. Governo Digital — Brasil. ePING — Padrões de Interoperabilidade de Governo Eletrônico. ePING
12. European Commission. Impact Assessment SWD(2022) 722. EUR-Lex