Euroopan seuraava tekoälyetu voi olla tylsä yhteentoimivuus

Eurooppa ei tee tekoälystä hyödyllisempää tekemällä kaikista järjestelmistä samanlaisia. Se voi tehdä siitä hallittavampaa vaatimalla, että järjestelmät...

Euroopan seuraava tekoälyetu voi olla tylsä yhteentoimivuus

Arkinen asia, joka tekee järjestelmästä käyttökelpoisen

Yhteentoimivuudella on brändiongelma. Se kuulostaa ohjelman osalta, joka jätetään niille, jotka nauttivat referenssiarkkitehtuureista, versiotaulukoista ja skeeman tarkasta välimerkityksestä. Tämä maine ei ole täysin ansaitsematon. Hyvä rajapintasopimus ei koskaan päihitä uutta mallia tuotelanseerauksessa. Kukaan ei tuo kakkua, koska kaksi palvelua vihdoin pääsevät yksimielisyyteen siitä, mitä poistettu tietue tarkoittaa.

Silti juuri tästä yksimielisyydestä suuri osa hyödyllisestä työstä alkaa. Malli voi olla vaikuttava yksinään ja silti vain rajallisesti hyödyllinen organisaatiolle, joka ei voi yhdistää sitä tietueisiin, sääntöihin, ihmisiin ja päätöksiin, jotka antavat työlle tarkoituksen. Malli voi tuottaa sujuvan vastauksen. Mutta jos vastaus ei voi kantaa lähdetunnistetta, jos korjaus ei voi tavoittaa järjestelmiä, jotka toimivat sen perusteella, jos ihminen ei voi kertoa, mitä politiikkaversiota sovellettiin, järjestelmä ei ole tullut osaksi työtä. Siitä on tullut toinen paikka, josta kopioida ja liittää.

Euroopan seuraava tekoälyetu voi siis olla melko epäglamouria. Se voi olla kyky saada järjestelmät kohtaamaan rajapinnoilla, jotka ovat eksplisiittisiä, tarkastettavia ja reiluja jättää. Ei mannertason super-sovellus. Ei vaatimus siitä, että jokainen sairaala, kunnantalo, laboratorio ja valmistaja käyttää yhtä tietokantaa. Hyödyllinen kunnianhimo on kapeampi ja vaikeampi: palvelun tulisi pystyä vaihtamaan tietoa, säilyttämään tiedon merkitys, kunnioittamaan sen ympärillä olevia ehtoja ja pysymään toimintakelpoisena, kun toinen komponentti muuttuu.

Tämä on strateginen kyvykkyys. Se muuttaa työkalujen kokoelman infrastruktuuriksi. Se antaa yhden jäsenvaltion hallinnolle mahdollisuuden tunnistaa toisessa jäsenvaltiossa tuotetun tietueen teeskentelemättä, että niiden lait, kielet tai menettelyt ovat identtisiä. Se antaa yritykselle mahdollisuuden vaihtaa tietojenkäsittelypalvelua menettämättä digitaalisia resursseja, jotka tekevät palvelusta toimivan. Se antaa ostajalle tavan kysyä, voiko tekoälyjärjestelmä liittyä olemassa olevaan prosessiin hiljaa omistamatta sitä. Se antaa pienemmälle toimittajalle mahdollisuuden kilpailla dokumentoidulla rajapinnalla pikemminkin kuin asiakkaan sietokyvyllä muutoksen tuskaa kohtaan.

Asia on helppo ymmärtää väärin. Yhteentoimivuus ei ole automaattinen hyve. Huonosti suunniteltu rajapinta voi levittää huonon oletuksen nopeasti. Jaettu tietomalli voi olla liian laaja, liian tunkeileva tai liian epämääräinen. Standardista voi tulla museoesine. Avoin API voi silti olla kallis, turvaton tai niin huonosti dokumentoitu, että se toimii lähinnä todisteena siitä, että API-osasto on joskus ollut olemassa. Eurooppa ei tarvitse koristeellista kasaa spesifikaatioita. Se tarvitsee sopimuksia, jotka toimivat tavallisissa olosuhteissa, mukaan lukien korjaus, peruutus, päivitys, keskeytys ja poistuminen.

Interoperable Europe -asetus antaa hyödyllisen määritelmän julkisille palveluille. Se käsittelee rajat ylittävää yhteentoimivuutta unionin toimielinten ja jäsenvaltioiden julkisen sektorin elinten kykynä olla vuorovaikutuksessa jakamalla dataa, tietoa ja tietämystä digitaalisten prosessien kautta, jotka täyttävät oikeudelliset, organisatoriset, semanttiset ja tekniset vaatimukset. Neljällä sanalla on merkitystä. Tekninen yhteensopivuus on vain yksi kerros. Kaksi palvelua voi vaihtaa tavuja ja silti olla eri mieltä auktoriteetista, tarkoituksesta, säilytyksestä tai tilan merkityksestä. Ne voivat jakaa kentän nimeltä approved, kun toinen tarkoittaa alustavaa tarkistusta ja toinen lopullista oikeudellista päätöstä. Kenttä kulkee. Päätös ei.

Tässä aiheesta tulee mielenkiintoisempi kuin putkityöt. Yhteentoimivuus kysyy, minkä on pysyttävä totena, kun jokin ylittää rajan. Mikä organisaatio on vastuussa? Mikä on tiedon yksikkö? Kuka voi muuttaa sitä? Mitä tapahtuu, kun lähde korjataan? Mitä puuttuva arvo tarkoittaa? Mikä identiteetti on vahvistettu? Kuinka kauan vastaanottaja saa säilyttää sitä? Voiko toinen järjestelmä todistaa, minkä version se sai? Nämä ovat julkisia kysymyksiä, kaupallisia kysymyksiä ja insinöörikysymyksiä samassa takissa.

