By · Last updated 2026-06-05

Takaisin BlogiinGDPR & Vaatimustenmukaisuus

GDPR:n tietojen minimointi: Reaaliaikainen API

GDPR:n artikla 5(1)(c) edellyttää vain välttämättömien tietojen keräämistä. Reaaliaikainen API-integraatio estää ylilomaoton lomakkeen lähetysvaiheen aikana — ennen kuin.

June 5, 20267 min lukuaika
GDPR data minimizationArticle 5real-time detectionAPI integrationform validation

GDPR:n tietojen minimointi: Reaaliaikainen API

Päivitetty vuodelle 2026

GDPR:n artikla 5(1)(c) sanoo: kerää vain mitä tarvitset. Tämä on tietojen minimointisääntö. Useimmat tiimit rikkovat sitä lomakesuunnittelun kautta, ei pahantahtoisuudesta. Vapaan tekstin kentät keräävät nimiä, osoitteita ja tunnistenumeroita, joita kukaan ei suunnitellut.

Tietokannan siivoaminen myöhemmin ei korjaa asiaa. Rikkomus tapahtui, kun keräsit tiedot. Niiden pysäyttäminen lähteessä on ainoa todellinen ratkaisu. Reaaliaikainen API-tarkistus lomakkeen lähetyksen yhteydessä estää ylikeräämisen ennen kuin se alkaa.

Katso vaatimustenmukaisuusyhteenvetomme ja tietoturvakäytäntömme siitä, miten tuemme GDPR:n artiklaa 5.

Miksi lomakkeet keräävät liikaa

Verkkosovelluksissa olevat vapaan tekstin kentät keräävät PII:tä, jota kukaan ei suunnitellut:

  • Tukipyynnön "syy"-kentät täytettynä sairaanhistorioilla ja vakuutusnumeroilla
  • Kyselylomakkeen "muut kommentit" -osiot sisältävät kokonaisia nimiä ja puhelinnumeroita
  • Henkilöstöhallinnon "muistiinpanot"-sarakkeet sisältävät vuosien epästrukturoituja henkilötietoja
  • Tilauksen "huomautukset"-kentät sisältävät asiakastunnistenumeroita, jotka on syötetty ongelmien ratkaisemiseksi

Minimointisääntö edellyttää, että tämä PII ei koskaan päädy järjestelmiisi. Jälkikäteinen siivous hoitaa oireen. Reaaliaikainen tunnistus poistaa syyn.

Miksi jälkikäteinen siivous ei riitä

Tallennetun PII:n siivoustiimit kohtaavat neljä ongelmaa.

Täydellisyys. Mallivertailu löytää ilmeisen PII:n, kuten sähköpostiosoitteet ja tunnistenumerot. Se jättää huomiotta kontekstiperustaisia viittauksia. "Sisarellani Sophialla oli sama ongelma" sisältää nimen, jonka useimmat skannaukset ohittavat.

Oikeudellinen ajoitus. Rikkomus tapahtuu keräyshetkellä. Tietojen siivous kuukausia myöhemmin ei korjaa sitä. Jos viranomainen tarkistaa ajanjakson, jolloin tietoja pidettiin, rikkomus on jo kirjattu.

Epätäydellinen poisto. Tietokannat varmuuskopioidaan. Järjestelmät kirjoittavat lokeja. Analytiikkatyökalut vievät tietoja. Vaikka poistaisit pääkannasta, kopioita voi jäädä varmuuskopiotiedostoihin ja tarkistuslogeihin.

Rikkomusaltistuminen. Keräämisen ja siivoomisen välillä ylimääräinen PII istuu järjestelmissäsi. Rikkomus tuona aikana asettaa ylikerätyn tiedon uhanalaiseksi.

Keräämisen estäminen lähteessä ratkaisee kaikki neljä. Tiedot, jotka eivät koskaan päädy sisään, eivät voi vuotua, eivät tarvitse poistamista eivätkä laske rikkomukseksi.

