AI Act Compliance Method: Comparative Analysis of Four Approaches Before 2 August 2026

A structured legal-technical comparison of documentary audit, AI governance platforms, the ZKMLOps academic framework, and the ZKAP (Zero-Knowledge Audit Protocol) — with five decision criteria for high-risk AI system deployers under Regulation (EU) 2024/1689.

I. Why the Choice of AI Act Compliance Method Is a Legal Act

The AI Act does not prescribe a specific technical method. It establishes the result-obligations — what must be demonstrated — while leaving to the obliged entity the right and responsibility to select the method of demonstration. This choice is not a technical detail. It is a legal act with sanctioned consequences.

Under Article 99 AI Act, non-conformity with Articles 9-15 triggers administrative fines of up to EUR 35 million or 7% of worldwide annual turnover, whichever is higher. Accordingly, the AI Act compliance method must be documented, justified, and defensible — not only before the regulator, but also before shareholders, insurers, and courts. The choice must withstand scrutiny under the principles of professional diligence and the standard of care expected of a reasonably competent operator.

This analysis presents the four principal methods that are operational as of April 2026 and supplies five selection criteria.

II. What "AI Act Compliance Method" Means in Practice

A method for AI Act compliance is a structured legal-technical process through which the obliged entity:

1. identifies which requirements of the AI Act apply to the specific system (Article 6 and Annex III);
2. establishes verifiable internal controls for each applicable requirement;
3. generates the evidentiary corpus that demonstrates discharge;
4. submits the evidence before a notified body or supervisory authority under Articles 43-49;
5. maintains continuous post-market monitoring under Article 72.

Four methodologies are available in the market as of 2026 that purport to cover these steps — each with different guarantees, exposures, and scaling properties.

III. The Four Methods Compared

Method 1 — Documentary Audit (the traditional approach)

A team of lawyers and technical experts compiles detailed documentation: technical description of the system (Article 11), training records, fundamental rights impact assessment (Article 27), cybersecurity policy (Article 15), and submits it to an auditor or notified body for review.

Strengths: established approach, mature legal practice, compatible with existing ISO 9001/27001 processes.

Weaknesses: (i) requires disclosure of technical and design documentation to the auditor — placing trade secrets under the Directive (EU) 2016/943 at risk; (ii) does not scale: with over 65,000 high-risk systems in scope across the EU, notified body capacity is structurally insufficient; (iii) the audit is a point-in-time snapshot and does not satisfy the continuous compliance obligation under Article 72.

Conclusion: suitable for small numbers of systems whose documentation is not commercially sensitive. Unsuitable for large-scale deployments or systems with high-value models.

Method 2 — AI Governance Platforms (Credo AI, Holistic AI, FairNow)

A third-party software platform automates checklists, manages documentation, and generates compliance reports.

Strengths: automation of routine tasks, unified documentation repository, operational support for compliance officers.

Weaknesses: (i) sensitive data is stored on a third-party's infrastructure — adding contractual and GDPR risk; (ii) the assurance is founded on the platform's reputation, not on a cryptographic guarantee; (iii) a compromise of the platform implicates all clients simultaneously (single point of failure); (iv) the method does not produce mathematically verifiable evidence that a notified body can independently verify.

Conclusion: useful as an organisational tool, but not sufficient as a stand-alone method for high-risk systems. Recommended for use in combination with a cryptographic methodology.

Method 3 — ZKMLOps (academic zero-knowledge MLOps framework)

A research framework published on arXiv (2510.26576 and 2505.20136) by a team from Tilburg University, Eindhoven University of Technology, and Politecnico di Milano. ZKMLOps integrates zero-knowledge proofs into the MLOps lifecycle at the software layer. Primary use case: a bank demonstrating to its contracted auditor that the deployed credit-risk model satisfies regulatory requirements.

Strengths: mathematical guarantee of inference correctness, protection of model parameters from disclosure, peer-reviewed and technically competent.