AI tekee takista tungoksisemman. Järjestelmä voi asettua rekisterien ja ihmisten väliin, hakea aineistoa useista lähteistä, soveltaa malliversiota, kutsua työkalua, suositella toimenpidettä ja jättää päätöksestä kirjauksen. Jos millään näistä siirtymistä ei ole määriteltyä sopimusta, kyvykäs malli voi tehdä organisaatiosta vähemmän läpinäkyvän eikä kyvykkäämmän. Vastaus voi olla vakuuttava mutta jäljittämätön. Työnkulku voi näyttää nopeammalta mutta tulla riippuvaiseksi yhden toimittajan yksityisestä viestimuodosta, yksityisestä agentin tilasta ja yksityisestä tehtävän määritelmästä. Se ei ole älykkyyttä. Se on omistajuuden muutos, joka on piilotettu kätevyysominaisuuteen.

Tylsän yhteentoimivuuden puolesta puhuva perustelu ei väitä, että se tekisi teknologiasta tylsää. Se väittää, että se tekee teknologiasta vastuullista. Eurooppa on poikkeuksellisen hyvässä asemassa arvostamaan tätä eroa. Sen julkiset palvelut ylittävät rajoja. Sen kielet ja hallinnolliset perinteet vastustavat fantasiaa, jonka mukaan yksi sanasto voidaan vain määrätä. Sen datasäännöt kohtelevat yhä useammin pääsyä, siirrettävyyttä ja hallintaa toimivan markkinan edellytyksinä. Ja sen organisaatiot yrittävät usein lisätä tekoälyn työhön, johon liittyy jo velvollisuuksia, rekistereitä ja seurauksia. Rajalla on merkitystä, koska ihmisiä seisoo jo sen molemmin puolin.

Yhteensopivuus ei ole vielä ymmärrystä

On useita tapoja, joilla kaksi järjestelmää voi näyttää yhteensopivilta. Ne voivat käyttää samaa verkkoprotokollaa. Ne voivat hyväksyä saman tiedostotyypin. Ne voivat todentaa käyttäjän samalla identiteettijärjestelmällä. Ne voivat jopa läpäistä saman vaatimustenmukaisuustestin. Jokainen näistä on hyödyllinen. Mikään ei ratkaise suurempaa kysymystä: voiko vastaanottava järjestelmä käyttää tietoa oikein ilmoitettuun tarkoitukseen?

Otetaan vaatimaton, hypoteettinen esimerkki. Alueviranomainen lähettää naapuriviranomaiselle ilmoituksen hyvin dokumentoidun rajapinnan kautta. Hyötykuorma vahvistetaan. Allekirjoitus varmistetaan. Jokainen vaadittu kenttä on läsnä. Yksi kenttä sisältää päivämäärän. Lähettävä järjestelmä tarkoittaa päivää, jolloin taustalla oleva tapahtuma sattui. Vastaanottava järjestelmä tulkitsee sen päiväksi, jona ilmoitus tuli oikeudellisesti voimaan. Yhtään pakettia ei kadonnut. Yksikään palvelin ei kaatunut. Järjestelmät olivat teknisesti yhteensopivia mutta semanttisesti epälinjassa. Tuloksena voi olla väärä määräaika, tarpeeton valitus tai henkilö, jota pyydetään tekemään uudelleen työtä, jonka kone on jo tehnyt.

Esimerkki on tarkoituksella hypoteettinen. Se ei tarvitse kuvitteellista kunnantaloa tai tiistaiamua osoittaakseen pointin. Monet vaikeat digitaaliset epäonnistumiset eivät ole dramaattisia. Ne saapuvat näennäisen täydellisenä rekisterinä, johon liittyy yksi lausumaton oletus. Aikaleimassa ei ole aikavyöhykettä. Arvo on tyhjä, mutta kukaan ei sano, tarkoittaako tyhjä tuntematonta, pois jätettyä, ei sovellettavaa vai vielä tarkistamatonta. Tunniste on vakaa yhdessä järjestelmässä ja kierrätetty toisessa. Suostumuslippu kulkee ilman tarkoitusta, laajuutta ja voimassaoloa, jotka tekivät siitä merkityksellisen. Integraatio toimii, kunnes joku luottaa siihen.

Semanttinen yhteentoimivuus on kurinalaisuutta, jolla nämä merkitykset tehdään riittävän yksiselitteisiksi jaettaviksi. Se ei edellytä yleismaailmallista sanakirjaa kaikille inhimillisille asioille. Se edellyttää, että määritellyn vaihdon osapuolet sopivat, mihin heidän terminsä viittaavat, mitkä rajoitteet pätevät, mitkä arvot ovat sallittuja ja miten muutokset viestitään. Standardointityön kielellä se koskee tietomalleja, sanastoja, tunnisteita, suhteita ja sääntöjä, joiden avulla vastaanottaja voi tulkita niitä. Operaattorin kielellä se on ero sen välillä, että vastaanottaa rekisterin ja että vastaanottaa jotakin, jonka pohjalta voi turvallisesti toimia.

ETSI:n dataa käsittelevä tekninen komitea kuvaa työtään datan hallinnan, semanttisen yhteentoimivuuden, ontologioiden ja sääntelyn yhdenmukaistamisen kautta, tavoitteenaan tehdä datasta jaettavaa ja uudelleenkäytettävää toimialojen ja rajojen yli. Tuo kehys on virkistävän vaatimaton. Se kieltäytyy ajatuksesta, että datalla olisi arvoa pelkästään siksi, että se on sijoitettu järveen, tilaan tai taulukkolaskentaan, jossa on kunnioitettava määrä välilehtiä. Datasta tulee uudelleenkäytettävää, kun sen ympärillä olevat ehdot ovat riittävän selkeitä, jotta toinen osapuoli voi tehdä siitä rajattua, hyväksyttävää käyttöä.

Euroopan datasäädös esittää saman asian toisesta suunnasta. Sen yhteentoimivuutta koskevat säännökset liittyvät datatiloihin ja datankäsittelypalveluihin. Komission selvityksen mukaan standardit ja yhteentoimivuus ovat keskeisiä, jotta dataa voidaan käyttää eri lähteistä yhteisten eurooppalaisten datatilojen sisällä ja niiden välillä sekä helpottaa siirtymistä datankäsittelypalvelujen välillä. Kyse ei ole lupauksesta, että kaikki järjestelmät yhtäkkiä ymmärtäisivät toisiaan. Kyse on poliittisesta tunnustuksesta, että eristyneiden palvelujen markkinoilla asiakkailla on vähemmän käytännön valinnanvaraa.

