When to Widen an AI Feature to Users Who Never Opted In

Consent validity and dark pattern enforcement have converged on the same design rules, and they are stricter than most product teams assume. Regulators treat pre-checked boxes, company-preferred defaults, confusing toggles and settings buried behind vague names as manipulative design. Reed Smith's compliance alert lists exactly these as examples of design methods regulators may deem dark patterns, and notes that state privacy laws including the CCPA, the Colorado Privacy Act and the Texas Data Privacy and Security Act now expressly prohibit using dark patterns to obtain consent.

Usercentrics adds the EDPB's six categories from Guidelines 03/2022: overloading, skipping, stirring, obstructing, fickle and left in the dark. Two of those map directly onto AI feature launches. "Obstructing" is the feature you cannot turn off without contacting support. "Left in the dark" is the feature that is running before the user has any idea it exists.

The interface contract that survives both tests is short:

1. A single interstitial at first exposure. One screen, plain language, stating what the feature does, what data it touches and what happens by default.
2. Two equally weighted buttons. "Keep it on" and "Turn it off" at the same visual weight. No grey text link, no pre-ticked box.
3. A persistent one-step control. The same toggle reachable from the feature surface itself, not three menus deep. Turning it off takes effect immediately, not at the next billing cycle.
4. A record. Log the exposure event, the notice version shown and the user's choice, because the balancing test asks you to demonstrate your safeguards.

A useful sanity check before shipping: hand the screen to someone who has never seen the product and ask them to turn the feature off. If they cannot do it in one step without help, you have a support ticket and possibly an enforcement risk.

Widening is a sequence of exposure levels, not a binary switch. The mechanics are well understood from canary deployments, which Google Cloud describes as splitting traffic between an already-deployed version and a new version, rolling it out to a subset of users before rolling out fully (Google Cloud documentation). Percentage rollout flags use consistent hashing so that the same user stays in the same bucket across requests, which is what makes a holdback group trustworthy (OneUptime).

The key insight most teams miss is that AI features need flags around configuration, not just code. Model identifiers, prompt templates and parameters often change without a git commit, which means the deployment pipeline has no record of the change and nothing to roll back. GrowthBook's guide to flagging AI models makes this argument directly and notes that AI failures are probabilistic: a change can work on 999 inputs and fail on the thousandth, so production exposure is the only real test.

Microsoft's staged rollout guidance for cloud authentication offers a transferable pattern with an explicit warning: staged rollout is a temporary testing mechanism, it should be used only for pilot groups, and you should maintain a fallback path during testing rather than leaving everyone in the staged state indefinitely (Microsoft Learn). Applied to AI features: the "default-on for everyone" state needs its own decision record and a defined way back.

A staged plan with gates looks like this.

The permanent holdback at stage 3 costs you a small slice of adoption and buys you the only clean comparison you will ever have. Keep it, and keep measuring it.

The failure literature on AI rollouts is consistent on one point: teams that define success after the fact cannot defend the result. The Institute of AI PM reports that 73 percent of failed AI projects had no agreed definition of success before starting, and that projects with quantified success metrics defined upfront achieved a 54 percent success rate versus 12 percent for those without (Institute of AI PM). That source also notes 61 percent of pilots were approved with no plan for what happens if they succeed.

For a widening decision, write the gate as a sentence with numbers before stage 1 begins. Example: "We advance to 25 percent exposure if, over 14 days, the exposed group's task completion rate is no more than 1 percentage point below the holdback, support tickets tagged to the feature stay under 4 per thousand exposed users per week, and the share of exposed users who turn the feature off stays under 15 percent." Every clause is measurable from the events you already log, and every clause has a threshold someone can contest later only by pointing at data.

Two measurement traps are worth naming. First, mix shift: if you widen to a market with different baseline behavior, any change in the aggregate metric may reflect the new population rather than the feature. Compare exposed versus holdback within each stage, never across stages. Second, silent failure: Rubicon's stage-gate model points out that production needs an evaluation set and thresholds, because without a golden dataset nobody can say whether the system is good enough and the decision keeps slipping. Carry your evaluation set forward from the opt-in cohort and run it against every widening stage.

Support is the constraint that widening exposes first, and it is the one least often modeled. Opt-in users are self-selected for tolerance; default-on users are not. The people who never opted in will file the tickets, and they will file them on day one of the widest stage.

Build the forecast from observed numbers rather than intuition. If your opt-in cohort of 2,000 users generated 30 tagged tickets over four weeks, that is roughly 15 tickets per thousand users per month. Do not multiply that rate by your full user base and call it a forecast. Opt-in cohorts typically run below the default-on rate because volunteers self-select for enthusiasm. Apply a multiplier you can defend, and state it in the plan: if you assume default-on generates 2.5 times the opt-in rate, then 100,000 users at 15 per thousand becomes 3,750 tickets per month, which is a staffing decision, not a footnote. Track the realized rate at stage 1 and replace the assumption with the measurement before stage 2.

Support readiness also includes the failure path. Continuity planning guidance for AI systems argues that when automation takes over a process, the humans who used to run it lose familiarity, so the manual fallback exists on paper but not in practice (Continuity Insights). For a default-on feature this matters twice: your support agents need a script for "the AI gave me something wrong," and the feature needs a degraded mode where it stays useful when the model is unavailable. The training material on enterprise AI continuity recommends defining fallback operating modes by risk, telling users clearly when capability is reduced, and logging what happened (AI continuity module). A rollback plan deserves a rehearsal, not just a document, because a rollback strategy on paper is untested until you have deliberately broken something in staging and restored it (Ispirer).

Run this checklist as a go or no-go meeting before every widening stage, with legal, support and engineering in the room.

The metrics that gate each step should be a small set you actually look at: task completion rate for exposed versus holdback, feature off-switch rate, tagged ticket rate per thousand exposed users, complaint or escalation rate, latency of the feature surface, and cost per active user against budget. If any of the first three breach their thresholds, the correct action is to step back one stage, not to wait and see. The growth of the feature is a sequence of reversible decisions, and reversibility is the whole point of the exercise.

When the work moves from a single feature to a portfolio of them, the question of who holds the model layer and who owns the outcome becomes the next constraint. Teams running several models behind one product often consolidate onto a single access path for text, image, audio and embeddings; Quanta Inference provides that single key and is priced in US dollars with prepaid billing. Before the next widening decision, a structured review of goals and a tailored recommendation can be worth the half hour: a free AI discovery call covers exactly that ground, with no obligation.