Chatbot-tarjoajien arviointi: DPA, alikäsittelijät ja tietonsiirrot kolmansiin maihin

Chatbot-tarjoajalla voi olla vakuuttava demo, EU-alueella sijaitseva palvelin ja valmis tietojenkäsittelysopimus (DPA) – ja silti kriittisiä kysymyksiä jää avoimeksi. Tiedot eivät nimittäin liiku vain näkyvässä chatbotissa. Usein palveluun osallistuu mallien rajapintoja (API), hosting-palveluita, vektoritietokantoja, virheenanalyysityökaluja, tukityökaluja, sähköpostipalveluita ja varmuuskopiointia. Verkkosivuston ylläpitäjälle ratkaisevaa onkin todennettavissa oleva käsittelyketju, ei myyntisivun tietosuojaiskulause.

Tämä tarkistuslista auttaa strukturoidussa toimittaja-arvioinnissa ennen hankintaa ja julkaisua. Se toimii käytännön ohjeena, ei oikeudellisena neuvontana. Roolit, oikeusperusteet, tiedottamisvelvoitteet ja siirtomekanismit on tarkistettava kussakin käyttötapauksessa erikseen. Korkean riskin, erityisten tietoryhmien tai avoimien sopimuskysymysten kohdalla tulee konsultoida tietosuojavastaavaa tai pätevää lakimiestä.

Ymmärrä ensin tietovirta, arvioi vasta sitten sopimus

Keskeinen kysymys ei ole vain "Missä palvelin sijaitsee?", vaan: Mitä henkilötietoja päätyy kenelle oikeushenkilölle, milloin, mistä syystä ja kuinka pitkäksi aikaa? Kävijä voi syöttää chattiin nimen, sähköpostiosoitteen, asiakasnumeron tai vapaamuotoista tekstiä. Lisäksi syntyy IP-osoitteita, aikaleimoja, laitetietoja, istuntotunnisteita, keskusteluhistorioita, arvioita ja teknisiä lokeja. Myös väitetysti anonyymistä keskustelusta voi muodostua henkilötieto useiden määritteiden yhdistämisen kautta.

Piirrä siksi yksinkertainen tietovirtakaavio ennen sopimuksen tarkistamista. Sen tulisi sisältää vähintään selainwidget, chatbot-alusta, tietopohja, mallintarjoaja, analyysi- ja virhepalvelut, tukinäkymät, varmuuskopiot sekä poistoreitit. Jokaisesta vaiheesta kirjataan ylös ylläpitäjä, maa, käyttötarkoitus, tietoryhmät, säilytysaika ja mahdolliset etäyhteydet. Esimerkiksi ilmoitus "EU-hostingista" ei kerro sitä, pääseekö Euroopan talousalueen ulkopuolella sijaitseva tukitiimi käsiksi tuotannon lokeihin.

Määritä tietosuojaroolit käyttötarkoituksen mukaan

Se, onko tarjoaja henkilötietojen käsittelijä vai yksittäisissä tarkoituksissa itse rekisterinpitäjä, määräytyy tosiasiallisen toiminnan perusteella. Euroopan tietosuojaneuvoston ohjeet 07/2020 selventävät tätä rajausta. Tarjoaja voi esimerkiksi käsitellä keskustelutietoja dokumentoitujen ohjeiden mukaisesti, mutta katsoa toimivansa eri roolissa omiin turvallisuus-, laskutus- tai tuotekehitystarkoituksiinsa. Varmista, että jokainen käyttötarkoitus, siihen liittyvä rooli ja oikeusperuste on määritelty nimenomaisesti. DPA ei kata automaattisesti palveluntarjoajan omia, itsenäisiä käyttötarkoituksia.

Tarkista DPA: Pakollisten sisältöjen on vastattava todellista palvelua

GDPR:n 28 artikla edellyttää, että rekisterinpitäjät käyttävät vain sellaisia käsittelijöitä, jotka antavat riittävät takeita sopivien teknisten ja organisatoristen suojatoimien toteuttamisesta. Sopimuksessa on määriteltävä muun muassa käsittelyn kohde ja kesto, luonne ja tarkoitus, tietotyypit, rekisteröityjen ryhmät sekä rekisterinpitäjän oikeudet ja velvollisuudet. Lisäksi tarvitaan ehdot dokumentoiduista ohjeista, salassapidosta, turvallisuudesta, avunannosta rekisteröityjen oikeuksien toteuttamisessa, tietojen poistamisesta tai palauttamisesta sekä auditointeihin liittyvästä tiedonsaannista ja yhteistyöstä.

