Európa következő AI-előnye az unalmas interoperabilitás lehet

Európa nem teszi hasznosabbá a mesterséges intelligenciát azzal, ha minden rendszer egyforma. Kormányozhatóbbá viszont teheti, ha ragaszkodik ahhoz, hogy a...

Európa következő AI-előnye az unalmas interoperabilitás lehet

Az a hétköznapi dolog, ami használhatóvá tesz egy rendszert

Az interoperabilitásnak imázsproblémája van. Úgy hangzik, mint egy programnak az a része, amit azokra hagynak, akik élvezik a referenciaarchitektúrákat, a verziótáblázatokat és egy séma pontos írásjeleit. Ez a hírnév nem teljesen alaptalan. Egy jó interfész-szerződés soha nem fog felülmúlni egy új modellt egy termékbemutatón. Senki nem hoz tortát azért, mert két szolgáltatás végre egyetért egy törölt rekord jelentésében.

Mégis ez az egyetértés az, ahol a hasznos munka nagy része kezdődik. Egy modell lenyűgöző lehet önmagában, és mégis korlátozott segítséget nyújthat egy szervezetnek, amely nem tudja összekapcsolni azokkal a rekordokkal, szabályokkal, emberekkel és döntésekkel, amelyek értelmet adnak a munkának. A modell gördülékeny választ adhat. De ha a válasz nem hordozhat forrásazonosítót, ha egy korrekció nem érheti el azokat a rendszereket, amelyek az alapján működtek, ha egy ember nem tudja megmondani, melyik szabályzatverzió volt érvényben, akkor a rendszer nem vált a munka részévé. Egy újabb hely lett, ahonnan másolni és beilleszteni lehet.

Európa következő AI-előnye ezért meglehetősen dicstelen lehet. Lehet, hogy az a képesség, hogy a rendszerek olyan határokon találkozzanak, amelyek egyértelműek, ellenőrizhetők és tisztességesen elhagyhatók. Nem egy kontinentális szuperalkalmazás. Nem egy követelmény, hogy minden kórház, városháza, laboratórium és gyártó egyetlen adatbázist használjon. A hasznos ambíció szűkebb és nehezebb: egy szolgáltatásnak képesnek kell lennie információt cserélni, megőrizni az információ jelentését, tiszteletben tartani a körülötte lévő feltételeket, és működőképesnek maradni, amikor egy másik összetevő megváltozik.

Ez stratégiai képesség. Egy eszközgyűjteményt infrastruktúrává alakít. Lehetővé teszi, hogy egy tagállam közigazgatása elismerjen egy másikban létrehozott rekordot anélkül, hogy azt színlelné, hogy a törvényeik, nyelveik vagy eljárásaik azonosak. Lehetővé teszi egy vállalatnak, hogy megváltoztasson egy adatfeldolgozó szolgáltatást anélkül, hogy elveszítené azokat a digitális eszközöket, amelyek működőképessé teszik a szolgáltatást. Lehetőséget ad a vevőnek, hogy megkérdezze, csatlakozhat-e egy AI-rendszer egy meglévő folyamathoz anélkül, hogy csendben a magáénak vallaná. Lehetőséget ad egy kisebb beszállítónak, hogy dokumentált határon versenyezzen, nem pedig az ügyfél migrációs fájdalomtűrésén.

A lényeget könnyű félreérteni. Az interoperabilitás nem automatikus erény. Egy rosszul megtervezett interfész gyorsan terjeszthet egy rossz feltételezést. Egy megosztott adatmodell lehet túl tág, túl tolakodó vagy túl homályos. Egy szabvány válhat múzeumi darabbá. Egy nyílt API lehet drága, nem biztonságos vagy olyan rosszul dokumentált, hogy főként annak bizonyítékaként szolgál, hogy egyszer létezett egy API-részleg. Európának nincs szüksége dekoratív specifikációhalomra. Olyan szerződésekre van szüksége, amelyek hétköznapi körülmények között működnek, beleértve a korrekciót, visszavonást, frissítést, megszakítást és távozást.

Az Interoperable Europe Act hasznos definíciót ad a közszolgáltatásokra. A határokon átnyúló interoperabilitást úgy kezeli, mint az uniós szervek és a tagállami közszféra szerveinek képességét arra, hogy kölcsönhatásba lépjenek adatok, információk és tudás megosztásával olyan digitális folyamatok révén, amelyek megfelelnek a jogi, szervezeti, szemantikai és technikai követelményeknek. A négy szó számít. A technikai kompatibilitás csak egy réteg. Két szolgáltatás cserélhet bájtokat, és mégis egyetérthetnek a tekintélyről, a célról, a megőrzésről vagy egy állapot jelentéséről. Megoszthatnak egy jóváhagyott mezőt, miközben az egyik előzetes ellenőrzést jelent, a másik pedig végleges jogi döntést. A mező utazik. A döntés nem.

Itt válik a téma érdekesebbé a csővezeték-szerelésnél. Az interoperabilitás azt kérdezi, minek kell igaznak maradnia, amikor valami átlép egy határt. Melyik szervezet felelős? Mi az információ egysége? Ki módosíthatja? Mi történik, ha egy forrást kijavítanak? Mit jelent egy hiányzó érték? Melyik személyazonosság lett ellenőrizve? Meddig őrizheti meg a fogadó? Egy másik rendszer bizonyítani tudja-e, melyik verziót kapta? Ezek közkérdések, kereskedelmi kérdések és mérnöki kérdések egy kabátban.

Az AI zsúfoltabbá teszi a kabátot. Egy AI-rendszer ülhet a nyilvántartások és az emberek között, anyagokat kérhet le több forrásból, alkalmazhat egy modellverziót, meghívhat egy eszközt, javasolhat egy műveletet, és döntési nyilvántartást hagyhat maga után. Ha ezeknek az átadásoknak egyikéhez sincs meghatározott szerződés, egy képességekkel rendelkező modell kevésbé átláthatóvá teheti a szervezetet, nem pedig képessébbé. A válasz lehet meggyőző, de nyomon követhetetlen. A munkafolyamat gyorsabbnak tűnhet, de függővé válhat egyetlen szállító privát üzenetformátumától, privát ügynökállapotától és privát feladatdefiníciójától. Ez nem intelligencia. Ez a tulajdonjog megváltozása, amely egy kényelmi funkcióba van rejtve.

