Article 5(1)(b) EU AI Act: exploitation of vulnerabilities

What Article 5(1)(b) of the EU AI Act prohibits and why it matters

Article 5(1)(b) bans AI systems that exploit a vulnerability of a person or a specific group due to their age, disability or a specific social or economic situation in order to materially distort their behavior, where the distortion causes, or is reasonably likely to cause, significant harm. The prohibition has applied since 2 February 2025 (Article 113 of Regulation (EU) 2024/1689). It binds providers that place such a system on the market or put it into service, and deployers that use it, so a product team cannot pass the risk to a vendor. A compliance lead asking whether an AI feature targets people in vulnerable situations should start by asking what the system is optimizing for and which user groups it reaches, not only what the feature is called.

The ban is harder to scope than it looks because it does not require any manipulative or deceptive technique. Point (a) of the same paragraph targets subliminal or manipulative methods, but point (b) is triggered by the exploitation of the listed vulnerability itself. A recommender, pricing engine, credit offer or onboarding flow that is entirely transparent can still fall within scope if it pushes a minor toward a purchase they would not otherwise make, or steers a person in financial distress toward a costly product, and the harm is significant. Teams should document, for each high-impact feature, which user segments the model can identify, whether those segments are chosen or inferred, and what behavior change the system is designed or observed to produce.

The fine ceiling for breaching the prohibition is EUR 35 million or 7% of total worldwide annual turnover for the preceding financial year, whichever is higher (Article 99(3)). For a large group, the percentage will usually be the larger figure. Confirm with counsel how the turnover base is determined for your corporate structure. Separately, if a system is high-risk, Article 9(9) requires providers to consider whether it is likely to adversely affect persons under 18 and other vulnerable groups as part of their risk management. The Commission's guidelines on prohibited practices are the next read for interpreting the terms.

Which EU AI Act systems and teams fall under the vulnerability ban

Article 5(1)(b) turns on who places an AI system on the market, who puts it into service or uses it, and whether its output reaches people in the EU. The cards below separate the product decisions that bring a system into scope from the teams that must answer for each one.

Consumer-facing chat and assistants

A chatbot that talks to the public can be used by people who are minors, have cognitive or other disabilities, or are in financial distress. The question is whether the system is designed or tuned to take advantage of those states to push a decision that causes significant harm, such as a costly purchase or a loan taken out under pressure. Product and conversation design teams own this decision, and legal should review any prompt or flow that targets users by situation.

Recommendation and dynamic pricing engines

Ranking and personalized pricing models can learn which users are vulnerable because of age, disability or a constrained economic situation, then steer them toward products or price points that materially distort their choices. Data science owns the model objectives and features, while commercial teams own the pricing rules. Check whether any feature proxies for a protected vulnerability and whether the optimization target rewards harm.

Collections and credit nudge systems

Models that choose the timing, channel or wording of payment reminders for borrowers in hardship sit close to the ban. Where the system exploits a specific economic situation to push a repayment or borrowing action that causes significant harm, Article 5(1)(b) applies even without manipulative techniques. Credit risk, collections operations and compliance should jointly document which signals the model uses and how hardship markers are excluded or handled.

Gaming and subscription retention tools

Engagement models that decide when to offer in-game purchases, time-limited bundles or renewal incentives can target players identified as minors or as having impulse-control difficulties. The ban asks whether the system exploits that vulnerability to distort behavior in a way that causes significant harm. Game design, live operations and trust and safety teams should agree age-related controls and review offers aimed at accounts likely to belong to children.

Systems used with minors or people with disabilities

Educational tools, health support apps and accessibility services are used by groups the Act names directly. Where such a system is deployed to these users, the deployer's use is in scope as well as the provider's design. For high-risk systems, Article 9(9) requires the provider's risk management to consider whether the system is likely to adversely affect persons under 18 and other vulnerable groups. Assign that review to the risk owner who signs the risk management file.

Non-EU operators serving EU users

The Act reaches providers and deployers established outside the EU when their AI output is used in the EU. A US or Asian platform that serves EU consumers with an ranking, pricing or chat system is therefore within reach of Article 5(1)(b). Legal and privacy teams should map which markets receive output from each system, and the EU representative or product owner should confirm which entity places the system on the market or puts it into service.

How the vulnerability test works in practice

An assessor checks Article 5(1)(b) as a sequence of four elements, and a system must meet all four before the ban applies. The first is the targeted person or group: the assessor asks who the system is aimed at or who it actually reaches. The second is the vulnerability itself, which must be one of the listed grounds: age, disability, or a specific social or economic situation. Evidence for these two elements usually comes from the product design documents, the target user definitions, marketing and onboarding flows, and any segmentation logic that routes users to particular outputs. If a provider can show that the system was not designed or used to single out people on these grounds, that record matters, but it does not replace testing the outputs.

