Suostumus ja oikeus tulla unohdetuksi

🌐 Saatavilla myös 28 kielellä

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Español (México) · Français (Canada) · Deutsch (Schweiz)

Kuva on luotu tekoälyllä

Tekoälyn kääntämä. Yhteisö ei ole vielä tarkistanut käännöstä. Lue englanniksi

Moduuli 5/6 luvussa Tietojen laatu ja hallinta, Data Architect -kurssin luku 5. Jokainen moduuli on itsenäinen. Edellinen: Tietosuojalait muovaavat suunnittelua · Seuraava: Suojaa, säilytä ja todista

Kysymys, johon tämä moduuli vastaa: Miten suunnittelet suostumuksen, ja henkilön tietojen poistamisen?

Steve Truckingilla on vastaanottajan (Recipient) puhelinnumero. Yksinkertainen kysymys: saammeko lähettää hänelle tekstiviestin? Ehkä. Tämänpäiväisestä toimituksesta? Huomisesta? Saammeko käyttää numeroa kampanjaan? Entä jos hän kielsi tekstiviestit, tai sanoi kyllä toimituspäivityksille mutta ei markkinoinnille, ja muutti sitten mielensä?

Nyt toiseen suuntaan. Vastaanottaja sanoo: poistakaa henkilötietoni. Missä ne ovat? Luultavasti Salesforcessa, mutta olemme oppineet, ettei se ole koko vastaus. Ne tulivat vähittäiskauppakumppanilta (Retail Partner). Ne voivat olla asiakastietoalustassa, kenttähistoriassa, arkistossa, toimitusmuistiinpanossa, viennissä, integraatiolokissa, agentin keskustelussa. Suostumus ja poistaminen kuulostavat käytäntökysymyksiltä, mutta lopulta järjestelmän on vastattava niihin. Se on arkkitehtuuria.

Suostumus on tietoa

Ensimmäinen periaate: suostumus on tietoa. Älä supista sitä muotoon Has_Opted_In__c = true. Todellinen kysymys ei ole koskaan pelkästään ”suostuiko hän?” Kysymys on, mihin hän suostui, minkä kanavan kautta, mihin osoitteeseen tai numeroon, mihin tarkoitukseen, milloin, onko se muuttunut ja pystymmekö todistamaan sen? Jos liiketoiminta tekee päätöksiä näiden vastausten perusteella, ne on tallennettava jäsenneltynä tietona. Kappale tietosuojaselosteessa ei riitä, eikä riitä valintaruutu verkkolomakkeella: valintaruutu tallentaa tapahtuman; arkkitehtuurin on säilytettävä se, mitä tapahtuma tarkoittaa.

Käytä mallia, jonka Salesforce on jo rakentanut

Kantani: käytä valmista suostumusmallia aina kun voit, älä rakenna samaa asiaa uudelleen mukautettuihin kenttiin. Salesforcen suostumustietomalli hallitsee suostumusta neljällä tasolla, joista jokainen on tarkempi kysymys (Understand the Salesforce Consent Data Model (opens in a new tab)):

• Yleinen suostumus, Individual-objektissa: kuka tämä henkilö on, ja onko hän kieltäytynyt kaikesta?
• Viestintäkanavan suostumus (Contact Point Type Consent): saammeko käyttää tämänlaista kanavaa, kuten tekstiviestiä tai sähköpostia?
• Yhteyspisteen suostumus: entä tämä tietty puhelinnumero tai sähköpostiosoite?
• Tietojen käyttötarkoitus (Data Use Purpose): mistä syystä: toimitusilmoitukset, asiakaspalvelu, markkinointi?

Yhdessä nämä antavat arkkitehtuurin vastata kysymykseen ”saammeko käyttää tämän henkilön tietoja tämän yhteyspisteen kautta tähän tarkoitukseen?”, mikä on paljon hyödyllisempää kuin ”suostumus = kyllä”. Mukana voi olla mikä tahansa tietue, joka liittyy yksilöön: liidit, yhteyshenkilöt, henkilötilit, käyttäjät.

Click to enlarge

Neljä kysymystä, kukin edellistä kapeampi. Yksi suostumuslippu ei vastaa hyvin yhteenkään niistä.

Käyttötarkoituksella on väliä