On houkuttelevaa kuulla sana "semanttinen" ja tarttua suureen ontologiaan, kaavioon, joka on niin laaja, että se vaatisi oman postiosoitteensa. Joskus toimiala tarvitsee laajaa jaettua mallinnusta. Mutta parempi lähtökohta on pienempi. Mikä on tämän vaihdon kohde? Mikä versio lähetetään? Mikä organisaatio omistaa virallisen arvon? Mikä tapahtuma voi muuttaa sitä? Mitä vastaanottajan on tehtävä, kun tämä tapahtuma sattuu? Mikä käyttö on sallittua? Miten ihminen voi tarkastaa vastauksen, kun automatisoitu polku on epävarma? Kapea, vastattavissa oleva sopimus on arvokkaampi kuin kattava kaavio, jota kukaan ei voi toteuttaa.

Sama pidättyväisyys koskee tekoälyä. Tekoälytyönkulku saattaa joutua siirtämään työkohteen mallille, vastaanottamaan ehdotetun luokittelun, liittämään lähteet, hakemaan hyväksynnän ja kirjaamaan päätöksen asianhallintajärjestelmään. Sen ei pitäisi teeskennellä, että luonnollisen kielen selitys on riittävä rajapinta. Työnkulku tarvitsee tyypitettyjä faktoja sanojen lisäksi: työkohteen tunnisteen, lähdeversiot, ilmoitetun tehtävän, sallitut työkalut, luottamus- tai kieltäytymisehdon tarvittaessa, arvioijan päätöksen, ajan ja käytännön version. Malli voi pysyä todennäköisyyksiin perustuvana. Mallin ympärillä oleva raja ei saisi olla epämääräinen tottumuksesta.

Tästä syystä yhteentoimivuus ei ole sama asia kuin integraatio. Integraatio voi olla yksityinen yhteys, joka on rakennettu yhtä suhdetta varten. Se voi olla täysin asianmukainen. Mutta kun sen semantiikka elää vain toimittajan toteutuksessa, työntekijän muistissa tai työpajan kalvosarjassa, yhteys ei kestä siirtoa. Yhteentoimiva raja jättää jälkeensä sopimuksen, jonka toinen pätevä osapuoli voi lukea, testata ja haastaa. Sen luominen on hitaampaa kuin pikaliittimen. Se on nopeampi korjata, kun alkuperäisestä liittimestä on tullut riippuvuus, jolla on logo.

Euroopan kehys alkaa koko ongelmasta

Interoperable Europe -säädös ei ole tekoälylaki, ja olisi virhe esittää se sellaisena. Se on asetus rajat ylittävästä julkisen sektorin yhteentoimivuudesta. Sen arvo tekoälylle on perustavanlaatuisempi. Se kuvaa tavan ajatella digitaalisia julkisia palveluja ennen kuin tietty teknologia asetetaan niiden keskelle.

Asetuksen mukaan unionin toimielinten ja soveltamisalaan kuuluvien julkisen sektorin elinten on tehtävä yhteentoimivuusarviointi ennen kuin ne päättävät uusista tai olennaisesti muutetuista sitovista vaatimuksista. Arvioinnissa tunnistetaan ja arvioidaan vaikutukset rajat ylittävään yhteentoimivuuteen, asiaankuuluviin sidosryhmiin ja Interoperable Europe -ratkaisuihin, jotka voivat tukea täytäntöönpanoa. Tuloksena oleva kertomus on julkaistava koneellisesti luettavassa muodossa, joka helpottaa automaattista kääntämistä, ottaen huomioon asetuksen suojaukset henkistä omaisuutta, liikesalaisuuksia, yleistä järjestystä ja turvallisuutta koskien.

Se on vaativampaa kuin kysyä, onko ehdotetulla järjestelmällä rajapinta. Rajapinta voi olla teknisesti siisti ja silti muodostaa esteen naapurihallinnolle, kansalaiselle, pienyritykselle tai toiselle julkisyhteisölle. Arviointi kysyy toista kysymystä: mitä muutoksia vuorovaikutuskykyyn tulee, kun tämä vaatimus otetaan käyttöön? Se luo tilaa sille, että oikeudellinen toimivalta, organisatorinen vastuu, semanttinen merkitys ja tekninen suunnittelu voivat esiintyä samassa keskustelussa. Ne ovat aina olleet osa samaa keskustelua. Ohjelmistolle oli vain annettu lupa pitää kokous eri huoneissa.

Asetus myös tekee jakamisesta konkreettista. 4 artikla edellyttää, että unionin toimielin tai julkisen sektorin elin asettaa toisen tällaisen toimielimen tai elimen pyynnöstä saataville yhteentoimivuusratkaisun, joka tukee eurooppalaista digitaalista julkista palvelua, mukaan lukien tekniset asiakirjat ja soveltuvin osin versiohistorian, dokumentoidun lähdekoodin ja viittaukset avoimiin standardeihin tai teknisiin eritelmiin. Poikkeuksiakin on, kuten kolmansien osapuolten immateriaalioikeudet ja julkiseen tehtävään kuulumattomat toimet. Periaate ei ole se, että jokainen julkisen sektorin ohjelmistorivi on julkaistava harkitsematta. Periaate on, että uudelleenkäytettävästä ratkaisusta ei pitäisi tulla yksityistä löytöä joka kerta, kun toinen hallinto tarvitsee sitä.

Tuossa sanamuodossa on hiljainen muutos. Asiakirjat ja versiohistoria eivät ole toissijaista paperityötä sen jälkeen, kun hyödyllinen osa on tehty. Ne ovat osa sitä, mikä tekee osasta uudelleenkäytettävän. Lähdekoodivarasto ilman kontekstia voi olla yhtä hyödytön kuin matkalaukku ilman avainta. Viitearkkitehtuuri ilman oletusten selitystä voi muuttua hyvin viimeistellyksi tavaksi viedä hämmennystä eteenpäin. Uudelleenkäytettävä asia on koodi, eritelmä, tunnetut rajat, versio, näyttö siitä, miten sitä oli tarkoitus käyttää, ja olosuhteet, joissa sitä ei pitäisi käyttää.

