AI and SaaS Data Privacy Compliance: GDPR, CCPA, and the 2026-2027 Rules

A SaaS company that adds AI features runs into privacy law in three places at once. The training data has to have been collected on a lawful basis and used within what customers were told. The model itself may hold personal data it memorized. And any automated decisions it makes about people now fall under specific rules in the EU and in several US states, with deadlines landing between August 2026 and January 2027.

This guide covers what each of those requires in practice. It is written for product, engineering, and legal teams at B2B and B2C SaaS companies, not as a substitute for counsel.

The regulations that matter, and when

About 20 US states now have comprehensive privacy laws. Indiana, Kentucky, and Rhode Island joined in January 2026. Most follow a similar pattern (access, deletion, correction, opt-out of targeted advertising and sale, opt-in or opt-out for sensitive data), so building to the strictest common requirements is usually cheaper than handling each separately.

Training on customer data: the question that decides most of this

The first question for any AI feature is whether you are allowed to use customer data to train or fine-tune a model. The answer depends on your role.

If you are a processor (most B2B SaaS). Your customers are the controllers, and your data processing agreement says you process their data only on their instructions. Using that data to train a model that benefits all customers, or your own product, is generally outside those instructions. The clean solutions are an explicit contract term that permits it (with an opt-out), training only on data from customers who opt in, or not training on customer data at all and saying so. Many enterprise buyers now ask for the last option in procurement, and some will not sign without it.

If you are a controller (most B2C SaaS). You need a lawful basis. The European Data Protection Board's Opinion 28/2024, adopted in December 2024, says legitimate interest can support model training if you pass the three-step test: a legitimate purpose, processing that is necessary for it, and a balancing test that the individual's rights do not override. Factors that help: data people would reasonably expect to be used this way, an easy opt-out offered before training starts, and technical measures that reduce what the model can reveal.

Whichever role you have, update your privacy notice before training starts, not after. Regulators treat retroactive notices badly.

Can the model itself contain personal data?

Yes. Researchers showed in 2021 (Carlini et al., Extracting Training Data from Large Language Models) that GPT-2 could be prompted to reproduce verbatim training text, including names, phone numbers, and email addresses that appeared in its training set. Larger models memorize more, and fine-tuned models trained on a small customer dataset are especially prone to it.

The EDPB's opinion takes the position that a model trained on personal data is not automatically anonymous. A controller claiming it is must be able to show that personal data cannot be extracted with reasonable effort. That affects deletion requests: if a model is not anonymous, a person's right to erasure may reach the model, and retraining is expensive.

Practical controls, roughly in order of cost:

1. Do not put personal data in training sets unless the feature needs it. Scrub names, emails, phone numbers, account numbers, and free-text fields with PII detection before data leaves production.
2. Prefer retrieval over fine-tuning for customer-specific answers. Retrieval-augmented generation keeps customer data in a database with normal access controls and deletion, instead of baking it into model weights.
3. Test for extraction. Before release, prompt the model to reproduce known training records and check whether it does.
4. Use differential privacy for sensitive training. It adds calibrated noise so the model cannot depend heavily on any single record. It reduces accuracy, so it suits high-risk data more than general features.

Anonymized, pseudonymized, and why the difference matters

Anonymized data falls outside GDPR entirely, but the bar is high: nobody can re-identify individuals using means reasonably likely to be used. Pseudonymized data, where identifiers are replaced with tokens and a key is kept separately, is still personal data for the holder of the key.

In September 2025, the EU Court of Justice ruled in EDPS v SRB (C-413/23 P) that pseudonymized data passed to a recipient who has no reasonable way to re-identify people may not be personal data for that recipient. That can simplify sharing data with a separate analytics or model training vendor, but it does not reduce the original company's duties, and the analysis depends on the facts.

Removing names and emails rarely anonymizes a dataset. Combinations of ZIP code, birth date, and gender, or detailed usage logs, can often identify people on their own.

Automated decisions about people

GDPR Article 22 gives people the right not to be subject to a decision based solely on automated processing that has legal or similarly significant effects, with narrow exceptions. The Court of Justice's SCHUFA ruling (C-634/21, December 2023) held that a credit score can itself count as such a decision when a lender relies heavily on it. In Dun & Bradstreet Austria (C-203/22, February 2025), the court said people are entitled to an explanation of the procedure and principles actually applied, in a form they can understand.

The California ADMT rules and Colorado's new law push US businesses in the same direction for significant decisions such as lending, housing, employment, insurance, and education. If your SaaS product scores, ranks, or filters people for customers who make those decisions, expect customers to ask you for:

• Documentation of what the model uses and how it was tested
• A way to generate plain-language reasons for an individual result
• Support for human review and correction of results
• Logs sufficient to reconstruct a decision later

Building these once as product features is cheaper than answering each customer's questionnaire by hand.

The paperwork that actually protects you

Records of processing and a data map. Where personal data comes in, where it is stored, which systems and vendors touch it, and how long it is kept. Every other obligation depends on this.

DPIAs. GDPR Article 35 requires a data protection impact assessment before processing likely to result in high risk. Most regulators consider large-scale profiling and innovative AI uses to qualify. The CCPA's risk assessments cover similar ground for California. One template that satisfies both saves time.

Vendor terms for AI APIs. Check that your model providers' enterprise terms exclude your inputs from their training, state retention periods, and list sub-processors. Consumer plans often do not.

International transfers. For EU data going to the US, the EU-US Data Privacy Framework remains available for certified US companies; the EU General Court rejected a challenge to it in September 2025. Standard Contractual Clauses plus a transfer impact assessment remain the fallback.

A 90-day plan

1. Weeks 1 to 3. Build or update the data map, including which datasets feed which models and which AI vendors receive data.
2. Weeks 3 to 5. Decide your training position for customer data (never, opt-in, or contractual permission with opt-out) and update DPAs and privacy notices to match.
3. Weeks 5 to 8. Run DPIAs, doubling as CCPA risk assessments, for each AI feature that touches personal data.
4. Weeks 8 to 10. Add PII scrubbing to training pipelines and run extraction tests on existing fine-tuned models.
5. Weeks 10 to 13. For features that affect significant decisions, add explanation, human review, and logging ahead of the January 2027 US deadlines.

For the governance side of these systems, see generative AI data governance and AI governance frameworks. For the security controls enterprise buyers check alongside privacy, see SOC 2 Type 2 for SaaS and SaaS security best practices.

This guide is for informational purposes only and is not legal advice. Privacy and AI laws change frequently and apply differently depending on your role and customers; consult qualified counsel.