Az unalmas interoperabilitás melletti érv nem az, hogy unalmassá teszi a technológiát. Hanem az, hogy felelősségre vonhatóvá teszi. Európa kivételesen jó helyzetben van ahhoz, hogy értékelje ezt a különbséget. Közszolgáltatásai átlépik a határokat. Nyelvei és közigazgatási hagyományai ellenállnak annak az ábrándnak, hogy egyetlen szókincs egyszerűen rákényszeríthető. Adatszabályai egyre inkább a hozzáférést, a hordozhatóságot és az irányítást tekintik a működő piac feltételeinek. Szervezetei pedig gyakran próbálnak AI-t hozzáadni olyan munkához, amelynek már vannak kötelezettségei, nyilvántartásai és következményei. A határ azért számít, mert az emberek már mindkét oldalán állnak.

A kompatibilitás még nem megértés

Többféleképpen tűnhet két rendszer kompatibilisnek. Használhatják ugyanazt a hálózati protokollt. Elfogadhatják ugyanazt a fájltípust. Hitelesíthetnek ugyanazzal az azonosítási rendszerrel. Akár ugyanazt a megfelelőségi tesztet is teljesíthetik. Mindegyik hasznos. Egyik sem dönti el a nagyobb kérdést: tudja-e a fogadó rendszer helyesen használni az információt a megadott célra?

Vegyünk egy szerény, hipotetikus példát. Egy regionális hatóság értesítést küld egy szomszédos hatóságnak egy jól dokumentált felületen keresztül. A csomag érvényes. Az aláírás ellenőrizhető. Minden kötelező mező jelen van. Az egyik mező egy dátumot tartalmaz. A küldő rendszer azt a napot érti alatta, amikor az alapul szolgáló esemény bekövetkezett. A fogadó rendszer azt a napot érti alatta, amikor az értesítés jogilag hatályossá vált. Nem veszett el csomag. Nem hibásodott meg szerver. A rendszerek technikailag kompatibilisek voltak, de szemantikailag eltértek egymástól. Az eredmény lehet rossz határidő, szükségtelen fellebbezés, vagy olyan személy, akitől azt kérik, hogy ismételjen meg egy olyan munkát, amelyet egy gép már elvégzett.

A példa szándékosan hipotetikus. Nem kell hozzá fiktív városháza vagy kedd reggel ahhoz, hogy érthető legyen a lényeg. Sok nehéz digitális hiba nem drámai. Úgy érkeznek, mint egy látszólag teljes nyilvántartás, amelyhez egy ki nem mondott feltételezés kapcsolódik. Egy időbélyegnek nincs időzónája. Egy érték üres, de senki nem mondja meg, hogy az üresség ismeretlent, elhallgatottat, nem alkalmazhatót vagy még nem ellenőrzöttet jelent-e. Egy azonosító stabil az egyik rendszerben, és újrahasznosított a másikban. Egy hozzájárulási jelző utazik a cél, a hatókör és a lejárat nélkül, amelyek értelmet adtak neki. Az integráció addig működik, amíg valaki rá nem hagyatkozik.

A szemantikai interoperabilitás az a fegyelem, amely ezeket a jelentéseket elég egyértelművé teszi ahhoz, hogy megoszthatók legyenek. Nem igényel univerzális szótárat az emberi ügyek minden területére. Azt igényli, hogy egy meghatározott adatcsere résztvevői megegyezzenek abban, hogy mire utalnak a kifejezéseik, milyen korlátozások vonatkoznak rájuk, mely értékek megengedettek, és hogyan kommunikálják a változásokat. A szabványosítás nyelvén ez adatmodelleket, szókincseket, azonosítókat, kapcsolatokat és azokat a szabályokat érinti, amelyek lehetővé teszik a fogadó számára az értelmezésüket. Egy üzemeltető nyelvén ez a különbség a nyilvántartás átvétele és annak átvétele között, amire biztonságosan lehet támaszkodni.

Az ETSI adatügyi műszaki bizottsága munkáját adatkezelési, szemantikai interoperabilitási, ontológiai és szabályozási összehangolási kérdésekkel írja le, azzal a céllal, hogy az adatok ágazatok és országhatárok között megoszthatók és újra felhasználhatók legyenek. Ez a keret üdítően szerény. Elutasítja azt a gondolatot, hogy az adatnak pusztán azért van értéke, mert egy tóba, egy térbe vagy egy tiszteletre méltó számú fület tartalmazó táblázatba került. Az adat akkor válik újra felhasználhatóvá, ha a körülötte lévő feltételek kellően egyértelműek ahhoz, hogy egy másik fél korlátozott, jogszerű felhasználást tegyen vele.

Az európai adatmegosztási rendelet ugyanezt a pontot más irányból közelíti meg. Az interoperabilitásra vonatkozó rendelkezései az adatterekre és az adatfeldolgozási szolgáltatásokra vonatkoznak. A Bizottság magyarázata szerint a szabványok és az interoperabilitás központi szerepet játszanak a különböző forrásokból származó adatok felhasználásában az európai közös adattereken belül és azok között, valamint az adatfeldolgozási szolgáltatások közötti könnyebb váltásban. Ez nem ígéret arra, hogy minden rendszer hirtelen megérti az összes többi rendszert. Ez annak szakpolitikai elismerése, hogy az elszigetelt szolgáltatások piaca kevesebb gyakorlati választási lehetőséget hagy az ügyfeleknek.