The third element is the objective or effect of materially distorting behavior. Intent counts, but so does effect: a system that predictably changes what a vulnerable person decides, even when nobody intended it, can meet this element. Evidence here includes decision logs, A/B test results, conversion or engagement metrics split by the vulnerable group, and documented reasoning on how prompts, nudges, pricing or recommendations were tuned. The fourth element is significant harm, caused or reasonably likely to be caused to that person or another person. Teams should record the harm scenarios they considered, the severity they assigned, and the monitoring that would detect harm in production.

Point (b) differs from point (a) in one important way: it does not require subliminal, manipulative or deceptive techniques. A plainly designed system, such as a clear offer tool that repeatedly steers an older user into a costly plan, can breach point (b) without any hidden design. The question for the organization is therefore not whether the interface looks manipulative but whether the vulnerability is exploited and the harm follows. Before launch, confirm with counsel which of the listed vulnerability grounds apply to your user base, and keep the risk assessment that Article 9 requires for high-risk systems, which must also consider persons under 18 and other vulnerable groups.

How an assessor tests the EU AI Act vulnerability prohibition

This table compares what an assessor checks for each element of the Article 5(1)(b) ban, the evidence they usually request, and the gaps they most often find. A market surveillance authority or an independent reviewer typically runs this review, because no certification body issues an Article 5 certificate. Read each row as a test question: if the evidence does not exist, the finding usually follows.

Element	What the assessor checks	Evidence requested	Common findings
Target population	Whether the system is designed or used to target people by age, disability or a specific social or economic situation	Targeting criteria, segment definitions, product and feature specifications	Undocumented targeting logic; segments built from proxies for age or financial distress with no review
Vulnerability trigger	Whether the vulnerability actually drives the system's outputs or decisions	Design records showing how the trigger feeds into outputs, model inputs and feature weights	Vulnerability signals present in the data but never tested for their effect on outputs
Behavioral effect	Whether the system materially distorts behavior, by object or by effect	Behavioral test results, A/B tests, conversion or engagement metrics, pre-release testing notes	A/B results retained but never reviewed for distortion; no pre-release behavior testing
Harm assessment	Whether significant harm to the person or another person is caused or reasonably likely	Written harm analysis, affected-person impact review, complaint and incident records	No harm analysis on record; harm marked as low without supporting evidence
Deployer use controls	How deployers configure, restrict and monitor the system for these groups	Deployer instructions, configuration settings, access rules, monitoring logs	Vendor disclaims misuse while deployers enable targeting of vulnerable groups without controls
Risk management link (high-risk systems)	Whether the provider considered persons under 18 and other vulnerable groups under Article 9(9)	Risk management file entries covering minors and vulnerable groups, with dated review records	Risk file silent on minors; vulnerable groups listed but no mitigation recorded

How to implement the EU AI Act vulnerability ban step by step

This sequence lets an organization show, before launch and while the system runs, that no AI system it provides or uses exploits age, disability or a specific social or economic situation to materially distort behavior. Each step closes with a record that an assessor or market surveillance authority could ask to see.

