An AI vendor handling customer information is a service provider under the FTC Safeguards Rule, which means your existing obligations extend to it. The dealership remains the accountable party — building the system yourself removes the vendor, not the duty, and most of the required work has to happen before anything is signed.
This guide covers why an AI vendor is a service provider, the five contract clauses to require, what customer data an AI system actually touches, what the audit trail must show, and where dealerships get this wrong.
Why does the Safeguards Rule apply to an AI vendor?
Because the Rule follows the data, not the technology.
The Safeguards Rule obligations cover customer information in your possession or handled on your behalf. An AI system that reads your CRM, responds to leads and logs conversations is handling customer information on your behalf. That makes it a service provider, and the Rule requires you to select providers capable of maintaining appropriate safeguards and to contract for those safeguards.
None of that is new or AI-specific. What is new is how easily an AI deployment adds a service provider without anyone noticing — a platform connected to the CRM through an integration, plus whatever model provider sits behind it, plus whatever logging or analytics the platform uses. One purchase, three handlers of customer data.
The accountability does not move. A breach at a vendor is still your breach from the perspective of your customers and your obligations. And building in-house does not remove the duty either; it just makes you the only party responsible for meeting it.
What customer data does an AI system actually touch?
More than the purchase conversation suggests. Inventory it before signing, not after.
| Data | How the AI touches it | Sensitivity |
|---|---|---|
| Name, phone, email | Read, and used in every outbound message | Standard |
| Conversation content | Generated, transmitted and stored | Often contains more than expected |
| Vehicle of interest, trade details | Read from CRM, discussed | Low on its own |
| Consent and opt-out records | Must read, should write | Critical — the control itself |
| Credit or financing indicators | Sometimes present in CRM notes | High, and frequently unplanned |
| Call recordings and transcripts | Created by voice systems | High, plus state recording laws |
The row that surprises people is the fifth. CRM free-text notes routinely contain financing context a salesperson typed in, and an AI reading the full record is reading that too. Scope the fields the system can access rather than granting whole-record access by default — a decision made at integration time, when narrowing permissions is still cheap.
What are the five clauses to require?
The contract checklist
Five clauses. If a vendor will not provide them in writing, that is your answer.
- Data scope and purpose. Which fields the vendor receives, and the sole purpose for which they may be used. Explicitly: no training of general models on your customer data without consent.
- Subprocessors, named. Who else touches the data — model providers, hosting, logging, analytics. Plus notification before the list changes.
- Retention and deletion. How long conversation content, transcripts and logs are kept, and a deletion commitment on termination with a deadline attached.
- Security controls and evidence. Encryption in transit and at rest, access control, and some form of independent assurance you can actually look at.
- Breach notification. A defined window, in hours, with a named contact — because your own notification obligations start running from when you find out.
The first clause is the one most often missing and the easiest to get. Ask for it specifically; vendors with good practice have the language ready.
What must the audit trail show?
Separate from the contract, and a frequent gap because it is a product capability rather than a legal one. Ask to see it during evaluation.
| Must show | Why |
|---|---|
| Every outbound message, with timestamp and channel | The record of what your store said |
| Consent state at the time of contact | Not current consent — consent when the message was sent |
| Opt-out received and honoured, with latency | The gap between request and compliance is the exposure |
| Escalations, with trigger and handoff time | Shows the boundary held — see agent autonomy |
| Access to customer records, by user and system | Required for access control, and the hardest to retrofit |
| Retention and deletion events | Proof the policy executes rather than exists |
The second row is the one that fails under examination. A system that logs "customer opted in" without a timestamp cannot demonstrate consent at the moment of a specific contact, which is the thing actually in question.
Does building it yourself make this easier?
It makes it simpler and more concentrated, not lighter.
Simpler: fewer parties, data stays in infrastructure you control, no subprocessor chain to track, retention under your own policy.
More concentrated: no vendor security program to rely on, no third-party assurance report to point at, and encryption, access control, logging and monitoring all become yours to build and operate.
| Licensed | Built | |
|---|---|---|
| Parties handling data | Vendor + subprocessors | You, plus any model provider |
| Who implements controls | Vendor | You |
| Evidence available | Vendor assurance report | Your own documentation |
| Who is accountable | You | You |
The bottom row is the point, and it is why the security requirements belong in the scope of work on a custom build exactly as they would belong in a vendor contract.
Where do dealerships get this wrong?
1. The AI vendor never entered the service provider inventory. It was bought as a marketing tool or an operations tool, so nobody added it to the list the Safeguards program is built around.
2. Whole-record access by default. The integration was granted broad read access because narrowing it was extra work, and now the system reads financing notes it never needed.
3. Consent is read but not written. The system checks consent before contacting and does not record the check. There is no way to demonstrate compliance for any specific message afterwards.
4. Subprocessors are invisible. The platform is known; the model provider and logging service behind it are not, and the chain was never named in the contract.
5. Call recording treated as a product feature. Voice systems create recordings, and recording consent is governed by state law independently of anything in the Safeguards Rule. This has to be handled at deployment, not discovered later.
What should you do before signing?
| Step | Output |
|---|---|
| Inventory the data the system will touch, field by field | A list you can hand to counsel |
| Narrow the access scope to the fields actually needed | A permission set, not full-record access |
| Request the five clauses in writing | Contract language, before negotiation closes |
| Review the audit trail in a live demo | Confirmation it captures consent at time of contact |
| Add the vendor to your service provider inventory | Your Safeguards program stays accurate |
| Set a review date | Annual, aligned with your existing program review |
The fourth row has to be a live demo rather than a documentation claim. Ask to see a real log entry for a real message, including the consent state attached to it.
Frequently asked questions
Does the FTC Safeguards Rule apply to AI vendors?
Yes. The Rule follows customer information rather than the technology handling it, so an AI system that reads your CRM, contacts customers and stores conversations is a service provider under the Rule. You are required to select providers capable of maintaining appropriate safeguards and to contract for those safeguards in writing.
Who is responsible if an AI vendor has a data breach?
The dealership remains the accountable party for customer information it collected, regardless of which party was breached. Contractual provisions determine how costs and remediation are allocated between you and the vendor, but they do not transfer your obligations to your customers or to regulators.
What contract clauses should a dealership require from an AI vendor?
Five: data scope and purpose with an explicit restriction on training general models with your customer data, a named list of subprocessors with notification before changes, retention and deletion terms including deletion on termination, security controls with some form of independent assurance, and breach notification within a defined window to a named contact.
Does building AI in-house reduce compliance obligations?
No. It reduces the number of parties and simplifies the data flow, but it concentrates the work rather than removing it. Encryption, access control, logging, monitoring and retention all become yours to implement and operate, with no vendor assurance report to rely on, and the accountability is identical either way.
What should the AI audit trail capture?
Every outbound message with timestamp and channel, the consent state at the moment each message was sent, opt-out requests with the time they were honoured, escalations with their trigger, access to customer records by user and system, and retention and deletion events. Consent at the time of contact is the item most commonly missing and the hardest to retrofit.
Is it a problem if the AI has full access to CRM records?
Usually yes. Free-text CRM notes frequently contain financing context and other sensitive detail that the system does not need, and broad access expands both the breach surface and the scope of what you must account for. Granting a narrowed permission set covering only the required fields is straightforward at setup and painful afterwards.
Do voice AI systems create extra obligations?
Yes, two kinds. They generate recordings and transcripts, which are additional customer information subject to the same retention and access requirements, and recording consent is governed by state law independently of the Safeguards Rule. Both need to be addressed at deployment rather than discovered during an incident.
How often should AI vendors be reviewed?
Annually at minimum, aligned with your existing Safeguards program review, and additionally whenever the vendor changes its subprocessor list or materially changes the product. AI vendors change infrastructure and model providers more frequently than traditional software vendors, which is why subprocessor change notification belongs in the contract.
Conclusion
- The Rule follows the data. An AI system handling customer information is a service provider, with everything that implies.
- Accountability does not move. A vendor breach is still your breach, and building in-house concentrates the duty rather than removing it.
- Five clauses, before signature. Data scope, named subprocessors, retention and deletion, security evidence, breach notification.
- Consent at the time of contact is the audit trail item that fails under examination. Verify it in a live demo.
- Narrow the access scope. Full-record access reads financing notes the system never needed.
Last updated: