A próxima vantagem da Europa em IA pode ser a interoperabilidade simples

A Europa não torna a IA mais útil ao tornar todos os sistemas idênticos. Pode torná-la mais governável ao insistir que os sistemas troquem significado,...

A próxima vantagem da Europa em IA pode ser a interoperabilidade simples

The ordinary thing that makes a system usable

Interoperability has a branding problem. It sounds like the part of a programme left to people who enjoy reference architectures, version tables and the precise punctuation of a schema. That reputation is not wholly unfair. A good interface contract will never beat a new model in a product launch. Nobody brings cake because two services finally agree on the meaning of a deleted record.

Yet that agreement is where much of the useful work begins. A model can be impressive in isolation and still be of limited help to an organisation that cannot connect it to the records, rules, people and decisions that give the work a purpose. The model may produce a fluent answer. But if the answer cannot carry a source identifier, if a correction cannot reach the systems that acted on it, if a person cannot tell which policy version applied, then the system has not become part of the work. It has become another place to copy and paste from.

Europe’s next AI advantage may therefore be rather unglamorous. It may be the ability to make systems meet at boundaries that are explicit, inspectable and fair to leave. Not a continental super-app. Not a demand that every hospital, town hall, laboratory and manufacturer use one database. The useful ambition is narrower and harder: a service should be able to exchange information, preserve the information’s meaning, respect the conditions around it and remain operable when another component changes.

That is a strategic capability. It turns a collection of tools into infrastructure. It allows an administration in one Member State to recognise a record produced in another without pretending that their laws, languages or procedures are identical. It allows a company to change a data-processing service without losing the digital assets that make the service function. It gives a buyer a way to ask whether an AI system can join an existing process without quietly owning it. It gives a smaller supplier a chance to compete on a documented boundary rather than on the customer’s tolerance for migration pain.

The point is easy to misunderstand. Interoperability is not an automatic virtue. A badly designed interface can spread a bad assumption quickly. A shared data model can be too broad, too invasive or too vague. A standard can become a museum piece. An open API can still be expensive, insecure or so poorly documented that it serves mainly as evidence that an API department once existed. Europe does not need a decorative pile of specifications. It needs contracts that work under ordinary conditions, including correction, withdrawal, update, interruption and departure.

The Interoperable Europe Act gives a useful definition for public services. It treats cross-border interoperability as the ability of Union entities and Member State public-sector bodies to interact by sharing data, information and knowledge through digital processes that meet legal, organisational, semantic and technical requirements. The four words matter. Technical compatibility is only one layer. Two services can exchange bytes and still disagree about authority, purpose, retention or the meaning of a status. They can share a field called approved while one means a preliminary check and the other means a final legal decision. The field travels. The decision does not.

This is where the subject becomes more interesting than plumbing. Interoperability asks what has to remain true when something crosses a boundary. Which organisation is responsible? What is the unit of information? Who can amend it? What happens when a source is corrected? What does a missing value mean? Which identity has been verified? How long may the recipient retain it? Can another system prove which version it received? These are public questions, commercial questions and engineering questions in the same coat.

IA torna o casaco mais cheio. Um sistema de IA pode colocar-se entre os registos e as pessoas, recuperar material de várias fontes, aplicar uma versão de modelo, invocar uma ferramenta, recomendar uma ação e deixar um registo de decisão. Se nenhuma dessas passagens tiver um contrato definido, um modelo capaz pode tornar uma organização menos legível em vez de mais capaz. A resposta pode ser persuasiva mas impossível de rastrear. O fluxo de trabalho pode parecer mais rápido, mas tornar-se dependente do formato de mensagem privado, do estado de agente privado e da definição privada de tarefa de um único fornecedor. Isso não é inteligência. É uma mudança de propriedade escondida dentro de uma funcionalidade de conveniência.

O argumento a favor da interoperabilidade monótona não é o de que torna a tecnologia aborrecida. É o de que a torna responsabilizável. A Europa está numa posição invulgarmente boa para valorizar essa distinção. Os seus serviços públicos atravessam fronteiras. As suas línguas e tradições administrativas resistem à fantasia de que um único vocabulário pode simplesmente ser imposto. As suas regras de dados tratam cada vez mais o acesso, a portabilidade e a governação como condições para um mercado que funciona. E as suas organizações tentam frequentemente acrescentar IA a um trabalho que já tem deveres, registos e consequências. A fronteira é importante porque as pessoas já estão dos dois lados dela.

Compatibilidade ainda não é compreensão

