If you operate AI that can affect people’s safety the law treats governance as a continuous lifecycle discipline, not a one‑time compliance checkbox. In this post we will break down what the Act expects, what “good” looks like in practice, how audits fit in, and how long you need to hang on to your records.

We’ll reference articles in the EU AI Act so you can also jump to the legal text. Where the Act delegates details to future implementing acts or harmonized standards, we’ll flag the open items.

Quick primer: what is a high risk AI system?

High risk systems fall into two main buckets:

• Products that already undergo EU product safety regimes (think medical devices, machinery, toys with safety functions, lifts, rail systems etc). When AI functionality is safety relevant within a product covered by existing EU legislation with third‑party conformity (Annex II, Section A), the AI component becomes high risk once that product safety law links to the AI Act.

• Standalone AI use cases listed in Annex III (e.g., biometric identification, critical infrastructure operation, education/assessment that impacts access, employment decisions including CV filtering and promotion, credit scoring, law enforcement analytics, migration/asylum triage, etc). The list is updateable by the Commission.

If your system lands in either bucket, the governance obligations below apply to you (with some role‑based differences for providers vs deployers).

Core governance pillars you must build

Below is a field‑ready translation of the legal text into workstreams you can actually execute. We’ve mapped primary article references in parentheses.

1. Risk management system (Art. 9)

Continuous, documented, and iterative. Cover design, development, validation, deployment, and post‑market phases. Identify known and reasonably foreseeable risks to health, safety, and fundamental rights. Rate severity + probability. Define mitigations. Loop in real‑world data and incident learnings. Update when context, data, or model behavior shifts.

Practice tips

• Build a living risk register keyed to harms scenarios, impacted rights, affected populations, controls in place, residual risk, and sign‑off owner.

• Use pre‑deployment hazard analysis (FMEA‑style), red teaming, adversarial testing, bias & robustness testing, and domain‑specific stress tests.

• Re‑run risk analysis whenever you materially change model weights, training data classes, operating environment, or intended purpose.

2. Data & data governance controls (Art. 10)

Training, validation, and testing data must be relevant, representative, free of errors where feasible, and complete for the intended purpose. You must understand data provenance, collection conditions and known biases.

Practice tips

• Maintain a data sheet / model card bundle that records sources, consent/legality conditions, geographic spans, demographic gaps, preprocessing steps, and quality metrics. You can use VerifyWise for this purpose.

• Track data lineage so you can answer regulator and customer questions fast.

3. Technical documentation (Art. 11)

You need to prepare and maintain documentation sufficient for regulators and notified bodies to assess compliance. Think of this as the “design history file” for AI.

What to include

• System description, intended purpose, user groups, and operating environment. Again VerifyWise is a great option here.

• Model architecture, training approach, version history.

• Data governance summary (see above).

• Performance metrics (accuracy, error rates, bias metrics, robustness testing outcomes). VerifyWise has a bias/fairness check feature for MLs and LLMs.

• Risk management records and mitigation decisions.

• Human oversight design and instructions.

• Post‑market monitoring plan.

Make sure you version control everything and also freeze a baseline package for each conformity assessment, then log deltas.

4. Recordkeeping / automatic logging (Art. 12 + logging references across the Act)

High risk systems must be able to log events automatically. The goal is traceability: what input came in, what model version processed it, what output went out, plus key system events and performance signals.

Practice tips

• Centralized, tamper‑evident log store with retention aligned to legal minimums (see retention section below).

• Tag logs with model version IDs and data slice IDs.

• Capture override events when humans intervene.

5. Transparency & instructions for use (Art. 13)

Users must get clear instructions, including system capabilities, limitations, data requirements, human oversight actions, performance characteristics, and known risk conditions. If minimum data quality is needed, say so. If performance degrades outside spec, warn them.

6. Human oversight (Art. 14)

Design your system so appropriately trained people can understand when intervention is needed and can really intervene. Oversight can mean real‑time review, confidence thresholds that route to humans, ability to stop automated operation, or workflows for appeal / second look.

Practice tips

• Define oversight roles: operator, reviewer, escalation authority.

• Provide dashboards with confidence bands, drift alerts, and anomaly flags.

• Train staff. Document training completion. Refresh training when system changes.

7. Accuracy, robustness, and cybersecurity (Art. 15)

You must meet state‑of‑the‑art thresholds appropriate to the use case, resist reasonably foreseeable misuse, and protect against data/model integrity attacks. Monitor for model drift, data poisoning, prompt injection (for interactive models), and adversarial examples where relevant.

8. Quality management system (QMS) (Art. 17)

Think ISO‑style. The QMS wraps your policies, procedures, roles, controls, internal audits, supplier management, corrective actions, and documentation practices across the entire AI lifecycle. 

Elements to cover:

• Organizational structure and responsibilities.

• Standard operating procedures for model development.

• Supplier / third‑party component controls (models, datasets, tools etc).

• Documentation control and versioning.

• Corrective and preventive actions.

• Internal audit and management review.

9. EU declaration of conformity & CE marking (Arts. 48‑51; Annex V sample)

Before you place a high risk AI system on the EU market or put it into service, you declare that it conforms to the Act. You keep the declaration and the supporting technical file available for EU authorities for the entire retention period.

Conformity assessment: when audits hit

You can’t deploy a high risk AI system in the EU without passing a conformity assessment pathway laid out in Articles 43‑47 (and mapped to Annexes). The path depends on whether standards cover your system and whether you fall under existing product safety regimes.

Assessment pathways

• Internal control (provider does the self‑assessment) when you fully apply relevant harmonized standards and there are no red flags requiring a notified body.

