Surveillance Pricing Is the AI Privacy Story Regulators Actually Care About Right Now

If you work in privacy engineering or product compliance, you've probably spent the last two years tracking model safety frameworks, AI executive orders, and voluntary commitments from frontier labs. Reasonable. But the specific AI use case that regulators are actually investigating, legislating, and preparing to enforce against right now is narrower and more concrete: surveillance pricing. The practice of using personal data to charge different consumers different prices for the same product. This is the privacy enforcement vector that's moving fastest, and most product teams aren't treating it that way yet.

Key Takeaways

• Surveillance pricing (using personal behavioral data to set individualized prices) is the AI application drawing the most concentrated regulatory action in 2026, with more than 40 bills across at least 24 states and active federal investigations.
• Regulators are enforcing through existing privacy law (CCPA, state UDAP statutes), not waiting for new AI-specific regulation. Your current privacy program is already the exposure surface.
• The legal distinction that matters: dynamic pricing responds to market conditions; surveillance pricing responds to the individual consumer. The second one is what's being banned.
• New state laws (Maryland, Connecticut, New York) don't just require disclosure. They prohibit the practice in covered industries, and they carve out loyalty programs only if the price wasn't derived from personal behavioral data.
• The emerging compliance requirement is provable data lineage: you need to demonstrate that a given price was not algorithmically derived from personal data, which is a technical architecture problem, not a policy statement.

What exactly is surveillance pricing?

Surveillance pricing is the use of detailed consumer data (location, browsing history, demographics, inferred behavioral patterns) to set individualized prices. The FTC has stressed that machine learning has made this practice scalable and, critically, hard for consumers to detect. You see a price. Someone else sees a different price. Neither of you knows.

The regulatory definition explicitly excludes ordinary dynamic pricing, the kind that responds to market-level signals like inventory, time of day, or aggregate demand. Surge pricing on a ride-share app when demand spikes citywide is dynamic pricing. Charging you specifically more because your browsing history suggests you'll pay it is surveillance pricing. Holland & Knight's April 2026 analysis lays out this distinction clearly: surveillance pricing responds to the individual consumer, not the market.

That distinction matters because it determines which side of the new laws you're on.

Why are regulators converging on this instead of broader AI risks?

Three reasons, all prosaic.

First, it touches everyday purchases. A privacy attorney quoted in Holland & Knight's mid-2026 review put it plainly: surveillance pricing draws outsized scrutiny because it involves groceries, hotel rooms, and household goods, not abstract model behaviors. Legislators can explain it to constituents in one sentence.

Second, there's already a concrete, publicized example. In December 2025, Consumer Reports found that Instacart charged different shoppers up to 23% more for identical items in the same store at the same time. That finding gave legislators a case study to point to, and it arrived shortly after the FTC's separate $60 million judgment against Instacart for unrelated deceptive practices.

Third, and this is the part product teams should internalize: regulators already have the legal tools. They don't need to wait for new AI-specific legislation to act. California AG Rob Bonta's investigative sweep, launched January 27, 2026, frames personalized pricing as a data-privacy compliance issue under CCPA's purpose limitation principle. Not an antitrust matter. Not a new AI regulation. Existing privacy law. Paul Weiss documented how this enforcement theory works: if you collected browsing data under a privacy policy that describes its use for "improving your experience," and then you fed that data into a pricing model, you may have exceeded the stated purpose. CCPA already covers that.

This is why we keep telling our own team: the compliance exposure is live under laws most companies think they've already handled.

What has actually been passed or signed into law?

The legislative pace in 2026 has been fast. Here's the concrete timeline.

On April 28, 2026, Maryland's governor signed the Protection from Predatory Pricing Act, making it the first state to ban surveillance pricing in certain industries (food retail, specifically). This isn't a disclosure requirement. It's a prohibition.

Connecticut followed. SB 4 was signed May 27, 2026, effective October 1, 2026, banning surveillance pricing as part of a broader privacy overhaul.

New York's One Fair Price Act passed the legislature on June 10, 2026, and is awaiting Governor Hochul's signature. AG Letitia James is publicly pushing for the signature.