Csábító, hogy a „szemantikus” szó hallatán egy grandiózus ontológiára gondoljunk, egy olyan ábrára, amelyhez saját postai cím kellene. Néha egy szakterületnek jelentős közös modellezésre van szüksége. De a jobb kiindulópont kisebb. Mi az objektum ebben a cserében? Melyik verziót küldik? Melyik szervezet birtokolja a hiteles értéket? Milyen esemény változtathatja meg? Mit kell tennie a címzettnek, amikor ez az esemény bekövetkezik? Melyik felhasználás engedélyezett? Hogyan vizsgálhatja meg egy személy a választ, ha az automatizált út bizonytalan? Egy szűk, megválaszolható szerződés értékesebb, mint egy átfogó ábra, amelyet senki sem tud megvalósítani.

Ugyanez a visszafogottság fontos a mesterséges intelligencia esetében is. Egy MI-alapú munkafolyamatnak lehet, hogy át kell adnia egy munkaelemet egy modellnek, fogadnia kell egy javasolt besorolást, csatolnia kell forrásokat, jóváhagyást kell kérnie, és be kell írnia a döntést egy ügykezelő rendszerbe. Nem szabad úgy tennie, mintha egy természetes nyelvű magyarázat elegendő felület lenne. A munkafolyamatnak tipizált tényekre is szüksége van, nem csak szavakra: a munkaelem azonosítójára, a forrásverziókra, a megadott feladatra, az engedélyezett eszközökre, a megbízhatósági vagy elutasítási feltételre, ahol releváns, a felülvizsgáló döntésére, az időpontra és a szabályzat verziójára. A modell maradhat valószínűségi alapú. A modell körüli határnak nem szabad megszokásból homályosnak lennie.

Ezért az interoperabilitás nem ugyanaz, mint az integráció. Az integráció lehet egy magánjellegű kapcsolat, amelyet egyetlen kapcsolat érdekében építettek ki. Lehet teljesen megfelelő. De ha a szemantikája csak a szállító megvalósításában, egy munkatárs emlékezetében vagy egy műhelymunka diasorában él, a kapcsolat nem terjed jól. Egy interoperábilis határ mögött olyan szerződés marad, amelyet egy másik hozzáértő fél el tud olvasni, tesztelni tud és meg tud kérdőjelezni. Létrehozása lassabb, mint egy gyors csatlakozóé. Javítása gyorsabb, amikor az eredeti csatlakozó logóval ellátott függőséggé vált.

Európa keretrendszere a teljes problémával kezdődik

Az interoperábilis Európa jogszabály nem MI-rendelet, és hiba lenne annak beállítani. Ez a határokon átnyúló, közszférán belüli interoperabilitásról szóló rendelet. Értéke a mesterséges intelligencia számára alapvetőbb. Leír egy gondolkodásmódot a digitális közszolgáltatásokról, mielőtt egy adott technológiát a középpontjukba helyeznénk.

A rendelet értelmében az uniós szerveknek és az alkalmazási körbe tartozó közszférabeli szerveknek interoperabilitási értékelést kell végezniük, mielőtt új vagy jelentősen módosított kötelező követelményekről döntenének. Az értékelés azonosítja és értékeli a határokon átnyúló interoperabilitásra, az érintett érdekelt felekre és az interoperábilis Európa megoldásokra gyakorolt hatásokat, amelyek támogathatják a végrehajtást. Az elkészült jelentést géppel olvasható formátumban kell közzétenni, amely megkönnyíti az automatikus fordítást, a rendelet szellemi tulajdonra, üzleti titkokra, közrendre és biztonságra vonatkozó védelmeinek sérelme nélkül.

Ez nagyobb kihívás, mint megkérdezni, hogy egy javasolt rendszer rendelkezik-e API-val. Egy API technikailag rendezett lehet, mégis akadályt jelenthet egy szomszédos közigazgatási szervnek, egy polgárnak, egy kisvállalkozásnak vagy egy másik közintézménynek. Az értékelés más kérdést tesz fel: mi változik az interakció képességében, ha ezt a követelményt bevezetik? Ez teret ad arra, hogy a jogi felhatalmazás, a szervezeti felelősség, a szemantikai jelentés és a technikai tervezés ugyanabban a beszélgetésben jelenjen meg. Mindig is ugyanannak a beszélgetésnek a részei voltak. A szoftvernek csupán megengedték, hogy külön termekben tartsa az értekezletet.

A rendelet a megosztást is kézzelfoghatóvá teszi. A 4. cikk előírja, hogy egy uniós szervezet vagy közszférabeli szerv egy transzeurópai digitális közszolgáltatást támogató interoperabilitási megoldást bocsásson egy másik ilyen szervezet vagy szerv rendelkezésére kérésre, beleértve a műszaki dokumentációt és adott esetben a verziótörténetet, a dokumentált forráskódot és a nyílt szabványokra vagy műszaki előírásokra való hivatkozásokat. Vannak kivételek, többek között a harmadik felek szellemi tulajdonjogai és a közfeladaton kívüli tevékenységek. Az elv nem az, hogy a közszféra szoftverének minden sorát meg kell jelentetni mérlegelés nélkül. Az elv az, hogy egy újra felhasználható megoldás ne váljon magánjellegű felfedezéssé minden alkalommal, amikor egy másik közigazgatási szervnek szüksége van rá.

Csendes elmozdulás van ebben a megfogalmazásban. A dokumentáció és a verziótörténet nem másodlagos papírmunka, miután a hasznos összetevő elkészült. Részei annak, ami az összetevőt újra felhasználhatóvá teszi. A forrásadattár kontextus nélkül éppoly használhatatlan lehet, mint a bőrönd kulcs nélkül. A referenciaarchitektúra a feltételezések magyarázata nélkül nagyon csiszolt módszerré válhat a zavar exportálására. Az újra felhasználható dolog a kód, az előírás, az ismert határok, a verzió, a bizonyíték arra vonatkozóan, hogyan szándékozták használni, és azok a feltételek, amelyek között nem szabad használni.