Vähittäiskauppakumppani lähettää Steve Truckingille vastaanottajan numeron, jotta tiimi voi sopia toimituksesta. Se ei tee vastaanottajasta markkinointiliidiä. Samoilla tiedoilla voi olla eri sallittuja käyttötapoja: toimituksen koordinointi, palvelun jälkiseuranta, markkinointi, tekoälyllä tehty personointi. Jos käytäntö tai laki kohtelee niitä eri tavoin, mallin on erotettava ne toisistaan. Kysymys ei ole onko meillä puhelinnumero? Kysymys on mitä saamme tehdä sillä?

Eikä suostumus ole aina käsittelyperuste. Osa käytöstä perustuu muihin perusteisiin, joista laki säätää, ja sen ratkaisevat lakiasiat. Älä rakenna arkkitehtuuria, joka olettaa jokaisen tietosuojapäätöksen olevan suostumusruutu. Tue sitä, mitä käytäntö sanoo: jos käyttö riippuu suostumuksesta, mallinna suostumus ja pane se täytäntöön; jos sovelletaan jotain muuta perustetta, tallenna silti se, mitä tarvitaan sen ratkaisemiseen, onko käyttö sallittua.

Suostumuksella on elinkaari ja auktoriteetti

Ihmiset antavat suostumuksen, peruvat sen, muuttavat asetuksiaan, vaihtavat numeroa. Liiketoiminta lisää uusia käyttötarkoituksia; lait muuttuvat. Suunnittele siis elinkaari: mitä valittiin, milloin, miten, mihin tarkoitukseen ja mitä tapahtuu, kun suostumus perutaan. Ja tässä kohtaa asia muuttuu kiinnostavaksi: kun vastaanottaja peruu suostumuksensa, Salesforce tietää sen. Tietääkö viestintäalusta? Analytiikka? Agentti? Suostumus, joka asuu yhdessä järjestelmässä, kun muut toimivat vanhentuneen luvan varassa, ei ole kummoinen kontrolli.

Se tarkoittaa kysymystä mikä järjestelmä on suostumuksen osalta auktoritatiivinen. Salesforce, asetusalusta, jokin muu? Vastauksesta riippumatta älä anna viiden järjestelmän päättää toisistaan riippumatta, suostuiko sama henkilö samaan käyttöön. Suostumus tarvitsee sen, mitä mikä tahansa hallittu tieto tarvitsee: omistajan, auktoritatiivisen tietueen, tavan synkronoida ja täytäntöönpanon.

Nyt henkilö sanoo: unohda minut

Ensimmäinen vaisto on poistaa yhteyshenkilö ja todeta työ tehdyksi. Mutta henkilön tietoja voi olla yhteyshenkilössä, toimituksessa, toimitusmuistiinpanossa, tapauksessa, valokuvassa, kenttähistoriassa, Snowflakessa, arkistossa, integraatiolokissa, hakuindeksissä tai agentin keskusteluhistoriassa. Siksi kantani poistamiseen alkaa aiemmin: poistaminen on käytännössä harvinaista ja vaikeaa, joten hallitse ensin, minne henkilötiedot menevät. Suunnittele niin, että ne päätyvät mahdollisimman harvaan paikkaan. Sitten, kun pyyntö tulee, sumenna tiedot tai katkaise niiden yhteys henkilöön siellä, missä se täyttää käytännön, ja jäljitä jokainen kopio: kenttähistoria, arkistot, Data 360, ja nykyään hakuindeksit ja agenttien keskustelut.

Älä aloita jäljitystä vasta, kun pyyntö saapuu. Silloin on liian myöhäistä alkaa ymmärtää järjestelmäkarttaa. Moduulin 3 sanasto, alkuperä ja luokittelu eivät olleet paperityötä; ne tekevät tämän mahdolliseksi. Tiedät jo, missä kentissä on henkilötietoja ja minne kopiot menivät.

Click to enlarge

Unohda minut -pyyntö on päätös jokaisesta kopiosta.

Aika kuluu

Näihin pyyntöihin liittyy määräaikoja. EU:n yleisen tietosuoja-asetuksen (GDPR) mukaan organisaation on toimittava henkilön pyynnön perusteella ilman aiheetonta viivytystä ja viimeistään kuukauden kuluessa pyynnön vastaanottamisesta; monimutkaisten tai lukuisten pyyntöjen vuoksi määräaikaa voidaan jatkaa enintään kahdella kuukaudella, mutta henkilölle on ilmoitettava jatkamisesta ja sen syistä ensimmäisen kuukauden kuluessa (12 artiklan 3 kohta, asetus (EU) 2016/679 (opens in a new tab)). Muut lait asettavat omat määräaikansa; lakiasiat kertovat, mitkä pätevät. Joka tapauksessa kuukausi ei riitä järjestelmäkartan selvittämiseen. Se on määräaika, joka kopioiden kartan on voitettava.

