Europas nästa AI-fördel kan vara tråkig interoperabilitet

Europa gör inte AI mer användbar genom att göra alla system identiska. Det kan göra den mer styrbar genom att kräva att system kan utbyta innebörd, föra...

Europas nästa AI-fördel kan vara tråkig interoperabilitet

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.

AI gör kappan mer trångbodd. Ett AI-system kan placeras mellan register och människor, hämta material från flera källor, tillämpa en modellversion, anropa ett verktyg, rekommendera en åtgärd och lämna en beslutslogg. Om ingen av dessa överlämningar har ett definierat kontrakt kan en kapabel modell göra en organisation mindre läsbar snarare än mer kapabel. Svaret kan vara övertygande men ospårbart. Arbetsflödet kan verka snabbare men bli beroende av en enda leverantörs privata meddelandeformat, privata agenttillstånd och privata definition av en uppgift. Det är inte intelligens. Det är ett ägarbyte gömt i en bekvämlighetsfunktion.

Argumentet för tråkig interoperabilitet är inte att den gör tekniken ointressant. Det är att den gör tekniken ansvarsskyldig. Europa är ovanligt väl positionerat för att värdera den skillnaden. Dess offentliga tjänster korsar gränser. Dess språk och administrativa traditioner motstår fantasin att ett enda ordförråd helt enkelt kan påtvingas. Dess dataregler behandlar i allt högre grad tillgång, portabilitet och styrning som villkor för en fungerande marknad. Och dess organisationer försöker ofta lägga till AI i arbete som redan har skyldigheter, register och konsekvenser. Gränsen spelar roll eftersom människor redan står på båda sidor av den.

Kompatibilitet är ännu inte förståelse

Det finns flera sätt för två system att verka kompatibla. De kan använda samma nätverksprotokoll. De kan acceptera samma filtyp. De kan autentisera med samma identitetsschema. De kan till och med klara samma konformitetstest. Varje sätt är användbart. Inget av dem avgör den större frågan: kan det mottagande systemet använda informationen korrekt för det avsedda ändamålet?

Ta ett blygsamt, hypotetiskt exempel. En regional myndighet skickar ett meddelande till en grannmyndighet via ett väldokumenterat gränssnitt. Nyttolasten valideras. Signaturen verifieras. Alla obligatoriska fält finns med. Ett fält innehåller ett datum. Det sändande systemet menar dagen då den underliggande händelsen inträffade. Det mottagande systemet behandlar det som dagen då meddelandet fick rättslig verkan. Inget paket gick förlorat. Ingen server kraschade. Systemen var tekniskt kompatibla och semantiskt felinriktade. Resultatet kan bli en felaktig deadline, ett onödigt överklagande eller en person som ombeds upprepa arbete som en maskin redan har utfört.

Exemplet är medvetet hypotetiskt. Det behöver inte en fiktiv stadshusbyggnad eller en tisdagsmorgon för att göra poängen. Många svåra digitala misslyckanden är inte dramatiska. De kommer som en till synes komplett post med ett outtalat antagande bifogat. En tidsstämpel saknar tidszon. Ett värde är tomt, men ingen säger om tomt betyder okänt, utelämnat, inte tillämpligt eller ännu inte kontrollerat. En identifierare är stabil inom ett system och återanvänds i ett annat. En samtyckesflagga färdas utan det syfte, den omfattning och det utgångsdatum som gjorde den meningsfull. Integrationen körs tills någon förlitar sig på den.

Semantisk interoperabilitet är disciplinen att göra dessa betydelser tillräckligt explicita för att kunna delas. Den kräver inte en universell ordbok för alla mänskliga angelägenheter. Den kräver att deltagarna i ett definierat utbyte kommer överens om vad deras termer refererar till, vilka begränsningar som gäller, vilka värden som är tillåtna och hur förändringar kommuniceras. På standardspråk rör det datamodeller, vokabulärer, identifierare, relationer och de regler som låter en mottagare tolka dem. På en operatörs språk är det skillnaden mellan att ta emot en post och att ta emot något de säkert kan agera på.

ETSI:s tekniska kommitté för data beskriver sitt arbete i termer av dataförvaltning, semantisk interoperabilitet, ontologier och regelverksanpassning, med målet att göra data delningsbara och återanvändbara över sektorer och gränser. Den beskrivningen är uppfriskande anspråkslös. Den avvisar idén att data har värde bara för att de har placerats i en datasjö, ett utrymme eller ett kalkylblad med ett respektabelt antal flikar. Data blir återanvändbara när villkoren kring dem är tillräckligt tydliga för att en annan part ska kunna göra en avgränsad, legitim användning av dem.

EU:s dataakt gör samma poäng från ett annat håll. Dess bestämmelser om interoperabilitet rör datasjöar och databehandlingstjänster. Kommissionens förklaring säger att standarder och interoperabilitet är centrala för att använda data från olika källor inom och mellan gemensamma europeiska datasjöar, och för enklare byte mellan databehandlingstjänster. Det är inte ett löfte om att alla system plötsligt ska förstå alla andra system. Det är ett politiskt erkännande av att en marknad med isolerade tjänster ger kunderna färre praktiska val.

Det är frestande att höra "semantisk" och sträcka sig efter en storslagen ontologi, ett diagram som är så stort att det skulle behöva en egen postadress. Ibland kräver en domän omfattande gemensam modellering. Men den bättre utgångspunkten är mindre. Vad är objektet i detta utbyte? Vilken version skickas? Vilken organisation äger det auktoritativa värdet? Vilken händelse kan ändra det? Vad måste mottagaren göra när den händelsen inträffar? Vilken användning är tillåten? Hur kan en person granska svaret när den automatiserade vägen är osäker? Ett snävt, besvarbart avtal är mer värdefullt än ett heltäckande diagram som ingen kan implementera.

Samma återhållsamhet gäller för AI. Ett AI-arbetsflöde kan behöva skicka en arbetsuppgift till en modell, ta emot en föreslagen klassificering, bifoga källor, söka godkännande och skriva beslutet till ett ärendehanteringssystem. Det bör inte låtsas att en förklaring på naturligt språk är ett tillräckligt gränssnitt. Arbetsflödet behöver typade fakta såväl som ord: arbetsuppgiftens identifierare, källversionerna, den deklarerade uppgiften, de tillåtna verktygen, konfidens- eller avvisandevillkoret där det är relevant, granskarens beslut, tidpunkten och policyversionen. Modellen kan förbli probabilistisk. Gränsen runt modellen bör inte vara vag av vana.

Det är därför interoperabilitet inte är detsamma som integration. En integration kan vara en privat koppling byggd för en enda relation. Den kan vara helt lämplig. Men när dess semantik bara lever i en leverantörs implementation, en anställds minne eller en presentation från en workshop, fungerar kopplingen inte bra på andra håll. En interoperabel gräns lämnar efter sig ett avtal som en annan kompetent part kan läsa, testa och ifrågasätta. Det tar längre tid att etablera än en snabb koppling. Det går snabbare att reparera när den ursprungliga kopplingen har blivit ett beroende med en logotyp.

Europas ramverk börjar med hela problemet

Interoperable Europe-förordningen är inte en AI-lag, och det vore ett misstag att presentera den som en. Det är en förordning för gränsöverskridande interoperabilitet inom den offentliga sektorn. Dess värde för AI är mer grundläggande. Den beskriver ett sätt att tänka kring digitala offentliga tjänster innan en viss teknik placeras i mitten av dem.

Enligt förordningen måste unionsorgan och offentliga organ inom tillämpningsområdet genomföra en interoperabilitetsbedömning innan de beslutar om nya eller väsentligt ändrade bindande krav. Bedömningen identifierar och utvärderar effekterna på gränsöverskridande interoperabilitet, berörda intressenter och de Interoperable Europe-lösningar som kan stödja genomförandet. Den resulterande rapporten ska offentliggöras i ett maskinläsbart format som underlättar automatisk översättning, med förbehåll för förordningens skydd för immateriella rättigheter, affärshemligheter, allmän ordning och säkerhet.

Det är mer krävande än att fråga om ett föreslaget system har ett API. Ett API kan vara tekniskt prydligt och ändå skapa en barriär för en grannförvaltning, en medborgare, ett litet företag eller en annan offentlig aktör. Bedömningen ställer en annan fråga: vad förändras i förmågan att interagera när detta krav införs? Det skapar utrymme för rättslig befogenhet, organisatoriskt ansvar, semantisk innebörd och teknisk design att framträda i samma samtal. De har alltid varit en del av samma samtal. Programvaran hade bara fått hålla mötet i separata rum.