Weaknesses: (i) operates entirely at the software layer — does not protect against compromise of the operator's software stack; (ii) presupposes a two-party relationship operator-auditor, without an institutionally distinct regulatory authority; (iii) the attestation is retrospective (post-hoc) — the output is delivered before the proof; (iv) the scope is narrowly focused on financial applications; (v) the authors themselves scope fairness verification and data privacy to Future Work.

Conclusion: valuable for local internal audit between an operator and its audit firm. Insufficient for regulatory regimes that require enforcement rather than retrospective verification.

Method 4 — ZKAP (Zero-Knowledge Audit Protocol)

A methodology developed during 2025-2026 by Radoslav Y. Radoslavov, Lead Methodologist in Legal Engineering, combining over twenty years of legal practice with seventeen years of inside experience at the Bulgarian Commission for Counteracting Corruption and the Forfeiture of Illegally Acquired Property (CACIAF, 2006-2023). ZKAP is the subject of two Bulgarian patent applications: BG/P/2026/114317 (filed 30 March 2026, hardware embodiment) and PTBG202600000316742 (filed 12 April 2026, software embodiment with hardware guardian). EPO, UKIPO and PCT/WIPO filings are in preparation within the priority deadlines under the Paris Convention.

ZKAP is positioned differently from the preceding three methods along four dimensions:

• Prove-before-output enforcement. The output of the AI system is physically blocked until cryptographic verification succeeds. A non-compliant output never reaches the user. This is a qualitative departure from Methods 1-3, where verification is retrospective.
• Certified Stack binding. The model, execution environment, bit-integrity policy, and hardware configuration are bound into a single cryptographic fingerprint (RootHash). Compromise of any component mathematically destroys the ability to generate a valid proof. This guarantees compliance in spite of operator compromise.
• Institutionally separated regulatory audit. The authority-signed constraint set (Constraint Authority) separates rule-setting from rule-execution and from rule-verification. This is a legal requirement under regimes in which the constraints themselves are the object of political and judicial scrutiny.
• Domain-independent by design. ZKAP covers the full surface of administrative and judicial decision-making regimes with legal consequence — high-risk AI under the AI Act, civil-forfeiture and anti-corruption regimes, cybersecurity supervision under NIS2, data-protection oversight under GDPR, financial-sector regulation, tax administration, public procurement and licensing.

A detailed conceptual description of the ZKAP architecture and the R-Domain / C-Domain separation is available in the companion piece The Transparency Paradox and in the public summary of the ZKAP White Paper.

IV. Comparison Matrix — Which AI Act Method to Select

V. Five Selection Criteria — Legal, Technical, Strategic

Criterion 1 — Sensitivity of the model and training data

If the model contains high-value trade secrets, or if the training data includes special categories of personal data under Article 9 GDPR, then methods that require disclosure of the model to an auditor are legally unacceptable. This excludes Method 1 (documentary audit) for most practical use cases in banking, health, and the public sector.

Criterion 2 — Regime of responsibility

Under regimes of imposed compliance (Article 72 AI Act post-market monitoring; Article 21 NIS2 continuous risk management), retrospective verification is insufficient. A method with enforcement before output is required. Only Method 4 (ZKAP) satisfies this condition in pure form.

Criterion 3 — Deployment environment

In a trusted cloud environment with a trusted operator, Method 3 (ZKMLOps) is adequate. In environments in which the operator may itself be compromised — the classical high-risk case under Article 6 AI Act — hardware anchoring is required. Only Method 4 provides this.

Criterion 4 — Institutional separation of roles

If the obliged entity is the same as the body that sets the rules (i.e. internal self-audit), Method 3 is suitable. Where the regulatory authority is institutionally distinct — the normal case under AI Act, NIS2, GDPR, and national anti-corruption regimes — a three-party protocol is necessary. This is characteristic only of Method 4.

Criterion 5 — Operational horizon

If the AI system will be in production for less than twelve months, investment in a cryptographic method may not pay back — Methods 1 or 2 become economically rational. For horizons beyond twenty-four months, the cryptographic method has systematically lower total cost of ownership, owing to avoided audit cycles and reduced sanction exposure.