Az Európai Interoperabilitási Keretrendszer, amelyet a jogszabály értékelési modelljének középpontjába helyez, hasonlóképpen foglalkozik a jogi, szervezeti, szemantikai és technikai interoperabilitással és irányítással. Ez a négyszintű nézőpont azért hasznos, mert megakadályozza, hogy az egyfajta siker a teljes eredményt utánozza. Egy műszaki csapat sikeresen megvalósíthat egy interfészt. Egy jogi csapat nem találhat akadályt a cserében. Egy műveleti csapat megállapodhat az eszkalációról. Egy szakterületi csapat összehangolhatja az objektumok jelentését. A rendszer csak akkor válik megbízhatóvá a határon, ha az érintett rétegek összehangoltak az adott felhasználásra.

Ezért is nem varázsige az „európai szabvány”. A szabványok csökkenthetik a felesleges változatosságot, és több résztvevő számára elérhetővé tehetik a szerződést. Nem dönthetik el, hogy egy adott csere arányos, jogszerű, biztonságos vagy hasznos-e. Egy műszaki profilt ki kell választani, meg kell valósítani, irányítani kell és felül kell vizsgálni. Verziószabályzatra van szüksége. Hibakezelésre van szüksége. Módra van szüksége a bizonytalanság ábrázolására. Eljárásra van szüksége annak eldöntésére, hogy mikor indokolt a helyi kiterjesztés, és mikor vált magánvillából nyilvános kabátban.

A közszféra esete különösen tanulságos, mert a szemantikai eltérés költségét gyakran a műszaki csapaton kívül álló személy viseli. Egy lakostól kétszer is elkérhetik ugyanazt az információt. Egy vállalkozásnak le kell fordíttatnia egy űrlapot az egyik közigazgatási szókincsből a másikba. Egy szakember időt veszíthet a nyilvántartások egyeztetésével. Egy határokon átnyúló szolgáltatás csak azoknak működhet, akiknek az ügye éppen beleillik a legkönnyebb útba. A jogszabály nem garantálja, hogy ezek az eredmények eltűnnek. Mechanizmusokat hoz létre annak érdekében, hogy az interoperabilitási következmények láthatóvá váljanak, mielőtt egy követelmény infrastruktúrává szilárdul.

Az MI-nek örökölnie kell ezt a fegyelmet. Mielőtt egy modellt egy transzeurópai vagy más módon jelentős szolgáltatáshoz adnak hozzá, az üzemeltetőnek meg kell tudnia mondani, hogy a modell mely objektumokat olvashatja, mely objektumokat hozhat létre, mely döntések maradnak emberi kézben, hogyan terjed egy korrekció, mely kimenet segédlet és nem hiteles nyilvántartás, hogyan viselkedik a szolgáltatás, ha a modell nem érhető el, és hogyan támadhatja meg vagy vizsgálhatja meg a címzett az eredményt. Ez nem egy további megfelelőségi réteg, amelyet egy egyébként kész termékre borítanak. Ez egy olyan rendszer interfész-definíciója, amely azt várja, hogy olyan emberek bízzanak benne, akik nem osztoznak a modell privát kontextusában.

Vigye az egérmutatót egy réteg fölé, és válassza ki. Egy határ csak akkor áll fenn, ha az érintett rétegek egyetértenek abban, hogy minek kell történnie.

A hordozhatóság próbája annak, hogy a határ valódi-e

Az interoperabilitás akkor válik stratégiaivá, amikor egy kapcsolat megváltozik. Egy szolgáltatást frissítenek. Egy szállítót lecserélnek. Egy közintézménynek újra kell hasznosítania egy összetevőt. Egy adattér-résztvevő módosítja a politikáját. Egy modellszolgáltató megváltoztatja az üzenetformátumát. Egy új biztonsági feltétel miatt egy munkaterhelésnek máshol kell futnia. Ekkor válik láthatóvá a határ minősége.

Az adatmegosztási rendelet ezt többre tartja, mint a vásárlók kellemetlenségét. Az adatfeldolgozási szolgáltatások közötti váltásra és interoperabilitásra vonatkozó szabályai célja, hogy csökkentsék a szolgáltatások közötti átjárás, a több szolgáltatás párhuzamos használatának, valamint az adatok és alkalmazások hordozhatóságának akadályait. A Bizottság 2026-os, az adatfeldolgozási szolgáltatások interoperabilitásáról szóló tanulmánya a 35. cikket úgy írja le, mint amely nyílt, harmonizált specifikációkat követel meg, amelyek lehetővé teszik, hogy az azonos típusú szolgáltatások együttműködjenek, és hogy az adatok és alkalmazások hordozhatók legyenek a biztonság hátrányos befolyásolása nélkül. A tanulmány megjegyzi továbbá a releváns szabványok és nyílt specifikációk tervezett uniós adattárát, valamint a közös specifikációk lehetőségét, ha a harmonizált szabványok nem elegendőek.

Érdemes pontosan meghatározni, hogy ez mit jelent és mit nem. Az adatmegosztási rendelet nem ígéri, hogy egy vásárló egy péntek délután felemelhet egy összetett szolgáltatást az egyik szolgáltatótól, és változatlanul elhelyezheti egy másikon. Nem követeli meg a szolgáltatóktól, hogy felfedjék üzleti titkaikat, veszélyeztessék a biztonságot, vagy minden szolgáltatástípust azonossá tegyenek. A funkcionális egyenértékűség, ahol a rendelet ezt megköveteli az azonos típusú szolgáltatásoknál, nem azonos konzolok, azonos ármodellek vagy azonos mérnöki döntések állítása. Ez egy hasznosabb és szerényebb gondolat: a közös funkcióknak lehetővé kell tenniük, hogy a vásárló munkaterhelése folytassa rendeltetésszerű működését egy releváns határon át.

