Article 5(1)(a) manipulative techniques: requirements and evidence

What Article 5(1)(a) bans and why it is hard to prove absent

Article 5(1)(a) bans AI systems that use subliminal techniques beyond a person's consciousness, or purposefully manipulative or deceptive techniques, where the objective or effect is to materially distort behavior and cause, or reasonably likely cause, significant harm. The prohibition has applied since 2 February 2025 and binds both providers that place systems on the EU market and deployers that put them into service or use them. A team asking whether its assistant, recommender or sales chatbot crosses the line should test four things in order: whether the system uses a technique that is subliminal or purposefully manipulative or deceptive, whether that technique appreciably impairs a person's ability to make an informed decision, whether the impaired decision is one the person would not otherwise have taken, and whether the result causes or is reasonably likely to cause significant harm to that person, another person or a group.

The test has three parts that a reader can document separately. The first is the technique, which covers interface design, persuasion patterns, framing, timing and generated content that operates below awareness or is designed to mislead. The second is distortion of an informed decision, which the Commission's guidelines of 4 February 2025 analyze with practical examples. The third is significant harm, which must be linked to the decision the technique produced. Intent and effect both matter: the ban reaches a system whose objective is manipulation, and also one whose effect is manipulation even if the designers meant well. That is why absence is hard to prove. A team must show that no measurable distortion occurred, which means defining the decisions the system influences and logging enough of its outputs and user paths to test them.

Confirm with counsel whether a given use is a prohibited practice or a transparency or high-risk matter, since the same interface can fall under several articles. Start the record now: list the decisions your system influences, the persuasion or generation techniques it uses, the user groups affected and the harms you could foresee. For generative systems, adversarial testing such as garak can probe for deceptive outputs, and tracing tools such as Langfuse can preserve the inputs, outputs and tool calls behind a disputed decision. Neither result is a legal finding. Fines for breaching Article 5 reach EUR 35 million or 7% of total worldwide annual turnover for the preceding financial year, whichever is higher, so the analysis should be documented before launch.

Which systems and teams fall under the manipulation ban

Article 5(1)(a) reaches any operator whose AI system is placed on the EU market, put into service or used in the EU, so the question is less about company size and more about where the system's output lands. The cards below separate the scoping decisions from the design reviews that decide whether a specific interface crosses the line.

Providers placing systems on the EU market

A provider that places an AI system on the EU market or puts it into service is bound by the ban whether it is established in the EU or elsewhere. Confirm whether the system is offered to EU users through a product, API or embedded component, because that decision alone brings the prohibition into scope. Record the placement date and each market release, since the ban has applied since 2 February 2025.

Deployers using systems in the EU

A deployer that uses an AI system in the EU is covered by the prohibition even when a third party built the model. Teams that configure a vendor's assistant, set its prompts or choose its nudges on a checkout or subscription flow should treat themselves as deployers. Ask vendors in writing whether their system contains any technique designed to distort decisions, so the deployer knows what it is putting into service.

Non-EU operators whose output is used in the EU

Article 2 extends the Act to non-EU providers and deployers whose AI output is used in the EU. A US or Asian marketing platform whose generated messages reach EU consumers may therefore fall in scope even with no EU entity. Map where outputs are delivered, not only where servers sit, and document the EU audience reached by each campaign or interface.

Product and conversational design teams

Product managers and conversational designers decide the flows, defaults and wording that an AI system presents to users, so they hold the most direct exposure to the ban. Review onboarding, consent screens, cancellation paths and chatbot scripts against the three-part test before release. Keep design rationale and test results so the team can show why a specific choice did not impair informed decisions.

Growth and marketing teams

Growth and marketing teams often tune AI-generated copy, urgency messages and personalized offers to raise conversion, which is where persuasive techniques shade into purposeful manipulation. Ask for a written record of the objective behind each automated campaign and the harm it could cause a decision-maker. Scarcity timers, false social proof and emotional pressure in generated text deserve the closest review.

Assessing persuasive design against the three-part test