Há várias formas de dois sistemas parecerem compatíveis. Podem usar o mesmo protocolo de rede. Podem aceitar o mesmo tipo de ficheiro. Podem autenticar com o mesmo esquema de identidade. Podem até passar no mesmo teste de conformidade. Cada uma é útil. Nenhuma resolve a questão mais ampla: consegue o sistema recetor usar a informação corretamente para o fim declarado?

Tomemos um exemplo modesto e hipotético. Uma autoridade regional envia um aviso a uma autoridade vizinha através de uma interface bem documentada. O conteúdo é validado. A assinatura é verificada. Todos os campos obrigatórios estão presentes. Um campo contém uma data. O sistema emissor refere-se ao dia em que o evento subjacente ocorreu. O sistema recetor trata-o como o dia em que o aviso se tornou juridicamente eficaz. Não se perdeu nenhum pacote. Nenhum servidor falhou. Os sistemas eram tecnicamente compatíveis e semanticamente desalinhados. O resultado pode ser um prazo errado, um recurso desnecessário ou uma pessoa obrigada a repetir um trabalho que uma máquina já realizou.

O exemplo é deliberadamente hipotético. Não precisa de uma câmara municipal fictícia nem de uma terça-feira de manhã para fazer o ponto. Muitas falhas digitais difíceis não são dramáticas. Chegam como um registo aparentemente completo com uma suposição não declarada anexada. Um carimbo de data e hora não tem fuso horário. Um valor está em branco, mas ninguém diz se o branco significa desconhecido, omitido, não aplicável ou ainda não verificado. Um identificador é estável dentro de um sistema e reciclado noutro. Um sinal de consentimento viaja sem o propósito, o âmbito e a validade que o tornavam significativo. A integração funciona até alguém se apoiar nela.

A interoperabilidade semântica é a disciplina de tornar esses significados suficientemente explícitos para serem partilhados. Não exige um dicionário universal para todos os assuntos humanos. Exige que os participantes numa troca definida concordem sobre o que os seus termos designam, que restrições se aplicam, que valores são permitidos e como as alterações são comunicadas. Na linguagem do trabalho de normas, diz respeito a modelos de dados, vocabulários, identificadores, relações e às regras que permitem a um recetor interpretá-los. Na linguagem de um operador, é a diferença entre receber um registo e receber algo sobre o qual pode agir com segurança.

O Comité Técnico de Dados da ETSI descreve o seu trabalho em termos de governação de dados, interoperabilidade semântica, ontologias e alinhamento regulamentar, com o objetivo de tornar os dados partilháveis e reutilizáveis entre setores e fronteiras. Este enquadramento é refrescantemente discreto. Recusa a ideia de que os dados têm valor simplesmente por terem sido colocados num lago, num espaço ou numa folha de cálculo com um número respeitável de separadores. Os dados tornam-se reutilizáveis quando os termos que os rodeiam são suficientemente claros para que outra parte possa fazer deles uma utilização delimitada e legítima.

A Lei Europeia dos Dados faz o mesmo ponto a partir de outra direção. As suas disposições sobre interoperabilidade dizem respeito a espaços de dados e serviços de processamento de dados. A explicação da Comissão afirma que as normas e a interoperabilidade são centrais para a utilização de dados de diferentes fontes dentro e entre Espaços Europeus Comuns de Dados, e para facilitar a mudança entre serviços de processamento de dados. Não se trata de uma promessa de que todos os sistemas passarão subitamente a compreender todos os outros sistemas. É um reconhecimento político de que um mercado de serviços isolados deixa os clientes com menos escolhas práticas.

É tentador ouvir «semântico» e pensar numa ontologia grandiosa, num diagrama suficientemente grande para merecer o seu próprio código postal. Por vezes, um domínio necessita de uma modelação partilhada substancial. Mas o melhor ponto de partida é mais pequeno. Qual é o objeto nesta troca? Que versão está a ser enviada? Que organização detém o valor de referência? Que evento pode alterá-lo? O que deve o destinatário fazer quando esse evento ocorre? Que utilização é permitida? Como pode uma pessoa inspecionar a resposta quando o caminho automatizado é incerto? Um contrato restrito e respondível vale mais do que um diagrama abrangente que ninguém consegue implementar.

A mesma contenção é importante para a IA. Um fluxo de trabalho de IA pode precisar de passar um item de trabalho a um modelo, receber uma classificação proposta, anexar fontes, procurar aprovação e registar a decisão num sistema de casos. Não deve fingir que uma explicação em linguagem natural é uma interface suficiente. O fluxo de trabalho precisa de factos tipificados, além de palavras: o identificador do item de trabalho, as versões das fontes, a tarefa declarada, as ferramentas permitidas, a condição de confiança ou de recusa quando relevante, a decisão do revisor, o momento e a versão da política. O modelo pode continuar a ser probabilístico. A fronteira em torno do modelo não deve ser vaga por hábito.

