AI Features and Automated Decision Making: What You Owe Your Customers

If you added AI features to your SaaS product by calling somebody else’s foundation model, you are almost certainly not a “developer” under the AI laws you have been reading about. You are a service provider. The automated decision making rules put the disclosure duty on your customer, not on you, and what you do owe is a lot narrower than they are going to ask for.

I represent lots, literally 100s and 100s, of software and SaaS vendors, and by now nearly every one of them has shipped some AI feature. Almost none of them train a model. They call somebody else’s API and build something useful on top of it. That one fact does most of the legal work here, and I do not think enough people have noticed.

So let’s talk about your role, because “we use AI” and “we are an AI company” are not the same legal position.

Your Role Decides Everything.

Picture three links in a chain. The foundation model provider is upstream. You are in the middle. Your business customer is downstream, facing the consumer or the employee or the applicant.

These statutes hand out duties by role, and role turns on one question: who decides the purposes and means of the processing. Not whose logo is on the screen. Not whether your marketing says AI. Your customer decides what the feature is for and how it gets used, so your customer is the business (California’s word) or the controller (everyone else’s). You process on their behalf, which makes you a service provider in California and a processor in Colorado, Connecticut, Minnesota, Oregon, and Texas.

Get that straight and most of the anxiety goes away.

You Are Not a Developer.

The heaviest AI provision in California is Civil Code section 3111, which makes a developer publish a public summary of everything it trained on. Twelve enumerated items, no size threshold, no trade secret carve out.

It does not reach you. Section 3110(b) defines a developer as someone who builds or substantially modifies an AI system “for use by members of the public,” and section 3111 only fires when that system is “made publicly available to Californians for use.” You hand a feature to a business customer under a contract, and your customer decides who touches it. Nothing you ship goes to the public.

The one deal shape to watch is a white label arrangement where your feature ends up in front of your customer’s own consumers. The definition follows who the system is built for, not who signs the order form. Worth a look before you sign that kind of deal, not after.

You Are Not the One Who Has to Disclose.

Pre-use notices, profiling explanations, adverse action reasons, candidate notices. Every one of those runs against the business or the controller. California says the allocation out loud in Civil Code section 1798.145: a service provider “shall likewise not be liable under this title for the obligations of a business for which it provides services… provided that the service provider or contractor shall be liable for its own violations of this title.”

Two halves of that sentence, and both matter. You do not inherit your customer’s failure. You do own your own.

One more falls away for a related reason. A CPPA regulation makes a business that supplies automated decisionmaking technology to another business hand over “all facts available” for the recipient’s risk assessment. It binds a “business,” not a service provider, and subsection (b) limits it to “ADMT trained using personal information.” If you do not train on personal data, it does not reach you on its face. See 11 CCR section 7153 in the CPPA regulations. Cheap representation to give, and it forecloses an expensive demand.

Automated Decision Making: Three Things You Actually Owe.

These are statutory. They exist whether or not the contract says so, and they are the floor.

• General request assistance. Civil Code section 1798.130: a service provider “shall provide assistance to a business with which it has a contractual relationship with respect to the business’ response to a verifiable consumer request, including… by providing to the business the consumer’s personal information in the service provider or contractor’s possession.” The same section says you are not required to answer a consumer request that arrives at your door directly. Route it to your customer.
• Access request assistance. 11 CCR section 7222(i): a service provider “must provide assistance to the business in responding to a verifiable consumer request to access ADMT, including by providing the business with the consumer’s personal information it has in its possession… or by enabling the business to access that personal information.”
• Audit and assessment cooperation. 11 CCR section 7050(h) makes you cooperate with your customer’s cybersecurity audit and risk assessment, make available relevant facts in your possession, and (this is the sleeper) “not misrepresent[] any fact” the auditor deems relevant. That is an accuracy obligation, not just a production obligation.

The other states compress all of this into one sentence. Minnesota, Oregon (ORS 646A.581), Texas, Connecticut, and Colorado all require a processor to assist the controller in responding to consumer rights requests, “taking into account the nature of the processing and the information available to the processor.”

One drafting note worth money. Minnesota left the qualifier out of the consumer-rights half of that sentence. Its clause (1) says only “taking into account the nature of the processing,” and the “information available to the processor” limiter shows up only in clause (2), on security and breach. So Minnesota’s assistance duty is textually broader than the other four. Put the missing words back in your contract.

What Assistance Does Not Mean.

Here is the sentence I want you to hold onto. Section 7222(i) says produce the consumer’s personal information. It does not say explain the model.

The logic explanation is a different duty and it belongs to your customer. Section 7222(b)(2) makes the business give the consumer “information about the logic of the ADMT… which may include the parameters that generated the output.” And section 7222(c)(1) lets the business leave trade secrets out of that answer entirely. The same carve out appears in the pre-use notice rule at section 7220(d).

