SWT3 witness anchors prove that specific operational controls were active at a specific point in time. They do not replace the assessor's independent judgment, professional expertise, or regulatory authority. Assessors must verify that anchored evidence is sufficient, appropriate, and relevant to the specific assessment context. Conformity assessment remains the exclusive competence of the Notified Body per Article 43.
This guide maps SWT3 witness anchor evidence to the conformity assessment requirements of Regulation (EU) 2024/1689 (the EU Artificial Intelligence Act). It is written for Notified Body assessors performing conformity assessments under Article 43, and for conformity assessment bodies evaluating AI systems against the technical requirements in Chapters III and V.
For each applicable article, this guide identifies:
SWT3 provides cryptographic evidence of operational facts. It does not replace policy documentation, risk narratives, or organizational governance structures. This guide is explicit about those boundaries.
This guide covers two tracks within the EU AI Act:
| Track | Chapter | Articles | Enforcement Date |
|---|---|---|---|
| High-Risk AI Systems (Annex III, standalone) | Chapter III, Section 2 | Art. 9, 10, 11, 12, 13, 14, 15 | 2 December 2027 (Digital Omnibus deferral) |
| High-Risk AI Systems (Annex I, safety components) | Chapter III, Section 2 | Art. 9, 10, 11, 12, 13, 14, 15 | 2 August 2028 (Digital Omnibus deferral) |
| GPAI Models | Chapter V | Art. 51, 53, 55, 56 | 2 August 2025 (enforceable now) |
Scope of application: High-risk AI systems as classified under Article 6 (systems listed in Annex III or used as safety components of products covered by Annex I). GPAI models as defined in Article 3(63), with systemic risk classification under Article 51.
The EU AI Act defines two conformity assessment procedures for high-risk AI systems:
The provider performs a self-assessment against the requirements of Section 2 (Articles 9-15). SWT3 evidence serves as the provider's internal compliance evidence. The provider must demonstrate that their quality management system produces cryptographic proof of ongoing compliance.
How SWT3 fits: Anchor chains serve as the automatic documentation of operational compliance. The provider presents anchor history, compliance passports, and verification results as evidence of their internal control process.
A Notified Body evaluates the provider's quality management system and technical documentation. SWT3 evidence supports the NB's assessment by providing independently verifiable proof of runtime behavior.
How SWT3 fits: The NB independently verifies anchor fingerprints using standard SHA-256 (no proprietary tooling required). The NB reviews procedure coverage, verdict distribution, and clearing level appropriateness. The NB can spot-check any individual anchor by recomputing its fingerprint from the factor inputs.
Providers of high-risk AI systems shall establish, implement, document, and maintain a risk management system throughout the AI system's lifecycle. The system shall identify and analyse known and reasonably foreseeable risks, adopt suitable risk management measures, and ensure residual risks are communicated to deployers.
| Procedure | Title | Article Ref | Factor Semantics |
|---|---|---|---|
AI-MDL.1 | Model Identity Verification | Art. 9(4)(a) | fa: hash present (1/0), fb: hash match (1/0), fc: method code |
AI-GRD.1 | Guardrail Enforcement | Art. 9(2)(a) | fa: guardrails required, fb: guardrails active, fc: 0 |
AI-GRD.2 | Content Safety Classification | Art. 9(4)(b) | fa: categories checked, fb: passed (1/0), fc: 0 |
AI-FAIR.2 | Fairness Threshold Calibration | Art. 9(6) | fa: threshold (scaled), fb: observed (scaled), fc: 0 |
AI-GOV.1 | Acceptable Use Policy Attestation | Art. 9(1) | fa: policy hash present (1/0), fb: enforced (1/0), fc: 0 |
AI-ACC.1 | Agent Access Control | Art. 9(4)(c) | fa: scopes requested, fb: scopes granted, fc: 0 |
AI-SEC.1 | Adversarial Threat Detection | Art. 9(2) | fa: tests run, fb: tests passed, fc: severity code |
Partial SWT3 provides evidence that risk mitigation measures are operational at runtime. The risk management system documentation itself (risk identification, risk analysis, residual risk communication) is supplementary.
Training, validation, and testing data sets shall be subject to appropriate data governance and management practices. Data sets shall be relevant, sufficiently representative, and to the best extent possible free of errors and complete.
| Procedure | Title | Article Ref | Factor Semantics |
|---|---|---|---|
AI-DATA.1 | Training Data Provenance | Art. 10(2)(a) | fa: source count, fb: verified (1/0), fc: 0 |
AI-DATA.2 | Data Quality Assessment | Art. 10(2)(f) | fa: quality score (scaled), fb: threshold (scaled), fc: 0 |
AI-DATA.3 | Training Data Statistics | Art. 10(3) | fa: row count, fb: feature count, fc: class balance (scaled) |
AI-DATA.4 | PII Lifecycle Management | Art. 10(5) | fa: record count, fb: pseudonymized (1/0), fc: method code |
AI-FAIR.1 | Bias Detection | Art. 10(3) | fa: threshold (scaled), fb: observed score (scaled), fc: 0 |
AI-GRD.3 | PII Redaction at Inference | Art. 10(2)(f) | fa: patterns required, fb: patterns enforced, fc: 0 |
Partial SWT3 witnesses data quality metrics, bias scores, and PII lifecycle events. Training data governance policies, data provenance documentation, and representativeness analysis are supplementary evidence the provider must supply.
Technical documentation shall be drawn up before the AI system is placed on the market or put into service, and shall be kept up to date. It shall demonstrate compliance with the requirements set out in Section 2.
| Procedure | Title | Article Ref | Factor Semantics |
|---|---|---|---|
AI-MDL.1 | Model Identity Verification | Art. 11(1) | fa: hash present (1/0), fb: hash match (1/0), fc: 0 |
AI-MDL.2 | Model Version Tracking | Art. 11(1) | fa: version registered (1/0), fb: version match (1/0), fc: 0 |
AI-SBOM.1 | AI Software Bill of Materials | Art. 11(1) | fa: component count, fb: all identified (1/0), fc: format code |
AI-CHR.1 | Agent Charter Attestation | Art. 11(1) | fa: charter hash present (1/0), fb: hash match (1/0), fc: 0 |
Partial SWT3 anchors provide automatic documentation of model identity, version, and component composition. The narrative technical documentation required by Annex IV (general description, design specifications, development methodology) is supplementary.
High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system. Logging capabilities shall ensure a level of traceability of the AI system's functioning throughout its lifecycle.
| Procedure | Title | Article Ref | Factor Semantics |
|---|---|---|---|
AI-INF.1 | Inference Provenance | Art. 12(1) | fa: witnessed (1), fb: recorded (1), fc: 0 |
AI-INF.2 | Inference Latency Monitoring | Art. 12(2) | fa: threshold (ms), fb: observed (ms), fc: 0 |
AI-INF.3 | Inference Volume Tracking | Art. 12(2) | fa: expected volume, fb: observed volume, fc: 0 |
AI-LOG.1 | Structured Log Attestation | Art. 12(1) | fa: log entries, fb: schema-compliant (1/0), fc: format code |
AI-TOOL.1 | Tool Call Accountability | Art. 12(1) | fa: tool invoked (1), fb: result code, fc: success (1/0) |
AI-ID.1 | Agent Identity Attestation | Art. 12(1) | fa: identity present (1), fb: verified (1), fc: 0 |
AI-AUDIT.1 | Audit Log Integrity | Art. 12(1) | fa: entries audited, fb: integrity verified (1/0), fc: 0 |
Full SWT3 provides automatic recording of events with cryptographic integrity, timestamp, and independent verification. This directly satisfies the record-keeping requirement. The anchor chain itself is the log.
High-risk AI systems shall 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.
| Procedure | Title | Article Ref | Factor Semantics |
|---|---|---|---|
AI-EXPL.1 | Explainability Attestation | Art. 13(1) | fa: explanation present (1/0), fb: method code, fc: 0 |
AI-EXPL.2 | Confidence Score Reporting | Art. 13(3)(b)(ii) | fa: confidence threshold, fb: observed confidence, fc: 0 |
AI-TRANS.1 | Transparency Notice | Art. 13(3)(b) | fa: notice displayed (1/0), fb: 1, fc: 0 |
Partial SWT3 witnesses explainability and confidence score generation. User-facing transparency notices, instructions for use, and deployer information packages are supplementary.
High-risk AI systems shall be designed and developed in such a way as to be effectively overseen by natural persons during the period in which they are in use. Human oversight measures shall aim to prevent or minimise risks, including through the ability to interrupt, override, or reverse AI system outputs.
| Procedure | Title | Article Ref | Factor Semantics |
|---|---|---|---|
AI-HITL.1 | Human Review Attestation | Art. 14(1) | fa: review required (1), fb: review completed (1), fc: 0 |
AI-HITL.2 | Override Capability | Art. 14(4)(d) | fa: override available (1), fb: override exercised (1/0), fc: 0 |
AI-HITL.3 | Reviewer Identity Binding | Art. 14(1) | fa: reviewers required, fb: reviewers present, fc: identity method code |
AI-REV.1 | Output Revocation | Art. 14(4)(d) | fa: 1, fb: 1, fc: revocation reason code |
AI-EMRG.1 | Emergency Override | Art. 14(4)(e) | fa: trigger type code, fb: response action code, fc: 0 |
Partial SWT3 witnesses that human review was exercised, that override capability exists, and that revocation and emergency stop mechanisms function. However, Art. 14 also requires the system to be designed and developed to enable effective human oversight -- this is an architectural property that an external witness layer cannot fully attest. SWT3 proves oversight was exercised; supplementary evidence must demonstrate the system was designed to facilitate it.
High-risk AI systems shall be designed and developed in such a way as to achieve an appropriate level of accuracy, robustness, and cybersecurity, and to perform consistently in those respects throughout their lifecycle.
| Procedure | Title | Article Ref | Factor Semantics |
|---|---|---|---|
AI-DRIFT.1 | Model Drift Detection | Art. 15(1) | fa: baseline score (scaled), fb: current score (scaled), fc: 0 |
AI-DRIFT.2 | Consequence-Mapped Drift | Art. 15(1) | fa: trigger type code, fb: response action code, fc: 0 |
AI-MDL.1 | Model Integrity Verification | Art. 15(3) | fa: hash present (1/0), fb: hash match (1/0), fc: 0 |
AI-PERF.1 | Performance Benchmark | Art. 15(1) | fa: benchmark score (scaled), fb: threshold (scaled), fc: benchmark type code |
AI-ROBUST.1 | Robustness Testing | Art. 15(3) | fa: perturbation count, fb: survived count, fc: perturbation type code |
AI-SEC.1 | Adversarial Threat Detection | Art. 15(4) | fa: tests run, fb: tests passed, fc: severity code |
AI-CYBER.1 | Cybersecurity Posture | Art. 15(4) | fa: controls assessed, fb: controls passing, fc: framework code |
Partial SWT3 witnesses model integrity, drift detection, performance metrics, robustness testing, and cybersecurity posture at runtime. However, Art. 15 also requires appropriate accuracy levels to be achieved by design and declared in instructions for use -- these are design-time and documentation requirements that runtime monitoring alone cannot satisfy. SWT3 proves ongoing monitoring; supplementary evidence must demonstrate design-time accuracy targets and declared performance levels.
This section maps SWT3 evidence to the obligations of providers of general-purpose AI models under Chapter V of the EU AI Act. These obligations apply to any organization that develops, trains, or substantially modifies a GPAI model and makes it available on the market.
Providers of GPAI models shall: (a) draw up and keep up to date technical documentation; (b) make available information and documentation to downstream providers integrating the model; (c) establish a policy to comply with copyright law; (d) make publicly available a sufficiently detailed summary of the training data.
| Procedure | Title | Art. 53 Ref | Factor Semantics |
|---|---|---|---|
AI-MDL.1 | Model Identity Verification | 53(1)(a) | fa: hash present (1/0), fb: hash match (1/0), fc: 0 |
AI-MDL.2 | Model Version Tracking | 53(1)(a) | fa: version registered (1/0), fb: version match (1/0), fc: 0 |
AI-SBOM.1 | AI Software Bill of Materials | 53(1)(a) | fa: component count, fb: all identified (1/0), fc: format code |
AI-CHR.1 | Agent Charter Attestation | 53(1)(a) | fa: charter hash present (1/0), fb: hash match (1/0), fc: 0 |
AI-LIC.1 | License Compliance | 53(1)(c) | fa: license type code, fb: compliant (1/0), fc: 0 |
AI-DEL.1 | Delegation Attestation | 53(1)(b) | fa: deployer count, fb: required procedures, fc: delegation type code |
Article 53(1)(b) requires GPAI providers to make information and documentation available to downstream providers. For organizations whose models are used by third parties -- whether through open-weight distribution, API access, cloud platform hosting, or embedded integration -- SWT3 provides a mechanism to demonstrate downstream compliance without accessing deployer infrastructure.
How it works:
This pattern is distribution-model-neutral:
| Distribution Model | Example | Delegation Type |
|---|---|---|
| Open-weight | Model weights distributed for local deployment | Code 0 |
| API access | Model served via inference API | Code 1 |
| Cloud platform | Model hosted on provider's cloud infrastructure | Code 2 |
| Embedded | Model integrated into provider's application | Code 3 |
Cross-provider interoperability: A deployer building on models from multiple providers uses a single SWT3 integration. The same anchors serve all provider relationships.
Partial SWT3 witnesses model identity, version tracking, SBOM, license compliance, and downstream deployer coverage. Technical documentation narrative, training data summaries, and copyright compliance policies are supplementary.
Providers of GPAI models with systemic risk shall: (a) perform model evaluation including adversarial testing; (b) assess and mitigate systemic risks; (c) report serious incidents to the AI Office; (d) ensure an adequate level of cybersecurity protection.
| Procedure | Title | Art. 55 Ref | Factor Semantics |
|---|---|---|---|
AI-REDTEAM.1 | Red Team Testing | 55(1)(a) | fa: category code, fb: tests run, fc: vulnerabilities found |
AI-ASSESS.1 | Champion-Challenger Assessment | 55(1)(a) | fa: challenger score, fb: champion score, fc: threshold breached (0/1) |
AI-INCIDENT.1 | Incident Report Attestation | 55(1)(c) | fa: severity code, fb: incident type code, fc: reported (1/0) |
AI-SEC.1 | Adversarial Threat Detection | 55(1)(d) | fa: tests run, fb: tests passed, fc: severity code |
AI-CYBER.1 | Cybersecurity Posture | 55(1)(d) | fa: controls assessed, fb: controls passing, fc: framework code |
Partial SWT3 provides evidence that adversarial testing, model evaluation, incident reporting, and cybersecurity measures are operational. Systemic risk assessment narratives, mitigation plans, and AI Office communications are supplementary.
The AI Office shall encourage and facilitate the drawing up of codes of practice at Union level. GPAI model providers may rely on adherence to a code of practice to demonstrate compliance with Art. 53 and 55 obligations.
When a code of practice specifies operational requirements (e.g., "providers shall monitor model drift," "providers shall perform red-team testing quarterly"), SWT3 anchors provide cryptographic proof that those operational requirements were met. The anchor chain serves as a verifiable compliance log referenced by the code of practice.
Partial SWT3 provides evidence of operational adherence to code-of-practice requirements. The code of practice itself, governance documentation, and provider's declaration of adherence are supplementary.
SWT3 provides cryptographic evidence of operational facts. It does not replace policy documentation, risk narratives, or organizational governance structures. The following items are explicitly outside the scope of SWT3 evidence:
An assessor encountering SWT3 evidence should evaluate it as one layer of a multi-layer evidence package. SWT3 anchors prove that controls were operational at runtime. Supplementary evidence proves that policies, procedures, and documentation exist and are adequate.
The following workflow is recommended for assessors evaluating SWT3 evidence as part of a conformity assessment:
| Step | Action | Verification Method |
|---|---|---|
| 1 | Request the provider's Compliance Passport or anchor export | JSON export, W3C Verifiable Credential, or HTML passport |
| 2 | Verify anchor chain integrity | Independent fingerprint recomputation (SHA-256) for a random sample. Use the public verifier at sovereign.tenova.io/verify or compute locally. |
| 3 | Review procedure coverage against required articles | Map provider's witnessed procedures to the article tables in Sections 4 and 5. Identify coverage gaps. |
| 4 | Assess clearing level appropriateness | Verify that the clearing level does not impair traceability requirements (Art. 12). Level 3 removes model identity, which may limit Art. 12(2) compliance. |
| 5 | Review supplementary evidence | For each article marked PARTIAL, collect the supplementary evidence listed in the blue boxes above. |
| 6 | Document findings with anchor references | Cite specific anchor tokens in conformity/non-conformity findings (see Section 8). |
The following table maps Annex IV technical documentation sections to SWT3 procedures that provide supporting evidence:
| Annex IV Section | Requirement | Supporting SWT3 Procedures | Coverage |
|---|---|---|---|
| 1 | General description of the AI system | AI-MDL.1, AI-MDL.2, AI-ID.1, AI-CHR.1 | Partial |
| 2 | Detailed description of elements and development process | AI-SBOM.1, AI-MDL.5, AI-MDL.6 | Partial |
| 3 | Monitoring, functioning, and control | AI-DRIFT.1, AI-DRIFT.2, AI-PERF.1 | Partial |
| 4 | Risk management system | AI-GRD.1, AI-VIO.1, AI-SAFE.1, AI-REACH.1 | Partial |
| 5 | Intended purpose, foreseeable misuse | AI-GOV.1, AI-CHR.1 | Partial |
| 6 | Human oversight measures | AI-HITL.1, AI-HITL.2, AI-HITL.3, AI-REV.1 | Partial |
| 7 | Accuracy, robustness, cybersecurity | AI-DRIFT.1, AI-ROBUST.1, AI-SEC.1, AI-CYBER.1 | Partial |
| 8 | Information about data | AI-DATA.1, AI-DATA.3, AI-FAIR.1 | Partial |
| 9 | Pre-defined changes | AI-MDL.2, AI-FREEZE.1 | Partial |
| 10 | Logging capabilities | AI-INF.1, AI-LOG.1, AI-AUDIT.1 | Full |
Note: Annex IV sections marked PARTIAL require narrative documentation in addition to SWT3 operational evidence. SWT3 anchors supplement Annex IV but do not replace the narrative documentation requirement.
The EU AI Act anticipates the development of harmonised European standards (hENs) to provide a presumption of conformity with the requirements in Chapter III. As of August 2026, the European Commission has issued standardisation requests to CEN and CENELEC (Standardisation Request M/593). Key standards in development include:
SWT3 evidence supports compliance with these standards by providing the operational evidence layer that management system documentation references. When harmonised standards are formally designated, SWT3 anchor chains can serve as the runtime evidence that demonstrates conformity with the technical requirements specified in the hEN.
Assessors should note that until hENs are formally designated in the Official Journal, compliance with ISO/IEC 42001 or other voluntary standards does not create a presumption of conformity with the EU AI Act. SWT3 evidence should be evaluated directly against the article requirements mapped in Sections 4 and 5.
When working with a provider's audit portal share link, the EU AI Act Conformity section displays per-article compliance status with enforcement countdown, coverage badges, and exclusion management. The portal maps live evidence directly to the article requirements in Sections 4 and 5 of this guide. See the Assessor Onboarding Kit for a full portal walkthrough.
| Tier | Maximum Penalty | Applies To |
|---|---|---|
| Art. 99(1) | 35,000,000 EUR or 7% of worldwide annual turnover | Prohibited AI practices (Art. 5) |
| Art. 99(2) | 15,000,000 EUR or 3% of worldwide annual turnover | Non-compliance with Art. 9-15 requirements (high-risk AI) |
| Art. 99(3) | 7,500,000 EUR or 1.5% of worldwide annual turnover | Incorrect, incomplete, or misleading information to authorities |
SWT3 evidence directly addresses Tier 2 (Art. 99(2)) obligations. Continuous witnessing provides a defense of due diligence: the provider can demonstrate that controls were operational and monitored throughout the system's lifecycle.