Vift People

Zero-Data retention prompt: Sikring af komplet anonymitet under søgning

Af Mikkel Vivelsted · Se profil

Prompten gennemgår din søgefunktion felt for felt: hvilke persondata der sendes ud, hvordan de maskeres før afsendelse, og om leverandøren gemmer dem. Du får en maskeringsplan, skarpe spørgsmål til leverandøren og testtilfælde, der afslører de læk du har overset.

Uden en præcis prompt svarer AI'en med generelle GDPR-råd. Den overser, at søgestrengen i sig selv kan udpege en person, at dine egne logs gemmer den, og at "vi træner ikke på dine data" ikke er det samme som "vi gemmer dem ikke".

Kode & udviklingChatGPTClaudeGeminiCopilotUdgivet 1. august 2026
Jeg stiller 7 korte spørgsmål — så er prompten din.

Prompten

3 af 7 klar3 af 7 klar
Du er privacy engineer med mange års erfaring i dataminimering i søge- og AI-integrationer. Du svarer teknisk og konkret. Du holder dig til min opsætning og springer generelle GDPR-forelæsninger over.

Opgave: gennemgå min søgefunktion. Fortæl mig, hvad der skal ændres, før en søgning ikke længere kan knyttes til en person — hverken af leverandøren, af mine egne systemer eller af nogen der får fat i loggen.

Min opsætning:
- Hvad søgefunktionen gør: 
- Data der sendes med hver forespørgsel: 
- Leverandør, model og aftale: 
- Hvad vi selv gemmer: 
- Følsomhed i data: 
- Ønsket maskering: 
- Svarform: 

Krav til dit svar:
1. Lav et datakort over alt, der forlader mit system. Marker hvert felt som direkte identifikator, indirekte identifikator eller neutralt.
2. Tilføj de felter jeg ikke selv nævnte, men som følger med alligevel: IP-adresse, tidsstempler, request-id, bruger- eller nøgle-id, og selve modelsvaret.
3. Peg på, hvor søgestrengen i sig selv udpeger en person. Nævn de kombinationer der re-identificerer, selv når navne er fjernet.
4. Giv en maskeringsplan felt for felt efter . Skriv for hvert felt, hvad det koster i søgekvalitet.
5. Sig lige ud, om resultatet er anonymt eller kun pseudonymt. Findes der en nøgle hos mig, er data stadig personoplysninger — skriv det.
6. Gennemgå opbevaring hos leverandøren. Hvad kræver nul opbevaring i praksis, hvilke endepunkter er dækket, og hvad falder udenfor (filupload, batch, misbrugsovervågning, sikkerhedslogs)?
7. Skriv 5 spørgsmål jeg skal stille leverandøren skriftligt. Formulér dem, så de kun kan besvares med ja, nej eller et tal.
8. Find lækagerne på min egen side: applikationslog, fejlsporing, APM, cache, backup, analytics og URL-parametre.
9. Giv 5 testtilfælde der får maskeringen til at fejle. Brug danske navne, CPR uden bindestreg, navn skjult i en e-mailadresse og en sjælden stillingsbetegnelse.
10. Slut med de 3 største tilbageværende risici i rækkefølge. Én linje pr. risiko om, hvad jeg gør først.

Skriv i -form. Ingen indledning og ingen generelle forbehold. Stil op til 3 spørgsmål før du svarer, hvis noget afgørende mangler.

—
Prompt af Mikkel Vivelsted · https://viftpeople.com/people/mikkel-vivelsted-a18f31

Flere prompts fra Mikkel Vivelsted

Sådan brugte Mikkel den selv

Sådan udfyldte Mikkel felterne

  • Hvad søgefunktionen gør: Rekrutteringskunder skriver en fritekstsøgning, fx "erfaren systemadministrator omkring Aarhus". Vi henter de 50 bedste kandidatprofiler fra vores database og sender søgestreng plus profiler til en LLM, der rangerer og begrunder rækkefølgen.
  • Data der sendes med hver forespørgsel: søgestreng, kandidat-id, fulde navn, e-mailadresse, by og postnummer, fødselsår, nuværende stilling og arbejdsgiver, fritekstfeltet "om mig", samt bruger-id på den der søger.
  • Leverandør, model og aftale: stor amerikansk LLM-udbyder via API, standard pay-as-you-go-konto, databehandleraftale underskrevet, ingen særskilt aftale om opbevaring.
  • Hvad vi selv gemmer: hele request-body logges 30 dage i vores APM. Fejl sendes til fejlsporing med fuld payload. Webserverens access-log gemmer søgestrengen som query-parameter.
  • Følsomhed i data: almindelige personoplysninger
  • Ønsket maskering: pladsholdere med lokal tilbagemapning
  • Svarform: tjekliste jeg kan arbejde ud fra