Förordningen gör också delning konkret. Artikel 4 kräver att en unionsenhet eller ett offentligt organ ställer en interoperabilitetslösning som stödjer en transeuropeisk digital offentlig tjänst till förfogande för en annan sådan enhet eller ett annat sådant organ på begäran, inklusive teknisk dokumentation och, i tillämpliga fall, versionshistorik, dokumenterad källkod och referenser till öppna standarder eller tekniska specifikationer. Det finns undantag, bland annat tredje parts immateriella rättigheter och verksamhet utanför det offentliga uppdraget. Principen är inte att varje rad offentlig programvara måste publiceras utan omdöme. Principen är att en återanvändbar lösning inte ska bli en privat upptäckt varje gång en annan förvaltning behöver den.

Det finns en stilla förskjutning i den formuleringen. Dokumentation och versionshistorik är inte sekundärt pappersarbete efter att den användbara komponenten har skapats. De är en del av det som gör komponenten återanvändbar. En källkodsdatabas utan sammanhang kan vara lika oanvändbar som en resväska utan nyckel. En referensarkitektur utan förklaring av antaganden kan bli ett mycket polerat sätt att exportera förvirring. Det återanvändbara är koden, specifikationen, de kända gränserna, versionen, beviset på hur den var avsedd att användas och villkoren för när den inte bör användas.

Den europeiska interoperabilitetsramen, som akten placerar i centrum av sin bedömningsmodell, behandlar på liknande sätt rättslig, organisatorisk, semantisk och teknisk interoperabilitet samt styrning. Denna fyrlagersvy är användbar eftersom den förhindrar att en typ av framgång utger sig för att vara hela resultatet. Ett tekniskt team kan framgångsrikt implementera ett gränssnitt. Ett juridiskt team kan finna inget hinder för utbytet. Ett operativt team kan enas om eskalering. Ett domänteam kan anpassa innebörden av objekten. Systemet blir tillförlitligt vid gränsen endast när de relevanta lagren är anpassade för den specifika användningen.

Det är också därför en "europeisk standard" inte är en trollformel. Standarder kan minska onödig variation och göra ett kontrakt tillgängligt för fler deltagare. De kan inte avgöra om ett specifikt utbyte är proportionerligt, lagligt, säkert eller användbart. En teknisk profil måste väljas, implementeras, styras och granskas. Den behöver en versionspolicy. Den behöver felhantering. Den behöver ett sätt att representera osäkerhet. Den behöver en process för att avgöra när en lokal utökning är motiverad och när den har blivit en privat förgrening i en offentlig kostym.

Den offentliga sektorn är särskilt avslöjande eftersom kostnaden för semantisk drift ofta bärs av någon utanför det tekniska teamet. En invånare kan bli ombedd att lämna in uppgifter två gånger. Ett företag kan behöva översätta ett formulär från en administrativ vokabulär till en annan. En yrkesperson kan förlora tid på att stämma av register. En gränsöverskridande tjänst kan fungera endast för personer vars ärende råkar passa den enklaste vägen. Akten garanterar inte att dessa utfall försvinner. Den skapar mekanismer för att göra deras interoperabilitetskonsekvenser synliga innan ett krav hårdnar till infrastruktur.

AI bör ärva den disciplinen. Innan en modell läggs till i en transeuropeisk eller på annat sätt viktig tjänst bör ägaren kunna ange vilka objekt modellen kan läsa, vilka objekt den kan skapa, vilka beslut som förblir mänskliga, hur en korrigering sprids, vilken utdata som är ett stöd snarare än en auktoritativ post, hur tjänsten beter sig när modellen inte är tillgänglig och hur en mottagare kan bestrida eller granska resultatet. Det är inte ett extra efterlevnadslager som läggs över en i övrigt färdig produkt. Det är gränssnittsdefinitionen för ett system som förväntar sig att bli betrott av människor som inte delar modellens privata kontext.

För muspekaren över ett lager och välj det. En gräns håller bara när de relevanta lagren är överens om vad som måste hända.

Portabilitet är ett test av om gränsen är verklig

