Does Your Team Need an AI Use Policy Before It Needs AI Tools?

Does Your Team Need an AI Use Policy Before It Needs AI Tools?

You need it before the tools become load-bearing, which is earlier than most teams think. A policy written after an incident is a post-mortem. Written before, it is a short document that lets people use AI confidently instead of quietly. The goal is permission with edges, not restriction.

We build AI into client workflows, and the pattern is consistent. The tools arrive through individuals, spread informally, become essential, and only then does anyone ask what the rules are. By that point the rules have to be retrofitted onto habits.

This is a practical framework, not legal advice. Anything below that touches regulation should be checked with a lawyer in the markets you operate in.

Why Do Most Teams Skip This?

Because adoption has outrun governance almost everywhere, and a policy feels like a brake on something that is working. The Content Marketing Institute and MarketingProfs found in their 2026 B2B research, from 1,015 B2B marketers fielded between 24 June and 14 August 2025, that 95 percent of organisations use AI-powered applications.

The maturity split underneath that number is the real story. Among those organisations, 20 percent described themselves as exploratory, 48 percent as developing, 24 percent as established, 5 percent as advanced and 3 percent as leading.

So near-universal use, and more than two thirds still figuring out how to use it. That is exactly the gap a short policy is for. It is not a governance programme, it is a way to stop the same question being answered differently by twelve people.

What Is Actually at Risk?

Four things, and only one of them is regulatory. Customer data going somewhere it should not. Confidential material becoming training data. Work being published that nobody verified. And decisions being made by a system nobody can explain afterwards.

The third is the one that bites soonest for most teams, because it is the most ordinary. Someone ships a page, a proposal or a support reply containing a confident statement that is not true, and the error carries your company's name.

The fourth is slower and harder to unwind. Once an AI step sits inside a process with no record of what it decided or why, you cannot audit the process at all. Our piece on audit trails for AI automations covers what to log.

Does Any Law Require a Policy?

Not a policy document as such, but obligations are arriving that a policy is the practical way to meet. The EU AI Act is Regulation (EU) 2024/1689, laying down harmonised rules on artificial intelligence, and it entered into force on 1 August 2024.

The European Commission sets out a phased timeline. Prohibited practices applied from 2 February 2025, general purpose AI governance obligations from 2 August 2025, and general applicability from 2 August 2026. High-risk system obligations follow later, from 2 December 2027 for certain sensitive areas and 2 August 2028 for regulated products.

The Act sorts systems into four risk levels: unacceptable risk, covering nine prohibited practices; high risk, carrying strict compliance obligations; transparency risk, where use of AI must be disclosed and generative content made identifiable; and minimal or no risk, with no specific rules.

Most B2B marketing and operations use sits in the transparency or minimal tiers rather than high risk. That is reassuring and it is not the same as nothing. Our piece on the AI Act and marketing automations goes through which tier common tools fall into.

What Does the AI Act Expect From a Deployer?

This distinction matters more than most teams realise, because almost everyone is a deployer rather than a provider. If you build and put an AI system on the market you are a provider. If you use someone else's, you are a deployer, and the obligations differ.

The Commission describes provider obligations as conducting risk assessments, using high-quality datasets, maintaining activity logs, providing documentation, ensuring human oversight and meeting robustness standards.

Deployer obligations are narrower but real: ensuring human oversight and monitoring, reporting serious incidents and malfunctions, and maintaining post-market surveillance.

Read those three deployer duties as a specification for your policy. Who oversees, how monitoring happens, and who reports when something goes wrong. If your policy answers those, it is doing useful work rather than signalling.

Is There a Framework Worth Starting From?

Yes, and it is free. The NIST AI Risk Management Framework was released on 26 January 2023 and is intended for voluntary use, to improve how trustworthiness is considered in the design, development and evaluation of AI products.

Its structure is four core functions: Govern, Map, Measure and Manage. That is a more useful skeleton for a small team than it looks, because it forces four different questions rather than one. Who decides. What are we using it for. How do we tell if it is working. What do we do when it is not.

NIST also published a generative-specific companion. On 26 July 2024 it released NIST-AI-600-1, the Artificial Intelligence Risk Management Framework Generative Artificial Intelligence Profile, to help organisations identify risks unique to generative AI and suggest management actions.

One caveat worth knowing before you build heavily on it: NIST notes that AI RMF 1.0 is being revised as part of the White House AI Action Plan. Use the structure, and expect the detail to move.

What Should a One Page Policy Actually Say?

Six things, and it genuinely fits on a page. Which tools are approved and who approves a new one. What data may never be pasted into any of them. Which outputs require human review before they leave the company. What must be disclosed to customers. Who to tell when something goes wrong. And when the policy gets revisited.

Write it as permissions, not prohibitions. "You may use these tools for these purposes without asking" removes far more uncertainty than a list of bans, and it is the uncertainty that drives people to use tools quietly.

Be concrete about review. "Human review" means nothing. "Anything published under the company name, sent to a customer, or committed to a repository is reviewed by a named person" means something, and people can follow it.

Keep the approved tool list short and easy to extend. A three week approval process for a new tool guarantees the policy is ignored, and an ignored policy is worse than none because it creates false confidence.

How Do You Handle Customer Data?

With a bright line, because this is the one rule that cannot have judgement in it. Name the categories that never go into a general-purpose AI tool, and name them specifically enough that nobody has to interpret: customer personal data, credentials, unreleased financials, anything under NDA.

Then provide the sanctioned path for the legitimate version of that need. People paste customer data in because they have a real job to do. If the policy only says no, they will find a way around it. If it says no, and here is the approved tool configured to handle it, the rule holds.

Check what each tool does with inputs by default, and check it again after any plan change. Retention and training settings are exactly the kind of thing that differs between tiers of the same product. Our guide to customer data in AI automations covers what to look for.

Who Enforces It?

One named person, with enough authority to say no and enough involvement to say yes quickly. Distributed responsibility for this produces no responsibility, and a committee produces delay, which produces workarounds.

The role is small in practice. Approve new tools, hold the data line, and be the person incidents get reported to. In a company under a hundred people that is a few hours a month, not a job.

Give them a real reporting path for mistakes, and make using it survivable. If admitting that an AI-generated error reached a customer is career-limiting, you will not hear about the errors, and the deployer duty to report serious incidents becomes impossible to meet. Our piece on accountability when an AI automation gets it wrong covers that culture problem.

How Do You Keep It From Becoming Theatre?

Attach it to real moments rather than to an annual training module. The policy should surface when someone requests a new tool, when something is about to be published, and when an incident is reported. Those are the three points where it changes behaviour.

Revisit it on a schedule, and say on the document when the next review is. This field moves fast enough that a policy without a review date is stale within a year. The AI Act's own obligations are still phasing in through 2028, and NIST's framework is being revised, so a static document is guaranteed to drift.

And measure something. Even a count of approved tools, exceptions granted and incidents reported tells you whether the policy is being used or routed around. A policy nobody ever invokes is either perfect or invisible, and it is rarely perfect.

Where Would We Start?

Write the data line first, today, in one sentence, and send it to everyone. That single rule prevents most of the damage available in this area, and it does not need a committee or a lawyer to draft.

Then build the rest of the page over a fortnight using the NIST functions as headings, and name the person who owns it. You are aiming for something people can read in two minutes and actually remember, not a document that satisfies an auditor who has not asked yet.

If you want help thinking through how AI fits into your website, content or operations workflow without creating problems you cannot see, we are happy to walk through it. You can find us at phoenix.studio.