É por isso que interoperabilidade não é o mesmo que integração. Uma integração pode ser uma ligação privada construída para uma única relação. Pode ser totalmente adequada. Mas quando a sua semântica vive apenas na implementação de um fornecedor, na memória de um membro do pessoal ou numa apresentação de um workshop, a ligação não se transporta bem. Uma fronteira interoperável deixa para trás um contrato que outra parte competente pode ler, testar e contestar. É mais lenta de estabelecer do que um conector rápido. É mais rápida de reparar quando o conector original se tornou uma dependência com um logótipo.

O enquadramento europeu começa pelo problema na sua totalidade

A Lei da Interoperabilidade para a Europa não é uma lei de IA, e seria um erro apresentá-la como tal. É um regulamento para a interoperabilidade transfronteiriça do setor público. O seu valor para a IA é mais básico. Descreve uma forma de pensar sobre os serviços públicos digitais antes de uma tecnologia específica ser colocada no seu centro.

Nos termos do Regulamento, as entidades da União e os organismos do setor público abrangidos devem realizar uma avaliação da interoperabilidade antes de decidirem sobre requisitos vinculativos novos ou substancialmente alterados. A avaliação identifica e avalia os efeitos na interoperabilidade transfronteiriça, nas partes interessadas relevantes e nas soluções de interoperabilidade da Europa Interoperável que podem apoiar a implementação. O relatório resultante deve ser publicado num formato legível por máquina que facilite a tradução automática, sem prejuízo das proteções do Regulamento em matéria de propriedade intelectual, segredos comerciais, ordem pública e segurança.

Isso é mais exigente do que perguntar se um sistema proposto tem uma API. Uma API pode ser tecnicamente impecável e ainda assim criar uma barreira para uma administração vizinha, um cidadão, uma pequena empresa ou outro organismo público. A avaliação coloca uma pergunta diferente: o que muda na capacidade de interagir quando este requisito é introduzido? Isso abre espaço para que a autoridade legal, a responsabilidade organizacional, o significado semântico e o design técnico apareçam na mesma conversa. Sempre fizeram parte da mesma conversa. O software apenas tinha sido autorizado a realizar a reunião em salas separadas.

O Regulamento também torna a partilha concreta. O artigo 4.º exige que uma entidade da União ou um organismo do setor público disponibilize, mediante pedido, uma solução de interoperabilidade que apoie um serviço público digital transeuropeu a outra entidade ou organismo desse tipo, incluindo documentação técnica e, quando aplicável, histórico de versões, código-fonte documentado e referências a normas abertas ou especificações técnicas. Existem exceções, incluindo direitos de propriedade intelectual de terceiros e atividades fora da missão pública. O princípio não é que cada linha de software do setor público deva ser publicada sem critério. O princípio é que uma solução reutilizável não deve tornar-se uma descoberta privada sempre que outra administração dela precisar.

Há uma mudança subtil nessa redação. A documentação e o histórico de versões não são burocracia secundária depois de o componente útil ter sido criado. Fazem parte do que torna o componente reutilizável. Um repositório de código-fonte sem contexto pode ser tão inútil quanto uma mala sem chave. Uma arquitetura de referência sem explicação dos pressupostos pode tornar-se uma forma muito elegante de exportar confusão. A coisa reutilizável é o código, a especificação, os limites conhecidos, a versão, a evidência de como se pretendia que fosse utilizada e as condições em que não deve ser utilizada.

O Quadro Europeu de Interoperabilidade, que o Regulamento coloca no centro do seu modelo de avaliação, aborda igualmente a interoperabilidade e a governação jurídica, organizacional, semântica e técnica. Esta visão em quatro camadas é útil porque impede que um tipo de sucesso se faça passar pelo resultado completo. Uma equipa técnica pode implementar com sucesso uma interface. Uma equipa jurídica pode não encontrar obstáculos à troca. Uma equipa operacional pode concordar com a escalada. Uma equipa de domínio pode alinhar o significado dos objetos. O sistema só se torna fiável na fronteira quando as camadas relevantes estão alinhadas para a utilização específica.

É também por isso que uma «norma europeia» não é uma fórmula mágica. As normas podem reduzir variações desnecessárias e tornar um contrato acessível a mais participantes. Não podem decidir se uma troca específica é proporcionada, legal, segura ou útil. Um perfil técnico tem de ser selecionado, implementado, governado e revisto. Precisa de uma política de versões. Precisa de tratamento de erros. Precisa de uma forma de representar a incerteza. Precisa de um processo para decidir quando uma extensão local é justificada e quando se tornou uma bifurcação privada num casaco público.

