Company AI policy: what staff may put into Claude, and what stays out

This guide covers one part of a company AI policy: what staff may put into Claude, and what they may not. Claude is Anthropic's AI assistant. Staff can type text into it, paste documents into it or upload files to it. Every one of those actions sends company information to an outside service. A policy is how you decide, in advance, which information may make that trip.

It helps to separate two documents. The UK Information Commissioner's Office (ICO) puts it this way: policies set out what the rules are, why they are in place and who they apply to, while procedures give directions on how to carry out those rules. Your AI policy says "no client bank details in Claude". Your procedure says which plan to log in to, how to redact a document and whom to ask for an exception.

A workable policy answers five questions:

• Approved tools and plans: which Claude plan staff use, and which they do not.
• Data: what may go in freely, what needs care and what never goes in.
• Approvals: who signs off a new use or an exception.
• Logging: what is recorded, where, and who can see it.
• Ownership: one named person who maintains the policy and answers questions.

You do not have to start from a blank page. The ICO notes that it can make more sense to adapt and extend policies you already have, such as data protection and information management policies. The rest of this post works through each question, then gives an outline and a one-week rollout.

The single most useful rule is which Claude plan staff may use for work. Anthropic sorts its plans into two groups with different terms. According to Anthropic's legal and compliance page, Team, Enterprise and Claude API users are covered by the Commercial Terms of Service, while Free, Pro and Max users are covered by the Consumer Terms of Service.

The difference is not cosmetic. Anthropic's help centre says the Consumer Terms of Service and Privacy Policy do not apply to the Claude for Work plan, where Anthropic acts as the data processor. Use of a Claude for Work account is governed by the agreement between Anthropic and your organisation. In plain terms, a Team or Enterprise account puts your company in charge of the data. A personal Pro account a member of staff pays for leaves your company with no agreement with Anthropic covering that data, but your company is still responsible for any client or staff data that goes into it.

So the rule for most businesses reads like this:

• Company work goes into the company's Team or Enterprise account only.
• Personal Free, Pro or Max accounts are not used for company information of any kind.
• Other AI tools are allowed only once they are added to the approved list.

The UK government's DWP AI security policy shows one way to enforce this. It notes that online AI tools may initially be blocked on its devices, and staff with a business need can ask for a tool to be unblocked. A smaller firm may not block anything, but the principle carries over: a short approved list, and a simple route to ask for additions.

Staff need a rule they can apply in seconds. A three-level classification works well: green for material that may go into the approved account freely, amber for material that needs a check first, and red for material that never goes in without written approval.

The red list borrows from a public example. The DWP policy says users must not upload OFFICIAL-SENSITIVE or higher data, personal data or non-public DWP code to AI tools unless explicit approval has been granted. Translate that into company terms and you get the table below.

Two further rules belong alongside the table. The government's guide to using AI at work advises asking participants for consent before using AI to transcribe, summarise or process a group meeting. It also states that you are responsible for AI-generated content as if you created it yourself, which is the right sentence to put in front of staff.

A policy that only lists prohibitions will be worked around. It needs a fast, named route for saying yes. Decide who approves three things: adding a tool to the approved list, a red-level exception, and a change in how an approved tool is used.

The third one is easy to miss. The DWP policy says that where there is a significant change to the use case of an approved AI tool, for example using personal data where it was not used before, the change must be approved by a relevant governance board. For a business without boards, that means the policy owner signs off, and the approval is written down.

Some uses need more than a signature. The ICO says explainability considerations belong in your impact assessment, which is likely to be a legally required assessment such as a Data Protection Impact Assessment (DPIA), a structured review of the risks a use of personal data creates. The ICO also says the assessment should happen before work begins on an AI decision-support system. The DWP, as a public body bound by the public sector equality duty, requires an Equality Analysis where an AI tool processes personal data about protected characteristics. A private business has no duty to write one, but should still check that the use cannot lead to unlawful discrimination.

When Svennis builds Claude into a client's business systems, we settle who owns the account and who approves a new use before the first connection goes live, because those are the two questions staff ask first. Leaving them open means each department invents its own answer.

Staff should know that work use of Claude is not private. On a Claude for Work plan, Anthropic's help centre says your organisation's designated Primary Owner manages the account and all associated data. The Primary Owner is the person your organisation names to run the account. They can request data exports, which may contain conversations with Claude, uploaded files and usage patterns, and they can remove a user's access.

The same page says your organisation decides which Claude services and features each user can access, and may limit certain functionality. That gives you a technical backstop for the written rules. If a feature is not approved, switch it off rather than relying on a sentence in a document.

Retention: what Anthropic keeps

Be precise about retention, because staff will ask. Anthropic's API and data retention page describes zero data retention (ZDR), under which Anthropic does not store prompts or responses at rest after the API response is returned. ZDR applies to the Claude API. The Claude Teams and Claude Enterprise product interfaces are not ZDR-eligible, with the exception of Claude Code used through Claude Enterprise with ZDR enabled. Even with ZDR, Anthropic may retain data where required by law or where automated trust and safety systems flag it, and flagged inputs and outputs may be kept for up to 2 years.

Apps such as Cowork and Claude Code also keep session transcripts on users' own machines for a set period. Check the current default on Anthropic's page and put it in the policy, so nobody assumes a session disappears when the window closes.