Interoperabilitet blir strategisk när en relation förändras. En tjänst uppdateras. En leverantör byts ut. En offentlig aktör behöver återanvända en komponent. En deltagare i ett dataområde ändrar sin policy. En modellleverantör ändrar sitt meddelandeformat. En ny säkerhetsförutsättning innebär att en arbetsbelastning måste köras någon annanstans. Vid den tidpunkten blir gränsens kvalitet synlig.

Dataakten behandlar detta som mer än en olägenhet för kunder. Dess regler om byte och interoperabilitet för databehandlingstjänster syftar till att minska hindren för att flytta mellan tjänster, använda flera tjänster parallellt och göra data och applikationer portabla. Kommissionens studie från 2026 om interoperabilitet för databehandlingstjänster beskriver artikel 35 som ett krav på öppna, harmoniserade specifikationer som gör att tjänster av samma typ kan samverka och att data och applikationer kan vara portabla utan att säkerheten påverkas negativt. Den noterar också den avsedda unionsdatabasen för relevanta standarder och öppna specifikationer, samt möjligheten till gemensamma specifikationer när harmoniserade standarder inte räcker till.

Det är värt att vara noggrann med vad detta innebär och inte innebär. Dataakten lovar inte att en kund kan lyfta en komplex tjänst från en leverantör och placera den oförändrad hos en annan en fredagseftermiddag. Den kräver inte att leverantörer avslöjar affärshemligheter, äventyrar säkerheten eller gör alla tjänstetyper identiska. Funktionell likvärdighet, där förordningen kräver det för tjänster av samma typ, är inte ett påstående om identiska konsoler, identiska prismodeller eller identiska tekniska val. Det är en mer användbar och mer blygsam idé: delade funktioner bör göra det möjligt för kundens arbetsbelastning att fortsätta sin avsedda funktion över en relevant gräns.

Den distinktionen är viktig eftersom en portabel fil inte nödvändigtvis är en portabel tjänst. En dataexport kan utelämna relationer, händelseordning, konfiguration, behörighetshistorik, identifierare, bevarandestatus, policyversioner och den operativa kunskap som krävs för att återställa systemet. En modellutdata kan exporteras medan hämtningskonfigurationen, promptversionen, utvärderingskriterierna och verktygsbehörigheterna som format den förblir privata. Filen har flyttats. Förutsättningarna under vilka den kunde betros har inte det.

Rätt test är inte ”kan vi ladda ner något?” Det är ”kan en kompetent mottagare tolka och driva den del av tjänsten som spelar roll?” Det är olika frågor. Den första kan besvaras med en knapp. Den andra kräver en inventering, ett schema, en mottagningsväg, ett test, människor som förstår gränsen och en ärlig redogörelse för vad som inte kan färdas.

Betrakta ytterligare ett uttryckligen hypotetiskt exempel. Ett team använder en AI-tjänst för att ta fram ett första utkast för intern granskning. Tjänsten har en exportfunktion. Under en planerad flytt får teamet den genererade texten och en lista över användarkonton. Teamet får inte versionerna av kunskapskällorna, beslutsprotokollen som avgjorde vilka källor som var tillåtna, godkännandestatusen för utkasten, modellkonfigurationen eller reglerna som hindrade tjänsten från att skicka ett utkast till en extern mottagare. Teamet har sin text. Det har inte återfått sitt arbetsflöde. Om den gamla tjänsten vore en dokumentredigerare kunde det vara acceptabelt. Om utkasten formar reglerat eller säkerhetsrelevant arbete är det en annan kategori av problem.

Portabilitet har därför minst fyra lager. Det finns teknisk portabilitet: kan data och gränssnitt överföras i användbara former? Det finns semantisk portabilitet: kan mottagaren förstå posterna, händelserna och begränsningarna? Det finns operativ portabilitet: kan människor köra, säkra, övervaka, korrigera och återställa arbetsbelastningen? Och det finns institutionell portabilitet: kan organisationen fullgöra sina offentliga, avtalsenliga och rättsliga skyldigheter medan flytten sker? Ingen enskild exportformat löser alla fyra.

Det är här upphandling kan bli en konstruktiv kraft. En anbudsförfrågan kan efterfråga kategorierna av exporterbara data och digitala tillgångar, scheman och versioner, hastighetsbegränsningar, integritetskontroller, identitets- och åtkomstkonsekvenser, kända begränsningar, kvarhållnings- och raderingsbeteende samt den hjälp som finns tillgänglig under en övergång. Den kan fråga om en representativ export kan tas emot och valideras av en destination utan privat åtkomst till leverantörens konsol. Den kan fråga vilka delar som är leverantörsspecifika av design. En öppen begränsning är hanterbar. En dold begränsning blir en akutbudget.

