Written by Marijn Overvest | Reviewed by Sjoerd Goedhart | Fact Checked by Ruud Emonds | Our editorial policy

Claude AI Policy for Procurement: Memory, Projects, and Computer Use

Why Claude Specifically Needs a Policy

A generic AI policy usually exists in organisations with any AI maturity. It covers the high-level questions: acceptable use, confidentiality, basic data handling, sanctioned versus unsanctioned tools. What it often does not cover is the specific features of specific AI tools that have governance implications.

For Claude, three specific features create governance questions the generic policy does not answer.

Memory. Claude's Memory feature stores facts across every conversation the user has. That is useful for procurement productivity and potentially problematic for data governance. The policy needs to say what categories of information are appropriate for Memory and what are not.

Projects. Projects contain files that may be sensitive, contracts, supplier scorecards, commercial terms. The policy needs to address which types of content belong in a Project, who can share Projects, and how long Projects are retained.

Computer Use. If the procurement team uses or plans to use Computer Use, the policy needs to specify which workflows are authorised, what approval is required for write actions, and what the audit trail looks like.

The Procurement Tactics 2026 AI Readiness in Procurement survey found 40% of procurement organisations have no AI policy at all. The share with a Claude-specific policy is much smaller. Procurement organisations scaling Claude without this governance work tend to produce a small set of predictable incidents that could have been prevented.

The Three-Area Structure of a Claude Policy

1. Data classification for Claude workflows

What categories of procurement data are appropriate for Claude, and on which features. Standard supplier data, general spend analysis, and routine contract review are usually fine on an enterprise Claude plan with commercial data-handling terms. Highly confidential commercial terms, regulated data (health, financial, defence-adjacent), and information from suppliers who have not consented to AI processing typically need additional review.

The classification statement should be two paragraphs, not a full information security framework. The specifics are handled by the organisation's broader information classification policy; the Claude-specific addendum says which classification levels are appropriate for which Claude features.

2. Memory and Projects governance

The policy specifies what goes in Memory (stable organisational context, role information, standard frameworks), what goes in Projects (workstream-specific content), and what goes in a single-use chat (sensitive content that should not persist).

For Projects specifically, the policy addresses: who can share a Project across a team, what review cadence applies to Projects containing sensitive data, when Projects should be retired.

3. Computer Use boundaries

If Computer Use is in scope: which workflows are authorised (usually read-only initially), which are explicitly forbidden (anything that would commit the organisation financially without human approval), and what the audit trail requirements are.

The policy should say explicitly that Computer Use is not authorised for workflows not named in the policy. The pattern that works is opt-in by specific workflow rather than opt-out of a broad permission.

What the Policy Looks Like in Length

Eight to ten pages is the sweet spot. Structured as: one page introduction, two pages on data classification, two pages on Memory and Projects governance, two pages on Computer Use, one page on roles and review cadence, one page on incident response.

Longer policies do not get read. Shorter policies leave too much unaddressed. The bounds are well-established from how procurement organisations actually use their policies in practice.

Ownership and Review

The policy is jointly owned. Procurement operations drafts the initial version and owns day-to-day application. IT security reviews the technical accuracy, how Memory actually works, what Projects actually share, what data Computer Use actually touches. Legal reviews the commercial accuracy, what the Claude enterprise terms cover, what data protection obligations apply, what incident response requirements the policy should include.

Single-function ownership tends to produce policy that is strong on one dimension and weak on the others. Joint ownership requires coordination but produces policy that is actually followed because each function has contributed to it.

Annual review is the minimum cadence. More frequent review is warranted when Claude's capabilities change materially, Anthropic releases significant Claude updates regularly, and some have policy implications.

The AI Fundamentals for Procurement Teams program provides a starting template that procurement teams adapt rather than writing from scratch. Adaptation takes an afternoon; writing from scratch takes weeks and usually misses something.

Frequently asked questions

How long should a Claude AI policy for procurement be?

Eight to ten pages. Long enough to cover the three core areas substantively, short enough to actually be read and applied by procurement professionals.

Can we use a generic AI policy instead of a Claude-specific one?

A generic policy is necessary and probably exists. A Claude-specific addendum addresses the Claude-specific governance questions, Memory, Projects, Computer Use. Both are typically needed.

Who approves the Claude policy before rollout?

Typically procurement leadership (CPO or Head of Procurement), IT security leadership, and legal leadership. Larger organisations also involve compliance and risk management.

How often should the policy be reviewed?

Annually as a minimum. More frequently when Anthropic releases Claude capability changes with policy implications, or when the procurement organisation changes its Claude deployment scope materially.

What happens when a user violates the policy?

The policy should specify the incident response, containment, investigation, remediation, communication to affected stakeholders. Most procurement organisations handle AI policy incidents through the existing information security incident process with minor adjustments.

Does the policy need to cover every Claude feature?

No. It needs to cover the features procurement actively uses and expects to use in the next planning cycle. Features the procurement team has not adopted can be added to the policy when they are, which is why the review cadence matters.