O caso do setor público é particularmente revelador porque o custo da deriva semântica é frequentemente suportado por alguém fora da equipa técnica. Um residente pode ser obrigado a apresentar informações duas vezes. Uma empresa pode precisar de traduzir um formulário de um vocabulário administrativo para outro. Um profissional pode perder tempo a reconciliar registos. Um serviço transfronteiriço pode funcionar apenas para pessoas cujo caso coincida com o caminho mais fácil. O Regulamento não garante que estes resultados desapareçam. Cria mecanismos para tornar visíveis as suas consequências de interoperabilidade antes de um requisito se solidificar em infraestrutura.

IA deveria herdar essa disciplina. Antes de adicionar um modelo a um serviço transeuropeu ou de outro modo consequente, o responsável deveria poder indicar quais objetos o modelo pode ler, quais objetos pode criar, quais decisões permanecem humanas, como uma correção se propaga, que resultado é um auxílio em vez de um registo com valor oficial, como o serviço se comporta quando o modelo não está disponível e como um destinatário pode contestar ou inspecionar o resultado. Isso não é uma camada adicional de conformidade sobreposta a um produto já completo. É a definição de interface de um sistema que espera ser confiado por pessoas que não partilham o contexto privado do modelo.

Passe o cursor sobre uma camada e selecione-a. Uma fronteira só se mantém quando as camadas relevantes concordam sobre o que deve acontecer.

A portabilidade é um teste de se a fronteira é real

A interoperabilidade torna-se estratégica quando uma relação muda. Um serviço é atualizado. Um fornecedor é substituído. Um organismo público precisa de reutilizar um componente. Um participante de um espaço de dados altera a sua política. Um fornecedor de modelos muda o formato das suas mensagens. Uma nova condição de segurança exige que uma carga de trabalho seja executada noutro local. Nesse momento, a qualidade da fronteira torna-se visível.

O Regulamento sobre Dados trata isto como mais do que um incómodo para os clientes. As suas regras sobre mudança de fornecedor e interoperabilidade dos serviços de processamento de dados visam reduzir os obstáculos à mudança entre serviços, à utilização de vários serviços em paralelo e à portabilidade de dados e aplicações. O estudo de 2026 da Comissão sobre a interoperabilidade dos serviços de processamento de dados descreve o artigo 35.º como apelando a especificações abertas e harmonizadas que permitam que serviços do mesmo tipo funcionem em conjunto e que os dados e as aplicações sejam portáveis sem comprometer a segurança. O estudo refere também o repositório da União previsto para normas e especificações abertas relevantes, e a possibilidade de especificações comuns quando as normas harmonizadas não forem suficientes.

Vale a pena ser preciso sobre o que isto significa e não significa. O Regulamento sobre Dados não promete que um cliente possa transferir um serviço complexo de um fornecedor para outro sem alterações numa sexta-feira à tarde. Não exige que os fornecedores revelem segredos comerciais, comprometam a segurança ou tornem todos os tipos de serviço idênticos. A equivalência funcional, quando o regulamento a exige para serviços do mesmo tipo, não é uma afirmação de consolas idênticas, modelos de preços idênticos ou escolhas de engenharia idênticas. É uma ideia mais útil e mais modesta: funcionalidades partilhadas deveriam permitir que a carga de trabalho do cliente continue a sua função prevista através de uma fronteira relevante.

Essa distinção é importante porque um ficheiro portável não é necessariamente um serviço portável. Uma exportação de dados pode omitir relações, ordem de eventos, configuração, histórico de permissões, identificadores, estado de retenção, versões de políticas e o conhecimento operacional necessário para restaurar o sistema. Um resultado de modelo pode ser exportado enquanto a configuração de recuperação, a versão do pedido, os critérios de avaliação e as permissões de ferramentas que o moldaram permanecem privados. O ficheiro mudou. As condições sob as quais poderia ser confiado não mudaram.

O teste certo não é "conseguimos descarregar algo?" É "consegue um destino competente interpretar e operar a parte do serviço que importa?" São perguntas diferentes. A primeira pode ser respondida por um botão. A segunda exige um inventário, um esquema, um caminho de receção, um teste, pessoas que compreendam a fronteira e uma declaração honesta do que não pode viajar.

