Tietosuojalait muovaavat suunnittelua

🌐 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 4/6 luvussa Tietojen laatu ja hallinta, Data Architect -kurssin luku 5. Jokainen moduuli on itsenäinen. Edellinen: Tunne tietosi · Seuraava: Suostumus ja oikeus tulla unohdetuksi

Kysymys, johon tämä moduuli vastaa: Mitä tietosuojasääntely ja toimialakohtainen sääntely vaativat Salesforce-suunnitelmalta?

Kun työskentelin Australiassa, tapasin paljon arkkitehdiksi pyrkiviä, jotka eivät olleet koskaan kuulleetkaan EU:n yleisestä tietosuoja-asetuksesta (GDPR). Eurooppalaiset eivät usein ole kuulleet Kalifornian tietosuojalaista, tai Kanadan, tai Brasilian. Se on luonnollista: tunnet säännöt siellä, missä työskentelet. Mutta nämä lait ulottuvat rajojen yli, ja ne muovaavat järjestelmien suunnittelua, vaikka yksikään niistä ei koske Salesforcea. Siksi ne kuuluvat tietoarkkitehtuurin kurssille.

Sinun ei tarvitse ryhtyä juristiksi. Sinun pitää kuitenkin nähdä, että sääntely voi muuttaa sitä, missä tietoja säilytetään, mitä keräät, kuka ne näkee, mihin saat niitä käyttää, kuinka kauan säilytät niitä, minne lähetät niitä, voitko poistaa niitä, mitä historiaa säilytät ja mitä pystyt myöhemmin todistamaan. Ne eivät ole pelkästään oikeudellisia kysymyksiä. Ne ovat tietoarkkitehtuurin kysymyksiä.

Tämä moduuli on arkkitehtuuriohjeistusta, ei oikeudellista neuvontaa. Lakiasioiden ja compliancen tiimit päättävät, mitkä lait ovat sovellettavia ja mitä ne vaativat. Arkkitehti muuntaa nämä vaatimukset täytäntöönpantavaksi suunnitteluksi.

Lait eivät pysähdy rajalle

Ensin suurin väärinkäsitys: ”emme ole Euroopassa, joten GDPR ei koske meitä.” Ehkä, ehkä ei. GDPR:n alueellinen soveltamisala ulottuu EU:n ulkopuolisiin organisaatioihin, jotka tarjoavat tavaroita tai palveluja EU:ssa oleville henkilöille tai seuraavat heidän käyttäytymistään siellä (3 artikla, asetus (EU) 2016/679 (opens in a new tab)). Yrityksesi pääkonttorin sijainti ei siis ratkaise kysymystä. Missä ovat asiakkaasi, työntekijäsi, ihmiset, joiden tietoja sinulla on, järjestelmäsi, henkilötietojen käsittelijäsi? Minne tiedot kulkevat? Se on taas luvun 4 järjestelmäkartta. Hyviä tietosuojapäätöksiä ei voi tehdä tietämättä, minne tiedot menevät.

Säädökset, jotka sinun pitäisi tunnistaa

Tässä ovat nimet, jotka arkkitehdin pitäisi tuntea, ja mitä kukin kattaa. Se on tunnistustaulukko, ei sovellettavuusmatriisi: älä lue sitä ja päätä, että ”meillä on asiakkaita Kaliforniassa, joten vaatimus X koskee meitä”. Sen ratkaisevat lakiasiat. Sinun tehtäväsi on tietää tarpeeksi, jotta osaat kysyä kysymyksen ennen kuin järjestelmä rakennetaan.

