Data Privacy Checklist Before Using AI at Work

Start with an honest inventory. CTR's checklist for employers puts this first: an organization cannot set meaningful rules until it understands where AI is already part of the workday (CTR). Ask each person, without blame, which AI tools they use, for what tasks, and on which account.

The account matters as much as the tool. Cyberhaven found that a large share of chatbot use at work happens through personal accounts, which bypass single sign-on, central logging, company retention settings and any business terms on training (Cyberhaven). It also observes that broad attempts to block AI rarely reduce risk; they push usage outside formal controls and reduce visibility.

So the practical goal is not to stop people using AI. It is to move the work onto tools and accounts the company controls. Harvard's guidance follows the same logic: use the organization's own version of a service rather than a personal or consumer account, and understand what protections apply to that specific tool and feature (Harvard Information Security).

Inventory questions:

• Which AI tools does each person use, including browser extensions and features built into existing software?
• Personal account or company account?
• What kinds of information go in: customer messages, documents, code, spreadsheets, meeting audio?
• Is anything connected, such as email, a shared drive or a calendar?

The most useful rule in any AI policy is a clear list of what must never go in. CTR suggests that employees may not enter protected, confidential or sensitive information into an AI platform unless the organization has approved both the tool and the specific use, and lists examples (CTR):

• National ID or social security numbers.
• Payroll, banking and financial information.
• Medical or benefits information and employee records.
• Customer or client information.
• Passwords and login credentials.
• Confidential strategy, proprietary processes and trade secrets.
• Information covered by contracts or confidentiality agreements.

CTR adds a point that is easy to miss: information without a name attached can still be identifiable when combined with other data. Removing a name from a customer complaint does not make the complaint anonymous if it includes an address, an order number and a date.

A simple three-tier scheme works for most small companies:

Harvard's guidance adds a habit worth teaching: remove unnecessary personal, confidential or identifying information before sharing content with an AI system, even with an approved tool (Harvard Information Security). Most tasks, such as rewriting an email or summarizing a policy, work just as well with the identifying details stripped out.

Before approving a tool, read what it does with your data. The terms that matter are training, retention, access and deletion, and they often differ between consumer and business versions of the same product.

As an example of what to look for, OpenAI's enterprise privacy page, as read on 2026-10-17, states that it does not train its models on business data from its business products and API by default, that customers own their inputs and outputs where the law allows, that it will sign a data processing addendum to support GDPR compliance, and that workspace administrators can access audit logs (OpenAI). Those commitments apply to the business products named on that page, not to every account.

Terms also change. A GitHub announcement about Copilot interaction data explains that its agreements with business and enterprise customers prohibit using their interaction data for model training, while individual users on free and paid personal plans are covered by different terms with an opt-out (GitHub Community). The same product, in other words, can treat your data differently depending on which plan the person is signed into.

A short statement such as "we never train on your data" is not enough on its own. Parseur, a document processing vendor, argues that security reviews have moved on to what can be checked, and publishes a list of questions to ask any vendor (Parseur). Adapted for a small company:

1. Do you use our inputs, outputs or corrections to train, fine-tune or evaluate any model?
2. Does that answer also cover anonymized, aggregated or derived versions of our data?
3. Which third parties (subprocessors) receive our data, and where do they run?
4. How long is each type of data kept, including logs and backups?
5. Can we set the retention period, and can we delete data on demand?
6. Can your staff view our content, when, and is that access logged?

Parseur also explains why the training question matters so much. Processing uses your data to complete a task and then stops. Training feeds it into a model, and there is no practical way to remove it afterwards (Parseur).

If staff put information about identifiable people into an AI tool for business purposes, the company has legal duties. Law firm Norton Rose Fulbright explains that in that situation your organization is likely the data controller for the personal data entered, so you need to make sure the people concerned are informed through privacy notices and that there are legal grounds for the processing (Norton Rose Fulbright). Its guidance recommends that a policy for consumer chatbot use ban personal information and client or confidential information in prompts, and prohibit using the tool to make queries about individuals.

For uses that do involve personal data, assess them first. ISACA recommends a data protection impact assessment to check whether existing data protection agreements cover the new use, and a transfer impact assessment where data may cross borders (ISACA). The details depend on where you and your customers are, so take advice for anything involving health, financial or children's data.

Questions to answer before personal data goes into any AI tool:

• Do our privacy notices cover this use?
• Do we have a legal basis for it?
• Is a data processing agreement in place with the vendor?
• Does data leave the country or region, and is that allowed?
• Can we honor a request to access or delete a person's data?

Meetings deserve a specific rule. Harvard advises using AI meeting assistants and note takers only when approved, telling participants when AI is recording, transcribing or summarizing, and following consent requirements (Harvard Information Security).

AI tools that connect to email, files and calendars widen the exposure. Harvard's guidance asks you to review what each tool can access, whether it can only read or can also create, modify, delete or send, to grant only the permissions a task needs, and to disconnect integrations that are no longer used (Harvard Information Security). It also flags two less obvious risks: persistent memory that carries information across conversations, and prompt injection, where instructions hidden in a document or web page try to make the AI disclose information or take unintended actions.

Connected tools inherit your existing permission mistakes. Metomic points out that if file-sharing permissions in tools such as shared drives and chat apps are too broad, employees can pull sensitive documents into an AI tool without realizing what they contain (Metomic). Tidy access in the source systems before connecting AI to them.

Limit who uses which tools. ISACA suggests role-based access, granting access to employees whose jobs need it, after security training specific to the tool (ISACA). It also notes that your suppliers may use AI tools with your data, so ask them to disclose it.

Copy this into your own documents and assign an owner.

BEFORE APPROVING AN AI TOOL
[ ] We know which AI tools staff already use, and on which accounts
[ ] The tool will be used on company accounts, not personal ones
[ ] We have read its terms on training, retention, subprocessors, deletion
[ ] The business plan's terms apply to the accounts we will use
[ ] A data processing agreement is signed if personal data is involved
[ ] Admin controls and logs are switched on where available

BEFORE DATA GOES IN
[ ] Each data type is classified as public, internal or restricted
[ ] Restricted data is only used for named, approved purposes
[ ] Identifying details are removed when the task does not need them
[ ] Privacy notices and legal basis cover any personal data use
[ ] Meeting recording or transcription is announced to participants

BEFORE CONNECTING SYSTEMS
[ ] Source system permissions are tidy
[ ] The tool gets only the access the task needs
[ ] Read-only access is used unless actions are required
[ ] Memory features are understood and set deliberately

ONGOING
[ ] Staff are trained on the rules and why they exist
[ ] Outputs are checked before use or sending
[ ] Vendor terms are re-checked at least twice a year
[ ] One named person owns this checklist

The Future of Privacy Forum's checklist adds the human side: train employees on the implications of using these tools, give clear guidance on when to use organizational accounts and which uses are permitted, and put systems in place that remind people to verify outputs for accuracy and possible intellectual property issues (Future of Privacy Forum).