Considere outro exemplo explicitamente hipotético. Uma equipa utiliza um serviço de IA para preparar um primeiro rascunho para revisão interna. O serviço tem uma função de exportação. Durante uma migração planeada, a equipa recebe o texto gerado e uma lista de contas de utilizador. Não recebe as versões das fontes de conhecimento, os registos de decisão que determinaram quais as fontes permitidas, o estado de aprovação dos rascunhos, a configuração do modelo nem as regras que impediam o serviço de enviar um rascunho a um destinatário externo. A equipa tem o seu texto. Não recuperou o seu fluxo de trabalho. Se o antigo serviço fosse um editor de documentos, isso poderia ser tolerável. Se os rascunhos moldam trabalho regulado ou relevante para a segurança, é uma categoria diferente de problema.

A portabilidade tem, portanto, pelo menos quatro camadas. Há a portabilidade técnica: podem os dados e as interfaces ser transferidos em formas utilizáveis? Há a portabilidade semântica: pode o destinatário compreender os registos, eventos e restrições? Há a portabilidade operacional: podem as pessoas executar, proteger, observar, corrigir e restaurar a carga de trabalho? E há a portabilidade institucional: pode a organização cumprir os seus deveres públicos, contratuais e legais durante a migração? Nenhum formato de exportação resolve as quatro.

É aqui que a contratação pública pode tornar-se uma força construtiva. Um concurso pode pedir as categorias de dados exportáveis e ativos digitais, os esquemas e versões, os limites de taxa, as verificações de integridade, as implicações de identidade e acesso, as limitações conhecidas, o comportamento de retenção e eliminação, e a assistência disponível durante uma transição. Pode perguntar se uma exportação representativa pode ser recebida e validada por um destino sem acesso privado à consola do fornecedor. Pode perguntar quais partes são específicas do fornecedor por conceção. Uma limitação franca é gerível. Uma limitação oculta torna-se um orçamento de emergência.

As mesmas perguntas ajudam um fornecedor. Um fornecedor que sabe qual fronteira tem de manter estável pode conceber menos dependências acidentais. Pode tornar explícita uma política de versões. Pode publicar um caminho de descontinuação. Pode dar aos clientes um ambiente de teste que se comporta como uma interface real, em vez de uma demonstração de marketing. Pode distinguir a parte de um sistema que é genuinamente proprietária da parte que deve ser partilhada para que o cliente mantenha capacidade de decisão. Isso não é caridade. É um contrato mais claro para ambos os lados.

A vantagem da Europa aqui não é que possa eliminar a dependência. Sistemas sérios têm dependências. A vantagem é a possibilidade de tornar a dependência legível, negociável e suficientemente reversível para o uso em questão. Um sistema que pode permanecer com um fornecedor porque continua a merecer a relação é mais forte do que um que permanece porque ninguém consegue reconstruir o significado dos seus registos noutro local.

Os espaços de dados não são armazéns com melhor iluminação

A expressão “espaço de dados” pode criar a imagem errada. Sugere uma grande sala onde todos trazem dados, colocam-nos numa prateleira e vão para casa satisfeitos com a interoperabilidade. A abordagem europeia é mais exigente. Os Espaços Europeus Comuns de Dados destinam-se a disponibilizar dados para acesso e reutilização num ambiente fiável e seguro. A Comissão descreve as infraestruturas comuns e os quadros de governação como os elementos que apoiam a partilha, o acesso e a disponibilização, juntamente com regras de acesso justas, transparentes, proporcionadas e não discriminatórias.

Essa é uma correção importante. A partilha de dados não é um ato único de transferência. É uma relação contínua entre partes com propósitos, poderes e responsabilidades diferentes. Um participante pode usar um conjunto de dados para investigação, mas não para marketing. Outro pode ter o dever de corrigir um valor. Um terceiro pode receber um resultado derivado, mas não o registo subjacente. Alguns dados devem ser conservados. Outros devem ser eliminados. Alguns só podem ser processados num ambiente específico. Os termos que regem essa relação fazem parte da interoperabilidade, não são uma nota de rodapé numa pasta jurídica separada.

O trabalho da Comissão sobre espaços de dados identifica apoio na arquitetura de referência, blocos de construção, semântica, especificações de interoperabilidade e modelos de dados, juntamente com serviços de aconselhamento através do Data Spaces Support Centre. Esta abrangência é sensata. Um conector seguro sem um vocabulário partilhado não resolve um problema semântico. Um vocabulário partilhado sem identidade, controlo de acesso ou governação não resolve um problema de confiança. Um modelo que pode consultar um espaço de dados sem um propósito declarado, registo de origem e caminho de correção não torna o espaço mais utilizável. Cria um novo consumidor de informação cujos deveres são obscuros.

Para a IA, a implicação é direta. Um modelo não deve ser tratado como um atalho privilegiado que contorna a fronteira de um espaço de dados. Se uma pessoa ou serviço precisa de uma base para o acesso, um propósito definido, uma identidade e um registo de utilização, um fluxo de trabalho de IA precisa da mesma disciplina. Pode haver diferenças técnicas na forma como um agente solicita dados ou como um passo de recuperação é executado. Não deve haver uma isenção mágica em que o sistema diz «o modelo precisava de contexto» e as regras de governação habituais saem do edifício.

Isto não significa que cada pedido precise de ser convertido numa cerimónia burocrática. Significa que o sistema deve distinguir entre uma pergunta e uma autorização. Um modelo pode formular uma consulta. Uma camada sensível às políticas deve decidir se a consulta pode chegar a uma determinada fonte, sob que propósito, com que minimização, e como o pedido e o resultado são registados. Uma resposta pode então citar uma fonte ou explicar uma limitação. Se a fonte mudar, o sistema precisa de uma forma de saber qual resposta ou decisão posterior pode precisar de revisão. Caso contrário, a proveniência torna-se uma ligação decorativa numa transcrição de conversa.

Os contratos semânticos são particularmente úteis aqui porque tornam visível a unidade mínima de confiança. Um identificador de fonte não é apenas uma string. Deve identificar uma versão ou uma referência estável. Uma permissão não é apenas verdadeira ou falsa. Pode ter um âmbito, um propósito, um titular, um limite de tempo e uma base. Uma correção não é apenas uma atualização. Pode substituir uma afirmação anterior, preservando o histórico necessário para explicar o que aconteceu. Uma recusa não é apenas um erro. Pode ser uma fronteira deliberada que precisa de ser compreensível para a pessoa que pergunta.

A tentação será resolver isto com uma «camada universal de interoperabilidade de IA» que afirma tornar intercambiáveis todos os agentes, modelos, bases de dados e ferramentas de fluxo de trabalho. Esse tipo de afirmação costuma confundir transporte comum com significado comum. Um protocolo genérico pode ser útil. Não pode dizer a um destinatário o que um código clínico, um estado de planeamento, uma decisão de benefício ou um sinal de risco significa no domínio específico. Não pode decidir quem pode sobrepor-se a uma sugestão automatizada. Não pode dizer a uma organização durante quanto tempo pode conservar um registo recuperado. As normas transportam acordos. Não eliminam a necessidade de os fazer.

Há uma ambição mais fundamentada. Construir acordos específicos de domínio onde o trabalho partilhado os justifique. Reutilizar blocos de construção gerais onde estes se ajustem genuinamente: identidade, autorização, proveniência, eventos, versionamento, testes de conformidade e documentação acessível. Manter a ligação entre uma norma geral e uma implementação local inspecionável. Assim, um participante pode aderir sem entregar todo o seu sistema, e um setor pode evoluir sem começar do zero sempre que chega um novo fornecedor.

Essa é uma versão melhor de escala. Não mede o sucesso pela quantidade de dados centralizados ou pelo número de serviços forçados a uma única interface. Mede o sucesso pela possibilidade de uma troca legítima acontecer com clareza suficiente para que os participantes possam usar, corrigir, governar e, quando necessário, interromper essa troca.

Selecione um cartão para inspecionar a parte de uma troca que torna um registo utilizável para além do seu sistema original.

As normas precisam de vida após a publicação

As normas são frequentemente descritas como se o seu trabalho terminasse quando o documento é publicado. Na prática, a publicação é o momento em que o trabalho mais difícil começa. Alguém tem de escolher o perfil aplicável. Alguém tem de o implementar. Alguém tem de testar casos extremos. Alguém tem de decidir se uma nova versão é compatível, quando a versão antiga é retirada e o que acontece aos registos criados segundo regras anteriores. Alguém tem de explicar todo o arranjo a uma equipa que não estava na sala quando o acrónimo foi escolhido.

A EN 18235-1:2026 do CEN e do CENELEC é um exemplo recente da direção seguida. A norma diz respeito à partilha e troca de dados entre organizações, com ênfase na interoperabilidade e na responsabilização, e as suas aplicações anunciadas incluem os Espaços Europeus de Dados Comuns. O detalhe importa menos aqui do que o sinal. A confiança na partilha de dados não está a ser tratada como um sentimento gerado por um painel de controlo. Está a ser tratada como algo moldado por acordos em torno da troca, da responsabilidade e da capacidade de prestar contas do que aconteceu.