Ez a megkülönböztetés azért fontos, mert egy hordozható fájl nem feltétlenül hordozható szolgáltatás. Egy adatexport kihagyhat kapcsolatokat, eseménysorrendet, konfigurációt, engedélyelőzményeket, azonosítókat, megőrzési állapotot, politikaváltozatokat és a rendszer helyreállításához szükséges működési ismereteket. Egy modellkimenet exportálható, miközben a lekérési konfiguráció, a promptverzió, az értékelési szempontok és az eszközengedélyek, amelyek alakították, privátak maradnak. A fájl elmozdult. Azok a feltételek, amelyek mellett megbízható lett volna, nem.

A helyes teszt nem az, hogy „le tudunk-e tölteni valamit?”, hanem az, hogy „egy hozzáértő célhely értelmezni és működtetni tudja-e a szolgáltatás releváns részét?”. Ezek különböző kérdések. Az elsőre egy gomb is választ adhat. A másodikhoz leltár, séma, fogadó útvonal, teszt, a határt értő emberek és őszinte nyilatkozat szükséges arról, hogy mi nem utazhat.

Vegyünk egy másik, kifejezetten hipotetikus példát. Egy csapat mesterséges intelligencia szolgáltatást használ arra, hogy belső felülvizsgálatra előkészítse az első vázlatot. A szolgáltatás rendelkezik exportálási funkcióval. Egy tervezett átállás során a csapat megkapja a generált szöveget és a felhasználói fiókok listáját. Nem kapja meg a tudásforrások verzióit, azokat a döntési nyilvántartásokat, amelyek meghatározták, hogy mely források voltak megengedettek, a vázlatok jóváhagyási állapotát, a modellkonfigurációt vagy azokat a szabályokat, amelyek megakadályozták, hogy a szolgáltatás vázlatot küldjön külső címzettnek. A csapatnak megvan a szövege. A munkafolyamatát nem kapta vissza. Ha a régi szolgáltatás dokumentumszerkesztő lett volna, ez talán elviselhető. Ha a vázlatok szabályozott vagy biztonsági szempontból releváns munkát alakítanak, akkor ez más kategóriájú probléma.

A hordozhatóságnak ezért legalább négy rétege van. Létezik technikai hordozhatóság: átvihetők-e az adatok és a felületek használható formában? Létezik szemantikai hordozhatóság: meg tudja-e érteni a fogadó fél a nyilvántartásokat, eseményeket és korlátozásokat? Létezik működési hordozhatóság: tudják-e az emberek futtatni, biztosítani, megfigyelni, javítani és helyreállítani a munkaterhelést? És létezik intézményi hordozhatóság: teljesíteni tudja-e a szervezet nyilvános, szerződéses és jogi kötelezettségeit az átállás alatt? Egyetlen exportformátum sem rendezi mind a négyet.

Itt válhat a beszerzés építő erővé. Egy pályázati felhívás kérheti az exportálható adatok és digitális eszközök kategóriáit, a sémákat és verziókat, az átviteli korlátokat, az integritásellenőrzéseket, az azonosítással és hozzáféréssel kapcsolatos következményeket, az ismert korlátokat, a megőrzési és törlési viselkedést, valamint az átállás során elérhető támogatást. Kérdezheti, hogy egy reprezentatív exportot fogadni és érvényesíteni tud-e egy célrendszer anélkül, hogy privát hozzáférést kapna a szállító konzoljához. Kérdezheti, hogy mely részek szállítóspecifikusak tervezésük szerint. A nyílt korlát kezelhető. A rejtett korlát vészhelyzeti költségvetéssé válik.

Ugyanezek a kérdések a szállítónak is segítenek. Az a szállító, amelyik tudja, melyik határt kell stabilan tartania, kevesebb véletlen függőséget tervezhet. Egyértelművé teheti a verziókezelési szabályzatát. Közzéteheti a kivezetési utat. Tesztkörnyezetet adhat az ügyfeleknek, amely valódi felületként viselkedik, nem pedig marketingbemutatóként. Meg tudja különböztetni a rendszer valóban védett részét attól a résztől, amelyet meg kell osztani ahhoz, hogy az ügyfél megtartsa a döntési képességét. Ez nem jótékonyság. Ez világosabb szerződés mindkét fél számára.

Európa előnye itt nem az, hogy megszüntetheti a függőséget. A komoly rendszereknek vannak függőségeik. Az előny annak a lehetősége, hogy a függőség átláthatóvá, tárgyalhatóvá és az adott felhasználáshoz kellően visszafordíthatóvá váljon. Az a rendszer, amely azért maradhat egy szállítónál, mert továbbra is kiérdemli a kapcsolatot, erősebb, mint az, amelyik azért marad, mert senki sem tudja másutt rekonstruálni a nyilvántartásainak jelentését.

Az adatterek nem jobb világítású raktárak

A „adattér” kifejezés rossz képet kelthet. Egy nagy helyiséget sugall, ahová mindenki behozza az adatait, polcra helyezi, és elégedetten távozik az együttműködési képességgel. Az európai megközelítés ennél igényesebb. A közös európai adatterek célja, hogy az adatok megbízható és biztonságos környezetben álljanak rendelkezésre hozzáférésre és újrafelhasználásra. A Bizottság a közös infrastruktúrákat és irányítási kereteket írja le az adatok összesítését, hozzáférését és megosztását támogató eszközökként, a tisztességes, átlátható, arányos és megkülönböztetésmentes hozzáférési szabályok mellett.

Ez fontos pontosítás. Az adatmegosztás nem egyszeri átadási aktus. Folyamatos kapcsolat olyan felek között, akiknek eltérő céljaik, jogaik és kötelezettségeik vannak. Az egyik résztvevő felhasználhat egy adatkészletet kutatásra, de marketingre nem. Egy másiknak kötelessége lehet egy érték kijavítása. Egy harmadik kaphat származtatott eredményt, de a mögöttes rekordot nem. Egyes adatokat meg kell őrizni. Egyeseket törölni kell. Egyesek csak meghatározott környezetben dolgozhatók fel. Az irányadó feltételek az interoperabilitás részét képezik, nem pedig egy külön jogi mappa lábjegyzetét.