Inventory every AI system that touches users
The product owner and the compliance lead list every AI system the organization provides or deploys that interacts with, ranks, recommends to or decides about people, including vendor tools and features switched on by default. Record the system name, owner, role under the AI Act (provider or deployer), user groups, and the channel through which users reach it. The output is a use-case register entry for each system. The check is that engineering and procurement confirm the list matches what is live in production and in pilots.
Map where outputs could target a listed vulnerability
Legal and the product owner review each register entry against the four vulnerabilities named in Article 5(1)(b): age, disability, and a specific social or economic situation. They note where the system could reasonably identify or infer those characteristics, such as through account data, behavioral signals, or onboarding answers, and where users in those situations could be steered toward decisions they would not otherwise make. The output is a vulnerability mapping memo for each system, signed by the compliance lead. Where the team concludes that no listed vulnerability is in play, the memo states the reasoning.
Review design and optimization objectives
Engineering and the product owner document the objective function, ranking signals, nudges, pricing or offer logic, and any A/B tests that tune the system toward a business metric. They check whether an optimization target could materially distort behavior for a vulnerable group, for example by maximizing conversion among users in financial distress. The output is an objectives review record that lists each optimized metric, the data it uses, and the design changes agreed. Ask engineering to show the configuration history, so reviewers can see when objectives changed.
Run adversarial and scenario tests on vulnerable user profiles
The test team builds scenario sets that represent users in the listed situations, including minors, users with cognitive or sensory disabilities, and users under financial or social pressure. They run the system against those profiles and record whether outputs push behavior in ways that could cause significant harm. Where the system is a language model or agent, security testers can use tooling such as garak to probe outputs at scale, and observability traces from a platform such as Langfuse help reviewers reconstruct how an individual response was produced. The output is a test report with scenarios, inputs, outputs, findings and retest results. Confirm the test method with your legal advisers, since the Commission's guidelines on prohibited practices shape what counts as materially distorting behavior.
Define stop rules and human review
The governance owner sets the conditions under which the system must be paused, restricted or sent to a human reviewer. Examples include a test finding that a profile receives materially different steering, a complaint from a user or guardian, or a monitoring alert that a vulnerable segment shows an unusual change in decisions. The owner also names who can invoke the stop, how fast it must happen, and who reviews the case. The output is a written stop-rule procedure with named roles and an escalation path. The check is a tabletop exercise in which the team shows it can execute the stop.
Record decisions and approve the release
The accountable executive reviews the register entry, mapping memo, objectives review, test report and stop-rule procedure, then records a go, go with conditions, or no-go decision for each system. The record states the residual risk, the conditions attached, and the date of the next review. The output is a signed risk decision stored with the system's technical documentation. Keep these records under version control so that a regulator or an independent auditor can trace what was known at each release.
Reassess when the system or its users change
The compliance lead schedules reassessment whenever the model, objective, user population, or market changes materially, and whenever monitoring or complaints raise a concern. The reassessment reruns the relevant steps and updates the register entry and mapping memo. The output is a dated change record linked to the earlier risk decision. Ask the team to confirm which triggers its change management process already captures, and where it needs a new trigger for this ban.

Evidence that shows compliance with the vulnerability prohibition

Article 5(1)(b) turns on what a system was designed to do, who it reaches and what it did to vulnerable people in practice. The six artifacts below answer those questions, and each one should carry a version, an owner and a review date so the record still matches the system an assessor sees.

AI system inventory with intended users

Keep a register of every AI system the organization provides or deploys, with the intended user population recorded for each. Flag any system whose users may include minors, people with disabilities or people in financial distress, because those are the groups point (b) names. Record the owner, the market or country of use and the date the entry was last confirmed. Review the register whenever a new use case or user segment is added, not only at audit time.

Documented design objectives

Write down what the system is meant to influence, such as purchase choices, borrowing decisions or engagement time, and what it must not do. An assessor will compare these objectives with observed behavior, so vague language such as improve user experience gives no defence. Version the document with the model and prompt releases it describes, and record who approved each change and why.

Vulnerability assessment per use case

For each use case, document which vulnerabilities of age, disability or specific social or economic situation could be relevant, and how the design accounts for them. This is the place to show that the organization considered the group before launch, which the high-risk risk management duty in Article 9(9) also requires for persons under 18 and other vulnerable groups where it applies. Set a review trigger for changes in user base or product features.

Scenario test results for vulnerable groups

Test the system with scenarios that simulate users in the listed vulnerable situations, such as a minor, a user with cognitive impairment or a person describing financial hardship. Record inputs, outputs, pass or fail criteria and the tester. Tools such as garak can probe language models for jailbreaks and toxic outputs, but they do not measure exploitation of a specific user group, so scenario tests still need a human-designed test plan. Retain results per model version.

Harm analysis and decision records

Document the harm analysis that assesses whether a distortion of behavior could cause significant harm to the person or to another person. Record each decision to accept, mitigate or stop a feature, with the reasons, the approver and the date. Assessors look for evidence that the organization considered harm before deployment and acted on what it found, so keep the reasoning and not only the outcome.

Monitoring logs of live behavior

Retain logs that show how the system behaved with real users, including prompts, outputs, tool calls and the user segment where it is known. Observability platforms such as Langfuse capture traces of each request with inputs, outputs and metadata, which helps reconstruct a disputed interaction. Confirm the retention period against privacy obligations, restrict access to logs that contain personal data, and review flagged interactions on a set cadence.

What meeting the EU AI Act vulnerability ban costs

This table lists the cost components of showing that an AI system does not exploit age, disability or social and economic vulnerabilities, who is typically paid for each, whether it is one-time or recurring, and what pushes it up or down. No supplied figure exists for this work, so use the drivers and quote questions to compare written proposals. The main takeaway is that the largest recurring cost is evidence upkeep for every user-facing system.

