The gap
The DPO is accountable for proving four things about AI processing of personal data. Data minimisation operated correctly under GDPR Article 5. The DPIA under Article 35 reflects the actual processing. The high-risk AI system logging under EU AI Act Article 12 is in place. Where the institution operates in jurisdictions with their own AI guidance (QCB and CBUAE in the Gulf, BNM in Malaysia), the equivalent obligations have been met.
What the DPO actually has from mainstream AI vendors is a privacy policy, a SOC 2 report, a Data Processing Agreement, and a contractual representation that data is not used for training. None of these are cryptographically verifiable evidence that data minimisation operated at runtime on a specific date on a specific prompt.
When a supervisory authority asks for evidence after an incident, vendor assurance answers the wrong question. The supervisor wants to see what the AI actually saw, what was redacted, and under what rule, at the moment the request was processed. That gap is where regulatory exposure now lives.
Why audit logs are not evidence
Most AI vendors will offer audit logs and tell the DPO that this is the evidence requirement met. Audit logs answer a different question. They tell you what happened from the vendor perspective. They do not tell a third party that what happened is verifiable without trusting the vendor.
The DPO is not the vendor. The supervisor is not the vendor. Both want evidence that does not require trusting the vendor. Vendor-asserted logs work for vendor-internal operations. They do not work for regulator-grade demonstration of policy enforcement.
Cryptographic non-disclosure proof is the alternative. It is not a stronger audit log; it is a different artefact category. The signature scheme means a regulator can confirm a specific fact about a specific interaction by verifying the signature against a public ledger, without ever contacting the vendor that produced the proof.
The four layers that close the gap
Four runtime layers, applied in sequence, produce the cryptographic non-disclosure proof the DPO actually needs.
Policy: machine-readable, version-controlled
The disclosure policy is structured as a machine-readable artefact, not a Word document attached to a DPIA. Fields, classifiers, redaction rules, and exceptions are defined in code that the runtime reads. When the DPO updates a policy, the runtime updates with it. The policy and its enforcement are the same artefact, not parallel descriptions.
Interception: prompt layer, before any model call
Every prompt sent to any AI tool passes through ZeroH Disclosure before reaching the model. Field-level classifiers identify PII, PHI, financial sensitivity, or Shariah-sensitive content. Redaction is applied under the policy. The model receives the redacted prompt only. The pre-redaction state never leaves the controller perimeter.
Evidence: signed, sequenced, anchored
For every prompt-redaction interaction, a signed evidence record is designed to be produced. The record contains a hash of the pre-redaction prompt, the policy version applied, the fields redacted, the timestamp, and the actor. The record is sequenced and designed to be anchored to a tamper-evident store. Any later attempt to alter the record breaks the chain.
Disclosure: BBS+ selective, share without exposure
When the DPO needs to share evidence with a supervisor, an auditor, or a data subject, the selective disclosure layer is designed to produce a verifiable proof that reveals specific facts (this PII field was redacted under this rule at this time) without exposing the underlying data. The supervisor can verify the proof independently. The DPO never over-discloses to demonstrate compliance.
What a data subject access request looks like
A DSAR under GDPR Article 15 obligates the controller to confirm what personal data is being processed and describe the processing. When AI is involved, the DPO needs to reconstruct what data was processed by AI on behalf of a specific data subject, when, under what policy, and what was masked.
With cryptographic non-disclosure proof, that reconstruction takes minutes. Query the audit trail for interactions involving the data subject. The signed evidence records show the policy version, the fields redacted, and the AI tool used. Export the resulting evidence pack. The data subject and the supervisory authority can verify the export independently against the tamper-evident evidence store.
Without cryptographic provenance, the same DSAR is a manual investigation. The DPO asks the vendor for logs. The vendor returns what its log retention allows. The controller composes a narrative. Nothing in the narrative is independently verifiable. Each DSAR consumes hours of legal and engineering time and produces evidence weaker than the request deserved.
Cross-border residency by architecture
Schrems II in the EU, Gulf data residency rules in Qatar and the UAE, and BNM rules in Malaysia all converge on the same question: did source personal data leave the authorised jurisdiction before processing? Mainstream AI inference is often offshore, which makes the answer hard to give honestly.
With prompt-layer interception, the answer is structural. Original prompts and source data stay on infrastructure under controller control. Cryptographic evidence records are designed to be anchored with on-soil storage where available. Only redacted content leaves the perimeter. The proof of non-disclosure is the proof of residency compliance at the same time.
Frequently asked questions
The gap between what the DPO must prove and what their tooling produces. GDPR Article 5 requires data minimisation. GDPR Article 35 requires DPIA evidence. EU AI Act Article 12 requires logging. The DPO is accountable for proving these requirements operated correctly at runtime. Mainstream AI vendors produce privacy policies, vendor-asserted logs, and SOC 2 reports. None of those are cryptographically verifiable proof that a specific PII field was redacted before a specific prompt reached the model.
Vendor assurance is a contractual representation. GDPR is an enforcement framework. When a supervisory authority asks for evidence that data minimisation operated at runtime on a specific date, vendor assurance answers the wrong question. The supervisor wants to know what data the AI actually saw, what was redacted, and under what policy, at the moment the request was processed. Without cryptographic provenance, the DPO's answer is necessarily 'we trust the vendor', which is a regulatory exposure rather than a compliance demonstration.
A prompt is intercepted at the policy layer before it reaches the AI. Field-level classification identifies PII, PHI, or other sensitive elements. Redaction is applied under the policy. The pre-redaction state, the redaction rules applied, and the post-redaction prompt are bundled into a signed evidence record designed to be anchored to a tamper-evident store. The platform is designed so that selective disclosure allows the DPO to later prove "PII field X was redacted under rule Y at time Z" without exposing the underlying data.
Yes. ZeroH Disclosure is designed as a bring-your-own-AI layer. It sits between staff and the AI tools the institution already uses (Microsoft Copilot, ChatGPT Enterprise, Claude, internal LLM deployments). Specific plugin integrations (Microsoft 365 Copilot, browser extension, MCP servers for Claude, custom adapters) are in active development.
A data subject access request under GDPR Article 15 obligates the controller to confirm what personal data is being processed and to describe the processing. With cryptographic non-disclosure proof, the controller can reconstruct exactly what data was processed by AI on behalf of a specific data subject, when, under what policy, and what was masked. The reconstruction is exportable in regulator-grade evidence format and is verifiable independently against the public ledger.
Originals stay on infrastructure under controller control. Cryptographic evidence records are designed to be anchored with on-soil storage where available. Only redacted content leaves the perimeter. The architecture is designed to prove that source data did not cross jurisdictional boundaries before redaction. This applies to Schrems II adequacy contexts, Gulf data residency rules (Qatar, UAE, Saudi), and similar frameworks.
See ZeroH Disclosure produce a cryptographic non-disclosure proof on a working workflow.
Schedule a demo