Take a small accountancy practice. Client records sit in Zoho CRM and bookkeeping in Zoho Books. Partners want staff to use Claude for drafting client letters and summarising long guidance notes, which the government guide lists among the tasks AI is good at. The guide also says AI struggles with tasks that need high accuracy and decisions that need professional judgement, so tax calculations and advice stay with qualified staff.

The practice makes these choices:

1. Plan: a Team plan. The office manager is the Primary Owner and the policy owner.
2. Data: client names, UTRs, bank details and payroll figures are red. Client examples with names, UTRs and other details removed are amber, but only where nobody could recognise the client from what is left. If they could, the example is still personal data and is red. Published HMRC guidance is green.
3. Features: the Primary Owner limits features to those the practice has approved.
4. Shared prompts: the practice writes a letter-drafting skill, uploads it as a .zip file containing a SKILL.md file, and it appears for everyone in Customize > Skills. Skills need code execution switched on to work.
5. Publishing: the owner sets the publishing setting to "Requires review", so staff-submitted skills need approval before others can install them. If no setting is chosen, the help centre says it switches to "Requires review" on October 2, 2026.
6. Checking: every letter is read and corrected by a person before it goes out.

Skill sharing events appear in the audit log and Compliance API as role_assignment events, though the contents of shared skills are not captured. If the practice also uses Claude Code, provisioned skills sync there unless syncClaudeAiSkills is set to false in managed settings. More processes for this sector are set out on our page on AI for accountants.

Claude Academy publishes an example of generating an AI policy with Claude. Its example policy includes sections on Governance Framework, Data Privacy and Protection, Appropriate Use Cases, Staff Guidelines, Ethical Standards and Implementation Plans. Adapted for a business focused on data going into Claude, the outline looks like this:

1. Purpose and scope: what the policy covers, who it applies to, including contractors.
2. Owner: the named policy owner and the Primary Owner of the Claude account.
3. Approved tools and plans: the company account, and the ban on personal accounts for work.
4. Permitted uses: drafting, summarising, restructuring, idea generation.
5. Prohibited uses: for example, decisions that need professional judgement. The Academy example lists clinical decisions and automated beneficiary assessments as prohibited uses for its sector.
6. Data classes: the green, amber and red table.
7. Checking output: the DWP policy requires users to check AI output for accuracy, reliability and credibility, and for misinformation or bias.
8. Approvals and exceptions: who approves what, and where exceptions are logged.
9. Logging and monitoring: what the Primary Owner can see.
10. Training: what everyone learns, and who needs more.
11. Review: dates and triggers.

For the review section, the Academy example includes an annual review and suggests triggers for interim updates: adopting new AI tools, after policy violations, when regulations change, or based on sector guidance. Its implementation workbook covers use case requests, risk assessment, training tracking, vendor evaluation, compliance monitoring and exception logs, which is a sensible set of registers to keep.

The Academy page makes the point that legal compliance for AI policies varies significantly by location, and its example template addresses a US law, HIPAA, because the example organisation handles health information. A UK business needs to anchor its policy in UK law instead.

Three points from UK sources matter most. First, if you buy an AI tool from a vendor, the ICO says you remain the data controller for the decisions made by the system, and it is your responsibility to make sure the vendor has taken the necessary steps. Signing up to a commercial plan does not hand your obligations to Anthropic. Second, the ICO says the level of detail in your policies is likely to be proportionate to the risk: the more impactful and less expected the processing, the more detail you need. Third, the ICO notes that its guidance on this subject is under review because of changes made by the Data (Use and Access) Act, so treat any policy as a living document.

The ICO also says you should consult relevant staff when drafting, so the rules make sense and work in practice. The Academy page recommends having legal counsel review the policy against your jurisdiction's requirements before board adoption. For an overview of the rules that apply, see our page on AI law in the UK for businesses.

A policy does not need a quarter-long project. For a small or mid-sized business, one week is enough to get a first version live, provided one person owns it.

1. Day one: inventory. Ask each team which AI tools they use and for what. Collect your existing data protection, information security and acceptable use policies, as the ICO and the Academy example both suggest building on these.
2. Day two: decide the plan and the owner. Choose Team or Enterprise, name the Primary Owner and the policy owner, and switch off features you have not approved.
3. Day three: draft. Use the outline above. Write the data table with examples from your own systems, not generic categories.
4. Day four: consult and review. Show the draft to a few staff who will use Claude daily, and send it for legal review if your data includes red-level material.
5. Day five: launch. Brief staff, move shared prompts into organisation skills, and open the exception log.

On the briefing, the Academy page gives useful advice: lead with what staff can do with AI tools before covering restrictions. A briefing that opens with a list of bans tends to push use onto personal accounts, which is the outcome the policy exists to prevent. Set the first review date before the meeting ends.

Start with the decision that removes the most risk: move company use of Claude onto a Team or Enterprise account and stop work use of personal accounts. That single step places the data under your organisation's agreement with Anthropic and gives you a Primary Owner who can see and manage it.

Then work through this short list:

• Name the policy owner and the Primary Owner, in writing.
• Write your green, amber and red table using examples from your own systems.
• Decide who approves new uses and exceptions, and create the exception log.
• Set the skills publishing setting to "Requires review" rather than waiting for the default change.
• Tell staff what the Primary Owner can see, and how long local transcripts are kept.
• Book the annual review and list the triggers for an earlier one.

If you are still deciding where Claude fits in your business at all, our guide on how any company can use AI sets out the common starting points. When you move from staff typing into Claude towards Claude working inside your systems, the data rules above become the specification for the integration, and our page on AI automation for growing businesses explains what that next stage involves.