Veriprompt Docs

Appearance

Meeting GDPR obligations ​

Putting a prompt through an external AI provider is processing personal data, and often transferring it to a third country. GDPR does not have an exception for "we were just asking a model". The obligations that bite hardest in practice are data minimisation, retention limits, the right of access, the right to erasure, and being able to show a supervisory authority what actually happened.

VeriPrompt addresses each of these directly:

ObligationWhereWhat it gives you
Data minimisation (Art. 5)/shield/sanitizePersonal data is detected and tokenized before the prompt leaves the perimeter. The provider processes a placeholder; you get the real value back.
Restricting transfers (Art. 44+)/ranger/routingRouting policies keep prompts inside chosen regions and providers, so no transfer happens that you have not decided on.
Storage limitation (Art. 5)/admin/prompt-logsExecution logs carry a retention period you set, rather than accumulating forever.
Right of access & erasure (Art. 15, 17)/admin/prompt-logsLogs are searchable and deletable per subject, so a request can actually be answered.
Accountability (Art. 5(2), 30)/admin/audit-logsA record of who changed which policy or permission, and when.

In short: this is what you need for data protection compliance when personal data passes through prompts — lawful processing, minimisation, retention limits, and the ability to answer a data subject.

Where to start. Sanitization is the highest-leverage control, because data that never left the perimeter creates no transfer to justify, no retention to limit and nothing to erase downstream. Configure it first, then routing policy, then retention.

The minimisation-first argument ​

The cheapest way to satisfy an obligation is to not incur it.

If a prompt containing a customer's name and address is sanitized to [PERSON_1] and [ADDRESS_1] before it leaves, then the provider never processed that person's data. The transfer question, the sub-processor question and the erasure question all shrink to the data VeriPrompt itself holds — which is inside your perimeter and under your retention policy.

This is why the order matters: sanitize, then decide routing for what is left, then set retention on the record of what happened. Working the other way round — long retention plus careful transfer paperwork on unsanitized prompts — is more work and protects less.

See PII sanitization for detection coverage and how de-tokenization restores the response.

Retention, and why it is not one number ​

Two different things are retained, and they should not share a period:

  • Execution logs (/admin/prompt-logs) — what was run and against which provider. These support access and erasure requests, so they need to live long enough to be useful and no longer.
  • Audit records (/admin/audit-logs) — configuration and permission changes. These carry no prompt content and are usually kept longer, because they are the evidence of accountability rather than a store of personal data.

Setting a single long retention across both is the common mistake: it manufactures a personal-data surface in order to keep an administrative record.

Answering a subject request ​

  1. Search /admin/prompt-logs for the subject's identifiers.
  2. Export the matching records for the access response.
  3. Delete them for an erasure request. Sanitized values were never sent to the provider, so there is nothing to chase downstream for those fields.
  4. /admin/audit-logs shows the deletion happened, which is what closes the file.