Samma frågor hjälper en leverantör. En leverantör som vet vilken gräns den måste hålla stabil kan designa färre oavsiktliga beroenden. Den kan göra en versionspolicy uttrycklig. Den kan publicera en utfasningsväg. Den kan ge kunder en testmiljö som beter sig som ett verkligt gränssnitt snarare än en marknadsföringsdemo. Den kan skilja den del av ett system som är genuint proprietär från den del som måste delas för att en kund ska behålla handlingsutrymme. Det är inte välgörenhet. Det är ett tydligare kontrakt för båda parter.

Europas fördel här är inte att det kan eliminera beroenden. Seriösa system har beroenden. Fördelen är möjligheten att göra beroenden läsbara, förhandlingsbara och tillräckligt reversibla för den aktuella användningen. Ett system som kan stanna hos en leverantör för att det fortsätter att förtjäna relationen är starkare än ett som stannar för att ingen kan rekonstruera innebörden av dess poster någon annanstans.

Dataspace är inte lagerlokaler med bättre belysning

Uttrycket ”dataspace” kan skapa en felaktig bild. Det antyder ett stort rum där alla tar med sig data, ställer den på en hylla och går hem nöjda med interoperabiliteten. Det europeiska synsättet är mer krävande. Gemensamma europeiska dataspace är avsedda att göra data tillgängliga för åtkomst och återanvändning i en tillförlitlig och säker miljö. Kommissionen beskriver gemensamma infrastrukturer och styrningsramar som det som stödjer poolning, åtkomst och delning, tillsammans med rättvisa, transparenta, proportionerliga och icke-diskriminerande åtkomstregler.

Det är en viktig korrigering. Datadelning är inte en engångshandling av överföring. Det är en fortlöpande relation mellan parter med olika syften, befogenheter och ansvar. En deltagare kan kanske använda en datamängd för forskning men inte för marknadsföring. En annan kan ha en skyldighet att korrigera ett värde. En tredje kan få ta emot ett härlett resultat men inte den underliggande posten. Vissa data måste bevaras. Vissa måste raderas. Vissa kan endast behandlas i en viss miljö. De styrande villkoren är en del av interoperabiliteten, inte en fotnot i en separat juridisk pärm.

Kommissionens arbete med dataområden identifierar stöd i referensarkitektur, byggstenar, semantik, interoperabilitetsspecifikationer och datamodeller, tillsammans med rådgivningstjänster genom Data Spaces Support Centre. Denna bredd är förnuftig. En säker anslutning utan ett gemensamt ordförråd löser inte ett semantiskt problem. Ett gemensamt ordförråd utan identitet, åtkomstkontroll eller styrning löser inte ett förtroendeproblem. En modell som kan fråga ett dataområde utan ett deklarerat syfte, källpost och korrigeringsväg gör inte området mer användbart. Den skapar en ny informationskonsument vars skyldigheter är oklara.

För AI är innebörden enkel. En modell bör inte behandlas som en privilegierad genväg förbi en dataområdesgräns. Om en person eller tjänst behöver en grund för åtkomst, ett definierat syfte, en identitet och en användningslogg, behöver ett AI-arbetsflöde samma disciplin. Det kan finnas tekniska skillnader i hur en agent begär data eller hur ett hämtningssteg utförs. Det bör inte finnas en magisk undantagsregel där systemet säger ”modellen behövde sammanhang” och de vanliga styrningsreglerna lämnar byggnaden.

Detta innebär inte att varje uppmaning behöver omvandlas till en byråkratisk ceremoni. Det innebär att systemet måste skilja mellan en fråga och en auktorisering. En modell kan formulera en fråga. Ett policymedvetet lager bör avgöra om frågan får nå en viss källa, under vilket syfte, med vilken minimering, och hur begäran och resultat registreras. Ett svar kan sedan citera en källa eller förklara en begränsning. Om källan ändras behöver systemet ett sätt att veta vilket senare svar eller beslut som kan behöva granskas. Annars blir härkomst en dekorativ länk i en chattutskrift.

