High-Risk Provider (EU)

Art.16(a) is the entry the inventory gains: compliance with the whole of Chapter III Section 2, Arts. 9 to 15, as one obligation binding the organisation directly rather than reaching it through a customer contract, with its own application dates of 2 December 2027 for an Annex III system and 2 August 2028 for an Annex I system and 2 August 2030 for a legacy system used by a public authority (ADR-025). Art.22 is a second entry that bites only where the provider is established outside the Union and the inventory is where that determination is recorded as owned before AIG-041 acts on it.

On the base the reason for this control is the provider seat: a customer's supervisor reaches the organisation through the customer's contract. Art.21 removes the intermediary. A competent authority addresses a reasoned request to the provider itself and is owed the information and documentation demonstrating conformity with Section 2, in an official Union language the Member State indicates, plus access to the Art.12(1) logs the provider controls. The register this control keeps therefore holds requests with no customer in them and the committed response period is measured against a counterparty that needs no contract to ask. The reason code moves from role-duty to risk-class-duty for that reason. AIG-043 holds the case record and the conformity evidence; GOV-028 holds the route, the named owner and the review that no customer term obstructs the access.

Customer-held keys are a commitment of a hosted service.

Location transparency is a commitment of a hosted service to its tenants.

Export and portability are commitments of a hosted service to its tenants.

Exit is executed by the provider on the customer's behalf, because the customer cannot run the transition on infrastructure it does not control.

Retrieval interfaces and the information needed to stand the service up elsewhere are commitments of a hosted service to its tenants, on the same footing as the export capability in DAT-023.

Tenant isolation exists because the product is cloud-hosted and shared.

Art.16(e) makes the provider keep the automatically generated logs of its high-risk systems where they are under its control and routes the period to Art.19, whose floor is six months. That is a floor and not a retention schedule: the control's documented periods stand and what the article adds is that a shorter period cannot be contracted or configured away and that the logs in question are the Art.12(1) AI event logs AIG-020 produces, which have to stay retrievable for the access Art.21 lets a competent authority demand.

The service level objective and the status channel are commitments of a hosted service.

Art.25(4) reaches a general vendor contract wherever what the vendor supplies is used in or integrated into a high-risk system: the contract has to carry the information, capabilities, technical access and other assistance the high-risk provider needs to comply, which is a positive duty owed by the supplier and not one of the security, audit and exit clauses this control enumerates. AIG-032 holds the AI-specific assessment and the agreement with an AI provider; the row here exists because a component or service contract signed by procurement, with no AI review in front of it, can be the Art.25(4) agreement and usually lacks the clause.

The shared responsibility matrix exists because the customer's workload runs on the provider's service.

Requests for customer data reach the provider because it hosts the tenant's data.

A hosted service has customers whose data it holds, so the terms on which a customer leaves and the terms a regulation makes compulsory for that data are commitments of the service rather than internal practice.

A customer scoping its own controls over a workload it does not run needs a stated route to inspect the provider. VND-011 publishes the boundary; this states the access across it.

The chain behind a multi-tenant service is invisible to the customer unless it is disclosed, and a change to it lands on the customer's workload without the customer touching anything.

The register this control keeps gains an EU AI Act entry that runs alongside the GDPR 72-hour clock and is measured from a different moment. The Art.73 deadlines are stated once, on the AIG-021 row; what this row adds is the trigger. Art.26(5) is why the deployer sits inside the provider's clock: awareness at the deployer starts the period the provider reports on, so the register entry names the deployer notification route as part of the trigger. AIG-021 defines what counts as serious and holds the incident record.

The contact list gains entries the base does not produce: the market surveillance authority of each Member State the system is made available in, because Art.20 informs them where the system presents a risk within the meaning of Art.79(1) and Art.73 reports serious incidents to the ones where the incident occurred. The notified body involved in the conformity assessment, which Art.73 brings into the investigation and which Art.22 requires an authorised representative to inform on terminating its mandate. The distributors, deployers, importers and authorised representative Art.20 names belong on the same list, because the corrective action message reaches them on the same trigger.