Det svarede AI'en

DATAKORT (forkortet)

  • Fulde navn, e-mail: direkte identifikator. Skal aldrig sendes.
  • Kandidat-id: direkte, hvis id'et er dit eget databasenøgle. Brug et engangs-id pr. forespørgsel.
  • Fødselsår + postnummer + arbejdsgiver: indirekte. Tilsammen peger de ofte på én person.
  • Fritekst "om mig": indirekte og værst. Folk skriver selv navn, arbejdsplads og fritidsklub.
  • Søgestreng: indirekte. "systemadministrator omkring Aarhus" er harmløst. "vikaren der stoppede hos [firma] i marts" er ikke.

DET DU IKKE NÆVNTE, MEN SENDER ALLIGEVEL

  • Din servers IP og din API-nøgle identificerer dig som kunde, ikke kandidaten. Det er fint.
  • Bruger-id på den der søger: tag det ud. Det knytter en navngiven rekrutterer til hver forespørgsel.
  • Modelsvaret indeholder begrundelser med navne, hvis navne kom med ind.

MASKERINGSPLAN (pladsholdere, tilbagemapning kun hos dig)

  • Navn → [KANDIDAT_1]. Koster intet i rangering.
  • E-mail → fjernes helt. Bruges ikke til rangering.
  • Fødselsår → erfaringsinterval, fx "10-15 år". Koster lidt præcision, fjerner meget risiko.
  • Arbejdsgiver → branche og størrelse, fx "kommune, over 1.000 ansatte". Her koster det mest.
  • "Om mig" → kør navne-, adresse- og firmagenkendelse på teksten, før den forlader dit netværk.

ÆRLIG VURDERING
Det er pseudonymisering, ikke anonymisering. Du gemmer nøglen der kobler [KANDIDAT_1] til en person. Data er stadig personoplysninger. Anonymt bliver det først, hvis nøglen ikke findes.

OPBEVARING HOS LEVERANDØREN
På en almindelig konto gemmes forespørgsler typisk en periode til misbrugsovervågning. Nul opbevaring er en aftale, ikke en knap, og den dækker sjældent filupload, batch-kørsler og gemt agent-tilstand. Sikkerhedslogs kører videre uanset.

SPØRGSMÅL TIL LEVERANDØREN

  1. Gemmes prompt og svar på disk efter svaret er sendt — ja eller nej?
  2. Hvor mange dage gemmes data til misbrugsovervågning?
  3. Hvilke endepunkter er IKKE dækket af nul opbevaring?
  4. Har mennesker adgang til indholdet af mine forespørgsler — ja eller nej?
  5. I hvilket land ligger behandlingen?

DINE EGNE LÆK (start her)

  • Access-loggen gemmer søgestrengen i URL'en. Flyt søgningen til POST i dag.
  • Fejlsporingen gemmer fuld payload i skyen. Slå payload fra, eller maskér før afsendelse.
  • APM med 30 dages request-body er reelt et kandidatregister uden formål.

TESTTILFÆLDE DER FÅR MASKERINGEN TIL AT FEJLE

  1. "Mette Nørgaard" — æ, ø, å slipper ofte gennem navnegenkendelse.
  2. CPR skrevet som 0101801234, uden bindestreg.
  3. [email protected] — navnet ligger i adressen.
  4. "Marts" og "April" som fornavne.
  5. "eneste kommunaldirektør på Læsø" — udpeger én person uden et eneste navn.

DE 3 STØRSTE RISICI

  1. Søgestrengen i access-loggen. Skift til POST først.
  2. Fritekstfeltet sendt råt. Sæt maskering ind før API-kaldet, ikke efter.
  3. Ingen aftale om nul opbevaring. Skriv til leverandøren i denne uge.

Gå ikke glip af de bedste danske AI-prompts — som foretrukken kilde prioriterer Google vores indhold til dig, også i AI-svarene.

Gør Vift People til din foretrukne kilde på Google

Åbner Googles egne indstillinger i et nyt faneblad — ét flueben, så er du med.

Sider som denne bliver fundet, fordi nogen søger. DU kan blive fundet på præcis samme måde.

Vi bygger Vift People, fordi det du er god til, fortjener at kunne findes — ikke at drukne i feeds og støj.

Hvad er du bedre til end de fleste?

Det du skriver her, bliver det første kort på din side — du skal kun bruge navn og mail, og det tager to minutter. Og Vift People er nyt: de første med er også de første, der bliver fundet.

Prompt af Mikkel Vivelsted

Ekspert i Cyber Security og AI

Har du brug for hjælp til mere end prompten kan klare? Mikkel er klar.

Find mig på Vift People