Miksi avoimet standardit merkitsevät enemmän kuin avoimet lupaukset
Vienti, joka oli avoin, kunnes joku avasi sen
Projekti näytti terveeltä ensimmäiseen siirtotestiharjoitukseen asti. Toimittaja oli luvannut avoimen viennin. Sopimus mainitsi tiedon siirrettävyyden. Myyntiesityksessä sana avoin lausuttiin sellaisen ihmisen varmuudella, joka ei ole koskaan joutunut lataamaan kahdeksan vuoden tietoja toiseen järjestelmään. Painike oli olemassa. Tiedostot saapuivat. Kaikki huokaisivat hetken helpotuksesta. Sitten vastaanottava tiimi avasi tiedostot ja huomasi, että vienti oli teknisesti avoin samalla tavalla kuin laatikollinen irrallisia ruuveja on teknisesti huonekalu.
Tiedostot olivat JSON-muodossa, mutta ne eivät noudattaneet yhteistä skeemaa. Aikaleimoissa sekoittuivat paikallinen aika ja UTC. Tilakoodit olivat sisäisiä numeroita, joiden osittaiset merkitykset löytyivät erillisestä taulukkolaskentatiedostosta. Liitteet viittasivat tallennusavaimiin, jotka vanhenivat seitsemän päivän kuluttua. Poistetut tietueet puuttuivat kokonaan sen sijaan, että ne olisi merkitty poistetuiksi. Auditointitapahtumat oli litistetty kommenteiksi. Käyttäjärooleilla oli nimiä, jotka olivat järkeviä vain vanhan tuotteen sisällä. Jotkin kentät sisälsivät ihmisten luettavaa tekstiä, toiset tunnisteita, ja jotkin sisälsivät molempia riippuen siitä, minkä työnkulun versio oli ne luonut. Vienti oli riittävän avoin sieltä poistumiseen, mutta ei riittävän avoin perille saapumiseen.
Kukaan ei ollaan valehdellut sarjakuvamielessä. Toimittaja saattoi rehellisesti sanoa, että tietoja ei ollut salattu vangiksi. Asiakas pystyi lataamaan ne. Kehittäjä pystyi jäsentämään tiedostot. Puuttui standardi, joka olisi varmistanut, että tiedot tarkoittavat samaa asiaa myös alkuperäisen kotinsa ulkopuolella. Lupaus oli kuvannut pääsyä. Organisaatio tarvitsi siirrettävyyttä. Nämä liittyvät toisiinsa, mutta eivät ole sama asia. Ovi, joka aukeaa suohon, on silti ovi. Se on vain huono uloskäynti.
Siksi avoimet standardit merkitsevät enemmän kuin avoimet lupaukset. Lupaukset riippuvat hyvästä tahdosta, tulkinnoista, henkilöstön muistista ja tulevan neuvottelun tunnelmasta. Standardit tarjoavat yhteisiä testejä. Ne määrittelevät, miten tietueet muotoillaan, miten versiot muuttuvat, miten merkitys säilyy, miten virheistä raportoidaan, miten identiteetti esitetään, miten metatieto kulkee ja miten yksi järjestelmä osoittaa toiselle puhuvansa samaa kieltä. Työ on tylsää samalla tavalla kuin perustukset ovat tylsiä. Rakennukset harvoin suosivat niitä. Rakennukset kaipaavat niitä välittömästi, kun ne puuttuvat.
Avoin on adjektiivi, ei arkkitehtuuri
Avoin on antelias sana ja siksi vaarallinen. Se voi tarkoittaa avointa lähdekoodia, avointa rajapintaa, avoimia painoarvoja, avointa dataa, avointa dokumentaatiota, avointa hallintoa, avointa hankintaa, avoimia standardeja tai yksinkertaisesti niin avointa, ettei kukaan esitä toista kysymystä. Kokouksissa sana leijuu usein yksityiskohtien yläpuolella kuin miellyttävä sääjärjestelmä. Ihmiset nyökkäävät, koska avoin kuulostaa historian oikealta puolelta. Sitten toteutus alkaa, ja adjektiivista on tultava arkkitehtuuri.
Avoin rajapinta voi silti olla omisteinen, jos sen objekteilla on yksityisiä merkityksiä. Avoin lähdekoodi voi silti tuottaa tietueita, joita mikään muu järjestelmä ei ymmärrä. Avoin data voi silti olla käyttökelvotonta, jos kentät ovat moniselitteisiä, lisenssit epäselviä, päivitykset epäsäännöllisiä eivätkä korjaukset säilytä historiaa. Avoimet painoarvot voivat silti olla toiminnallisesti suljettuja, jos koulutusdataa, arviointimenetelmää, turvallisuusoletuksia ja käyttöönottorajapintoja ei voida tarkastaa tai toistaa. Avoimuus yhdellä tasolla ei automaattisesti avaa seuraavaa tasoa. Teknologia on erittäin hyvä piilottamaan lukot kauniimpien ovien taakse.
Avoimuuslupaukset annetaan yleensä sillä tasolla, joka on helpoin näyttää. Tässä on päätepiste. Tässä on säilö. Tässä on ladattava tiedosto. Tässä on aiejulistus. Nämä asiat voivat olla arvokkaita. Ne ovat myös puutteellisia. Vakavat järjestelmät riippuvat käyttäytymisestä ajan mittaan. Mitä tapahtuu, kun skeema muuttuu. Mitä tapahtuu, kun kenttä poistetaan käytöstä. Mitä tapahtuu, kun tehdään korjaus. Mitä tapahtuu, kun kaksi yhdenmukaista järjestelmää ovat eri mieltä. Mitä tapahtuu, kun viranomainen kysyy polkua lähteestä päätökseen. Lupaus on alku. Standardi on koneisto keskivaihetta varten.
Erolla on merkitystä, koska instituutiot eivät osta ohjelmistoa vain julkaisupäivää varten. Ne ostavat sen vaihtopäivää, tilintarkastuspäivää, häiriöpäivää, fuusiopäivää, julkisuuspyyntöpäivää ja sitä syvästi epämuodikasta päivää varten, jolloin jonkun on luettava seitsemän vuotta vanha tietue. Avoimet lupaukset harvoin selviävät kaikista näistä päivistä ilman apua. Avoimet standardit on suunniteltu juuri siksi, että muistiin, kannustimiin ja organisaatiokaavioihin ei voi luottaa käyttäytyvän ikuisesti. Tämä ei ole kyynisyyttä. Se on asiakirjahallintaa paremmissa kengissä.
Standardit tekevät poistumisesta todellista
Poistuminen on rehellisin avoimuuden testi. Voiko organisaatio lähteä datansa, todisteidensa, konfiguraatioidensa, käyttöoikeuksiensa, lokiensa ja toiminnallisen merkityksensä kanssa ehjänä. Ei teoreettisesti. Ei sen jälkeen, kun ammattilaispalvelut käyttävät kuusi kuukautta räätälöityjen muuntimien kirjoittamiseen. Ei sen jälkeen, kun sankarikehittäjä purkaa tilakoodeja vanhoista kuvakaappauksista. Voiko organisaatio lähteä suunnitellusti, testattavasti sekä juridisesti ja toiminnallisesti puolustettavasti. Jos ei, avoimuuden lupaus oli mukavuuspeitto, johon oli liitetty uusimisehto.
Todellinen poistuminen edellyttää formaatteja, skeemoja, tunnisteita, sanastoja, aikaleimoja, versiosääntöjä, virheiden käsittelyä ja vaatimustenmukaisuustestejä. Se edellyttää tietoa siitä, ovatko viennit täydellisiä, onko poistetut tietueet merkitty, ovatko liitteet pysyviä, säilyttävätkö auditointijäljet kausaalisuuden, sisältyvätkö johdetut tiedot vai onko ne tarkoituksella jätetty pois ja voidaanko käyttöoikeudet rekonstruoida. Nämä ovat tylsiä kysymyksiä, kunnes niistä tulee kiireellisiä. Sitten niistä tulee ainoita kysymyksiä, joista kukaan välittää.
Standardit vähentävät myös pelkoa hankinnassa. Jos ostajat tietävät, että järjestelmä tukee hyvin testattuja standardeja, he voivat valita soveltuvuuden perusteella panttivankiriskin sijaan. Toimittajat voivat kilpailla palvelulla, toteutuksella, suorituskyvyllä, tuella ja toimialasoveltuvuudella sen sijaan, että kilpailisivat asiakkaan poistumisen pelolla. Tämä on terveellisempää kaikille paitsi liiketoimintamalleille, jotka nauttivat hiljaa vankeudesta. Ei tarvita melodraamaa. Markkinat toimivat paremmin, kun poistumiset eivät ole arkeologisia projekteja.
Poistumisen testaamisessa ennen sitoutumista on hyödyllinen kurinalaisuus. Pyydä näytevienti. Validoi se. Tuo se neutraaliin työkaluun. Säilytä auditointikonteksti. Suorita korjaus. Vaihda skeemaversiota. Tarkista, säilyvätkö lähdetunnisteet. Kysy, miten tuleva järjestelmä tietäisi eron ei koskaan ollut olemassa, poistettu, muokattu ja ei saavutettavissa välillä. Jos tämä tuntuu liioittelulta hankinnan aikana, vertaa sitä siihen, että hallitukselle selitetään, miksi avoin tarkoitti ladattavaa mutta ei käytettävää. Hallitus ei välttämättä arvosta erottelua yhtä paljon kuin myyntiesitys.
Semantiikassa lukkiutuminen piileskelee
Tekniset tiimit keskittyvät usein syntaksiin, koska syntaksi epäonnistuu äänekkäästi. Virheellinen tiedosto ei jäsennä. Puuttuva kenttä rikkoo validoinnin. Päätepiste palauttaa virheen. Semantiikka epäonnistuu kohteliaammin. Tiedosto jäsentyy, tuonti suoritetaan, kojelauta täyttyy, ja vasta myöhemmin joku huomaa, että suljettu tarkoitti valmistunut toisessa järjestelmässä ja hylätty toisessa. Syntaksivirheet ovat meluisia. Semanttiset virheet pukeutuvat toimistovaatteisiin ja osallistuvat kokouksiin.
Vendorilukko piileskelee usein näissä merkityksissä. Tilaelinkaari, jonka tuntee vain yksi tuote. Käyttöoikeusmalli, jota ei voi ilmaista missään muualla. Työnkulun tila, joka yhdistää lainopillisen hyväksynnän, operatiivisen valmiuden ja laskutustriggerin. Mallin arviointitulos, joka on tallennettu tunnisteena ilman dataa, metriikkaa tai kynnysarvoa, joka sen tuotti. Dokumentin tiivistelmä, joka on irrotettu lähdeversiosta. Data on olemassa. Merkitys on vangittuna.
Avoimet standardit pakottavat keskustelemaan merkityksistä ennen siirtymäpäivää. Ne kysyvät, mitä kenttä tarkoittaa, onko sen merkitys vakaa, mikä taho sen määrittelee, mikä versio on voimassa, miten muutokset viestitään ja mitä vastaanottaja voi turvallisesti päätellä. Tämä voi tuntua hitaalta. Se on hitaampaa kuin vientipainikkeelle vilkuttaminen. Se on paljon nopeampaa kuin se, että sääntelytarkastuksen aikana huomataan, ettei organisaatio osaa selittää, miksi tuotu tietue tarkoittaa sitä, mitä se nyt näyttää tarkoittavan.
Järjestelmät, jotka käyttävät tekoälyä, tekevät semanttisesta siirrettävyydestä entistä tärkeämpää. Ne tuottavat johdettuja artefakteja: upotuksia, luokitteluja, tiivistelmiä, riskipisteitä, selityksiä, kehotteita, työkalujälkiä ja arviointituloksia. Nämä artefaktit voivat vaikuttaa päätöksiin, vaikka alkuperäinen lähde olisi jossain muualla. Jos niiden semantiikka on yksityistä, organisaatio ei voi tarkastella, korjata, toistaa tai poistaa niitä siististi. Upotus ilman malliversiota ja lähdealuetta ei ole siirrettävää tietoa. Se on matkamuisto laskennasta.
Standardit ovat sosiaalista teknologiaa
Standardi ei ole vain tekninen dokumentti. Se on sosiaalista teknologiaa, jolla koordinoidaan ihmisiä, joilla ei ole yhteistä esihenkilöä. Toimittajat, julkiset toimielimet, arkistot, sairaalat, koulut, sääntelyviranomaiset, tutkijat, kansalaiset ja kehittäjät voivat tehdä yhteistyötä, koska standardi vähentää sitä, kuinka paljon heidän on luotettava toisiinsa henkilökohtaisesti. He voivat testata vaatimustenmukaisuutta. He voivat kiistellä versioista. He voivat rakentaa työkaluja itsenäisesti. He voivat säilyttää tietueita, vaikka alkuperäinen toimittaja, tiimi tai poliittinen taustavoima olisi siirtynyt muihin tehtäviin.
Tämä sosiaalinen puoli on syy siihen, miksi hallinnolla on merkitystä. Standardi, jota yksi osapuoli ylläpitää ilman läpinäkyviä muutossääntöjä, voi olla hyödyllinen, mutta se on hauras. Standardi, jota yhteisö ylläpitää selkeällä versioinnilla, vaatimustenmukaisuustesteillä, ongelmaprosesseilla, tietoturvakäsittelyllä ja siirtymäohjeistuksella, on enemmän kuin dokumentaatio. Se on institutionaalista muistia. Se antaa osallistujille paikan, jossa kiistellä tuottavasti ennen kuin jokaisesta integraatiosta tulee kahdenvälinen sopimus, jossa on huonommat tarjoilut.
Hyvät standardit tuntevat myös rajansa. Ne eivät yritä koodata jokaista paikallista yksityiskohtaa. Ne määrittelevät vakaat ytimet ja laajennuskohdat. Ne sallivat alan erikoistumisen tuhoamatta yhteentoimivuutta. Ne erottavat pakolliset kentät valinnaisista, informatiivisen ohjeistuksen normatiivisista vaatimuksista ja kokeelliset ominaisuudet vakaista sitoumuksista. Tämä kurinalaisuus estää kaksi vastakkaista epäonnistumista: standardin, joka on niin ohut, ettei se tarkoita mitään, ja standardin, joka on niin täydellinen, ettei kukaan voi toteuttaa sitä ilman sapattivapaata.
On kuiva vitsi siinä, miten organisaatiot valittavat, että standardikokoukset ovat hitaita, ja käyttävät sitten vuosia räätälöityihin integraatiokokouksiin, koska he ohittivat standardin. Hidas kerran voi olla halvempaa kuin hidas ikuisesti. Kysymys ei ole siitä, onko koordinoinnilla kustannus. Kysymys on siitä, maksetaanko kustannus avoimesti, josta monet voivat hyötyä, vai maksetaanko se yksityisesti jokaisessa projektissa, kunnes kaikki teeskentelevät, että monimutkaisuus on paikallinen sääilmiö.
AI tarvitsee standardoitua näyttöä, ei vain malleja
Suuri osa tekoälykeskustelusta keskittyy mallien avoimuuteen. Se on ymmärrettävää. Mallit ovat näkyviä, kalliita ja poliittisesti kiinnostavia. Mutta tekoälyä käyttävät organisaatiot tarvitsevat muutakin kuin pääsyn malliin. Ne tarvitsevat standardoituja tapoja kuvata lähteiden alkuperää, kehotteiden mallipohjia, työkalujen kutsuja, malliversioita, turvallisuusrajoitteita, arviointiaineistoja, luottamusmittareita, ihmisen tekemiä korjauksia ja päätösten kuittauksia. Ilman näitä standardeja tekoälyjärjestelmiä on vaikea vertailla, auditoida, siirtää ja korjata.
Tarkastellaan yksinkertaista tekoälyavusteista päätöstä. Pyyntö saapuu. Lähteitä haetaan. Malli luonnostelee vastauksen. Tarkistaja varmistaa väitteet. Ihminen muokkaa luonnosta. Työnkulku lähettää lopullisen viestin. Mitkä osat pitäisi tallentaa. Missä muodossa. Mitkä tunnisteet yhdistävät vastauksen lähteisiin. Miten malliversio esitetään. Miten hakuparametrit säilytetään. Miten ihmisen eriävä mielipide tallennetaan. Miten toinen järjestelmä voi myöhemmin toistaa tai haastaa ketjun. Nämä ovat standardikysymyksiä. Jos jokainen toimittaja keksii oman vastauksensa, siirrettävyydestä tulee tulkitsevaa tanssia oikeudellisine riskeineen.
Standardoitu näyttö auttaa myös välttämään valheellista läpinäkyvyyttä. Järjestelmä voi näyttää viittauksia, jotka eivät ole pysyviä tunnisteita. Se voi näyttää luottamusluvun, jonka merkitys on yksityinen. Se voi näyttää selityksen ilman sääntöversiota, joka sen muokkasi. Se voi näyttää auditointilokeja, joita ei voi yhdistää lähdemuutoksiin. Standardoidut kentät ja vaatimustenmukaisuustestit tekevät läpinäkyvyydestä vähemmän koristeellista. Ne pakottavat näytön säilymään toimivana myös sen esittävän käyttöliittymän ulkopuolella.
Tämä ei tarkoita, että kaikki tekoälyn jäljet pitäisi julkaista tai säilyttää ikuisesti. Yksityisyys ja turvallisuus vaativat pidättyväisyyttä. Standardit voivat auttaa myös tässä määrittelemällä tietojen poistamisen, hajautusarvot, säilytyksen metatiedot, käyttöoikeusroolit ja vähimmäisnäyttövaatimukset eri riskiluokille. Standardi ei ole vaatimus paljastaa kaikkea. Se on tapa päättää johdonmukaisesti, mitä on tallennettava vastuullisuuden vuoksi ja mitä on suojattava. Tässä erottelussa vakava hallinto elää.
Standardit suojaavat myös pieniä toimijoita
Avoimia standardeja kuvataan joskus toimittajia rajoittavina, mutta ne suojaavat myös pienempiä toimittajia, tutkijoita ja julkisen sektorin tiimejä. Yhteinen standardi alentaa markkinoille tulon kustannuksia, koska uusien toimijoiden ei tarvitse selvittää käänteismallintamalla jokaisen asiakkaan yksityistä tietorakennetta. Ne voivat rakentaa yhteensopivia työkaluja, validaattoreita, katseluohjelmia, arkistoja, siirtopalveluita ja toimialalaajennuksia. Yhteentoimivuus ei ole vain ostajien poistumisluukku. Se on markkinoiden infrastruktuuria.
Organisaation sisällä standardit vähentävät riippuvuutta yksittäisten ihmisten muistista. Data-analyytikko lähtee. Tuoteomistaja vaihtaa roolia. Konsultin sopimus päättyy. Standardi säilyttää sovitun asian muodossa, jota muut voivat testata. Tämä on erityisen tärkeää julkisissa ja säännellyissä ympäristöissä, joissa tietojen on säilyttävä projekteja pidempään ja päätösten on pysyttävä selitettävinä, vaikka organisaation toimintatavat muuttuvat. Ohjelmistoalan muotivirtaukset vaihtuvat nopeammin kuin säilytysajat, mikä on epäkohteliasta mutta havaittavaa.
Standardit myös vähentävät yhteistyön sankarillisuutta. Kaksi sairaalaa voi jakaa tietomääritelmiä. Kaksi kuntaa voi vertailla palvelujen tuloksia. Tutkijat voivat toistaa aineistoja. Arkistot voivat säilyttää tietoja. Tilintarkastajat voivat tarkastaa jälkiä. Saavutettavuustyökalut voivat lukea sisältöä. Tietoturvatyökalut voivat varmistaa asetuksia. Mikään tästä ei edellytä, että kaikki käyttävät samaa tuotetta. Se on koko asian ydin. Standardointi oikealla tasolla luo monimuotoisuutta sen yläpuolelle, ei yhdenmukaisuutta itseisarvona.
Riskinä on standarditeatteri. Organisaatio väittää tukevansa standardia mutta toteuttaa vain helpon osajoukon. Toimittaja tarjoaa yhteensopivan kuoren, mutta keskeinen semantiikka pysyy yksityisenä. Projekti kirjoittaa profiilin, joka on niin paikallinen, että se kumoaa laajentamansa standardin. Ratkaisu ei ole kyynisyys. Ratkaisu on vaatimustenmukaisuuden testaus, julkiset profiilit, jaetut esimerkit, negatiiviset testit ja hankintakieli, joka erottaa yhteensopivan siitä, joka on vain saanut inspiraationsa. Inspiroituminen on ihanaa arkkitehtuurilehtiin. Se on vähemmän ihanaa tietojen siirrossa.
Hankintalauseke ei riitä
Monet sopimukset sisältävät nykyään kirjauksia avoimuudesta, siirrettävyydestä, yhteentoimivuudesta ja kohtuullisesta avusta. Tämä on hyvä asia, mutta lausekkeet eivät jäsennä tiedostoja. Sopimus voi luoda oikeuden. Se ei yksinään voi luoda käyttökelpoista vientiä, vakaata sanastoa, testisarjaa tai siirtymäpolkua. Juridisen kielen ja teknisten standardien on kohdattava ennen kuin järjestelmä otetaan käyttöön. Muuten sopimuksesta tulee kartta sillalle, jota kukaan ei rakentanut.
Hankinnassa pitäisi siis pyytää näyttöä, ei adjektiiveja. Mitä standardeja tuetaan. Mitä versioita. Mitä profiileja. Mitä vaatimustenmukaisuustestejä. Mitkä työkalut voivat vahvistaa tulosteen. Mitä esimerkkivientejä on saatavilla. Mitkä kohteet on rajattu pois. Miten laajennukset dokumentoidaan. Miten yhteensopivuutta rikkovat muutokset ilmoitetaan. Miten tarkastusjäljet viedään. Miten identiteetti esitetään. Miten tekoälyn tuottamat artefaktit käsitellään. Miten ostaja voi testata tämän ennen allekirjoitusta. Nämä kysymykset säästävät rahaa, koska ne siirtävät kivun hetkeen, jolloin toimittajilla on vielä motivaatio vastata.
Hankinnan pitäisi myös rahoittaa tylsät osat. Standardityö vie aikaa: paikallisten käsitteiden kartoitus, profiilien kirjoittaminen, reunatapausten testaus, skeemojen ylläpito, laajennusten dokumentointi, validaattorien rakentaminen ja hallintaan osallistuminen. Standardien kohteleminen ilmaisena taustamusiikkina on virhe. Kustannus ilmestyy jonnekin. On parempi maksaa siitä nyt kuin löytää se myöhemmin integraatiovelkana, siirtymäpäänsärkynä tai konsulttilaskuna, jonka loppusummaa voi ihailla suoraltaan.
Kaikkeen ei tarvitse vaatia maksimaalista standardointia. Jotkut kokeilut voivat olla väljiä. Jotkut sisäiset työkalut voivat olla paikallisia. Jotkut prototyypit voivat käyttää väliaikaisia formaatteja. Tärkeintä on tietää, milloin työ siirtyy pysyviin tietoihin, julkisiin velvoitteisiin, säänneltyihin prosesseihin, jaettuun infrastruktuuriin tai strategiseen riippuvuuteen. Siinä vaiheessa avoimet lupaukset eivät riitä. Järjestelmä tarvitsee standardeja, jotka voivat kantaa merkityksen, kun alkuperäinen konteksti on jo siirtynyt eteenpäin.
Paikalliset standardit ja globaalit standardit tarvitsevat toisiaan
Globaalien standardien ja paikallisen todellisuuden välillä on väärä vastakkainasettelu. Globaali standardi tuo yhteentoimivuutta ja työkalujen tuen. Paikallinen profiili tuo toimialan tarkkuutta. Toimiva malli on kerroksellinen. Käytä yhteistä pohjaa siellä, missä se on mahdollista. Määrittele paikalliset laajennukset siellä, missä se on tarpeen. Julkaise laajennukset. Testaa vaatimustenmukaisuus. Vältä pohjan merkityksen muuttamista vain siksi, että paikallinen oikotie on kätevä. Oikotiet tuntuvat tehokkailta, kunnes kaikki muut joutuvat kiertämään niitä ikuisesti.
Tämä kerroksellinen lähestymistapa on erityisen tärkeä Euroopassa, jossa lainsäädäntö, kieli, hallinto ja toimialakäytännöt vaihtelevat samalla kun rajat ylittävä digitaalinen työ lisääntyy jatkuvasti. Standardi, joka jättää huomiotta paikalliset oikeudelliset käsitteet, epäonnistuu. Paikallinen järjestelmä, joka jättää huomiotta yhteiset standardit, eristäytyy. Ratkaisu ei ole puhtaus kummallakaan puolella. Ratkaisu on kurinalainen kartoitus: yhteiset tunnisteet, monikieliset sanastot, versioidut profiilit, yhteiset testikiinnikkeet sekä hallintomalli, joka sallii paikalliset erot menettämättä vaihdettavuutta.
AI tuo mukaan uuden kerroksen. Mallien käyttäytyminen voi vaihdella kielen, toimialan ja käyttöympäristön mukaan, mutta näyttöä tästä käyttäytymisestä tulisi kuvata yhteisillä rakenteilla aina kun mahdollista. Arviointitulokset, lähteiden alkuperä, työkalujäljet ja ihmisen tekemät tarkistusmerkinnät eivät saisi muuttua yksityisiksi murteiksi. Jos jokainen organisaatio kuvaa AI-näyttöä eri tavalla, valvonnasta tulee käsityöläisyyttä. Käsityöläisvalvonta kuulostaa viehättävältä, kunnes viranomaisen on verrattava viittäkymmentä järjestelmää ennen lounasta.
Opetus
Avoimet lupaukset ovat hyödyllisiä, mutta ne eivät riitä. Ne kertovat ostajille, mitä toimittaja aikoo tai sallii tietyllä hetkellä. Avoimet standardit kertovat toisistaan riippumattomille järjestelmille, miten vaihtaa merkityksiä, säilyttää näyttöä, validoida käyttäytymistä ja selviytyä muutoksista. Toinen on julkilausuma. Toinen on infrastruktuuria. Vakavat digitaaliset järjestelmät tarvitsevat infrastruktuuria enemmän kuin rauhoittavia adjektiiveja.
Tämä korostuu, kun AI tulee osaksi tavallisia työnkulkuja. AI tuottaa johdettua näyttöä, päätöksiä, yhteenvetoja, reittejä, pisteytyksiä ja jälkiä, joita on voitava tarkastaa, korjata, siirtää ja joskus haastaa vuosia myöhemmin. Ilman standardeja jokaisesta AI-käyttöönotosta tulee oma yksityinen vastuullisuuden murteensa. Se voi olla kätevää käyttöönoton hetkellä. Se on vihamielistä auditoinnille, siirrettävyydelle, kilpailulle, säilytykselle ja yleiselle luottamukselle.
Käytännön testi on yksinkertainen. Jos järjestelmä väittää olevansa avoin, kysy, mitä toinen riippumaton järjestelmä voi tehdä sen tuotoksella. Voiko se vahvistaa sen. Voiko se säilyttää merkityksen. Voiko se rekonstruoida todisteet. Voiko se panna oikeudet täytäntöön. Voiko se selviytyä skeeman muutoksesta. Voiko se tukea poistumista. Jos vastaus riippuu enimmäkseen hyvästä tahdosta, kokouksista ja räätälöidystä työstä, organisaatiolla on avoin lupaus. Jos vastaus riippuu jaetuista, testatuista ja ylläpidetyistä säännöistä, sillä on avoimen standardin alku. Tämä ero ratkaisee, onko avoimuutta vielä olemassa silloin, kun sitä lopulta tarvitaan.