A Bizottság adatterekkel kapcsolatos munkája támogatást nyújt a referenciaarchitektúrában, az építőelemekben, a szemantikában, az interoperabilitási specifikációkban és az adatmodellekben, valamint tanácsadási szolgáltatásokat a Data Spaces Support Centre révén. Ez a szélesség ésszerű. A biztonságos összekötő közös szókincs nélkül nem old meg szemantikai problémát. A közös szókincs identitás, hozzáférés-vezérlés vagy irányítás nélkül nem old meg bizalmi problémát. Az a modell, amely deklarált cél, forrásrekord és javítási út nélkül tud lekérdezni egy adatteret, nem teszi használhatóbbá a teret. Új információfogyasztót hoz létre, akinek a kötelezettségei homályosak.

A mesterséges intelligencia esetében a következtetés egyértelmű. A modellt nem szabad kiváltságos rövidítésként kezelni az adattér határai körül. Ha egy személynek vagy szolgáltatásnak hozzáférési alapra, meghatározott célra, azonosítóra és használati nyilvántartásra van szüksége, az MI-munkafolyamatnak is ugyanezt a fegyelmet kell követnie. Lehetnek technikai különbségek abban, hogy egy ügynök hogyan kér adatot, vagy hogyan hajtódik végre egy lekérési lépés. Nem lehet mágikus kivétel, amelyben a rendszer azt mondja: „a modellnek kontextusra volt szüksége”, és a szokásos irányítási szabályok távoznak a színről.

Ez nem azt jelenti, hogy minden felszólítást bürokratikus ceremóniává kell alakítani. Azt jelenti, hogy a rendszernek különbséget kell tennie kérdés és felhatalmazás között. A modell képes lekérdezést megfogalmazni. Egy szabályzatot ismerő rétegnek kell eldöntenie, hogy a lekérdezés elérhet-e egy adott forrást, milyen célból, milyen minimalizálással, és hogyan kerül rögzítésre a kérés és az eredmény. A válasz ezután hivatkozhat forrásra vagy magyarázhat korlátozást. Ha a forrás megváltozik, a rendszernek tudnia kell, melyik későbbi válasz vagy döntés szorulhat felülvizsgálatra. Ellenkező esetben a származás dekoratív hivatkozássá válik egy csevegési átiratban.

A szemantikus szerződések itt különösen hasznosak, mert láthatóvá teszik a bizalom minimális egységét. A forrásazonosító nem csupán egy sztring. Verziót vagy stabil hivatkozást kell azonosítania. Az engedély nem csupán igaz vagy hamis. Lehet hatóköre, célja, jogosultja, időkorlátja és alapja. A javítás nem csupán frissítés. Felülírhat egy korábbi állítást, miközben megőrzi a történetet, amely megmagyarázza, mi történt. Az elutasítás nem csupán hiba. Lehet szándékos határ, amelyet érthetővé kell tenni a kérdező számára.

A kísértés az lesz, hogy ezt egy univerzális „MI-interoperabilitási réteggel” oldják meg, amely azt állítja, hogy minden ügynököt, modellt, adatbázist és munkafolyamat-eszközt felcserélhetővé tesz. Az ilyen állítás általában összekeveri a közös szállítást a közös jelentéssel. Az általános protokoll hasznos lehet. Nem tudja megmondani a címzettnek, mit jelent egy klinikai kód, egy tervezési állapot, egy ellátási döntés vagy egy kockázati jelzés az adott területen. Nem tudja eldönteni, ki írhat felül egy automatizált javaslatot. Nem tudja megmondani egy szervezetnek, meddig őrizheti meg a lekérdezett rekordot. A szabványok megállapodásokat hordoznak. Nem szüntetik meg a megkötésük iránti igényt.

Van egy megalapozottabb ambíció. Építsünk doménspecifikus megállapodásokat ott, ahol a közös munka indokolja őket. Használjuk újra az általános építőelemeket, ahol valóban illenek: identitás, jogosultságkezelés, származás, eseménykezelés, verziókezelés, megfelelőségvizsgálat és hozzáférhető dokumentáció. Tartsuk átláthatónak a kapcsolatot egy általános szabvány és egy helyi implementáció között. Így egy résztvevő úgy csatlakozhat, hogy nem kell feladnia a teljes rendszerét, és egy szektor úgy fejlődhet, hogy nem kell minden új beszállító érkezésekor üres lapról indulnia.

Ez a méret jobb változata. Nem azt méri sikernek, hogy mennyi adatot központosítottak, vagy hány szolgáltatást kényszerítettek egyetlen interfészbe. Azt méri sikernek, hogy egy legitim adatcsere létrejöhet-e kellő átláthatósággal ahhoz, hogy a résztvevők használni, javítani, irányítani és szükség esetén leállítani tudják.

Válasszon egy kártyát, és vizsgálja meg az adatcsere azon részét, amely egy rekordot az eredeti rendszerén túl is használhatóvá tesz.

A szabványok élete a publikálás után kezdődik

A szabványokról gyakran úgy beszélnek, mintha a munka a dokumentum megjelenésével véget érne. A gyakorlatban a publikálás az a pillanat, amikor a nehezebb munka elkezdődik. Valakinek ki kell választania az alkalmazandó profilt. Valakinek implementálnia kell. Valakinek tesztelnie kell a határeseteit. Valakinek el kell döntenie, hogy egy új verzió kompatibilis-e, mikor vonul ki a régi verzió, és mi történik a korábbi szabályok szerint létrehozott rekordokkal. Valakinek el kell magyaráznia az egész felállást egy csapatnak, amely nem volt a teremben, amikor a betűszót kiválasztották.

A CEN és a CENELEC EN 18235-1:2026 szabványa jó példa erre az irányra. A szabvány a szervezetek közötti adatmegosztásról és adatcseréről szól, hangsúlyt fektetve az interoperabilitásra és az elszámoltathatóságra, és a bejelentett alkalmazási területei közé tartoznak a közös európai adatterek. A részletek itt kevésbé fontosak, mint a jelzés. Az adatmegosztásba vetett bizalommal nem úgy bánnak, mint egy dashboard által generált érzéssel. Úgy bánnak vele, mint amit az adatcsere körüli megállapodások, a felelősség és az elszámoltathatóság képessége formál.

