By · Last updated 2026-06-05

Tornar al BlogGDPR i Compliment

Minimitzacio de Dades del RGPD: API en Temps Real

L'Article 5(1)(c) del RGPD requereix recollir nomes les dades necessaries. La integracio d'API en temps real preveu la sobrerecollida en l'etapa d'enviament del formulari -- abans que les dades entrin als sistemes.

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

Minimitzacio de Dades del RGPD: API en Temps Real

Actualitzat per al 2026

L'Article 5(1)(c) del RGPD diu recolliu nomes el que necessiteu. Aquesta es la norma de minimitzacio de dades. La majoria d'equips la incompleixen per culpa del disseny de formularis, no de mala intencio. Els camps de text lliure recullen noms, adreces i numeros d'identificacio que ningu havia planejat.

Netejar la base de dades despres no ho soluciona. La infrac. va passar quan vareu recollir les dades. Aturar-ho a la font es l'unica solucio real. Una comprovacio d'API en temps real en el moment d'enviament del formulari atura la sobrerecollida abans que comenci.

Vegeu la nostra visio general de compliment i les practiques de seguretat per a com suportem l'Article 5 del RGPD.

Per que els Formularis Sobrereculllen

Els camps de text lliure en aplicacions web reuneixen PII que ningu havia planejat:

  • Camps de "rao" de tiquet de suport plens d'historials medics i numeros d'asseguranca
  • Seccions de "altres comentaris" d'enquestes amb noms complets i numeros de telefon
  • Columnes de "notes" de RRHH amb anys de detalls personals no estructurats
  • Camps de "notes" de comandes amb numeros d'ID de client introduits per ajudar amb problemes

La norma de minimitzacio requereix que aquesta PII mai entri als vostres sistemes. La neteja retroactiva tracta el simptoma. La deteccio en temps real elimina la causa.

Per que la Neteja Retroactiva es Insuficient

Els equips que netegen PII emmagatzemada s'enfronten a quatre problemes.

Completesa. La correspondencia de patrons troba PII obvia com adreces de correu electronic i numeros d'ID. Es perd les referencies basades en context. "La meva germana Sofia va tenir el mateix problema" conte un nom que la majoria d'escaneigs ometen.

Temporalitat legal. La infrac. passa en el moment de la recollida. Netejar les dades mesos despres no ho soluciona. Si un regulador revisa el periode en que les dades es van mantenir, la violacio ja esta registrada.

Eliminacio incompleta. Les bases de dades fan copies de seguretat. Els sistemes escriuen registres. Les eines d'analisi exporten dades. Fins i tot despres d'eliminar de la base de dades principal, les copies poden romandre en arxius de copia de seguretat i registres d'auditoria.

Exposicio a violacions. Entre la recollida i la neteja, la PII extra esta als vostres sistemes. Una violacio durant aquesta finestra posa les dades sobrerecollides en l'abast.

Aturar la recollida a la font soluciona els quatre. Les dades que mai entren no poden ser violades, no necessiten eliminacio i no compten com a infrac.

Patrons de Deteccio per a la Validacio de Formularis

Hi ha tres maneres d'afegir deteccio de PII en temps real a un formulari.

Costat del client (Extensio de Chrome). L'extensio vigila els esdeveniments d'enganxar en els camps del navegador. Quan un usuari enganxa text amb PII, destaca les entitats immediatament. L'usuari les elimina abans d'enviar. No cal cap crida d'API -- la deteccio s'executa localment. Vegeu el glossari per a les definicions dels tipus d'entitats.

Costat del servidor (integracio d'API). El formulari envia al vostre servidor. Abans de l'escriptura a la base de dades, el vostre codi crida l'API de deteccio. L'API retorna els tipus d'entitats amb puntuacions de confiana. Les coincidencies d'alta confiana bloquegen l'enviament amb un missatge clar. Les coincidencies de confiana mitjana sol.liciten un pas de revisio. Les dades estan netes abans d'emmagatzemar-se.

Hibrid (recomanat). La destacació del costat del client dona als usuaris retroalimentacio rapida. Les comprovacions del costat del servidor proporcionen la garantia de compliment. Si un usuari ignora l'avis del client, la comprovació del servidor encara captura la PII. Res arriba a la base de dades sense comprovar. Vegeu el nostre FAQ per a preguntes frequents sobre els llindars de deteccio.

Exemple: Portal de Pacients de Sanitat

Un portal de pacients permet als pacients descriure els seus simptomes en un camp de text lliure abans de reservar. El camp rep regularment entrades que inclouen noms d'altres pacients, numeros d'ID i adreces domiciliaries. Res d'aixo pertany al sistema de programacio.

Abans de la deteccio en temps real:

  • PII al camp de simptomes: aproximadament el 12% dels enviaments
  • Metode de neteja: proces per lots setmanal
  • Estat de compliment: reactiu -- la infrac. de l'Article 5(1)(c) es va produir en el moment de la recollida

Despres de la integracio d'API en l'enviament:

  • L'API detecta PII d'alta confiana abans de qualsevol escriptura a la base de dades
  • El pacient veu: "El vostre missatge sembla contenir informacio personal. Elimineu-la abans d'enviar."
  • El pacient revisa i reenvia
  • La base de dades rep nomes la descripcio del simptoma

En aquest escenari, la PII al camp va baixar de aproximadament el 12% a menys de l'1% dels enviaments. El compliment es demostra ara a traves de registres de deteccio del costat del servidor en lloc de cicles de neteja retrospectius.

Registres d'Auditoria en el Punt de Recollida

Els reguladors tracten els equips reactius de manera diferent als que tenen controls en vigor. L'Article 25 del RGPD -- proteccio pel disseny i per defecte -- premia els darrers.

La deteccio en el punt de recollida crea registres d'auditoria utils:

  • Registre de deteccio. Cada escaneig de formulari es desa amb els tipus d'entitats trobats, les puntuacions de confiana, l'accio presa i el resultat.
  • Informes mensuals. Els resums mostren la taxa de deteccio per camp i tipus d'entitat, i com responen els usuaris.
  • Registres de configuracio. La configuracio de llindars, els camps coberts i els tipus d'entitats vigilats -- aixo demostra una politica clara i gestionada.

Aquests registres ajuden en les revisions del regulador. Tambe donen suport a la auditoria interna i als registres de tractament. Vegeu els nostres casos d'estudi per a exemples de controls en el punt de recollida en practica.

Eines d'IA i Minimitzacio de Dades

Els agents de suport sovint enganxen correus electrics de clients a eines de redaccio d'IA. Aquests correus poden contenir noms, adreces i numeros de compte. Enviar aixo a un model d'IA pot anar mes enlla del que es necessari.

El Servidor MCP afegeix un pas de deteccio abans que el text arribi al model. Els noms de clients es converteixen en [CUSTOMER]. Els detalls especifics es netegen. L'IA redacta una resposta fent servir el text netejat. L'agent afegeix nomes el que la resposta necessita.

Aixo compleix la norma de minimitzacio de dades per a l'us de la IA. El model obte nomes el que es necessari -- que habitualment no es cap PII. Vegeu entitats per a la llista completa de tipus d'entitats que detectem.

Fonts

Preparat per protegir les vostres dades?

Comenceu a anonimitzar PII amb més de 285 tipus d'entitats en 48 idiomes.

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.