Eurooppalainen yhteentoimivuuskehys, jonka asetus asettaa arviointimallinsa keskiöön, käsittelee samalla tavoin oikeudellista, organisatorista, semanttista ja teknistä yhteentoimivuutta sekä hallintoa. Tämä neljän tason näkemys on hyödyllinen, koska se estää yhdenlaista menestystä esiintymästä koko tuloksena. Tekninen tiimi voi onnistuneesti toteuttaa rajapinnan. Lakitiimi voi havaita, ettei vaihdolle ole estettä. Operatiivinen tiimi voi sopia eskalaatiosta. Toimialueen tiimi voi yhdenmukaistaa kohteiden merkityksen. Järjestelmästä tulee luotettava rajapinnalla vasta, kun olennaiset tasot ovat linjassa kyseistä käyttöä varten.

Siksi myös "eurooppalainen standardi" ei ole loitsu. Standardit voivat vähentää tarpeetonta vaihtelua ja tehdä sopimuksesta useampien toimijoiden saatavilla. Ne eivät voi päättää, onko tietty vaihto oikeasuhteinen, lainmukainen, turvallinen tai hyödyllinen. Tekninen profiili on valittava, toteutettava, hallinnoitava ja arvioitava. Se tarvitsee versiopolitiikan. Se tarvitsee virheiden käsittelyn. Se tarvitsee tavan esittää epävarmuus. Se tarvitsee prosessin päättää, milloin paikallinen laajennus on perusteltu ja milloin siitä on tullut yksityinen haara julkisessa takissa.

Julkisen sektorin tapaus on erityisen paljastava, koska semanttisen ajautumisen kustannuksen kantaa usein joku teknologiatiimin ulkopuolella. Asukasta voidaan pyytää toimittamaan tietoja kahdesti. Yritys voi joutua kääntämään lomakkeen hallinnollisesta sanastosta toiseen. Ammattilainen voi menettää aikaa tietojen yhteensovittamiseen. Rajat ylittävä palvelu voi toimia vain sellaisille ihmisille, joiden tapaus sattuu sopimaan helpoimpaan polkuun. Asetus ei takaa, että nämä lopputulokset katoavat. Se luo mekanismeja, joilla niiden yhteentoimivuusvaikutukset tulevat näkyviksi ennen kuin vaatimus kovettuu infrastruktuuriksi.

AI:n tulisi periä tämä kurinalaisuus. Ennen kuin malli lisätään valtioiden rajat ylittävään tai muuten merkittävään palveluun, omistajan tulisi pystyä kertomaan, mitä objekteja malli voi lukea, mitä objekteja se voi luoda, mitkä päätökset pysyvät ihmisillä, miten korjaus leviää, mikä tuotos on apuväline eikä virallinen asiakirja, miten palvelu toimii, kun malli ei ole käytettävissä, ja miten vastaanottaja voi riitauttaa tai tarkastaa tuloksen. Tämä ei ole ylimääräinen vaatimustenmukaisuuskerros valmiin tuotteen päälle. Se on järjestelmän rajapintamääritelmä, jonka odotetaan saavan luottamuksen ihmisiltä, jotka eivät jaa mallin yksityistä kontekstia.

Siirrä osoitin kerroksen päälle ja valitse se. Raja pitää vain, kun olennaiset kerrokset ovat yksimielisiä siitä, mitä pitää tapahtua.

Siirrettävyys on testi sille, onko raja todellinen

Yhteentoimivuudesta tulee strategista, kun suhde muuttuu. Palvelu päivitetään. Toimittaja vaihdetaan. Julkinen toimija haluaa käyttää komponenttia uudelleen. Datatilan osallistuja muuttaa käytäntöään. Mallipalvelun tarjoaja muuttaa viestiformaattiaan. Uusi tietoturvaehto tarkoittaa, että työkuorma on ajettava muualla. Silloin rajan laatu tulee näkyväksi.

Data-asetus käsittelee tätä muuna kuin pelkkänä asiakkaan haittana. Sen säännöt palveluntarjoajan vaihtamisesta ja datankäsittelypalvelujen yhteentoimivuudesta pyrkivät vähentämään esteitä palvelujen välillä siirtymiselle, useiden palvelujen rinnakkaiselle käytölle sekä datan ja sovellusten siirrettävyydelle. Komission vuoden 2026 tutkimus datankäsittelypalvelujen yhteentoimivuudesta kuvaa 35 artiklan edellyttävän avoimia, yhdenmukaistettuja eritelmiä, jotka mahdollistavat samantyyppisten palvelujen yhteistoiminnan ja datan sekä sovellusten siirrettävyyden tietoturvaa vaarantamatta. Tutkimuksessa todetaan myös aiottu unionin tietovarasto asiaankuuluville standardeille ja avoimille eritelmille sekä mahdollisuus yhteisiin eritelmiin, jos yhdenmukaistetut standardit eivät riitä.

Kannattaa olla tarkka siitä, mitä tämä tarkoittaa ja mitä ei. Data-asetus ei lupaa, että asiakas voi nostaa monimutkaisen palvelun yhdeltä palveluntarjoajalta ja sijoittaa sen muuttumattomana toiselle perjantai-iltapäivänä. Se ei edellytä, että palveluntarjoajat paljastavat liikesalaisuuksia, vaarantavat tietoturvan tai tekevät kaikista palvelutyypeistä samanlaisia. Toiminnallinen vastaavuus, jota asetus edellyttää samantyyppisille palveluille, ei ole väite samanlaisista konsoleista, samanlaisista hinnoittelumalleista tai samanlaisista teknisistä ratkaisuista. Se on hyödyllisempi ja vaatimattomampi ajatus: jaettujen ominaisuuksien tulisi antaa asiakkaan työkuorman jatkaa aiottua toimintaansa olennaisen rajan yli.

Tämä erottelu on tärkeä, koska siirrettävä tiedosto ei välttämättä ole siirrettävä palvelu. Data-exportti voi jättää pois suhteet, tapahtumajärjestyksen, konfiguraation, käyttöoikeushistorian, tunnisteet, säilytystilan, käytäntöversiot ja toiminnallisen tiedon, jota järjestelmän palauttaminen edellyttää. Mallin tuotos voidaan viedä, kun hakukonfiguraatio, promptiversio, arviointikriteerit ja työkaluoikeudet, jotka muovasivat sitä, pysyvät yksityisinä. Tiedosto on siirtynyt. Olosuhteet, joissa siihen voitiin luottaa, eivät ole siirtyneet.