Älä vertaa DPA-sopimusta vain mallilistaan, vaan peilaa sitä tietovirtakaavioosi ja todelliseen tilaamaasi palvelupakettiin. Hyvä sopimus määrittelee selkeästi chat-toiminnan, tietopohjan kouluttamisen tai indeksoinnin, lokituksen, tukiyhteydet ja valinnaiset ominaisuudet. Epäselvät yleisluontoiset ilmaukset, kuten "palvelun parantaminen", on purettava konkreettisiin tietoihin, tarkoituksiin, valintamahdollisuuksiin ja rooleihin.

• Ohjeistus: Onko selvää, että sisältöjä ja metatietoja käsitellään vain asiakkaan dokumentoituihin tarkoituksiin? Mikä määritystoimenpide tulkitaan ohjeeksi?
• Käyttö malleihin: Käytetäänkö kehotteita (prompts), vastauksia tai ladattuja sisältöjä yleiseen mallien kouluttamiseen tai tuotekehitykseen? Jos ei, tämän tulee olla sopimuksellisesti ja teknisesti todennettavissa; ja jos kyllä, rooli ja oikeusperuste on arvioitava erikseen.
• Poistaminen: Onko keskusteluhistorioille, lokeille, vektori-indekseille, varmuuskopioille ja tukikopioille määritelty konkreettiset säilytysajat? Mitä tapahtuu sopimuksen päättyessä?
• Turvallisuus: Onko pääsynhallinta, asiakkaiden tietojen erottelu, salaus, lokitus, haavoittuvuuksien hallinta ja vaaratilanneprosessit kuvattu riittävän tarkasti?
• Tuki ja avunanto: Sääteleekö DPA käytännön tasolla tietojen vientiä, oikaisua, poistamista, tarkastusoikeutta, tietoturvaloukkauksia ja tarvittaessa tietosuojan vaikutustenarviointia (DPIA)?
• Todisteet: Ovatko auditointiraportit, sertifikaatit tai muut luotettavat todisteet saatavilla, ja koskevatko ne täsmälleen käytettyjä palveluita ja sijainteja?

Sertifikaatit ja arviointiraportit antavat tärkeitä viitteitä, mutta ne eivät korvaa yksittäisen käsittelytapahtuman arviointia eivätkä sopivia sopimuslausekkeita. Myös standardimuotoinen DPA on vain niin hyvä kuin sen täytetyt liitteet ja vastaavuus teknisen todellisuuden kanssa.

Alikäsittelijät: Hallitse nimiä, tehtäviä ja muutoksia

GDPR:n 28 artiklan 2 kohdan mukaan henkilötietojen käsittelijä ei saa käyttää toisen käsittelijän eli alikäsittelijän palveluja ilman rekisterinpitäjän etukäteen antamaa kirjallista erityistä tai yleistä lupaa. Yleisen luvan kohdalla käsittelijän on tiedotettava kaikista suunnitelluista muutoksista ja annettava mahdollisuus vastustaa niitä. Euroopan komission vakiolausekkeita koskevat kysymykset ja vastaukset vahvistavat myös, että pelkät kategoriakuvaukset eivät riitä: yksittäiset alikäsittelijät on nimettävä.

Pyydä ajantasainen, vietävissä oleva lista, josta käy ilmi virallinen nimi, maa, konkreettinen palvelu ja käsiteltävät tiedot. Tarkista lisäksi, onko yritys vain sopimuskumppani vai käsitteleekö se tietoja tosiasiallisesti useissa eri sijainneissa. Erityisen olennaisia ovat malli- ja embedding-tarjoajat, pilvipalvelut, tietokannat, CDN-verkot, monitorointi, virheanalyysi, tuki, sähköposti ja varmuuskopiointi. Jokaisesta merkinnästä on voitava päätellä, tallennetaanko tietoja, siirretäänkö niitä vain läpi vai voiko henkilöstö katsella niitä.

Muutosprosessi kuuluu myös arviointiin: Miten asiakkaille ilmoitetaan, kuinka pitkä ennakkoilmoitusaika annetaan ja mitä tapahtuu perustellun vastustuksen yhteydessä? Sähköposti muutospäivänä ilman teknistä tai sopimuksellista reaktiomahdollisuutta on arvoton. Selvitä, onko vaihtoehtoinen konfiguraatio, toiminnon deaktivointi tai viime kädessä hallittu sopimuksen päättäminen ja tietojen vienti mahdollista. Jatkoalikäsittelijöille on siirrettävä samat tietosuojavelvoitteet; ensimmäinen käsittelijä on edelleen vastuussa rekisterinpitäjälle näiden velvoitteiden täyttämisestä.

