You use or develop AI.What is your company responsible for?

Article 25(1) covers these situations for systems already placed on the market or put into service:

• Your name or trademark on a high-risk system: 25(1)(a). The article leaves room for contractual arrangements allocating the obligations differently.
• A substantial modification of a high-risk system that remains high-risk: 25(1)(b). Configuration or integration does not automatically amount to substantial modification.
• Changing the intended purpose of a system previously not considered high-risk so that it becomes high-risk under Article 6: 25(1)(c). Following the instructions of a tool already intended for recruitment does not itself establish that change.

These situations bring the provider obligations in Article 16. Article 25(3) also covers manufacturers of products in Annex I, Section A, where a high-risk system is a safety component: when they place it on the market with the product under their name or trademark, or put it into service under their name or trademark after marketing the product.

Gather the original offer and instructions, describe the change and identify who decided it. Article 25(2), amended in 2026, governs the initial provider’s cooperation through relevant information, documentation and technical access. That obligation does not apply if the provider clearly specified that its system should not become high-risk. Article 25(4) provides for written agreements on information, capabilities, access and assistance with parties supplying systems, models or components; it excepts publicly accessible open-source contributions, other than GPAI models. These provisions do not grant unconditional access to all of a supplier’s materials.

The example concerns the provider of the system using general-purpose AI. It does not automatically make the company a provider of the GPAI model. Building your own system from a model also requires checking the provider definition in Article 3. Processing CV data remains subject to applicable law, including the GDPR.

Sources: Article 25 of the consolidated Act, the 2026 amendment, Article 1(12), and Commission guidance on GPAI models and systems.

Article 17 requires a quality management system. EN 18286 is a reference for organising that framework; standards applicable to Articles 9–15 address other system requirements. Implementing and documenting them requires quality and engineering to work together throughout development and subsequent changes.

Standards are voluntary. Presumption of conformity means that complying with a harmonised standard cited in the Official Journal of the EU allows conformity to be presumed for the requirements it covers. It does not establish conformity of the whole system or extend EN 18286 automatically to Articles 9–15. Check each standard’s recorded status.

For systems subject to the Chapter III requirements, the engineering work and its evidence need to support the following areas. Product legislation and the coordination rules in Article 2 must also be considered.

• Article 9 — risk management. Identify and evaluate risks, select treatments and test their effectiveness throughout the lifecycle.
• Article 10 — data and data governance. Record how training, validation and test data are prepared and assessed, including relevant properties and possible biases.
• Article 11 — technical documentation. Describe the system and provide the information needed to assess its requirements. Annex IV specifies the content; a description alone does not supply the supporting evidence.
• Article 12 — logging. Build the capability to record relevant events during operation and keep those records attributable to the evaluated system.
• Article 13 — information for deployers. Explain capabilities, limitations and instructions for use. This is distinct from Article 50’s obligation to inform people that they are interacting with AI.
• Article 14 — human oversight. Define who can interpret, intervene or stop the system, and provide the means to do so.
• Article 15 — accuracy, robustness and cybersecurity. Establish relevant performance levels and assess failures and threats across the lifecycle.
• Article 17 — quality management. Set the procedures, responsibilities and controls that sustain this work.

These are the technical and management requirements in the standards map. Providers also need to establish the conformity assessment, declaration, marking and registration obligations that apply to their system. A high-risk classification does not show that any of those obligations have been met.

For the binding requirements, consult Chapter III of the AI Act together with its amendments. Our coverage page identifies the clauses Froga evaluates and the limits of that coverage.

Post-market monitoring, corrective measures and applicable cooperation with authorities also need to be organised. Capabilities, limitations and instructions go to the deployer; observations and incidents from use support subsequent action.

The provider declares the classification. A tool does not take over that responsibility or turn an unchecked declaration into evidence of conformity.

Article 26 requires deployers to organise the use of the high-risk systems it covers. These are organisational responsibilities; quality needs to coordinate the relevant functions, without taking on every task alone.

• Instructions and oversight. Apply technical and organisational measures to use the system according to its instructions; assign oversight to people with competence, training, authority and support.
• Input data. Where you control the inputs, ensure that they are relevant and sufficiently representative for the intended purpose.
• Monitoring and response. Monitor operation according to the instructions. Where there is reason to consider that use may present a risk under Article 79(1), promptly inform the provider or distributor and the market surveillance authority, and suspend use. Serious incidents have specific reporting duties.
• Logs. Keep automatically generated logs under your control for a period appropriate to the purpose and at least six months, unless other applicable law provides otherwise.
• Information for people. Before workplace use, inform workers’ representatives and affected workers. For Annex III systems that make or support decisions about people, inform them that they are subject to that use, with the applicable exceptions.
• Further checks for particular uses. Public bodies and those acting on their behalf must address Article 49 registration. Public authorities and EU institutions, bodies, offices or agencies must not use an unregistered system and must inform the provider or distributor: Article 26(8). Provider information also supports a data protection impact assessment where required. Remote biometric identification has specific conditions; duties to cooperate with authorities remain.

The provider’s documentation does not replace your decisions about use. Connect the information you receive to the actual conditions in your organisation and communicate relevant incidents.

Source: Article 26 of the consolidated Act.

A FRIA is a fundamental rights impact assessment. It examines how a use may affect people and the measures taken to address those effects. Article 27 requires it before first deployment for certain Annex III systems:

• For bodies governed by public law and private entities providing public services.
• For deployers of creditworthiness assessment and risk assessment or pricing for life and health insurance under points 5(b) and 5(c).

It is not required of every deployer, and Annex III point 2 is excluded. Check the organisation and the specific use.

The assessment describes the process, duration and frequency of use, affected people and groups, specific risks, oversight and response measures, including complaint mechanisms. It must be updated if relevant elements change and notified to the market surveillance authority as Article 27 requires.

The 2026 amendment allows references to, or relevant parts of, a data protection impact assessment. The two assessments are not equivalent: complete what the fundamental rights analysis requires.

Sources: Article 27 and the 2026 amendment, Article 1(13).

• Intended purpose. What we will use AI for, whom it affects and which decisions it influences. Gather the original system’s offer and instructions.
• Functionality. What it evaluates, recommends or changes from the previous use; whether it changes classification or our role, including under Article 25.
• Commitments. What we offer customers or add to our service, what we need to prepare and what evidence supports it.

The conversation with quality should establish what to check, who needs to take part and what is missing before putting that use into operation. This applies both to a new offering and to adopting or extending another provider’s solution.