Cost component	Who is paid	One-time or recurring	What drives it up or down
Legal and policy review of prohibited practices	External counsel or the organization's own legal team	One-time, then periodic review	Up: many user-facing products and markets. Down: a shared policy covering all systems and a clear internal definition of vulnerable groups
Engineering time for logging and controls	Internal engineers or an implementation partner	One-time build, recurring tuning	Up: personalization depth, number of models and ranking logic. Down: reusable logging and tracing already in place for other obligations
Scenario testing against vulnerable user profiles	Internal QA, testers or a security testing firm	Recurring with each material model or prompt change	Up: number of age, disability and economic profiles tested and frequency of releases. Down: a maintained test library reused across releases
Evidence upkeep and documentation	Internal compliance staff or a partner preparing records	Recurring	Up: regulated-sector overlap that requires parallel records. Down: a single AI system inventory and self-hosted tooling that stores traces and reports
External testing or independent review	Specialist testers or independent reviewers	Recurring or per release, depending on scope	Up: high-risk or consumer-facing systems and novel vulnerability types. Down: a narrow written scope agreed before work starts
Authority engagement or auditor involvement	National market surveillance authority or independent assessor, where applicable	Event-driven	Up: complaints, incidents or a regulator inquiry. Down: documented decisions and records ready before any request

Self-hosted open-source tools that produce vulnerability evidence

Article 5(1)(b) turns on whether a system exploits a listed vulnerability and causes significant harm, which no single tool can prove. The three tools below each produce a different kind of evidence: scenario test records, runtime traces and decision records. Used together, they help an organization show what it tested, what the system did in production and who decided what.

Scenario testing with garak

garak is an Apache-2.0 scanner that probes language models for hallucination, data leakage, prompt injection, misinformation, toxicity and jailbreaks. Its JSONL report records every attempt and evaluation, and its hit log lists attempts that found a weakness. Treat it as test evidence for your own scenarios, such as a prompt that targets a minor or a user in financial distress. It does not decide whether exploitation occurred. Confirm that your test scenarios match the vulnerability groups you claim to cover.

Runtime traces with Langfuse

Langfuse (MIT) records each trace of a request, including LLM calls, retrieval steps, tool executions and custom logic, with timing, inputs, outputs, token usage and metadata. For this prohibition, the useful signal is whether a trace shows the system adapting its responses to a user's age, disability or financial position. Metadata must carry enough context to answer that question. Check your retention settings and who can read traces, because traces hold personal data and may be subject to the GDPR.

Decision records with CISO Assistant

CISO Assistant (AGPL-3.0-only) ships more than 200 frameworks, including ISO 27001, NIST CSF, SOC 2, DORA and GDPR, and runs assessments against them with automatic mapping between frameworks. Use it to record the risk assessment for each system, the decision that a use case falls outside the ban, the owner of each decision and the evidence attached to it. Its value lies in showing who decided what and when. Do not treat any automatic mapping as confirmed without review.

Confirming license fit

garak, Langfuse and CISO Assistant use different licenses. AGPL-3.0-only carries network-use obligations that can affect a modified, hosted deployment, and MIT and Apache-2.0 carry different notice and patent terms. Before you embed or modify any of them in a customer-facing product, have counsel confirm how each license applies to your architecture. This review is an internal step. It is not legal advice from DeployOpen, and it should be completed before the tools become part of your evidence chain.

Who does what: your team, a partner and the auditor

Your organization owns the prohibition. It decides which AI systems are in scope, whether any feature could target people because of age, disability or a specific social or economic situation, and whether the resulting distortion of behavior could cause significant harm. Those judgments are product and legal decisions, and no partner or auditor can make them for you. Your team also maintains the use-case register and signs the risk acceptance for anything that remains open.

Use-case register: list every AI system and feature, including purpose, users, target groups and whether minors or vulnerable adults can reach them.
Vulnerability analysis: document which listed vulnerabilities each use case could touch and the reasoning for ruling each one in or out.
Product decisions: approve design changes, such as removing nudging for users in financial distress or blocking engagement tactics aimed at minors.
Risk acceptance: record who accepted any residual risk, on what basis, and when it will be reviewed.
Legal interpretation: obtain counsel's view on borderline cases, and check the Commission's guidelines on prohibited practices.

Check that every decision has a named owner and a dated record before anyone outside the company reviews it.

Frequently asked questions about the EU AI Act vulnerability ban

How much effort does complying with the vulnerability ban take?

Most of the effort goes into review, documentation and evidence, with some engineering work where a system needs changes. The workload grows with the number of AI systems you build or use, the number of user groups they reach, and how much of the model logic you can inspect. Start with an inventory of systems that interact with people, then check each one for design or outputs that could target age, disability or a specific social or economic situation. Internal staff time is usually a large part of the cost. External help is priced from a written scope, so ask any provider which systems are covered, which tests they will run, and which deliverables you will receive.