Poista, tee tunnisteettomaksi vai säilytä?

Pyyntö ei välttämättä tarkoita, että kaikki katoaa kaikkialta. Joitain tietueita on säilytettävä tai niitä saa säilyttää; jotkin operatiiviset tietueet voivat jäädä mutta lakata tunnistamasta henkilöä; joitain tietoja voidaan tehdä tunnisteettomiksi. Sovellettava käytäntö ja laki ratkaisevat; arkkitehtuuri tukee jokaista lopputulosta sijainti kerrallaan: poista se, tee siitä tunnisteeton tai säilytä se hyväksytyn vaatimuksen perusteella (ja silloin: kuka saa nähdä sen, kuinka kauan, miksi?).

Muista moduulin 4 erottelu. Yhteyden katkaiseminen lasketaan unohtamiseksi vain, kun henkilöä ei voida kohtuudella tunnistaa uudelleen. Pseudonymisoidut tiedot ovat yhä henkilötietoja. Älä käytä sumentamista oikotienä oikeudellisen vaatimuksen ohi.

Et voi poistaa sitä, mitä et löydä

Ennen kuin voit poistaa jonkun, sinun on löydettävä hänet. Pyyntö tulee sähköpostiosoitteesta. Yksi vähittäiskauppakumppani lähetti ”Jane Smith”, toinen ”J. Smith”, ja puhelinnumero on vaihtunut. Vastaanottaja ei ole yhteyshenkilö lainkaan; hänen tietonsa ovat jokaisessa toimituksessa. Sama henkilö sai toimituksia kahdelta eri kumppanilta. Yksi järjestelmä tuntee hänet sähköpostista, toinen ulkoisesta tunnisteesta. Poistaminen riippuu identiteetistä, etkä halua poistaa jonkun toisen tietoja, koska täsmäyksesi oli liian aggressiivinen. Identiteettiarkkitehtuuri on osa tietosuoja-arkkitehtuuria.

Steve Trucking tekee tästä vielä vaikeampaa. Yksikään vähittäiskauppakumppani ei saa koskaan nähdä toisen toimituksia tai vastaanottajia. Jos sama henkilö sai toimituksia kahdelta kumppanilta, operatiivisen toiminnan on pidettävä nämä suhteet erillään, kun taas tietosuojan on ehkä silti löydettävä henkilö molempien kautta. Älä ratkaise tietosuojaa rikkomalla tietoturvarajaa, äläkä suojaa rajaa tekemällä tietosuojapyynnöistä mahdottomia. Arkkitehtuurin on tehtävä molemmat.

Valokuvat ja vapaa teksti ovat myös tietoa

Tietosuojaa on helppo ajatella kenttinä: nimi, sähköposti, puhelinnumero, osoite. Mutta Steve Trucking ottaa miljoonia toimitusvalokuvia vuodessa, ja joissakin näkyy ihmisiä tai kodin sisätila. Säilytys- tai poistokäytäntö, joka katsoo vain jäsenneltyjä kenttiä, on puutteellinen; samoin käytäntö, joka sivuuttaa tiedostot, asiakirjat, litteroinnit, lokit sekä tekoälyn kehotteet ja vastaukset.

Ja vapaa teksti on vaarallista. Poistat nimen, puhelinnumeron ja osoitteen ja löydät sitten tämän toimitusmuistiinpanon: ”Soita Janelle numeroon 602-555-0198. Porttikoodi 4821. Koira on pihalla.” Siinä se on. Toimitusmuistiinpanojen luokittelu arkaluonteisiksi kertoo, että ongelma voi olla olemassa; se ei löydä eikä poista tekstin sisällä olevia henkilötietoja. Joskus paras vastaus on estää tarpeettomien henkilötietojen päätyminen sinne lainkaan. Hallitse ensin, minne henkilötiedot menevät.

Privacy Center on työkalu, ei koko arkkitehtuuri

Salesforcen Privacy Center auttaa pyörittämään näitä prosesseja. Sen oikeus tulla unohdetuksi -käytännöt rakennetaan objektikohtaisesti kattamaan kaikki, minkä haluat poistaa, ja ne ajetaan tiettyä asiakastietuetta vastaan (Delete Data with Right to Be Forgotten Policies (opens in a new tab)). Se on hyödyllistä. Mutta ”ostimme Privacy Centerin, joten olemme valmiita” ei ole arkkitehtuuri. Henkilön tiedot voivat olla minkä tahansa yksittäisen työkalun ulottumattomissa: Data 360, tietovarasto, kumppanien järjestelmät, arkistot, lokit, haku, tiedostot, agenttien keskustelut. Yritys tarvitsee silti koko yrityksen kattavan vastauksen, ja sinun on tarkistettava, mitä kukin työkalu todella kattaa, ennen kuin luotat siihen.

