Verstaspäiväkirja on jatkuva sarja siitä, miten työkalut oikeasti syntyvät — omissa ja asiakkaiden projekteissa, ideasta erehdyksen kautta iteraatioon. Tämä on osa 2; osa 1 kertoi paikallisesta tekoälystä ja RAG:sta.

Osa 1 päättyi kysymykseen, jonka lakaisin sivuun: paikallinen tekoäly pitää datan kotona, mutta se vaatii laitteistolta tehoa. Entä jos tehoa ei ole — tai jos sitä tarvitaan enemmän kuin oma kone antaa? Tehoa voi ostaa. Mutta samalla kun ostat tehoa, siirrät jotain paljon tärkeämpää kuin laskentaa.

Miksi paikallinen malli syö tehoa

Kielimallin ajaminen — inferenssi — on raskasta puuhaa. Malli koostuu miljardeista parametreista, ja jotta vastaukset syntyvät järkevässä ajassa, noiden parametrien pitää mahtua näytönohjaimen muistiin (VRAM). Tämä on se pullonkaula, joka ratkaisee enemmän kuin mikään muu: ei niinkään prosessorin nopeus, vaan se, mahtuuko malli muistiin vai ei.

Kokoa voi pienentää kvantisoinnilla — pakkaamalla parametrit karkeampaan tarkkuuteen — jolloin isompikin malli mahtuu vaatimattomampaan korttiin pienellä laatuhinnalla. Käytännössä maltillinen, kvantisoitu malli ja kohtuullinen kuluttajanäytönohjain riittävät yllättävän pitkälle: yhden käyttäjän dokumenttihaku ja RAG pyörivät tällä hyvin.

Kolme asiaa työntää kuitenkin nopeasti oman koneen katon vastaan: selvästi isompi ja tarkempi malli, iso ja jatkuvasti kasvava datamäärä (vektorointi on sekin laskentaa), tai monta yhtäaikaista käyttäjää. Yhdelle ihmiselle riittävä kone tukehtuu, kun kymmenen kysyy samaan aikaan. Silloin edessä on valinta: tinkiä mallista — tai ostaa tehoa muualta.

Kolme tapaa ostaa tehoa

Reittejä on karkeasti kolme, ja ne eroavat ennen kaikkea siinä, kuinka paljon dataa ja vastuuta ne siirtävät ulos.

1. Vuokrattu GPU-palvelin. Vuokraat pelkkää laskentaa — virtuaalipalvelimen tai GPU-instanssin — ja ajat siellä omaa malliasi ja RAG:iasi. Data menee palveluntarjoajan konesaliin, mutta ohjelmisto, mallit ja logiikka ovat sinun. Kontrolli on suuri: sinä päätät mitä ajetaan ja miten data käsitellään. Vastuu on jaettu — sinä ympäristöstäsi, he raudasta.

2. Hallittu inferenssi-API. Käytät valmista mallia palveluna: lähetät kysymyksen rajapintaan, saat vastauksen. Helpoin ja usein halvin tapa, mutta datasi kulkee kolmannen osapuolen mallin läpi. Tässä luetaan erityisen tarkkaan, mitä palveluntarjoaja tekee syötteilläsi — säilyttääkö niitä, lokittaako, käyttääkö mallin kouluttamiseen. Ero „emme säilytä” ja „säilytämme 30 päivää väärinkäytösten varalta” välillä on herkän datan kohdalla ratkaiseva.

3. Privaatti pilvi. Oma eristetty ympäristö pilvessä — mieluiten EU-alueella — jossa ajat malliasi sopimuksen alla jakamatta mallia tai laitteistoa muiden kanssa. Kallein vaihtoehto, mutta lähimpänä „oma kone” -kontrollia silloin, kun mittakaava kasvaa isoksi eikä pöytäkone enää riitä.

Käytännössä paras ratkaisu on usein hybridi: herkin data ja arkikäyttö pyörivät paikallisesti omalla koneella, ja ostettua tehoa käytetään vain raskaisiin, harvempiin ajoihin — esimerkiksi ison aineiston kertavektorointiin — ja vain sellaisella datalla, joka kestää lähteä ulos. Näin maksat tehosta vain kun tarvitset sitä, etkä altista arkaa dataa turhaan.

Kun data lähtee talosta, vastuu siirtyy sopimukseen

Osa 1:n koko idea oli, että data ei lähde koneelta. Heti kun ostat tehoa ulkoa, data lähtee — ja tietoturva lakkaa olemasta tekninen asetus omalla koneella ja muuttuu sopimusasiaksi.

Se ei tarkoita, että kontrolli katoaa. Se tarkoittaa, että kontrolli siirtyy koneelta sopimuspöydälle. Tämä on tärkeä ero, koska moni luulee pilveen siirtymisen tarkoittavan vastuusta luopumista. Se on päinvastoin: vastuu datasta säilyy sinulla, mutta keinot hallita sitä ovat nyt sopimusehtoja, eivät palomuurin sääntöjä.