Laki tai standardi	Missä tai mitä	Miksi arkkitehdin pitäisi tunnistaa se
GDPR (opens in a new tab)	Euroopan unioni	Henkilötiedot, lainmukainen käsittely, rekisteröityjen oikeudet, säilytys, siirrot, sisäänrakennettu tietosuoja
CCPA, as amended by the CPRA (opens in a new tab)	Kalifornia	Kuluttajien oikeudet henkilötietoihin, joita yritykset keräävät heistä
PIPEDA (opens in a new tab)	Kanada	Miten yksityisen sektorin organisaatiot käsittelevät henkilötietoja
LGPD (opens in a new tab)	Brasilia	Brasilian yleinen henkilötietojen suojaa koskeva laki
Privacy Act 1988 (opens in a new tab)	Australia	Miten organisaatiot käsittelevät henkilötietoja Australian tietosuojaperiaatteiden (Australian Privacy Principles) mukaisesti
HIPAA (opens in a new tab)	Yhdysvaltain terveydenhuolto	Suojatut terveystiedot lain kattamissa yhteyksissä
PCI DSS (opens in a new tab)	Maksukortit	Maksukorttien tilitietojen suojaaminen
Sarbanes-Oxley (SOX) (opens in a new tab)	Yhdysvaltain pörssiyhtiöt	Taloudellisen raportoinnin taustalla olevat kontrollit ja näyttö
COPPA (opens in a new tab)	Yhdysvallat, lapset verkossa	Lapsilta verkossa kerätyt henkilötiedot

Lista kasvaa (yhä useammalla Yhdysvaltain osavaltiolla on oma lakinsa), ja lait muuttuvat. Siksi en halua, että opettelet taulukon ulkoa ja luulet oppineesi tietosuoja-arkkitehtuurin. Opettele nimet, ja opettele sitten kysymykset, jotka elävät niitä pidempään.

Mitä laeilla on yhteistä

Yksityiskohdat vaihtelevat, mutta suuret tietosuojalait palaavat aina samoihin muutamaan asiaan, ja jokainen niistä osuu arkkitehtuuriin.

Oikeudet. Ihmiset voivat pyytää saada nähdä tietonsa, oikaista ne, poistaa ne ja siirtää ne mukanaan; Kalifornian ja Brasilian lakien nojalla he voivat myös kieltää tietojensa myymisen. Jokainen näistä pyynnöistä tarkoittaa henkilön tietojen löytämistä, kaikkien niiden.

Siirrot. GDPR ja LGPD valvovat henkilötietojen siirtymistä niiden lainkäyttöalueen ulkopuolelle ja edellyttävät riittävää suojaa siellä, minne tiedot menevät; PIPEDA edellyttää samantasoista suojaa, kun kolmas osapuoli käsittelee tietoja, missä tahansa se onkin. Se on taas järjestelmäkartta: mitkä nuolet ylittävät rajan?

Tietoturvaloukkauksista ilmoittaminen. Kun henkilötietoja paljastuu, lait edellyttävät, että ilmoitat viranomaisille, ja joskus asianomaisille henkilöille, määräajassa, joka vaihtelee laeittain. Et voi ilmoittaa tiedoista, joiden olemassaolosta et tiennyt, etkä kertoa, mitä paljastui, jos et löydä kopioita.

Osoitusvelvollisuus. Sinun on pystyttävä osoittamaan, että noudatat vaatimuksia: selosteet siitä, mitä käsittelet ja miksi, vaikutustenarvioinnit korkean riskin käsittelystä ja GDPR:n ja LGPD:n mukaan tietosuojavastaava. Arkkitehtuurin on tuotettava nämä tiedot.

Aloita siitä, mikä on henkilötietoa

Ennen kuin suojaat henkilötietoja, löydä ne. Osa on ilmeistä: nimi, kotiosoite, puhelinnumero, sähköposti. Osa ei ole: sijainti, laitetunnisteet, IP-osoitteet, kuvat, käyttäytymistiedot, kaikki, mikä voidaan yhdistää takaisin henkilöön. Ja asiayhteydellä on väliä. Steve Truckingin toimituksessa on vastaanottajan (Recipient) nimi, osoite, puhelinnumero, toimitusmuistiinpanot ja valokuvat. Valokuvassa voi näkyä laatikko kuistilla, tai ihminen, tai kodin sisätila. Toimitus on operatiivista tietoa, mutta osa sen attribuuteista on henkilötietoja. Siksi moduuli 3 luokitteli kenttiä: tietosuoja alkaa siitä, että tiedät, mitä sinulla on.