O melhor trabalho de normalização deixa espaço para aquilo que não consegue resolver. Uma especificação técnica pode definir uma estrutura de mensagem. Não pode declarar uma base jurídica local. Um vocabulário pode definir um conceito. Não pode garantir que um processo local usa o conceito com honestidade. Um teste de conformidade pode mostrar que uma implementação satisfaz casos nomeados. Não pode provar que a organização formou as pessoas que lidam com exceções. Fingir o contrário faz um desserviço às normas. Faz com que pareçam um substituto do julgamento, em vez de uma ferramenta que permite que o julgamento vá mais longe.

Os testes de conformidade são especialmente valiosos porque transformam a interoperabilidade de uma promessa numa propriedade observável. Um fornecedor pode afirmar que suporta um perfil. Um comprador deve poder perguntar qual a versão, quais as funcionalidades opcionais, quais os casos negativos, quais as respostas de erro e quais as provas de teste publicadas que sustentam essa afirmação. Um implementador deve poder executar os mesmos casos antes de uma integração chegar à produção. Uma alteração deve declarar se é retrocompatível e quais os consumidores que têm de agir.

Para interfaces de IA, isto pode parecer exigente até à primeira alteração incompatível. Uma chamada de ferramenta espera um valor monetário em cêntimos. Outra devolve uma string decimal sem moeda. Um agente trata um campo ausente como um pedido de mais informações. Outro interpreta-o como permissão para inferir um valor. Uma atualização do modelo altera a estrutura das citações. Um processo a jusante continua a analisar o formato antigo. Nenhum destes casos é um enigma filosófico. São falhas de interface comuns, tornadas mais consequentes por um sistema que pode agir rapidamente.

Um bom contrato contém, portanto, tanto a recusa como o sucesso. Especifica o que o sistema rejeitará, o que devolverá quando uma fonte não puder ser verificada, o que fará quando faltar uma política, como o destinatário pode distinguir dados parciais de dados completos e onde começa a revisão humana. O silêncio é uma péssima estratégia de interoperabilidade. Uma recusa clara é, muitas vezes, a resposta mais compatível, porque dá ao sistema seguinte um estado honesto com que trabalhar.

O versionamento merece o mesmo respeito. Uma interface útil não se limita a acrescentar um número de versão a um URL e a esperar pelo melhor. Declara a alteração, indica o caminho de migração, preserva o contrato antigo durante o período prometido, sempre que possível, regista como os dados armazenados são interpretados entre versões e dá aviso suficiente para que os sistemas dependentes se adaptem. Este não é um trabalho entusiasmante. É assim que um limite deixa de ser uma surpresa. Nos Países Baixos, há uma preferência por dizer que uma coisa é "suficientemente clara" até alguém ter de a construir. A política de versões é o que resta depois de essa expressão encontrar um sistema de produção.

Há aqui um ponto económico europeu. Organizações mais pequenas podem participar quando as regras de ligação são públicas, documentadas e testáveis. Não precisam de uma relação privada com cada plataforma dominante apenas para descobrir como funciona uma troca. Organizações maiores também beneficiam, porque podem reduzir a dívida de integração personalizada e testar as afirmações de um fornecedor antes de se formar uma dependência central. O resultado não é isento de atritos. É um atrito mais justo: o trabalho é visível, tem preço e é partilhado, em vez de ser descoberto depois de o contrato ter estreitado as opções.

A questão prática é o que sobrevive à transição

A maioria dos programas de interoperabilidade melhora quando começa com uma troca pequena, em vez de uma grande aspiração. Escolha um limite de decisão ou de serviço. Descreva as informações que o devem atravessar. Identifique a fonte de autoridade, o destinatário, a finalidade permitida, o vocabulário, os eventos do ciclo de vida, as condições de segurança e as evidências que mostrarão que a troca ocorreu como pretendido. Depois, teste tanto o sucesso como o fracasso.

A conversa resultante é, muitas vezes, mais reveladora do que uma comparação de funcionalidades. O que acontece quando a fonte corrige um registo? O destinatário consegue identificar qual cópia é afetada? O que acontece quando um sistema de IA não consegue apoiar uma recomendação com uma fonte permitida? Devolve uma recusa explícita, um resultado parcial ou uma confiança inventada? O que acontece quando um destinatário recebe uma versão de esquema que não compreende? Consegue rejeitar a troca em segurança? O que acontece quando uma pessoa contesta uma classificação? A correção torna-se um novo evento com rasto, ou o resultado antigo é sobrescrito até ninguém conseguir reconstruir a base da ação original?

