Audience: GPAI providers subject to EU AI Act transparency obligations, Notified Bodies conducting conformity assessments, AI Offices evaluating compliance tooling, and deployers integrating GPAI models into high-risk AI systems.
1. Overview and Timeline
The EU AI Act (Regulation 2024/1689) creates specific obligations for providers of General-Purpose AI (GPAI) models. Article 53 requires GPAI providers to comply with a Code of Practice that operationalizes transparency requirements. The GPAI Code of Practice is being developed through the AI Office consultation process, with the final draft expected in June 2026.
SWT3 (Sovereign Witness Traceability) provides the cryptographic evidence infrastructure that GPAI providers need to demonstrate ongoing compliance with these obligations. This document maps specific SWT3 procedures to each Code of Practice requirement.
Applicable Obligations
| Article | Scope | Enforcement |
|---|---|---|
| Art. 50 | Transparency for AI-generated content (labeling, detection) | August 2, 2026 |
| Art. 53 | GPAI provider obligations (documentation, CoP compliance) | August 2, 2026 |
| Art. 55 | Additional obligations for systemic risk GPAI models | August 2, 2026 |
| Art. 72 | Post-market monitoring for high-risk AI systems | December 2, 2027 |
2. Transparency Chapter (Art. 50, 53)
The Code of Practice transparency chapter requires GPAI providers to maintain and disclose technical documentation about their models, training data, and operational characteristics. SWT3 addresses these requirements through continuous, automated evidence generation rather than point-in-time documentation.
Core Transparency Requirements
- Model identification and versioning -- which model was used, which version, when
- Capability and limitation disclosure -- what the model can and cannot do
- Training data provenance -- data sources, governance, and quality measures
- Operational logging -- what the model did in production, with evidence
- Downstream notification -- informing deployers of changes and obligations
3. Model Documentation Form
The Code of Practice requires GPAI providers to complete a standardized Model Documentation Form. SWT3 procedures map to the form's key sections:
Model Identification and Version Control
Every SWT3 witness anchor records the model identifier and a SHA-256 hash of the model weights. This creates a verifiable chain of evidence showing exactly which model version was used for each inference. Addresses the Model Documentation Form requirement for "unique model identifier" and "version history."
Automated Continuous verification at every inference.
Version Identifier and Change History
Records version identifiers at each inference event. Combined with the Merkle rollup system, provides a tamper-evident version history that auditors can verify independently. Addresses the "model card" and "version changelog" requirements.
Automated Version recorded in every anchor.
Model Architecture Documentation
AI-MDL.5 (model weight hashing), AI-MDL.6 (adapter stack witnessing), and AI-MDL.7 (quantization tracking) collectively document the model architecture, fine-tuning layers, and compression methods. Addresses requirements for "model architecture description" and "modifications from base model."
Automated Hash-based verification of model state.
4. 10-Year Retention Obligation
Article 53(1)(c) requires GPAI providers to retain technical documentation for 10 years. SWT3 provides the infrastructure for this requirement through three layers:
Tamper-Evident Long-Term Storage
Layer 1 -- WAL: Every witness anchor is written to a crash-resilient Write-Ahead Log before network transmission. The WAL survives process crashes, network failures, and system restarts.
Layer 2 -- Merkle Rollups: Daily Merkle tree rollups compress all anchors into a single cryptographic root. The root is stored in the ledger. Any individual anchor can be proven to be part of the daily rollup using a Merkle proof.
Layer 3 -- Clearing Levels: Data retention respects clearing levels. At Level 3 (Classified), only numeric factors and hashed identifiers are retained, ensuring that sensitive content is never stored long-term while the compliance evidence remains verifiable.
Automated Retention is a property of the architecture, not a manual process.
5. 14-Day Disclosure Obligation
The Code of Practice requires GPAI providers to disclose certain information to downstream deployers within 14 days of a material change. SWT3 supports this through:
Continuous Operational Evidence
Every inference is witnessed with prompt/response hashes, latency measurements, and model identifiers. When a material change occurs (model update, parameter change, guardrail modification), the witness record reflects it immediately. The export_evidence() method generates auditor-ready evidence bundles on demand.
Automated Evidence available within seconds of any change.
Material Change Notification
When a model is recalled, a policy violation is discovered, or regulatory action requires it, the revoke() method mints a revocation anchor (AI-REV.1) that references the original anchor. Seven standardized reason codes (model_recall, policy_violation, data_contamination, consent_withdrawal, regulatory_order, error_correction, unspecified) provide structured disclosure. Downstream deployers can verify revocation status through the public verification endpoint.
Automated Revocation propagates through the verification chain.
6. Downstream Provider Obligations
GPAI providers must ensure downstream deployers can meet their own obligations. SWT3's Trust Mesh and chain witnessing provide the evidence infrastructure:
Cross-Provider Evidence Chain
When a GPAI model is integrated into a downstream AI system (e.g., a deployer's application using an API), AI-CHAIN.1 anchors record the chain of custody. Each handoff between providers is witnessed with trust level assessment (AI-CHAIN.2 detects trust degradation). The resulting evidence chain proves that every provider in the pipeline maintained compliance.
Automated Chain witnessing at every handoff point.
Provider-to-Deployer Trust Handshake
The Trust Mesh enables bilateral verification between GPAI providers and deployers. Each party presents cryptographic credentials. Trust levels (Denied, Basic, Verified, Attested, Sovereign) are evaluated at every interaction. Deployers can verify that their GPAI provider maintains active compliance attestation.
Automated Continuous trust evaluation, not point-in-time certificates.
7. Systemic Risk (Art. 55)
GPAI models classified as posing systemic risk face additional obligations including adversarial testing, incident reporting, and cybersecurity measures. SWT3 provides evidence infrastructure for these requirements:
Adversarial Testing Evidence
Records results from adversarial testing systems (prompt injection detection, jailbreak attempts, data poisoning scans). The witness anchor includes threat scores, threat types, and detection thresholds. Provides auditable evidence that adversarial testing was performed and what it found.
Automated Witnesses existing security tooling results.
Safety Filter Documentation
AI-GRD.1 witnesses guardrail activation (required filters are present and active). AI-GRD.2 records content safety filter results (output classification). AI-GRD.3 binds guardrail configuration to a specific policy version. Together, they provide evidence that safety measures are deployed, operational, and version-controlled.
Automated Guardrail state recorded at every inference.
Exploit Chain Prevention
For systemic risk models deployed as agents, the ChainEnforcer provides velocity limits, depth tracking, token budget enforcement, and tool blocklists. Violations are recorded as forensic evidence. The sentinel daemon provides cross-process enforcement that prevents bypass through process spawning. Addresses Art. 55 cybersecurity and robustness requirements.
Automated Pre-execution enforcement with forensic logging.
8. Procedure-to-Obligation Mapping Table
| Code of Practice Requirement | Article | SWT3 Procedure(s) | Coverage |
|---|---|---|---|
| Unique model identifier | Art. 53(1)(a) | AI-MDL.1, AI-MDL.2 | Full |
| Model architecture description | Art. 53(1)(a) | AI-MDL.5, AI-MDL.6, AI-MDL.7 | Full |
| Training data provenance | Art. 53(1)(a) | AI-DATA.1, AI-DATA.2 | Partial |
| Capability and limitation disclosure | Art. 53(1)(b) | AI-INF.1, AI-INF.2, AI-GRD.2 | Full |
| 10-year documentation retention | Art. 53(1)(c) | WAL + Merkle + Clearing Levels | Full |
| 14-day change disclosure | Art. 53(1)(d) | AI-REV.1, export_evidence() | Full |
| Downstream provider notification | Art. 53(2) | AI-CHAIN.1, AI-CHAIN.2, Trust Mesh | Full |
| AI-generated content labeling | Art. 50(2) | AI-INF.1 (response hashing) | Partial |
| Copyright policy compliance | Art. 53(1)(c) | AI-DATA.3, AI-DATA.4 | Partial |
| Adversarial testing (systemic) | Art. 55(1)(a) | AI-SEC.1 | Full |
| Incident reporting (systemic) | Art. 55(1)(b) | AI-REV.1 + Violation callback | Full |
| Cybersecurity measures (systemic) | Art. 55(1)(c) | ChainEnforcer, Sentinel, AI-GRD.3 | Full |
| Human oversight documentation | Art. 14 | AI-HITL.1, AI-HITL.2, AI-HITL.3 | Full |
| Accuracy and robustness | Art. 15 | AI-INF.2 (latency), AI-GRD.1 | Full |
| Post-market monitoring | Art. 72 | Continuous witnessing + drift detection | Full |
Coverage key: Full = SWT3 procedure directly addresses the requirement with automated evidence. Partial = SWT3 provides supporting evidence; additional organizational measures may be needed. Manual = Organizational process required; SWT3 records the evidence once the process is completed.
9. Clearing Levels and Data Sovereignty
GPAI providers operating across jurisdictions must balance transparency obligations with data protection (GDPR) and trade secret protection. SWT3 clearing levels provide this balance:
| Level | Name | Data Transmitted | GPAI Use Case |
|---|---|---|---|
| 0 | Analytics | Hashes + factors + model + provider + guardrails + context | Internal R&D, pre-deployment testing |
| 1 | Standard | Hashes + factors + model + provider | Production API services (default) |
| 2 | Sensitive | Hashes + factors + model only | Healthcare, legal, PII-adjacent workloads |
| 3 | Classified | Numeric factors only, model ID hashed | Defense, sovereign cloud, air-gapped |
At all clearing levels, raw prompts and responses never leave the deployment infrastructure. The SDK computes SHA-256 hashes locally and transmits only irreversible hashes and numeric factors. This architecture satisfies both the transparency requirement (evidence exists and is verifiable) and the data protection requirement (content is never exposed).
10. Evidence Generation for Notified Bodies
When a Notified Body or the AI Office requests evidence of Code of Practice compliance, SWT3 provides multiple export formats:
- Auditor Portal: Read-only web interface showing all procedures, verdicts, evidence chains, and the Agent Subway Map. See live demo.
- Evidence Bundles: JSON or self-contained HTML exports with cryptographic watermarks ("Self-Signed / Unnotarized" for local, "Axiom Certified" for ledger-verified).
- OSCAL Packages: NIST OSCAL-formatted SSP, POA&M, and Assessment Results validated against the NIST reference implementation.
- Public Verification: Any anchor can be independently verified at the public verification endpoint using only the fingerprint.
- Merkle Proofs: Individual anchor inclusion in a daily Merkle rollup can be proven cryptographically without revealing other anchors.