State Privacy Law Patchwork Hits a New Gear: What New Jersey's Data Broker Law Means for AI Products

New Jersey now has the most expensive and arguably most expansive data broker registration law in the country. If you ship an AI product that builds user profiles, you need to understand whether this law applies to you. The privacy implications are not theoretical. The registration fees start at $5,000 and scale to $1.5 million annually. The sensitive-data sale ban carries a $50,000-per-record civil penalty. And the statute creates a category, "data collector," that exists in no other state's broker regime. This piece walks through what the law actually says, where AI products are likely to trip over it, and where the real regulatory gap (inference) still sits wide open.

Key Takeaways

• New Jersey's new data broker law (A.5328) creates a novel "data collector" category that can sweep in AI companies with direct user relationships if they share or license personal data downstream, even if they never think of themselves as brokers.
• Registration fees scale from $5,000 to $1.5 million per year based on consumer volume, making this the costliest state broker registration regime by a wide margin.
• A near-universal ban on selling sensitive data took effect immediately on June 30, 2026, with $50,000 per-record penalties. The registry itself won't launch until spring 2027, but the legal obligation to register exists now.
• The law's definition of "sale" omits exclusions found in New Jersey's own comprehensive privacy law, broadening the scope of what counts as a regulated transaction.
• AI-generated inferences (behavioral scores, health signals, sentiment analysis) may fall outside the statute's reach entirely, creating a gap that privacy-conscious builders should address architecturally rather than wait for regulators to close.

What Did New Jersey Actually Pass?

Governor Mikie Sherrill signed Assembly Bill A.5328 on June 30, 2026. The bill had been introduced two days earlier, on June 28, then approved by both chambers and signed in a 48-hour sprint. That timeline is worth noting because the speed drew immediate political backlash, and we'll come back to what that means for enforcement below.

The law does two things at once. First, it establishes a data broker registration regime administered by the Division of Consumer Affairs. Second, it amends the New Jersey Data Protection Act (NJDPA) to impose a near-universal ban on selling sensitive data, applying to all entities, not just those otherwise subject to the NJDPA.

The registration fees are the headline number, and they are not modest. Per Hunton's analysis, annual fees start at $5,000 for entities handling data on 100,000 consumers or fewer and climb to $1.5 million for those covering more than 4.5 million consumers. For comparison: California charges $6,000. Vermont charges $100. Connecticut charges $2,500. New Jersey is operating on a different scale.

What Is a "Data Collector" and Why Should AI Founders Care?

The law creates two regulated categories. The first, "data broker," is familiar: a business with no direct consumer relationship that collects, purchases, or receives personal data and then resells it. Most state broker laws stop there. New Jersey does not.

The second category is "data collector." This is a business that does have a direct consumer relationship, collects personal data from that consumer, and then sells or licenses that data to a data broker. New Jersey is the only state whose data broker law requires data collectors to register. This is the provision that makes the law uniquely dangerous for AI product companies.

If you run an AI assistant, a recommendation engine, a personalization layer, or any product that maintains user profiles, you almost certainly have a direct consumer relationship. You probably assumed that direct relationship puts you outside the data-broker perimeter. Under every other state's regime, you'd be right. Under New Jersey's law, the question is different: do you share, license, or transfer any of that user-sourced personal data to a downstream entity that itself qualifies as a data broker?

Think about your vendor contracts. Your analytics partners. Any arrangement where CRM exports, anonymized usage data, or profile-derived features flow to a third party that monetizes data. If that third party meets the data broker definition, you may have just become a regulated data collector. A direct customer relationship is not automatically a safe harbor under this statute.

Does My AI Product with User Profiles Count as a Data Broker?

It depends on what happens to the data after your product ingests it. The law's definitions hinge on downstream commercial activity, not on the existence of profiles themselves.

If your AI product collects personal data from users, builds profiles, and uses those profiles solely to deliver the product's core functionality (personalized responses, memory, recommendations) without selling, licensing, or sharing that data externally, you are likely not a data broker. You are also likely not a data collector, because you are not feeding data to a broker.

But "solely" is doing a lot of work in that sentence. Here's a non-exhaustive list of arrangements that could change the analysis:

• Licensing aggregated or anonymized user behavioral data to an ad-tech or analytics partner.
• Providing model-training datasets derived from user interactions to a third party.
• Revenue-sharing arrangements where a partner receives user-profile-derived data as part of the deal.
• Allowing a data enrichment vendor to match your user records against their database, where the vendor then resells the enriched output.

Any of these could pull you into "data collector" territory. The statute's definition of "sale" is unusually broad: it covers sharing, disclosing, or transferring personal data for monetary or other valuable consideration. Unlike the NJDPA's comprehensive privacy provisions, this definition contains no exclusion list. That missing exclusion list is a material difference. Activities that the NJDPA might exempt (service-provider processing, mergers, internal transfers) are not necessarily exempt under the broker statute.

