Article 8 Compliance with the requirements: requirements and evidence

What Article 8 compliance with the requirements asks of high-risk AI

A team that must show its high-risk AI system meets Articles 9 to 15 before market placement needs one answer first: Article 8(1) makes compliance with the whole Section 2 set a condition of placing the system on the market, and it does not let the provider satisfy each requirement in isolation. The system must meet those requirements in light of its intended purpose and the generally acknowledged state of the art, and the risk management system under Article 9 is the reference point for deciding what that means in practice. The risk addressed is straightforward to state: a system that is accurate in a lab but fails for the people it is actually used on, or that is secure in design but unsafe in the workflow the deployer built around it, causes harm that the Section 2 duties were written to prevent.

The difficulty is that Articles 9 to 15 are not a checklist. Risk management feeds data governance choices, data choices shape accuracy and bias results, accuracy and robustness determine what the instructions for use can honestly claim, human oversight depends on the logs and transparency the system produces, and cybersecurity protections must hold across all of them. A change to training data can invalidate an accuracy declaration that the technical documentation already states. The practical task is therefore to map each requirement to the others, name one owner for the risk register that drives them, and set a rule that any material change reopens the affected evidence. Confirm with your notified body or market surveillance contact, where relevant, how they expect that linkage to be shown.

Two decisions shape the work. First, decide the intended purpose in writing early, because the state of the art test and the depth of each requirement scale with it, and the purpose statement is what deployers will read in the instructions for use. Second, if the product is an Annex I product covered by existing sectoral law, Article 8(2) lets the provider fold AI Act testing, reporting and documentation into the sectoral procedures already in place, but the provider remains responsible for full compliance with all applicable harmonisation legislation. The Commission must issue guidelines on applying that integration by 1 August 2027 under Article 96(1)(g), so teams should check whether those guidelines have been published before finalizing their approach.

Which systems, teams and sectoral files fall under Article 8

Article 8 applies only once a system is high-risk, and the route by which it became high-risk, the date it must comply, and the role your organization holds all change what evidence you produce. The cards below cover the decisions that most often shift the work, so you can confirm scope before you plan controls.

Annex III standalone systems

Annex III lists standalone use cases such as employment, credit scoring, insurance pricing and access to essential services. A system in one of these areas is high-risk on its own, so Article 8 applies to it directly, and Articles 9 to 15 become the design baseline. Check the intended purpose in writing first, because the same model can fall in or out of Annex III depending on the task it performs. Also check whether the Article 6(3) exemption is claimed, and document the reasoning if it is.

Annex I product systems

Annex I covers AI that is a safety component of, or is itself, a product already covered by EU harmonisation legislation, such as machinery or medical devices. These systems are high-risk through the product route and follow the product's own conformity procedures alongside the AI Act. Confirm which Annex I legislation applies and which notified body or procedure the product already uses, because that determines where the AI evidence is filed. The later application date for these systems gives time to align the product file with the AI requirements.

Provider and deployer roles

Article 8 is addressed to the high-risk system itself, but the obligations that flow from it fall on the provider who places the system on the market. An organization that builds a system and sells it under its own name is the provider. One that buys a system and uses it in its own operations is a deployer, and must rely on the provider's documentation. An organization that customizes a vendor's model for its own purpose may move into the provider role, so confirm this before scoping evidence ownership.

Article 8(2) route for Annex I providers

Article 8(2) allows providers of Annex I products to integrate AI Act testing, reporting and documentation into existing sectoral procedures rather than run a separate file. The provider remains fully responsible for compliance with all applicable harmonisation legislation. Map each Article 9 to 15 requirement to a clause or document already in the sectoral technical file, then record the gaps. Commission guidelines on applying this provision are due by 1 August 2027 under Article 96(1)(g), so check for updates before finalizing the mapping.

Harmonised standards and presumption of conformity

Conformity with harmonised standards cited in the Official Journal gives a presumption of conformity with Section 2 to the extent those standards cover it. Where no standard exists, the Commission may adopt common specifications. Before scoping evidence, confirm which standards are cited for each system category and which parts they leave uncovered, because the uncovered parts still need documented proof. The first harmonised standard, EN 18286:2026 on quality management, was cited on 14 October 2026.

National authority requests for proof