Tunnistusmallit lomakkeiston validoinnille

On kolme tapaa lisätä reaaliaikainen PII-tunnistus lomakkeeseen.

Asiakaspuoli (Chrome-laajennus). Laajennus seuraa liittämistapahtumia selainkentissä. Kun käyttäjä liittää tekstiä, jossa on PII, se korostaa kohteet välittömästi. Käyttäjä poistaa ne ennen lähettämistä. API-kutsua ei tarvita — tunnistus suoritetaan paikallisesti. Katso sanasto kohdetyyppien määritelmiin.

Palvelinpuoli (API-integraatio). Lomake lähettää palvelimellesi. Ennen tietokantakirjausta koodisi kutsuu tunnistus-API:ta. API palauttaa kohdetyypit luottamuspistein. Korkean luottamuksen osumaat estävät lähetyksen selkeällä viestillä. Keskitason luottamuksen osumaat kehottavat tarkistusvaiheeseen. Tieto on puhtaana ennen tallentamista.

Hybridi (suositeltu). Asiakaspuolen korostus antaa käyttäjille nopean palautteen. Palvelinpuolen tarkistukset tarjoavat vaatimustenmukaisuuden takuun. Jos käyttäjä jättää asiakasvaroituksen huomiotta, palvelinpuolen tarkistus havaitsee silti PII:n. Mikään ei pääse tietokantaan tarkistamattomana. Katso UKK yleisille kysymyksille tunnistuskynnysarvoista.

Esimerkki: Terveydenhuollon potilasportaali

Potilasportaali antaa potilaiden kuvailla oireitaan vapaan tekstin kentässä ennen ajanvarausta. Kentässä saa säännöllisesti merkintöjä, jotka sisältävät muiden potilaiden nimiä, tunnistenumeroita ja kotiosoitteita. Mikään tästä ei kuulu ajanvarausjärjestelmään.

Ennen reaaliaikaista tunnistusta:

  • PII oirekentässä: noin 12 % lähetyksistä
  • Siivousmenetelmä: viikoittainen eräprosessi
  • Vaatimustenmukaisuusstatus: reaktiivinen — artiklan 5(1)(c) rikkomus tapahtui keräyksen yhteydessä

API-integraation jälkeen lähetyksen yhteydessä:

  • API havaitsee korkean luottamustason PII:n ennen kirjoittamista tietokantaan
  • Potilas näkee: "Viestisi näyttää sisältävän henkilötietoja. Poista ne ennen lähettämistä."
  • Potilas tarkistaa ja lähettää uudelleen
  • Tietokanta vastaanottaa vain oirekuvauksen

Tässä skenaariossa PII kentässä laski noin 12 prosentista alle 1 prosenttiin lähetyksistä. Vaatimustenmukaisuus osoitetaan nyt palvelinpuolen tunnistuslokeilla eikä jälkikäteisillä siivousajoilla.

Tarkistustietueet keräyspisteessä

Viranomaiset kohtelevat reaktiivisia tiimejä eri tavalla kuin niitä, joilla on kontrolleja käytössä. GDPR:n artikla 25 — suojaus suunnittelulla ja oletuksena — palkitsee jälkimmäiset.

Keräyspisteen tunnistus luo hyödyllisiä tarkistustietueita:

  • Tunnistusloki. Jokainen lomakeskannaus tallennetaan löydettyjen kohdetyyppien, luottamuspisteiden, suoritetun toimenpiteen ja tuloksen kanssa.
  • Kuukausittaiset raportit. Yhteenvedot näyttävät tunnistusasteen kentän ja kohdetyypin mukaan sekä kuinka käyttäjät reagoivat.
  • Konfiguraatiotietueet. Kynnysasetukset, katetut kentät ja tarkkaillut kohdetyypit — tämä osoittaa selkeän, hallitun käytännön.