How long do we have to prepare for the vulnerability ban?

There is no preparation window left for this ban because it has applied since 2 February 2025. Any AI system you place on the market, put into service or use in the EU must already avoid the prohibited pattern. The time you need depends on how many systems are in scope, whether they are built in-house or bought from vendors, and how much existing documentation you can reuse. Organizations that find a gap should first confirm, with counsel, whether the system is affected, then decide whether to change, restrict or withdraw it. Timelines for any remediation should come from a written plan for your own environment, not from a generic estimate.

What do product and legal teams need to contribute?

Product teams explain what each AI system does, who uses it, what it optimizes for and where it is shown to people. Legal and compliance teams interpret the listed vulnerabilities, the material distortion test and the significant harm threshold, and they decide how to document that reasoning. Engineering teams supply logs, prompts, model settings and evaluation results. The most useful outputs are a short written assessment per system, a record of who approved it, and a change process that triggers a fresh review when a feature, audience or model changes. Ask your implementation partner to map these handoffs in the written scope so each team knows its share.

Can a small team handle the vulnerability ban in-house?

A small team can handle the ban in-house when it has few AI systems, clear product ownership and someone who can read the legal text with counsel. The work is narrower than a full high-risk program because the prohibition targets one pattern of harm. The harder cases are systems with many user segments, vulnerable audiences such as minors, or third-party models that give you limited visibility into behavior. In those cases, an outside reviewer can test outputs and challenge your assessment. Whatever the split, keep the decision record, the test results and the approval trail, because those are what you will need to show if a market surveillance authority asks.

Can an outside partner certify that we comply?

No. No one can certify in advance that an AI system complies with this ban. Only the competent authorities and, ultimately, the courts decide whether a practice breaches the prohibition. An implementation partner such as DeployOpen can prepare systems, test behavior, document the assessment and organize evidence, but it does not issue audit reports, attestations or certificates. Be cautious with any provider that offers a certificate for this prohibition. Ask instead for the written scope, the test methods, the evidence files you will own, and a clear statement of what the provider does and does not sign off on.

Does emotional design alone trigger the vulnerability ban?

No. Emotional design by itself does not trigger Article 5(1)(b). The ban requires that the system exploits a vulnerability linked to age, disability or a specific social or economic situation, that it materially distorts the behavior of that person or group, and that the distortion causes or is reasonably likely to cause significant harm. Engaging, warm or persuasive interfaces that do not target those vulnerabilities fall outside this point. Techniques that operate subliminally or manipulate people without a listed vulnerability are a separate question under Article 5(1)(a), so review both. Read the Article 5 text on EUR-Lex with counsel before deciding.

How does the vulnerability ban interact with the high-risk rules?

The two sets of rules run separately, and a system can face both. The prohibition already applies, while the high-risk rules in Chapter III Section 2 apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I product systems. For high-risk systems, Article 9(9) requires providers to consider in their risk management whether the system is likely to adversely affect persons under 18 and other vulnerable groups. The prohibition carries fines of up to EUR 35 million or 7% of worldwide annual turnover, while most operator obligations carry up to EUR 15 million or 3%. Treat the risk analysis as shared evidence, but keep a separate, dated assessment for the ban.

How DeployOpen prepares evidence for this prohibition

DeployOpen works on Article 5(1)(b) by preparing the systems, test records and documentation that show how an AI system handles users with age, disability or economic vulnerabilities inside your own infrastructure. Your organization owns the prohibition assessment and any compliance decision, and only independent auditors or authorities give a determination.

How we scope

Written scope names the AI systems, user groups and vulnerability categories reviewed under Article 5(1)(b).
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
Scope records which systems reach minors, persons with disabilities or financially stressed users.

How we build

Logging of prompts, outputs and decisions is set up so behavior toward vulnerable user groups can be reviewed.
Adversarial probes test whether system responses exploit age, disability or economic situation.
Test results are captured in repeatable reports that map to each tested scenario and its outcome.

How we hand over

Documentation covers system purpose, design safeguards, test methods, findings and remediation status.
Evidence packs are delivered into your own repositories and systems, for your staff to keep and maintain.
A handover session walks your compliance and engineering teams through each artifact and its limits.

How we support

Ongoing support, upgrades and continuous testing are available as retainers for systems that change over time.
Re-testing follows model, prompt or product changes that could affect how vulnerable users are treated.
Questions about legal interpretation should go to your counsel or a qualified assessor, not to DeployOpen.