CCPA Neural Data Rules 2026 (SB 1223): What AI and Wearable Companies Must Do
California added neural data to CCPA's sensitive personal information category. The affected companies mostly aren't brain-implant startups — they're consumer wearables, VR headsets, sleep and focus apps, and the AI models that consume those signals.
What SB 1223 Actually Changed
SB 1223 did not create a standalone neurotechnology statute. It made a surgical amendment: neural data was inserted into CCPA's existing definition of sensitive personal information, alongside things like precise geolocation, genetic data, and biometric identifiers used for identification.
That framing matters. There is no new registration regime and no new agency. Instead, an entire pre-existing machinery of obligations — notice, limit-use rights, purpose limitation, service provider contracts, risk assessments — snapped into place over a data type most product teams had classified as ordinary telemetry.
The Definitional Line: Measured vs. Inferred
The statutory definition turns on data generated by measuring the activity of the central or peripheral nervous system, and specifically excludes what is merely inferred from non-neural information. Two products can output the same "focus score" and land on opposite sides of the line depending on where the signal came from.
The practical consequence: a single wearable can carry one sensor that is squarely in scope and three that are not. Classify at the sensor level and record the reasoning, because a blanket product-level answer will be wrong in one direction or the other.
What Attaches Once Data Is Sensitive
- Identify neural data explicitly as a category of sensitive personal information collected
- State the purposes, at the point of collection — not buried in a privacy policy update
- Disclose retention period, or the criteria used to determine it, for each purpose
- Update the categories list in the privacy policy for the trailing 12-month disclosure
- Offer a mechanism to limit use and disclosure to what is necessary to perform the requested service
- Design the product so a limited-use state is actually functional, not a dark pattern that bricks the device
- Ensure the limit propagates to model training, analytics, and any secondary research use
- Honor it downstream: the limit must flow to service providers and contractors, not stop at your API boundary
- Collect only signal necessary for the disclosed purpose — sampling rate and channel count are compliance decisions
- Prefer on-device feature extraction; discard raw waveforms once features are computed where the product allows
- Do not repurpose neural-derived features for advertising, scoring, or profiling without a fresh basis
- Delete on schedule and prove it — retention claims are the easiest thing for a regulator to test
- Flow sensitive-PI restrictions into every service provider and contractor agreement, including model vendors
- Confirm no AI API you send this data to reserves rights to train on it
- Include neural processing in CCPA risk assessment scope
- Include it in security program scope; sensitive categories carry elevated breach consequences
The Model-Training Problem
Neural signal is noisy, individual-specific, and expensive to collect, which is exactly why consumer neurotech products train on user data by default. That default is now the highest-risk piece of the stack.
Three questions decide whether your training pipeline is defensible:
- Is training necessary to the requested service? Improving a general model for future users is a different purpose from delivering the feature this user asked for. Only the latter clearly survives a limit-use request.
- Can you honor deletion? If neural data is baked into weights, a deletion request that your pipeline can only satisfy by removing a row from a dataset — while the trained model persists — is a gap you should identify before someone else does.
- Does your API provider train on it? Default terms at several major AI providers historically permitted training on submitted data. Sending sensitive neural features under those terms converts a processing activity into a disclosure.
Frequently Asked Questions
We're a small startup under the CCPA revenue threshold. Does this reach us?
CCPA applicability thresholds are unchanged by SB 1223 — you still need to meet one of the revenue, volume, or data-sale tests. But the 100,000 consumer threshold catches wearable companies faster than founders expect, and neural data is precisely the category where you want the compliance architecture in place before you cross a line rather than after.
Our device processes everything on-device. Are we out of scope?
On-device processing dramatically narrows exposure, and it is the strongest design answer available. But check what leaves the device: crash logs, sync payloads, analytics events containing derived scores, and cloud backup of local stores are all common leak paths that put derived neural features back on your servers.
Does the biometric-identifier category already cover this?
Not reliably. CCPA's biometric identifier concept is oriented toward identification of an individual, and many neural applications are not identifying anyone — they're inferring a state like attention or fatigue. That gap is much of why a separate neural data category was added rather than relying on the existing one.
What about employee or research subject neural data?
CCPA's employee and B2B exemptions expired, so employee data is covered personal information — which makes workplace fatigue-monitoring and attention-tracking deployments a live issue under this amendment. Research contexts may carry separate human-subjects obligations that stack on top rather than replace privacy law.
How should we handle an existing user base collected before this?
Re-paper the notice, add the limit-use mechanism, and review whether historic data was collected for purposes you can still defend. Retroactively narrowing purposes and deleting data you no longer have a defensible basis for is unglamorous, and it is the cheapest version of this problem you will ever face.
Start With a Sensor Inventory
You cannot answer any of this at the product level. List every sensor, state what it physically measures, and mark whether that measurement comes from the nervous system or from observable behavior. That table is the whole compliance analysis in compressed form.
Then follow each in-scope signal through the pipeline — device, transport, storage, features, model, analytics, vendors — and confirm the sensitive-PI restrictions survive every hop.
This article is general information, not legal advice. Neural privacy law is moving quickly across multiple states; confirm current requirements with counsel before shipping.