Art.6(4) makes the exemption assessment a document rather than a field: a provider who considers an Annex III system is not high-risk documents that assessment before the system is placed on the market and produces it to a national competent authority on request. Art.49(1) adds a counterparty and a clock the inventory has to carry, registration of the provider and the system in the EU database under Art.71 before an Annex III system is placed on the market or put into service, Annex III point 2 excepted. Art.49(2) requires the same registration for the system the provider concluded is exempt, so the exemption route ends in a public entry rather than in silence. Annex VIII fixes the content of both, with the Regulation (EU) 2026/1744 deletion of section B points 7 and 9 shortening the exempt-system entry (ADR-025).

Art.9(1) makes the process a risk management system established, implemented, documented and maintained across the entire lifecycle, which is a standing system rather than an assessment repeated on a cycle. It is the artefact Art.11 and Annex IV expose to an authority. Art.9(2) fixes what it identifies, known and reasonably foreseeable risks to health, safety and fundamental rights under intended use and under reasonably foreseeable misuse, with post-market monitoring data as a named input. Art.9(3) bounds it to risks that design, development or adequate technical information can reasonably mitigate, so a risk parked as the deployer's problem needs that information supplied under Art.13. Art.9(5) requires each hazard's residual risk and the overall residual risk to be judged acceptable, with design-level elimination taken before mitigation and before informational controls, which is stronger than an accountable owner's acceptance. The Art.9(9) vulnerable-groups consideration sits on AIG-006.

Art.9(9) gives the vulnerable-groups limb a legal object and a home: the provider considers, in view of the intended purpose, whether the system is likely to have an adverse impact on persons under the age of 18 and, as appropriate, other vulnerable groups. That consideration is part of the risk management system rather than a separate exercise, so it is read inside the Art.11 documentation. The deployer's Art.27 fundamental rights impact assessment stays out of this seat and is recorded not-applicable on the base.

Art.9(6) and (8) fix what the gate measures against: testing throughout development and in any event before the system is placed on the market or put into service, against pre-defined metrics and probabilistic thresholds, to identify the risk management measures and to verify compliance with Section 2. The threshold is therefore set before the test rather than read off it. Art.60 adds a second regime where the testing runs in real-world conditions outside a regulatory sandbox and it is a permission rather than a practice: a real-world testing plan submitted to the market surveillance authority of the Member State the testing runs in, that authority's approval, with tacit approval after 30 days only where national law provides for it, registration under a Union-wide single identification number with the Annex IX information and a provider established in the Union or holding a legal representative who is.

Art.43(4) attaches an external consequence to the substantial-modification definition this control already carries: the conformity assessment is repeated whether or not the system is distributed further or continues in service. The definition and its worked examples are therefore the trigger for a procedure outside the organisation and not only for the internal pre-deployment checks. Changes predetermined and documented in the initial assessment for a continuously learning system are outside it, which is what makes writing them down at first assessment pay. AIG-037 holds the repeated assessment and the reissued declaration.

Art.10(1) makes the quality criteria a condition of development rather than a target and Art.10(3) and (4) state them as a testable standard: the training, validation and testing sets are relevant, sufficiently representative and, to the best extent possible, free of errors and complete in view of the intended purpose, with appropriate statistical properties for the affected persons or groups and an account of the geographical, contextual, behavioural or functional characteristics of the setting the system is used in. Art.10(2) adds the documented content, the collection processes and origins, the preparation operations, the assumptions about what the data represents and the bias examination. That last item makes the setting of the system, not only the data, something the validation record has to name.

Art.10(2) makes the collection processes and the origin of each dataset content of the documented data governance for a high-risk system, so the provenance record is read as part of the Annex IV technical documentation and is retained with it for the Art.18(1) ten years after the system is placed on the market, which is longer than the control's own floor of as long as the models are in use.