Article 16(k) requires providers to demonstrate conformity when a national competent authority asks for it in a reasoned request. This means the evidence set must be retrievable on short notice, not only assembled at the time of a market placement review. Identify which authority would supervise each system, since national market surveillance authorities enforce the Act for AI systems, with the AI Office taking exclusive competence for some systems built on a provider's own general-purpose model. Keep the response owner and the evidence index current.

How an assessor tests the Article 8 claim

A national competent authority can ask a provider to demonstrate conformity with the Section 2 requirements on a reasoned request under Article 16(k). The request is reactive: it usually follows a complaint, an incident, a market surveillance inquiry or a documented concern about a specific system. The authority is not asking for a certificate, because the Act does not provide one for most Annex III systems. It is asking the provider to show, for the system in question, how Articles 9 to 15 were met in light of the intended purpose and the generally acknowledged state of the art.

Scope of the request: The authority typically names the system, the version and the requirement it is probing, such as data governance or human oversight.
Reasoned basis: Expect the authority to state why it asks. A vague request should be clarified in writing before the provider sends material.
Risk management as the reference: Article 8(1) ties compliance to the Article 9 risk management system, so the provider should show how identified risks led to the measures it built.
Version control: Evidence must match the system as placed on the market. Logs of changes and document history help show that.
Coordination: Where a sectoral file already covers part of the question, the provider should explain how that file relates to the AI Act evidence.

Before responding, confirm the authority's jurisdiction, the deadline it sets and whether legal counsel should review the response.

How to build the Article 8 compliance chain step by step

This sequence turns the Article 8 umbrella requirement into a traceable chain, running from intended purpose through the Article 9 risk file to owned, evidenced controls for Articles 9 to 15, with a defined route for Annex I products and a review cadence that keeps the evidence current.

Define intended purpose and scope the system
The provider writes down what the high-risk AI system is for, who it is for, the contexts where it is deployed, and the foreseeable misuse that falls outside that purpose. Legal or compliance staff confirm the classification route with the product owner, because Article 8 measures compliance against intended purpose. The step closes when a signed intended-purpose statement and system boundary document exist and every later step cites them.
Record state-of-the-art references
Article 8 requires compliance to take the generally acknowledged state of the art into account, so the team lists the standards, published guidance, benchmark methods and known attack techniques it relied on for each Section 2 requirement. Engineering and security leads select these references and record why each was chosen and what version was used. The output is a dated reference register that an assessor can compare against the design choices made in the system.
Anchor the Article 9 risk management file
The Article 9 risk management system is the reference point for Article 8, so the team opens or updates the risk file before any other requirement is mapped. It records identified risks to health, safety and fundamental rights, residual risk decisions, and the testing results that support them. The risk owner approves the file and assigns a version. The step is complete when every later requirement can point to a specific risk entry or explain why none applies.
Map each Article 9 to 15 requirement to an owner
The team builds a matrix with one row per requirement in Articles 9 to 15 and columns for the accountable owner, the design decision, the test or check, and the artifact that proves it. Typical owners include the risk lead for Article 9, the data lead for Article 10, the documentation lead for Article 11, the platform engineer for Article 12, the product lead for Article 13, the operations lead for Article 14, and the security lead for Article 15. Each row names an artifact, such as a log schema or a test report, so the gap list is visible before the audit.
Decide the Annex I integration route
Providers of products covered by Annex I Section A must make the AI Act evidence fit inside existing sectoral procedures, and Article 8(2) allows AI Act testing, reporting and documentation to be integrated there. Legal and quality teams decide whether the AI system is covered by an existing sectoral file, which harmonisation legislation applies, and which notified body or assessor is involved. The output is a written integration decision that lists each Article 9 to 15 artifact and the sectoral document where it is held. Confirm the current Commission guidance on this route before relying on it, since Article 96(1)(g) requires guidelines on the topic.
Assemble the evidence store and version control
Each artifact in the matrix is placed in one controlled repository with an owner, a version and a change history, so an assessor can see what was current on a given date. Document management tools such as XWiki keep page versions and let teams compare and restore earlier revisions. The compliance lead checks that every matrix row resolves to a stored artifact with a visible version. The step closes when a trace from requirement to owner to artifact can be followed without asking anyone to explain it.
Set a review cadence and trigger events
The chain stays valid only if it is reviewed when the system changes, so the team sets a fixed review schedule and a list of trigger events, such as a model retrain, a change in intended purpose, a new incident, or a new harmonised standard citation. The compliance lead owns the schedule and records each review decision in the evidence store. Confirm the review frequency with the internal governance policy and any notified body or assessor requirements. The output is a dated review log linked to the matrix and the risk file.

