EU AI Act Art.17 QMS Audit Readiness: The Complete Conformity Assessment Checklist for High-Risk AI Developers (2026)

Post #1631 in the sota.io EU Cyber Compliance Series — EU AI Act Art.17 QMS Series, Part 5 of 5

The August 2026 deadline is 53 days away. If you've followed this five-part series you now have a functioning Art.17 Quality Management System — foundations, Annex IV documentation, testing and validation pipelines, and a change management framework for Art.45 substantial modifications. This finale answers the final question: how do you know your QMS will actually pass a conformity assessment?

Art.17 does not exist in isolation. It is the process backbone that feeds evidence into every other assessment touchpoint: Art.43 conformity assessment procedures, Art.44 notified body certificates, Art.47 EU declaration of conformity, and Art.49 registration. An auditor — whether an internal assessor or a designated notified body — will reconstruct your development process from your QMS outputs. If the trail breaks anywhere, the assessment fails.

This checklist maps every required artifact to the QMS process that produces it, so you can verify your audit readiness without waiting for an auditor to find the gap.

Why Audit Readiness Is a Separate Discipline From QMS Implementation

A QMS can be technically correct and still fail an assessment because of presentation gaps. Common failure modes include:

• Evidence fragmentation — artifacts exist but are distributed across five tools with no cross-reference index
• Version misalignment — Annex IV technical file references a risk assessment version that predates the model currently in production
• Untraceable approvals — sign-off records are in email threads rather than your QMS approval log
• Change management gaps — modifications applied between assessment cycles have no documented classification decision (Art.45 threshold analysis missing)
• Missing completeness declarations — the EU declaration of conformity (Art.47) references compliance with requirements not documented in the technical file

Each of these is an automatic deficiency finding. None requires substantive compliance work to fix — they are documentation and linkage issues. Audit readiness discipline catches them before assessment day.

The Art.17 QMS Artifact Map

Your QMS under Art.17 must produce six categories of evidence. The table below maps each category to the downstream assessment requirement it satisfies.

Every document in your QMS must carry a version identifier, approval signature, and date. An undated document cannot anchor an audit timeline.

Section 1: Conformity Assessment Procedure (Art.43)

Art.43 defines the pathway your high-risk AI system must follow before EU market placement. For most high-risk AI systems, the options are internal control (Art.43(2)) or full NB involvement (Art.43(3)). Your QMS documentation must make the selected pathway explicit.

1.1 Pathway Selection Document

Create a conformity-assessment-pathway.md in your QMS repository:

# Conformity Assessment Pathway — [System Name] v[Version]

## System Classification
- High-risk category: Annex III, Point [X]
- Annex I (safety component): [Yes/No — mandatory NB if yes]
- General-purpose AI model component: [Yes/No]

## Selected Pathway
- Pathway: Internal Control (Art.43(2)) / Notified Body (Art.43(3))
- Rationale: [Why this pathway applies]
- NB Name (if applicable): [NB name, EU NB ID]

## Harmonised Standards Applied
- [Standard number and title, e.g. EN ISO/IEC 42001:2023]

## Assessment Schedule
- Initial assessment: [Date]
- Next review trigger: Substantial modification (Art.45) OR annual review

Approved by: [Name, Role]
Date: [YYYY-MM-DD]

This document anchors the entire assessment. An auditor reading your QMS should find this within two directory levels of your QMS root.

1.2 Internal Control Checklist (Art.43(2))

If you are using internal control (the majority of high-risk AI providers not covered by Annex I product safety legislation):

□ Technical documentation (Annex IV) complete and version-matched to production system
□ Quality management system (Art.17) documented and implemented
□ Risk management system (Art.9) records complete
□ Testing and validation records demonstrate conformity with Art.10 data requirements
□ Human oversight mechanisms (Art.14) implemented and tested
□ Transparency measures (Art.13) implemented in production
□ Post-market monitoring plan (Art.72) established
□ EU declaration of conformity (Art.47) drafted, signed, dated
□ Registration in EU AI Act database (Art.49) prepared
□ GDPR Data Protection Impact Assessment current (where applicable)

