AI Privacy Checklist for a Small Business

Before using AI with business data, map the complete pipeline. Record what enters, where it moves, who can access it, what gets logged, how long each copy remains, and how it is deleted. Review the application, model, retrieval store, workflow platform, analytics, backups, support tools, and human reviewers.

Local processing is not automatically private. A local model can still receive data from a cloud inbox, write prompts to logs, call external tools, store embeddings in a hosted database, or send alerts containing sensitive text.

Assign an owner to each data flow. Remove fields the task does not need. Use narrow access, approval for sensitive actions, tested deletion, and an incident plan. This is an operational checklist, not legal advice. Ask qualified counsel or privacy staff to assess duties that apply to your location, contracts, sector, and data.

What data should you inventory?

Start with the business process, not the model. List the sources, fields, attachments, and people involved. Include customer records, employee data, support messages, financial documents, credentials, and confidential business material.

For each field, ask whether the workflow needs the raw value. A ticket classifier may need message text but not a full customer profile. A document extractor may need an invoice total but not unrelated pages in the file.

Also inventory derived data. Prompts, embeddings, summaries, labels, confidence scores, and model outputs can reveal source information. Treat them according to their content, not their file type.

Give each dataset an owner and purpose. If nobody can explain why a field enters the system, remove it from the pilot.

Where can data leave a local system?

Draw every hop:

1. Source application or device.
2. Intake service and network.
3. OCR or parser.
4. Retrieval index and embedding process.
5. Model runtime.
6. Tools and external actions.
7. Output store and user interface.
8. Logs, metrics, traces, backups, and alerts.
9. Human review and support access.

A local model covers only one box. Cloud storage, remote access, crash reporting, package downloads, hosted monitoring, or third-party embedding APIs can cross the intended boundary.

The local document processing guide shows how OCR, retrieval, validation, and storage create separate privacy decisions.

What should the data-flow register contain?

Use one row per transfer or stored copy. The sample entries below are examples, not a finding about your system.

“No retention” should not be a copied vendor phrase. Identify which service, data type, account setting, and contract it describes.

How should you review an AI vendor?

Read the current service terms, privacy documentation, security documentation, and data-processing terms that apply to your account. Marketing pages are not enough.

Ask:

• Does the service use submitted data for training or product improvement?
• What settings or contract terms change that behavior?
• Which subprocessors and regions may receive data?
• What logs and abuse-monitoring copies remain?
• How long are prompts, outputs, files, and metadata retained?
• Can an administrator export and delete them?
• How are incidents reported?
• What happens when the account closes?

Record the source URL, review date, account tier, and reviewer. Vendor terms can change, so repeat the review after a material service or contract change.

NIST describes its AI Risk Management Framework as voluntary and organizes its core around Govern, Map, Measure, and Manage. The official NIST AI RMF resource can help structure a review, but it does not replace requirements that apply to a specific business.

What access and secret controls are needed?

Use separate service accounts for each environment and workflow where practical. Grant only the permissions required for the task. A drafting workflow does not need authority to issue refunds or change customer accounts.

Store API keys and passwords in an approved secrets system, not in prompts, workflow exports, source files, or chat history. Restrict who can view or change credentials. Rotate a secret after suspected exposure and remove access when roles change.

Require stronger authentication for administrators. Keep development and production credentials separate. Review access on a documented cadence based on risk.

The agent sandboxing guide covers one technical control. A container does not replace identity, network, data, and approval controls.

What should logs contain?

Log enough to investigate behavior without copying sensitive content by default. A useful event can include a request ID, workflow version, model identifier, route, status, latency, token count, reviewer action, and error category.

Redact or omit prompt text, attachments, credentials, and retrieved documents unless a defined investigation requires them. Protect debug logs as production data. Short-lived debugging can otherwise become the longest-retained copy.

Set a retention rule for application logs, model traces, monitoring events, workflow history, and backups. Verify deletion rather than trusting a configuration label. Search for a test identifier across the pipeline.

Which actions need human approval?

Require a person to approve actions that can affect money, rights, access, commitments, safety, or sensitive relationships. Examples include refunds, account changes, contractual promises, employee actions, and messages about a vulnerable customer.

Approval should display the proposed action, source evidence, affected record, and relevant policy. The reviewer must be able to edit, reject, and escalate. A button that hides the source does not create meaningful oversight.

Record who approved the action and which workflow version produced it. Do not let the model approve its own exception.

The local LLM customer support guide applies these controls to refunds, promises, account changes, and sensitive tickets.

How should retention and deletion work?

Set retention by data purpose and system. Do not choose one period for every copy. Operational records, debug traces, backups, and evaluation samples have different needs.

Create a deletion map that covers primary storage, vector indexes, caches, files, logs, and recoverable backups. Decide how deletion requests move from the source record to derived data.

Test with a synthetic record. Delete it through the normal process, then search each store. Document any delayed backup expiry or technical limitation. Do not promise immediate deletion if the architecture cannot provide it.

What should an incident plan cover?

Define how staff report a suspected disclosure, wrong recipient, exposed key, excessive access, or unsafe automated action. Assign an incident lead and backup.

The plan should cover containment, evidence preservation, credential changes, service suspension, scope review, internal communication, and qualified assessment of notification duties. Do not publish a legal deadline from a generic checklist. Applicable duties depend on facts and jurisdiction.

Practice with a tabletop scenario. For example, assume debug logging captured support messages for a week. Identify the systems to search, people to contact, and controls to change.

What should you verify before launch?

Before production:

• Confirm the data map matches the deployed path.
• Remove unnecessary fields and tool permissions.
• Review current vendor terms and account settings.
• Test access removal, deletion, backup restore, and incident contacts.
• Trigger spending and security alerts.
• Confirm sensitive actions stop for human approval.
• Give staff a clear rule for prohibited data and escalation.

Recheck after adding a model, tool, integration, log service, or new data type. Privacy belongs to the whole pipeline. Changing one box can change the boundary.