The Problem

AI Act Enforcement Faces a Structural Impossibility

Regulation (EU) 2024/1689 requires transparency for high-risk AI systems. But the current enforcement toolkit cannot deliver it without breaking other legal obligations.

65K+

High-Risk AI Systems

Estimated deployments requiring conformity assessment by August 2027. Existing supervisory capacity cannot audit them through traditional inspection methods.

<200

Qualified Auditors

Notified bodies across the EU lack the technical expertise and scale to inspect proprietary model internals. Manual audit of neural network weights is not a viable path.

3-Way

Legal Paradox

The AI Act demands transparency. GDPR demands data minimization. Trade secret law demands non-disclosure. No traditional audit instrument satisfies all three simultaneously.

Technical Architecture

How ZKAP Works

Five steps, from input to verified output. The model never leaves the certified stack. The proof proves adherence to formalized rules without revealing how.

1

Stack Validation & Constraint Binding

The certified stack verifies its integrity: RootHash = H(H(M) || H(Env) || H(ProofGen)). The model, execution environment, and proof module are cryptographically bound. Formal constraints C — polynomially encoded regulatory rules — are validated against an authorized signature. Substitution of any component invalidates the entire stack.

2

Deterministic Inference in TEE

Input data x enters a hardware-isolated Trusted Execution Environment. The model executes y = M(x) using quantized INT8/INT4 arithmetic for bit-level determinism. A full computational trace T is recorded. The output is physically blocked until proof verification completes.

3

Zero-Knowledge Proof Generation

The computational trace and constraints are encoded into an arithmetic circuit over finite field F_p. A zk-SNARK or zk-STARK proof π is generated, certifying that R(pub, w) = 1 — the model produced this output while respecting every formalized rule. The witness (model internals, raw data) is never revealed.

4

Prove-Before-Output

Internal verification confirms Verify(π, pub) = 1. Only then does the hardware-controlled mechanism release output y together with the proof. If any constraint is violated, the system returns CONSTRAINT_VIOLATED(c_i) and the output is permanently blocked. No unverified result ever leaves the stack.

5

State Commitment & External Verification

A cryptographic state commitment S_i is generated and chained to the previous commitment, forming an immutable hash chain. Any third party — regulator, notified body, or court — can verify the proof in O(log n) time. Quintillions of operations compressed into a ~2 MB certificate, verifiable in milliseconds.

Operational Architecture

Four Operational Modes

ZKAP is designed to operate in two fundamentally distinct modes, each serving a different principal and a different regulatory function. In both modes, the zero-knowledge property is absolute: the verifying party receives only cryptographic proofs and public parameters — no raw input data, no model weights, no personal information, no training data, and no intermediate computational state.

MODE 1

Enforcement

Prove-Before-Output

Deployed within the operator's production infrastructure. The enforcement mechanism — hardware gate or software syscall interceptor — physically blocks the release of every output not accompanied by a valid zero-knowledge proof. Non-compliant output never leaves the system.

Buyer: the operator of the AI system.
Value: legal certainty & protection from regulatory exposure.

MODE 1A

Real-Time Monitoring

Parallel Attestation Without Blocking

Output is released immediately to the client with zero latency. The proof is generated in parallel. A pre-commitment record is written to the hash chain before release, ensuring that even if proof generation fails, the inference event is permanently recorded. Violations are detected and documented, not prevented.

Ideal for: latency-critical systems, constraint calibration, compliance scoring.
Who decides: the Constraint Authority signs the permissible mode — the operator cannot switch unilaterally.

MODE 2

Audit

Regulatory Oversight

Deployed by a regulator or authorised audit body, independently of the operator. Has three operationally distinct sub-variants:

2A — Retrospective Audit. A defined historical period verified upon request. Audit firms can offer mathematically certified compliance reports.
2B — Shadow Audit. Continuous oversight in real time, without interfering with production. Regulatory Intelligence as a Service.
2C — Hybrid Audit. Combines real-time observation with retrospective evidence collection for legal proceedings.

The technical implementation of all modes — including the cryptographic protocol architecture, hardware enforcement, software enforcement, and pre-commitment protocol — is protected under two patent applications: BG/P/2026/114317 (hardware variant, filed 30 March 2026) and PTBG202600000316742 (software variant, filed 12 April 2026), with international filings before EPO and UK IPO in preparation.

Local Deployment

Software ZKAP — No Special Hardware Required

The software variant of ZKAP (Patent PTBG202600000316742, filed 12 April 2026) implements the full prove-before-output principle at the operating system level, without requiring specialised hardware such as TEE or custom silicon. It runs on any standard server — Windows, Linux, BSD, macOS, or containerised environments — making cryptographic compliance verification immediately deployable in any organisation.