Persuasive design, nudging and dark patterns are assessed against three elements: a subliminal, manipulative or deceptive technique, an objective or effect of materially distorting behavior, and a resulting decision that causes or is reasonably likely to cause significant harm. Ordinary persuasion that leaves the user free to choose usually falls outside the ban. Document each element for every flagged pattern, and route patterns that target a person's age, disability or financial distress to the separate vulnerability review in 5(1)(b).

How the manipulation ban differs from the vulnerability ban in point (b)

Article 5(1)(a) and Article 5(1)(b) both ban AI systems that materially distort behavior and cause significant harm, but they turn on different questions. Point (a) asks how the system influences the person: through subliminal techniques beyond a person's consciousness, or through purposefully manipulative or deceptive techniques. Point (b) asks who the system targets: people who are exploited because of their age, disability or a specific social or economic situation. A manipulation review starts from the design of the interaction, while a vulnerability review starts from the characteristics of the audience.

Illustrative example, hypothetical: a retail app uses a chatbot that presents a limited-time offer as ending in minutes, when the timer is fake, and repeats the claim until users commit to a loan. The deceptive technique is the focus of point (a), and the decision to borrow may be caught even if the users are not vulnerable. A second hypothetical: a payday-lending model sends high-cost credit offers only to people whose data suggests financial distress, using neutral wording. No manipulative technique is needed for point (b) to apply, because the exploitation of the economic situation is the harm. Teams should record which of these two questions each feature answers.

One system can fall under both bans. A hypothetical mobile game that uses deceptive countdowns and targets children whose impulse control is still developing could trigger point (a) because of the technique and point (b) because of the audience. Before launch, a compliance lead should map each user-facing feature to the technique it uses and to the groups it reaches, and should confirm with counsel how the Commission's guidelines of 4 February 2025 treat the boundary between manipulation and ordinary persuasion, since that analysis is where the two bans overlap in practice.

How an assessor tests the manipulation prohibition

This table sets out each step an assessor is likely to take when testing whether an AI system falls foul of the Article 5(1)(a) ban, the evidence to hold ready for each step, and where reviews usually stall. Read it as a checklist for preparing the file before any review starts. The main takeaway is that an assessor looks for a documented reasoning trail as much as for technical test results.

Assessment step	What the assessor examines	Evidence to prepare	Common finding
Purpose and design review	The intended purpose, target users and the decisions the system influences, including whether it nudges choices about money, health or work	Written intended-purpose statement, design specification and list of decisions the output can affect	Purpose described only in marketing terms, with no link to the decisions it shapes
Interaction flow review	Screens, prompts, default options, timing cues and wording that could push users toward a particular choice	Annotated user journeys, copy inventory and records of default settings	Persuasion features such as countdowns, pre-selected options or urgency language never tested
Persuasion logic review	Whether the system adapts its messages to individual traits, emotional state or vulnerabilities, and what techniques the model or rules apply	Description of personalization logic, prompt or rule templates and any optimization objectives	Optimization targets that reward conversion or engagement with no harm limit set
Harmful distortion testing	Whether test users are materially influenced into decisions they would not otherwise take, and whether the effect appreciably impairs informed choice	Test plans, user study or simulation results, adversarial prompt runs and pass or fail criteria	No testing of distortion outcomes, only accuracy or satisfaction metrics
Harm analysis	Whether a distorted decision is reasonably likely to cause significant harm to the person, another person or a group	Documented harm scenarios, severity and likelihood reasoning and affected-group analysis	Missing harm analysis, or harm treated as a purely commercial loss
Documented decision analysis	Why each flagged feature was judged compliant or changed, and who approved the decision	Decision log with rationale, legal review sign-off and version history of design changes	No record of why a design was judged compliant
Monitoring of real outcomes	Whether live behavior is watched for distortion patterns, complaints and harm signals after launch	Monitoring dashboards, trace or log samples, incident records and corrective action history	Monitoring limited to uptime and usage, with no outcome or complaint review
Legal characterization	Whether the practice amounts to a prohibited technique is a question for the competent authority	Counsel's analysis and the assessor's notes separated, so each party's view is clear	Assessor or consultant presented as the final voice on whether the ban applies