Oikea testi ei ole ”voimmeko ladata jotakin?”. Se on ”voiko pätevä kohde tulkita ja käyttää sitä palvelun osaa, jolla on merkitystä?”. Nämä ovat eri kysymyksiä. Ensimmäiseen voi vastata painike. Toinen edellyttää inventaariota, skeemaa, vastaanottopolun, testin, ihmisiä, jotka ymmärtävät rajan, ja rehellistä selvitystä siitä, mikä ei voi siirtyä.

Pohdi toista nimenomaan hypoteettista esimerkkiä. Tiimi käyttää tekoälypalvelua ensimmäisen luonnoksen valmisteluun sisäistä tarkastelua varten. Palvelussa on vientitoiminto. Suunnitellun siirron aikana tiimi saa tuotetun tekstin ja luettelon käyttäjätileistä. Se ei saa tietolähteiden versioita, päätöstietoja siitä, mitkä lähteet sallittiin, luonnosten hyväksyntätilaa, mallikonfiguraatiota eikä sääntöjä, jotka estivät palvelua lähettämästä luonnosta ulkoiselle vastaanottajalle. Tiimillä on teksti. Se ei ole saanut työnkulkuaan takaisin. Jos vanha palvelu olisi dokumenttieditori, se saattaisi olla siedettävää. Jos luonnokset muokkaavat säänneltyä tai turvallisuuteen liittyvää työtä, kyseessä on eri luokan ongelma.

Siirrettävyydellä on siis vähintään neljä kerrosta. On tekninen siirrettävyys: voidaanko tiedot ja rajapinnat siirtää käyttökelpoisessa muodossa? On semanttinen siirrettävyys: voiko vastaanottaja ymmärtää tietueet, tapahtumat ja rajoitteet? On operatiivinen siirrettävyys: voivatko ihmiset ajaa, suojata, tarkkailla, korjata ja palauttaa työmäärän? Ja on institutionaalinen siirrettävyys: voiko organisaatio täyttää julkiset, sopimukselliset ja oikeudelliset velvoitteensa siirron aikana? Mikään yksittäinen vientimuoto ei ratkaise kaikkia neljää.

Tässä hankinta voi muuttua rakentavaksi voimaksi. Tarjouspyynnössä voidaan kysyä vietävissä olevien tietojen ja digitaalisten resurssien luokkia, skeemoja ja versioita, nopeusrajoituksia, eheystarkistuksia, identiteetti- ja pääsynhallinnan vaikutuksia, tunnettuja rajoitteita, säilytys- ja poistokäyttäytymistä sekä siirtymän aikana saatavilla olevaa tukea. Siinä voidaan kysyä, voidaanko edustava vienti vastaanottaa ja validoida kohdejärjestelmässä ilman yksityistä pääsyä toimittajan konsoliin. Siinä voidaan kysyä, mitkä osat ovat toimittajakohtaisia suunnitteluperiaatteella. Rehellinen rajoite on hallittavissa. Piilotettu rajoite muuttuu hätäbudjetiksi.

Samat kysymykset auttavat toimittajaa. Toimittaja, joka tietää, minkä rajan sen on pidettävä vakaana, voi suunnitella vähemmän tahattomia riippuvuuksia. Se voi tehdä versiopolitiikastaan yksiselitteisen. Se voi julkaista käytöstäpoistopolun. Se voi antaa asiakkaille testiympäristön, joka käyttäytyy kuin oikea rajapinta eikä kuin markkinointidemo. Se voi erottaa järjestelmän osan, joka on aidosti omistusoikeudellinen, osasta, joka on jaettava, jotta asiakas säilyttää toimijuutensa. Tämä ei ole hyväntekeväisyyttä. Se on selkeämpi sopimus molemmille osapuolille.

Euroopan etu tässä ei ole se, että se voi poistaa riippuvuuden. Vakavilla järjestelmillä on riippuvuuksia. Etu on mahdollisuus tehdä riippuvuudesta luettavaa, neuvoteltavaa ja riittävän käännettävää käsillä olevaan käyttöön. Järjestelmä, joka voi pysyä toimittajalla, koska se ansaitsee edelleen suhteen, on vahvempi kuin sellainen, joka pysyy, koska kukaan ei voi rekonstruoida sen tietueiden merkitystä muualla.

Datatilat eivät ole varastoja paremmalla valaistuksella

Ilmaus "datatila" voi luoda väärän mielikuvan. Se viittaa suureen huoneeseen, johon kaikki tuovat dataa, asettavat sen hyllylle ja lähtevät kotiin tyytyväisinä yhteentoimivuuteen. Eurooppalainen lähestymistapa on vaativampi. Yhteisten eurooppalaisten datatilojen on tarkoitus tehdä datasta saatavilla pääsyä ja uudelleenkäyttöä varten luotettavassa ja turvallisessa ympäristössä. Komissio kuvailee yhteisiä infrastruktuureja ja hallintokehyksiä asioiksi, jotka tukevat datan yhdistämistä, pääsyä ja jakamista sekä oikeudenmukaisia, avoimia, oikeasuhteisia ja syrjimättömiä pääsääntöjä.

Se on tärkeä korjaus. Tiedon jakaminen ei ole kertaluonteinen siirtotoimi. Se on jatkuva suhde osapuolten välillä, joilla on erilaiset tarkoitukset, valtuudet ja vastuut. Yksi osapuoli voi käyttää aineistoa tutkimukseen, mutta ei markkinointiin. Toisella voi olla velvollisuus korjata arvo. Kolmas voi saada vastaanottaa johdetun tuloksen, mutta ei taustalla olevaa tietuetta. Osa tiedoista on säilytettävä. Osa on poistettava. Osa voidaan käsitellä vain tietyssä ympäristössä. Hallinnoivat ehdot ovat osa yhteentoimivuutta, eivät alaviite erillisessä lakikansiossa.