Mitä DPA:sta pitää lukea

GDPR:n artikla 28 edellyttää tietojenkäsittelysopimusta (DPA) aina, kun ulkopuolinen käsittelee henkilötietoa puolestasi. Ja vaikka henkilötietoa ei olisikaan, samat rivit ratkaisevat liikesalaisuuksien kohtalon. Viisi kohtaa, jotka luen aina ensimmäisenä:

Datan sijainti — missä maantieteellisesti data lepää ja käsitellään (EU/ETA vai muualla). Alihankkijat — keitä sub-processoreita palveluntarjoaja käyttää ja miten niiden vaihdoksista ilmoitetaan. Salaus — levossa ja siirrossa, ja kuka hallitsee avaimia. Poisto — saatko datasi ulos ja tuhotuksi sopimuksen päättyessä, ja millä takuulla. Käyttö — usein tärkein rivi: käyttääkö palveluntarjoaja syötteitäsi omiin tarkoituksiinsa, kuten mallin kouluttamiseen. Käytettävyys ja palvelutaso (SLA) ovat oma lukunsa, mutta tietosuojan kannalta juuri nämä viisi ratkaisevat.

Missä data lepää — ja kenen laki siihen ylettyy

Sijainti ei ole vain tekninen yksityiskohta. Se määrää, kenen lainsäädännön piiriin datasi joutuu. Yhdysvaltalaisen palveluntarjoajan hallussa oleva data voi kuulua Yhdysvaltain lainsäädännön (kuten CLOUD Actin) ulottuville, vaikka palvelin sijaitsisi Euroopassa — ja EU:n ja Yhdysvaltain väliset tiedonsiirrot ovat olleet oikeudellisesti liikkuvaa maaperää aina Schrems-ratkaisuista lähtien.

Käytännön johtopäätös pk-toimijalle on yksinkertainen: jos data on aidosti herkkää, EU-alueella toimiva, eurooppalaisen oikeuden piirissä oleva palvelu on turvallisempi lähtökohta kuin halvempi vaihtoehto, jonka lainkäyttöalue on epäselvä. Tämä on juuri se kohta, jossa paikallinen ratkaisu (osa 1) on ylivoimainen: kun data ei lähde talosta, kysymys lainkäyttöalueesta ei edes synny.

Pilveen siirtyy laskenta, ei vastuu. Vastuu jää sinulle — ja ainoa tapa hallita sitä on sopimus, jonka olet oikeasti lukenut.

NIS2 tekee toimittajastasi sinun vastuusi

Tässä moni pk-yritys yllättyy. NIS2 — ja huoltovarmuusajattelu laajemminkin — ei katso vain sinun omaa tietoturvaasi. Se katsoo toimitusketjuasi. Kun ostat laskentaa tai tekoälypalvelua, tuosta toimittajasta tulee osa sinun turvallisuuttasi, ja sinun on kyettävä osoittamaan, että olet arvioinut sen.

Käytännössä se tarkoittaa muutamaa konkreettista asiaa: toimittajan due diligence ennen sopimusta, kirjatut turvallisuusvaatimukset sopimukseen, sovittu menettely poikkeamien ilmoittamiseen, ja exit-suunnitelma sen varalle että yhteistyö loppuu tai toimittaja kaatuu. Tehon ostaminen ei ulkoista riskiä — se lisää toimitusketjuusi lenkin, jota sinun on hallittava siinä missä omaakin ympäristöäsi. Ketju on täsmälleen heikoimman lenkkinsä veroinen.

Miten valita: datan luokka ratkaisee

Yksinkertainen kehys päätöksen tueksi: älä kysy ensimmäisenä „mikä on halvin”, kysy „mitä dataa tähän menee”. Kun data on luokiteltu, oikea ratkaisu putoaa lähes itsestään.

Julkinen tai matalan herkkyyden data (yleinen ohjeistus, julkiset aineistot) — hallittu API on täysin riittävä, halpa ja vaivaton. Luottamuksellinen data (liikesalaisuudet, sopimukset, hinnoittelu) — EU-privaatti pilvi tai vuokrattu palvelin, aina DPA:n kanssa. Henkilötieto — pidä paikallisena; jos se ei muuten onnistu, tiukka DPA ja tiedon minimointi. Ja kuten osassa 1 totesin: henkilötieto rajataan mieluiten kokonaan pois koko järjestelmästä jo kartoitusvaiheessa.

Näin päättäjän kehys on selvä: paikallinen kun voit, ostettu teho kun täytyy, aina sopimus takana, ja datan luokka valinnan ohjaajana. Mutta on olemassa iso joukko organisaatioita, joiden data on jo valmiiksi pilvessä — Microsoft 365:ssä. Silloin kysymys ei ole „viedäänkö pilveen” vaan „kuka hallitsee pääsyä”. Siitä seuraavassa osassa.

Osa 3: SharePoint, Graph API ja Intune — kun tieto asuu jo pilvessä, turvaraja siirtyy identiteettiin.