New Art.4a(1), inserted by Regulation (EU) 2026/1744, is what makes the bias-detection case usable and what it costs. Special categories may be processed only to the extent strictly necessary for bias detection and correction under Art.10(2), points (f) and (g), only where the same result cannot be reached by processing other data including synthetic or anonymised data and only under technical limitations on re-use with state-of-the-art security and privacy-preserving measures. The screening record therefore carries a finding the GDPR basis does not supply on its own, that no less intrusive dataset would have worked. The dataset held solely for bias correction is the one Art.4a(1) is about.

Art.11(1) fixes the artefact and its moment: the technical documentation is drawn up before the system is placed on the market or put into service, kept up to date and contains at minimum the Annex IV elements, so version correspondence is a condition of lawful placing and not a documentation habit. Art.72(3) puts the post-market monitoring plan inside that Annex IV documentation, with a Commission template due by 2 September 2027 (ADR-025), so the plan AIG-018 writes is versioned and produced with this documentation. Art.18(1) sets the retention at 10 years after the system is placed on the market or put into service, covering the technical documentation, the quality management system documentation, the documents and decisions of the notified body and the EU declaration of conformity. One thing here is a relief rather than a duty and is not a row of its own: the Art.11(1) second subparagraph as amended lets an SME, a start-up or a small mid-cap give the Annex IV elements in the Commission's simplified form, requires that form to be used where the option is taken and requires notified bodies to accept it (extract row EU-AI-Art.11.2).

Art.50 disclosure binds every provider of an interacting or generating system, whatever its risk class.

Art.13(3) names the explainability capabilities as mandatory content of the instructions for use, which gives this documentation a fixed audience and a fixed home: it is written for the deployer, inside the instructions, next to the performance metrics and the guidance on interpreting outputs. Art.13(1) is the standard the result is judged against, operation transparent enough for the deployer to interpret an output and use it appropriately. Where explanation is not technically feasible, the recorded limitation is what the instructions have to state rather than something held internally.

Art.72 makes post-market monitoring a documented system proportionate to the technology and the risk, actively and systematically collecting and analysing performance data supplied by deployers or drawn from other sources across the system's whole lifetime. It fixes the question the data answers: whether the system still complies with the Chapter III Section 2 requirements, not only whether it still performs. Where relevant the analysis reaches the interaction with other AI systems. Art.72(3) makes the plan part of the Annex IV technical documentation, so it is an artefact produced to an authority alongside AIG-015 rather than an internal runbook. A Commission template for it is due by 2 September 2027 (ADR-025).

Art.12(1) and (2) make logging a design property of the system rather than an operational practice: the system technically allows the automatic recording of events over its lifetime, at a granularity that serves the identification of risk situations and substantial modifications, post-market monitoring and the deployer's monitoring of operation. Art.16(e) keeps the provider responsible for the logs under its control and Art.21 is what they are produced under. For a remote biometric identification system under Annex III, point 1(a), Art.12(3) fixes the fields rather than leaving them to design, the start and end date and time of each use, the reference database used, the input data that led to a match and the identification of the natural persons who verified the results (extract row EU-AI-Art.12.2). Retention is MON-003.

Art.73 supplies the counterparty and the deadlines this control leaves to applicable law. A serious incident goes to the market surveillance authorities of the Member States where it occurred, immediately once the provider has established a causal link with the system or the reasonable likelihood of one and in any event within 15 days of the provider or the deployer becoming aware, cut to two days for a widespread infringement or a serious incident in the Art.3(49)(b) sense and to 10 days where a person has died. An incomplete initial report followed by a complete one is allowed where that is what makes the deadline. The clause barring an investigation that alters the system before the authority is informed is Art.73 as well and the investigation, its risk assessment and the corrective action are owed without delay after the report, with the notified body brought in where relevant.

Art.14(1) and (3) move oversight upstream from an operating procedure to a design obligation: the system is designed and developed, human-machine interface tools included, so that natural persons can effectively oversee it while it is in use, with the measures commensurate with the risks, the level of autonomy and the context. The oversight design is therefore drawn before the system is placed on the market and travels with it and Art.14(4) fixes the capabilities it has to deliver to the person holding oversight. For remote biometric identification under Annex III, point 1(a), Art.14(5) requires that no action or decision is taken on an identification result unless at least two natural persons with the necessary competence, training and authority have separately verified and confirmed it (extract row EU-AI-Art.14.3); the deployer performs that verification and the provider designs the system so it can be performed.

