Article 5(1)(b) prohibits the placing on the market, the putting into service or the use of an AI system that exploits any of the vulnerabilities of a natural person or a specific group of persons due to their age, disability or a specific social or economic situation, with the objective or the effect of materially distorting the behaviour of that person or a person belonging to that group in a manner that causes or is reasonably likely to cause that person or another person significant harm. The vulnerability, the exploitation, the distortion and the harm must all be present. Serving a vulnerable group, or designing accessible products, is not exploitation in itself.
Which vulnerabilities does point (b) name?
Point (b) names vulnerabilities due to age, disability, or a specific social or economic situation. Age covers children and older people where age creates a relevant vulnerability in context. Disability covers physical, sensory, intellectual and psychosocial disabilities where the disability affects the person's interaction with the system. A specific social or economic situation covers circumstances such as financial hardship, dependence, bereavement, or social isolation where the situation creates a vulnerability that the system could exploit. The vulnerability must be a characteristic or situation of the person or group, not merely a preference or a general susceptibility to advertising. The record should name the group, the vulnerability, and the evidence that it exists in the deployment context.
What does exploiting a vulnerability mean?
Exploitation means the system takes advantage of the vulnerability to achieve the distortion described in the article. The system must exploit the vulnerability with the objective or the effect of materially distorting behaviour. A system that is merely used by a vulnerable person does not exploit that person. A system that adapts its approach because it detects a vulnerability, and uses that detection to steer the person toward a decision they would not otherwise take, needs examination. Design choices are evidence: targeting criteria, personalisation signals, timing, language and pressure tactics all show whether a vulnerability was merely present or actively exploited. The distinction should be recorded with the design facts, not with an assertion of good intent.
For the broader regulatory framework, see prohibited practices under Article 5.
How are distortion and harm tested here?
The distortion test mirrors point (a): behaviour is materially distorted by appreciably impairing the ability to make an informed decision, so that the person takes a decision they would not otherwise have taken. The harm test requires significant harm caused or reasonably likely to be caused to that person or another person. In a vulnerability case, the assessment of both elements must take the vulnerability into account. A technique that would leave a person without that vulnerability able to decide freely may appreciably impair a person with the vulnerability. Harm should be assessed from the perspective of the affected person, including financial, health and autonomy harms, and the record should explain why the harm is significant in that context rather than merely inconvenient.
How does point (b) differ from point (a)?
Point (a) focuses on the technique: subliminal or purposefully manipulative or deceptive techniques. Point (b) focuses on the target: exploitation of a vulnerability. A single system can engage both points, for example where a deceptive technique is aimed at a vulnerable group, and each point should be screened separately. A system can also engage point (b) without engaging point (a), where the technique is not subliminal or deceptive in itself but exploits a vulnerability through timing, personalisation or pressure. Screening both points separately prevents a system from being cleared on technique alone when the vulnerability analysis would have caught it, or vice versa.
What safeguards should teams consider before deployment?
Teams should identify the user groups, including any vulnerable groups, at the design stage, and test the system with those groups in mind. Safeguards include clear disclosure, genuine choice, limits on targeting based on vulnerability signals, human review for consequential decisions, and escalation where a user shows signs of distress or confusion. Safeguards should be tested, not merely stated, and the testing should include the groups the system will actually reach. Where a system is intended for a vulnerable group for a legitimate purpose, such as accessibility or support, the record should explain how the design serves that purpose without exploiting the vulnerability, and how the distinction is maintained in practice.
Continue with manipulative techniques prohibition.
What remains undecided in this guide?
This guide explains the elements of point (b). It does not decide whether any particular system exploits a vulnerability, whether a group counts as vulnerable in a specific context, or whether a safeguard is sufficient. Those questions need the user group, the design, the deployment context and the harm analysis, read against the consolidated text. Where a system targets or reaches children, people with disabilities, or people in hardship, and where decisions are consequential, confirmation should be sought from a competent authority or legal adviser before the system is placed on the market, put into service or used.
Frequently asked questions
Is designing for children automatically prohibited?
No. Point (b) requires exploitation of a vulnerability with the objective or effect of materially distorting behaviour and causing or risking significant harm. A product designed to serve children safely and transparently, without exploiting age-related vulnerability, is not described by that wording, although other laws on children and data protection will apply.
Does point (b) require intent to exploit?
The wording covers both objective and effect. A system can be prohibited where exploitation is its objective or where that is its effect, provided the other elements are met. Design and outcome evidence both matter.
What if only some users are vulnerable?
The prohibition can apply to a specific group of persons. Screening should consider the groups the system will actually reach, not only the intended audience, and should record how vulnerable users are identified and protected in the design.
Continue through this AI Act cluster
This article is an informational overview, not a legal determination. Check the current legal text and official implementation guidance for your system and role.
Consolidated Regulation (EU) 2024/1689 ↗AI Act Service Desk timeline ↗European Commission regulatory framework for AI ↗