AI and Customer Data: A Practical Compliance Checklist for US Businesses

Most AI compliance advice is either legal boilerplate or hand-waving. Here is the practical checklist we apply before any customer data reaches a model.

The question we get from every serious client before an AI project starts is the right one: what happens to our customer data. The answers circulating online are unhelpfully split between legal boilerplate and reassurance. What follows is the operational checklist we work through before a single record leaves a client's systems.

1. Read the vendor's actual data terms

Enterprise and API tiers from major providers do not train on your inputs by default. Consumer chat products frequently do. The distinction is contractual, not technical, and it means an employee pasting a client contract into a personal chat account is a materially different event from the same text passing through a business API. Write the rule down and communicate it — this is the most common real-world leak, and it is a policy problem, not an engineering one.

2. Minimize before you send

• Strip identifiers the model does not need. A support classifier rarely needs a full name, email address or payment reference to do its job.
• Redact or tokenize sensitive fields at the boundary, and rehydrate them after generation if the answer needs them.
• Send excerpts, not entire databases. Retrieval should return the three relevant passages, not the whole document store.

3. Know where the data physically goes

Regional processing matters for healthcare, financial and public-sector clients, and increasingly for enterprise procurement teams regardless of sector. Establish which regions your provider processes in, whether that is contractually guaranteed, and whether any subprocessor moves data elsewhere. If you serve EU customers from the US, this determines what your privacy notice must disclose.

4. Set retention deliberately

Most AI platforms retain request logs for a period for abuse monitoring, often thirty days, and some offer zero-retention on request. Separately, your own application probably logs prompts and responses — including whatever the user pasted in. Teams routinely tighten vendor retention while their own debug logs quietly accumulate customer data for years.

5. Cover the US state law patchwork

There is no single federal privacy statute, so obligations follow your customers' residence. California, Virginia, Colorado, Connecticut, Texas and a growing list impose access, deletion and opt-out rights, with specific rules on automated decision-making and sensitive categories. Practically, build one capability — locate and delete everything associated with an individual, including in your vector index — and most state requirements become satisfiable at once.

• 0 records sent that the task does not require
• 1 process to locate and delete a person's data everywhere
• 100% AI actions logged with actor and timestamp

6. Log what the AI does, not just what it says

The moment an agent takes actions — sending emails, updating records, issuing refunds — you need an audit trail: what was requested, what data was retrieved, what the model returned, what was executed, and under whose authority. This is what an auditor, an insurer or a customer complaint will require, and retrofitting it after an incident is painful.

7. Decide what AI never touches

Write an explicit list. Credentials, full payment card data, unredacted health records and material under strict client confidentiality are common entries. A short, unambiguous prohibition list is enforceable; a lengthy nuanced policy is ignored by exactly the people it targets.

The realistic failure mode is not a model leaking your data. It is an over-permissioned integration doing something wrong at scale, with no log explaining why.