A legjobb szabványosítási munka teret hagy azoknak a dolgoknak, amelyeket nem tud eldönteni. Egy műszaki specifikáció meghatározhat egy üzenetstruktúrát. Nem nyilváníthat ki helyi jogalapot. Egy szókincs meghatározhat egy fogalmat. Nem garantálhatja, hogy egy helyi folyamat őszintén használja a fogalmat. Egy megfelelőségvizsgálati teszt megmutathatja, hogy egy implementáció teljesíti a megnevezett eseteket. Nem bizonyíthatja, hogy a szervezet kiképezte azokat, akik a kivételeket kezelik. Ennek az ellenkezőjét állítani kárt tesz a szabványokban. Úgy tűnnek ettől, mintha az ítélőképesség helyettesítői lennének, nem pedig egy eszköz, amely lehetővé teszi, hogy az ítélőképesség messzebbre jusson.

A megfelelőségvizsgálat különösen értékes, mert az interoperabilitást ígéretből megfigyelhető tulajdonsággá változtatja. Egy szállító mondhatja, hogy támogat egy profilt. Egy vevőnek meg kell tudnia kérdezni, hogy melyik verzió, melyik opcionális funkciók, melyik negatív esetek, melyik hibaválaszok és melyik publikált teszteredmények támasztják alá ezt az állítást. Egy implementálónak ugyanazokat az eseteket kell tudnia futtatni, mielőtt egy integráció éles környezetbe kerül. Egy változásnak be kell jelentenie, hogy visszafelé kompatibilis-e, és mely fogyasztóknak kell lépniük.

Az AI-felületek esetében ez aprólékosnak tűnhet egészen az első inkompatibilis változásig. Az egyik eszközhívás centben várja a pénzösszeget. Egy másik tizedestörtet ad vissza pénznem megjelölése nélkül. Az egyik ágens a hiányzó mezőt további információ iránti kérelemként kezeli. Egy másik felhatalmazásként értelmezi arra, hogy értéket következtessen. Az egyik modellfrissítés megváltoztatja a hivatkozások szerkezetét. Egy downstream folyamat továbbra is a régi formátumot dolgozza fel. Egyik sem filozófiai rejtély. Ezek mind hétköznapi interfészhibák, amelyeket súlyosabbá tesz egy olyan rendszer, amely gyorsan képes cselekedni.

Egy jó szerződés ezért az elutasítást éppúgy tartalmazza, mint a sikert. Meghatározza, mit utasít el a rendszer, mit ad vissza, ha egy forrás nem ellenőrizhető, mit tesz, ha hiányzik egy szabályzat, hogyan tudja a fogadó megkülönböztetni a részleges adatot a teljestől, és hol kezdődik az emberi felülvizsgálat. A csend szörnyű interoperabilitási stratégia. Az egyértelmű elutasítás gyakran a legkompatibilisebb válasz, mert őszinte állapotot ad a következő rendszernek, amellyel dolgozhat.

A verziókezelés ugyanilyen tiszteletet érdemel. Egy hasznos interfész nem csupán verziószámot fűz egy URL-hez, és bízik a legjobbakban. Bejelenti a változást, megadja a migrációs utat, ahol lehetséges, az ígért ideig fenntartja a régi szerződést, rögzíti, hogyan értelmezik a tárolt adatokat a verziók között, és elegendő időt ad a függő rendszereknek az alkalmazkodásra. Ez nem izgalmas munka. Így válik egy határ megszűnik meglepetés lenni. Hollandiában kedvelik azt a mondást, hogy valami „elég világos”, amíg valakinek meg nem kell építenie. A verziós szabályzat az, ami megmarad, miután ez a kifejezés találkozott egy éles rendszerrel.

Van itt egy európai gazdasági szempont. A kisebb szervezetek akkor tudnak részt venni, ha a kapcsolódás szabályai nyilvánosak, dokumentáltak és tesztelhetők. Nincs szükségük privát kapcsolatra minden domináns platformmal ahhoz, hogy megtudják, hogyan viselkedik egy csere. A nagyobb szervezetek is profitálnak, mert csökkenthetik az egyedi integrációs adósságot, és tesztelhetik a szállító állításait, mielőtt magfüggőség alakulna ki. Az eredmény nem súrlódásmentes. Ez igazságosabb súrlódás: a munka látható, árazott és megosztott, nem pedig utólag felfedezett, miután a szerződés leszűkítette a lehetőségeket.

A gyakorlati kérdés az, hogy mi éli túl az átadást

A legtöbb interoperabilitási program jobbá válik, ha egy kis cserével kezdődik, nem pedig nagy ambícióval. Válasszon egy döntési vagy szolgáltatási határt. Írja le azokat az információkat, amelyeknek át kell kelniük rajta. Nevezze meg a tekintély forrását, a fogadót, az engedélyezett célt, a szókincset, az életciklus-eseményeket, a biztonsági feltételeket és azokat a bizonyítékokat, amelyek megmutatják, hogy a csere a tervezett módon történt. Ezután tesztelje mind a sikert, mind a kudarcot.

Az így kialakuló beszélgetés gyakran tanulságosabb, mint egy funkció-összehasonlítás. Mi történik, ha a forrás javít egy rekordot? Fel tudja-e ismerni a fogadó, hogy melyik másolat érintett? Mi történik, ha egy AI-rendszer nem tud egy ajánlást megengedett forrással alátámasztani? Explicit elutasítást, részleges eredményt vagy kitalált magabiztosságot ad vissza? Mi történik, ha a fogadó olyan sémaverziót kap, amelyet nem ért? Biztonságosan el tudja-e utasítani a cserét? Mi történik, ha egy személy vitat egy besorolást? A javítás új esemény lesz nyomvonallal, vagy a régi eredményt felülírják, amíg senki nem tudja rekonstruálni az eredeti művelet alapját?

