Kuvittele, että kolme viikkoa ennen julkaisua sinulle kerrotaan, että tekoälyjärjestelmä, jota tiimisi on rakentanut puoli vuotta, saattaa olla laiton suurimmalla markkina-alueellanne. Malli toimii. Tuote on valmis. Monisivuinen juridinen tarkistuslista kehottaa kuitenkin laittamaan projektin jäihin.
Näin vastuullisen tekoälyn vaatimustenmukaisuus yleensä hoidetaan ja järjestys on juuri väärin päin. Useimmissa organisaatioissa se on prosessin viimeinen osa: juridisella kielellä kirjoitettu staattinen kyselylomake, joka ojennetaan insinööreille vaiheessa, jossa systeemisen riskin korjaaminen on kallista. EU AI Actin myötä myöhään havaittu virhe ei ole enää vain hidas korjattava, vaan se voi tarkoittaa miljoonien vastuita.
Voisiko asian tehdä toisella tapaa?
Ongelma ei ole säännöt vaan se, missä vaiheessa ne kohtaat
Kolme asiaa tekee perinteisestä lähestymistavasta raskaan:
- Se on reaktiivista. Useimmat työkalut tarkistavat järjestelmän vasta ennen käyttöönottoa tai sen jälkeen, joten ongelmat paljastuvat silloin, kun niiden korjaaminen maksaa eniten. Suunnitteluvaiheessa havaittu virhe on usein kertaluokkaa halvempi korjata kuin julkaisussa havaittu.
- Se aiheuttaa tarkistuslistaväsymystä. Juridiset viitekehykset ovat pitkiä ja juristeille kirjoitettuja. Kehittäjät täyttävät ne nopeasti ymmärtämättä aina, mitä oikeastaan vakuuttavat. Paperityö tulee tehdyksi, mutta riski jää löytymättä.
- Se on siiloutunutta. Juridiikka, tuote ja insinöörityö toimivat eri työkaluissa ja puhuvat eri kieltä, joten arviointi ei koskaan kohtaa niitä päätöksiä, joita koodissa oikeasti tehdään.
Lopputulos on molempien maailmojen huonoin yhdistelmä eli raskas prosessi ja heikko suoja.
Siirrä arviointi aikaisemmaksi, osaksi työnkulkua
Vaihtoehto on helppo sanoa, mutta vaikea toteuttaa. Vastuullinen tekoäly siirretään loppuvaiheen tarkistuslistasta reaaliaikaiseksi suunnitteluvaiheen ohjaukseksi, joka on upotettu sinne, missä insinöörit jo työskentelevät. Siis IDE:hen ja MLOps-putkeen, ei erilliseen vaatimustenmukaisuusportaaliin.
Eräässä tuoreessa yhteistyöhankkeessa autoimme rakentamaan juuri tällaisen ratkaisun: hallinta-avustajan, joka toimii kehitystyönkulun sisällä ja tekee kaksi asiaa.
Ensinnäkin se kohdentaa kysymykset roolin ja projektivaiheen mukaan. Yhden valtavan staattisen listan sijaan se esittää lyhyen joukon tilannekohtaisia kysymyksiä: kehittäjälle eri kysymykset kuin juristille tai tuotepäällikölle ja projektin alussa eri kysymykset kuin lähellä julkaisua. Vastaat siihen, mikä on sinulle olennaista, silloin kun se on olennaista.
Toiseksi se luonnostelee vaikutustenarvioinnin puolestasi. Varsinaisiin lähdesäännöksiin ankkuroitu kielimalli (EU AI Act, YK:n kestävän kehityksen tavoitteet ja ihmisoikeuksien yleismaailmallisen julistuksen artiklat) lukee järjestelmäkuvauksen, päättelee vaihe vaiheelta, missä riskit ovat, luokittelee käyttötapauksen asteikolla hyväksyttävästä korkean riskin kautta kiellettyyn ja ehdottaa konkreettisia hallintakeinoja. Ihminen pysyy ohjaksissa, mutta tyhjän sivun ongelma katoaa.
Kehystimme koko asian uudelleen: kyse ei ole "vaatimustenmukaisuustuotteesta" vaan työkalusta, jonka kehittäjät ottavat mielellään käyttöön. Älykästä suunnittelua ja kevyttä vaatimustenmukaisuutta. Ohjausta, joka suojaa innovaatiota sen sijaan, että hidastaisi sitä.
Mitä validointi osoitti
Validoinnin luvut olivat parempia kuin odotimme:
- 95 %:n tarkkuus käyttötapausten riskiluokittelussa EU AI Actin mukaan ihmisasiantuntijoihin verrattuna.
- 30 % vähemmän aikaa vaikutusraportin valmisteluun automaattisen esitäytön ansiosta.
- 67 tunnin säästö yhdessä projektissa verrattuna käsin tehtyyn tarkistuslistatyöhön.
- 138 simuloidusta käyttötapauksesta järjestelmä tunnisti 16 korkean riskin sovellusta, jotka ihmistiimit olivat jättäneet kokonaan huomaamatta.
“Hyvin toteutettu automatisointi ei siis vain nopeuta vaatimustenmukaisuustyötä. Se tekee siitä myös perusteellisempaa kuin korvaamansa käsityö.
Tämä viimeinen kohta jäi mieleemme. Kone ei väsy eikä lue huolimattomasti ja se tarkastelee sadannenkin käyttötapauksen yhtä huolellisesti kuin ensimmäisen.
Varsinainen oppi
Vastuullisen tekoälyn ei tarvitse olla se, mikä hidastaa. Kitka syntyy lähes aina siitä, milloin ja miten arviointi tehdään, ei säännöistä itsestään. Kun arviointi tuodaan aikaisemmaksi, viedään työnkulkuun ja ankkuroidaan oikeisiin viitekehyksiin, vaatimustenmukaisuus lakkaa olemasta julkaisun jarru ja muuttuu osaksi hyvää rakentamista.
EU AI Act tekee tästä väistämätöntä. Ne yritykset, jotka ottavat sen mukaan jo suunnittelupöydälle, julkaisevat nopeammin ja turvallisemmin kuin ne, joille se tulee vastaan vasta julkaisun kynnyksellä.
Missä kohtaa kehitysprosessianne vastuullinen tekoäly on tänään ja mikä muuttuisi, jos se siirtyisi alkuun?
