What Article 16 requires from a high-risk AI provider
Article 16 asks a provider of a high-risk AI system to meet twelve duties before and after the system reaches users: comply with the Section 2 requirements, label the system with a name and contact address, run a quality management system, keep documentation and logs, complete a conformity assessment, issue an EU declaration of conformity, affix CE marking, register the system, take corrective action, demonstrate conformity on request, and meet the accessibility requirements. The duties are a single checklist because each one depends on another. The quality management system defines how the technical documentation, logs and post-market records are produced. The conformity assessment under Article 43 must be completed before the system is placed on the market or put into service, so the documentation it tests has to exist first. Registration, the declaration and CE marking then follow from a passed assessment.
These duties apply only once the system is high-risk under Chapter III. 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. Providers should confirm now which of their systems fall into either group, because the documentation and logging work for a system launched in 2027 starts well before that date. Ask the team to record the intended purpose for each system, since changing that purpose can make a system high-risk and shift all twelve duties onto whoever made the change under Article 25(1).
For the quality management system, the documentation, the logs and the corrective action duty, providers should decide early who owns each record, where it is stored and how long it is kept, and whether an implementation partner will prepare the evidence while the provider keeps accountability. Authorities can request documentation and access to logs under their control (Article 21), so the evidence must be retrievable on demand, not assembled after a request. Confirm the current text of each article in the consolidated AI Act before fixing the checklist.
Which providers and systems Article 16 applies to
Article 16 applies only once a system is high-risk and someone counts as its provider. The cards below cover the scoping questions that decide whether the provider duties land on your organization, and which route and timing follow from the answers.
Who counts as a provider
Under Article 2, the Act reaches providers placing AI systems on the EU market wherever they are established. A non-EU developer whose system's output is used in the EU is in scope too. Check who develops the system, who puts it on the market or into service under its own name, and whether that party is inside or outside the EU. A non-EU provider must also appoint an EU authorised representative (Article 22).
Deployers who become providers
Under Article 25(1), a distributor, importer, deployer or other third party takes on the provider role and all Article 16 duties if it rebrands a high-risk system, substantially modifies it, or changes its intended purpose so that it becomes high-risk. Review fine-tuning, white-labeling and custom integrations before you assume you are only a deployer. The change in role happens at the moment of modification, not at the next audit.
Annex III systems: timing and route
Annex III systems are assessed under the internal-control route in Annex VI for most categories. For Annex III systems the high-risk rules in Chapter III Sections 1 to 3 apply from 2 December 2027 under the 2026 amendment. Confirm the conformity route with your counsel and any notified body involvement for biometric use cases before you fix the project plan.
Annex I products: timing and route
Systems that are safety components of products under the Annex I harmonised legislation fall under the sectoral conformity procedure, which can involve a notified body. Under the 2026 amendment the high-risk rules apply to these product systems from 2 August 2028. Map the existing product certification path first, since the AI conformity assessment is folded into it rather than run alongside.
Article 6(3) exemption decisions
A system listed in Annex III may fall outside high-risk status under the Article 6(3) exemption when it performs only a narrow procedural task or preparatory work, among other conditions. Document the assessment before you claim it, because a provider who concludes the system is not high-risk must still be able to show that reasoning to authorities. A wrong exemption call leaves every Article 16 duty unmet.
Importers and distributors in the chain
Importers placing a non-EU provider's system on the EU market and distributors making it available carry verification duties (Articles 23 and 24) and become providers only in the Article 25(1) cases. Agree in writing who holds the technical file, the declaration of conformity and the CE marking before the system moves. Ask suppliers which Article 16 documents they will hand over and on what timescale.
How to implement the twelve Article 16 duties in sequence
The sequence turns twelve separate provider duties into one ordered program, so each step produces the evidence the next one needs and the system can be placed on the EU market with its conformity assessment already complete.
Confirm high-risk status and scope
Before any Article 16 work starts, the provider confirms that the system is high-risk, either because it falls under an Annex III use case or because it is a product covered by Annex I, and records the intended purpose and the Article 6(3) reasoning if an exemption is claimed. Legal and product owners sign the scope record. Done means a dated classification memo exists, the intended purpose is fixed in writing, and the team knows which Chapter III Section 2 requirements and which conformity route apply. Confirm the dates in force for the system with counsel, since the 2026 amendments changed when Section 2 applies.
Build the quality management system
The provider documents its quality management system covering the Article 17 aspects, assigns owners for design, data, testing, risk and post-market activity, and ties procedures to the existing ISO 27001 or ISO 42001 management system where one exists. EN 18286:2026 was cited in the Official Journal on 14 October 2026 as the first harmonised standard on quality management, so the provider should confirm whether it intends to rely on it. Done means approved procedures, named owners and a management review record exist for the system.
Prepare technical documentation, records and logging
Engineering and compliance teams assemble the technical documentation, risk management records, data governance evidence and the automatic logging design, and configure the system to generate and retain logs under the provider's control. Article 18 sets how long records must be kept and Article 19 sets the log retention duty. Done means a versioned technical file exists, each Article 8 to 15 requirement maps to a document or test, and log retention is confirmed in configuration. A self-hosted wiki with version history can hold the file, provided its change record is preserved.
Complete the Article 43 conformity assessment
The provider completes the conformity assessment route that applies, which for most Annex III systems is internal control under Annex VI, while some biometric systems and Annex I products need a notified body under Article 43. This must finish before the system is placed on the market or put into service, as Article 16(f) requires. Done means a signed assessment record, test results and, where needed, a notified body certificate are in the technical file. Ask any notified body for its scope and timeline in writing before engagement.
Draw up the EU declaration of conformity
Once the assessment is complete, the provider prepares the EU declaration of conformity, a signed written statement that the system meets the Section 2 requirements. The declaration must be kept with the technical file. Done means an authorized signatory has signed the declaration for the specific system version, and the declaration references the assessment record it relies on. Each new substantially modified version needs its own check against this step.
Apply the CE marking and provider identification
The provider affixes the CE marking to the system, packaging or accompanying documentation as the Act requires, adds its name, registered trade name or trademark and contact address, and includes the notified body number where one took part. Done means a labeling check against the Article 16(b) and CE marking requirements is recorded, and the marking appears on a sample of the shipped or deployed product. Product and legal teams should review the placement for each delivery channel.
Register the system in the EU database
The provider registers the high-risk system in the EU database before it is placed on the market or put into service, entering the data set out in the registration annex. Done means a registration confirmation is stored in the technical file and the registered data matches the declaration of conformity. Re-check the registration whenever the intended purpose or version changes.
Set up corrective action, cooperation and accessibility
The provider puts in place a process to correct non-conforming systems, notify authorities and answer reasoned requests for documentation and log access under Article 21, and it confirms that the system meets the accessibility requirements of Directives (EU) 2016/2102 and (EU) 2019/882. Done means a tested runbook names who answers authority requests and how quickly, an accessibility test report is on file, and corrective action records are kept with the technical file. Confirm the response expectations with counsel before relying on them.
Why the duties depend on each other
Article 16(f) makes the conformity assessment a gate. The assessment under Article 43 must be completed before a high-risk system is placed on the market or put into service. The EU declaration of conformity, the CE marking and the registration in the EU database all follow from that completed assessment, so they cannot be prepared as paperwork to finish at launch. In practice, the assessment route depends on the system: most Annex III systems use internal control under Annex VI, while some biometric systems and Annex I products involve a notified body. Confirm the route early, because a notified body is a separate engagement with its own lead time and scope, and a missed gate can delay release. Only the independent body issues a certificate where one applies, and the organization still signs its own declaration.
Before the gate opens, the other duties feed one another in a loop. The quality management system under Article 17 sets the procedures that produce the technical documentation, the logs that the system generates under Article 19, and the records that show how the system behaves in use. Post-market information and serious incidents then reveal faults, and the corrective action duty requires the provider to fix or withdraw a non-conforming system and to update its documentation and assessment where the change matters. A substantial modification can also restart the assessment. Teams should assign one owner for change control that links issue tracking, document revisions and log retention, so each corrective action leaves a traceable trail.
Article 21 means every part of that loop can be requested at once. On reasoned request, a competent authority can ask the provider for all the information and documentation needed to demonstrate conformity, and for access to the logs under the provider's control. The authority does not need to ask for each element separately, so the records must be complete, current and retrievable as a single set. Ask whether your document system keeps version history and access records, and run a test request against a sample system to see how long it takes to assemble the full file. The gaps you find in that test are usually the gaps an assessor would find.
How an assessor tests each Article 16 duty
This table compares each group of Article 16 duties by how an assessor tests it, the evidence requested and the findings that most often come up. The assessor is a national market surveillance authority or a notified body, never DeployOpen, so read each row as what the provider must be able to show that independent reviewer.
| Duty group | Test approach and evidence requested | Common findings |
|---|---|---|
| Conformity assessment gate (Article 16(f)) | Assessor checks the dated record that the Article 43 route was completed before the system was placed on the market or put into service, with the signed assessment file and any notified body certificate. | Market launch or pilot use dated before the assessment was finished, or the wrong route chosen for the system. |
| Declaration and CE marking (Articles 47 and 48) | Assessor compares the signed EU declaration of conformity with the technical file version in use, and checks the CE marking on the system, packaging or documentation and any notified body number. | Declaration signed against an older version of the system, or marking missing from digital delivery channels. |
| Registration record (Article 16(i) and Article 49) | Assessor matches the EU database entry against the system's current intended purpose, version and provider details, and asks for the registration timestamp relative to first use. | Entry missing, out of date after a change, or describing a different intended purpose from the one in the file. |
| Name and contact details (Article 16(b)) | Assessor inspects the system, packaging or accompanying documentation for the provider name, registered trade name or mark and a reachable contact address. | Contact details present in the documentation but absent from the product interface or packaging where the Act requires them. |
| Documentation and log access (Articles 18, 19 and 21) | On a reasoned request, assessor expects complete technical documentation and access to logs under the provider's control within the time the authority sets. Ask your team to test the export path before any request arrives. | Logs held by a third party with no contractual access, or documentation scattered across tools with no index. |
| Corrective action records (Articles 20 and 21) | Assessor asks for the non-conformity log, root cause analysis, corrective steps taken, dates, and proof that the authorities and deployers were informed where the Act requires it. | Issues fixed in code without a written record, or no evidence that the risk was communicated to deployers and distributors. |
| Accessibility (Article 16(l)) | Assessor checks the system against the accessibility requirements of Directives (EU) 2016/2102 and (EU) 2019/882, expecting test results, an accessibility statement and records of remediation. | No accessibility test on file, or testing limited to the user interface and not the documentation and support channels. |
| Demonstrating conformity on request (Article 16(j)) | Assessor expects the provider to present a single, indexed evidence pack on demand that maps each Article 16 duty to its document, owner and date. | Evidence exists but cannot be located quickly, or the pack contradicts the technical file on version or scope. |
Evidence that shows each Article 16 duty is met
Article 16 duties are proven through records, not statements. The cards below group the evidence a provider should hold for each duty, and they share one requirement: every record must be dated, versioned and traceable to the system version it describes. Keep each item current between audits so it can be produced the moment a competent authority asks for it.
Conformity assessment record
Keep the completed conformity assessment under Article 43 as a dated record that shows it was finished before the system was placed on the market or put into service, as Article 16(f) requires. Check that the record names the system version, the route followed (internal control or notified body) and the sign-off. If the system is later substantially modified, the record must be reopened, so track which version each assessment covers.
Signed EU declaration of conformity
Hold the signed EU declaration of conformity for each high-risk system, stored with the technical file and tied to the same version as the conformity assessment. Confirm that the signatory has authority to bind the provider and that the declaration matches the system's labeled name and contact details. Retention periods for the declaration are set by Article 18, so the document management system should apply them automatically.
CE marking samples and labels
Keep photographs or files of the CE marking as applied to the physical product or documentation, along with any notified body number where one applies. Record where the marking appears so that packaging, interface screens and accompanying documents can be checked against the same version. Mismatched labels are an easy finding, so compare marking samples against the declaration on each release.
Registration confirmation
Retain the confirmation issued after the system is registered in the EU database, together with the Annex VIII data submitted. Compare the registered details against the current system version, intended purpose and provider contact address, and update the registration when they change. Also store the proof for any claimed not-high-risk system, since regulators will check the reasoning as well as the entry.
QMS and technical documentation index
Maintain an index that maps each Article 17 quality management system element and each technical documentation section to its current document, owner and version. Use version control so every change records what changed, when and by whom, and keep access logs showing who viewed or edited controlled records. Confirm that the index is reviewed on a set schedule, since stale indexes are the most common reason evidence cannot be found quickly.
Log retention and corrective action records
Retain the automatically generated logs for the period Article 19 sets, under the provider's control, and keep records of any corrective action taken under Article 20, including the root cause, the fix and the notifications made. Confirm that logs are protected against alteration and that access is restricted to named roles. Corrective action logs should link to the affected system version and to the incident or monitoring data that triggered them.
What meeting Article 16 costs in money and effort
Tooling costs cover the software and infrastructure that hold the evidence Article 16 requires: version-controlled documentation, log storage, compliance tracking and access control. Open-source platforms remove license fees for the core software, but hosting, storage, backup and any commercial add-ons still carry cost, and those are paid to cloud providers, hardware vendors or software suppliers. Most of this spend recurs because logs accumulate and platforms need upgrades and patching.
- Infrastructure: compute, storage and backup for the log store and documentation platform, sized for the retention period the provider sets.
- Open-source components: no license fee for the core software, but confirm the license terms of each component and any paid support contract.
- Commercial add-ons: SIEM, identity or evidence-management products the organization already runs, where Article 16 evidence is pulled from them.
- Upgrades and patching: recurring effort to keep platforms current inside the organization's own environment.
- Retention growth: storage needs rise over time, so the cost model should show year-on-year growth.
Ask the vendor or implementation partner for a quote that separates one-time setup from annual run costs, lists every third-party license, and states the storage assumptions behind each line.
Engineering effort is usually the largest cost in Article 16. Logging, documentation and traceability must be designed into the system and maintained as it changes, which means work by platform, security and data engineers. Most of this is one-time build work followed by recurring effort every time the system, its data or its intended purpose changes. The cost depends heavily on how much of the system is already instrumented.
- Log design: capturing the automatically generated logs the system produces, with the fields needed to trace its operation over the period the provider must keep them.
- Documentation build: producing and linking technical documentation, instructions for use and the records that support the declaration of conformity.
- Traceability: connecting code, model versions, datasets and test results so an assessor can follow one change through the evidence.
- Change control: updating documentation and tests with each release, which is recurring work.
- Integration: connecting the system to existing ticketing, identity and monitoring tools.
Ask for effort estimates broken down by these items, with the assumptions about existing logging and documentation stated, and a separate line for change control after go-live.
Article 16(c) requires a quality management system, which is an operating process rather than a one-time document set. Upkeep covers the people who run it, the reviews it requires and the records it generates. The effort scales with how many high-risk systems the organization runs and how often they change. Proportionality rules for small and medium enterprises may reduce some elements, so the scope of the QMS should be confirmed before budgeting.
- Process ownership: a named owner and time allocated for risk management, change control, complaint handling and record keeping.
- Internal reviews: periodic checks of the QMS against the system's actual operation, with findings tracked to closure.
- Training: keeping staff current on the procedures that apply to their roles.
- Management review: recurring governance time to review QMS performance and approve changes.
- Standards alignment: the first harmonised standard for quality management, EN 18286:2026, was cited in the Official Journal on 14 October 2026, so teams should confirm how it applies to their existing management system.
Ask for the QMS scope in writing, the roles and hours assumed for each recurring activity, and whether the QMS will be integrated with an existing management system or built separately.
External review is optional for many Annex III systems but is often bought to test controls before an assessor sees them. Testing covers application security, AI-specific behavior and the accessibility obligation in Article 16(l). These are paid to independent testers or consultants, and the cost depends on scope, number of systems and how many test cycles are needed. Testing is usually repeated after material changes, so it recurs.
- Security testing: application, API and infrastructure testing to confirm the system's controls work as documented.
- AI system testing: structured probing of language model or agent behavior, where the system uses such models. Tools such as garak can generate a JSONL report and a hit log of attempts that found a vulnerability, which the testers can review.
- Accessibility review: checks against the accessibility directives named in Article 16(l), confirmed by a qualified reviewer.
- Gap review: a pre-assessment read-through of the evidence against each Article 16 obligation.
- Retesting: repeat testing after material changes or findings.
Ask for a written scope listing the systems, test types, number of test cycles and deliverables, and state who retains the findings and remediation records.
Notified body involvement applies only where Article 43 requires it, which is generally for some biometric systems and Annex I products, not most Annex III systems that use internal control under Annex VI. Where a notified body is required, its fees are paid directly to the body, and the provider also bears preparation costs and any reassessment after substantial modification. Fees are set by each body, so the provider should obtain quotes from more than one.
- Assessment fee: charged by the notified body for the conformity assessment, usually based on the scope and effort of the review.
- Preparation: internal and partner time to build the technical file and evidence the body will review.
- Reassessment: costs when the system is substantially modified, and certificate renewal where applicable.
- Surveillance activity: ongoing checks by the body that the provider will need to plan for.
- Route check: confirming whether Article 43 requires a notified body at all, before any fee is committed.
Ask each body for a written quote that states what the fee covers, the review steps, the expected duration of the review and the cost of any reassessment, and confirm the route with legal or compliance counsel first.
Self-hosted open-source tools that produce Article 16 evidence
This table compares four self-hosted open-source tools by the Article 16 duty each helps evidence, the license terms to review, and what the tool cannot do. Read each row as a source of records for your own quality management and documentation, not as a route to compliance. The main takeaway is that a tool produces evidence only when your team defines the process, owns the content and keeps the records current.
| Tool | Article 16 duty supported | Evidence it can produce | License caveat |
|---|---|---|---|
| CISO Assistant | Quality management system and conformity assessment (Article 16(a) and (f)), mapped to the controls you choose | Framework mappings, assessment records and audit trails for internal control checks against the frameworks loaded in the tool | AGPL-3.0-only: review network-use obligations before offering a modified version to users over a network |
| XWiki | Documentation keeping and the technical file (Article 16(d)), and the EU declaration of conformity (Article 16(g)) | Version history showing what changed, when and by whom, plus comparisons and rollbacks between document versions | LGPL-2.1-or-later: confirm obligations for any modified library components you distribute |
| BookStack | Access to documentation by role (supports Article 16(d) and the accountability expected of the provider) | Role assignments and page-level permission settings that show who could read or edit each document | MIT: permissive, with the notice and license text retained in copies you distribute |
| garak | Testing and risk management for language model components, feeding the QMS and post-market monitoring evidence (Article 16(a) and (k)) | JSONL reports of every probe attempt and evaluation, plus a hit log of attempts that found a vulnerability | Apache-2.0: retain the license and notices; confirm that probe results are not a substitute for your own validation |
Who owns each Article 16 duty and what to outsource
The provider remains legally responsible for the high-risk system, so its own accountable owners must make the decisions that Article 16 places on the provider. Outside parties can prepare material, but they cannot take over these decisions or sign on the provider's behalf. Assessors will look for named internal owners who can explain how each duty is met.
- Accountable decisions: Senior staff decide the intended purpose, the risk position, the accessibility claims and whether to place the system on the market.
- Quality management system ownership: Internal leaders approve the policies, roles and procedures that make up the quality management system and run its reviews.
- Declaration and marking: The provider signs the EU declaration of conformity and applies CE marking only after its own review confirms the conformity assessment is complete.
- Corrective action and authority contact: The provider decides on corrective measures, informs distributors and deployers, and answers authority requests.
- Post-market duties: Internal teams own monitoring, incident decisions and registration in the EU database.
Confirm that each Article 16 duty has a named internal owner and a deputy, and that the owner can explain the evidence without relying on a consultant.
An implementation partner such as DeployOpen works inside the provider's infrastructure to build the technical and documentary parts that the provider then reviews and adopts. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms in the client's own cloud accounts, data centers or air-gapped networks. It prepares systems, controls and evidence for assessment. It does not issue audit reports, attestations or certifications.
- Log and records infrastructure: The partner can configure the systems that retain logs, version documentation and store records, so the provider can meet its retention duties.
- Documentation and evidence preparation: The partner can structure technical documentation, map evidence to Article 16 duties and keep it under version control.
- Security testing: The partner can run application, API, infrastructure and AI system testing, and report findings to the provider's owners for remediation.
- Compliance readiness: The partner can run a gap assessment against the requirements and prepare the materials an assessor will request.
- Hardening and backup: The partner can harden, back up and upgrade the platforms that hold the system's data and records.
Before engagement, ask the partner to state in writing which deliverables it prepares, which it reviews and which remain the provider's responsibility.
An independent party assesses conformity and issues the output that the Act requires. For most Annex III systems, the provider can use internal control under Annex VI, so the assessment is performed and documented by the provider itself. For some biometric systems and Annex I products, a notified body must be involved under Article 43. Only the independent auditor, assessor or notified body issues reports or certificates.
- Route determination: Confirm early whether the system follows internal control or requires a notified body, because the route determines who must sign off.
- Notified body assessment: Where required, the notified body evaluates the quality management system and technical documentation and issues any certificate.
- Independence: The assessor must be separate from the people who designed and built the system, which is why the implementation partner cannot act as assessor.
- Authority cooperation: Market surveillance authorities may request documentation and log access from the provider, and the assessor does not replace that duty.
- Scheduling: Ask any notified body for its own timeline and fee basis in writing, since these are set by that body and not by this page.
Check whether the system's route and the notified body's scope are confirmed in writing before any work begins.
Where providers usually fall short on Article 16
Most Article 16 failures are not missing policies. They are gaps between documents that should agree with each other and the system as it actually runs. The cards below cover the points where providers most often lose that alignment, with a closing action for each.
Market placement before assessment
Article 16(f) requires the conformity assessment under Article 43 to be completed before a high-risk system is placed on the market or put into service. Teams often treat a pilot, a beta or a internal rollout as outside that rule, then discover that a customer-facing release has already started. Check the release calendar against the assessment sign-off date, and confirm with counsel how your deployment model counts as placing on the market.
Declaration that drifts from the file
The EU declaration of conformity states that the system meets the requirements, so it must match the technical documentation and the assessment record it relies on. A version number, intended purpose or data description that changed in one place but not the other undermines the whole file. Before signing, compare the declaration line by line against the current technical documentation and the version actually deployed.
Logs kept but out of reach
Article 16 requires providers to keep logs, and Article 21 requires them to give a competent authority access to logs under their control on reasoned request. Logs often sit in a vendor-managed tool, a rotating buffer or a team account nobody can export from. Confirm where each log stream lands, who can retrieve it, how long it is kept, and whether an authority request can be answered within a set internal deadline.
Accessibility evidence missing
Article 16(l) requires high-risk systems to meet the accessibility requirements of Directives (EU) 2016/2102 and (EU) 2019/882. Teams often assume accessibility belongs to the user interface team and never record how it was tested. Keep dated test results, the standard version used, the open defects and the owner of each fix so the evidence can be shown to an assessor.
No corrective action trail
When a high-risk system is non-conforming or presents a risk, the provider must take corrective action, and Article 16 expects that trail to be demonstrable. Fixes are often made in a ticket or a chat thread without a link to the original finding, the affected versions or the notification decision. Use one record per finding that links the root cause, the change, the verification test and any authority or customer notice.
Rebranding turns deployers into providers
Under Article 25(1), a distributor, importer, deployer or other third party becomes the provider with all Article 16 obligations if it rebrands a high-risk system, substantially modifies it, or changes its intended purpose so that it becomes high-risk. A business unit that white-labels a vendor tool or repurposes a model for hiring decisions can take on these duties without anyone updating the compliance plan. Review every rebrand, modification and new use case against Article 25 before launch.
Questions providers ask about Article 16
What does meeting Article 16 cost, and what drives the cost?
Cost depends mainly on how many high-risk systems you operate, how much documentation and evidence already exists, and whether a notified body is involved. Article 16 sets 12 provider obligations, and most of them create ongoing work, such as keeping logs, maintaining the quality management system, monitoring the system after launch and answering authority requests. The main cost lines are internal staff time from engineering, legal, risk and product teams, any consultants or implementation partners you pay for preparation and tooling, and assessment fees where a notified body applies. Ask every bidder for a written scope that separates one-time setup from recurring operations, names who performs each deliverable, and lists the evidence you will receive. Confirm each cost line against your own environment before you commit budget.
How long does Article 16 work take and what sets the timeline?
The timeline is set by the application dates and by how far your systems are from conformity, not by a fixed duration. Under the 2026 amendment, the high-risk rules apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I product systems. Article 16(f) requires the conformity assessment under Article 43 to be completed before a system is placed on the market or put into service, so that step sits on the critical path. Other drivers include how many systems are in scope, whether a quality management system and technical documentation already exist, how long logs and testing take to produce usable evidence, and whether a notified body's schedule applies. Plan backward from your planned market entry date and ask any partner for a written plan with milestones tied to those dates.
Can an internal team handle Article 16 without an outside partner?
Yes, an internal team can meet Article 16 if it has the people, time and skills to build and maintain the evidence. Most Annex III systems follow an internal-control route under Annex VI, in which the provider carries out the conformity assessment itself. The obligations cut across engineering, security, legal, quality and product, so each one needs a named owner for the quality management system, documentation, logging, post-market monitoring and incident handling. Outside help usually fills specific gaps, such as a first readiness review, logging and access control on self-hosted infrastructure, evidence collection, or an independent check before an assessment. Be clear about accountability: the organization owns its controls and its declaration of conformity, while an implementation partner prepares systems and evidence. Only an independent auditor or certification body issues reports or certificates where one applies.
Does every high-risk AI system need a notified body?
No. Most Annex III high-risk systems use internal control under Annex VI, so the provider carries out the conformity assessment itself. Notified bodies are involved for some biometric systems and for Annex I products, under the routes set out in Article 43. Which route applies depends on the category your system falls into, so settle that classification before you plan budget or schedule. If a notified body is required, its assessment adds cost and time that the internal route does not, and its availability sits outside your control, so raise it early with your team. Confirm the route against Article 43 and your own classification with counsel or an assessor, and read the regulation directly in the EUR-Lex text of Regulation (EU) 2024/1689.
What does the work need from our teams and leadership?
The work needs named owners, access to real system data and logs, and time from the people who build and operate the system. Because Article 16 covers 12 obligations, the first requirement is one accountable owner for each, including quality management, technical documentation, logging, conformity assessment, the EU declaration of conformity, registration, corrective action and accessibility. Engineering must make logs and test results retainable and producible to a competent authority on reasoned request. Legal and compliance must confirm scope, classification and supplier contract terms. Leadership should approve the scope, fund the recurring work and decide who signs the declaration. Assign someone to track harmonised standards such as EN 18286:2026 as they are applied, since they shape how the quality management system is evidenced.
When does a deployer become a provider under Article 25(1)?
A deployer, importer, distributor or other third party becomes the provider of a high-risk system when it rebrands the system, substantially modifies it, or changes its intended purpose so that it becomes high-risk. From that point it carries all Article 16 obligations, including the quality management system, documentation, conformity assessment and CE marking. Common triggers include putting your name on a vendor's system, adapting it for a new use case, or changing its intended purpose in a way that makes it high-risk. Review every change to a third-party system against these triggers before you deploy it. Supplier contracts should state who holds the documentation and who performs the assessment, so the change in role is planned before launch. Confirm the boundary for your specific case with counsel.
What part of Article 16 can an implementation partner take on?
An implementation partner can prepare the systems, controls and evidence that Article 16 requires, while the organization keeps ownership of the controls and of every declaration. DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms in your own cloud accounts, data centers or air-gapped networks, which is where much of the logging, access control and documentation evidence is produced. Typical scoped work includes a readiness review against the 12 obligations, a documentation and record-keeping structure, log configuration and retention on infrastructure you control, and evidence packs for an assessor. DeployOpen does not issue audit reports, attestations, certifications or the declaration of conformity. Engagements are fixed-scope, so the written scope should list each deliverable before work starts.
How DeployOpen prepares Article 16 evidence
DeployOpen prepares the systems, records and test results that a provider of a high-risk AI system needs for its Article 16 obligations, but the provider stays responsible for every obligation and for the decisions behind them. Work starts from a fixed scope agreed in writing, which names the high-risk system, the obligations in scope, the deliverables and the timeline before any engineering begins. DeployOpen does not issue audit reports, attestations, declarations of conformity or certificates. The EU declaration of conformity and CE marking are the provider's own acts, and conformity assessment is carried out by the route that applies to the system, whether internal control or a notified body. A quote follows from the written scope, so the reader should expect pricing to depend on how many systems, obligations and environments are included.
In practice, the work sits on the client's own infrastructure: their cloud accounts, data centers or air-gapped networks. DeployOpen can configure the logging pipeline for the system so that the logs the provider controls are retained and can be produced to an authority, set up a document control workflow that records every change to the technical documentation, and build the test harness used to demonstrate conformity. Test evidence, including records from the testing of the system against its requirements, is kept in a form the provider's assessor can inspect. Confirm with your own assessor which artifacts they will accept and in what format before the build starts, because a log export that the auditor cannot read is no evidence at all.
Support for the independent assessment is the last step. DeployOpen can assemble the evidence index that maps each Article 16 obligation to the artifact that shows it, walk the assessor's team through the systems, and answer follow-up requests on configuration. Ongoing work such as upgrades, continuous testing and log retention checks can be covered by a separate retainer, which the provider should scope so that it matches the post-market monitoring and corrective action duties that continue after launch.
