Back to Dashboard
Verification / Deployment/ 5.4.1

5.4.1 Verifiable Audits

2026 Governance Status: Prototype-level / component-level operationalization

Original Problem in the Paper

Paper motivation: external audits and assessments are proposed as governance tools for building trust among developers, auditors, governments, and users, and for helping prove compliance. The paper frames verifiable audit attestations as a way to attest to an audit process or outcome without necessarily giving every verifier full access to proprietary systems. It identifies open problems around verifying claimed model capabilities or performance under restricted access, using ZK proofs despite overhead, proving that a live inference pipeline matches the audited pipeline, handling dynamic models, scaling beyond enclave-only critical systems, giving users low-friction verification signals, preventing auditor exfiltration of model weights or benchmark leakage, and verifying post-deployment safety measures such as filters and classifiers.

July 2026 Update & Trajectory

Verifiable-audit ingredients are maturing: research ZK inference proofs for 13B-parameter LLMs, TEE/confidential-computing attestation architectures for protected inference, AI Act/GPAI model-evaluation and documentation workflows, and public system-card/scorecard practices. The cited evidence supports those component technologies and workflows, but not a production-standard public audit registry that binds audit results to live, user-facing generations from dynamic deployed pipelines by July 2026. ZK proof-generation latency, TEE trust boundaries, dynamic model and pipeline updates, model-weight exfiltration risk, and user-facing verification remain live deployment problems rather than solved end-to-end audit infrastructure.

Deployed / Operationalized

  • Audit-like transparency and compliance artifacts: system cards, safety scorecards, external red-team summaries, and GPAI Code model documentation forms.
  • TEE/confidential-computing architectures can use remote attestation to verify expected hardware/software measurements before releasing model decryption keys or other secrets into protected execution environments.
  • ZK LLM inference proofs demonstrate research feasibility for selected proof systems and model scales, including reported 13B-parameter inference proofs, but the reported proof-generation time is still far from routine low-latency verification for large live services.
  • EU AI Act/GPAI workflows create model-evaluation, adversarial-testing, documentation, serious-incident reporting, and Code-of-Practice compliance mechanisms for providers within the covered scope; they are not cryptographic proof systems for live inference.

New Tractable Vectors

  • ZK proofs of LLM inference correctness/authenticity for selected moderately large models while preserving model-parameter privacy.
  • Attestation/reference-value chains tying approved container and model-artifact measurements to runtime key release, with audit-result binding still an open design problem.
  • Regulatory model-evaluation, adversarial-testing, documentation, incident-reporting, and Code-of-Practice compliance workflows under the EU AI Act/GPAI regime.
  • Standardized audit-like public reporting formats that distinguish evaluated system behavior, mitigations, scorecards, and deployment caveats without claiming cryptographic verifiability.

Key Open Questions

  • Public audit registries that bind audit results to every user-facing generation from a changing deployed pipeline.
  • Scalable ZK/TEE verification for frontier multimodal systems with acceptable latency, cost, and coverage of the full serving stack.
  • Safe auditor access that reduces model-weight exfiltration, prompt/benchmark leakage, and overfitting-to-audit risks.
  • Verifying that post-deployment safety filters/classifiers are attached, current, and enforced for every relevant request.
  • Making verification understandable to users without overstating what a system card, regulatory documentation form, TEE attestation, or ZK proof actually guarantees.

Evidence & Primary Sources

  • The original TAIG paper motivates external audits/assessments, audit-process and audit-outcome attestations, public certificate registries, inference-time certificates, ZK proofs with high overhead, dynamic-model complications, enclave limitations, low-friction user warnings, auditor exfiltration risk, and verification of post-deployment filters/classifiers. (2024-07-21): https://arxiv.org/pdf/2407.14981
  • zkLLM is presented as a zero-knowledge proof system for LLM inference authenticity; the arXiv abstract says it preserves model-parameter privacy and, for 13B-parameter LLMs, reports proof generation for the entire inference process in under 15 minutes with proof size under 200 kB. This supports research feasibility, not routine low-latency production verification. (2024-04-24): https://arxiv.org/abs/2404.16109
  • NVIDIA's zero-trust confidential AI factory reference architecture describes hardware-enforced TEEs, Confidential Containers, cryptographic remote attestation, expected software measurements/reference values, encrypted/signed images and model artifacts, and key release only after attestation; it also says application vulnerabilities, availability attacks, non-hardware enclaves, and network/storage security remain outside the CoCo trust boundary. (2026-03-23): https://developer.nvidia.com/blog/building-a-zero-trust-architecture-for-confidential-ai-factories/
  • Regulation (EU) 2024/1689, the AI Act, requires providers of general-purpose AI models with systemic risk to perform model evaluation using standardized protocols and tools, conduct and document adversarial testing, assess and mitigate systemic risks, keep track of/document/report serious incidents and possible corrective measures, and ensure adequate cybersecurity protection; Article 55 also allows reliance on codes of practice under Article 56 until harmonized standards are published. (Official Journal 2024-07-12): https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689
  • The European Commission's GPAI Code page says the GPAI Code of Practice is a voluntary tool to help providers comply with AI Act obligations for general-purpose AI models; it says the Code was published on 2025-07-10, has Transparency, Copyright, and Safety and Security chapters, includes a Transparency chapter with a Model Documentation Form, and was last updated on 2026-04-23. (page last updated 2026-04-23): https://digital-strategy.ec.europa.eu/en/policies/contents-code-gpai
  • The Commission news page says the final GPAI Code of Practice was available on 2025-07-10, is designed to help industry comply with AI Act GPAI rules, and consists of Transparency, Copyright, and Safety and Security chapters. (2025-07-10): https://digital-strategy.ec.europa.eu/en/news/general-purpose-ai-code-practice-now-available
  • The Commission Opinion page says the Commission and AI Board confirmed that the GPAI Code of Practice is an adequate voluntary tool for providers of GPAI models to demonstrate compliance with the AI Act; this adequacy confirmation is listed as published on 2025-08-01. (2025-08-01): https://digital-strategy.ec.europa.eu/en/library/commission-opinion-assessment-general-purpose-ai-code-practice
  • OpenAI's GPT-4o System Card was published on 2024-08-08 and presents a GPT-4o Scorecard, Preparedness Framework scorecard, end-to-end safety assessment, external red-teaming information, safety evaluations, mitigations, and safeguards. It is evidence of audit-like transparency and safety reporting, not cryptographic verifiability or live attestation that deployed generations match the assessed system. (2024-08-08): https://openai.com/index/gpt-4o-system-card/