Reasonably Foreseeable Misuse: EU AI Act Definition and Obligations
Article 3(13) of the EU AI Act defines reasonably foreseeable misuse. Providers must evaluate it under Article 9 and warn deployers under Article 13.
When the EU AI Act asks providers to manage risk, it does not limit that duty to the uses they designed for. Article 9 requires you to identify and evaluate risks arising from reasonably foreseeable misuse alongside intended use. Miss that half of the equation and your risk management system is incomplete — and the conformity assessment that depends on it is built on a gap.
Regulation (EU) 2024/1689 defines the term, ties it to concrete documentation obligations, and draws a line between misuse a provider must anticipate and conduct so extreme that the person responsible shifts into provider status themselves. Understanding where that line sits determines both how you document your system and how you draft the instructions that go with it.
The EU AI Act definition
Article 3, point 13 of Regulation (EU) 2024/1689 defines reasonably foreseeable misuse as:
"the use of an AI system in a way that is not in accordance with its intended purpose, but which may result from reasonably foreseeable human behaviour or interaction with other systems, including other AI systems."
Two things follow immediately from that definition.
First, it is explicitly paired with intended purpose, defined in Article 3, point 12 as the use for which a system was designed according to its provider — including the specific context and conditions of use. The two concepts are counterparts. Article 9 does not let you define your way out of the risk management duty by narrowing the intended purpose; it reaches past the specification and asks what a real user will predictably do.
Second, the standard is reasonable foreseeability, not omniscience. You are not required to anticipate every conceivable abuse, corner-case attack, or adversarial scenario. The duty is calibrated to what a competent provider in your sector would foresee — a test that varies by domain, user population, and deployment context.
A recruitment-screening model deployed by HR departments: a provider can reasonably foresee that a deployer might run it on a candidate pool the provider was not briefed on, or that the system will be queried through an integrated HR platform that passes data in slightly different form. Those scenarios belong in the risk management file. A scenario requiring a nation-state threat actor and a zero-day exploit in the deployer's infrastructure almost certainly does not.
Why it matters: the Article 9 risk management duty
Article 9 of Regulation (EU) 2024/1689 requires every high-risk AI system to have a risk management system — a continuous, iterative process across the lifecycle of the system, not a one-time pre-launch exercise.
Within that process, Article 9 specifically requires providers to:
- Identify and analyse known and foreseeable risks associated with the system in the context of its intended purpose — and its reasonably foreseeable misuse.
- Estimate and evaluate risks that may emerge from that misuse when the system is used as intended and when it is not.
- Adopt appropriate risk management measures designed to address those evaluated risks, with particular attention to the likely users, their technical knowledge, and the context of use.
The phrase "reasonably foreseeable misuse" therefore does real legal work inside Article 9. It sets the scope of the risk identification exercise. A provider who restricts the Article 9 analysis to the sunny-day intended-purpose scenario — and ignores the predictable ways users will deviate — has an incomplete risk management system. That incompleteness will surface in the technical documentation required under Article 11 and the conformity assessment under Article 43.
Article 9 also requires measures to be proportionate: the residual risk after mitigation must be judged acceptable against the benefits. You are not required to design out every foreseeable misuse scenario, only to evaluate it and adopt measures commensurate with the assessed risk level.
How providers address it
Testing against realistic misuse scenarios. A provider who tests only the intended operating envelope is not testing for the risks Article 9 requires to be addressed. Practical approaches include structured red-teaming against likely off-label uses, evaluation of edge-case inputs that a user might send in good faith but that fall outside the training distribution, and (where applicable) testing interactions with third-party systems that will sit in the same pipeline.
For systems in the employment, credit, or law-enforcement domains under Annex III, the relevant misuse scenarios are relatively well-defined: the system being applied to a population its training data did not cover; outputs being used to make binding decisions without the human review the provider assumed would occur; integration with a downstream system that reformats the output before the human decision-maker sees it. These are foreseeable. They belong in the risk file.
Instructions for use (Article 13). Article 13 requires providers of high-risk AI systems to supply information that enables deployers to understand the system and use it correctly. That information must include contraindications — intended purposes the system must not be used for, and foreseeable misuse scenarios that are specifically excluded. A well-drafted Article 13 instructions document does more than describe what the system does; it explicitly warns against the misuse scenarios the provider has identified under Article 9.
In practice this means naming the misuse scenarios in the instructions, not just saying "do not use outside the intended purpose." If the system has been evaluated and found reliable only for a defined population segment, the instructions should say so. If integration with a specific class of downstream system produces unreliable outputs, that should be stated. Deployers need actionable guidance, and the more specific the instructions, the harder it becomes for a deployer to claim they were unaware of a foreseeable risk.
Human oversight by design (Article 14). Article 14 requires high-risk AI systems to be designed to allow effective human oversight. Where a foreseeable misuse scenario involves a user bypassing an intended oversight step — for example, using a system in an automated pipeline where the provider assumed a human would review outputs — Article 14 imposes a design obligation: build the system so that oversight remains possible even if the deployment context does not guarantee it. This can mean output explanations that make review feasible, hard stops when the system encounters inputs outside its validated range, or logging that creates a reviewable record.
Reasonable foreseeability vs the unforeseeable — and the Article 25 line
There is a limit to the concept. "Reasonably foreseeable" means a provider is not responsible for every conceivable deviation. The question is what a competent provider in the relevant sector would expect, not what a determined adversary with privileged access could achieve.
That limit matters because Article 25 of Regulation (EU) 2024/1689 creates a role-shift rule: a deployer, distributor, or importer that substantially modifies a high-risk AI system — or that modifies the intended purpose in a way not covered by the provider's conformity assessment — becomes a provider of the modified system. The obligations that attach to providers under Article 16 then apply to them: technical documentation, risk management, conformity assessment, registration.
This creates a clean analytical boundary. Misuse that a provider should anticipate is the provider's problem: it must be evaluated under Article 9, documented, and addressed in the instructions. Misuse that involves a deployer genuinely repurposing the system — taking a recruitment-screening model and redirecting it at creditworthiness assessment, for instance — crosses into territory where Article 25 can convert the deployer into a provider. The original provider does not carry unlimited residual liability for uses they could not foresee and that were outside the scope of their conformity assessment.
In practice the boundary is not always sharp. A use case that is adjacent to the intended purpose and plausibly foreseeable does not trigger Article 25 just because the deployer behaved carelessly. The Article 25 line requires a genuine modification of the intended purpose, not merely poor compliance by the deployer. But the distinction matters when you are drafting instructions for use: the more precisely you define the intended purpose and the clearer you are about excluded uses, the stronger the case that a deployment outside those bounds is the deployer's responsibility rather than a gap in your Article 9 analysis.
Frequently Asked Questions
Q: Does reasonably foreseeable misuse apply to all AI systems or only high-risk ones?
The formal risk management obligation under Article 9 — which explicitly requires evaluation of reasonably foreseeable misuse — applies to high-risk AI systems. Lower-risk systems are not subject to Article 9. However, the concept of foreseeable misuse also informs Article 13 (instructions for use), which is a high-risk obligation, and Article 14 (human oversight), likewise high-risk. For minimal-risk or limited-risk systems, foreseeability remains a general product-safety and contractual question, but the explicit statutory duty is confined to the high-risk tier.
Q: How do we determine what counts as "reasonably foreseeable" in practice?
Start from the intended purpose and work outward: who are the realistic users, what is their technical level, what adjacent uses might they attempt, and what third-party systems will this system interact with? Sector guidance, incident data from comparable deployed systems, and structured red-teaming against off-label use scenarios all inform the analysis. The standard is what a competent provider in your domain would anticipate, not a theoretical maximum. Document the analysis — if a risk assessment concludes that a given misuse scenario falls outside reasonable foreseeability, record why.
Q: What happens if a deployer uses a system for an unforeseeable purpose and causes harm?
Where a deployer uses a high-risk AI system in a way that is genuinely outside the intended purpose — especially if that involves repurposing or substantially modifying the system — Article 25 can convert the deployer into a provider. The original provider's liability is tied to the conformity assessment they completed and the instructions they issued. If a deployer takes the system beyond that scope, responsibility shifts. The provider's clearest protection is a precisely drafted Article 13 instructions document that names what the system must not be used for and identifies the foreseeable misuse scenarios they have evaluated.
Q: Must every identified foreseeable misuse scenario be designed out of the system?
No. Article 9 requires you to identify, evaluate, and adopt appropriate measures — not to eliminate every foreseeable misuse by design. The proportionality test in Article 9 applies: the residual risk after mitigation must be acceptable in light of the benefits, and measures must be appropriate to the risk level. In practice this often means addressing some scenarios through warnings and instructions rather than technical controls. High-severity scenarios affecting health, safety, or fundamental rights will demand stronger technical mitigation; lower-severity scenarios may be adequately addressed by operational guidance to deployers.
Q: Does reasonably foreseeable misuse need to be mentioned in the technical documentation?
Yes. Article 11 requires technical documentation that covers the intended purpose and foreseeable uses, and Article 9 requires the risk management system — including its treatment of foreseeable misuse — to be documented. The Annex IV technical documentation template lists the intended purpose, reasonably foreseeable misuse and unintended outcomes, and the risk management measures adopted. Omitting the foreseeable misuse analysis from the technical file is a gap that a market-surveillance authority or notified body will identify.
Q: Can a provider limit foreseeable misuse liability by restricting the intended purpose very narrowly?
A narrow intended purpose reduces the scope of what the provider must foresee — but only up to a point. Article 9's reference to "reasonably foreseeable human behaviour" is not bounded by the provider's self-definition of the intended purpose; it asks what a real user might actually do. A provider who defines the intended purpose so restrictively that obvious adjacent uses fall outside it, without addressing those uses in the Article 9 analysis, risks an incomplete risk management file. The instructions for use under Article 13 remain the right tool for drawing the line: name the excluded uses explicitly and warn against foreseeable misuse scenarios, rather than relying on a narrow definition alone.
How Confir structures the Article 9 analysis
Confir's AIGM module — Governance & Post-Market Monitoring — guides providers through the Article 9 risk management workflow. The intake process includes structured prompts for both intended purpose and reasonably foreseeable misuse scenarios, outputs the risk assessment findings as part of the Article 11 / Annex IV technical documentation pack, and flags gaps in the instructions-for-use section where Article 13 coverage of foreseeable misuse is thin. The engine is rule-based and deterministic: every finding traces to an explicit rule tied to a specific Article, so the rationale is auditable. Pricing starts at €600/year; confir.eu.
Related terms
- Intended purpose — Article 3, point 12
- Risk management system — Article 9
- EU AI Act risk management: provider obligations
- Instructions for use — Article 13
- Human oversight — Article 14
- Substantial modification and role shifts
Manage your EU AI Act compliance in one place
Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 7-day free trial.
Start free trial →