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.
11. GPAI Deployer Obligations (Art. 26)
Sections 1-10 address GPAI provider obligations: the entity that develops, trains, and distributes the general-purpose AI model. This section addresses deployer obligations: the entity that integrates a GPAI model into a downstream system and operates it in production. Many organizations are deployers, not providers. They license a foundation model (GPT-4, Llama, Gemini, Claude) and embed it in their own product or infrastructure.
11.1 Provider vs Deployer Responsibility Matrix
| Obligation | Provider | Deployer | SWT3 Evidence |
|---|---|---|---|
| Model documentation (Art. 53) | Creates and maintains | Receives and verifies | AI-MDL.5 model weights hash at deployment |
| Training data provenance | Documents and discloses | Reviews for suitability | AI-DATA.1 (provider supplies) |
| Capability and limitation disclosure | Publishes | Validates in operational context | AI-INF.1 inference witnessing confirms behavior |
| Risk management (Art. 9) | Assesses model-level risks | Assesses deployment-level risks | AI-DRIFT.1 + AI-DRIFT.2 operational monitoring |
| Human oversight (Art. 14) | Designs override mechanisms | Implements and staffs oversight | AI-GRD.1 guardrails, AI-EMRG.1 overrides |
| Logging (Art. 12) | Enables logging capability | Operates and retains logs | AI-INF.1 + AI-LOG.1 continuous evidence |
| DPIA (Art. 26(5)) | Provides input data | Conducts and maintains | AI-DPIA.1 assessment evidence |
| Inform affected persons (Art. 26(8)) | n/a | Full responsibility | AI-INF.1 with CJT metadata (purpose_class) |
| Post-market monitoring (Art. 72) | Model-level monitoring | Deployment-level monitoring | AI-DRIFT.1 + AI-PERF.1 operational metrics |
| Incident reporting | Model-level incidents | Deployment-level incidents | AI-INCIDENT.1 + AI-EMRG.1 |
11.2 Art. 26 Deployer Obligations
Article 26 of the EU AI Act defines specific obligations for deployers of high-risk AI systems. When a GPAI model is integrated into a system that qualifies as high-risk (Article 6), the deployer bears these obligations regardless of whether the underlying model was developed in-house or licensed from a third party.
Operational Compliance with Provider Instructions
Deployers must use the AI system in accordance with the provider's instructions of use. SWT3 witnesses the operational parameters of each inference (AI-INF.1), enabling auditors to verify that the system operates within documented boundaries. Drift detection (AI-DRIFT.1) alerts when operational behavior deviates from the provider's documented capabilities.
Automated AI-INF.1 inference provenance, AI-DRIFT.1 operational drift
DPIA for High-Risk AI Processing
Deployers of high-risk AI systems must carry out a DPIA under GDPR Article 35 before putting the system into use. SWT3 procedure AI-DPIA.1 records the assessment evidence. The FRIA/DPIA mapping guide provides detailed field-level mapping between fundamental rights impact assessment and SWT3 attestation.
Automated AI-DPIA.1 assessment record, AI-IMPACT.1 impact documentation
Deployer-Side Human Oversight
Deployers must ensure human oversight by natural persons with competence, training, and authority. SWT3 guardrail enforcement (AI-GRD.1) provides evidence that automated safeguards are active. Emergency override attestation (AI-EMRG.1) documents when human operators intervene. For AI systems where real-time human intervention is impractical (e.g., network optimization, autonomous scheduling), human-on-the-loop oversight is evidenced through drift alerts and threshold-based escalation.
Partial AI-GRD.1 guardrails, AI-EMRG.1 override evidence. Organizational measures (staffing, training) required separately.
Transparency to Individuals
Deployers must inform natural persons that they are subject to the use of a high-risk AI system. SWT3 Cross-Jurisdictional Transparency (CJT) metadata records the purpose_class and legal_basis for each inference, providing an auditable record that the deployer has a documented transparency framework. The actual notification mechanism is an organizational responsibility.
Partial AI-INF.1 with CJT fields. Notification mechanism is organizational.
11.3 Art. 50 Transparency for Deployers
Article 50 imposes specific transparency obligations on deployers that differ from provider obligations:
- Art. 50(1): Deployers of emotion recognition or biometric categorization systems must inform natural persons of the system's operation. SWT3 witnesses the inference event (AI-INF.1) with purpose metadata.
- Art. 50(3): Deployers of AI systems that generate deep fakes must disclose that the content is AI-generated. SWT3 witnesses the generation event with content hashing.
- Art. 50(4): Deployers of AI systems that generate text published to inform the public on matters of public interest must label the output as AI-generated. SWT3 provides inference provenance evidence.
11.4 Telecom Example: GPAI in Cloud RAN
A mobile network operator integrates a licensed foundation model into their Cloud RAN infrastructure for network optimization. The model provider supplies the model, documentation, and capability disclosures per Articles 53-55. The operator (deployer) bears Article 26 obligations for operational behavior.
| Obligation | Provider Evidence | Deployer Evidence (SWT3) |
|---|---|---|
| Model documentation | Model card, architecture description | AI-MDL.5: hash of deployed model weights confirms version match |
| Risk management | Model-level risk assessment | AI-DRIFT.1/2: operational drift with consequence mapping to network impact |
| Human oversight | Override API documentation | AI-EMRG.1: emergency override evidence when operators intervene in AI-driven network changes |
| Logging | Logging capability in model API | AI-INF.1 + AI-LOG.1: continuous inference witnessing across all RAN nodes |
| DPIA | Data processing documentation | AI-DPIA.1: assessment record for subscriber data processing by the AI model |
| Post-market monitoring | Model performance benchmarks | AI-PERF.1: operational performance metrics vs provider benchmarks |
For the complete telecom AI compliance guide covering O-RAN architecture, latency-constrained attestation, MEC, and network slicing governance, see Telecom AI Compliance: 5G, RAN, and Network Edge Attestation.
11.5 Deployer Evidence Checklist
A GPAI deployer operating a high-risk AI system should produce the following evidence. Each item maps to one or more SWT3 procedures:
- Deployed model identity: Hash of model weights at deployment time confirms version alignment with provider documentation.
AI-MDL.5 - Operational drift monitoring: Continuous comparison of model behavior against provider-documented capabilities.
AI-DRIFT.1, AI-DRIFT.2 - Inference provenance: Continuous record of AI decisions with model ID, clearing level, and operational context.
AI-INF.1 - Guardrail enforcement: Evidence that safety filters and operational boundaries are active on every inference.
AI-GRD.1 - Human oversight evidence: Records of human operator interventions, emergency overrides, and escalation events.
AI-EMRG.1, AI-SAFE.1 - Hardware attestation: Inventory of compute infrastructure running the AI system.
AI-HW.1 - DPIA record: Data protection impact assessment with risk scores and mitigation measures.
AI-DPIA.1 - Performance metrics: Accuracy, latency, and throughput measurements against provider benchmarks.
AI-PERF.1 - Incident documentation: Records of AI-related incidents, root cause analysis, and corrective actions.
AI-INCIDENT.1 - Cross-jurisdictional transparency: Jurisdiction, legal basis, and purpose classification for each processing activity.
CJT metadata on AI-INF.1
For the generic deployer responsibility matrix covering all AI Act obligations (not GPAI-specific), see Deployer Responsibility Matrix.