How It Works

The ZKAP runtime executes within an isolated software environment on a standard computing host. A specialised enforcement layer — the Syscall Interceptor — blocks all output channels (files, network sockets, inter-process communication, shared memory) until a valid zero-knowledge proof has been generated and verified internally. The blocking operates at the interface between userspace and the operating system kernel, using mechanisms native to each platform:

Linux: seccomp-bpf / eBPF filters, namespaces, control groups
Windows Server: minifilter drivers, ETW tracing, API hooking, Hyper-V isolation
macOS: Endpoint Security Framework, sandbox-exec
BSD: Capsicum (FreeBSD), pledge/unveil (OpenBSD)
Containers: Docker, Kubernetes, microVM (Firecracker, Kata Containers)

The technical effect is identical to the hardware variant: unverified data cannot escape the isolated environment through any channel. The difference is in the enforcement mechanism — OS-level interception instead of a physical gate — but the cryptographic protocol, hash chain, and proof system are exactly the same.

🏦

Banks & Financial Services

Credit scoring, risk assessment, anti-money laundering AI — cryptographically prove non-discrimination and regulatory compliance without exposing client data or proprietary models.

🏛

Government Agencies

Public administration AI for resource allocation, permit processing, social benefit eligibility — verifiable fairness and timeliness without disclosing citizen data to auditors.

🏥

Hospitals & Healthcare

Diagnostic AI for imaging, triage, drug interaction — prove non-discrimination and accuracy to regulators without exposing patient records (GDPR Art. 9 compliant).

💼

Enterprises & Corporations

HR/recruitment AI, supply chain optimisation, insurance underwriting — continuous compliance scoring and audit-ready cryptographic evidence at every inference.

🔍

Audit Firms

Deploy ZKAP as a verification tool to offer clients mathematically certified compliance reports — not opinions, but cryptographic facts. Transform audit from investigation to verification.

⚡

Critical Infrastructure

Energy grids, water treatment, transport systems — NIS2 compliance attestation without revealing network architecture or security configurations to external auditors.

Deployment: installs as a sidecar process or container alongside the existing AI system. No changes to the model, no changes to the infrastructure, no special hardware. Works on-premise, in private cloud, or at the edge.

Who ZKAP Serves

Built for Every Stakeholder in the AI Act Ecosystem

Your model is your competitive advantage. ZKAP lets you prove adherence to any formalized rules — regulatory, technical, or ethical — without opening the black box.

Certified Stack Architecture

Model, execution environment, and proof module are cryptographically bound via a single RootHash. Any tampering — weight modification, environment change, module substitution — invalidates the stack and makes proof generation impossible.

Prove-Before-Output Mechanism

Hardware-enforced gate: no inference result is released until a valid zero-knowledge proof confirms compliance with all formalized constraints. Non-compliant outputs are physically blocked at the TEE level.

Surrogate Execution Detection

Three-layer detection prevents model substitution: arithmetic trace verification, timing profile analysis (3σ deviation threshold), and TEE remote attestation. A surrogate model cannot produce a valid proof.

Deterministic Reproducibility

INT8/INT4 quantized arithmetic eliminates floating-point non-determinism. Identical input produces bit-identical output on any certified hardware. Every result is independently reproducible and verifiable.

ZKAP maps directly to the obligations your organization faces under Regulation (EU) 2024/1689. Each article translates to a verifiable cryptographic constraint.

Art. 9 — Risk Management

Formal constraints encode risk thresholds as polynomial equations. Every inference is verified against them automatically. Violations trigger CONSTRAINT_VIOLATED with a specific constraint identifier.

Art. 10 — Data Governance

Input completeness constraints verify all mandatory fields are present and within valid ranges. Data quality requirements are polynomially formalized and checked at every execution.

Art. 13 — Transparency

ZKAP redefines transparency: from revealing model internals to proving compliance properties. The zero-knowledge proof is the transparency instrument — it proves what matters without disclosing what should not be disclosed.

Art. 14 — Human Oversight

Ethical Quarantine: automated halting when non-compliance is detected. Humans define the constraints; the protocol enforces them. The prove-before-output mechanism realizes Art. 14 at the hardware level.

Art. 15 — Accuracy & Robustness

Counterfactual validation detects hidden bias: the system tests outputs with modified protected attributes and verifies |M(x) − M(x′)| < ε. The threshold is set by compliance officers, enforced by mathematics.

Art. 43 — Conformity Assessment

The zero-knowledge proof serves as a conformity certificate. Notified bodies verify a compact cryptographic proof instead of inspecting model internals. Assessment scales from one system to thousands.

ZKAP gives notified bodies the ability to verify compliance at scale — mathematically, not through manual inspection of proprietary architectures.

