GDPR-kysymys tekoälyagenteissa ei ole "onko sallittua", vaan "minkä artiklan mukaan". Asiakassähköposteja lukeva tekoälyagentti käsittelee henkilötietoja. Hakemuksen automaattisesti hylkäävä agentti tekee automaattista päätöksentekoa. Toimintansa 18 kuukaudeksi lokittava agentti liittyy säilytysajan kysymykseen. GDPR:llä on omat sääntönsä jokaiseen. Käymme tässä artikkelissa läpi ne viisi artiklaa, joilla on oikeasti merkitystä eurooppalaisella datalla toimiville agenteille: miltä vaatimustenmukainen arkkitehtuuri näyttää konkreettisesti ja mitkä virheet vetävät tietosuojaviranomaisen ovelle.
Mikä lasketaan henkilötiedoksi, kun agentti on mukana
GDPR:n artikla 4 määrittelee henkilötiedon laajasti: tieto, joka koskee tunnistettua tai tunnistettavissa olevaa luonnollista henkilöä. Agentit koskettavat tyypillisesti monta tällaista kategoriaa yhtä aikaa: sähköpostien sisältöjä, IP-lokeja, lomakkeiden tietoja, asiakaspalvelun keskusteluja ja CRM-tietueita. Pseudonymisoitu data on yhä soveltamisalassa (vain täysin anonymisoitu data on ulkopuolella). Kun agenttisi käsittelee tätä dataa, organisaatiosi on joko rekisterinpitäjä tai käsittelijä. Erottelu vaikuttaa sopimusvastuisiin asiakkaille ja vastuuseen, jonka otat suhteessa alikäsittelijöihin, kuten LLM-toimittajaan. Tämä kartoitus tehdään ensimmäiseksi, ennen muuta suunnittelua.
Artiklat 5 ja 6: oikeusperuste ja minimointi
Artikla 5 listaa käsittelyn periaatteet: lainmukaisuus, käyttötarkoitussidonnaisuus, minimointi, täsmällisyys, säilytyksen rajoitus, eheys ja luottamuksellisuus sekä osoitusvelvollisuus. Agenttikohtaisesti tämä tarkoittaa, että valitset artiklan 6 mukaisen oikeusperusteen (yleensä sopimus tai oikeutettu etu liiketoimintaoperaatioille), et anna agentille pääsyä laajempaan dataan kuin tehtävä edellyttää ja dokumentoit perustelun valinnallesi. Juuri dokumentointivaihe jää useimmilta tiimeiltä tekemättä. Osoitusvelvollisuuden nojalla sinun tulee pystyä todistamaan päätös, ei vain tehdä sitä. Esimerkki: sähköpostien lajitteluagentti tarvitsee työhönsä vain lähettäjän ja otsikon, ei viestin runkoa. Rungon antaminen silti on minimoinnin vastaista ja heikentää asemaasi, jos viranomainen tarkastaa käsittelyn hallinnon dokumentaation.
Artikla 22: automaattiset päätökset, jotka osuvat asiakkaaseen
Tämä on artikla, jonka olemassaolosta useimmat yrittäjät eivät tiedä. Rekisteröidyllä on oikeus olla joutumatta sellaisen päätöksen kohteeksi, joka perustuu pelkästään automaattiseen käsittelyyn, jos päätöksellä on oikeusvaikutuksia tai se vaikuttaa rekisteröityyn vastaavalla tavalla merkittävästi. Luottopäätökset, työhakemusten hylkäykset, vakuutusten hinnoittelutasot ja palvelun saatavuuteen vaikuttava personointi kuuluvat kaikki soveltamisalaan. Poikkeukset ovat kapeat: käsittely on välttämätöntä sopimuksen tekemiseksi tai täyttämiseksi, laki valtuuttaa käsittelyn tai rekisteröity on antanut nimenomaisen suostumuksen. Poikkeuksenkin alla yksilöllä on oikeus saada ihmisen tekemä uudelleenkäsittely, esittää kantansa ja kiistää päätös. Käytännön ratkaisu on human-in-the-loop-tarkastus kaikissa agentin tuotoksissa, jotka koskettavat palvelun käyttöoikeutta, hinnoittelua tai yksilön mahdollisuuksia. Tämä prosessi rakennetaan ennen agentin käyttöönottoa, ei ensimmäisen valituksen jälkeen.
Artiklat 30 ja 32: dokumentointi ja tietoturva
Artikla 30 vaatii käsittelytoimien luettelon (RoPA). Jokaisesta käsittelytoimesta, myös jokaisesta agentista, dokumentoidaan käyttötarkoitus, datakategoriat, vastaanottajat, säilytysajat ja turvatoimet. Artikla 32 vaatii käsittelyn riskiin nähden asianmukaisia teknisiä ja organisatorisia toimenpiteitä: salaus, pääsynvalvonta, poikkeamien havaitseminen ja auditointijälki. Agentit sopivat tähän hyvin, koska jokainen kutsu on luonnostaan lokiteltavissa: syöte, mallin tuotos, tehty toimenpide, kesto ja lopputulos. ISO 27001 -standardin mukaisuus kattaa suurimman osan artiklan 32 pinta-alasta, joskaan sertifikaatti yksin ei ole automaattinen GDPR-läpäisy (lisää aiheesta alla olevissa usein kysytyissä kysymyksissä).
Luku V: miksi palveluntarjoajan sijainti ratkaisee puolet työstä
Schrems II -päätös (2020) kumosi Privacy Shieldin. Henkilötietojen siirrot Yhdysvaltoihin ovat yhä mahdollisia EU:n mallisopimuslausekkeilla ja täydentävien suojatoimien arvioinnilla, mutta dokumentointi- ja riskityökuorma on todellinen. Siisteintä on käsitellä kaikki EU:n alueella. Jos agenttisi lähettää asiakasdataa yhdysvaltalaiselle LLM-toimittajalle, teet luvun V mukaisen siirron ja joudut dokumentoimaan, perustelemaan ja arvioimaan sen uudelleen aina, kun tietosuojan riittävyyspäätös muuttuu. Paikallinen malli EU-infrastruktuurissa (esimerkiksi Ollama Hetznerillä) poistaa siirtokysymyksen kokonaan valtaosassa pyyntöjä. Tuotantomalleja voi käyttää vaikeissa tapauksissa, ja jokainen tällainen kutsu muuttuu erilliseksi, lokitetuksi ja perustelluksi tapahtumaksi oletusmallin sijaan.
Miltä vaatimustenmukainen arkkitehtuuri näyttää konkreettisesti
Malli, jota itse ajamme, näyttää tältä: EU-vain-hostaus Hetzner Cloudilla Suomessa ja Saksassa, paikallinen malli hoitamassa valtaosan pyynnöistä, tuotantomallin kutsut vain niihin tapauksiin, joihin paikallinen malli ei riitä (jokainen niistä lokitetaan luvun V siirtotapahtumana ja perustellaan), asiakaskohtainen auditointijälki dokumentoidulla säilytysajalla, automaattinen poisto säilytysikkunan päätyttyä, ISO 27001 -linjaiset kontrollit ja evästeetön analytiikka, joka poistaa erillisen suostumustaakan kävijädatasta agentin käsittelytaakan lisäksi. Jokainen ketjun lenkki on puolustettavissa artiklan 32 toimenpide. Sama arkkitehtuuri toimitetaan osana tekoälyagenttipalveluamme, jotta asiakkaan ei tarvitse keksiä vaatimustenmukaisuuden kokonaisuutta uudelleen.
Usein kysyttyjä kysymyksiä
K: Tarvitsemmeko DPIA:n, kun otamme tekoälyagentin käyttöön? V: Artikla 35 edellyttää DPIA:ta silloin, kun käsittely todennäköisesti aiheuttaa korkean riskin yksilöiden oikeuksille. Automaattinen päätöksenteko, jolla on oikeudellisia tai vastaavia merkittäviä vaikutuksia, järjestelmällinen laajamittainen valvonta ja erityisten henkilötietoryhmien käsittely laukaisevat velvollisuuden. Sähköpostien lajitteluagentti, joka ei tee käyttäjään kohdistuvia päätöksiä, ei yleensä laukaise. Luottopisteytykseen liittyvä agentti laukaisee. Epäselvässä tilanteessa dokumentoi perustelu sille, miksi DPIA:ta ei tehty: dokumentti on itsessään artiklan 24 osoitusvelvollisuuden täyttävä artefakti.
K: Voimmeko käyttää ChatGPT:tä asiakastietojen kanssa? V: Voitte, jos teillä on voimassa oleva tietojenkäsittelysopimus toimittajan kanssa, artiklan 6 mukainen oikeusperuste ja luvun V mukainen siirto dokumentoituna. Useimmat eurooppalaiset yritykset päätyvät siihen, että paperityö ja täydentävien suojatoimien arviointi on raskaampaa kuin vaihtoehto: paikallinen malli rutiinikäsittelyyn ja tuotantomalli vain niihin tapauksiin, joihin paikallinen ei riitä. Hybridiarkkitehtuuri välttää suurimman osan siirtodokumentaatiosta ja pitää asiakasdatan oletusarvoisesti EU:ssa.
K: Mitä tapahtuu, jos agentti tekee virheellisen automaattisen päätöksen? V: Artiklan 22 nojalla yksilöllä on oikeus ihmisen tekemään uudelleenkäsittelyyn merkittävien automaattisten päätösten osalta. Tarvitaan määritelty prosessi: yksilö pyytää uudelleenkäsittelyä, pätevä henkilö tarkastelee tapauksen, päätös harkitaan tai vahvistetaan, ja yksilölle vastataan perusteluineen. Jos agentti vaikuttaa luoton, työpaikan tai palvelun saatavuuteen, prosessi rakennetaan ennen käyttöönottoa, ei ensimmäisen valituksen jälkeen. Prosessin puuttuminen on yksi viime aikojen sanktiopäätösten toistuvimmista kuvioista.
K: Kuinka pitkään agentin lokeja voi säilyttää? V: Vain niin pitkään kuin on dokumentoitua käyttötarkoitusta varten tarpeellista. Tietoturvaloukkausten tutkintaa varten tyypillinen säilytysaika on 12 kuukautta. Vianjäljityslokit riittävät usein 30 vuorokaudella. Asiakaskohtaiset mallin tuotoslokit seuraavat tyypillisesti asiakastiedon säilytysikkunaa. Olennaista on, että säilytysaika on dokumentoitu käsittelytoimien luetteloon ja poisto tapahtuu automaattisesti ikkunan umpeutuessa, eikä dataa säilytetä "varmuuden vuoksi" loputtomiin.
K: Riittääkö ISO 27001 GDPR:n artiklan 32 vaatimusten täyttämiseen? V: ISO 27001 kattaa suurimman osan artiklan 32 odottamista teknisistä ja organisatorisista toimenpiteistä, mutta se ei ole automaattinen läpäisy. Artikla 32 vaatii toimenpiteitä, jotka ovat oikeasuhtaisia tietyn käsittelyn riskiin nähden. Sertifikaatti osoittaa, että hallintajärjestelmä on olemassa, mikä vie pitkälle. Käsittelykohtainen dokumentointi, rekisteröidyn pyyntöjen käsittelyprosessit ja tietoturvaloukkausten ilmoitusmenetelmät tarvitsevat yhä erillisen huomion. ISO 27001 ei sertifioi niitä suoraan.
Jos olet vasta aloittamassa, ennen kuin vaatimustenmukaisuuskysymys tulee ajankohtaiseksi, tekoälyagenttien perusopas käy läpi perusteet ensin. Kun olet valmis suunnittelemaan GDPR-yhteensopivan toteutuksen omaan toimintaasi, varaa esittelykeskustelu ja käymme sen kanssasi läpi.
---
*Kirjoittanut Leap Laboratoryn tiimi. Tämä ei ole oikeudellista neuvontaa. Kysy GDPR-asiantuntijalta päätöksistä, jotka koskevat tuotantodataa. Päivitetty huhtikuussa 2026.*