Siirrettävyys ja todisteet

Jotkin lait antavat ihmisille myös oikeuden saada kopio tiedoistaan. Huomaa, että se on sama löytämisongelma: poistaminen kysyy missä tämän henkilön tiedot ovat, jotta voimme toimia niiden suhteen? Siirrettävyys kysyy missä ne ovat, jotta voimme toimittaa ne? Molemmat nojaavat identiteettiin, luokitteluun, alkuperään, järjestelmäinventaarioon ja omistajuuteen.

Ja sitten: miten todistat, että teit sen? Pyyntö vastaanotettu, henkilöllisyys tarkistettu, järjestelmät käyty läpi, toimet tehty, poikkeukset kirjattu, säilytetyt tiedot perusteltu, valmistuminen kirjattu. Tässä on todellinen jännite: poistat jonkun henkilötietoja ja säilytät samalla tarpeeksi näyttöä osoittaaksesi, että käsittelit pyynnön asianmukaisesti. Juuri siksi arkkitehtien ei pidä keksiä säilytyssääntöjä omin päin. Lakiasiat ja compliance päättävät, minkä näytön on jäätävä; arkkitehtuuri säilyttää sen säilyttämättä niitä tietoja, jotka sen piti poistaa.

Kokeen jälkeen: mitä tekoäly muuttaa. Tekoäly luo uusia käyttötarkoituksia ja uusia kopioita. Lupa käyttää tietoja palvelun tarjoamiseen ei automaattisesti kata agentin groundingia (ankkurointia dataan), personointia tai koulutusta; Data Use Purpose on luonteva paikka erottaa ne. Ja henkilötiedot voivat säilyä kehotteissa, grounding-kontekstissa, keskusteluissa, yhteenvedoissa, haku- ja vektori-indekseissä sekä lokeissa. ”Poistimme lähdetietueen” ei ole täydellinen vastaus, jos tekoälykerros muistaa yhä.

Mitä arkkitehti tässä päättää

• Miten suostumus ja sallittu käyttö mallinnetaan, jotta järjestelmät voivat vastata kysymyksiin kuka, mikä kanava, mikä yhteyspiste ja mihin tarkoitukseen.
• Mikä järjestelmä on suostumuksen osalta auktoritatiivinen, ja miten peruutukset tavoittavat jokaisen järjestelmän, joka toimii sen perusteella.
• Minne henkilötiedot voivat levitä: kentät, vapaa teksti, tiedostot, historia, analytiikka, arkistot, integraatiot, haku ja tekoäly.
• Miten pyyntö löytää oikean henkilön ja johtaa kussakin sijainnissa poistoon, tunnisteettomaksi tekemiseen tai hyväksyttyyn säilytykseen.
• Mitä näyttöä jää todistamaan, että suostumukset ja tietosuojapyynnöt käsiteltiin.

Suostumus ja poistaminen näyttävät vastakohdilta (saammeko käyttää näitä tietoja? voimmeko lopettaa ja poistaa ne?), mutta ne nojaavat samoihin perustuksiin: identiteettiin, käyttötarkoitukseen, luokitteluun, alkuperään, omistajuuteen, täytäntöönpanoon ja näyttöön. Käytä vakiomuotoista suostumusmallia, hallitse, minne henkilötiedot menevät, tiedä, missä kopiot ovat, ja suunnittele poistoprosessi ennen kuin ensimmäinen pyyntö saapuu. Kun joku kysyy ”voitteko unohtaa minut?”, arkkitehtuuri tarvitsee paremman vastauksen kuin ”luulemme niin”.

Lue lisää

• Salesforce Help, Understand the Salesforce Consent Data Model (opens in a new tab) (englanniksi, tarkistettu 2026-10-14).
• Regulation (EU) 2016/679 (GDPR) (opens in a new tab), 12 artiklan 3 kohta, pyyntöön vastaamisen määräaika (tarkistettu 2026-10-14).
• Salesforce Help, Delete Data with Right to Be Forgotten Policies (opens in a new tab) (Privacy Center) (englanniksi, tarkistettu 2026-10-14).