Verification in Milliseconds

Proof verification runs in O(log n) time. A zk-SNARK proof of ~2 MB compresses the verification of quintillions of arithmetic operations into a single check that takes milliseconds, regardless of model complexity.

Scale Without Proportional Cost

Traditional audit cost scales linearly with the number of systems. ZKAP verification cost is effectively constant per system. One notified body can assess thousands of high-risk systems with the same infrastructure.

No Access to Proprietary Models Required

The zero-knowledge property means the verifier confirms compliance without ever seeing the model weights, architecture, or training data. This eliminates conflicts of interest and reduces liability exposure.

Immutable Audit Trail

The hash chain of state commitments provides a continuous, tamper-evident record of every inference. Retroactive manipulation is detectable. Any gap in the chain triggers an alert. Courts can rely on it as evidence.

ZKAP resolves the legal trilemma at the intersection of AI Act transparency, GDPR data protection, and trade secret law — without requiring your client to choose which law to violate.

Trade Secret Protection

Model weights, architecture, and training methodology remain inside the certified stack. The zero-knowledge property guarantees that compliance verification reveals nothing about the proprietary internals. Directive 2016/943 obligations are preserved by design.

GDPR Compatibility

No personal data leaves the Trusted Execution Environment. The proof attests to properties of the computation, not to the data itself. Data minimization (Art. 5(1)(c) GDPR) is architecturally enforced, not merely procedurally claimed.

Evidentiary Value

Each proof is a cryptographically signed, timestamped, independently verifiable certificate of compliance. The hash chain provides non-repudiation. The mathematical guarantee exceeds the evidentiary weight of any audit report.

Liability Reduction

Continuous, automated compliance verification shifts the liability posture from reactive (post-incident) to preventive (pre-output). Every output carries its own compliance certificate. No output exists without one.

Comparison

ZKAP vs. Traditional Audit vs. Existing zkML

Existing approaches solve parts of the problem. ZKAP addresses the full regulatory stack.

Capability	Traditional Audit	Existing zkML	ZKAP
Cryptographic proof of adherence	No — report-based, no mathematical guarantee	Yes — per-inference proof	Yes — per-inference proof with formalized regulatory, technical, and ethical constraints
Trade secret protection	No — requires model access	Yes — zero-knowledge property	Yes — zero-knowledge property within certified stack
Formalized rules as constraints	No — subjective auditor judgment	No — technical constraints only	Yes — polynomial encoding of regulatory, technical, and ethical requirements
Certified stack binding	No	No — model and environment are independent	Yes — RootHash binds model + environment + proof module
Surrogate execution detection	No	No	Yes — trace analysis + timing + TEE attestation
Prove-before-output	No — ex-post review only	Partial — proof generated, release not enforced	Yes — hardware-enforced output gate
Continuous hash chain audit trail	No — periodic snapshots	No	Yes — every inference cryptographically chained
Verification scalability	Linear — cost per system	O(log n)	O(log n) — mass audit viable
GDPR data minimization	No — data access required	Partial	Yes — TEE isolation, no data leaves enclave
AI Act article-level mapping	Partial — interpretive	No	Yes — Art. 9, 10, 13, 14, 15, 43

Intellectual Property

Patent Status

Patent Pending — Two Applications

Hardware ZKAP: BG/P/2026/114317

Filed 30 March 2026 • TEE + hardware gate • Highest-risk AI systems

Software ZKAP: PTBG202600000316742

Filed 12 April 2026 • Syscall interception • Any standard server

Applicant / Inventor: Radoslav Yordanov Radoslavov

Priority: Partial (compound) priority under Paris Convention Art. 4F

Jurisdictions: Bulgarian Patent Office (BPO) • European Patent Office (EPO) • UK Intellectual Property Office (UKIPO) • PCT International (WIPO) — international filings in preparation

Claims: 43 total (method, system, storage medium, integrated circuit — covering four operational modes, three audit sub-variants, pre-commitment protocol, graceful degradation, external transparency log anchoring, mode configuration signing, and compliance scoring)

IPC Classification: G06F 21/64 (Data integrity) • G06N 20/00 (Machine learning) • H04L 9/32 (Secure communication verification)

Technical Documentation

ZKAP White Paper

The public preview of the ZKAP technical framework. Covers the architecture, cryptographic mechanisms, formal constraint encoding for any set of formalized rules, and practical embodiment examples including civil confiscation proceedings and public administration.

Read the White Paper

→ Policy Brief: The Transparency Paradox in AI Regulation

→ Book: The Collapse of Transparency (2026) — Cryptographic AI governance with comparative EU/US/China analysis and 11 practical scenarios

→ Strategic Collaboration Opportunities

→ Full ZKAP® Framework & Methodology