California's pending AB 2564 would impose fines of $12,500 per violation. Per violation. Not per complaint.

As of April 2026, more than 40 bills across at least 24 states address surveillance pricing in some form. The definitions vary by state, which creates its own compliance problem, but the direction is uniform.

What's happening at the federal level?

On March 5, 2026, the House Oversight Committee launched a formal investigation, sending letters to major travel and platform companies. The committee characterized the practice as a "black box" in which algorithms infer willingness to pay and adjust prices without consumer awareness.

In April 2026 congressional testimony, FTC leadership confirmed that staff work on surveillance pricing continues and the agency is assessing whether additional disclosures may be required when pricing is highly personalized or data-driven. The FTC has also signaled something worth paying attention to: even when companies deny using personal data for pricing, opacity or inconsistent consumer-facing explanations can independently trigger investigation. Scrutiny extends to how pricing systems are described, not just how they operate.

There's also a federal preemption question looming. A December 2025 White House Executive Order on AI policy directs federal agencies including the FTC to consider issuing a policy statement on when federal law preempts state AI and pricing mandates. If you're building compliance infrastructure for the state patchwork, be aware that a federal preemption fight could reshape the landscape. We don't know which direction that goes.

Why does this matter more to product teams than "AI safety" broadly?

Because it's a data-minimization failure, not a model-safety failure.

The regulatory throughline here isn't about model alignment, hallucination risk, or whether your AI can be jailbroken into saying something harmful. It's about what data feeds the pricing algorithm and whether that data's use exceeds what a reasonable consumer would expect. That's the CCPA purpose-limitation theory California is applying.

If your product architecture doesn't ingest granular behavioral signals or location data into pricing logic in the first place, you're structurally exempt from an entire emerging compliance category. That's not a hypothetical advantage. It's a concrete one. Privacy-by-design, in this specific case, beats retrofitted AI governance because the enforcement theory targets the data input, not the model output.

For product teams running A/B price tests, personalized offer engines, or "smart pricing" features: audit what signals feed those systems. If the answer includes browsing history, device fingerprints, location data, or inferred demographic attributes, you're inside the scope of these laws. If you're using aggregate demand curves and inventory levels, you're probably outside it. The line is that specific.

What technical requirements do the new laws create?

The most consequential new requirement is provable data lineage.

Here's why. The state laws that have passed or are pending generally carve out legitimate discounts and loyalty programs. New York's One Fair Price Act, for instance, doesn't ban all price variation. It bans price variation derived from personal data. This means companies now need to prove, not merely claim, that a given price wasn't algorithmically derived from an individual's behavioral profile.

That's an engineering problem. Specifically, it requires:

• Data lineage tracking: for any price shown to a consumer, you need to trace which data inputs influenced it and demonstrate that none of those inputs were personal behavioral data in the prohibited sense.
• Feature flagging and isolation: if your pricing model ingests both market-level signals (inventory, demand curves) and individual-level signals (browsing history, purchase frequency), you need architectural separation that lets you demonstrate which features were active for a given price decision.
• Explainability logs: an audit trail showing why a price was set at a particular level for a particular transaction, granular enough to satisfy a regulator asking "was this price personalized?"

This is distinct from generic "AI ethics" documentation. It's closer to what privacy engineers already do for data subject access requests under CCPA or GDPR, but applied to the pricing pipeline specifically.

How strong is public support for these bans?

Strong enough that legislators face minimal political risk. Polling from Groundwork Action and Data for Progress found roughly 76-77% of Americans and New Yorkers support banning surveillance pricing outright, not just requiring disclosure. That's not a slim majority. That's the kind of number that makes "ban" politically easier than "regulate with nuance."

For founders, this polling data matters because it suggests the trend accelerates rather than stalls. When three-quarters of the public supports an outright ban, the legislative incentive is to pass one, not to negotiate a disclosure framework.

What does the state patchwork mean for compliance?

It means complexity. Sheppard's analysis details how the definitions vary by state: Maryland's law covers food retail specifically; Connecticut's is embedded in a broader privacy statute; New York's applies more broadly. The covered industries, definitions of "personal data," and carve-outs for loyalty programs all differ.

