AI privacy and security checklist for teams using AI tools

Most AI security problems at work are not exotic. Someone pastes a customer spreadsheet into a free chat assistant, a connected tool reads an email containing hidden instructions, or an AI draft reaches a client with unchecked figures. None of these need a sophisticated attacker; they happen because a team adopted a powerful tool faster than it agreed how to use it.

This guide gives you a checklist to work through with your team in an afternoon and revisit every few months, ending with an acceptable-use policy outline you can adapt.

This is general guidance, not legal advice. Privacy and data-protection obligations vary by country, sector and contract, so involve a qualified lawyer or privacy professional before you finalize policies that carry legal weight.

Start with data classification

Before you decide which AI tools are safe, decide what kinds of information you hold. A simple four-tier scheme works for most small and mid-sized teams:

The point of the table is speed: before pasting anything into a chat window, people should be able to answer "which tier is this?" in two seconds.

Vendor data-retention and training settings to check

AI vendors differ widely in what they do with your inputs, and the same vendor often has different terms for free, individual and business plans. Read the current data-use documentation, because these policies change. For every approved tool, answer these questions:

1. Is my data used to train or improve models? Look for whether training use is on by default and whether an admin can switch it off for the whole organization.
2. How long are prompts and outputs retained? Note the default retention period, whether you can shorten it, and what happens to deleted conversations.
3. Where is data processed, and who at the vendor can see it? Regional hosting and human review for abuse monitoring can both matter for contracts.
4. What happens with connected apps? If the tool connects to your email, drive or calendar, confirm exactly what it can read and whether that content is retained.
5. Is there a data-processing agreement? Business plans usually offer one; consumer plans usually do not.
6. Are there admin controls? Single sign-on, user provisioning, audit logs and the ability to disable features such as public sharing links are strong signals of a business-ready product.

Record the answers in a dated register, and add these questions to your criteria when comparing products in the AI tools directory.

Access control and accounts

Apply the usual basics first:

• Use company-managed accounts tied to single sign-on, not personal sign-ups with work email addresses.
• Turn on multi-factor authentication and remove access promptly when people leave.
• Restrict who can create public share links to conversations or generated documents.

Then the AI-specific issue: connectors and agents act with the permissions you give them. An assistant that can search your whole shared drive can surface a salary spreadsheet that was only "hidden" by being hard to find, so audit folder permissions before connecting it. Give automations and AI agents the narrowest access that lets them do their job, and prefer read-only access unless writing is essential.

Prompt injection and data exfiltration

Prompt injection is the security risk most specific to language models. A model processes instructions and data in the same stream of text, so it can struggle to tell your instructions apart from instructions hidden inside content it reads. An attacker can plant text in a web page, a PDF, an email or a support ticket that says, in effect, "ignore previous instructions and do this instead".

The danger grows with capability. An assistant that only writes text can be manipulated into a wrong answer. One that can also browse, send email or read your files can be manipulated into doing something, such as forwarding private data to an outside address.

Practical defenses:

• Treat all external content an AI reads as untrusted input, the same way developers treat form input on a website.
• Require human confirmation before an AI tool sends messages, makes purchases, changes records or shares files outside the organization.
• Avoid giving a single agent both access to sensitive data and the ability to communicate externally, unless there is a review step in between.
• If you build your own AI features, test them with deliberately malicious documents before launch. The OWASP project maintains a widely used list of risks for LLM applications that is a useful starting point.

Teams building retrieval-augmented generation systems should pay particular attention here, because every document in the knowledge base becomes potential input to the model.

Shadow AI: tools nobody approved

Shadow AI means staff using AI tools nobody reviewed: a personal chat account, a page-summarizing browser extension, a free meeting transcription app. Blanket bans tend to push this usage underground. A more effective approach has three parts:

1. Provide a good approved option. If the sanctioned tool is capable and easy to reach, most people will use it.
2. Make the request path quick. Publish a short form for requesting a new tool, and commit to a review turnaround measured in days, not months.
3. Look for usage, without punishing honesty. Ask teams what they already use. Review browser extensions, meeting bots joining calls, and expense claims for AI subscriptions.

Watch meeting recorders and browser extensions closely; both can passively capture confidential information.

Output review and accountability

What comes out of AI tools can cause harm too: invented facts, wrong figures, vulnerable code, or confidential details carried over from earlier in a conversation. Set review rules by consequence, not by tool:

• Low stakes (internal brainstorming, personal drafts): the author reviews.
• Medium stakes (customer emails, published articles, internal reports used for decisions): the author verifies facts and figures against source material before sending.
• High stakes (contracts, financial statements, regulatory filings, production code, medical or legal content): a second qualified person reviews, and the AI's role is documented.

Run AI-generated code through the same review and dependency scanning as human code, and be wary of unfamiliar suggested packages, since models sometimes invent package names that attackers can register.

Incident response for AI mistakes

Extend your existing incident process rather than writing a separate one. Make sure people know that the following count as incidents and should be reported quickly:

• Confidential or restricted data pasted into an unapproved tool.
• An AI agent or automation taking an unexpected action.
• AI-generated content published with significant errors.
• A suspected prompt injection attempt, even an unsuccessful one.

For a data exposure, record what was shared, with which tool and when; delete the conversation if possible; check whether the vendor's retention terms make deletion effective; and involve whoever handles data-protection notifications, since some exposures carry legal reporting duties. Treat honest mistakes reported promptly as learning opportunities, so people report early.

The core checklist

Assign an owner and a revisit date to each line.

If you want a broader view of where your organization stands, the AI readiness score quiz covers governance alongside skills and tooling. For a structured approach to risk, the NIST AI Risk Management Framework organizes the work into governing, mapping, measuring and managing risk, and many organizations use it as a reference even when it is not required of them.

An acceptable-use policy outline

A good AI acceptable-use policy fits on two or three pages. Use this outline:

1. Purpose and scope. Who the policy covers (employees, contractors) and which tools (chat assistants, embedded AI features, coding assistants, image generators).
2. Approved tools. A link to the live register, plus how to request a new tool.
3. Data rules. The classification table and what each tier means for AI use.
4. Prohibited uses. For example: entering restricted data, using AI to make final decisions about hiring or discipline without human review, generating deceptive content about real people, and bypassing security controls.
5. Output responsibility. The person who uses an AI output is accountable for it; review rules by stakes.
6. Disclosure. When staff should tell customers or colleagues that AI was involved.
7. Agents and automations. Who can build them, what approvals are needed, and the requirement for human confirmation on external actions.
8. Reporting and incidents. How to report mistakes and suspected attacks.
9. Training and review. Short onboarding and a scheduled review date.

Pair it with a one-page summary. For help adapting it, our AI services team can support policy and rollout work, and the AI for small business guide covers how to choose first use cases safely.

This guide is general information, not professional advice. Spotted an error? Tell us.