Skip to Content

GDPR

VeriProof is designed to help you build GDPR-compliant AI systems, not just to comply with GDPR in its own data handling. This page covers both: what VeriProof does with your data under GDPR, and how VeriProof’s features help you satisfy GDPR Article requirements in your own AI pipelines.

A Data Processing Agreement (DPA) is available for all paying customers. See DPA for standard terms, or contact legal@veriproof.app to negotiate custom terms.


Roles and Responsibilities

RolePartyScope
Data ControllerYour organisationYou determine what data is captured and for what purpose
Data ProcessorVeriProofWe process the data you send us under your instructions
Sub-processorMicrosoft Azure, Solana validatorsInfrastructure and blockchain anchoring sub-services

VeriProof acts as a data processor. What data gets captured — the prompts, outputs, and metadata in your AI pipelines — is determined entirely by your SDK configuration and adapter instrumentation. If you don’t send it, VeriProof doesn’t have it.


Lawful Basis

VeriProof’s audit and compliance features are typically used under one of two lawful bases:

  • Legitimate interests (Article 6(1)(f)): Maintaining an immutable audit trail of AI decisions for accountability, governance, and legal defensibility
  • Legal obligation (Article 6(1)(c)): Satisfying documentation requirements under regulations such as the EU AI Act, HIPAA, or financial services rules

The appropriate lawful basis for processing in your pipelines is your responsibility as the data controller. If you’re building AI systems that process personal data, work with your legal team to establish the correct basis before going live.


Article 17 — Right to Erasure

VeriProof implements GDPR Article 17 (Right to Erasure) using cryptographic erasure rather than physical data deletion. This approach satisfies the requirement to render data “no longer identifiable” while preserving the structural integrity of blockchain anchoring records, which cannot be removed from the Solana ledger.

How Cryptographic Erasure Works

Each data subject whose sessions you capture using VeriProof is represented by a DataSubject record linked to your organisation. Session commitments are computed using a key derived from:

  1. A master pepper in Azure Key Vault (tenant-scoped)
  2. A per-data-subject salt stored in the database

When erasure is executed, the per-subject salt is deleted. Without the salt, the Level 2 derivation key cannot be reconstructed — which means the commitment can no longer be computed or verified. The session record and blockchain anchor remain structurally intact, but the content is permanently inaccessible and unverifiable.

Master pepper (Key Vault) HKDF-SHA256 (info: customer_id) ← Level 1 key HKDF-SHA256 (info: data_subject_id + salt) ← Level 2 key ─── SALT DELETED ON ERASURE HMAC-SHA256 (input: session JSON) ← Commitment / Merkle root

Erasure Workflow

Register the data subject

When you create an AI session for a specific user, call the Customer Portal API to register or retrieve a DataSubject record for that user’s external identifier:

subject = client.data_subjects.create_or_get( external_id="user_12345", # your internal user ID display_name="User 12345", # optional )

Capture sessions linked to the subject

Submit sessions with the data_subject_id field set. VeriProof links the session commitment to the subject’s salt, making erasure possible.

Request erasure

When a user exercises their right to erasure, call the erasure endpoint:

client.data_subjects.request_erasure( subject_id=subject.id, reason="User request under GDPR Article 17", )

This flags the record as ErasureRequested. The actual erasure is not immediate.

30-day hold period

The system enforces a 30-day hold before executing erasure. This window allows for:

  • Cancellation if the request was made in error or a legal hold applies
  • Fulfilment of any active legal obligation to retain the record

A background worker runs daily and executes erasure for all subjects whose hold period has expired and who have no active legal hold.

Erasure completes

The data subject’s salt is set to NULL. All session commitments linked to this subject become permanently unverifiable. The commitment values and blockchain anchors remain, but without the salt, they cannot be reconstructed or used to verify content.

If a data subject’s records are subject to a legal hold (for example, as part of ongoing litigation), erasure is blocked until the hold is lifted. Attempting to request erasure while a hold is active returns an error. Once the hold expires, erasure can proceed normally.


Article 15 — Right of Access

You can export a data subject’s session records, including decision inputs, outputs, and blockchain proof data, via the Customer Portal or API. This export forms the basis for responding to Subject Access Requests.


Data Residency

Data resides in the Azure region selected at account creation time. By default:

TierResidency
StandardWest Europe (primary), North Europe (geo-replication)
Enterprise FederatedYour own Azure subscription — any region you choose

Enterprise customers who require single-region storage without geo-replication can configure this by disabling geo-redundancy in their deployment. Contact your account manager for details.


Subprocessors

Refer to the Subprocessors list for the current list of third-party vendors that process data on our behalf. We notify customers of material subprocessor changes with at least 14 days’ notice.


Breach Notification

VeriProof commits to notifying affected customers of any confirmed personal data breach within 72 hours of discovery, in accordance with Article 33. Notifications are sent to the primary account email address and include the nature of the breach, categories of data affected, and recommended actions.


Next Steps

Last updated on