Every box must link to the specific document or log entry that satisfies it. "Implemented" without a document reference fails an assessment.

Section 2: Technical Documentation (Annex IV)

Annex IV specifies eight sections that your technical documentation must contain. Each section must be present, current, and cross-referenced to your QMS processes.

2.1 Annex IV Completeness Audit

Run this check against your documentation repository before every assessment:

#!/bin/bash
# annex-iv-audit.sh — verify Annex IV completeness

TECH_FILE_DIR="./docs/technical-file"
REQUIRED_SECTIONS=(
    "1-system-description-purpose"
    "2-system-design-development-process"
    "3-system-monitoring-functioning"
    "4-testing-validation-results"
    "5-risk-management-system-outputs"
    "6-changes-across-lifecycle"
    "7-harmonised-standards-applied"
    "8-eu-declaration-conformity-reference"
)

PASS=0; FAIL=0

for section in "${REQUIRED_SECTIONS[@]}"; do
    if ls "${TECH_FILE_DIR}/${section}"* &>/dev/null; then
        echo "✅ ${section}"
        ((PASS++))
    else
        echo "❌ MISSING: ${section}"
        ((FAIL++))
    fi
done

echo ""
echo "Result: ${PASS} present, ${FAIL} missing"
[ $FAIL -eq 0 ] && echo "PASS — Annex IV complete" || exit 1

Integrate this script into your CI/CD pipeline as a gate on your main or release branch.

2.2 Version Alignment Check

The most common Annex IV deficiency is a technical file that describes a model version no longer in production. Before each assessment:

# verify-annex-iv-version.py

import subprocess, yaml, sys

# Read the version declared in the technical file
with open("docs/technical-file/1-system-description-purpose/system-description.yaml") as f:
    doc_version = yaml.safe_load(f)["system_version"]

# Read the version deployed in production
prod_version = subprocess.check_output(
    ["kubectl", "get", "deployment", "ai-system", "-o", 
     "jsonpath='{.spec.template.metadata.labels.version}'"],
    text=True
).strip().strip("'")

if doc_version != prod_version:
    print(f"❌ VERSION MISMATCH: docs={doc_version}, prod={prod_version}")
    sys.exit(1)
else:
    print(f"✅ Version aligned: {doc_version}")

If your deployment is not Kubernetes-native, adapt the production version read to match your deployment mechanism (Docker label, config file, environment variable).

Section 3: Notified Body Certificates (Art.44)

If your conformity assessment pathway includes notified body involvement (Art.43(3)), Art.44 governs the certificates the NB issues. Your QMS must manage the certificate lifecycle.

3.1 NB Certificate Lifecycle Log

# qms/certificates/nb-certificates.yaml

certificates:
  - certificate_id: "[NB ID]-[Year]-[Serial]"
    issuing_nb: "[NB Name]"
    nb_eu_id: "[NB0000]"
    system_name: "[AI System Name]"
    system_version: "[Version at certificate issue]"
    issue_date: "YYYY-MM-DD"
    expiry_date: "YYYY-MM-DD"          # Typically 5 years; confirm with NB
    scope: "[Description of what the certificate covers]"
    
    # Conditions attached to the certificate
    conditions:
      - "Annual surveillance audit required"
      - "Notify NB within 30 days of substantial modification (Art.45)"
    
    # Renewal tracking
    renewal_initiated: false
    renewal_target_date: "YYYY-MM-DD"  # 6 months before expiry recommended
    
    # Withdrawal risk triggers (Art.44(4))
    withdrawal_triggers_monitored:
      - "Substantial modification applied without NB notification"
      - "Serious incident not reported within Art.73 timelines"
      - "Post-market monitoring summary overdue"

Art.44(4) permits the NB to restrict, suspend, or withdraw a certificate if the AI system no longer meets requirements. The three withdrawal triggers above are the most common causes — your QMS must monitor all three in your PMM process.