Implementing the manipulation review step by step

This sequence takes an organization from an unknown set of persuasive AI features to a documented, tested and reviewed position under the Article 5(1)(a) ban. Each step closes with a named record, so the file can be shown to an assessor or market surveillance authority. The organization owns the decisions, and any outside help prepares the evidence.

Inventory every AI feature that influences choices
Start with a complete list of AI-enabled features that touch a user's decision, including recommendations, nudges, offers, ranking, persuasive copy, chat assistants and interface prompts. Include features built on third-party models and features a vendor embeds in a product you deploy. The product owner and the compliance lead should agree the scope in writing. The output is a feature register that names each system, its provider, its purpose, the users it reaches and whether it operates in the EU. The step is complete when product and engineering confirm that nothing shaping a choice is missing.
Classify each feature against the three elements
For each register entry, test the feature against the three elements in Article 5(1)(a): a technique that is subliminal, purposefully manipulative or deceptive; an objective or effect of materially distorting behavior by appreciably impairing informed decision-making; and a resulting decision the person would not otherwise have taken that causes, or is reasonably likely to cause, significant harm. Record a yes, no or unclear answer for each element, with a reason. Features that clear all three elements go to deeper review, and unclear entries go to legal counsel. The output is a classification memo with a reason for every entry.
Run behavioral testing on persuasive outputs
Test the in-scope features with controlled prompts and scenarios, comparing outputs against a neutral baseline. Check for urgency cues, unverified claims, selective framing, emotional pressure and hidden defaults, and record whether each output shifts a choice. Open-source tools can support the language model layer. garak probes models for misinformation and other failure modes and writes a JSONL report of every attempt plus a hit log of findings. Confirm with the vendor whether its probes cover persuasion or deception, and add tests for anything it misses. The output is a test report per feature with prompts, outputs and pass or fail notes.
Capture traces that show the decision path
Influence often comes from a chain of retrieval, prompts, tool calls and ranking logic, so a single output is weak evidence on its own. Enable tracing on the production path, for example with Langfuse, which records inputs, outputs, tool executions, token usage and metadata for each operation in a request. Agree retention and access rules with the data protection team, because traces can contain personal data. The output is a trace sample for each in-scope feature showing how the influence reached the user.
Document the harm and decision analysis
For each feature that still shows a distorting effect, write a decision record. Describe the affected user group, the decision the user made or was steered toward, the harm that could follow, its severity and who bears it. Address the three elements one at a time so an assessor can follow the reasoning. Check separately whether the vulnerability ban in Article 5(1)(b) applies to the same group. Involve legal, product and a privacy or ethics owner, and name the person who accepts any residual risk. The output is a signed decision record per feature stating whether the ban applies and why.
Apply design changes and log them
Change the features that fail. Typical changes include removing unverifiable claims, replacing pressure language with neutral information, disclosing defaults and AI involvement, adding a confirmation step before consequential choices, or retiring a persuasive mechanic altogether. Retest each change against the same scenarios used in the original tests. Keep every change in version control with a reference to the decision record it answers. The output is a change log linking each failed test to its fix and its retest result.
Set up recurring review and triggers
Schedule the review and attach triggers to it. Re-run the register and classification whenever a new model, prompt, ranking rule or persuasive feature is released, when a complaint or incident involves user choices, and when Commission guidance or the Act's text changes. Assign a named owner and keep the register, test reports, decision records and change log together so they can be produced on request. Confirm the review interval in your governance policy, since this page does not set one. The output is a dated review log that shows each review and its outcome.

Evidence that shows a manipulation review holds up

Article 5(1)(a) turns on what a system does to people in practice, so the evidence has to show what the system was designed to do, how it was tested and what it actually does after launch. The artifacts below connect design intent, test results and live behavior, and each needs a named owner and a review trigger to stay current.

Feature register

A register listing every user-facing feature, prompt pattern, nudge, default and personalization rule the AI system uses, with its purpose, the persuasion technique it relies on and the date it was last reviewed. Keep it current by requiring an entry before any release that changes what users see or how the system responds. Check that each entry names the decision it could influence, since Article 5(1)(a) reaches only techniques that materially distort decisions.

