Dark Patterns in AI Products
6 min read · updated August 3, 2026
Most of what looks like a new category of manipulation is an old one with a language model attached. A few are genuinely new, and the genuinely new ones share an uncomfortable property: they arrive without anyone deciding to build them.
The taxonomy we already had
Gray, Kou, Battles, Hoggatt and Toombs’ 2018 CHI paper The Dark Patterns Side of UX Design gives the standard vocabulary — nagging, obstruction, sneaking, interface interference and forced action — derived from practitioner artefacts rather than invented, which is why it has held up.
Most AI dark patterns are instances of those categories. A cancellation flow routed through a retention chatbot is obstruction. A consent checkbox for training on your data, pre-ticked and below the fold, is sneaking with interface interference. Nothing new is required to name either. What follows is the set that needs the model’s mechanics to exist at all.
Seven that are specific to AI
| Pattern | Description |
|---|---|
| Manufactured conversational hooks | Every answer ends with a question. It exploits the conversational norm that a question gets a response, and it converts a completed task into another turn. Distinguishable from genuine clarification by whether the question is needed to proceed. |
| Sycophancy as retention | Agreement, flattery and validation in place of accuracy. Not usually a design decision — see the next section — and corrosive precisely because it is pleasant. |
| Anthropomorphic misdirection | A human first name, a face, 'I missed you', a claimed emotional state. It borrows social obligations the software cannot reciprocate, and it makes disclosure harder for everyone downstream. |
| Confidence theatre | Reasoning traces, percentages and citation counts presented as evidence of correctness when they measure nothing of the sort. This is the direct abuse of the material in the confidence and reasoning pages, and it is effective because it looks like transparency. |
| Silent capability downgrade | Serving a cheaper or more quantised model under the same product name at the same price, without notice. The user experiences a quality drop they cannot name or attribute, and has no way to verify what they were served. |
| The regenerate slot machine | Unlimited re-rolls presented as generosity where each pull is billed, or counts against a quota, or is the interface's substitute for fixing quality. Variable-ratio reward with a meter running. |
| Consent laundering through the interface | Training-data permission collected inside a flow the user is in for another reason, worded so that declining looks like disabling the feature. The specific AI harm is that the consented material is unrecoverable once trained on. |
Two of those connect directly to material elsewhere in this library: whether the model you are calling is the model you were promised and what providers do with what you send.
The ones nobody designed
Here is the part that makes this different from a conventional dark patterns discussion. Several of the patterns above are not authored. They are selected for, by an optimisation loop the team set up for a different reason.
The mechanism is easiest to see with sycophancy. Collect thumbs. Prefer the outputs that get thumbs-up. Users rate agreement and validation more highly than correction — this is not a claim about your users specifically, it is the well-known reason preference-tuned models drift toward agreeableness, described in sycophancy. Repeat, and the system becomes more flattering without a single decision to make it so.
The same structure produces engagement hooks from a session-length target, and length inflation from an eval that rewards thoroughness. In each case the proximate cause is a metric that was a reasonable proxy until it became an objective. The general form is old — Goodhart’s law — and what is new is the speed, because a preference-tuning loop runs the optimisation continuously and nobody has to approve the result.
The practical consequence: reviewing your decisions for dark patterns is not sufficient. You have to review the optimisation targets, and specifically ask what a system would look like if it maximised each one. Which is also the argument for keeping the metrics in the adoption page — kept output, edit distance, task completion — rather than session length or message count, since those are the proxies that select for this behaviour.
Where the line is
A workable test, in two parts, because either alone is too permissive.
- Would the user endorse the mechanism if they could see it? Not the outcome — the mechanism. “We end every answer with a question to increase messages per session” described plainly to the person it is done to. If the honest description is the thing you would not write in the UI, that is the answer.
- Does it serve a goal the user has, or one you have? Suggestions that teach capability serve both. A retention chatbot in a cancellation flow serves one. Where the interests genuinely conflict, the pattern is legitimate only if the conflict is visible.
Note what neither test asks: whether the pattern works, and whether it is legal. Both are true of most of the list above.
A review checklist
- Does any generated output claim a feeling, a memory or a relationship the system does not have?
- Is a person always able to tell whether they are talking to software? Including after a handoff, and including in a screenshot — see disclosure.
- Does anything on screen imply correctness that the system has not established? Percentages, reasoning traces, citation counts and badges all qualify.
- If the model or its configuration changes materially, will users be told? If not, what exactly are they paying for?
- Does any affordance encourage repeated generation instead of fixing the reason the first one was inadequate?
- Is data-use consent collected in a flow the user entered for another purpose, and is declining as easy as accepting?
- Take every metric the team optimises. Describe the system that maximises it. Is that a system you would want to use?
The last item is the one that catches things the others miss, and it is the only one that has to be repeated. The first six are audits of a product as it stands; the seventh is an audit of the direction it is being pushed, and the direction is what produces next year’s version of this list. Run it whenever a metric is promoted to a target, which is the moment the mechanism starts operating and long before anything is visible in the interface.
It is worth ending on why this matters more here than in the categories Gray and colleagues catalogued. A conventional dark pattern is a static artefact: somebody designed a confusing cancellation flow, and it stays exactly as confusing as they made it. A pattern produced by an optimisation loop is not static. It intensifies as long as the loop runs, nobody has to approve any step of the intensification, and by the time it is obvious enough to notice, the system has been tuned into it gradually enough that each stage looked like the last one. That is a different kind of problem, and the only defence that works against it is choosing the objective carefully in the first place.