Komission datatila-työ tunnistaa tukea viitearkkitehtuurissa, rakenneosissa, semantiikassa, yhteentoimivuusmäärityksissä ja tietomalleissa sekä neuvontapalveluissa Data Spaces Support Centren kautta. Tämä laajuus on järkevä. Suojattu yhdyskäytävä ilman yhteistä sanastoa ei ratkaise semanttista ongelmaa. Yhteinen sanasto ilman identiteettiä, käyttövaltuuksien hallintaa tai hallintomallia ei ratkaise luottamusongelmaa. Malli, joka voi kysellä datatilaa ilman ilmoitettua tarkoitusta, lähdetietuetta ja korjauspolkua, ei tee tilasta käytettävämpää. Se luo uuden tiedon käyttäjän, jonka velvollisuudet ovat epäselvät.

Tekoälyn kannalta seuraus on suoraviivainen. Mallia ei pidä kohdella etuoikeutettuna oikotienä datatilan rajan yli. Jos henkilö tai palvelu tarvitsee käyttöoikeuden perusteen, määritellyn tarkoituksen, identiteetin ja käyttötietueen, tekoälytyönkulku tarvitsee saman kurinalaisuuden. Tekniset erot voivat liittyä siihen, miten agentti pyytää tietoja tai miten hakuvaihe suoritetaan. Minkäänlaista maagista poikkeusta ei saa olla, jossa järjestelmä sanoo ”malli tarvitsi kontekstia” ja tavalliset hallintosäännöt poistuvat kuvasta.

Tämä ei tarkoita, että jokainen kehote pitäisi muuttaa byrokraattiseksi seremoniaksi. Se tarkoittaa, että järjestelmän on erotettava kysymys valtuutuksesta. Malli voi muotoilla kyselyn. Käytäntötietoisen kerroksen on päätettävä, saako kysely tavoittaa tietyn lähteen, minkä tarkoituksen nojalla, millä minimoinnilla ja miten pyyntö ja tulos kirjataan. Vastaus voi sitten viitata lähteeseen tai selittää rajoituksen. Jos lähde muuttuu, järjestelmän on pystyttävä tietämään, mikä myöhempi vastaus tai päätös saattaa vaatia uudelleentarkastelua. Muuten alkuperäprovenienssista tulee koristeellinen linkki keskustelutallenteessa.

Semanttiset sopimukset ovat erityisen hyödyllisiä tässä, koska ne tekevät luottamuksen vähimmäisyksikön näkyväksi. Lähdetunniste ei ole pelkkä merkkijono. Sen pitäisi yksilöidä versio tai vakaa viite. Käyttöoikeus ei ole pelkkä tosi tai epätosi -arvo. Sillä voi olla laajuus, tarkoitus, haltija, aikaraja ja peruste. Korjaus ei ole pelkkä päivitys. Se voi korvata aiemman väitteen säilyttäen samalla historian, joka tarvitaan tapahtuneen selittämiseen. Kieltäytyminen ei ole pelkkä virhe. Se voi olla tietoinen raja, jonka on oltava ymmärrettävä kysyjälle.

Kiusaus on ratkaista tämä yleismaailmallisella ”tekoälyn yhteentoimivuuskerroksella”, joka väittää tekevänsä kaikista agenteista, malleista, tietokannoista ja työnkulun työkaluista vaihtokelpoisia. Tällainen väite sekoittaa yleensä yhteisen kuljetuksen yhteiseen merkitykseen. Yleiskäyttöinen protokolla voi olla hyödyllinen. Se ei voi kertoa vastaanottajalle, mitä kliininen koodi, suunnittelun tila, etuuspäätös tai riskilippu tarkoittaa kyseisellä toimialalla. Se ei voi päättää, kuka saa ohittaa automatisoidun ehdotuksen. Se ei voi kertoa organisaatiolle, kuinka kauan se saa säilyttää haetun tietueen. Standardit kantavat sopimuksia. Ne eivät poista tarvetta tehdä niitä.

On olemassa maanläheisempi tavoite. Rakentakaa toimialakohtaisia sopimuksia siellä, missä yhteinen työ ne oikeuttaa. Käyttäkää uudelleen yleisiä rakennuspalikoita silloin, kun ne aidosti sopivat: identiteetti, valtuutus, alkuperä, tapahtumat, versiointi, vaatimustenmukaisuustestaus ja saavutettava dokumentaatio. Pitäkää yhteys yleisen standardin ja paikallisen toteutuksen välillä tarkastettavissa. Silloin osallistuja voi liittyä mukaan luovuttamatta koko järjestelmäänsä, ja toimiala voi kehittyä ilman, että jokaisen uuden toimittajan saapuessa aloitetaan tyhjältä pöydältä.

Se on parempi versio skaalautumisesta. Se ei mittaa onnistumista sillä, kuinka paljon dataa on keskitetty tai kuinka monta palvelua on pakotettu yhteen rajapintaan. Se mittaa onnistumista sillä, voiko laillinen vaihto tapahtua riittävän selkeästi, jotta osallistujat voivat käyttää, korjata, hallinnoida ja tarvittaessa pysäyttää sen.

Valitse kortti tarkastellaksesi sitä vaihdon osaa, joka tekee tietueesta käyttökelpoisen alkuperäisen järjestelmän ulkopuolella.

Standardit tarvitsevat elämän julkaisun jälkeen

Standardeja kuvataan usein niin, kuin niiden työ päättyisi dokumentin julkaisuun. Käytännössä julkaisu on hetki, jolloin vaikeampi työ alkaa. Jonkun on valittava sovellettava profiili. Jonkun on toteutettava se. Jonkun on testattava reunatapaukset. Jonkun on päätettävä, onko uusi versio yhteensopiva, milloin vanha versio poistuu käytöstä ja mitä tapahtuu aikaisempien sääntöjen mukaan luoduille tietueille. Jonkun on selitettävä koko järjestely tiimille, joka ei ollut huoneessa, kun lyhenne valittiin.

CEN:n ja CENELEC:n EN 18235-1:2026 on tuore esimerkki kehityssuunnasta. Standardi koskee datan jakamista ja vaihtoa organisaatioiden välillä painottaen yhteentoimivuutta ja vastuullisuutta, ja sen ilmoitettuihin sovelluskohteisiin kuuluvat Common European Data Spaces. Yksityiskohdilla on tässä vähemmän merkitystä kuin signaalilla. Luottamusta datan jakamiseen ei käsitellä tunteena, jonka kojelauta tuottaa. Sitä käsitellään asiana, jota muovaavat vaihtoa, vastuuta ja kykyä selvittää, mitä tapahtui, koskevat sopimukset.