Design and persuasion review records

Signed records showing that a reviewer assessed each feature for subliminal, manipulative or deceptive elements, including urgency cues, framing, default options and anthropomorphic language. The record should state the reviewer's conclusion and the reasoning behind it. Refresh it at each release and whenever the model, prompt or interface changes, because a review of an earlier design does not cover the new one.

Adversarial and behavioral test results

Documented test runs that try to get the system to pressure, mislead or hide material information from users, with the prompts used, the outputs observed and pass or fail results. Open-source probes such as garak can supply repeatable attempts for language model systems, but they cover generic failure modes, so add scenario tests written for your own use case. Rerun the suite after every model or prompt change and record the version tested.

Harm analysis

A written analysis of who could be harmed if the system distorted a decision, which decisions are affected (for example, a purchase, a loan acceptance or a health choice), and how likely and serious the harm would be. Article 5(1)(a) requires significant harm or a reasonable likelihood of it, so the analysis is the document that shows why the threshold was or was not met. Update it when the user population, the decisions involved or the sector changes.

Change records for redesigns

Version-controlled records linking each redesign of prompts, interface flows, recommendation logic or model choices to a new or updated feature register entry and review. Each change record should show who approved it, what the manipulation review concluded and which tests were rerun. Without this link, a later complaint cannot be traced to the design decision that caused it, and the review cannot show it covered the change.

Production monitoring logs

Logs of live interactions, including inputs, outputs and any escalations or user complaints about pressure, deception or unexpected steering. Observability tools such as Langfuse can record traces of model calls, tool use and outputs, which helps reconstruct how a decision was influenced. Confirm your retention period and access controls with your legal team, because the logs may contain personal data that GDPR also governs.

What meeting Article 5(1)(a) costs in money and effort

Most of the work to show Article 5(1)(a) is covered is internal: listing every AI system that uses persuasive, nudging or interface-driven features, documenting the intended purpose and the decisions each system influences, and testing whether the system could materially distort behavior in a way that causes significant harm. The largest cost is staff time from product, data science, security and compliance, and it is largely one-time for the first review and recurring each time a feature changes.

Engineering time: Product and ML teams trace prompts, ranking logic, recommendation outputs and UI copy back to the decisions they influence.
Testing tools: Open-source probing and logging tools such as garak and Langfuse can be run in-house, but licensing is zero only for the software itself; hosting, storage and the people who read the output are still costs.
Monitoring upkeep: Trace review and periodic re-testing after model or prompt changes recur for as long as the system runs.
Documentation: Records of intended purpose, known harms and mitigations take time to keep current.

Ask your team to estimate hours per system, separating the first review from quarterly upkeep, and confirm who signs off the conclusion.

Open-source tools that produce manipulation test evidence

This table compares three open-source tools that can generate evidence relevant to Article 5(1)(a) testing: garak for probing language models, Langfuse for tracing requests, and CISO Assistant for recording assessments. Read each row as what the tool produces and what it leaves to your own legal and governance work, because none of them decides whether a system is compliant.

Tool	What it produces	Licence	Limits for Article 5(1)(a) evidence
garak (probing)	JSONL reports of every probe attempt and evaluation, plus a hit log of attempts that found a vulnerability	Apache-2.0	Probes cover prompt injection, misinformation, toxicity and jailbreaks. Manipulation-specific test design, scenarios and pass criteria must be written and justified by your team.
Langfuse (tracing)	Traces of each request with LLM calls, retrieval steps, tool executions, timing, inputs, outputs, token usage and metadata	MIT	Traces show what the system did and said. Judging whether an output materially distorted a user's decision still requires human review and documented criteria.
CISO Assistant (records)	Tracked assessment records, audits and compliance assessments against chosen frameworks	AGPL-3.0-only	Stores the paperwork around testing and sign-off. It does not run manipulation tests or classify a system under Article 5.
Evidence chain	Test results from garak, production traces from Langfuse and approvals recorded in CISO Assistant	Mixed open-source licences	Confirm with counsel which combination of records your regulator or auditor will expect, and retain them under your own retention policy.

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