3.2 NB Communication Log

Every formal communication with your notified body must be logged:

## NB Communication Log — [NB Name]

| Date | Type | Reference | Summary | Action Required |
|------|------|-----------|---------|-----------------|
| YYYY-MM-DD | Initial submission | REF-001 | Annex IV technical file submitted | Await NB review (target: 60 days) |
| YYYY-MM-DD | Clarification request | REF-002 | NB requested V&V methodology detail for scenario X | Provide within 14 days |
| YYYY-MM-DD | Certificate issued | CERT-001 | Certificate #[NB ID]-[Year]-[Serial] issued | Log in certificates.yaml; set renewal reminder |
| YYYY-MM-DD | Change notification | REF-003 | Art.45 analysis submitted — change classified non-substantial | Await NB acknowledgement |

Section 4: EU Declaration of Conformity (Art.47)

Art.47 requires providers to draw up an EU declaration of conformity before market placement. The declaration must be kept for 10 years after the AI system has been placed on the market.

4.1 Declaration Template

# EU Declaration of Conformity
## Regulation (EU) 2024/1689 — EU AI Act

**Provider:**  
Company Name: [Legal entity name]  
Address: [Registered address]  
EU Representative (if non-EU provider): [Name, address]

**High-Risk AI System:**  
System name: [Product/service name]  
Version: [Version identifier]  
Intended purpose: [As per Art.9 risk management scope]  
High-risk category: Annex III, Point [X]

**Declaration:**  
The undersigned declares that the above-described AI system conforms to the relevant provisions of Regulation (EU) 2024/1689 (EU AI Act), specifically:

- Art.9 — Risk management system implemented and maintained
- Art.10 — Data governance and management practices applied  
- Art.12 — Record-keeping and logging requirements met
- Art.13 — Transparency and provision of information to deployers implemented
- Art.14 — Human oversight measures designed and implemented
- Art.15 — Accuracy, robustness and cybersecurity requirements met
- Art.17 — Quality management system established and operational

**Notified Body (if applicable):**  
NB Name: [Name]  
NB EU ID: [NB0000]  
Certificate number: [Certificate ID]  
Date of issue: [YYYY-MM-DD]

**Harmonised standards applied:**  
- [EN ISO/IEC 42001:2023 — AI Management Systems]
- [EN ISO/IEC 27001:2022 — Information Security (if applicable)]

**Technical documentation location:**  
[Internal reference or controlled document system path — not a public URL]

Signed by: [Name, Role — must be authorised signatory]  
Place: [City, Country]  
Date: [YYYY-MM-DD]

The declaration must be updated whenever a substantial modification (Art.45) results in a new conformity assessment. Your change management log (Part 4 of this series) provides the trigger: any change classified as "substantial" requires a new declaration before the modified system is placed on the market.

4.2 Declaration Retention Check

# verify-declaration-retention.py
# Run annually as part of QMS internal audit

import os, yaml
from datetime import datetime, timedelta

with open("qms/declarations/declaration-log.yaml") as f:
    declarations = yaml.safe_load(f)["declarations"]

today = datetime.now().date()
RETENTION_YEARS = 10

for decl in declarations:
    market_placement_date = datetime.strptime(decl["market_placement_date"], "%Y-%m-%d").date()
    retention_deadline = market_placement_date + timedelta(days=RETENTION_YEARS * 365)
    
    if "withdrawn_date" in decl:
        withdrawn = datetime.strptime(decl["withdrawn_date"], "%Y-%m-%d").date()
        retention_deadline = withdrawn + timedelta(days=RETENTION_YEARS * 365)
    
    status = "ACTIVE" if today < retention_deadline else "RETENTION EXPIRED — ARCHIVE REVIEW REQUIRED"
    print(f"{decl['version']}: {status} (retain until {retention_deadline})")

Section 5: Registration (Art.49)

Art.49 requires providers to register their high-risk AI systems in the EU AI Act database before market placement (for Annex III systems where no exception applies). The registration generates an EU-wide identifier that must appear in your technical documentation.