• Third‑party assessment by a notified body when harmonized standards aren’t (yet) available, when you deviate from them or when required under linked product safety law.

• QA system + technical documentation review hybrids for some product‑law‑linked categories.

When do you need a new/fresh assessment?

• First placement on the market or first putting into service in the EU.

• Any substantial modification that changes intended purpose, architecture, learning approach, or performance in ways that affect compliance.

• A deployer repurposes the system outside the provider’s declared intended use. In that case the deployer may become a “provider” in the eyes of the law and trigger a new assessment obligation.

How long does an audit take?

The regulation doesn’t set a fixed number of days. Duration can depend on the following:

• Complexity of the system.

• Completeness of your technical documentation package.

• Whether harmonized standards apply (faster) or the assessor must dig into bespoke evidence (slower).

• Need for on‑site inspections, sampling of training data governance, or live system testing.

In regulated product domains (medical, machinery) notified body reviews today typically range from a few days (doc review only) to several weeks or months (complex systems, corrective action cycles). 

Post‑market monitoring & incident response (Arts. 72‑74)

Passing assessment isn’t the end. Providers must operate a post‑market monitoring system to collect, analyze, and act on performance and safety data from real‑world use. Serious incidents and malfunction trends must be reported to national authorities. 

Monitoring loop

1. Gather telemetry, accuracy metrics, error patterns, drift signals.

2. Correlate with environment changes (data shifts, user behavior, adversarial attempts).

3. Feed findings back into risk management and QMS CAPA.

4. Update technical documentation and user instructions.

Retention: how long to keep your docs

Retention rules show up in several places and here’s the consolidated view of it:

Minimum retention periods

• EU declaration technical documentation: Keep for 10 years after the AI system is placed on the market or put into service. (Mentioned in Art. 18 cross‑reads with conformity articles; check sectoral product law if longer.)

• QMS records & change history: Align with the 10‑year window but if your industry norm is longer (medical records often longer), you’d need to follow the longer rule.

• Automatic logs: The Act doesn’t fix a single number in the base text, but guidance emerging from policy discussions and draft commentary suggests at least 6 months baseline retention to support traceability and investigation. Many providers target 12‑24 months to be safe, longer if safety‑critical.

• Incident reports & corrective actions: Retain for 10 years in the technical file so you can demonstrate your history.

How does your AI governance calendar should look like?

If you’re starting up a compliance program, map recurring actions to a calendar so the work never drifts. Here’s a starter cadence you can tune by risk level.

Before the AI system release;

• Complete risk analysis workshop.

• Run bias, robustness, and security tests.

• Finalize technical documentation package.

• Internal conformity self‑check or notified body engagement.

Do those quarterly:

• Review drift metrics vs acceptance thresholds.

• Sample audit logs for anomalies and data quality.

• Update risk register with incident learnings.

• Confirm human oversight staffing and training currency.

Do those semiannualy:

• Table‑top incident response drill.

• Data governance revalidation: representativeness, licensing status and deletion requests.

Do those annual

• Full internal audit across Articles 9‑15, 17.

• Contract + supplier reassessment (models, APIs, data sources).

• Re‑issue updated instructions for use if capabilities changed.

Trigger unscheduled reviews when:

• You materially retrain or fine‑tune the model.

• You expand to a new user population or geography.

• You observe performance degradation beyond documented tolerances.

• Regulators issue new harmonized standards.

Implementation blueprint: standing up a high risk AI governance program in 90 days

You won’t finish everything in 90 days, but you can get many things in place.

Days 0‑15: Scope & inventory

• Inventory AI systems. Map to Annex III categories and product law links.

• Identify providers, deployers, importers, distributors across the supply chain.

• Flag candidate high risk systems.

Days 15‑30: Governance design

• Stand up cross‑functional working group (legal, risk, engineering, data, product, operations, ethics).

• Draft risk taxonomy and scoring rubric aligned to fundamental rights.

• Select tooling (risk register, model card repo, logging pipeline, documentation portal).

Days 30‑60: Controls build

• Create risk register templates and pre‑deployment checklist.

• Implement data provenance tracking and dataset documentation.

• Configure automated logging with model version tagging.

• Draft human oversight SOPs and escalation playbook.

Days 60‑90: Evidence & audit readiness

• Populate technical documentation skeleton for each high risk candidate.

• Pilot internal conformity assessment dry run.

• Close top corrective gaps.

• Establish retention policies and storage classes.

Frequently asked questions

a. Does the Act tell me exactly how long an external audit will last? Nope. It defines when you must undergo a conformity assessment and what evidence you must provide. Duration depends on system complexity and assessor workload.

b. Is 6 months of logs enough? It’s a floor emerging from policy commentary, not a ceiling. Regulated industries and safety‑critical applications should keep much longer, especially if incidents may surface slowly.

c. If I fine‑tune a foundation model for credit scoring, am I the provider? If you place that fine‑tuned system on the EU market or put it into service for that Annex III use case, regulators are likely to treat you as a provider for that deployment. That means full obligations, including conformity assessment and 10‑year documentation retention.

d. What if my startup goes out of business? Member States will define mechanisms to preserve technical documentation so regulators can continue supervision. Build escrow or transfer clauses into contracts now.

Final take

Governance for high risk AI under the EU AI Act is a living system. The law ties safety to disciplined lifecycle management. If you build those muscles early, conformity assessments become smoother and customers trust you more.

If you want a ready‑to‑use workspace that maps these requirements to configurable templates, check out open source governance platforms like VerifyWise or integrate similar workflows into your existing GRC stack.