Tietonsiirrot kolmansiin maihin: Tarkista mekanismi ja todellinen vaikutus

GDPR:n V luku koskee henkilötietojen siirtoja kolmansiin maihin ja eteenpäinsiirtoja. Siirto ei synny pelkästään pysyvästä tallentamisesta; myös hallinnollinen pääsy, tukiyhteys tai datan hakeminen ETA-alueen ulkopuolisen palvelun toimesta voi olla siirto. Osoita siksi jokaiselle tietovirtakaavion nuolelle kohdemaa, vastaanottaja ja siirtomekanismi.

1. Tietosuojan riittävyyttä koskeva päätös: Tarkista Euroopan komission jatkuvasti päivittyvältä päätöslistalta, kattaako päätös kyseisen alueen, sektorin ja yksittäisen vastaanottajan. Rajoitetuissa järjestelmissä pelkkä toimipaikka maassa ei riitä.
2. Asianmukaiset suojatoimet: Jos riittävyyspäätöstä ei ole, kyseeseen tulevat GDPR:n 46 artiklan mukaiset mekanismit. Usein käytetään Euroopan komission vakiosopimuslausekkeita (SCC). Moduulin, osapuolten, liitteiden, siirtokuvauksen ja teknisten toimien on vastattava todellista ketjua.
3. Tehokkuuden arviointi: Allekirjoitettu SCC-asiakirja ei automaattisesti päätä arviointia. EDPB:n lopulliset suositukset 01/2020 kuvaavat riskipohjaista prosessia: tunnista siirrot, määritä väline, arvioi kolmannen maan lainsäädäntö ja käytännöt, päätä tarvittaessa täydentävistä toimenpiteistä, hoida muodolliset vaiheet ja arvioi tilannetta säännöllisesti uudelleen.

Täydentävien teknisten toimenpiteiden on sovittava konkreettiseen riskiin. Esimerkiksi salaus on merkitsevä vain silloin, kun avaintenhallinta, käyttöoikeudet ja käsittelyn tarkoitus otetaan huomioon. Mallintarjoaja, jonka täytyy käsitellä salaamatonta tekstiä ja jolla on itsellään pääsy avaimiin, on eri tilanne kuin pelkkä salattu varmuuskopiotallennus. Yleisluontoiset väitteet kuten "AES-256" tai "GDPR-yhteensopiva" eivät korvaa tätä tarkastelua. GDPR:n 49 artiklan mukaiset poikkeukset eivät myöskään ole tarkoitettu säännöllisen SaaS-käsittelyn vakioreitiksi.

Käytännön esimerkki: EU-alue globalisoituneessa palveluketjussa

Oletetaan, että chatbot tallentaa päätietokantansa Frankfurtiin. Vastaukset generoi kuitenkin yhdysvaltalaisen yrityksen malli-API, virheraportit menevät toiselle palvelulle ja globaali tukitiimi voi avata keskustelulokeja ongelmatilanteissa. Tällöin ilmaisu "tietojen tallennus EU:ssa" kuvaa vain osaa järjestelmästä.

Due diligence -prosessi erottaa neljä kysymystä: Mitkä sisällöt poistuvat ETA-alueelta mallivastauksen tuottamista varten? Tallennetaanko kehotteita siellä tai käytetäänkö niitä muihin tarkoituksiin? Sisältävätkö virheraportit salaamatonta tekstiä, tunnisteita vai vain minimoitua teknistä dataa? Millä ehdoilla ETA-alueen ulkopuolinen tuki pääsee käsiksi tietoihin? Vasta näiden jälkeen voidaan arvioida siirtovälinettä, täydentäviä toimia ja jäljelle jäävää riskiä.

Teknisesti verkkosivuston ylläpitäjä voi usein pienentää riskiä: kytkeä tarpeettomat lokikentät pois päältä, siivota syötteet ennen ulkoisia kutsuja, asettaa lyhyet säilytysajat, erottaa arkaluonteiset osiot julkisesta botista, eristää tietolähteet asiakaskohtaisesti sekä lokittaa tukipääsyt ja edellyttää niille hyväksyntää. Miten julkinen botti ja asiakasportaali erotetaan toisistaan turvallisesti, selvitetään artikkelissa Julkinen tekoäly-chatbot vs. asiakasportaali. Ladattavien tiedostojen osalta toimittaja-arviointia täydentää opas tiedostojen tarkastuksesta, tietosuojasta ja siirroista.

Päätöksenteko liikennevaloilla mututuntuman sijaan