And go read the five state processor sections. Not one of them mentions profiling or automated decisions at all. They reach profiling only because the consumer-rights section they cross-reference happens to contain the profiling right. Nothing in any of them requires you to generate an explanation, produce your logic, or build the counterfactual Minnesota asks for.

The Asymmetry Nobody Uses.

Your customer’s pre-use notice has to explain “how the ADMT processes personal information to make a significant decision about consumers, including the categories of personal information that affect the output.” They cannot write that sentence without you.

But look at who that rule binds. Section 7220 opens with “a business that uses ADMT… must provide consumers with a Pre-use Notice.” Service providers are not mentioned anywhere in the section. There is no statutory hook that makes you author it.

The contract rules seal it. The CPPA’s required-terms list at section 7051 says the contract may require a service provider “to assist the business in complying with the business’s ADMT requirements pursuant to Article 11.” May. Not shall. So when procurement sends you a clause obliging you to assist with all AI compliance obligations, they are asking for something no regulation compels.

Give them a fixed, pre-approved functional description on a schedule. Do not sign a live obligation to explain your model on demand, and mirror the trade secret carve out so your assistance can never exceed what your customer itself has to disclose. This is the same discipline we bring to any SaaS contract negotiation: bound the obligation, then price it.

The Thing That Actually Costs You.

Not disclosure. Role drift.

Minnesota, Oregon, Connecticut, and Colorado all say flatly that a processor who fails to follow the controller’s instructions, or who “begins, alone or jointly with others, determining the purposes and means of the processing,” becomes a controller. Connecticut and Oregon spell out that the flip carries enforcement exposure. Texas does not codify it but gets to a similar place through its definitions. Every one of them calls it a fact-based determination that depends on context.

AI features are exactly where that drift happens, because AI features are where a vendor quietly starts deciding things: tuning a threshold because the output looked off, swapping in a different model, retraining on customer data to improve quality, adding a scoring behavior nobody asked for. Do enough of that and you become a controller without a single contract changing, and you inherit every duty this post just told you that you did not have.

The defense is boring and it works. Document that model selection, configuration, thresholds, and any retraining happen on customer instruction. That paper trail is what keeps you a processor. And in Colorado you cannot contract out of processor liability at all, so handle that one through indemnity and the cap, not a disclaimer. If you want help mapping this, that is squarely data privacy work.

The White Label Wrinkle.

Plenty of my clients ship under the customer’s brand, so the question comes up: does being invisible change anything?

For your privacy role, no. Controller and processor turn on who decides purposes and means, and none of these statutes mentions branding at all. Minnesota even defines the covered decisions as “decisions made by the controller that result in the provision or denial by the controller” of the thing at issue. Your logo is not a factor.

Two practical problems do come with it. Colorado’s assessment rules can require your customer to name the third-party profiling software in its data protection assessment and produce evaluations of its accuracy, which runs straight into a standard white label confidentiality covenant. Put a regulatory compliance carve out in the NDA before it bites. And California treats “the degree to which the involvement of service providers… is apparent to the consumer” as a factor in what a consumer reasonably expects, so white labeling weakens your customer’s position, which is exactly why they will come asking for broader disclosure rights. Help them describe the function generically. That is not the same as agreeing to be named.

Questions I Get.

• Customer’s DPA says we will “assist with all AI compliance obligations.” Sign it? No. That is far broader than any statute requires. Narrow it to producing the consumer’s personal information and a defined documentation package.
• Do we have to tell end users they are talking to AI? Almost never in a B2B product. Those laws reach government agencies, health care providers, and consumer companion apps.
• We fine tune the model. Does that change anything? Only if the result goes out to the public. Modifying a model does not make you a developer by itself.
• Our AI feature is fraud and abuse detection. Does that help? Possibly quite a lot. Section 3111(b)(1) exempts a generative AI system “whose sole purpose is to help ensure security and integrity.”
• Customer wants a model card and audit rights. Increasingly standard. Negotiate scope, confidentiality, and cost. In Connecticut you can offer a qualified independent assessment instead of submitting to a customer audit, which is often the cleaner trade.
• Where does this show up in our paper? The DPA assistance clause, the audit clause, and the service level commitments. Worth reading alongside your SaaS SLA, since both get negotiated by the same procurement team.
• What about Colorado’s new AI law? Colorado repealed and replaced its AI act before the original ever took effect. The replacement lands in 2027, puts documentation duties on developers, and voids clauses that indemnify a party for its own discriminatory use. Plan for it. Do not comply with it yet.

The practical move is unglamorous. Write down who ultimately uses the output, write down who decides what, and then go read the assistance clause in your three biggest customer DPAs. That is your real position, and it is usually better than you think.

I hope this helps.

Resources:

• Data Privacy Lawyer for Software and SaaS Vendors
• SaaS Contract Attorney
• 2 Reasons Why You Need an API License Agreement
• How to Use FAQs in SaaS Contract Negotiations

Disclaimer:

This post is for informational and educational purposes only, and is not legal advice. You should hire an attorney if you need legal advice, which should be provided only after review of all relevant facts and applicable law.