If you operate nationally, you can't just comply with the strictest law and call it done, because the strictest law in one dimension (scope of covered industries) might be the most permissive in another (what counts as a loyalty program exemption). Faegre Drinker characterizes surveillance pricing as "the next frontier of privacy litigation", and the patchwork is a big reason why. Inconsistencies create litigation surface area.

The practical response, if you're a product team, is to treat the most restrictive interpretation as your baseline and build the architectural separation described above. The alternative, maintaining different pricing logic per state, is fragile and expensive.

How should privacy teams reframe their priorities?

Start by accepting that regulators are using privacy law, not AI law, as the enforcement vehicle. This has a concrete implication for how you allocate resources.

If your team has been building an "AI governance" program focused on model cards, bias audits, and responsible-use policies while leaving pricing systems to the product or revenue team, you have a gap. The pricing pipeline is now a privacy-regulated system. Your CCPA data mapping, your purpose-limitation documentation, your data subject rights infrastructure: all of it needs to extend to cover how pricing decisions are made and what data influences them.

Corporate Compliance Insights notes that regulators are watching not just the practice itself but how companies describe their pricing systems to consumers. If your privacy policy says data is used for "personalization" and your pricing engine uses behavioral data to set prices, a regulator could argue you disclosed it. If your privacy policy says data is used for "improving services" and you're feeding it into a pricing model, that's a purpose-limitation violation. The words in your privacy policy are now load-bearing for your pricing compliance.

Where does this leave the broader AI regulation landscape?

Surveillance pricing is instructive because it shows the pattern regulators will likely follow for other AI use cases: reach for existing statutes first, legislate specifically second, and address abstract model-level risks later (if at all).

The FTC isn't writing new rules about large language models. It's using Section 5 unfair-and-deceptive-practices authority it's had for decades. California isn't passing an AI pricing law. It's enforcing CCPA. This pattern, applying existing privacy and consumer-protection frameworks to specific AI-driven practices, is probably how most near-term AI enforcement will work.

For us, this validates a straightforward thesis: privacy infrastructure matters more than AI-specific governance frameworks, because privacy law is what regulators are actually using. We built Selina around the idea that the less personal data your systems ingest, the smaller your compliance surface. Memory in Selina is encrypted at rest and protected by design, though we should be honest: memory is NOT end-to-end encrypted, because a slice of each request reaches a frontier provider at inference. Files and transfers via SelinaSEND are end-to-end encrypted. Operational metadata is kept for a short retention window. We state these limits plainly because the entire point of a privacy architecture is knowing exactly where the boundaries are.

That same principle applies to pricing systems. Know exactly what data goes in. Know exactly where it goes. Be able to prove both to a regulator. The companies that can do this will find the surveillance pricing wave manageable. The companies that can't will find it expensive.

What should you do this quarter?

Five concrete steps, none of them dramatic:

1. Audit your pricing pipeline's data inputs. Catalog every signal that influences a price shown to a consumer. Flag any that constitute personal data under CCPA or the new state laws.
2. Review your privacy policy's description of data use. If "personalization" or "improving your experience" could be read to encompass pricing, either update the language or stop using personal data for pricing.
3. Build or plan data lineage for pricing decisions. You need to be able to answer the question "was this price influenced by personal behavioral data?" for any given transaction.
4. Track the state patchwork. Maryland and Connecticut are effective October 1, 2026. New York is pending signature. California's AB 2564 could move. The AI Laws by State tracker is a reasonable resource.
5. Brief your legal team on the CCPA purpose-limitation enforcement theory. If they're thinking about surveillance pricing as an antitrust or pricing-regulation issue, they're looking at the wrong statute.

None of this requires a new platform, a new vendor, or a new org chart. It requires your privacy team and your product team to look at the same system at the same time. Which, if we're honest, is what privacy engineering was always supposed to be.

If you're rethinking how your tools handle personal data, start a free 7-day trial of Selina, no card required.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

• www.upwork.com
• x.com
• medium.com
• selinalabs.io