By · Last updated 2026-06-05

Tornar al BlogTècnic

RGPD en registres d'aplicacio: compliment de dades personals JSON

Els registres d'aplicacio contenen adreces de correu electronic, IPs i numeros de compte de clients que l'Article 5(1)(e) del RGPD exigeix gestionar.

June 5, 20266 min llegit
API logsGDPR complianceJSON anonymizationobservabilitystorage limitation

El risc silencis del RGPD en el vostre sistema de registres

Actualitzat per al 2026

La majoria dels equips comproven la seva base de dades per detectar informacio personal. Menys ho fan per al seu sistema de registres.

L'Article 5(1)(e) del RGPD limita el temps que podeu emmagatzemar informacio personal. Per a les bases de dades, els equips estableixen politiques i executen tasques d'eliminacio. Per als fitxers de registre, la regla es mes senzilla: conserveu-ho tot durant 90 dies per a la depuracio.

El problema? Aquests registres contenen informacio personal. Les entrades de peticions contenen correus electronics d'usuaris. Les captures d'error contenen valors d'entrada en brut. Les entrades d'acces contenen adreces IP. Cadascuna d'aquestes compta com a informacio personal en virtut del RGPD. El vostre equip necessita una base legal i un pla de retencio per a cadascuna.

Que acaba als vostres fitxers de registre

El registre estandard d'aplicacions web incorpora una amplia gamma de dades personals.

Registres d'acces (nginx/Apache):

  • Adreces IP: informacio personal segons la guia del CEPD
  • Cadenes user-agent: poden permetre la identificacio del dispositiu
  • Tokens de sessio: si s'escriuen a la sortida

Registres d'aplicacio (JSON estructurat):

  • IDs d'usuari i adreces de correu electronic
  • Errors d'entrada: sovint inclouen el valor invalid en brut, que pot ser informacio real de l'usuari
  • Esdeveniments de negoci: IDs de comanda vinculats a comptes de clients
  • Cerques: poden contenir noms o adreces

Registres de la passarel·la API:

  • Capaleres d'autenticacio: parcialment capturades en algunes configuracions
  • Parametres de consulta: poden portar IDs d'usuari, noms o correus electronics
  • Cossos de peticions i respostes: presents en configuracions de nivell de depuracio

Entrades d'auditoria de base de dades:

  • Consultes SQL amb clausules WHERE com email = 'usuari@example.com'
  • Valors personals literals en parametres de consulta

Aixo no es fa intencionadament. Es un efecte secundari dels registres dissenyats per a la depuracio, no per al RGPD.

Guia del CEPD sobre les adreces IP

El Comitè Europeu de Proteccio de Dades afirma que les adreces IP son informacio personal. Els ISP les poden vincular als seus abonats. Dins d'una organitzacio, poden identificar usuaris especifics.

L'impacte es directe. Els registres d'acces amb adreces IP son registres personals. Conservar la sortida de nginx durant 12 mesos significa conservar informacio personal durant 12 mesos. Aixo necessita una base legal en virtut de l'Article 6. Tambe necessita que el periode de retencio coincideixi amb la vostra finalitat declarada.

La majoria dels equips ometen aquest pas. "Conservem les entrades durant 90 dies perque ho diu seguretat" es una regla general. No es una revisio de l'Article 5(1)(e) del RGPD. Vegeu la nostra descripcio general del compliment legal per a com s'integra aixo en un programa mes ampli.

Com assolir el compliment

La via practica per a la majoria d'equips no es reduir les finestres de retencio. Les raons operatives i de seguretat per a finestres mes llargues son reals. El camino millor es emmascarar els registres abans de l'emmagatzematge a llarg termini.

Un model per nivells funciona be.

0-7 dies: Registres bruts complets per a la depuracio activa. Set dies es prou curt per a la majoria d'equips.

7-90 dies: Registres emmescarats per a l'analisi de tendències i la revisio de seguretat. Les adreces IP es substitueixen. Els correus electronics dels usuaris es converteixen en tokens estables. Els numeros de compte s'emmascaren. Els camps clau --marques de temps, codis d'error, latència, punts finals-- es mantenen tal com estan.

90+ dies (si cal): Nomes sortida agregada. Recomptes d'esdeveniments, taxes d'error, intervals de latència. No resten registres a nivell d'usuari.

La informacio personal s'atura als set dies. La sortida agregada pot continuar endavant sense exposar ningu. Vegeu Seguretat i Compliment per a mes detalls.

Manteniu l'estructura intacta per al monitoratge

Un bon emmascarament manté l'estructura JSON intacta. Nomes substitueix el contingut. Aixo manté la sortida util per a la depuracio i les alertes.

Sense canvis:

  • Claus i anidament JSON
  • Marques de temps i ordre temporal
  • Tipus d'error i codis d'estat HTTP
  • Mètodes HTTP, rutes i valors de latència
  • Tipus d'esdeveniments de negoci

Substituits:

  • Adreces de correu electronic -> token estable per original (p. ex. usuari1@example.com)
  • Adreces IP -> intervals RFC 5737 (192.0.2.x)
  • Numeros de compte -> COMP_XXXXX
  • Numeros de telefon -> +XX XXX XXX XXXX
  • Noms en text d'error -> [PERSONA]

Els tokens estables mantenen els rastres utils. Un rastre per a usuari1@example.com a traves de 40 entrades funciona igual que l'original. Les metriques agregades --taxes d'error, latència, rendiment-- no necessiten cap informacio personal. Vegeu el Glossari per als termes pseudonimitzacio i anonimitzacio.

Tres maneres d'integrar-ho

Tres patrons cobreixen la majoria d'equips d'enginyeria.

Opcio 1 -- Emmascarament en el pipeline: Fluentd o Logstash intercepta cada linia abans d'enviar-la. Un pas d'emmascarament s'executa en linia. Elastic o Datadog nomes rep registres nets. No calen canvis al codi de l'aplicacio.

Opcio 2 -- Lot nocturn: Els registres bruts arriben a l'emmagatzematge local. Un treball nocturn emmascara la sortida del dia anterior i elimina la versio bruta. Els registres emmascarats van a l'emmagatzematge a llarg termini. La sortida bruta es conserva nomes set dies.

Opcio 3 -- Emmascarament previe a la comparticio: Els registres bruts romanen interns amb controls d'acces estrictes. Abans de compartir amb provadors de penetracio o contractistes externs, executeu un pas d'emmascarament. Les parts externes sempre reben versions netes.

Per a la documentacio del RGPD, l'emmascarament es una "mesura tècnica" en virtut de l'Article 32. Registreu l'eina, la seva configuracio i la vostra politica de retencio al vostre Registre d'Activitats de Tractament (RAT) en virtut de l'Article 30. Vegeu les nostres preguntes freqüents per a preguntes habituals sobre el RAT.

Voleu un exemple real? Consulteu els casos d'estudi per a detalls d'implementacio concrets. Tambe podeu revisar els nostres preus per veure quin pla inclou pipelines d'emmascarament integrats.

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.