VI. Timeline — What Must Be Done by 2 August 2026

The typical process of selecting and deploying a method for AI Act compliance takes between three and nine months, depending on system complexity. Recommended sequence for obliged entities as of April 2026:

• April - May 2026: legal scope assessment (gap analysis) — which systems fall within AI Act scope, in which categories (Article 6, Annex III), at what risk level.
• May - June 2026: selection of compliance method based on the five criteria above.
• June - July 2026: implementation, internal verification, documentation.
• July 2026: engagement of notified body under Articles 43-49 AI Act (where applicable) and filing of the declaration of conformity.
• 2 August 2026: obligations enter force — from this date, any use of a non-conformant high-risk AI system constitutes a violation.

Delay carries a cumulative effect: notified body capacity is limited, and undertakings that engage audit in July 2026 risk not receiving timely response. A decision taken in April-May 2026 is materially different in risk from one taken in July.

VII. Our Engagement — Comprehensive Legal-Technical Support

Advanced Consulting-London RR, in conjunction with the Radoslavov Law Firm (Bulgaria), provides end-to-end support for the selection and deployment of an AI Act compliance method:

• Scope assessment — identification of all AI systems within the organisation, classification under AI Act (Article 6, Annex III), mapping of legal obligations across AI Act, GDPR, and NIS2;
• Method selection — reasoned legal analysis against the five criteria, with a documented decision that is defensible before regulator, board, and court;
• ZKAP deployment — for organisations that select the cryptographic method, we provide methodology licensing and technical deployment guidance;
• Regulatory representation — before data protection authorities, cybersecurity regulators, and courts in proceedings under AI Act, GDPR, and NIS2;
• Related materials: ZKAP protocol, The Transparency Paradox (policy brief), ZKAP White Paper (public summary), The Collapse of Transparency (book).

VIII. Conclusions

The choice of an AI Act compliance method is a strategic legal decision with long-term consequences. The traditional approaches — documentary audit and governance platforms — remain applicable in low-risk scenarios, but they do not satisfy the legal requirements for high-risk systems at the scale of 65,000+ obliged entities across the EU.

Cryptographic methods — and in particular ZKAP — deliver a qualitatively new regime: continuous cryptographic attestation with preservation of trade secret, prove-before-output enforcement, hardware anchoring, and institutional separation. This is the methodology that permits the obliged entity to comply with the AI Act without compromise of trade secret, personal data, or intellectual property.

The 2 August 2026 deadline is not susceptible to postponement. Method selection must be made, documented, and deployed in time.

References

• [1] Regulation (EU) 2024/1689 of the European Parliament and of the Council laying down harmonised rules on artificial intelligence (AI Act)
• [2] Regulation (EU) 2016/679 — General Data Protection Regulation (GDPR)
• [3] Directive (EU) 2016/943 on the protection of undisclosed know-how and business information (Trade Secrets Directive)
• [4] Directive (EU) 2022/2555 on measures for a high common level of cybersecurity (NIS2)
• [5] Radoslavov, R.Y. (2026). “Management and Regulation of AI Models in Public Administration: Cryptographic Transparency and Digitalization of Legal Norms.” Industry 4.0, XI International Scientific Conference, Borovets, 23-30 March 2026. DOI: 10.5281/zenodo.19509511.
• [6] Radoslavov, R.Y. (2025). “Management and Regulation of AI Models: Concept for Transparency and Accountability in Administrative Activities.” Industry 4.0. DOI: 10.5281/zenodo.19614243. [ResearchGate]
• [7] Scaramuzza, F. et al. (2025). “Engineering Trustworthy Machine-Learning Operations with Zero-Knowledge Proofs.” arXiv:2505.20136.
• [8] Scaramuzza, F. et al. (2025). “‘Show Me You Comply… Without Showing Me Anything’: Zero-Knowledge Software Auditing for AI-Enabled Systems.” arXiv:2510.26576.
• [9] European Commission, AI Act Implementation Timeline. artificialintelligenceact.eu.