Your organization owns the legal judgment on whether a system uses subliminal, purposefully manipulative or deceptive techniques, and whether that use is reasonably likely to cause significant harm. Only you can decide whether a design choice, a persuasion pattern or a nudge in the user interface falls inside the ban, and you carry the fines if you get it wrong. Legal, product and risk owners should record that decision before release.

Decision record: Keep a dated written assessment for each AI feature that influences user choices, stating the techniques used, the decisions targeted and the harm considered.
Product changes: Own the design fixes, such as removing dark patterns, changing default options or adding friction before irreversible decisions.
Accountability: Name an owner for each system who signs off on the assessment and reviews it when prompts, models or interfaces change.
Provider and deployer split: Confirm which role you hold, since both placing on the market and using the system are covered.
Escalation: Define who can stop a feature in production when a complaint or test result suggests harmful manipulation.

Before relying on any assessment, confirm with counsel how the Commission's guidelines of 4 February 2025 apply to your specific use cases.

Where teams usually fall short on the manipulation ban

Most gaps in Article 5(1)(a) work are not technical. They come from treating persuasive design as product copy, skipping the harm analysis, and testing a system without asking whether it changes what people decide. The cards below cover the gaps assessors and market surveillance authorities are most likely to find, each with a closing action.

Dark patterns treated as UX

Teams often assign interface nudges, urgency timers and default options to design or growth, outside the AI review. When an AI system chooses which message, offer or framing a user sees, that selection is AI conduct and falls within the scope of Article 5(1)(a) if it is purposefully manipulative or deceptive. Bring personalization logic into the AI inventory so design decisions made by a model receive the same review as any other model output.

No harm analysis on record

The prohibition only reaches distortion that leads a person to a decision they would not otherwise have taken and that causes, or is reasonably likely to cause, significant harm. Many teams never write that chain down, so they cannot show why a system falls outside the ban. Write a harm analysis for each user-facing decision point that names the decision, the likely harm, the affected group and why the harm is not significant.

Testing for accuracy only

Evaluation suites usually measure whether outputs are correct, relevant or on policy. Distortion is a different property: a fully accurate message can still impair a person's ability to make an informed decision through framing, urgency or selective emphasis. Adversarial probing tools such as garak can help test for jailbreaks and misinformation, but teams must also design tests that measure decision changes in users, such as comparing choices made with and without a given prompt pattern.

No link to the 5(1)(b) review

Article 5(1)(a) covers manipulation in general, while Article 5(1)(b) covers exploitation of age, disability or a specific social or economic situation, which does not require manipulative techniques. Teams that review one and not the other miss cases where a vulnerable group is targeted with ordinary persuasive content. Run both prohibitions in a single review with the same user segments, so a finding under one informs the other.

No post-launch monitoring

A system that passes review at launch can drift as prompts, ranking logic, models and user populations change. Without monitoring, a team cannot show that the effect on behavior stayed below the threshold after deployment. Traces that record inputs, outputs and tool calls, such as those captured by Langfuse, can provide the data for this review. Set a recurring review of trace samples and define the triggers that reopen the harm analysis.

No documented legal reasoning

The Commission's guidelines of 4 February 2025 explain the prohibited practices with legal analysis and practical examples, yet many files contain only a conclusion that the system is compliant. Assessors and authorities look for the reasoning: which element of the prohibition was considered, what evidence was relied on and who approved the decision. Keep a dated legal memo that maps each element of Article 5(1)(a) to the evidence and is signed off by a named owner.

Questions buyers ask about the manipulation prohibition

What does an Article 5(1)(a) review cost and what drives the price?

No fixed price applies to this review, and the Act does not set fees for it. The cost depends on the number of AI systems in scope, whether a system interacts with people or generates persuasive content, how many user journeys and decision points must be tested, and how complete the design records and logs are. Costs fall into three groups: internal staff time from legal, product and data teams, external advisers or testers paid by the organization, and tooling. Initial assessment is one-time work. Re-review after model, prompt or interface changes recurs. DeployOpen provides quotes only from a written scope, so ask for the systems covered, deliverables, assumptions and what the client must supply before comparing offers.