Art.14(4) names the stop mechanism as one of the capabilities the system provides to the oversight person, intervening or interrupting operation and bringing the system to a safe state, which puts the mechanism inside what is examined for conformity rather than in operational readiness. Art.15(4) supplies the other half, resilience to errors, faults and inconsistencies with technical and organisational measures that may include redundancy and fail-safe mechanisms, plus minimisation of biased feedback loops where the system keeps learning after deployment. So the safe state has to be defined and reachable and not only the control present.

Art.5 binds every provider, whatever the risk class of its other systems.

Art.10(2), points (f) and (g), are the source: the datasets are examined in view of possible biases likely to affect health, safety or fundamental rights or to lead to prohibited discrimination. Appropriate measures to detect, prevent and mitigate those biases are taken. That places the fairness objective, its metric and its threshold inside the data governance an authority reads under Art.11, so they are evidence against Art.10 rather than an internal quality measure. It names the axis the evaluation is disaggregated on. The lawful route to the special categories such an evaluation needs is new Art.4a(1), whose conditions are on AIG-014.

Art.15(5) names the attack classes the evaluation has to reach, data poisoning, model poisoning, adversarial examples, confidentiality attacks and model flaws. It states the standard as the system's resilience against attempts by unauthorised third parties to alter its use, outputs or performance. The measured thing is the resilience and not the existence of a test, so a result that records only that an evaluation ran does not answer it.

Art.15(1) requires an appropriate level of accuracy achieved by design and held consistently across the lifecycle and Art.13(3) requires the accuracy level and the metrics it was measured against to be stated in the instructions for use. Between them they turn the confidence threshold and the calibration result from an internal tuning parameter into a declared figure a deployer relies on and an authority can test the system against, which is also why a threshold changed after a model update has to move in the instructions.

Art.15(1) holds a generative accuracy claim to the same consistency standard as any other performance property and Art.13(3) requires the performance metrics and the known foreseeable risks to health, safety and fundamental rights to be given to the deployer in the instructions for use. The measured hallucination rate and the threshold it is judged against therefore leave the organisation with the product. Neither article fixes a rate, which is why both mappings stay partial and why the documented threshold remains the provider's to set and to defend.

Art.15(5) reaches prompt injection through the model flaws it names and through the alteration of the system's use and outputs it prohibits, so the direct and indirect injection tests become evidence for a Section 2 requirement rather than application security housekeeping. The mapping stays partial because Art.15(5) states the resilience and not the two injection paths, the privilege separation or the sandbox, so a conformity file that cites this control has to show the test results and not the article.

Art.9(2) requires the risk management system to estimate risk under reasonably foreseeable misuse as well as intended use, which is the question the foreseeability assessment in this control answers. It makes that assessment an input to Art.9 rather than a safety-team artefact. Art.15(5) covers the misuse that alters the system's use, outputs or performance, so the detection and response stack is measured as resilience. The Art.5(1)(ba) and (bb) safeguards are a prohibition binding whatever the risk class and apply from 2 December 2026 (ADR-025), ahead of the Chapter III dates.

Art.25(4) makes the supplier agreement compulsory and fixes its object: a third party supplying an AI system, model, tools, services, components or processes that are used in or integrated into a high-risk system specifies by written agreement the information, capabilities, technical access and other assistance, on the generally acknowledged state of the art, that the high-risk provider needs to meet its own obligations. A tool, service, process or component made publicly available under a free and open-source licence is outside it, general-purpose models excepted. Art.25(1) runs the other way and is what the integrator clause has to anticipate: a distributor, importer, deployer or other third party that puts its name or trade mark on the system, modifies it substantially, or changes a non-high-risk system's intended purpose so that it becomes high-risk, is considered the provider and takes the Art.16 obligations with it.