Missä ne asuvat?

”Salesforcessa.” Tuskin pelkästään Salesforcessa. Tulivatko ne vähittäiskauppakumppanilta? Kopioitiinko ne Snowflakeen, otettiinko ne sisään Data 360:een, kirjoitettiinko ne integraatiolokiin, vietiinkö ne käyttäjän toimesta ulos, jäivätkö ne kenttähistoriaan, arkistoitiinko ne, kopioitiinko ne sandboxiin, välitettiinkö ne kumppanille, käytettiinkö niitä agentin keskustelussa? Henkilötiedot leviävät. Kun lakiasiat kysyvät ”missä säilytämme tämän henkilön tietoja?”, vastaus ”tiedämme, missä nykyinen arvo on” ei riitä. Haluan järjestelmäkartan ja alkuperän: minne kopiot menivät.

Click to enlarge

Yksi puhelinnumero, monta kopiota. Tietosuoja koskee myös kopioita.

Miksi saat käyttää niitä?

Se, että sinulla on tietoja, ja se, että saat käyttää niitä, eivät ole sama asia. Steve Truckingilla on vastaanottajan puhelinnumero tämänpäiväisen toimituksen koordinointia varten. Tekeekö se siitä markkinointilistan? Ei. Käsittelyperuste riippuu lainkäyttöalueesta ja tilanteesta, ja lakiasiat ohjaavat sitä, mutta arkkitehtuurin on kannettava vastaus: miksi tiedot kerättiin, mikä käyttö sallittiin, tarvittiinko suostumus, annettiinko se, peruttiinko se, ja mitä kanavaa, osoitetta ja käyttötarkoitusta se koskee. Lupa käyttää tietoja on voitava esittää tietona, koska käytäntöasiakirja ei voi tehdä päätöstä ajon aikana. Seuraava moduuli mallintaa sen.

Vähemmän keräämisen päätös on arkkitehtuuripäätös

Yksi vahvimmista tietosuojakontrolleista on se, ettei tietoja kerätä, tai niitä ei kopioida sinne, missä niitä ei tarvita. Tarvitseeko Snowflake vastaanottajan puhelinnumeroa? Tarvitseeko analytiikka koko katuosoitetta? Tarvitseeko sandbox oikeita toimitusten valokuvia? Tarvitseeko agentti vastaanottajan henkilötietoja vastatakseen tähän kysymykseen? Jos ei, vahvin kontrolli voi olla se, ettei niitä laiteta sinne. Jokainen kopio, jota et tee, on kopio, jota sinun ei tarvitse suojata, säilyttää, poistaa, jonka suostumusta ei tarvitse seurata, jota ei tarvitse auditoida eikä raportoida tietoturvaloukkauksessa. Halvimmat hallittavat arkaluonteiset tiedot ovat ne, joita et koskaan kopioinut.

Säilytys on osa mallia

”Säilytetään toistaiseksi kaikki” on säilytyskäytäntö. Se on vain huono sellainen. Tärkeistä tiedoista haluan tietää jo suunnitteluvaiheessa, kuinka kauan tarvitsemme niitä ja miksi; asettaako jokin säädös vähimmäisajan tai toinen enimmäisajan; milloin aika alkaa kulua; ja mitä tapahtuu lopussa: poisto, arkistointi, tunnisteettomaksi tekeminen, ja missä kopiot ovat? Taloudellisia tietueita voidaan joutua säilyttämään määräajan. Vastaanottajan porttikoodilla ei ole käyttötarkoitusta vuosia toimituksen jälkeen. Nämä päätökset eivät odota, että tietokanta kasvaa suureksi.

Anonymisoitu, pseudonymisoitu, salattu, peitetty