Evidence that shows Article 8 compliance and how to keep it current

Article 8 is met through a body of evidence rather than a single document. The artifacts below connect the intended purpose to the Article 9 risk management system and to the Article 9 to 15 requirements, and each one needs a refresh rhythm so the file reflects the system as it runs today.

Documented intended-purpose statement

This statement fixes the use case, the deployment context, the affected people and the conditions the system is not designed for. Article 8 measures compliance against intended purpose, so every later assessment depends on it. Keep it current by re-reading it whenever the use case, user population, input data sources or market changes, and by recording who approved each revision. Check that marketing material, instructions for use and the risk register all describe the same purpose.

Traceability matrix for Articles 9 to 15

A matrix maps each requirement in Articles 9 to 15 to the design decision, test, document and log that address it, and names an owner for each row. It shows an assessor where any requirement is met without a search. Refresh it at every release and whenever a control moves, and flag rows whose evidence link is broken or points to a superseded version. Gaps found in this matrix are usually the fastest route to a finding.

Risk register with residual risk decisions

The register lists identified risks to health, safety and fundamental rights, the mitigations applied, the residual risk remaining and the person who accepted it. Article 8 relies on this register as the reference point, so a residual risk without a recorded decision is a visible gap. Review entries after each incident, each material model or data change and on a set schedule. Confirm that the acceptance criteria are written down before testing begins.

Version-controlled design records

Design decisions, architecture diagrams, model selection rationale and change approvals need a history that shows what changed, when and by whom. A page history lets an assessor see which design existed when a system was placed on the market. Store records in a wiki or document system that keeps every revision and allows comparison and rollback. Confirm that releases link to the record version they were built from, and that deleted or overwritten pages are not silently lost.

Logged test results

Test runs against predefined metrics, adversarial probes and bias checks produce the proof that the system performs as declared. Keep raw outputs, the dataset and model versions tested, the thresholds applied and the pass or fail decision for each run. Probe tools such as garak write a JSONL record of every attempt and a hit log of successful attacks, which can be retained with the release file. Rerun the suite after each change that could affect behavior, and record which results were accepted and why.

Annex I integration note

Providers of products covered by Annex I Section A can fold AI Act testing, reporting and documentation into existing sectoral procedures, so this note records which AI Act evidence sits in which sectoral file and who is responsible for each. Without it, the sectoral file and the AI Act file drift apart. Review the note when the harmonisation legislation changes, and confirm against the Commission guidelines that Article 96(1)(g) requires by 1 August 2027.

What meeting Article 8 costs in money and effort

This table breaks down what Article 8 compliance costs across internal time, tooling, evidence upkeep, outside testing and assessor fees. Read each row for who is paid, whether the cost is one-time or recurring, and what to ask for in a quote. No fees or durations are fixed by the Act itself, so the figures a provider should expect come from its own scope and its own sectoral route.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it and what to request in a quote
Internal engineering and compliance time	Your own engineers, product owners, risk and legal staff	Both: initial build, then recurring upkeep	Number of Article 9 to 15 requirements in scope and number of systems. Ask the partner to itemize effort by requirement and by role.
Risk management and documentation work	Internal teams, with optional outside support for the Article 9 process and Article 11 technical file	Mostly one-time, updated on each substantial change	Complexity of the system and how many versions are on the market. Ask for a list of documents produced and who signs off each.
Tooling and licences	Software vendors, or no licence cost for open-source platforms	Recurring for commercial tools, hosting and maintenance for open-source	Choice of self-hosted open-source components removes most licence spend, but hosting, backup and upgrades remain. Confirm licence terms with each vendor.
Evidence upkeep and logging	Platform and operations teams	Recurring for the life of the system	Volume of event logs and retention periods required by the Act. Ask how logs, versions and approvals are stored and reviewed.
External testing or review	Independent security testers or reviewers under a fixed-scope agreement	Usually periodic or per release	Scope of testing against Article 15 robustness and cybersecurity, and the number of releases. Request a written scope before work starts.
Notified body or assessor fees	Notified body or independent assessor, where a route requires one	Recurring for certificate maintenance and surveillance, where applicable	Only some systems, such as certain biometric systems and Annex I products, need a notified body (Article 43). Most Annex III systems use internal control, so confirm your route first.
Commission guidance and standards	No fee, but effort to track changes	Recurring monitoring effort	Article 96(1)(g) requires Commission guidelines by 1 August 2027, and EN 18286:2026 was cited in the Official Journal on 14 October 2026. Budget time to adapt documents when these land.

