What technical documentation does the AI Act require (Article 11)?

retail and consumer

Webshop builds its own consumer credit check: what belongs in the file

A non-food retail chain lets customers pay later in its webshop and decides at checkout whether a consumer qualifies. The team builds that assessment system in house, on top of a pre-trained model supplied by a vendor. The question is what has to be on record before the feature goes live, and who has to put it there.

Provenance: Article 11(1) requires the technical documentation of a high-risk AI system to be drawn up before that system is placed on the market or put into service, and to be kept up to date. It must be drawn up so as to demonstrate compliance with the requirements of that Section and to give national competent authorities and notified bodies the necessary information, in a clear and comprehensive form, to assess that compliance; it contains at a minimum the elements set out in Annex IV. Annex IV lists those elements as applicable to the AI system concerned, and asks among other things for the methods and steps performed for development, including, where relevant, recourse to pre-trained systems or tools provided by third parties and how those were used, integrated or modified by the provider, for the validation and testing procedures used, and for a description of relevant changes made by the provider to the system through its lifecycle. SMEs, including start-ups, may supply those elements in a simplified manner; where they take that route, they must use the simplified form the Commission is to establish for that purpose.

Article 11 puts the documentation duty on the provider, so the first open question here is who that provider is. If the creditworthiness assessment of consumers counts as high-risk in your situation, then in our reading there is a strong case that a webshop assembling the system itself and putting it into service under its own name is no longer merely a deployer but ends up on the provider side, carrying the documentation duty that comes with it. Article 11 does not settle that allocation of roles, so test it against the definitions and against Article 25 before assuming the file is your vendor's problem. In our reading the hard part in retail is not the first version of the file but the pace afterwards, because a webshop often ships changes per release while the file stays frozen at the state it had when the feature went into service. So contract for the provenance, training and testing information that Annex IV expects from you when you buy the pre-trained model, and assign per release who updates the file.

Editorial example. The rule above is in the Regulation. The situation was written by us to show how that rule plays out in this sector, and is not taken from a worked case in official guidance.

Article 11(1) and Annex IV

retail and consumer

Security monitoring by a SaaS company: cybersecurity alone is not a safety component

A software company supplies a SaaS platform that monitors network traffic at an operator of critical digital infrastructure and reports anomalous patterns to that customer's security team. Its developers see that use at such an operator may fall under point 2 of Annex III and wonder whether their own product therefore becomes a high-risk AI system.

Provenance: The Commission draft guidelines of 19 May 2026 state that point 2 of Annex III lists AI systems intended to be used as safety components in the management and operation of, among other things, critical digital infrastructure, and that Recital 55 draws a clear distinction between a safety component and a cybersecurity component. To fall within point 2, an AI system must not be used solely for cybersecurity purposes; without a direct safety role it cannot be a safety component in critical infrastructure and therefore cannot be classified as high-risk under Article 6(2). As examples of systems used solely for cybersecurity and thus falling outside point 2, they list an AI honeypot that identifies and neutralises cyber threats in real time, technology that actively engages with potential attackers to learn new attack patterns, a system supporting the detection of unauthorised access, and a system that detects suspicious email addresses and identifies stolen data. They add that an AI system is classified as a safety component in critical infrastructure only where it is used by an entity identified as a critical entity by a Member State under the CER Directive, and that this interpretation does not require that status to be disclosed to a third-party provider. The document is a consultation version: non-binding and not yet final.

We read this passage as a line drawn function by function rather than customer by customer: the fact that your client operates critical digital infrastructure does not by itself turn your monitoring product into a safety component. What we cannot settle from the text is where mere flagging ends and a safety function begins, because the same guidelines also count monitoring and detecting situations that may directly lead to physical harm among the safety functions. The open question is therefore whether your SaaS platform stands apart from the systems that drive physical control, or in practice becomes part of them. So record, per product function, what the system performs and what it expressly leaves to the operator, because that distinction carries your entire classification and is hard to reconstruct after the fact.

Draft guidelines on the classification of high-risk AI systems, 19 May 2026, annex on Annex III, paragraphs (187), (188), (190) and (191)

retail and consumer

Two AI systems at one grid operator, two regimes

A grid operator uses an AI model that automatically balances load and disconnects parts of the electricity network to prevent outages. The same organisation also runs a chatbot that helps customers with billing questions.

Provenance: The Commission draft guidelines of 19 May 2026 address this case when determining whether an application falls under Annex III. The document is a consultation version: non-binding and not yet final.

Map your AI function by function rather than organisation-wide, because only systems that directly protect the physical integrity of the infrastructure are safety components, while supportive and customer-facing tools fall outside.

Draft guidelines on high-risk AI classification, 19 May 2026, annex on Annex III

from another sector: recruitment and selection

Candidate recommendation that automatically becomes a decision

An employer uses a system that ranks applicants and recommends a candidate to hire. In one setup a recruiter weighs that recommendation in their own assessment; in the other the outcome is applied automatically and a candidate is rejected without anyone looking at it.