Art.13(2) and (3) turn the instructions for use into a regulated document with a fixed minimum content: an appropriate digital or other format, concise, complete, correct, clear, relevant, accessible and comprehensible to deployers, carrying the provider identity and contact details, the capabilities, limitations and performance metrics including the accuracy, robustness and cybersecurity levels, the known foreseeable risks, the explainability capabilities, performance on specific persons or groups where relevant, the input data specifications, the guidance for interpreting outputs, the human oversight measures, the compute and hardware requirements, the expected lifetime and maintenance and the log collection guidance. Art.16(b) fixes the identification marking, the provider's name, registered trade name or trade mark and a contact address, shown on the system, its packaging or the accompanying documentation. The Art.25(1) clause that decides when an integrator becomes the provider is on AIG-032.

The base makes this conditional on the risk class. Here the class is settled by the profile's facets, so the quality management system is a standing duty: Art.16(c) and Art.17(1) require it in writing as policies, procedures and instructions covering the elements Art.17 lists. The conformity assessment route and the handling of modifications are two of them. Art.17(2) as amended by Regulation (EU) 2026/1744 makes implementation proportionate to the size of the organisation, in particular for an SME, a start-up or a small mid-cap, while requiring the same degree of rigour and level of protection compliance needs. That proportionality reaches how an element is implemented, not which elements exist.

The base makes this conditional on the risk class. Here the class is settled by the profile's facets, so conformity assessment is a standing duty and the only open question is the route, which turns on which limb of Art.6 the system sits under. A safety component of a product covered by an Annex I instrument is assessed under that product's own conformity assessment procedure with the Section 2 requirements folded into it (Art.43(3)), so there is no separate AI procedure and the body involved is the one that instrument names. An Annex III system runs internal control under Annex VI and for points 2 to 8 Art.43(2) makes that the whole of it, with no notified body. Art.43(1) singles out Annex III point 1 biometrics: internal control under Annex VI is available where harmonised standards or common specifications have been applied. A quality management system assessment under Annex VII with a notified body is the route where they have not. Art.43(4) repeats the assessment on a substantial modification whether or not the system is distributed further. Art.47 requires a written, machine-readable EU declaration of conformity per system, identifying the system, stating that it meets Section 2, carrying the Annex V information, translated for the competent authorities of each Member State it is placed on the market in, kept up to date and kept at their disposal for 10 years, with a single declaration where other Union harmonisation legislation also requires one. Art.48 requires the CE marking, affixed visibly, legibly and indelibly or on the packaging or accompanying documentation where the system does not allow it, in digital form for a digitally provided system only where it is reachable from the interface or through a machine-readable code, followed by the notified body's identification number where one was involved and repeated in any promotional material claiming CE conformity. AIG-009 holds the internal side of a substantial modification.

The provider is also a user of AI systems, including the models beneath its product. The use register covers both.

The statement on customer data in training and the opt-out are the provider's to give.

The base makes this conditional on the risk class. Here the class is settled by the profile's facets. Art.20 fixes the trigger at the point the provider considers or has reason to consider a system it placed on the market is not in conformity, requires the corrective action immediately and names who is told, the distributors and, where applicable, the deployers, the authorised representative and the importers; where the system presents a risk within the meaning of Art.79(1) the market surveillance authorities of the Member States where it was made available are told as well. Art.21 fixes the content of the answer to a reasoned request: all the information and documentation needed to demonstrate conformity with Section 2, in an official Union language the Member State concerned indicates, plus access to the Art.12(1) automatically generated logs to the extent they are under the provider's control, with what the authority receives held under the Art.78 confidentiality obligations. The language requirement is the item most often missed, because it makes a conformity file a translation problem. The Art.53(3) arm for general-purpose model providers stays with gpai-model-provider.

Any organisation that trains, fine-tunes or evaluates a production model runs the pipeline this control secures. A provider that only calls a third-party model records that no pipeline exists against the inventory entry.