Korvaa ”Jane Smith” arvolla 7F92A1. Onko Jane anonymisoitu? Ei, jos toisessa taulussa lukee yhä 7F92A1 = Jane Smith. Se on pseudonymisointia: suora tunniste on korvattu, mutta tiedot voidaan yhdistää uudelleen erikseen säilytettyjen tietojen avulla, ja GDPR:n mukaan pseudonymisoidut tiedot ovat yhä henkilötietoja (4 artiklan 5 alakohta). Anonymisointi menee pidemmälle: tietoja ei voida enää kohtuudella yhdistää henkilöön (johdanto-osan 26 perustelukappale). Joten kun joku sanoo ”meidän ei tarvitse poistaa sitä, poistamme vain nimen”, ole varovainen. Jos henkilö voidaan yhä kohtuudella tunnistaa, et ole ylittänyt sitä rajaa. Sen, täyttääkö lopputulos lain vaatimukset, ratkaisevat lakiasiat; arkkitehdin tehtävä on kertoa tarkasti, mitä järjestelmä tekee: voidaanko tiedot yhdistää uudelleen, mitä avaimia on jäljellä, missä mappaukset ovat?

Käytä sanoja täsmällisesti, koska ne ratkaisevat eri ongelmia. Salaus suojaa tietoja luvattomalta paljastumiselta; valtuutettu käyttäjä voi yhä purkaa salauksen. Peittäminen muuttaa sitä, mitä tietyt käyttäjät tai ympäristöt näkevät. Pseudonymisointi erottaa suoran identiteetin mutta säilyttää tien takaisin. Anonymisointi poistaa kohtuullisen mahdollisuuden tunnistaa henkilö. Vain viimeinen vie tiedot pois ”henkilötietojen” piiristä.

Sääntelystä tulee vaatimuksia

Lakiasioiden ei tarvitse käskeä minua luomaan käyttöoikeusjoukkoa; se on minun puoleni rajasta. Lakiasiat voivat sanoa: ”vain työntekijät, joilla on oikeutettu liiketoiminnallinen tarve, saavat käyttää tätä henkilötietoluokkaa.” Sitten minä muunnan: keitä he ovat, miten tunnistamme luokan, miten pääsy myönnetään, mitä tapahtuu, kun joku vaihtaa tehtävää, voiko integraatio lukea sen, voiko agentti, voiko sen viedä ulos, ja miten todistamme, kuka sen näki? Omistajat päättävät käytännöt, arkkitehdit panevat ne täytäntöön. Lakiasiat ja compliance määrittävät velvoitteen, tietojen omistajat päättävät liiketoiminnan käytännön, ja arkkitehti suunnittelee täytäntöönpanon.

Click to enlarge

Sääntelystä näyttöön: lakiasiat tulkitsevat, omistaja päättää käytännön, arkkitehti saa sen toimimaan ja todistettavaksi.

Ja vaatimustenmukaisuus ei ole tuote. Et voi ostaa asetusta ”compliance: päällä”. Salaus voi tukea vaatimusta, auditointiominaisuudet tuottavat näyttöä, säilytystyökalut toteuttavat käytäntöä, suostumustiedot tukevat sallittua käyttöä, mutta ominaisuuden lisensoiminen ei tee arkkitehtuurista vaatimustenmukaista. Vaatimustenmukaisuus syntyy koko suunnitelmasta: ihmisistä, käytännöistä, prosesseista, tiedoista, kontrolleista ja näytöstä. Salesforce on osa sitä, ei kaikki. Ja jos käytäntö on niin tärkeä, että se pannaan täytäntöön, kysy, onko se niin tärkeä, että se pitää todistaa: kuka käytti tätä tietuetta 17. maaliskuuta, kuka muutti tätä kenttää, mitä se vienti sisälsi? Moduuli 6 käsittelee näyttöä.

Tietosuoja muuttaa järjestelmäkarttaa

Steve Truckingilla vastaanottajan henkilötiedot saapuvat kolmen kumppani-integraation kautta. Salesforce tarvitsee niitä toimitusten pyörittämiseen; tiimit tarvitsevat osan niistä, vain omilla pysähdyksillään ja vain sinä päivänä; Snowflake haluaa toimitusanalytiikkaa; taloushallinto tarvitsee tarpeeksi laskuttaakseen, mutta ei sitä, mitä tiimi näkee. Eikä yksikään vähittäiskauppakumppani saa koskaan nähdä toisen vastaanottajia. Tietosuoja muuttaa nuolia: tietyt kentät eivät mene Snowflakeen, analytiikka saa vaikeammin tunnistettavan version, tiimit näkevät vain omat pysähdyksensä, alavirran säilytys poikkeaa operatiivisesta säilytyksestä. Tietosuojavaatimus ei istu järjestelmäkarttakaavion vieressä. Se muuttaa sitä.