Who owns Article 8 compliance, who prepares it and who assesses it

Under Article 8(1), the high-risk AI system must comply with the Section 2 requirements, and the provider is the party placing it on the market who answers for that compliance. Ownership cannot be handed to a vendor or consultant. The provider decides the intended purpose, accepts or rejects residual risk under the risk management system, signs the declaration of conformity where it applies, and answers to the national competent authority if it asks the provider to demonstrate conformity under Article 16(k).

Accountable executive: Name one person who holds the conformity decision and can sign off residual risk for each system.
Intended purpose statement: Keep a written, approved intended purpose, since Article 8 measures compliance against it.
Control ownership: Assign each Article 9 to 15 requirement to an internal owner with a deputy.
Decision record: Log go or no-go decisions, their rationale and the evidence reviewed.
Regulator response: Define who receives an authority request and how quickly the evidence pack can be produced.

Check that your own governance documents name the decision owner, not only the team that did the work.

Where Article 8 programs usually fall short

Article 8 is short, but it makes every other Section 2 requirement answer to one reference point: the risk management system and the intended purpose. Most programs fail not because a single requirement is missing but because these links between documents were never built or kept current. The gaps below are the ones to test first.

Risk management file stands alone

Teams often write a risk register under Article 9 and then treat Articles 10 to 15 as separate projects with their own documents. Article 8 expects the risk management system to be the reference for the whole set. Check whether each data, documentation, logging, transparency, oversight and accuracy decision names the risk it addresses and the residual risk it accepted. If a risk entry cannot be traced to a design control or a test result, the link is missing.

Intended purpose drifts from practice

The intended purpose written in the instructions and technical file often describes a narrower use than the one sales, customer success or internal teams actually run. Because Article 8 measures compliance against intended purpose, drift changes which requirements apply and how far they reach. Compare the documented purpose with support tickets, pilot projects and customer configurations at least once per release. Any use outside the stated purpose needs a documented decision.

State-of-the-art claims lack a basis

Providers frequently state that a design reflects the generally acknowledged state of the art without recording what they reviewed. Article 8(1) makes this a condition of compliance, so an unsupported sentence is a finding in waiting. Keep a dated review that lists the techniques, published benchmarks and standards considered, the reasons for each choice and who approved it. Revisit the review when the model, data or threat picture changes.

Annex I teams duplicate sectoral files

Providers of Annex I products may integrate AI Act testing, reporting and documentation into existing sectoral procedures, and Article 8(2) keeps them responsible for full compliance with the applicable harmonisation law. Teams that run a separate AI Act file beside the sectoral file create two versions of the same test results that drift apart. Map each Section 2 requirement to the sectoral section that holds its evidence, then keep one authoritative record. Confirm with the notified body or sectoral authority how they expect the file to be arranged.

Evidence is not versioned

Assessors ask which version of the system a test or document applies to, and Article 16(k) requires providers to demonstrate conformity on request from a national competent authority. Evidence kept in shared drives or overwritten pages cannot answer that question. Store risk files, purpose statements and state-of-the-art reviews under version control, with dates, authors and the system release each one covers. Test that you can retrieve the version in force on a past release date.

How long, how costly and how much work is Article 8 compliance?

What drives the cost of Article 8 compliance?

The cost depends mainly on how many high-risk systems you have, how many Articles from 9 to 15 each one touches, and how much of your evidence already exists. Article 8 itself adds no separate deliverable; it makes Sections 2 requirements the test, so the work sits in Articles 9 to 15 and the risk management system that anchors them. Costs fall into internal staff time, engineering changes to logging, oversight and documentation, tooling, and any outside help. Systems that already run under ISO/IEC 27001 or a sectoral quality management system usually need less new evidence, while a system built without documentation may need a full technical file rebuilt. Ask any provider to price each system separately and to split one-time build work from recurring monitoring and updates.

Is there enough time before the high-risk dates?