Semantiska kontrakt är särskilt användbara här eftersom de gör den minsta förtroendeenheten synlig. En källidentifierare är inte bara en sträng. Den bör identifiera en version eller en stabil referens. En behörighet är inte bara sann eller falsk. Den kan ha en omfattning, ett syfte, en innehavare, en tidsgräns och en grund. En korrigering är inte bara en uppdatering. Den kan ersätta ett tidigare påstående samtidigt som historiken bevaras för att förklara vad som hände. Ett avslag är inte bara ett fel. Det kan vara en medveten gräns som måste vara begriplig för den som frågar.

Frestelsen blir att lösa detta med ett universellt ”AI-interoperabilitetslager” som påstår sig göra varje agent, modell, databas och arbetsflödesverktyg utbytbara. Sådana påståenden blandar oftast ihop gemensam transport med gemensam innebörd. Ett generiskt protokoll kan vara användbart. Det kan inte tala om för en mottagare vad en klinisk kod, en planeringsstatus, ett förmånsbeslut eller en riskflagga betyder i den specifika domänen. Det kan inte avgöra vem som får åsidosätta ett automatiskt förslag. Det kan inte tala om för en organisation hur länge den får behålla en hämtad post. Standarder bär överenskommelser. De tar inte bort behovet av att skapa dem.

Det finns en mer jordnära ambition. Bygg domänspecifika överenskommelser där det gemensamma arbetet motiverar dem. Återanvänd generella byggstenar där de verkligen passar: identitet, auktorisation, härkomst, händelser, versionshantering, överensstämmelsetestning och tillgänglig dokumentation. Håll kopplingen mellan en generell standard och en lokal implementering granskningsbar. Då kan en deltagare ansluta utan att överlämna hela sitt system, och en sektor kan utvecklas utan att börja från tomma blad varje gång en ny leverantör ansluter.

Det är en bättre form av skala. Den mäter inte framgång i hur mycket data som har centraliserats eller hur många tjänster som har tvingats in i ett enda gränssnitt. Den mäter framgång i om ett legitimt utbyte kan ske med tillräcklig tydlighet för att deltagarna ska kunna använda, korrigera, styra och, när det behövs, stoppa det.

Välj ett kort för att inspektera den del av ett utbyte som gör en post användbar utanför sitt ursprungliga system.

Standarder behöver ett liv efter publicering

Standarder beskrivs ofta som om arbetet avslutas när dokumentet publiceras. I praktiken är publiceringen den punkt där det svårare arbetet börjar. Någon måste välja den tillämpliga profilen. Någon måste implementera den. Någon måste testa gränsfall. Någon måste avgöra om en ny version är kompatibel, när den gamla versionen fasas ut och vad som händer med poster som skapats under tidigare regler. Någon måste förklara hela arrangemanget för ett team som inte var i rummet när akronymen valdes.

CEN och CENELEC:s EN 18235-1:2026 är ett färskt exempel på utvecklingsriktningen. Standarden rör datadelning och utbyte mellan organisationer, med tonvikt på interoperabilitet och ansvarsskyldighet, och dess annonserade tillämpningar inkluderar gemensamma europeiska datautrymmen. Detaljerna spelar mindre roll här än signalen. Förtroende för datadelning behandlas inte som en känsla som genereras av en instrumentpanel. Det behandlas som något som formas av överenskommelser kring utbyte, ansvar och förmågan att redogöra för vad som har hänt.

Det bästa standardiseringsarbetet lämnar utrymme för det som det inte kan avgöra. En teknisk specifikation kan definiera en meddelandestruktur. Den kan inte fastställa en lokal rättslig grund. En vokabulär kan definiera ett begrepp. Den kan inte garantera att en lokal process använder begreppet ärligt. Ett överensstämmelsetest kan visa att en implementering uppfyller namngivna fall. Det kan inte bevisa att organisationen har utbildat de personer som hanterar undantag. Att låtsas något annat gör standarderna en otjänst. Det får dem att framstå som ett substitut för omdöme snarare än ett verktyg som låter omdömet nå längre.

Överensstämmelsetestning är särskilt värdefull eftersom den förvandlar interoperabilitet från ett löfte till en observerbar egenskap. En leverantör kan säga att den stöder en profil. En köpare bör kunna fråga vilken version, vilka valfria funktioner, vilka negativa fall, vilka felsvar och vilka publicerade testbevis som stöder det påståendet. En implementerare bör kunna köra samma fall innan en integration når produktion. En ändring bör deklarera om den är bakåtkompatibel och vilka konsumenter som måste agera.

För AI-gränssnitt kan detta kännas petigt tills den första inkompatibla ändringen. Ett verktygsanrop förväntar sig ett penningbelopp i cent. Ett annat returnerar en decimalsträng utan valuta. En agent behandlar ett frånvarande fält som en begäran om mer information. En annan tolkar det som tillstånd att sluta sig till ett värde. En modelluppdatering ändrar strukturen på citat. En nedströmsprocess tolkar fortfarande den gamla strukturen. Inget av detta är ett filosofiskt problem. Det är vanliga gränssnittsfel som blir mer konsekvensrika av ett system som kan agera snabbt.

Ett bra kontrakt innehåller därför både avvisanden och framgångar. Det anger vad systemet kommer att avvisa, vad det returnerar när en källa inte kan verifieras, vad det gör när en policy saknas, hur mottagaren kan skilja partiell från fullständig data och var mänsklig granskning börjar. Tystnad är en fruktansvärd interoperabilitetsstrategi. Ett tydligt avvisande är ofta det mest kompatibla svaret eftersom det ger nästa system ett ärligt tillstånd att arbeta med.

Versionshantering förtjänar samma respekt. Ett användbart gränssnitt lägger inte bara till ett versionsnummer i en URL och hoppas på det bästa. Det deklarerar ändringen, anger migreringsvägen, bevarar det gamla kontraktet under den utlovade perioden där det är möjligt, dokumenterar hur lagrad data tolkas mellan versioner och ger tillräckligt med varsel för att beroende system ska kunna anpassa sig. Detta är inte spännande arbete. Det är så en gräns slutar vara en överraskning. I Nederländerna finns en förkärlek för att säga att en sak är "tillräckligt tydlig" tills någon måste bygga den. Versionspolicy är det som återstår efter att det uttrycket har mött ett produktionssystem.

Det finns en europeisk ekonomisk poäng här. Mindre organisationer kan delta när reglerna för anslutning är offentliga, dokumenterade och testbara. De behöver inte en privat relation med varje dominerande plattform bara för att upptäcka hur ett utbyte beter sig. Större organisationer gynnas också, eftersom de kan minska skräddarsydd integrationsskuld och testa en leverantörs påståenden innan ett kärnberoende har formats. Resultatet är inte friktionsfritt. Det är rättvisare friktion: arbetet är synligt, prissatt och delat snarare än upptäckt efter att kontraktet har begränsat alternativen.

Den praktiska frågan är vad som överlever överlämningen

De flesta interoperabilitetsprogram blir bättre när de börjar med ett litet utbyte snarare än en stor ambition. Välj en beslutspunkt eller tjänstegräns. Beskriv informationen som måste korsa den. Namnge auktoritetskällan, mottagaren, det tillåtna syftet, vokabulären, livscykelhändelserna, säkerhetsvillkoren och bevisen som ska visa att utbytet skedde som avsett. Testa sedan både framgång och misslyckande.

Det resulterande samtalet är ofta mer avslöjande än en funktionsjämförelse. Vad händer när källan korrigerar en post? Kan mottagaren identifiera vilken kopia som påverkas? Vad händer när ett AI-system inte kan stödja en rekommendation med en tillåten källa? Returnerar det ett explicit avvisande, ett partiellt resultat eller ett påhittat förtroende? Vad händer när en mottagare får en schemaversion det inte förstår? Kan det avvisa utbytet säkert? Vad händer när en person bestrider en klassificering? Blir korrigeringen en ny händelse med ett spår, eller skrivs det gamla resultatet över tills ingen kan rekonstruera grunden för den ursprungliga åtgärden?

Dessa är designfrågor, inte bara efterlevnadsfrågor. De formar huruvida människor kan driva en tjänst, huruvida en leverantör kan stödja den och huruvida ett annat system kan ansluta utan att ärva en odokumenterad risk. De formar också kvaliteten på AI. En modell med en tydlig informationsgräns har mindre utrymme att förvandla tvetydig kontext till osynliga antaganden. Ett arbetsflöde med typade utdata och källidentitet ger granskare något konkret att inspektera. En versionshanterad beslutslogg gör utvärdering möjlig efter att modellen, prompten eller policyn har ändrats.