Estas são questões de design, não apenas de conformidade. Moldam se as pessoas conseguem operar um serviço, se um fornecedor o consegue apoiar e se outro sistema pode aderir sem herdar um risco não documentado. Também moldam a qualidade da IA. Um modelo com um limite de informação claro tem menos espaço para transformar contexto ambíguo em suposições invisíveis. Um fluxo de trabalho com saídas tipadas e identidade da fonte dá aos revisores algo concreto para inspecionar. Um registo de decisão com versões torna a avaliação possível depois de o modelo, o prompt ou a política terem mudado.

Há limites sensatos. Há dados que não devem viajar. Há informações que devem ser minimizadas ou agregadas. Alguns serviços precisam de uma fronteira à medida, porque o trabalho é invulgar, sensível ou de alto risco. Algum vocabulário local deve permanecer local, porque forçar uma falsa equivalência destruiria o significado. A interoperabilidade não é uma exigência de que todos os sistemas exponham tudo. É uma exigência de que a fronteira escolhida seja honesta quanto ao que expõe, porquê, a quem e com que consequências.

Essa honestidade é especialmente importante quando os fornecedores de IA oferecem uma ligação rápida. Um conector que copia silenciosamente um grande corpus para o contexto de um modelo pode resolver um problema de demonstração enquanto cria um problema de governação. Uma ferramenta que escreve num sistema empresarial sem um identificador de trabalho duradouro pode criar uma automatização enquanto destrói a capacidade de a auditar. Um protocolo universal de agentes pode facilitar a descoberta enquanto deixa por resolver a autorização, a limitação de finalidade e a responsabilidade semântica. A questão deve ser sempre o que sobrevive à passagem: os dados, o significado, a permissão, a evidência e a capacidade de corrigir.

Um programa útil dá a cada um desses elementos um lugar. Os dados precisam de um formato e de uma verificação de integridade. O significado precisa de um modelo, de um vocabulário ou de um mapeamento explícito. A permissão precisa de uma identidade, de uma finalidade e de uma fronteira de política. A evidência precisa de um registo da origem, da versão, da transformação e da decisão. A correção precisa de um percurso de eventos e de um responsável. A operação precisa de um runbook, de observabilidade e de uma forma de parar ou reverter uma alteração. Nada disto dá para um filme de lançamento heroico. Mas torna possível que um sistema continue útil depois de o filme de lançamento ter sido substituído por um ticket de suporte.

Na Dweve, aplicamos o princípio de forma restrita na descrição pública do Fabric. O site descreve um modelo de objetos centrado no trabalho, no qual modelos, agentes, ferramentas, pessoas e fluxos de trabalho participam através de contratos tipificados, e descreve interfaces de utilizador e APIs que operam no mesmo domínio. Essa é uma posição de design de produto, não uma prova de que qualquer implementação é automaticamente interoperável ou de que uma interface tipificada resolve questões legais, semânticas ou operacionais. É simplesmente o tipo de fronteira que achamos que os sistemas de IA sérios precisam: uma em que o trabalho duradouro não desaparece numa conversa específica de um fornecedor.

A HEDL oferece um exemplo público mais pequeno. A sua documentação descreve um formato de texto licenciado sob Apache 2.0, uma especificação de formato publicada e documentos de conformidade, com conversões de e para JSON, YAML, XML, CSV, Parquet e TOON. Essas funcionalidades não tornam todos os conjuntos de dados compatíveis e não transformam uma conversão de formato num acordo semântico. Mas fazem uma afirmação útil sobre uma fronteira: um formato de intercâmbio deve ser inspecionável, testável e capaz de coexistir com os sistemas existentes, em vez de exigir que cada sistema se torne o seu próprio dialeto privado.

A Europa não precisa de vencer uma corrida de IA fugindo das suas próprias instituições. A sua oportunidade é tornar essas instituições, mercados e comunidades técnicas mais fáceis de ligar, sem fingir que as suas diferenças não importam. O trabalho parecerá aborrecido à distância. É histórico de versões, fixtures de teste, escolhas de vocabulário, regras de acesso, exercícios de migração e a reunião desconfortável ocasional sobre quem pode alterar um campo. De perto, é o trabalho que permite que um sistema seja confiado por alguém que não seja a equipa que o construiu.

Essa é uma vantagem que vale a pena ter. Um modelo pode ser substituído. Um fornecedor pode ser mudado. Um serviço pode atravessar uma fronteira. Uma correção pode chegar ao lugar onde importa. Uma pessoa pode perguntar o que aconteceu e receber algo melhor do que um parágrafo confiante. A tecnologia continua ambiciosa. A fronteira continua comum. É a parte comum que dá à ambição um lugar fiável onde assentar.

Fontes