Advanced deployer FAQ — EU AI Act + NIS2
22 in-depth answers for organisations that already understand the basics and are working through Article 26 implementation, FRIA scope, Annex IV evidence, vendor management, penalty exposure and the Digital Omnibus timeline. Article numbers reference Regulation (EU) 2024/1689 (EU AI Act) and Directive (EU) 2022/2555 (NIS2).
This page is technical documentation, not legal advice. PowerQuant ApS (CVR 46274067) is a compliance-evidence vendor; for legal interpretation consult qualified counsel.
1. What concretely does Article 26 require from a deployer of a high-risk AI system?
Article 26 sets out the core deployer duties: (a) use the system in accordance with the provider's instructions for use (Art. 26(1)); (b) assign human oversight to natural persons with the necessary competence, training, authority and support (Art. 26(2)); (c) where the deployer controls the input data, ensure it is relevant and sufficiently representative for the intended purpose (Art. 26(4)); (d) monitor operation against the instructions and inform the provider/distributor and the market-surveillance authority where the use presents a risk under Art. 79(1), suspending use without undue delay (Art. 26(5)); (e) keep automatically generated logs to the extent they are under the deployer's control for at least six months unless EU or national law says otherwise (Art. 26(6)); (f) for workplace deployment, inform workers' representatives and affected workers before putting the system into service (Art. 26(7)).
2. Who must conduct a Fundamental Rights Impact Assessment (FRIA) under Article 27?
Three categories of deployers must perform a FRIA before first use of a high-risk AI system listed in Annex III: (i) bodies governed by public law; (ii) private entities providing public services; and (iii) any deployer using AI for creditworthiness evaluation or for risk assessment and pricing in life and health insurance (Annex III, point 5(b) and (c)). The assessment must describe the process the system supports, the period and frequency of use, the categories of natural persons and groups likely to be affected, the specific risks of harm, the human-oversight measures planned, and the actions to be taken if risks materialise — including governance and complaint arrangements. The result is notified to the market-surveillance authority on the AI Office's template, and any GDPR DPIA under Art. 35 GDPR is complemented — not replaced — by the FRIA.
3. What are the AI Act administrative fine tiers under Article 99?
Article 99 sets three ceilings, in each case the higher of a flat amount or a percentage of worldwide annual turnover: (1) up to €35,000,000 or 7% of total worldwide annual turnover for breaches of the prohibited-practice rules in Article 5; (2) up to €15,000,000 or 3% for breaches of most other obligations binding on providers, importers, distributors, deployers, notified bodies and authorised representatives (including Art. 26 deployer duties); (3) up to €7,500,000 or 1% for supplying incorrect, incomplete or misleading information to notified bodies or national competent authorities. For SMEs, including start-ups, the lower of the flat amount or percentage applies (Art. 99(6)).
4. How do NIS2 fines compare to AI Act fines if both apply?
They are independent regimes and can stack. Under NIS2 Article 34, essential entities face administrative fines: essential entities up to at least €10,000,000 (or, if higher, an amount equal to 2% of total worldwide annual turnover of the preceding financial year); important entities up to at least €7,000,000 (or, if higher, 1.4%). Those NIS2 ceilings are entirely separate from the AI Act's own enforcement. The AI Act tiers (Art. 99) — €35M/7%, €15M/3%, €7.5M/1% — apply on top, for the same incident if it triggers both regimes (e.g. a security breach in a high-risk recruitment AI system that is also subject to NIS2 reporting). NIS2 also introduces personal liability for senior management for gross-negligence failures in cyber-governance.
5. When do the deployer obligations actually start to bite?
The framework date is 2 August 2026 — when Chapter III obligations for high-risk systems (including Art. 26 deployer duties and Art. 27 FRIA) were originally set to apply. The Digital Omnibus provisional political agreement of 7 May 2026 proposes pushing stand-alone Annex III high-risk applicability to 2 December 2027, and AI embedded in Annex I regulated products (medical devices, machinery, vehicles, etc.) to 2 August 2028. These changes only take legal effect once the Omnibus is formally adopted and published in the Official Journal — until then 2 August 2026 remains the binding date. Article 5 prohibitions and Article 4 AI-literacy duties have applied since 2 February 2025, and the penalty regime in Chapter XII has applied since 2 August 2025.
6. Do deployer obligations apply outside the EU?
Yes, in two ways. (i) Art. 2(1)(b) covers deployers established or located within the Union. (ii) Art. 2(1)(c) extends the Regulation extraterritorially to providers and deployers established or located outside the Union where the output produced by the AI system is used in the Union. A Norwegian or UK deployer using a high-risk recruitment system to screen candidates for an EU subsidiary is therefore in scope, even though the deployer entity sits outside the EU.
7. Are we a deployer or a provider if we fine-tune or rebrand a vendor's high-risk model?
Article 25(1) reclassifies a deployer (or distributor or importer) as a new provider of the high-risk AI system in three situations: (a) putting your name or trademark on a high-risk system already placed on the market or put into service; (b) making a substantial modification to a high-risk system such that it remains high-risk under Art. 6; or (c) modifying the intended purpose of a non-high-risk AI system so that it becomes high-risk. When that happens, the original provider's obligations transfer to you, and the original provider must cooperate and share the information needed to comply (Art. 25(2)). Fine-tuning a foundation model for a high-risk HR use case is the classic trap here.
8. What is a 'substantial modification' that flips us into provider status?
Art. 3(23) defines substantial modification as a change to an AI system, after its placing on the market or putting into service, that is not foreseen or planned in the initial conformity assessment by the provider and as a result of which the compliance with the high-risk requirements in Chapter III, Section 2 is affected, or that results in a modification to the intended purpose for which the AI system has been assessed. Recital 128 clarifies that retraining within parameters predetermined by the provider is not substantial. Material changes to the training data distribution, output classes, or risk profile typically are.
9. What records of automated logs must we keep, and for how long?
Art. 26(6) requires deployers to keep the logs automatically generated by the high-risk AI system, to the extent those logs are under their control, for a period appropriate to the intended purpose of the system and at least six months — unless other Union or national law (notably GDPR) sets a different period. The logs themselves are defined by Art. 12: traceability across the system's lifecycle that enables identification of situations that may result in a risk under Art. 79(1) or that may lead to a substantial modification, and that facilitates post-market monitoring under Art. 72. For Annex III, point 1 biometric systems Art. 12(3) sets explicit minimum log content (period of use, reference database, input data, persons involved in verification).
10. What instructions for use should we expect from the provider, and what if they are inadequate?
Art. 13 requires providers to supply instructions for use that include the provider's identity and contact details; the characteristics, capabilities and limitations of performance (including intended purpose, accuracy/robustness/cybersecurity levels referred to in Art. 15, foreseeable misuse, performance on persons/groups, input data specifications); changes pre-determined by the provider; human-oversight measures under Art. 14; computational and hardware resources, expected lifetime and maintenance; and a description of the log-collection mechanism. If the instructions are missing, incomplete or do not enable use in accordance with the intended purpose, the deployer cannot rely on Art. 26(1) compliance. Practically: refuse delivery, demand a corrected version, and document the request — this becomes evidence in any later enforcement action.
11. What does effective human oversight (Art. 14) actually look like on the deployer side?
Art. 14 places the design duty on the provider, but Art. 26(2) places the operational duty on the deployer: assign oversight to natural persons with the necessary competence, training, authority and support. In practice this means (i) named individuals per system with documented role descriptions; (ii) evidence that they understand the system's capacities and limitations and can correctly interpret outputs (Art. 14(4)(a)–(b)); (iii) the authority to decide not to use the output, to override or reverse it, and to stop the system via a 'stop' button or comparable procedure (Art. 14(4)(d)–(e)); (iv) awareness of automation bias (Art. 14(4)(b)). For Annex III point 1 biometric identification, Art. 14(5) additionally requires verification by at least two natural persons with the necessary competence before any action is taken.
12. Are we obliged to register anything in the EU database?
Public-authority deployers (and those acting on their behalf) of high-risk Annex III systems must register themselves and the use of the system in the EU database before putting it into service or using it (Art. 49(3)–(4) and Art. 71). Private-sector deployers do not register themselves directly — the provider registers the high-risk AI system itself under Art. 49(1) and the provider's listing carries the system identifier. Deployers should keep that provider-issued registration reference in their AI inventory as part of evidence of placing-on-market lawfulness.
13. What evidence must we be able to show on an inspection by a market-surveillance authority?
Art. 26(12) requires deployers to cooperate with competent authorities on any action they take in relation to the high-risk AI system. In practice authorities will request: (i) the AI inventory mapping each system to its Annex III category, role (deployer vs. provider) and provider EU-database ID; (ii) the provider's CE-marked declaration of conformity and instructions for use (Art. 47, Art. 13); (iii) FRIA outputs and the notification template sent to the market-surveillance authority where Art. 27 applies; (iv) human-oversight role assignments, training records and incident logs; (v) Art. 26(6) automated logs; (vi) the Art. 86 explanations provided to affected persons on request; (vii) workplace-notification records under Art. 26(7); (viii) Art. 4 AI-literacy training records.
14. What does the Art. 86 'right to explanation' mean for a deployer?
Art. 86 grants any person subject to a decision taken by the deployer on the basis of the output of a high-risk Annex III AI system (except point 2 — critical infrastructure) and which produces legal effects or similarly significantly affects them in a way they consider to adversely affect their health, safety or fundamental rights, the right to obtain from the deployer clear and meaningful explanations of the role of the AI system in the decision-making procedure and the main elements of the decision taken. Deployers should pre-build an explanation template per high-risk system rather than improvising under time pressure when a request arrives, and should align it with any GDPR Art. 22 obligations that may apply in parallel.
15. We use an AI system that may be a general-purpose AI (GPAI) model fine-tuned for HR. What changes?
If the system you deploy is a high-risk AI system, your Art. 26 obligations apply regardless of what model architecture sits inside it. The provider's GPAI-model duties (Chapter V — technical documentation under Art. 53, transparency to downstream providers, copyright policy under Art. 53(1)(c), and for systemic-risk models the additional Art. 55 duties) are upstream. As a deployer the practical consequence is that your provider should give you the Art. 53 information you need to integrate the model into a high-risk system and to fulfil your Art. 26 duties — including limitations, evaluation results and intended-purpose constraints. If the provider refuses or cannot, that is a value-chain risk you must document.
16. How does an AI Act conformity assessment differ for Annex III systems vs. Annex I?
Most Annex III high-risk systems use the internal control conformity-assessment procedure in Annex VI (self-assessment by the provider) — including the HR-tech category in Annex III, point 4. Annex III, point 1 biometric systems can use the third-party Annex VII procedure involving a notified body in specified cases (Art. 43(1)). Annex I high-risk systems — AI embedded in products already regulated by Union harmonisation legislation listed in Annex I, Section A (medical devices, machinery, in-vitro diagnostics, etc.) — follow the conformity assessment of the relevant sectoral regulation, integrating AI Act requirements (Art. 43(3)). Deployers do not run the conformity assessment, but they verify it was done before using the system.
17. What goes into the Annex IV technical documentation, and do deployers need to keep a copy?
Annex IV is the provider's responsibility — it lists 11 mandatory points: (1) general description of the AI system; (2) detailed description of the elements and the development process; (3) detailed information about the monitoring, functioning and control of the AI system; (4) description of appropriateness of performance metrics; (5) detailed description of the risk-management system under Art. 9; (6) description of relevant changes through the lifecycle; (7) list of harmonised standards applied or, if not applied, a description of solutions adopted; (8) a copy of the EU declaration of conformity under Art. 47; (9) detailed description of post-market monitoring under Art. 72; (10) the system's plan for substantial modifications; and (11) the most recent training, validation and testing dataset description. Deployers do not need to hold a full Annex IV copy, but should retain the instructions for use, declaration of conformity, and provider contact details — and should be able to request Annex IV evidence from the provider when authorities ask.
18. What should AI vendor contracts include to keep us compliant on the deployer side?
At minimum: (i) a binding warranty that the system is a high-risk AI system (where applicable) lawfully placed on the EU market under Art. 16 with valid CE marking and declaration of conformity (Art. 47); (ii) commitment to provide Art. 13 instructions for use in a Union language acceptable to the deployer (Art. 13(1)); (iii) Art. 25(4) cooperation clause obliging the provider to share information and access necessary for the deployer to fulfil Art. 26; (iv) notification of substantial modifications and material changes before they are deployed; (v) incident-reporting cooperation under Art. 73; (vi) audit and log-access rights aligned with Art. 26(6); (vii) post-market monitoring information flow under Art. 72; (viii) GDPR data-processing addendum where personal data is processed (Art. 28 GDPR).
19. Does Art. 4 AI-literacy apply to the whole organisation or only to oversight staff?
Art. 4 requires providers and deployers to take measures to ensure, to their best extent, a sufficient level of AI literacy of their staff and other persons dealing with the operation and use of AI systems on their behalf, taking into account their technical knowledge, experience, education and training, and the context in which the AI systems are to be used, and considering the persons or groups of persons on whom the AI systems are to be used. The duty has been in force since 2 February 2025 and is risk-proportionate: oversight personnel of high-risk systems need deeper training than occasional users of a chatbot. There is no prescribed curriculum — the test is whether training is appropriate to role and context. Document the training programme, the roles it covers and the evidence each person completed it.
20. What incident-reporting obligations apply to a deployer?
Art. 26(5) requires deployers to inform the provider/distributor and the relevant market-surveillance authority without undue delay and suspend use when they have reason to consider that use of the high-risk system in accordance with the instructions may result in a risk under Art. 79(1). Separately, Art. 73 places the primary serious-incident reporting duty on the provider — but deployers must inform the provider without undue delay after they become aware of a serious incident (Art. 26(5) read with Art. 73(1)). Serious incident is defined in Art. 3(49) and includes incidents directly or indirectly leading to the death of a person, serious harm to a person's health, a serious and irreversible disruption of critical infrastructure, infringement of Union law fundamental-rights obligations, or serious harm to property or the environment.
21. How does the AI Act interact with NIS2 for a HR-tech deployer that processes 'important' workforce data?
NIS2 scope is by sector and size (Annexes I and II), not by AI-specific criteria. A HR-tech vendor or in-house HR-tech function will rarely fall under NIS2 directly — but a parent group classified as essential or important under NIS2 (e.g. in banking, energy, health, digital infrastructure, ICT service management) inherits NIS2 obligations across its IT estate, including the AI systems embedded in HR workflows. Where both apply, the AI Act's cybersecurity requirement on high-risk systems (Art. 15) and the NIS2 Art. 21 technical, operational and organisational measures must both be satisfied. The reporting clocks differ: AI Act serious-incident notification is 'without undue delay' (Art. 73) while NIS2 requires an early warning within 24 hours, an incident notification within 72 hours and a final report within one month (Art. 23).
22. We're a small Nordic SME. Is there any proportionality in the AI Act?
Yes, three levers help SMEs: (i) Art. 62 obliges Member States to give SMEs and start-ups priority access to AI regulatory sandboxes and tailored awareness and training; (ii) Art. 56(2)(e) directs Codes of Practice to consider the needs of SMEs; (iii) Art. 99(6) caps SME fines at the lower of the percentage or the flat amount (the inverse of the 'whichever is higher' rule for large undertakings). The substantive Art. 26 deployer obligations themselves do not scale down by company size — proportionality is in how the duties are met (a smaller deployer can document a lighter oversight programme, but it still must exist and be auditable).
PowerQuant M1 (AI inventory + gap analysis + Article 4 controls memo) and M2 (Procurement Evidence Pack) turn the questions above into documented evidence per system. Fixed price, 5-day delivery, source citations down to the AI Act text.