Arviointikohta	Vihreä	Keltainen	Punainen
Tietovirta	Täydellinen, ajantasainen ja pakettikohtainen	Yksittäisiä pääsyjä tai tallennuspaikkoja avoinna	Vain markkinointiväite EU-alueesta
DPA	Tarkoitukset, tiedot, ajat ja tuki konkreettisia	Täydennyksiä tarvitaan ennen julkaisua	Ei selvää ohjeistusvelvoitetta tai poistoa
Alikäsittelijät	Nimilista, jossa mainitaan maa ja tehtävä	Muutosprosessi epäkäytännöllinen	Vain luokitteluita tai tuntematon ketju
Tietonsiirto kolmansiin maihin	Mekanismi, laajuus ja arviointi todennettu	Toimenpiteet vaativat vielä varmistusta	"EU-palvelin" väitetään kattavan kaikki siirrot
Ylläpito ja käyttö	Omistaja, tarkistuspäivä ja exit testattu	Todisteet ilman kiinteää tarkistusta	Ei monitorointia sopimuksen teon jälkeen

Keltainen valo ei automaattisesti tarkoita palveluntarjoajan hylkäämistä. Se vaatii kuitenkin vastuuhenkilön, määräajan ja tarkistettavan hyväksyntäkriteerin. Punaisen valon keskeisessä käsittelyketjussa pitäisi estää tuotantostartti, kunnes sopimusta, konfiguraatiota tai toimittajavalintaa on muutettu. Dokumentoi myös hyväksytyt jäännösriskit ja henkilö, joka on tehnyt kyseisen päätöksen.

Tiivis Go-live -tarkistuslista verkkosivuston ylläpitäjälle

• Tietovirtakaavio ja roolit käyttötarkoituksittain on hyväksytty.
• DPA ja sen liitteet vastaavat valittua pakettia, toimintoja, tietotyyppejä ja säilytysaikoja.
• Kaikki alikäsittelijät on dokumentoitu nimeltä, maantieteellisellä sijainnilla, tehtävällä ja muutosprosessilla.
• Jokaisella kolmansien maiden tietonsiirrolla on sopiva, ajantasaisesti tarkistettu mekanismi ja tarvittaessa täydentävät toimenpiteet.
• Mallien koulutus tai muu chatti-tietojen oma käyttö on selvitetty ja määritelty sopimuksen mukaan.
• Lokitus, tukipääsy, tietojen vienti, poistaminen ja sopimuksen päättäminen on testattu käytännössä.
• Tietosuojaseloste ja chat-käyttöliittymä selittävät käsittelyn ymmärrettävästi; käyttäjiä ei houkutella syöttämään tarpeettomia arkaluonteisia tietoja.
• On tarkistettu, edellyttääkö kyseinen käyttötapaus tietosuojan vaikutustenarviointia (DPIA).
• Vastuuhenkilö (Owner) valvoo alikäsittelijöiden, siirtomekanismien, toimintojen ja tietoturvatodistusten muutoksia.

Lisäksi kannattaa peilata kokonaisuutta perusohjeeseen Tekoäly-chatbot ja GDPR sekä oppaaseen tietoja minimoivasta chatbot-analytiikasta. Tällöin hankintaa, teknistä konfiguraatiota ja jatkuvaa ylläpitoa ei käsitellä toisistaan erillisinä projekteina.

Tarkistusten jatkaminen sopimuksen tekemisen jälkeen

Due Diligence ei ole kerran kasattu PDF-kansio. Määritä vähintään säännöllinen tarkistussykli sekä tapahtumaperusteiset tarkistukset. Liipaisimena voivat olla uudet alikäsittelijät, eri mallintarjoaja, uudet tuoteominaisuudet, muuttuneet tallennuspaikat, tietoturvaloukkaus, vanhentuvat todistukset tai muutokset riittävyyspäätöksissä. Ajantasainen alikäsittelijäluettelo ja keskeiset sopimusversiot tulee arkistoida päiväyksellä, jotta myöhemmät muutokset säilyvät jäljitettävinä.

Käytännön mittapuu on yksinkertainen: Pystyykö tiimisi selittämään jokaisesta olennaisesta tietovirrasta, kuka käsittelee mitä ja miksi, missä se tapahtuu, kuinka kauan tiedot säilyvät, mikä suojatoimi on käytössä ja miten palvelun lopettaminen toimii? Kun nämä vastaukset on todennettu, yleisestä tietosuojaväitteestä tulee kestävä hankintapäätös. Jos keskeisiä vaiheita jää tuntemattomiksi, chatbotin ei pitäisi vielä käsitellä todellisia kävijätietoja.