5.1 Registration Readiness Checklist

□ EU AI Act database account created (eudamed equivalent for AI — database not yet live, 
  but registration obligation active August 2026)
□ Registration package prepared:
    □ Provider name and address
    □ System name, version, intended purpose
    □ High-risk category (Annex III point)
    □ EU declaration of conformity reference
    □ NB certificate reference (if applicable)
    □ Instructions for use (deployer-facing documentation)
    □ Contact for market surveillance authority queries
□ Registration reference number logged in:
    □ Annex IV technical documentation (Section 8)
    □ EU declaration of conformity
    □ QMS certificate log
□ Post-registration: annual update process documented in QMS

The registration information must be kept current. If you make a substantial modification that triggers a new conformity assessment, the registration must be updated before the modified system is placed on the market.

Section 6: The Pre-Assessment QMS Freeze Protocol

The week before a conformity assessment — whether internal or notified body — run a QMS freeze protocol. Changes to assessed artifacts during an active assessment create version control problems that can invalidate the assessment.

6.1 Freeze Checklist

#!/bin/bash
# pre-assessment-freeze.sh

ASSESSMENT_DATE=$1  # Usage: ./pre-assessment-freeze.sh YYYY-MM-DD

echo "=== PRE-ASSESSMENT FREEZE PROTOCOL ==="
echo "Assessment date: ${ASSESSMENT_DATE}"
echo ""

# Tag the repository state
git tag "assessment-freeze-${ASSESSMENT_DATE}" HEAD
echo "✅ Git tag created: assessment-freeze-${ASSESSMENT_DATE}"

# Create freeze notice
cat > QMS_FREEZE_NOTICE.md << EOF
# QMS FREEZE NOTICE

**Freeze activated:** $(date -u +"%Y-%m-%dT%H:%M:%SZ")
**Assessment date:** ${ASSESSMENT_DATE}
**Freeze scope:** All Annex IV technical documentation, QMS records, risk management outputs

## Changes permitted during freeze:
- Read-only access to all QMS documents
- Clarification annotations (clearly marked DRAFT, not part of assessed record)
- Security patches to production system (log in PMM, not in Annex IV)

## Changes NOT permitted during freeze:
- Any modification to Annex IV sections 1-8
- New risk management records
- V&V result additions
- Change management log entries for the assessed version

## Freeze release:
Assessment complete + deficiency findings closed + new assessment cycle initiated.
EOF

echo "✅ Freeze notice created"

# Lock protection for key directories
git config core.hooksPath .git/hooks
cat > .git/hooks/pre-commit << 'HOOK'
#!/bin/bash
if [ -f QMS_FREEZE_NOTICE.md ]; then
    CHANGED=$(git diff --cached --name-only | grep -E "^docs/technical-file/|^qms/")
    if [ -n "$CHANGED" ]; then
        echo "❌ BLOCKED: QMS freeze active. Cannot modify assessment documents."
        echo "Changed files: ${CHANGED}"
        exit 1
    fi
fi
HOOK
chmod +x .git/hooks/pre-commit
echo "✅ Pre-commit hook installed (blocks QMS doc changes during freeze)"

6.2 Deficiency Response Workflow

When an assessment produces a deficiency finding, your QMS must have a documented response process:

# qms/assessments/deficiency-log.yaml

assessment_id: "ASSESS-2026-001"
deficiency_findings:
  - finding_id: "DEF-001"
    category: "Minor"  # Minor / Major / Critical
    description: "Section 3 of Annex IV (system monitoring) does not reference PMM threshold values"
    root_cause: "PMM thresholds documented in separate runbook, not cross-referenced in technical file"
    
    corrective_action:
      description: "Add cross-reference to PMM threshold configuration in Section 3"
      owner: "[Name, Role]"
      target_date: "YYYY-MM-DD"  # Must be before assessment closure
      completed_date: null
      evidence: null  # Commit hash or document reference when resolved
    
    preventive_action:
      description: "Add PMM cross-reference check to pre-assessment freeze checklist"
      owner: "[Name, Role]"
      target_date: "YYYY-MM-DD"
      completed_date: null