Paras standardityö jättää tilaa asioille, joita se ei voi ratkaista. Tekninen eritelmä voi määritellä sanomarakenteen. Se ei voi vahvistaa paikallista oikeusperustaa. Sanasto voi määritellä käsitteen. Se ei voi taata, että paikallinen prosessi käyttää käsitettä rehellisesti. Vaatimustenmukaisuustesti voi osoittaa, että toteutus täyttää nimetyt tapaukset. Se ei voi todistaa, että organisaatio on kouluttanut poikkeuksia käsittelevät henkilöt. Muun väittäminen tekee standardeille karhunpalveluksen. Se saa ne näyttämään harkinnan korvikkeelta sen sijaan, että ne olisivat työkalu, joka vie harkinnan pidemmälle.

Vaatimustenmukaisuustestaus on erityisen arvokasta, koska se muuttaa yhteentoimivuuden lupauksesta havaittavaksi ominaisuudeksi. Toimittaja voi sanoa tukevansa profiilia. Ostajan pitäisi voida kysyä, mikä versio, mitkä valinnaiset ominaisuudet, mitkä negatiiviset tapaukset, mitkä virhevastaukset ja mitkä julkaistut testitodisteet tukevat tätä väitettä. Toteuttajan pitäisi voida ajaa samat tapaukset ennen kuin integraatio siirtyy tuotantoon. Muutoksen pitäisi ilmoittaa, onko se taaksepäin yhteensopiva ja joutuvatko jotkut käyttäjät toimimaan.

AI-rajapinnoissa tämä voi tuntua nipotukselta siihen asti, kunnes tulee ensimmäinen yhteensopimaton muutos. Yksi työkalu kutsu odottaa rahasummaa sentteinä. Toinen palauttaa desimaalimerkkijonon ilman valuuttaa. Yksi agentti tulkitsee puuttuvan kentän pyynnöksi lisätiedoista. Toinen tulkitsee sen luvaksi päätellä arvo. Yksi mallipäivitys muuttaa viittausten rakenteen. Alavirran prosessi jäsentää yhä vanhaa muotoa. Mikään näistä ei ole filosofinen ongelma. Ne ovat tavallisia rajapintavirheitä, jotka korostuvat järjestelmässä, joka voi toimia nopeasti.

Hyvä sopimus sisältää siksi sekä kieltäytymisen että onnistumisen. Se kertoo, mitä järjestelmä hylkää, mitä se palauttaa, kun lähdettä ei voida varmistaa, mitä se tekee, kun käytäntö puuttuu, miten vastaanottaja erottaa osittaisen ja täydellisen tiedon sekä mistä ihmisen arviointi alkaa. Hiljaisuus on surkea yhteentoimivuusstrategia. Selkeä kieltäytyminen on usein yhteensopivin vastaus, koska se antaa seuraavalle järjestelmälle rehellisen tilan, jonka kanssa työskennellä.

Versiointi ansaitsee saman kunnioituksen. Hyödyllinen rajapinta ei vain liitä versionumeroa URL-osoitteeseen ja toivo parasta. Se ilmoittaa muutoksesta, kertoo siirtymäpolun, säilyttää vanhan sopimuksen luvatun ajan, kun se on mahdollista, tallentaa, miten säilytettyä dataa tulkitaan eri versioissa, ja antaa riittävästi varoitusaikaa riippuvaisille järjestelmille sopeutua. Tämä ei ole jännittävää työtä. Näin rajasta lakkaa tulemasta yllätys. Alankomaissa sanotaan mielellään, että asia on "riittävän selvä", kunnes joku joutuu rakentamaan sen. Versiopolitiikka on sitä, mitä jää jäljelle, kun tuo sanonta kohtaa tuotantojärjestelmän.

Tässä on eurooppalainen taloudellinen näkökulma. Pienemmät organisaatiot voivat osallistua, kun yhteyden säännöt ovat julkisia, dokumentoituja ja testattavia. Niiden ei tarvitse olla yksityisessä suhteessa jokaisen hallitsevan alustan kanssa vain selvittääkseen, miten vaihto käyttäytyy. Myös suuremmat organisaatiot hyötyvät, koska ne voivat vähentää räätälöidyn integraation velkaa ja testata toimittajan väitteitä ennen kuin ydintriippuvuus on muodostunut. Lopputulos ei ole kitkaton. Se on reilumpaa kitkaa: työ on näkyvää, hinnoiteltua ja jaettua sen sijaan, että se löydettäisiin vasta, kun sopimus on kaventanut vaihtoehdot.

Käytännön kysymys on, mikä selviää luovutuksesta

Useimmat yhteentoimivuusohjelmat paranevat, kun ne alkavat pienestä vaihdosta suuren tavoitteen sijaan. Valitse yksi päätös- tai palveluraja. Kuvaile tieto, jonka on ylitettävä se. Nimeä auktoriteetin lähde, vastaanottaja, sallittu käyttötarkoitus, sanasto, elinkaaritapahtumat, turvallisuusehdot ja todisteet, jotka osoittavat vaihdon tapahtuneen tarkoitetulla tavalla. Testaa sitten sekä onnistuminen että epäonnistuminen.

Syntynyt keskustelu on usein paljastavampi kuin ominaisuusvertailu. Mitä tapahtuu, kun lähde korjaa tietueen? Voiko vastaanottaja tunnistaa, mihin kopioon muutos vaikuttaa? Mitä tapahtuu, kun AI-järjestelmä ei voi tukea suositusta sallitulla lähteellä? Palauttaako se selkeän kieltäytymisen, osittaisen tuloksen vai keksityn luottamusarvon? Mitä tapahtuu, kun vastaanottaja saa skeemaversion, jota se ei ymmärrä? Voiko se hylätä vaihdon turvallisesti? Mitä tapahtuu, kun henkilö kiistää luokituksen? Tuleeko korjauksesta uusi tapahtuma jäljityksellä, vai kirjoitetaanko vanha tulos päälle, kunnes kukaan ei voi enää rekonstruoida alkuperäisen toiminnon perustaa?