Nämä tietueet auttavat viranomaistarkistuksissa. Ne tukevat myös sisäistä tarkistusta ja käsittelyrekisteriä. Katso tapaustutkimuksemme esimerkkejä keräyspisteen kontrolleista käytännössä.

Tekoälytyökalut ja tietojen minimointi

Tukihenkilöstö liittää usein asiakkaiden sähköposteja tekoälyn luonnostyökaluihin. Nämä sähköpostit voivat sisältää nimiä, osoitteita ja tilinumeroita. Niiden lähettäminen tekoälymallille voi ylittää sen, mitä tarvitaan.

MCP-palvelin lisää tunnistusvaiheen ennen kuin teksti saavuttaa mallin. Asiakkaiden nimistä tulee [CUSTOMER]. Tarkat yksityiskohdat puhdistetaan. Tekoäly luonnostelee vastauksen puhdistetun tekstin perusteella. Agentti lisää takaisin vain sen, mitä vastaus tarvitsee.

Tämä täyttää tietojen minimointisäännön tekoälykäytölle. Malli saa vain sen, mitä on välttämätöntä — mikä on yleensä ei lainkaan PII:tä. Katso kohteet saadaksesi täydellisen luettelon havaitsemistamme kohdetyypeistä.

Lähteet

Valmiina suojaamaan tietojasi?

Aloita PII-anonymisointi yli 285 entiteettityypillä 48 kielellä.

About this page

We update this page when our platform or the law changes.

Read our founder note for how we work.

Each change shows up in the timestamp at the top.

Related reading

We follow these rules

  • GDPR (EU 2016/679).
  • ISO/IEC 27001:2022.
  • NIS2 (EU 2022/2555).
  • HIPAA safe harbor under 45 CFR § 164.514(b)(2).

Our promise

We do not sell your data.

We do not train models on your text.

We store your files in Germany.

You can delete your account at any time.

You own your work.

Where we run

Our servers live in Falkenstein, Germany.

We use Hetzner. They hold ISO 27001 certification.

All data stays in the EU.

Backups run every day.

Need help?

Email support@anonym.legal.

We reply within one business day.

How we test

We run a full check suite on every release.

Each surface gets its own sweep script and report.

Human reviewers spot-check the output each week.

We track recall and precision on a labelled set.

Bad runs block the deploy.

What we never do

  • We never sell your information to third parties.
  • We never train models on what you upload.
  • We never keep your work after you delete it.
  • We never share keys with any outside firm.
  • We never run ads inside the product.

Plans in plain words

We sell credits, not seats.

One credit covers one short job.

Long jobs use a few credits each.

You can top up at any time.

Unused credits roll over each month.

Read the plans page for current rates.

Who built this

A small team of engineers and lawyers built this.

We ship from Europe and work in the open.

Our founder note spells out why we started.

Where to start

How the parts fit

A browser add-on cleans text inside Chrome.

A Word plug-in handles drafts in Office.

A small desktop tool works on whole folders.

An agent protocol link feeds large models safely.

All four share one core engine and one rule set.

Words from our team

We started this work after a lunch about cookies.

One friend kept getting odd ads on her phone.

We asked why a court file leaked through a draft.

We sketched the first build on a napkin that week.

By month three we had a tiny demo for a friend.

She used it on her first case the next day.

Common questions we hear

Can the tool read scanned PDFs? Yes, with OCR.

Does it work on long files? Yes, in small chunks.

Can I roll my own rule set? Yes, save it as a preset.

Does it run offline? The desktop build runs offline.

Do you keep my files? No, the cloud build wipes after each run.

Will it learn from my work? No, we never train on inputs.

A short tour of the workflow

Upload a file or paste a snippet of prose.

Pick the entities you want gone from the draft.

Choose a method: replace, mask, hash, encrypt, or redact.

Press run and watch the side panel show each hit.

Skim the result and tweak any rule that misfired.

Save the cleaned file or send it to a teammate.