Audience: You are a Notified Body assessor evaluating a high-risk AI system under Regulation (EU) 2024/1689. This walkthrough maps EU AI Act articles to SWT3 procedures that generate cryptographic compliance evidence. Each procedure mints an immutable witness anchor that you can verify independently at /verify.
SWT3 is an industry-agnostic cryptographic witness protocol. The evidence described in this guide is identical regardless of the AI system's application domain, deployment geography, or risk classification. This walkthrough maps that universal evidence to EU AI Act articles so Notified Body assessors can verify conformity using independently verifiable cryptographic proof.
Contents
1. Art. 4 -- AI Literacy 2. Art. 6 -- Risk Classification 3. Art. 9 -- Risk Management System 4. Art. 10 -- Data Governance 5. Art. 11 -- Technical Documentation 6. Art. 12 -- Record-Keeping 7. Art. 13 -- Transparency 8. Art. 14 -- Human Oversight 9. Art. 15 -- Accuracy, Robustness, and Cybersecurity 10. Art. 17 -- Quality Management System 11. Art. 25-26 -- Supply Chain and Deployer Obligations 12. Art. 27 -- Fundamental Rights Impact Assessment 13. Art. 49-50 -- CE Marking and Synthetic Content 14. Art. 53 -- GPAI Model Obligations 15. Art. 62 -- Serious Incident Reporting 16. Art. 72 -- Post-Market Monitoring 17. Anchor Anatomy 18. Related Resources1. Art. 4 -- AI Literacy
What this requires
Article 4 requires providers and deployers to ensure that their staff and other persons dealing with the operation and use of AI systems have a sufficient level of AI literacy. This obligation considers the technical knowledge, experience, education, and training of the persons involved, as well as the context in which the AI systems are to be used.
| Procedure | Title | What It Witnesses |
|---|---|---|
AI-GOV.2 | AI Governance Training | Records that responsible personnel have completed governance training covering the AI system's risk profile, intended use, and known limitations. Each training completion event is witnessed with a timestamp and participant identifier. |
How to verify
Locate the procedure in the audit portal
Navigate to the ledger and filter by procedure AI-GOV.2. Confirm that training anchors exist for all personnel identified in the provider's AI literacy plan.
Check verdict and recency
Each anchor should show a PASS verdict. Verify the epoch timestamp falls within the provider's stated training cadence (typically annual or upon role change).
Verify the anchor independently
Copy the full SWT3 anchor string to /verify. The verifier will confirm the fingerprint matches the ledger record and has not been revoked.
- Training anchors exist only for technical staff, with no coverage for business decision-makers or deployer-side operators
- Training was completed before the AI system's risk classification changed, making the anchor stale
- No AI-GOV.2 anchors at all, indicating literacy is treated as an informal process without evidence
2. Art. 6 -- Risk Classification
What this requires
Article 6 establishes the classification rules for high-risk AI systems. Providers must determine whether their system falls within Annex III categories or is a safety component of a product covered by Union harmonisation legislation listed in Annex I. This classification decision and its rationale must be documented.
| Procedure | Title | What It Witnesses |
|---|---|---|
AI-DUALUSE.1 | Dual-Use Classification | Records the provider's classification decision, including whether the system has dual-use potential (civil and military, or multiple risk categories). Witnesses the rationale and the Annex III category assignment. |
How to verify
Confirm classification evidence exists
Filter the ledger for AI-DUALUSE.1. A PASS verdict confirms the provider has documented their risk classification rationale. Review the factor data to confirm the Annex III category is specified.
Cross-reference with technical documentation
The classification recorded in AI-DUALUSE.1 should match the risk category stated in the provider's Art. 11 technical documentation. Any mismatch is a conformity gap.
- Classification recorded as "general purpose" without Annex III category analysis
- No dual-use assessment despite the system being deployable across multiple risk categories
- Classification was performed once at design time and never re-evaluated after significant changes to intended purpose
3. Art. 9 -- Risk Management System
What this requires
Article 9 is the backbone of the EU AI Act's technical requirements. It mandates a continuous, iterative risk management system that identifies, analyses, evaluates, and treats risks throughout the AI system's lifecycle. Sub-articles specify foreseeable misuse testing (9(2)(a)), residual risk identification (9(2)(b)), bias testing against affected persons (9(4)(a)), safety measures (9(4)(b)), accessibility safeguards (9(4)(c)), and adversarial testing (9(7)).
| Procedure | Title | What It Witnesses |
|---|---|---|
AI-CHAIN.1 | Chain of Custody | Witnesses the provenance chain from data ingestion through model training to deployment, establishing traceability of the AI system's lineage. |
AI-CHAIN.2 | Chain Integrity Verification | Verifies that the chain of custody has not been broken or tampered with since the last witnessed checkpoint. |
AI-GOV.1 | AI Governance Framework | Records the existence and version of the provider's AI governance framework, including risk appetite and escalation thresholds. |
AI-IMPACT.1 | Impact Assessment | Witnesses the provider's impact assessment covering affected persons, severity of potential harms, and probability estimates. |
AI-MULTI.1 | Multi-Agent Coordination | Records how risk is managed across multi-agent or compound AI systems where multiple models interact. |
AI-RISK.1 | Risk Identification | Witnesses the provider's risk register, including identified risks, their likelihood, severity, and planned mitigations. |
AI-SKILL.1 | Skill Manifest | Documents the AI system's declared capabilities and boundaries, enabling assessors to evaluate scope-of-risk. |
AI-TRUST.1 | Trust Verification | Witnesses inter-component trust relationships, confirming that each component in the system has been verified. |
AI-TRUST.2 | Credential Presentation | Records the presentation and validation of credentials between system components or between provider and deployer. |
AI-VIO.1 | Violation Detection | Witnesses that the system monitors for policy violations and that detected violations trigger appropriate responses. |
AI-GRD.1 | Guardrail Enforcement | Records guardrail configuration and confirms that input/output filters are active and blocking foreseeable misuse patterns (Art. 9(2)(a)). |
AI-BASE.1 | Baseline Measurement | Witnesses the system's performance baseline, enabling detection of residual risks through drift from known-good state (Art. 9(2)(b)). |
AI-DRIFT.1 | Drift Detection | Records continuous monitoring for model drift, data drift, or concept drift that could introduce new residual risks (Art. 9(2)(b)). |
AI-FAIR.2 | Fairness Testing | Witnesses bias testing results against protected groups, including demographic parity and equalized odds metrics (Art. 9(4)(a)). |
AI-MDL.1 | Model Registration | Records model metadata, version, and intended use, enabling traceability of which model version was bias-tested (Art. 9(4)(a)). |
AI-SKILL.3 | Reward Model Witnessing | Witnesses the reward model or objective function used in training, which directly affects fairness outcomes (Art. 9(4)(a)). |
AI-SAFE.1 | Safety Boundary | Records safety constraints and confirms the system operates within defined safe boundaries (Art. 9(4)(b)). |
AI-ACC.1 | Access Control | Witnesses access control policies ensuring the system is accessible only to authorized persons in appropriate contexts (Art. 9(4)(c)). |
AI-REDTEAM.1 | Red Team Assessment | Records adversarial testing results, including attack vectors tested, success rates, and remediation actions taken (Art. 9(7)). |
How to verify
Confirm lifecycle coverage
Art. 9 requires a continuous risk management system. Filter the ledger for all Art. 9 procedures and check that anchors span the system's lifecycle, not just a single assessment point. Look for recurring AI-DRIFT.1 and AI-VIO.1 anchors as evidence of ongoing monitoring.
Verify the risk-to-mitigation chain
For each risk identified in AI-RISK.1, trace the mitigation evidence: AI-GRD.1 (guardrails), AI-SAFE.1 (safety boundaries), AI-FAIR.2 (bias testing), or AI-REDTEAM.1 (adversarial testing). A risk without a corresponding mitigation anchor is a conformity gap.
Check adversarial testing depth
AI-REDTEAM.1 should show testing against the specific risk categories identified in the system's Annex III classification. Generic penetration testing without AI-specific attack vectors (prompt injection, data poisoning, model evasion) is insufficient under Art. 9(7).
- AI-RISK.1 exists but AI-REDTEAM.1 is absent, meaning risks were identified but never adversarially tested
- AI-DRIFT.1 anchors stop after initial deployment, indicating monitoring was abandoned
- AI-FAIR.2 tests only one protected attribute (e.g., gender) while the system operates in a context where multiple attributes are relevant
- AI-MULTI.1 is missing despite the system using a multi-model pipeline (e.g., RAG with retriever + generator)
- AI-CHAIN.1 shows a gap between training data provenance and the deployed model version
4. Art. 10 -- Data Governance
What this requires
Article 10 establishes data governance obligations for training, validation, and testing datasets. It requires purpose specification (10(2)(a)), bias examination (10(2)(f)), representativeness (10(3)), and special provisions for personal data processing (10(5)). Providers must document data collection processes, preparation procedures, and any assumptions made about the data.
| Procedure | Title | What It Witnesses |
|---|---|---|
AI-CONSENT.1 | Data Consent Tracking | Records consent status for data used in training, validation, or operation. Tracks consent withdrawal events and their downstream impact on the AI system (Art. 10). |
AI-DATA.1 | Data Provenance | Witnesses the origin, collection method, and chain of custody for datasets used in training and validation (Art. 10(2)(a)). |
AI-DATA.2 | Data Quality Assessment | Records data quality metrics including completeness, accuracy, timeliness, and consistency of training and validation datasets (Art. 10(2)(a)). |
AI-FAIR.1 | Fairness Baseline | Witnesses the fairness baseline established before deployment, including the protected attributes examined and the statistical tests applied (Art. 10(2)(f)). |
AI-FAIR.3 | Fairness Monitoring | Records ongoing fairness monitoring results post-deployment, detecting bias drift in production data distributions (Art. 10(2)(f)). |
AI-GRD.3 | Policy Version Binding | Witnesses that the data governance policy version applied to the dataset matches the version in effect at the time of data collection (Art. 10(2)(f)). |
AI-DATA.3 | Data Representativeness | Records representativeness analysis of training data relative to the intended deployment population, including identified gaps and their risk impact (Art. 10(3)). |
AI-DATA.4 | Data Retention and Deletion | Witnesses data retention policies and confirms deletion of personal data when consent is withdrawn or retention periods expire (Art. 10(5)). |
How to verify
Trace data from collection to model
Start with AI-DATA.1 (provenance) and verify it covers all datasets referenced in the provider's technical documentation. Then check AI-DATA.2 for quality metrics on those same datasets. Any dataset mentioned in Art. 11 documentation without a corresponding AI-DATA.1 anchor is a gap.
Examine fairness coverage
AI-FAIR.1 should establish the baseline before deployment; AI-FAIR.3 should show ongoing monitoring after deployment. If the system processes personal data of EU residents, AI-CONSENT.1 must show active consent tracking with evidence of withdrawal handling.
Verify representativeness
AI-DATA.3 should explicitly document the deployment population and how the training data represents it. For systems deployed across multiple EU member states, check whether representativeness was assessed per-jurisdiction or only in aggregate.
- AI-DATA.1 covers the primary training set but not validation or test sets
- AI-FAIR.1 baseline exists but AI-FAIR.3 monitoring was never activated post-deployment
- AI-CONSENT.1 is absent despite the system processing sensitive personal data
- AI-DATA.3 representativeness analysis uses global population statistics rather than the specific EU deployment context
5. Art. 11 -- Technical Documentation
What this requires
Article 11 requires providers to draw up technical documentation before the AI system is placed on the market or put into service. This documentation must demonstrate compliance with Chapter III, Section 2 requirements and provide national competent authorities and Notified Bodies with all necessary information to assess compliance. The documentation must include the system's general characteristics, development methodology, computational resources, and design choices.
| Procedure | Title | What It Witnesses |
|---|---|---|
AI-ENV.1 | Runtime Environment | Records the runtime environment specification including operating system, framework versions, and container configuration. |
AI-ENV.2 | Environment Drift | Witnesses changes to the runtime environment since the last documented baseline, detecting configuration drift. |
AI-HW.1 | Hardware Attestation | Records the hardware configuration used for training and inference, including accelerator type, memory, and compute capacity. |
AI-MDL.5 | Model Weights Hash | Witnesses a cryptographic hash of the model weights file, enabling verification that the deployed model matches the documented version. |
AI-MDL.6 | Adapter Stack | Records the adapter or fine-tuning stack applied to the base model, including LoRA ranks, layer freezing, and quantization parameters. |
AI-SBOM.1 | AI Software Bill of Materials | Witnesses the complete dependency tree of the AI system, including model components, data pipeline libraries, and inference runtime dependencies. |
How to verify
Match documentation to anchors
The provider's technical documentation should reference specific SWT3 anchors as evidence. Verify that each anchor referenced in the documentation exists in the ledger and shows a PASS verdict.
Verify model integrity
AI-MDL.5 provides a hash of the model weights. If the provider allows, compute the hash independently and compare it to the witnessed value. Any mismatch indicates the deployed model differs from the documented version.
Check SBOM completeness
AI-SBOM.1 should list all dependencies, not just direct imports. Cross-reference with the AI-ENV.1 environment record to confirm consistency between declared and actual runtime dependencies.
- AI-MDL.5 hash was computed at training time but never re-verified after model serialization or format conversion
- AI-SBOM.1 lists Python packages but omits system-level libraries (CUDA, cuDNN) that affect model behavior
- AI-ENV.1 and AI-ENV.2 show environment changes that were never reflected in updated technical documentation
- AI-HW.1 is absent, making it impossible to verify whether the documented compute requirements match the deployment infrastructure
6. Art. 12 -- Record-Keeping
What this requires
Article 12 mandates automatic logging of events throughout the AI system's lifecycle. Logs must enable traceability of the system's functioning, including the identification of input data (12(2)(a)), the specific model version producing each output (12(2)(b)), human oversight decisions (12(2)(d)), and retention periods appropriate to the system's intended purpose (12(3)). This is the article that most directly maps to the SWT3 witness pattern, as every witnessed event becomes an immutable log entry.
| Procedure | Title | What It Witnesses |
|---|---|---|
AI-AUDIT.1 | Audit Trail | Records the existence and completeness of the system's audit trail, confirming that all required event types are being logged (Art. 12). |
AI-AUDIT.2 | External Timestamp Attestation | Witnesses that log entries are anchored to an external timestamp authority (RFC 3161 TSA), preventing retroactive log manipulation (Art. 12(1)). |
AI-ID.1 | Agent Identity | Records the unique identity of each AI agent or model instance, enabling attribution of outputs to specific system components (Art. 12(1)). |
AI-INF.1 | Inference Witnessing | Witnesses individual inference events, recording the model, input hash, output hash, and timestamp (Art. 12(1)). |
AI-INF.3 | Inference Metadata | Records inference metadata including latency, token counts, and confidence scores, enabling performance analysis over time (Art. 12(1)). |
AI-TOOL.1 | Tool Invocation | Witnesses tool calls made by AI agents, including the tool name, parameters, and return values (Art. 12(1)). |
AI-INF.2 | Inference Chain | Records the sequence of inferences in multi-step reasoning, establishing the chain from initial prompt to final output (Art. 12(2)). |
AI-SKILL.2 | Memory Context | Witnesses the memory or context state accessed by the AI system during inference, enabling reconstruction of what information was available to the system (Art. 12(2)(a)). |
AI-MDL.2 | Model Version Tracking | Records which specific model version (including fine-tune and adapter version) produced each output, enabling version-to-output traceability (Art. 12(2)(b)). |
AI-HITL.3 | Human Override Logging | Witnesses human intervention events where a human operator overrode, corrected, or vetoed the AI system's output (Art. 12(2)(d)). |
AI-LOG.1 | Log Retention Compliance | Records that log retention periods meet the minimum duration appropriate to the system's intended purpose and risk classification (Art. 12(3)). |
How to verify
Verify logging completeness
AI-AUDIT.1 should confirm that the system logs all event types required by Art. 12. Cross-reference the logged event types against the sub-articles: input data (12(2)(a)), model version (12(2)(b)), human overrides (12(2)(d)), and retention (12(3)). Each should have a corresponding procedure with a PASS anchor.
Check timestamp integrity
AI-AUDIT.2 provides external timestamp attestation. If present, it confirms that the provider uses RFC 3161 timestamping, which makes retroactive log manipulation cryptographically detectable. This is a strong conformity signal.
Verify inference traceability
Select a sample of AI-INF.1 anchors and confirm that each can be traced to a specific model version via AI-MDL.2. For multi-step systems, verify that AI-INF.2 chains connect the full reasoning path.
- AI-INF.1 records inference events but AI-MDL.2 is missing, breaking the output-to-model-version traceability chain
- AI-HITL.3 is absent despite the provider claiming human-in-the-loop operation
- AI-LOG.1 shows a retention period shorter than the system's expected operational lifetime
- AI-TOOL.1 is missing in agentic systems that invoke external APIs, databases, or code execution
7. Art. 13 -- Transparency
What this requires
Article 13 requires that high-risk AI systems be designed and developed in such a way as to ensure that their operation is sufficiently transparent to enable deployers to interpret the system's output and use it appropriately. This includes general transparency of operation (13(1)), and specific requirements for deployers to understand the system's capabilities and limitations (13(3)(b)(ii)). Transparency obligations extend to retrieval-augmented generation systems where the source of retrieved information must be traceable.
| Procedure | Title | What It Witnesses |
|---|---|---|
AI-CHR.1 | Chronological Record | Witnesses the chronological sequence of system operations, creating a timeline that deployers can review to understand system behavior over time. |
AI-RAG.1 | RAG Provenance | Records the source documents retrieved during retrieval-augmented generation, enabling deployers to trace generated content back to its information sources. |
AI-RAG.2 | RAG Relevance | Witnesses the relevance scoring of retrieved documents, confirming that the retrieval pipeline is surfacing contextually appropriate information. |
AI-TRANS.1 | Transparency Declaration | Records the provider's transparency declaration, including intended use, known limitations, and foreseeable misuse scenarios. |
AI-EXPL.1 | Explainability | Witnesses that the system can provide explanations for its outputs at a level appropriate to the deployment context (Art. 13(1)). |
AI-EXPL.2 | Output Interpretation | Records the interpretability mechanisms available to deployers, including confidence indicators and feature attribution (Art. 13(3)(b)(ii)). |
How to verify
Assess transparency adequacy
AI-TRANS.1 should exist and show a PASS verdict. Review the factor data to confirm the transparency declaration covers intended use, limitations, and foreseeable misuse. Compare this against the system's actual deployment context.
Verify RAG traceability (if applicable)
For RAG systems, AI-RAG.1 and AI-RAG.2 should show ongoing PASS verdicts. If only AI-RAG.1 exists without AI-RAG.2, the provider is tracking provenance but not verifying relevance, which may be insufficient for high-risk deployments.
Test explainability in practice
AI-EXPL.1 witnesses that explainability mechanisms exist. During your assessment, request sample explanations from the system and verify they are comprehensible to a non-technical deployer. The anchor confirms the mechanism exists; you must confirm it is adequate.
- AI-EXPL.1 exists but the actual explanations are technical model internals (attention weights, logits) rather than deployer-comprehensible narratives
- AI-RAG.1 is missing in systems that clearly use retrieval, indicating undocumented data flows
- AI-TRANS.1 transparency declaration was written for a different deployment context than the current one
8. Art. 14 -- Human Oversight
What this requires
Article 14 requires that high-risk AI systems be designed to allow effective human oversight during the period they are in use. The system must enable the human overseer to fully understand the system's capacities and limitations (14(1)), properly monitor its operation, and intervene or interrupt the system when necessary (14(4)(d)). This includes the ability to decide not to use the system, override its output, or reverse its decisions.
| Procedure | Title | What It Witnesses |
|---|---|---|
AI-AUTO.1 | Autonomy Level Declaration | Records the declared autonomy level of the AI system, distinguishing between advisory, semi-autonomous, and fully autonomous operation modes. |
AI-AUTO.2 | Autonomous Generation Depth | Witnesses the depth of autonomous operation, including recursive or self-directed generation chains that may operate beyond direct human oversight. |
AI-HITL.1 | Human-in-the-Loop Configuration | Records the human oversight configuration, including which decisions require human approval, review thresholds, and escalation triggers (Art. 14(1)). |
AI-HITL.2 | Human Override Capability | Witnesses that the system supports human override, including the ability to interrupt, reverse, or veto AI decisions in real time (Art. 14(4)(d)). |
AI-REV.1 | Anchor Revocation | Records the revocation of a previously issued witness anchor, demonstrating the ability to retract or invalidate a prior AI output or decision (Art. 14(4)(d)). |
How to verify
Verify oversight is proportional to autonomy
Compare AI-AUTO.1 (declared autonomy) with AI-HITL.1 (oversight configuration). Higher autonomy levels should correspond to more rigorous human oversight mechanisms. A system declared as "fully autonomous" with minimal HITL configuration is a significant conformity risk.
Test override and revocation capability
AI-HITL.2 should show a PASS verdict confirming override capability exists. AI-REV.1 anchors demonstrate that revocation has been exercised at least once. The absence of any AI-REV.1 anchors in a long-running system may indicate the override capability exists in design but has never been tested in practice.
Check autonomous generation depth
AI-AUTO.2 is particularly relevant for agentic AI systems that can recursively generate content or invoke tools without per-step human approval. Verify that the witnessed depth limits align with the provider's declared autonomy level.
- AI-HITL.1 shows "human-in-the-loop" configuration but AI-HITL.3 (from Art. 12) logs show zero actual human interventions over months of operation
- AI-AUTO.2 is missing despite the system performing multi-step agentic workflows
- AI-REV.1 has never been used, raising questions about whether the revocation mechanism is operational
- Override latency (time between AI output and human review) exceeds the timeframe in which the output has already been acted upon
9. Art. 15 -- Accuracy, Robustness, and Cybersecurity
What this requires
Article 15 addresses the technical integrity of the AI system. It requires appropriate levels of accuracy (15(1)), resilience against errors and inconsistencies (15(3)), and cybersecurity measures proportionate to the risk level (15(4)). Robustness testing must cover adversarial inputs, data corruption, and environmental perturbations. Cybersecurity measures must protect against attacks that exploit system-specific vulnerabilities, including data poisoning, model manipulation, and adversarial examples.
| Procedure | Title | What It Witnesses |
|---|---|---|
AI-HW.3 | Hardware Resilience | Records hardware-level resilience measures including redundancy, failover capability, and error correction in the inference infrastructure (Art. 15). |
AI-PERF.1 | Performance Metrics | Witnesses accuracy, precision, recall, F1, or domain-specific performance metrics appropriate to the system's intended purpose (Art. 15(1)). |
AI-GRD.2 | Output Validation | Records output validation rules that detect and filter anomalous, corrupt, or out-of-distribution outputs (Art. 15(3)). |
AI-MDL.7 | Quantization Witnessing | Witnesses the quantization parameters applied to the model, documenting any accuracy trade-offs from model compression (Art. 15(3)). |
AI-ROBUST.1 | Robustness Testing | Records robustness testing results, including perturbation tolerance, noise sensitivity, and degradation curves (Art. 15(3)). |
AI-SEC.2 | Model Security | Witnesses model-level security measures including weight encryption, inference isolation, and side-channel protections (Art. 15(3)). |
AI-CYBER.1 | Cybersecurity Assessment | Records the results of cybersecurity assessments specific to the AI system, including attack surface analysis and vulnerability scanning (Art. 15(4)). |
AI-MDL.4 | Model Integrity | Witnesses the integrity of the deployed model, detecting unauthorized modifications through cryptographic verification (Art. 15(4)). |
AI-SEC.1 | Security Configuration | Records the security configuration of the AI system's infrastructure, including network isolation, API authentication, and encryption at rest (Art. 15(4)). |
How to verify
Validate accuracy claims
AI-PERF.1 should record metrics relevant to the system's intended purpose. The assessor determines whether the witnessed metrics align with the provider's accuracy claims in their technical documentation.
Assess robustness coverage
AI-ROBUST.1 should demonstrate testing against perturbations relevant to the deployment context. AI-MDL.7 documents quantization trade-offs. If the model has been quantized, verify that AI-PERF.1 metrics were re-evaluated after quantization, not only on the full-precision model.
Verify cybersecurity proportionality
AI-CYBER.1 and AI-SEC.1 should reflect measures proportionate to the risk classification. A high-risk system handling personal data requires stronger protections than one operating on publicly available information. Cross-reference with AI-MDL.4 to confirm model integrity is continuously monitored.
- AI-PERF.1 reports benchmark scores from the model provider's published results rather than the provider's own evaluation on deployment-relevant data
- AI-ROBUST.1 tests only adversarial text inputs while the system also accepts images or structured data
- AI-CYBER.1 is a generic infrastructure security scan without AI-specific attack vectors (prompt injection, model extraction, training data poisoning)
- AI-MDL.4 integrity check was run once at deployment but no continuous verification is in place
- AI-MDL.7 is missing despite the system using a quantized model, obscuring accuracy degradation
10. Art. 17 -- Quality Management System
What this requires
Article 17 requires providers to establish a quality management system (QMS) that ensures compliance with the Regulation in a systematic and documented manner. The QMS must cover design and development procedures, quality control mechanisms, examination and testing procedures, and post-market monitoring. It must be proportionate to the size of the provider's organisation.
| Procedure | Title | What It Witnesses |
|---|---|---|
AI-GOV.6 | QMS Documentation | Records the existence, version, and scope of the provider's quality management system documentation, including its coverage of AI-specific processes. |
AI-GOV.7 | QMS Review | Witnesses periodic QMS review events, confirming that the quality management system is being actively maintained and updated in response to findings. |
How to verify
Confirm QMS scope
AI-GOV.6 should show a PASS verdict with factor data indicating the QMS covers AI-specific processes, not just generic software quality. Check that the QMS version matches the current operational state of the system.
Verify review cadence
AI-GOV.7 anchors should appear at regular intervals (quarterly or annually). A long gap between AI-GOV.7 anchors suggests the QMS review process has lapsed.
- AI-GOV.6 references an ISO 9001 QMS that predates the organisation's AI activities and contains no AI-specific procedures
- AI-GOV.7 shows a single review event with no follow-up, indicating one-time documentation rather than continuous improvement
- QMS scope covers the AI system in isolation but not the data pipeline, annotation process, or human oversight workflow
11. Art. 25-26 -- Supply Chain and Deployer Obligations
What this requires
Article 25 establishes the obligations of authorized representatives, who act on behalf of providers established outside the Union. Article 26 sets out deployer obligations, including the duty to use the AI system in accordance with its instructions for use, to assign competent human overseers, and to monitor the system's operation. Together, these articles create a supply chain accountability framework where both providers and deployers bear specific, documented responsibilities.
| Procedure | Title | What It Witnesses |
|---|---|---|
AI-GOV.5 | Authorized Representative | Records the designation and identity of the authorized representative within the Union, including their mandate scope and contact details (Art. 25). |
AI-SUPPLY.1 | Supply Chain Mapping | Witnesses the supply chain structure, including the provider, authorized representative, importer, distributor, and deployer, with their respective responsibilities documented (Art. 25). |
AI-GOV.4 | Deployer Governance | Records the deployer's governance framework for using the AI system, including their compliance obligations, monitoring practices, and incident reporting procedures (Art. 26). |
How to verify
Verify supply chain completeness
AI-SUPPLY.1 should map the full chain from provider to deployer. For non-EU providers, AI-GOV.5 must confirm an authorized representative is designated. Cross-reference the supply chain map against the EU Declaration of Conformity.
Assess deployer preparedness
AI-GOV.4 should show that the deployer has documented their own obligations under Art. 26, not merely relied on the provider's documentation. This is especially important when the deployer modifies the system's intended purpose.
- AI-GOV.5 is missing for a provider headquartered outside the EU, which is a mandatory requirement
- AI-SUPPLY.1 identifies the provider and deployer but omits intermediaries (importers, distributors) who also bear obligations
- AI-GOV.4 is a copy of the provider's documentation rather than the deployer's own governance framework
12. Art. 27 -- Fundamental Rights Impact Assessment
What this requires
Article 27 requires deployers of high-risk AI systems that are bodies governed by public law, or private entities providing public services, to perform a fundamental rights impact assessment (FRIA) before putting the system into use. The FRIA must describe the deployer's processes, the period and frequency of use, the categories of affected natural persons, and the specific risks of harm to fundamental rights.
| Procedure | Title | What It Witnesses |
|---|---|---|
AI-DPIA.1 | Data Protection Impact Assessment | Records the completion of a FRIA/DPIA, including the scope of affected persons, identified fundamental rights risks, and planned mitigation measures. Combines GDPR Art. 35 DPIA and EU AI Act Art. 27 FRIA requirements. |
How to verify
Confirm FRIA was conducted before deployment
The AI-DPIA.1 anchor's epoch timestamp must predate the system's operational deployment date. A FRIA conducted after the system is already in use does not satisfy Art. 27.
Verify scope of rights assessed
Review the factor data to confirm the assessment covers all fundamental rights relevant to the deployment context, not only data protection. Art. 27 references the Charter of Fundamental Rights of the European Union broadly.
- AI-DPIA.1 covers GDPR data protection risks but not broader fundamental rights (non-discrimination, freedom of expression, human dignity)
- FRIA was conducted at the organizational level rather than for the specific AI system being assessed
- No AI-DPIA.1 anchor exists despite the deployer being a public authority
13. Art. 49-50 -- CE Marking and Synthetic Content
What this requires
Article 49 requires that high-risk AI systems bear the CE marking to indicate conformity with the Regulation. The CE marking must be affixed before the system is placed on the market. Article 50(2) requires that providers of AI systems that generate synthetic audio, image, video, or text content ensure that the outputs are marked in a machine-readable format as artificially generated or manipulated. This applies to deep fakes, synthetic media, and AI-generated text.
| Procedure | Title | What It Witnesses |
|---|---|---|
AI-GOV.3 | Conformity Declaration | Records the provider's EU Declaration of Conformity, confirming that the conformity assessment has been completed and the CE marking is justified (Art. 49). |
AI-MARK.1 | Content Marking | Witnesses that AI-generated content is marked with machine-readable provenance metadata, enabling downstream systems to identify synthetic content (Art. 50(2)). |
AI-WATERMARK.1 | Watermark Embedding | Records the application of digital watermarks to synthetic content, including the watermark technique, robustness parameters, and detection mechanism (Art. 50(2)). |
How to verify
Verify CE marking basis
AI-GOV.3 should reference the specific conformity assessment procedure followed (Annex VI internal control or Annex VII with Notified Body involvement). The anchor's factor data should link to the Declaration of Conformity document.
Test content marking (if applicable)
For systems that generate synthetic content, request sample outputs and verify that AI-MARK.1 metadata is present and machine-readable. For watermarked content (AI-WATERMARK.1), verify that the watermark survives common transformations (compression, cropping, format conversion) as claimed by the provider.
- AI-GOV.3 references a Declaration of Conformity that was drafted before the conformity assessment was completed
- AI-MARK.1 metadata is present in API responses but stripped by the deployer's front-end application
- AI-WATERMARK.1 watermarks do not survive JPEG compression or screenshot capture, rendering them ineffective in practice
14. Art. 53 -- GPAI Model Obligations
What this requires
Article 53(1)(d) requires providers of general-purpose AI (GPAI) models to put in place a policy to comply with Union law on copyright, in particular to identify and comply with reservations of rights expressed pursuant to Article 4(3) of Directive (EU) 2019/790 (the DSM Directive). This includes making publicly available a sufficiently detailed summary of the content used for training.
| Procedure | Title | What It Witnesses |
|---|---|---|
AI-LIC.1 | Model Licensing Compliance | Records the provider's copyright compliance posture, including the model's license terms, training data copyright analysis, and opt-out mechanism for rights holders (Art. 53(1)(d)). |
How to verify
Check licensing documentation
AI-LIC.1 should confirm the provider has a copyright compliance policy. Review the factor data for references to the model's training data summary and opt-out mechanism. For GPAI models, the training data summary should be publicly available as required by Art. 53(1)(d).
Verify opt-out mechanism
If the model was trained on web-scraped data, confirm the provider has implemented a mechanism for rights holders to opt out of future training. The absence of such a mechanism is a conformity gap under Art. 53(1)(d).
- AI-LIC.1 references the upstream model provider's license but does not address the deployer's own copyright obligations for fine-tuning data
- Training data summary is missing or describes categories ("web data") rather than specific sources
- AI-LIC.1 is absent entirely for systems built on open-weight GPAI models, under the assumption that open licenses eliminate copyright obligations
15. Art. 62 -- Serious Incident Reporting
What this requires
Article 62 requires providers of high-risk AI systems to report any serious incident to the market surveillance authorities of the Member States where the incident occurred. A "serious incident" means an incident or malfunctioning that directly or indirectly leads to death, serious damage to health, serious disruption to critical infrastructure, or serious breaches of fundamental rights obligations. Reports must be filed immediately and no later than 15 days after the provider becomes aware of the incident.
| Procedure | Title | What It Witnesses |
|---|---|---|
AI-INCIDENT.1 | Incident Classification | Records the classification of AI-related incidents, including severity assessment, affected persons, and whether the incident meets the Art. 62 "serious incident" threshold. |
AI-IR.1 | Incident Response | Witnesses the incident response actions taken, including containment, root cause analysis, corrective measures, and regulatory notification timestamps. |
How to verify
Verify incident response readiness
Even if no serious incidents have occurred, AI-INCIDENT.1 should exist with a PASS verdict confirming the provider has an incident classification framework in place. The absence of any incident-related anchors suggests the provider has no systematic incident management process.
Check response timeliness
If AI-IR.1 anchors exist for past incidents, verify the timestamps. The time between the incident classification (AI-INCIDENT.1) and the response action (AI-IR.1) should be consistent with Art. 62's 15-day reporting requirement. The witness anchors provide cryptographic proof of when each action was taken.
- AI-INCIDENT.1 classification exists only for technical failures (model errors), not for fundamental rights impacts
- AI-IR.1 shows corrective actions but no evidence of regulatory notification
- No incident management anchors exist at all, despite the system having been operational for months
16. Art. 72 -- Post-Market Monitoring
What this requires
Article 72 requires providers to establish and document a post-market monitoring system proportionate to the nature of the AI technology and the risks of the high-risk AI system. The system must actively and systematically collect, document, and analyse relevant data provided by deployers or collected through other sources. Article 72(1) specifies that the monitoring system must allow the provider to continuously evaluate the AI system's compliance throughout its lifetime.
| Procedure | Title | What It Witnesses |
|---|---|---|
AI-PMM.1 | Post-Market Monitoring Plan | Records the existence and scope of the provider's post-market monitoring plan, including data collection methods, analysis frequency, and escalation criteria (Art. 72). |
AI-MDL.3 | Model Lifecycle Tracking | Witnesses the model's operational lifecycle events, including version deployments, performance degradation, retraining decisions, and retirement (Art. 72(1)). |
How to verify
Confirm monitoring is active
AI-PMM.1 should show a recent PASS verdict, not just one from the initial deployment. Post-market monitoring is a continuous obligation. Check that AI-MDL.3 anchors appear at regular intervals corresponding to the monitoring cadence declared in the plan.
Verify lifecycle coverage
AI-MDL.3 should cover the full lifecycle. For systems that have been updated, each model version should have its own lifecycle anchors. A gap in AI-MDL.3 anchors between versions indicates a period of unmonitored operation.
Cross-reference with drift detection
AI-PMM.1's monitoring plan should reference AI-DRIFT.1 (from Art. 9) as one of its data sources. Post-market monitoring without drift detection is monitoring without teeth.
- AI-PMM.1 was created at launch but never updated as the system's deployment context evolved
- AI-MDL.3 lifecycle tracking stops at the current production version, with no evidence of monitoring for previous versions still in use by some deployers
- Post-market monitoring plan collects deployer feedback but does not systematically analyse it for compliance signals
17. Anchor Anatomy
Every SWT3 Witness Anchor follows a fixed format that encodes the deployment tier, infrastructure provider, compliance domain, specific procedure, verdict, timestamp, and a cryptographic fingerprint. Here is how to read one:
SHA256("WITNESS:{tenant}:{procedure}:{factor_a}:{factor_b}:{factor_c}:{timestamp_ms}").hex()[:12]The fingerprint is deterministic. Given the same inputs, any implementation in any language will produce the same 12-character hex string. This enables independent verification without access to the provider's infrastructure.
18. Related Resources
- Assessment Mapping -- Procedure-to-article mapping for all supported frameworks
- Assessor Checklist -- Printable checklist for conformity assessment evidence collection
- Anchor Verifier -- Verify individual anchors or run enclave-wide integrity checks
- UCT Registry -- Complete procedure catalog with namespace filtering
- Assessment Playbook -- Multi-framework assessment methodology for all evaluator types
- FRIA/DPIA Mapping -- Detailed mapping of FRIA (Art. 27) and DPIA (Art. 35) to SWT3 procedures
- SDK Documentation -- Python, TypeScript, and additional language SDK references