Kysymykset, jotka elävät säädöksiä pidempään

Säädökset muuttuvat, joten pidä mukanasi pysyvä joukko kysymyksiä kaikista arkaluonteisista tai säännellyistä tiedoista:

• Mitä se on? Henkilötietoa, arkaluonteista, taloudellista, terveyteen liittyvää, maksutietoa, lasten tietoa vai muuten säänneltyä?
• Missä se asuu? Jokainen kopio: integraatiot, historia, analytiikka, arkistot, sandboxit, lokit, tekoälyn käyttö.
• Miksi saamme käyttää sitä? Mikä käyttötarkoitus ja käsittelyperuste pätevät? Liittyykö siihen suostumus?
• Kuka saa käyttää sitä? Ihmiset, järjestelmät, kumppanit, integraatiot, agentit.
• Kuinka kauan säilytämme sitä, ja mitä tapahtuu lopussa?
• Voiko henkilö käyttää oikeuksiaan siihen? Pääsy, oikaisu, poisto, siirrettävyys, vastustaminen, sen mukaan kuin laki säätää.
• Pystymmekö todistamaan, mitä tapahtui? Pääsy, muutokset, viennit, suostumus, poisto, säilytys.

Tekoälyn hallinnasta on tulossa lakia

Tekoäly tuo hallituille tiedoille uuden kuluttajan. Saako tekoälyjärjestelmä käyttää näitä tietoja, mihin tarkoitukseen, groundingina (ankkurointina dataan), yhdistettynä mihin, toistettuna tuotoksessaan, kirjattuna minne ja kuinka pitkäksi aikaa? Tekoälyn hallinta on siirtymässä yritysten käytännöistä lainsäädäntöön: Euroopan unionin tekoälysäädös (asetus (EU) 2024/1689 (opens in a new tab)) on ensimmäinen laaja esimerkki. Mitä se vaatii, riippuu järjestelmästä ja käytöstä. Suunta arkkitehdeille on selvä: tekoäly ei ole hallinnan ulkopuolella; se on yksi hallittujen tietojen kuluttaja lisää.

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

• Missä säännellyt tai arkaluonteiset tiedot tulevat sisään, asuvat, liikkuvat ja kopioituvat järjestelmäkartalla.
• Miten lakiasioiden ja compliancen käytännöistä tulee täytäntöönpantavia vaatimuksia ilman, että arkkitehti tulkitsee lakia.
• Tarvitseeko kukin arkaluonteisia tietoja vastaanottava järjestelmä niitä, vai riittäisikö vaikeammin tunnistettava versio.
• Miten säilytys, poisto, anonymisointi, pseudonymisointi, suojaus ja näyttö muovaavat tietojen elinkaarta.
• Millaista näyttöä on oltava olemassa sen osoittamiseksi, että tärkeät kontrollit todella toimivat.

Säädöksistä ei tule arkkitehtuuria laittamalla niiden nimet dialle. Niistä tulee arkkitehtuuria, kun ne muuttavat sitä, miten tietoja kerätään, luokitellaan, siirretään, suojataan, säilytetään, poistetaan ja todistetaan.

Lue lisää

• Säädösten viralliset lähteet on linkitetty yllä olevaan taulukkoon (tarkistettu 2026-10-14).
• Regulation (EU) 2016/679 (GDPR) (opens in a new tab): 3 artikla (alueellinen soveltamisala), 4 artiklan 5 alakohta (pseudonymisointi), johdanto-osan 26 perustelukappale (anonyymit tiedot).
• Regulation (EU) 2024/1689 (the AI Act) (opens in a new tab), EUR-Lex (tekoälysäädös).