assessment_status: "Deficiencies open"
reassessment_required: false  # True for Major/Critical findings
closure_target: "YYYY-MM-DD"

Section 7: Ongoing QMS Audit Schedule

Art.17 requires your QMS to include an internal audit programme. Conformity is not a one-time event — it is a continuous state that must be demonstrated at each assessment cycle.

7.1 Annual QMS Audit Calendar Template

## QMS Internal Audit Calendar — [Year]

### Q1 (January–March)
- [ ] Annex IV technical file completeness audit (annex-iv-audit.sh)
- [ ] Risk management record currency check (all Art.9 records dated within 12 months or assessed as still current)
- [ ] V&V results coverage review — all Annex III scenarios covered?
- [ ] Change management log review — any unresolved Art.45 threshold analyses?

### Q2 (April–June)  
- [ ] Post-market monitoring summary compilation (Art.72 annual report if required)
- [ ] NB certificate expiry check — renewal required within 12 months?
- [ ] EU declaration of conformity currency check — matches production version?
- [ ] Registration data accuracy check (Art.49 update if required)

### Q3 (July–September)
- [ ] Serious incident log review — all Art.73 notifications sent within required timelines?
- [ ] Training records audit — QMS-relevant staff trained and certified current?
- [ ] Supplier/third-party component assessment — any upstream changes affecting conformity?
- [ ] Security and robustness review (Art.15) — penetration test results current?

### Q4 (October–December)
- [ ] Full management review (QMS effectiveness, resource adequacy)
- [ ] Next year audit schedule published
- [ ] Pre-assessment freeze protocol test (dry run)
- [ ] August 2026 deadline compliance confirmation (for 2026 — transition to ongoing)

7.2 Management Review Record Template

## QMS Management Review — [Quarter/Year]

**Attendees:** [QMS Owner, Legal, Engineering Lead, Product Lead]
**Date:** [YYYY-MM-DD]

### Agenda

1. **Internal audit results** — [Summary of findings, status of corrective actions]
2. **Customer/deployer feedback** — [Complaints, queries, transparency requests]
3. **Serious incidents** — [Art.73 notifications sent, outcomes, systemic risks identified]
4. **Post-market monitoring** — [Drift indicators, performance trends, threshold breaches]
5. **Changes since last review** — [Modifications, Art.45 classifications, declaration updates]
6. **Regulatory environment** — [New guidance from AI Office, NCA communications]
7. **Resource adequacy** — [QMS staffing, tooling, budget]

### Decisions and Actions

| Decision | Owner | Target Date |
|----------|-------|-------------|
| [e.g. Extend PMM alert threshold review to monthly] | [Name] | [Date] |

**Approved by:** [Name, Role]  
**Next review:** [Date — maximum 12 months]

The ART17-QMS-2026 Series: What You've Built

This five-part series has taken you from QMS foundations through every major implementation domain:

A developer who has worked through all five parts has a QMS that can survive a notified body audit. The documentation is structured, version-controlled, linked across requirements, and equipped with scripts that automate compliance evidence generation.

The Infrastructure Foundation Underneath

One constraint runs through every QMS requirement: your compliance documentation infrastructure must be under your jurisdiction.

Art.44 NB certificates, Art.47 declarations, Annex IV technical files — these documents contain evidence of your conformity with EU law. If that evidence lives in a SaaS platform operated by a US parent company, it is reachable under the CLOUD Act regardless of where the data center is located. A US federal subpoena to the US parent can reach EU-server data without EU judicial process.

The practical solution is not to move every system to EU infrastructure, but to be explicit about what requires EU-jurisdictional hosting:

• QMS document repository — EU-hosted, Git-native (Gitea on Hetzner, or similar)
• V&V test records — EU-hosted, append-only log
• PMM metrics and incident logs — EU-hosted time-series database
• NB certificate storage — EU-hosted, access-logged