How long does a manipulation prohibition review take?

No review duration is supplied for this work, so treat any figure you hear from a vendor as unverified. Length depends on the number of systems, access to logs and test environments, the availability of product and legal decision-makers, and whether user testing or remediation is needed. The timing pressure comes from the calendar: Article 5 has applied since 2 February 2025, so systems already in use fall under the prohibition now. Ask for milestones, dependencies and acceptance criteria in the written scope, and confirm which items depend on the client's own availability.

What does the client need to provide for an Article 5 review?

The client owns its systems, decisions and legal conclusions, so it must supply the material that shows how the system behaves. Typical inputs include:

Purpose statements, intended users and deployment contexts for each system
System prompts, interface flows, nudges, default settings and persuasive design elements
Logs or traces of representative interactions, such as those captured by observability tools
Complaint, incident and user-feedback records that show possible harm
Named owners who can approve changes and interpret the Article 5 conditions
A test environment that mirrors production

An implementation partner can prepare systems and evidence from these inputs, but only an independent auditor or assessor issues reports.

Can we run an Article 5(1)(a) review in-house?

Yes. The prohibition binds providers and deployers directly, so the organization can carry out the assessment itself. The work needs three skills: legal reading of the conditions (a subliminal, purposefully manipulative or deceptive technique, a material distortion of behavior, and significant harm), technical testing of how the system responds to users, and product or UX review of design choices. The hardest judgment is whether a distortion is likely to cause significant harm. The Commission's guidelines of 4 February 2025 explain the prohibited practices with legal analysis and practical examples, and they are a sound starting point for an internal method. Document each conclusion and the evidence behind it.

Is there a certification for the manipulation prohibition?

No. Article 5(1)(a) is a ban, not a requirement that a system can be certified against. The Act's conformity assessment routes, including internal control under Annex VI and the notified body route in Article 43, apply to high-risk AI systems and do not issue a compliance certificate for Article 5 practices. An organization can still commission an independent assessor to review its systems and report findings, but that report is an opinion within the agreed scope, not a certificate under the Act. Confirm the scope, wording and intended audience of any report with the assessor and with the national market surveillance authority for your use case.

What are the fines under Article 99(3) for manipulative AI?

Breaching the manipulation prohibition can bring fines of up to EUR 35 million or, for an undertaking, 7% of total worldwide annual turnover for the preceding financial year, whichever is higher. The higher-of rule means that for large groups the percentage figure is usually the larger amount. National market surveillance authorities enforce the Act for AI systems, so the authority in each Member State where the system is placed on the market, put into service or used will assess the case. Fines are a reason to document design choices and testing early, because the evidence is what an authority will ask to see.

How DeployOpen works on this

DeployOpen helps organizations plan, build and document the technical evidence that shows an AI system does not use manipulative or deceptive techniques under Article 5(1)(a). The organization keeps ownership of its legal position and conclusions, while DeployOpen prepares systems, testing and records in the organization's own infrastructure.

How we scope

Agree in writing which AI systems, interfaces and user journeys fall inside the Article 5(1)(a) review.
Record which teams own the legal assessment, the product decisions and the technical testing evidence.
Engagements are fixed-scope, so deliverables and timelines are confirmed before any work starts.

How we build

Deploy self-hosted open-source platforms inside the client's cloud accounts, data centers or air-gapped networks.
Configure tracing so prompts, outputs and decision points can be reviewed against the harm criteria.
Run deception and manipulation probes against language model features and record each attempt and result.

How we hand over

Deliver the test plan, probe logs, trace configuration and records of each review decision.
Document the boundary between the ban in point (a) and the vulnerability ban in point (b) for each system.
Confirm with the client's counsel which findings require escalation and which need design changes.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the initial handover.
Re-run manipulation tests whenever prompts, models, interface design or incentive logic changes.
Ask your legal and compliance advisers to confirm the final position, since only they can issue that conclusion.