Nämä ovat suunnittelukysymyksiä, eivät vain vaatimustenmukaisuuskysymyksiä. Ne muovaavat, voivatko ihmiset käyttää palvelua, voiko toimittaja tukea sitä ja voiko toinen järjestelmä liittyä mukaan perimättä dokumentoimatonta riskiä. Ne muovaavat myös AI:n laatua. Malli, jolla on selkeä tietoraja, jättää vähemmän tilaa muuttaa epäselvä konteksti näkymättömiksi oletuksiksi. Työnkulku, jossa on tyypitetyt tulosteet ja lähteen identiteetti, antaa arvioijille konkreettista tarkasteltavaa. Versioitu päätöstietue mahdollistaa arvioinnin myös sen jälkeen, kun malli, kehote tai käytäntö on muuttunut.

On olemassa järkeviä rajoja. Osa tiedoista ei saa liikkua. Osa tiedoista on syytä minimoida tai aggregoida. Osa palveluista tarvitsee oman rajapinnan, koska työ on poikkeuksellista, arkaluonteista tai riskialtista. Osa paikallisesta sanastosta on syytä jättää paikalliseksi, koska väkisin rakennettu väärä vastaavuus tuhoaisi merkityksen. Yhteentoimivuus ei ole vaatimus siitä, että jokainen järjestelmä paljastaisi kaiken. Se on vaatimus siitä, että valittu rajapinta on rehellinen sen suhteen, mitä se paljastaa, miksi, kenelle ja millä seurauksilla.

Tämä rehellisyys on erityisen tärkeää, kun tekoälytoimittajat tarjoavat nopeaa yhteyttä. Liitin, joka hiljaa kopioi suuren aineiston mallin kontekstiin, voi ratkaista demonstraatio-ongelman samalla kun se luo hallintaongelman. Työkalu, joka kirjoittaa liiketoimintajärjestelmään ilman pysyvää työtunnistetta, voi luoda automaation samalla kun se tuhoaa mahdollisuuden auditoida sitä. Universaali agenttiprotokolla voi helpottaa löydettävyyttä samalla kun se jättää valtuutuksen, käyttötarkoituksen rajaamisen ja semanttisen vastuun käsittelemättä. Kysymyksen pitäisi aina olla se, mikä säilyy luovutuksessa: data, merkitys, lupa, näyttö ja kyky korjata.

Toimiva ohjelma antaa jokaiselle näistä paikan. Data tarvitsee formaatin ja eheystarkistuksen. Merkitys tarvitsee mallin, sanaston tai nimenomaisen kuvauksen. Lupa tarvitsee identiteetin, käyttötarkoituksen ja käytäntörajan. Näyttö tarvitsee kirjauksen lähteestä, versiosta, muunnoksesta ja päätöksestä. Korjaus tarvitsee tapahtumapolun ja vastuuhenkilön. Käyttö tarvitsee toimintaohjeet, seurattavuuden ja tavan pysäyttää tai peruuttaa muutos. Mikään tästä ei sovi sankarilliseen julkaisuvideoon. Se kuitenkin mahdollistaa sen, että järjestelmä pysyy hyödyllisenä sen jälkeen, kun julkaisuvideon on korvannut tukipyyntö.

Dwevessä sovellamme periaatetta suppeasti Fabricin julkisessa kuvauksessa. Sivusto kuvaa työkeskeistä oliomallia, jossa mallit, agentit, työkalut, ihmiset ja työnkulut osallistuvat tyypitettyjen sopimusten kautta, ja se kuvaa käyttöliittymiä ja rajapintoja, jotka toimivat samalla toimialueella. Tämä on tuotesuunnittelun kannanotto, ei todiste siitä, että mikä tahansa käyttöönotto olisi automaattisesti yhteentoimiva tai että tyypitetty rajapinta ratkaisisi juridiset, semanttiset tai operatiiviset kysymykset. Se on yksinkertaisesti sellainen rajapinta, jota pidämme vakavien tekoälyjärjestelmien tarpeena: sellainen, jossa pysyvä työ ei katoa toimittajakohtaiseen keskusteluun.

HEDL tarjoaa pienemmän, julkisen esimerkin. Sen dokumentaatio kuvaa Apache 2.0 -lisensoidun tekstiformaatin, julkaistun formaattispesifikaation ja vaatimustenmukaisuusasiakirjat, sekä muunnokset JSON-, YAML-, XML-, CSV-, Parquet- ja TOON-muotoihin ja niistä takaisin. Nämä ominaisuudet eivät tee jokaisesta tietoaineistosta yhteensopivaa, eivätkä ne muuta formaattimuunnosta semanttiseksi sopimukseksi. Ne kuitenkin tekevät hyödyllisen väitteen rajapinnasta: vaihtoformaatin pitäisi olla tarkastettavissa, testattavissa ja kyettävä toimimaan olemassa olevien järjestelmien rinnalla sen sijaan, että se vaatisi jokaista järjestelmää muuttumaan omaksi yksityiseksi murteekseen.

Euroopan ei tarvitse voittaa tekoälykilpailua kilpailemalla pois omista instituutioistaan. Sen mahdollisuus on tehdä näistä instituutioista, markkinoista ja teknisistä yhteisöistä helpommin yhdistettäviä teeskentelemättä, etteivät niiden erot merkitse mitään. Työ näyttää kaukaa katsottuna tylsältä. Se on versiohistoriaa, testitapauksia, sanastovalintoja, käyttösääntöjä, siirtokokeita ja satunnaisia epämiellyttäviä kokouksia siitä, kuka saa muuttaa kenttää. Läheltä katsottuna se on työtä, joka mahdollistaa sen, että järjestelmään voi luottaa joku muu kuin sen rakentanut tiimi.

Tämä on etu, joka kannattaa pitää. Mallin voi korvata. Toimittajan voi vaihtaa. Palvelu voi ylittää rajan. Korjaus voi saavuttaa paikan, jossa sillä on merkitystä. Ihminen voi kysyä, mitä tapahtui, ja saada vastaukseksi jotakin parempaa kuin itsevarman kappaleen. Teknologia pysyy kunnianhimoisena. Rajapinta pysyy tavallisena. Tavallinen osa on se, mikä antaa kunnianhimolle luotettavan jalansijan.

Lähteet