Required, as the library states every control whose trigger is a feature set rather than a facet (DAT-018, AIG-014, AIG-042, AIG-056): the documented assessment the control opens with is the first artefact. It bites where a system relies on user-supplied or external audio, image or video as evidence of a person's identity, of the provenance of an artefact or of a real-world event, which is a live case for identity verification, onboarding, claims and content-moderation features. An organisation whose assessment finds no such intake point records that finding and the detection limb has nothing to attach to. Restated from recommended on the S13 benchmark (ADR-049 amendment, 2026-09-16).

Art.4 as replaced by Regulation (EU) 2026/1744 binds providers and deployers whatever the risk class, so it is live ahead of the Art.113 dates. It is a duty to take measures supporting AI literacy rather than to guarantee any level of it in an individual (ADR-025), which is why the evidence is the standard and its delivery rather than a test score. What the high-risk seat adds is a competence standard with a named object: Art.14(4) requires the persons assigned oversight to understand the system's capacities and limits, monitor for anomalies, stay aware of automation bias, interpret the output correctly and decide not to use the system or to override it. Art.14(5) requires the two verifiers of a remote biometric identification to hold the necessary competence, training and authority. The training standard therefore needs a group defined per system and not only per role band.

Condition: the organisation is established outside the Union

The base condition carries the risk class and the establishment together. Here the class is settled by the profile's facets, so establishment is all that is left to test. Art.22 requires a provider established in a third country to appoint an authorised representative established in the Union by written mandate before the system is made available on the Union market. It fixes the mandate's contents rather than leaving them to the parties: verifying that the Art.47 declaration and the Art.11 technical documentation have been drawn up and an appropriate conformity assessment carried out; keeping the provider's contact details, a copy of the declaration, the technical documentation and any notified body certificate at the disposal of the competent authorities for 10 years after the system is placed on the market; answering a reasoned request with the information demonstrating conformity and with access to the Art.12(1) logs; cooperating with authorities; and complying with the Art.49(1) registration where it applies. The representative terminates the mandate where it has reason to consider the provider is acting contrary to the Regulation and informs the market surveillance authority and any notified body immediately, which is a counterparty that can walk away. The Art.54 arm for general-purpose model providers stays with gpai-model-provider.

Worker notification before a system is put into use at a workplace is an employer's duty under Art.26(7). A provider placing the system on the market owes it for its own workforce only where it is also the deployer, which is the enterprise-ai-deployer seat.

Registration by the organisation using the system is a deployer duty under Art.49(3). The provider registration of Art.49(1) and (2) sits on AIG-003 and is required of this profile there.

The fundamental rights impact assessment of Art.27 is owed by the deployer about the use it makes of the system. A provider's duty is to supply the information the assessment draws on, which AIG-034 carries.

Documentation of a general-purpose model as such is the gpai-provider seat (gpai-model-provider, ADR-046). A SaaS provider documents its product under AIG-015 and, where it also trains and offers a general-purpose model, holds the gpai-provider role and that profile alongside this one.

The public training content summary is the gpai-provider seat (ADR-046). A provider that fine-tunes a third-party model for its product records provenance under AIG-013 and is not the models provider.

The copyright policy and crawler conduct of a general-purpose model provider are the gpai-provider seat (ADR-046). A SaaS providers own licensed assets and training data licences are GOV-015 and AIG-013.

Systemic risk at Union level attaches to a designated general-purpose model and its provider (ADR-046). Risk from the systems a SaaS provider builds is AIG-005.

Evaluation under standardised protocols attaches to a designated general-purpose model (ADR-046). A SaaS provider evaluates the systems it operates under AIG-026 and AIG-008.

Protection of a designated models weights to a stated security goal is the gpai-provider seat (ADR-046). A SaaS providers development assets and training pipeline are IAM-014 and AIG-055.

Reporting to the AI Office about a designated model is the gpai-provider seat (ADR-046). A SaaS provider reports a systems serious incident to the competent authority under AIG-021.

The safety and security model report is the gpai-provider seat (ADR-046) and is recommended rather than required even there.