Article 26: Using a High Risk System According to Its Instructions
Article 26 of the EU AI Act imposes a straightforward but often overlooked duty on deployers. You must use high-risk AI systems only in the manner and for the purposes described in the instructions for use provided by the provider. This is not an optional guideline; it is a binding obligation. The regulation recognises that misuse of a high-risk system can cause serious harm and that deployers are accountable for how they deploy systems in practice.
The instructions for use are the contract between provider and deployer. When a vendor sells you a high-risk system, they must provide documentation that describes the intended use case, the data it expects, the population it was tested on, any known limitations, and the conditions under which the system should be monitored or overridden. A deployer must read, understand and follow these instructions. This duty applies even if you believe you could use the system differently without regulatory approval.
Consider a healthcare provider that purchases an AI diagnostic system intended for detecting cancer in mammography images. The vendor’s instructions state that the system is calibrated for standard resolution images from imaging equipment models X, Y and Z, that it was trained on images from female patients aged 40 to 80, and that it must not be used for screening in male patients or for other cancer types. A deployer must not then use the system on lower-resolution images, on male patients, or for lung cancer screening without explicit vendor approval and a new compliance review. Doing so would breach Article 26.
The practical implication is that deployers must actively govern what their teams do with AI systems. You cannot simply hand a system to staff and assume they will use it correctly. You must communicate the permitted use cases to everyone who touches the system. Training, job specifications, and process documentation must all reflect the vendor’s instructions. When staff are tempted to stretch the system beyond its intended scope, you must say no until the vendor confirms the wider use is safe.
Scope boundaries are non-negotiable
Vendors define scope boundaries for sound technical reasons. A credit scoring system trained on data from one country may behave differently in another. A hiring assessment system trained on university graduate data may perform poorly on secondary school leavers. A fraud detection system calibrated for transactions under 100,000 euros may not be reliable above that threshold. These are not arbitrary limits imposed by lawyers; they are technical facts about how models perform under different conditions.
Model performance changes when the input data characteristics change. A model trained on data from customers aged 25 to 65 may not perform well on customers aged 18 to 24 who have different income patterns and credit histories. A model trained on English language customer service queries may perform poorly on requests in other languages. A model trained to detect defects in one manufacturing line may not work on a different production line using different equipment or materials. These performance differences are measurable and real.
Article 26 enforces scope boundaries. You are liable if you breach it. The liability is both regulatory (the authorities can fine you) and civil (affected people can claim damages). If your loan application decisions are based on an AI system used outside its approved scope and the wrong people are rejected, the affected applicants may sue you for discrimination. The vendor may also refuse to support your system if you misuse it and a failure occurs. Your liability insurance may not cover claims arising from your breach of the vendor’s scope statement.
Documentation and evidence
To comply with Article 26, you must evidence that your use is within scope. This means retaining the vendor’s instructions and documenting how you deploy the system. Log files should show the types of inputs the system receives. Process documentation should reference the vendor’s scope statement. Audit trails should confirm that staff are following the instructions. When regulators inspect your AI governance, they will ask for this evidence.
Your documentation should include a scope compliance checklist for each system. For a hiring assessment system, the checklist might specify: the educational backgrounds the system was trained on, the job roles it was designed for, the geographic regions it covers, the languages it supports, and any population demographics it was tested on. Staff deploying the system should confirm they are operating within each parameter.
If you discover that your organisation has been using a system outside its intended scope, you must stop that use immediately and report to the vendor. Depending on the severity, you may need to notify affected people and the authorities. Documenting your corrective action demonstrates good faith compliance and may mitigate penalties if regulators investigate.