What About the Sensitive Data Ban?

Separately from the registration regime, the law imposes a near-universal prohibition on selling sensitive data. This applies to all entities: data brokers, data collectors, controllers, processors. The penalty is $50,000 per record.

For AI products, the sensitive-data categories that matter most are the ones your model might store or surface: health information, biometric data, precise geolocation, sexual orientation, racial or ethnic origin, religious beliefs, and data concerning minors. If your AI product maintains memory or profiles that include any of these categories, and if any downstream flow of that data constitutes a "sale" under the statute's broad definition, you are exposed to per-record penalties that can compound fast.

The penalty structure is designed to be punitive. $50,000 per record, applied to a user base of even modest size, produces numbers that make the registration fees look trivial.

When Does This Take Effect?

The timelines are split, and the split is somewhat confusing. The underlying legal obligations, including the duty to register and the sensitive-data sale ban, took effect immediately on June 30, 2026. There is no grace period for the substantive requirements.

However, the Division of Consumer Affairs issued a July 10 alert clarifying that the public registry won't launch until spring 2027, with registration open from approximately April to June 2027. So the obligation to register exists now, but you cannot actually register yet. This creates a liminal period where you are technically required to do something the state has not yet built the mechanism for.

On top of that, the political situation adds another layer of uncertainty. Reports indicate that a senior official in the governor's office stated the governor will not enforce the Act until the legislature addresses "defects" in the law. The 48-hour passage drew criticism, and amendments are plausible before the registry goes live.

What this means practically: the sensitive-data sale ban is live and carries no announced enforcement pause. The registration mechanics are delayed. And the entire law may be amended before the registry opens. You should not rely on the enforcement pause as a compliance strategy. It is an informal political signal, not a legal safe harbor.

Are There Exemptions That Apply to AI Products?

Yes, the law includes narrow, activity-specific exemptions. These cover things like platform or e-commerce incidental activity, directory assistance, public professional information, financial and real estate services, health and safety alerts, and title or settlement services.

None of these are tailored to AI products. If your product happens to operate within one of the exempted verticals (say, a financial services AI tool), you may benefit from the relevant exemption. But a general-purpose AI assistant, a consumer-facing recommendation engine, or a productivity tool with user profiles is unlikely to fit neatly into any of the carved-out categories.

Do not assume an exemption applies without mapping your specific data flows to the statutory language. The exemptions are activity-specific, not entity-specific. You could be exempt for one data flow and regulated for another within the same product.

What About Inferred Data? The Regulatory Blind Spot AI Founders Should Understand

Here is where the law's scope gets interesting, and where its limits become apparent. The statute regulates the collection, purchase, sale, and licensing of personal data. It does not clearly regulate what a company concludes from that data.

This distinction matters enormously for AI products. If your model ingests a user's browsing history, purchase records, or message content and then generates an inference (a health risk score, a sentiment classification, a behavioral prediction, a political leaning estimate), that inference may not constitute "collected" or "purchased" personal data under the statute. It was generated, not collected. State privacy watchdogs have flagged that this inference gap is a systemic problem: privacy laws generally govern what companies can share and sell, but often do not extend to what those companies can conclude.

California's CPPA has started pushing against this boundary. The CPPA has alleged that creating and selling consumer profiles built from patterns and inferences constitutes data broker activity under California law. That enforcement posture could migrate east. But under New Jersey's current statutory text, the treatment of inferences is ambiguous at best.

If you are building an AI product that generates inferred attributes from user data, this ambiguity is not comfort. It is a timing problem. Regulators will eventually close this gap, either through statutory amendment or aggressive interpretation. The question is whether you want to build your data architecture around the current loophole or around the inevitable correction.

Why Self-Imposed Inference Controls Matter More Than Statutory Compliance

Statutory compliance is a floor. For AI products that generate sensitive inferences from user data, the floor is currently set low because the law has not caught up with the capability. This is a temporary condition.

If you architecturally prevent your product from generating, storing, or exporting sensitive inferred attributes (health conditions, political orientation, financial distress signals), you avoid a class of regulatory risk that no current statute fully addresses but that multiple enforcement agencies are actively working toward. You also avoid the reputational cost of being the test case.

This is where product architecture becomes a compliance strategy. If your system does not generate the inference, it cannot sell it, and it cannot be regulated for selling it. The absence of the data is a stronger defense than any contractual restriction on its use.

How Should AI Founders Audit Their Data Flows Under This Law?

Start with a concrete inventory. You need to answer five questions with specificity:

1. What personal data do you collect directly from users? This includes anything your product ingests as part of its core function: messages, documents, preferences, behavioral signals, uploaded files.
2. Does any of that data, or any derivative of it, flow to a third party? Check your analytics vendors, your infrastructure providers' data-use terms, any model-training data licensing agreements, and any revenue-sharing partnerships that involve data access.
3. Does any recipient of that data meet the definition of a data broker? A data broker under this law is an entity with no direct consumer relationship that collects or receives personal data and resells it. If your analytics partner or ad-tech vendor fits that description, and you are feeding them user-sourced data, you may be a data collector.
4. Does any of the data you collect or share qualify as sensitive under the NJDPA? If so, the sale ban applies to you regardless of your broker/collector status, with $50,000 per-record penalties.
5. What inferences does your product generate, and do any of them touch sensitive categories? Even if these are not currently regulated as "collected" data, they are a forward-looking risk. Follow your data before regulators do.

If you discover that any of your data flows trigger the data collector definition, you need to plan for registration fees that scale with your user base. For an AI product with 500,000 users in New Jersey, the annual fee alone could be substantial, before you even consider the compliance overhead of maintaining the registration.

Can You Structure Your Product to Stay Outside the Law's Reach?

Yes, but it requires architectural choices, not just contractual ones. Contracts that restrict downstream use of data are helpful but insufficient. The statute looks at the act of sharing or transferring data for valuable consideration, not at what the recipient promises to do with it.

The cleanest approach is to eliminate the regulated transaction entirely:

• Do not sell, license, or share user-sourced personal data with third parties whose business models involve reselling data.
• If you use third-party analytics, ensure your data-processing agreements are structured as service-provider relationships, not data-licensing arrangements. (Note: the broker statute's definition of "sale" lacks the exclusions the NJDPA provides for service providers, so this analysis requires care.)
• If you train models on user data, keep the training internal. Do not license training datasets that contain or derive from personal data to external parties.
• Build deletion that actually deletes. If a user requests deletion, the data should be gone from your systems and from any downstream recipients. Not archived. Not retained for model retraining. Gone.

This is how we think about it at Selina. We do not sell or license user data. User content is encrypted at rest. Memory is not end-to-end encrypted (a slice of each request reaches a frontier provider at inference), and we state that limit plainly rather than pretend it away. Files and transfers via SelinaSEND are zero-knowledge encrypted. Non-content operational metadata is kept for a short retention window, then discarded. We structurally cannot trigger the data broker or data collector thresholds under this law because the regulated transaction (selling or licensing user data to a broker) does not exist in our architecture.

That is not a compliance hack. It is a product decision that happens to have compliance benefits. If your business model depends on monetizing user data through downstream licensing or sales, New Jersey just made that model significantly more expensive. If your business model does not, the law is largely irrelevant to you. The architecture is the strategy.

How Does This Compare to Other State Data Broker Laws?

Every state with a data broker registration law defines "data broker" slightly differently, but New Jersey is an outlier on three dimensions:

The data collector category. No other state requires businesses with direct consumer relationships to register when they share data with brokers. This is unique to New Jersey.

The fee structure. The $5,000-to-$1.5-million annual fee range is orders of magnitude above what other states charge. California's Delete Act imposes a $6,000 fee. Oregon's is $750. New Jersey's top-tier fee is 250x California's.

The sale definition. By omitting the exclusions found in the NJDPA's own definition of "sale," the broker statute captures transactions that the state's comprehensive privacy law does not. This means you could be compliant with the NJDPA and still violate the broker statute for the same data flow. Two laws in the same state, with incompatible definitions of "sale." Welcome to the patchwork.

What Happens Next?

Three things to watch:

Legislative amendments. The reported enforcement pause and acknowledgment of "defects" suggest the legislature may revise the law before the registry launches in spring 2027. The data collector category and the fee structure are the most likely targets for amendment. Monitor the legislative session.

DCA guidance. The Division of Consumer Affairs will need to issue implementing regulations before the registry opens. Those regulations may clarify ambiguities in the statute, including the treatment of inferred data, the scope of exemptions, and the interaction between the broker statute's sale definition and the NJDPA's.

Enforcement signals from other states. California's CPPA is already treating inference-based profiling as broker activity. If New Jersey follows that interpretive lead, the inference gap discussed above could close faster than the statutory text suggests. Watch CPPA enforcement actions for leading indicators.

For now, the practical advice is straightforward: audit your data flows, understand whether any downstream relationship triggers the data collector definition, confirm you are not selling sensitive data under the statute's broad definition, and make architectural decisions that keep you outside the regulated perimeter. If your product is built to protect user data rather than monetize it, you are already most of the way there.

If you want to see what an AI assistant looks like when it's built around that principle: start a free 7-day trial, 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