Draft harmonized AI standards mapped to SWT3 witness procedures. Implementation guidance while JTC 21 standards finalize.
Who this is for: EU AI Act providers deploying GPAI and high-risk AI systems, notified body assessors preparing conformity assessment procedures, EU AI Office supervisory staff, and enterprise compliance teams collecting Article 50 evidence before harmonized standards are published.
Standards in development. CEN-CENELEC JTC 21 is drafting harmonized European standards for the EU AI Act under Commission Standardization Request M/593. The first draft, prEN 18286 (AI Quality Management System), is in public enquiry. No harmonized standards have been published in the Official Journal of the EU (OJEU) yet. Article 50 transparency obligations and GPAI enforcement powers take effect August 2, 2026 regardless of standards status. This mapping tracks draft requirements and known working group mandates. It will be updated as standards are published. SWT3 does not provide presumption of conformity. It provides technical evidence that may support conformity assessment against future harmonized standards.
CEN-CENELEC JTC 21 "Artificial Intelligence" is the joint technical committee mandated by the European Commission to develop harmonized European standards (hEN) supporting the EU AI Act. When these standards are published in the OJEU, providers who conform to them gain a presumption of conformity with the corresponding AI Act requirements (Article 40).
JTC 21 organizes its work across five working groups, each addressing a distinct area of the Commission's Standardization Request M/593:
| Working Group | Focus Area | Commission Mandate |
|---|---|---|
| WG 1 | Foundational Standards | Terminology, concepts, AI system classification, general framework |
| WG 2 | Risk Management | Risk assessment methodology, risk treatment, residual risk documentation |
| WG 3 | Engineering and Lifecycle | System design, development, testing, deployment, monitoring, retirement |
| WG 4 | Governance and QMS | Quality management system, organizational processes, record-keeping |
| WG 5 | Data Quality | Training data governance, dataset documentation, bias assessment, data lifecycle |
The Commission's standardization request covers six essential requirement areas from the AI Act: risk management (Art. 9), data governance (Art. 10), technical documentation (Art. 11), record-keeping (Art. 12), transparency (Art. 13), and human oversight (Art. 14). JTC 21's standards will provide the technical specifications for meeting these articles.
EU AI Act enforcement operates on a fixed timeline set by Regulation (EU) 2024/1689. Regardless of whether harmonized standards are finalized:
Because harmonized standards remain in draft form while enforcement powers activate, providers face a compliance gap: they must demonstrate conformity but lack a finalized technical specification to conform against.
The practical implication: Providers cannot wait for published standards. Evidence collection must begin now using the best available technical frameworks. When harmonized standards are published, evidence already collected against SWT3 procedures maps forward to the standard requirements. The evidence does not become invalid; the mapping simply becomes more precise.
This guide provides that forward-compatible mapping. Each SWT3 procedure is aligned to the known requirement areas from the Commission's standardization request and available draft texts.
Each JTC 21 working group's mandate maps to SWT3 procedure namespaces. Coverage reflects alignment with the Commission's standardization request requirements and available draft content.
| WG | Focus | Key Draft Standards | SWT3 Procedures | Coverage |
|---|---|---|---|---|
| WG 1 | Foundational | Terminology, classification | AI-BASE.1 AI-LIC.1 |
Indirect |
| WG 2 | Risk Management | Risk assessment, treatment | AI-RISK.1 AI-IMPACT.1 AI-SAFE.1 AI-DPIA.1 |
Full |
| WG 3 | Engineering / Lifecycle | Design, testing, monitoring | AI-MDL.1-.7 AI-INF.1 AI-PERF.1 AI-DRIFT.1-.2 AI-LCM.1 |
Full |
| WG 4 | Governance / QMS | prEN 18286 (public enquiry) | AI-GOV.1-.7 AI-AUDIT.1-.2 AI-LOG.1 AI-HITL.1 |
Full |
| WG 5 | Data Quality | Dataset governance, bias | AI-DATA.1 AI-RAG.1-.2 AI-FAIR.1 |
Full |
Coverage levels: Full = SWT3 procedures directly generate evidence for this requirement area. Partial = procedures cover a subset of requirements. Indirect = procedures provide supporting evidence but do not address the requirement directly.
prEN 18286 is the most mature JTC 21 draft, currently in public enquiry. It establishes that providers must implement product-focused lifecycle governance with automated logging mechanisms. The following maps its known requirement areas to SWT3 procedures:
| Requirement Area | prEN 18286 Mandate | SWT3 Procedure(s) | Coverage |
|---|---|---|---|
| Quality policy | Establish and communicate AI quality management policy | AI-GOV.1 Policy attestation | Full |
| Organizational roles | Define AI governance roles, responsibilities, authorities | AI-HITL.1 Human oversightAI-GOV.3 Committee structure | Full |
| Risk-based planning | Plan QMS activities based on AI-specific risk assessment | AI-RISK.1 Risk identificationAI-IMPACT.1 Impact assessment | Full |
| Resource management | Ensure competence, awareness, infrastructure for AI operations | AI-HW.1 Hardware attestationAI-COST.1 Resource witnessing | Partial |
| Automated logging | Implement automated, tamper-evident logging of AI system operations | AI-LOG.1 Logging pipelineAI-AUDIT.1 Audit integrity | Full |
| Record-keeping | Maintain documented information with integrity controls | AI-AUDIT.1 Audit log integrityAI-AUDIT.2 External timestamp | Full |
| Lifecycle governance | Govern AI system development, deployment, monitoring, retirement | AI-LCM.1 Lifecycle managementAI-MDL.1 Model integrityAI-REV.1 Revocation | Full |
| Performance monitoring | Continuously monitor AI system accuracy, robustness, drift | AI-DRIFT.1 Drift detectionAI-PERF.1 Performance monitoring | Full |
| Nonconformity management | Detect, record, and correct AI system nonconformities | AI-INCIDENT.1 Incident detectionAI-IR.1 Incident response | Full |
| Supplier management | Govern third-party AI components and services | AI-CHAIN.1 Supply chainAI-SUPPLY.1 Supplier attestation | Full |
| Requirement Area | Mandate | SWT3 Procedure(s) | Coverage |
|---|---|---|---|
| Risk identification | Systematic identification of AI-specific risks | AI-RISK.1 | Full |
| Impact assessment | Evaluate societal, individual, and environmental impact | AI-IMPACT.1 AI-DPIA.1 | Full |
| Safety verification | Verify safe state under failure conditions | AI-SAFE.1 | Full |
| Residual risk documentation | Document risks remaining after treatment | AI-RISK.1 Factor B/C | Partial |
| Requirement Area | Mandate | SWT3 Procedure(s) | Coverage |
|---|---|---|---|
| Model integrity | Verify model weights, architecture, version provenance | AI-MDL.1 AI-MDL.5 | Full |
| Version control | Track model versions through development lifecycle | AI-MDL.2 | Full |
| Testing and validation | Test AI systems against requirements before deployment | AI-ASSESS.1 AI-ROBUST.1 | Full |
| Deployment governance | Control deployment decisions with authorization gates | AI-GOV.5 Deployment approval | Full |
| Post-deployment monitoring | Monitor production performance, detect drift | AI-DRIFT.1 AI-DRIFT.2 | Full |
| Quantization and adaptation | Document model compression and fine-tuning changes | AI-MDL.6 AI-MDL.7 | Full |
| Requirement Area | Mandate | SWT3 Procedure(s) | Coverage |
|---|---|---|---|
| Data provenance | Document source, lineage, and transformation of training data | AI-DATA.1 | Full |
| Retrieval provenance | Track retrieved context in RAG architectures | AI-RAG.1 AI-RAG.2 | Full |
| Bias assessment | Measure and document bias across protected attributes | AI-FAIR.1 | Full |
| Data governance framework | Establish policies for data collection, storage, retention | AI-GOV.1 AI-DATA.1 | Partial |
These obligations take effect August 2, 2026 regardless of harmonized standard status. Evidence collection should begin immediately.
| Obligation | Requirement | SWT3 Evidence | Coverage |
|---|---|---|---|
| Art. 50(1) | AI-generated content must be marked in a machine-readable format | AI-GRD.1 Guardrail attestation (SHA-256 execution proof)AI-MARK.1 Content markingAI-WATERMARK.1 Watermark attestation |
Full |
| Art. 50(2) | Deepfake content must be disclosed as artificially generated | AI-TRANS.1 Transparency disclosure |
Partial |
| Art. 50(4) | AI-generated text on matters of public interest must be labelled | AI-TOOL.1 Tool execution witnessing (stateless proof)AI-GRD.1 Output attestation |
Full |
| Obligation | Requirement | SWT3 Evidence | Coverage |
|---|---|---|---|
| Audit logging | Maintain privacy-preserving audit logs of training and inference for 10 years | AI-LOG.1 at Clearing Level 2 (local hashing, no raw PII stored) |
Full |
| Training data transparency | Document training data sources, methods, and curation processes | AI-DATA.1 Data provenanceAI-RAG.1 Retrieval provenance |
Full |
| Model capability reporting | Document model capabilities, limitations, and known risks | AI-MDL.1 Model integrityAI-RISK.1 Risk identification |
Partial |
| Incident reporting | Report serious incidents to the AI Office | AI-INCIDENT.1 DetectionAI-IR.1 Response chain |
Partial |
Clearing Level 2 is the recommended minimum for GPAI providers. It performs local SHA-256 hashing of prompts, responses, and tool executions without transmitting raw content. This satisfies the 10-year retention requirement while preserving trade secrets and user privacy. The hash chain is independently verifiable without access to the original data.
prEN 18286 requires: AI systems must implement automated, tamper-evident logging of operations including inference requests, model decisions, and system state changes. Logs must support post-incident investigation and regulatory audit.
How SWT3 addresses it: Each witness() call in the SDK generates a deterministic SHA-256 fingerprint of the inference event (model ID, factors, timestamp) and mints an immutable SWT3 Witness Anchor. Anchors are append-only and cryptographically chained. At Clearing Level 2, raw content is hashed locally before transmission, preserving trade secrets while maintaining audit integrity. The Merkle rollup produces daily tamper-evident roots per tenant.
AI-LOG.1 anchors in the compliance ledger. Factor A identifies the model. Factor B records the operation type. Factor C records the clearing level applied. The daily Merkle root proves no anchors were retroactively inserted or modified. For GPAI 10-year retention, demonstrate that Clearing Level 2 hashes content locally before any network transmission.
prEN 18286 requires: Organizations must establish, communicate, and periodically review an AI quality management policy covering acceptable use, risk tolerance, and governance structure.
How SWT3 addresses it: AI-GOV.1 witnesses the existence, version, and review status of the organization's AI governance policy. Factor A records the policy version hash. Factor B records compliance status (compliant/non-compliant). Factor C records the last review date. Regular attestation at the management review cycle creates a timestamped chain proving continuous governance.
AI-GOV.1 anchor chain over time. The gap between attestation timestamps should match the organization's stated review cycle. Factor A changes indicate policy updates. A break in the chain indicates a lapsed review period, which the assessor should flag as a nonconformity against the QMS standard.
WG 2 requires: Providers must conduct systematic risk assessment covering technical risks (accuracy, robustness, bias), societal risks (discrimination, manipulation), and operational risks (dependency, failure modes).
How SWT3 addresses it: AI-RISK.1 witnesses each risk identification event. Factor A records the risk category. Factor B records the assessed severity. Factor C records the treatment decision (mitigated, accepted, transferred). Combined with AI-IMPACT.1 (societal impact assessment), the anchor chain provides a complete risk register backed by cryptographic evidence.
AI-RISK.1 anchors spanning all risk categories for each AI system in scope. Factor B severity should align with the organization's risk matrix. Missing risk categories indicate incomplete assessment. Pair with AI-IMPACT.1 anchors to demonstrate that societal impact was evaluated alongside technical risk.
WG 3 requires: Providers must verify and document model integrity throughout the lifecycle, including weight provenance, architecture specification, and version lineage.
How SWT3 addresses it: AI-MDL.1 witnesses the model's identity and integrity state. Factor A records the model identifier. Factor B records the weight file SHA-256 hash. Factor C records the framework and version. Combined with AI-MDL.5 (weight attestation) and AI-MDL.2 (version tracking), the chain proves model provenance from training through deployment.
AI-MDL.1 anchors for each deployed model. Factor B (weight hash) should remain stable between deployments unless a model update occurred. If the hash changes, a corresponding AI-MDL.2 anchor should document the version transition. Missing MDL.1 anchors for a production model indicate unwitnessed deployment.
WG 5 requires: Providers must document training data sources, collection methods, curation processes, and known limitations. Data governance must cover the full data lifecycle from acquisition through retirement.
How SWT3 addresses it: AI-DATA.1 witnesses data provenance at ingestion time. Factor A records the data source identifier. Factor B records the record count or dataset size. Factor C records the collection method. For RAG architectures, AI-RAG.1 extends provenance witnessing to retrieval-time context, recording which documents were retrieved and their relevance scores.
AI-DATA.1 anchors for each training dataset. Factor A should match the data source inventory. Factor B provides a quantitative record. For RAG systems, AI-RAG.1 anchors prove which context was used for each inference, supporting both data governance and transparency requirements.
Article 50 requires: Providers must ensure AI-generated content is marked in a machine-readable format detectable by other AI systems and automated tools.
How SWT3 addresses it: AI-GRD.1 generates a stateless SHA-256 cryptographic proof of each AI output execution. The proof includes the model identifier, guardrail status, and output attestation. This machine-readable anchor serves as the Article 50 marking: any system can query the verification endpoint with the anchor fingerprint to confirm the content was AI-generated and which guardrails were active.
AI-GRD.1 anchors for content-generating AI systems. Demonstrate verification at /verify/ using an anchor fingerprint. Factor A identifies the model. Factor B records the guardrail configuration. The anchor itself is the machine-readable mark, verifiable instantly at sovereign.tenova.io/verify without access to the originating system.
prEN 18286 requires: Maintain documented information with integrity controls. Records must be protected against unauthorized modification and available for regulatory inspection.
How SWT3 addresses it: Every SWT3 Witness Anchor is immutable once minted. AI-AUDIT.1 specifically witnesses the integrity of the audit log itself. Factor A records the log source. Factor B records the entry count. Factor C records the retention period. Combined with AI-AUDIT.2 (external RFC 3161 timestamps), the chain provides independent temporal proof that records existed at a claimed time.
AI-AUDIT.1 anchors at regular intervals proving log integrity was verified. AI-AUDIT.2 anchors provide external timestamp proof independent of the organization's systems. Gaps in the audit chain indicate periods where integrity was not verified. The daily Merkle rollup provides an additional layer of tamper evidence.
WG 3 requires: Continuously monitor deployed AI systems for accuracy degradation, distributional shift, and performance drift. Trigger revalidation or rollback when thresholds are breached.
How SWT3 addresses it: AI-DRIFT.1 witnesses drift measurements at configured intervals. Factor A records the metric being tracked. Factor B records the current value. Factor C records the baseline threshold. When drift exceeds the threshold, the anchor verdict changes from PASS to FAIL, creating an auditable record of when the system went out of specification. AI-DRIFT.2 extends this with consequence-mapped thresholds (warn/degrade/halt).
AI-DRIFT.1 anchor series over time for each production model. Plot Factor B (current) against Factor C (baseline) to show trend. FAIL verdicts indicate threshold breaches. Demonstrate that each FAIL was followed by either a corrective action (AI-IR.1 anchor) or a revalidation (AI-ASSESS.1 anchor). Missing monitoring intervals are themselves a nonconformity.
| Assessor Question | Where to Look |
|---|---|
| Has the organization established an AI quality management policy? | AI-GOV.1 anchors. Factor A shows policy version. Factor B shows compliance status. Attestation frequency should match the management review cycle. |
| Are AI system operations logged automatically? | AI-LOG.1 anchors. Factor C shows clearing level. Clearing Level 2+ satisfies GPAI 10-year retention without exposing raw PII. Verify daily Merkle roots exist. |
| Has a risk assessment been conducted for each AI system? | AI-RISK.1 + AI-IMPACT.1 anchors per system. Factor A identifies risk category. Factor B shows severity. All three risk domains (technical, societal, operational) should have anchors. |
| Is AI-generated content marked in a machine-readable format? | AI-GRD.1 anchors for content-generating systems. Verify at sovereign.tenova.io/verify. The anchor fingerprint is the machine-readable mark per Article 50. |
| Are model versions tracked through the lifecycle? | AI-MDL.1 (integrity) + AI-MDL.2 (version) anchor chains. Hash changes without version documentation indicate uncontrolled model updates. |
| Is post-deployment drift being monitored? | AI-DRIFT.1 anchor series at regular intervals. Gaps indicate monitoring lapses. FAIL verdicts should have corresponding AI-IR.1 corrective action anchors. |
| Are training data sources documented? | AI-DATA.1 anchors per dataset. Factor A identifies the source. Factor B provides quantitative metadata. For RAG, AI-RAG.1 anchors extend provenance to retrieval time. |
| Does the organization have an incident response process? | AI-INCIDENT.1 (detection) paired with AI-IR.1 (response) anchors. Timestamp delta shows time-to-resolution. Factor C in AI-IR.1 confirms corrective action was taken. |
| Are third-party AI components governed? | AI-CHAIN.1 + AI-SUPPLY.1 anchors. Factor A identifies the supplier. Factor B shows attestation status. Trust Mesh verification via AI-TRUST.1 proves mutual verification. |
Full SDK documentation: sovereign.tenova.io/docs
Create a free account: sovereign.tenova.io/signup