Det finns förnuftiga gränser. Vissa uppgifter bör inte färdas. Viss information bör minimeras eller aggregeras. Vissa tjänster behöver en skräddarsydd gräns eftersom arbetet är ovanligt, känsligt eller högrisk. En del lokal vokabulär bör förbli lokal, eftersom att tvinga fram en falsk likvärdighet skulle förstöra innebörden. Interoperabilitet är inte ett krav på att varje system ska exponera allt. Det är ett krav på att den valda gränsen är ärlig om vad den exponerar, varför, för vem och med vilka konsekvenser.

Den ärligheten är särskilt viktig när AI-leverantörer erbjuder snabb anslutning. En koppling som i tysthet kopierar ett stort korpus till en modellkontext kan lösa ett demonstrationsproblem samtidigt som den skapar ett styrningsproblem. Ett verktyg som skriver in i ett affärssystem utan en beständig arbetsidentifierare kan skapa en automatisering samtidigt som det omöjliggör granskning. Ett universellt agentprotokoll kan göra upptäckt enklare samtidigt som auktorisering, ändamålsbegränsning och semantiskt ansvar lämnas obehandlade. Frågan bör alltid vara vad som överlever överlämningen: uppgifterna, innebörden, tillståndet, bevisningen och möjligheten att korrigera.

Ett användbart program ger var och en av dessa en plats. Uppgifter behöver ett format och en integritetskontroll. Innebörd behöver en modell, vokabulär eller explicit mappning. Tillstånd behöver en identitet, ett ändamål och en policygräns. Bevisning behöver en registrering av källa, version, transformation och beslut. Korrigering behöver en händelseväg och en ansvarig ägare. Drift behöver en runbook, observerbarhet och ett sätt att stoppa eller rulla tillbaka en ändring. Inget av detta ger en hjältemodig lanseringsfilm. Det gör däremot att ett system kan förbli användbart efter att lanseringsfilmen har ersatts av en supportanmälan.

På Dweve tillämpar vi principen snävt i den offentliga beskrivningen av Fabric. Webbplatsen beskriver en arbetscentrerad objektmodell där modeller, agenter, verktyg, människor och arbetsflöden deltar genom typade kontrakt, och den beskriver användargränssnitt och API:er som verkar på samma domän. Det är en produktdesignposition, inte bevis för att någon driftsättning automatiskt är interoperabel eller att ett typat gränssnitt avgör juridiska, semantiska eller operativa frågor. Det är helt enkelt den typ av gräns som vi anser att seriösa AI-system behöver: en där det beständiga arbetet inte försvinner in i en leverantörsspecifik konversation.

HEDL erbjuder ett mindre, offentligt exempel. Dess dokumentation beskriver ett textformat licensierat under Apache 2.0, en publicerad formatspecifikation och konformansdokument, med konverteringar till och från JSON, YAML, XML, CSV, Parquet och TOON. Dessa funktioner gör inte varje dataset kompatibelt, och de gör inte en formatkonvertering till semantisk överensstämmelse. De gör däremot ett användbart påstående om en gräns: ett utbytesformat bör vara inspekterbart, testbart och kunna ligga bredvid befintliga system snarare än att kräva att varje system blir sin egen privata dialekt.

Europa behöver inte vinna en AI-kapplöpning genom att springa ifrån sina egna institutioner. Dess möjlighet är att göra dessa institutioner, marknader och tekniska gemenskaper lättare att koppla samman utan att låtsas att deras skillnader inte spelar någon roll. Arbetet kommer att se tråkigt ut på avstånd. Det är versionshistorik, testfixturer, vokabulärval, åtkomstregler, migreringsövningar och det enstaka obekväma mötet om vem som får ändra ett fält. På nära håll är det arbetet som gör att ett system kan litas på av någon annan än teamet som byggde det.

Det är en fördel värd att ha. En modell kan ersättas. En leverantör kan bytas. En tjänst kan passera en gräns. En korrigering kan nå dit där den spelar roll. En person kan fråga vad som hände och få något bättre än ett självsäkert stycke. Tekniken förblir ambitiös. Gränsen förblir ordinär. Det ordinära är det som ger ambitionen något tillförlitligt att stå på.

Källor