Your production AI model training infrastructure, inference serving, and application code can make independent hosting decisions. But the compliance evidence chain — the documents an NB or national market surveillance authority will subpoena to verify your Art.43 conformity — should live on infrastructure you control in EU jurisdiction.

sota.io (Hetzner Germany, no US parent, no CLOUD Act exposure) is purpose-built for this compliance stack. Your QMS repository, PMM database, and audit logs can run as containerised services on EU-sovereign infrastructure from €9/month.

Final Pre-August-2026 Checklist

53 days remain before the EU AI Act August 2026 deadline for high-risk AI providers.

ART17-QMS SERIES COMPLETION CHECKLIST

FOUNDATIONS (Part 1):
□ Quality policy drafted, approved, published
□ QMS process architecture documented (scope, exclusions, interfaces)
□ Roles and responsibilities defined (QMS Owner, Process Owners)
□ QMS repository initialised (version control, access control)

DOCUMENTATION (Part 2):
□ Annex IV technical file: all 8 sections present and version-aligned to production
□ Document naming convention and version scheme applied consistently
□ Cross-references between technical file sections complete

TESTING & VALIDATION (Part 3):
□ V&V plan covering all Annex III scenario requirements
□ Test record format standardised (test ID, scenario, result, sign-off)
□ V&V pipeline integrated into CI/CD (gate on release branch)
□ Failure and exception records retained

CHANGE MANAGEMENT (Part 4):
□ Three-tier change classification framework documented
□ Art.45 substantial modification threshold analysis template in use
□ Change management log current (no unresolved entries older than 30 days)
□ Re-assessment trigger logic tested against last 5 production changes

AUDIT READINESS (Part 5 — This post):
□ Conformity assessment pathway document complete (Art.43)
□ Internal control checklist fully evidenced OR NB selected and engaged
□ Annex IV completeness audit script passing in CI/CD
□ EU declaration of conformity drafted, reviewed, ready for signing
□ Art.49 registration package prepared
□ NB certificate log current (if NB pathway)
□ Pre-assessment freeze protocol documented and tested
□ Annual QMS audit calendar scheduled for [Year]
□ Management review process scheduled (first review before August 2026)

INFRASTRUCTURE:
□ QMS repository on EU-jurisdictional infrastructure
□ PMM metrics database on EU-jurisdictional infrastructure
□ Incident log on EU-jurisdictional infrastructure (Art.73 evidence chain)
□ Access logs for compliance document repository retained

The August 2026 deadline is not the end of QMS work — it is the beginning of the continuous compliance cycle. The organisations that treat QMS as a living operational process, rather than a documentation sprint before a deadline, are the ones whose Art.43 assessments close without major deficiency findings.

This is Part 5 of 5 in the EU AI Act Art.17 QMS series. Earlier parts: Art.17 QMS Foundations · Annex IV Documentation · Testing & Validation Pipeline · Change Management & Art.45. sota.io publishes EU compliance implementation guides weekly — browse the full series.

See Also

• EU AI Act Art.43 Conformity Assessment + CLOUD Act: What Notified Body Auditors Will Find (2026) — Art.43 pathway selection and what auditors actually examine in your technical file and QMS evidence chain
• EU AI Act Conformity Chain: From Art.43 Assessment to Art.47 DoC to Art.48 CE Marking — step-by-step workflow from completed conformity assessment through declaration drafting to CE marking
• EU AI Act Notified Bodies: Art.44 Certificates and What NB Auditors Check — Art.44 certificate lifecycle, NB designation requirements, and the review criteria auditors apply
• EU AI Act Notified Bodies: Managing Substantial Modifications (Art.45) and NB Reporting Obligations — how Art.45 threshold classifications trigger NB notification and what the reporting window requires
• EU AI Act Notified Bodies: Complete NB-Audit Readiness Checklist for High-Risk AI Developers — companion checklist covering NB operations, audit preparation, and developer obligations across the notified body engagement lifecycle