Ezek tervezési kérdések, nem csupán megfelelőségi kérdések. Meghatározzák, hogy az emberek tudnak-e szolgáltatást üzemeltetni, hogy egy szállító tudja-e támogatni, és hogy egy másik rendszer csatlakozhat-e anélkül, hogy dokumentálatlan kockázatot örökölne. Az AI minőségét is alakítják. Egy egyértelmű információs határral rendelkező modellnek kevesebb tere van arra, hogy a kétértelmű kontextust láthatatlan feltételezésekké alakítsa. A tipizált kimenetekkel és forrásazonossággal rendelkező munkafolyamat konkrét vizsgálati anyagot ad az értékelőknek. A verziózott döntési nyilvántartás lehetővé teszi az értékelést, miután a modell, a prompt vagy a szabályzat megváltozott.

Vannak ésszerű korlátok. Bizonyos adatoknak nem szabad utazniuk. Bizonyos információkat minimalizálni vagy összesíteni kell. Egyes szolgáltatásoknak egyedi határvonalra van szükségük, mert a munka szokatlan, érzékeny vagy kockázatos. Egyes helyi szókincsnek helyben kell maradnia, mert a kényszerű hamis egyenértékűség elpusztítaná a jelentést. Az interoperabilitás nem azt követeli meg, hogy minden rendszer mindent kitárjon. Azt követeli meg, hogy a választott határvonal őszinte legyen arról, hogy mit tár ki, miért, kinek és milyen következményekkel.

Ez az őszinteség különösen fontos, amikor az AI-szállítók gyors kapcsolódást kínálnak. Egy csatlakozó, amely csendben átmásol egy nagy korpuszt egy modell kontextusába, megoldhat egy demonstrációs problémát, miközben irányítási problémát teremt. Egy eszköz, amely tartós munkaazonosító nélkül ír egy üzleti rendszerbe, létrehozhat egy automatizálást, miközben tönkreteszi az auditálhatóságát. Egy univerzális ügynökprotokoll megkönnyítheti a felfedezést, miközben az engedélyezést, a célhoz kötöttséget és a szemantikai felelősséget megválaszolatlanul hagyja. A kérdésnek mindig az kell lennie, hogy mi éli túl az átadást: az adat, a jelentés, az engedély, a bizonyíték és a korrekció képessége.

Egy hasznos program mindegyiknek otthont ad. Az adatnak formátumra és integritásellenőrzésre van szüksége. A jelentésnek modellre, szókincsre vagy explicit leképezésre van szüksége. Az engedélynek identitásra, célra és szabályzati határvonalra van szüksége. A bizonyítéknak a forrás, a verzió, az átalakítás és a döntés nyilvántartására van szüksége. A korrekciónak eseményútra és felelős gazdára van szüksége. A működésnek runbookra, megfigyelhetőségre és a változtatás leállításának vagy visszagörgetésének módjára van szüksége. Egyikből sem lesz hősies indulófilm. De lehetővé teszi, hogy egy rendszer hasznos maradjon, miután az indulófilmet egy támogatási jegy váltotta fel.

A Dweve-nél szűken alkalmazzuk az elvet a Fabric nyilvános leírásában. A webhely egy munka-központú objektummodellt ír le, amelyben modellek, ügynökök, eszközök, emberek és munkafolyamatok gépelt szerződéseken keresztül vesznek részt, és olyan felhasználói felületeket és API-kat ír le, amelyek ugyanazon a tartományon működnek. Ez terméktervezési álláspont, nem pedig bizonyíték arra, hogy bármely telepítés automatikusan interoperábilis, vagy hogy egy gépelt felület jogi, szemantikai vagy működési kérdéseket rendez. Ez egyszerűen az a fajta határvonal, amelyre szerintünk a komoly AI-rendszereknek szükségük van: olyan, amelyben a tartós munka nem tűnik el egy szolgáltató-specifikus beszélgetésben.

A HEDL kisebb, nyilvános példát kínál. Dokumentációja egy Apache 2.0 licencű szövegformátumot, közzétett formátumspecifikációt és megfelelőségi dokumentumokat ír le, JSON, YAML, XML, CSV, Parquet és TOON formátumok közötti konverziókkal. Ezek a funkciók nem teszik kompatibilissé az összes adatkészletet, és nem változtatják a formátumkonverziót szemantikai egyetértéssé. De hasznos állítást tesznek egy határvonalról: egy csereformátumnak ellenőrizhetőnek, tesztelhetőnek kell lennie, és képesnek kell lennie a meglévő rendszerek mellett működni, nem pedig azt követelni, hogy minden rendszer saját magándialektussá váljon.

Európának nem kell megnyernie egy AI-versenyt azzal, hogy elrohan a saját intézményeitől. Lehetősége az, hogy ezeket az intézményeket, piacokat és technikai közösségeket könnyebben összekapcsolhatóvá tegye anélkül, hogy úgy tenne, mintha a különbségeik nem számítanának. A munka távolról unalmasnak tűnik. Verziótörténet, teszteszközök, szókincsválasztások, hozzáférési szabályok, migrációs gyakorlatok és az alkalmankénti kényelmetlen megbeszélés arról, hogy ki módosíthat egy mezőt. Közelről ez az a munka, amely lehetővé teszi, hogy egy rendszerben megbízzon valaki más is, mint aki építette.

Ez egy megtartásra érdemes előny. Egy modell lecserélhető. Egy szállító lecserélhető. Egy szolgáltatás átlépheti a határt. Egy korrekció eljuthat oda, ahol számít. Egy ember megkérdezheti, mi történt, és jobbat kaphat egy magabiztos bekezdésnél. A technológia ambiciózus marad. A határvonal hétköznapi marad. A hétköznapi rész adja meg az ambíciónak a megbízható talajt.

Források