Provenance: The Commission draft guidelines of 19 May 2026 address this case when determining whether an application falls under Annex III. The document is a consultation version: non-binding and not yet final.

Assess a recruitment system on its intended purpose rather than on whether a recruiter reviews the output, because adding or removing human involvement does not change its high-risk classification.

Draft guidelines on high-risk AI classification, 19 May 2026, annex on Annex III

Annex I lists legislation, not products

The draft guidelines of 19 May 2026, published for consultation and expressly non-binding, clarify that Annex I AI Act does not list individual products to be classified as high-risk, but Union harmonisation legislation regulating the safety aspects of certain products. Whether an AI system falls within the scope of Annex I therefore depends on whether the system, or the product of which it is a safety component, falls within the material scope of one of the listed legislative acts. According to the draft guidelines the list in Annex I is exhaustive; products can only be added or removed by amending the scope of the harmonisation legislation itself or by adding new harmonisation legislation to Annex I. The draft guidelines also state that through Article 6(1) the AI Act does not itself extend the scope of harmonisation legislation to new or additional products, and that the AI Act does not determine or change the risk profile of a product but builds on the sectoral risk classification. Products mentioned include machinery, toys, lifts, equipment and protective systems for potentially explosive atmospheres, radio equipment, pressure equipment, recreational craft, cableway installations, appliances burning gaseous fuels, medical devices, in vitro diagnostic medical devices, and products in the automotive and aviation sectors.

Draft guidelines Annex I, points (23) to (26)

Section A and Section B of Annex I trigger different requirement sets

The Commission draft guidelines of 19 May 2026, which are non-binding as long as the final version has not been adopted, draw a distinction that is often missed in practice. AI systems classified as high-risk under Article 6(1) in respect of products covered by the harmonisation legislation in Section A of Annex I are subject to the requirements for high-risk systems in Section 2 of Chapter III AI Act. By contrast, for AI systems classified as high-risk under Article 6(1) in respect of products covered by the harmonisation legislation in Section B of Annex I, only Article 6(1), Articles 102 to 109 and Article 112 AI Act apply. The draft guidelines refer to Article 2(2) AI Act for this. Section A contains harmonisation legislation based on the New Legislative Framework, Section B the other Union harmonisation legislation.

Draft guidelines Annex I, point (60), referring to Article 2(2) AI Act

Two cumulative conditions for high-risk under Annex I

The European Commission draft guidelines of 19 May 2026, which are expressly non-binding and not final, read Article 6(1) as two cumulative conditions. First, the AI system must be intended to be used as a safety component of a product, or the AI system must itself be a product, covered by the Union harmonisation legislation listed in Annex I. Second, that product, or the AI system itself where it is the product, must be required to undergo a third-party conformity assessment. The draft guidelines state explicitly that not all AI systems that are components of regulated products are high-risk, but only the subset that satisfies both criteria.

Draft guidelines Annex I, points (27) and (21)

The Article 6(3) filter: four exhaustive grounds, to be read narrowly

According to the non-binding draft guidelines of 19 May 2026 on the classification of high-risk AI, Article 6(3) sets out four grounds on which a provider may exempt a system from high-risk classification: performing a narrow procedural task, improving the result of a previously completed human activity, detecting decision-making patterns or deviations from prior patterns without replacing or influencing the previously completed human assessment absent proper human review, and performing a preparatory task. Paragraph (88) of this draft states these grounds are exhaustive but alternative, that there is no separate independent risk test, and that they must be interpreted narrowly because Article 6(3) is an exception to rules that among other things protect fundamental rights. Paragraph (87) states the filter applies only to systems under Article 6(2) and not to systems under Article 6(1). Paragraph (89) states a system always remains high-risk where it performs profiling. Paragraph (90) adds that the filter does not apply where the system forms part of a complex system whose combined intended purpose or joint outputs materially influence an individual decision, including agentic AI. Paragraphs (113) to (116) of this draft describe that this is a self-assessment by the provider, that Article 6(4) requires documenting the assessment before placing on the market and registering in the Article 71 EU database, and that the assessment must contain at least the intended purpose, why the system falls under Article 6(2), which Article 6(3) condition applies and why, and why the system does not perform profiling. Paragraph (117) of these draft guidelines points to Articles 80 and 99 where an authority finds a system was misclassified as non high-risk to circumvent the rules.

Draft guidelines on high-risk AI classification (19 May 2026), Annex III chapter, sections 2.7, 2.7.1, 2.7.3 and 2.7.4, paragraphs (84) to (90) and (113) to (117)

prEN 18285: conformity assessment framework for AI systems

prEN 18285 (Conformity assessment framework) is the JTC 21 deliverable under M/613 covering the conformity assessment of high-risk AI systems under Article 43 and Annex VII of the AI Act. As at June 2026 the deliverable was at the drafting stage. It has not yet been published as an EN and is not cited in the Official Journal. Standardisation request M/613 was amended by Implementing Decision C(2025)3871 of 23 June 2025 and expires on 28 February 2027.