Yes, for most organizations the window is workable if the inventory starts now, but the dates differ by system type. As amended in 2026, the high-risk rules apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I product systems. Start by classifying each system, then sequence the Article 9 risk management work first, because the other requirements reference it. Allow time for internal review, testing of changes and any conformity assessment route that applies to your system, and confirm each step with your legal and notified body advisers, since the timing of those steps depends on your own product and sector.

What does the work ask of our engineers and compliance staff?

Engineers carry the technical share: they must make the system log events automatically, build human oversight controls such as override and stop, test accuracy and robustness against declared metrics, and protect the system against attacks such as data poisoning. Compliance and legal staff own the classification, the intended purpose statement, the risk decisions and the technical file. Product owners must confirm the intended purpose and the state of the art argument. Plan for regular reviews, because the evidence must stay current across the lifecycle, not only at launch.

Can we do Article 8 compliance in-house?

Many organizations can do most of it in-house if they have engineers who understand the system, a compliance lead who can read the Articles closely, and time to keep records current. The harder parts are usually independent judgment on risk acceptability, testing evidence that a reviewer will accept, and conformity assessment routes that need a third party. Decide per system: an in-house team can own the controls and the evidence, while outside help can review gaps, prepare the technical file and test the logs. Only an independent auditor, assessor or notified body issues conformity findings; no implementation partner can issue them.

What does an implementation partner change in the work?

A partner changes who does the preparation and how fast the gaps close, not who is accountable. DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so it can build the logging, oversight workflows, version-controlled documentation and test harnesses that produce the evidence. It also runs security testing of applications, APIs and AI systems, which can support the Article 15 robustness and cybersecurity evidence. Your organization still owns the controls, the classification and the decisions. DeployOpen does not issue audit reports, attestations or certifications.

Is Article 8 compliance enough on its own?

No. Article 8 is the umbrella that requires you to meet Articles 9 to 15, so it does not stand alone. Providers must also cover the quality management, registration, post-market monitoring and incident obligations in other chapters, and deployers have their own duties. If your system is an Annex I product, Article 8(2) lets you fold AI Act testing and documentation into existing sectoral procedures, and the Commission must issue guidelines on that by 1 August 2027 under Article 96(1)(g). Confirm which obligations apply to your role with counsel before you scope the work.

What should a written scope for Article 8 work include?

A written scope should name each high-risk system, its role (provider or deployer), the Articles covered and the evidence each one must produce. Ask for deliverables by system, the acceptance criteria for each, the people responsible on both sides, and what is excluded. Request separate prices for one-time build work and recurring support, the assumptions that drive the effort, and the dependencies on your own teams and data. Confirm which standards and sectoral files the work will reuse, and ask how changes after go-live are handled. Fixed-scope engagements agree these items in writing before work starts.

How DeployOpen prepares Article 8 evidence for your systems

DeployOpen works from a written scope, agreed before any work starts, that names the high-risk systems in question, the Article 9 to 15 components each one must evidence, and the infrastructure those systems run on. Most engagements are fixed-scope, so the scope, deliverables and timelines are settled in writing first, and a quote follows from that scope. DeployOpen implements the self-hosted open-source platforms that support the evidence, such as a governance platform for the requirement register and assessment records, a tracing platform for lifecycle logs, and a version-controlled wiki for the documentation set, inside your own cloud accounts, data centers or air-gapped networks. It hardens and documents them, then prepares the systems, controls and evidence an assessor will ask to see.

DeployOpen does not issue audit reports, attestations or certifications. Conformity for an Annex III system is normally shown through the internal-control route in Annex VI, and the organization that places the system on the market owns that declaration. Where a notified body or another independent body is involved, that body performs the assessment and issues any certificate. Confirm early which route applies to each system, and ask your legal or compliance lead to confirm whether an Annex I product file will be combined with sectoral documentation under Article 8(2). Your organization keeps ownership of its risk decisions, its declarations and its regulator relationships throughout.

When you request a quote, ask for the scope to list each system, the Article 8 evidence items it will produce, the platforms to be deployed and where they will run, who holds administrative access after handover, and which items remain with your own staff or a separate assessor. Ask how the work is split between one-time setup, such as deployment and documentation templates, and recurring work, such as upgrades, evidence refreshes and support, which DeployOpen offers as retainers. Those answers determine the cost and effort far more than the number of frameworks named in the request.

Article 8 Compliance with the requirements