A Client Has Asked for Our AI Policy: What Should It Say?

Six sections: which AI tools are approved, what data may be entered into them, who owns approval for new tools, how AI output is reviewed before it reaches a client, what happens when someone breaks the rules and who to contact with questions. Two to four pages is enough.

Reviewed by Jason Holloway, QL Security.

What should an AI policy actually say?

Those six sections are the framework we use in our own policy work, and they are the whole substance. Everything beyond them is usually either restating a policy you already have or describing controls you do not yet operate. Both weaken the document.

A client reading your policy is testing whether you have thought about the problem and can describe your own behaviour accurately. A short policy that matches reality passes that test. A twenty-page policy describing an approval board you have never convened does not, because the first question in a follow-up call will expose it. Our AI Security Programmes hub sets out how policy, tooling and assurance fit together. Our AI governance entry covers the wider structure a policy sits inside.

What is the client actually checking for?

In most supplier requests we see, the client is checking three things rather than assessing your policy against a framework: that a policy exists and is dated, that it names a person or role accountable for AI decisions and that it says something specific about client data entering third-party AI tools.

An undated document suggests nobody owns it. The data question matters because that is the risk their own legal team raised when the questionnaire was drafted. Your client is answering the same question further up their own supply chain: their customer or regulator asked them about AI in their delivery chain, and they are passing it down. They need a document they can point to. Give them one that is clear about data handling and accountability and you have solved their problem. Where the request arrived as a questionnaire, our guidance on answering the AI section of a security questionnaire covers the wording. Where the request exposes gaps a policy cannot close on its own, our AI Security Gap Analysis is the usual starting point.

How specific do we need to be about which tools are approved?

Name them: list the tools your people actually use, with a short note on what each is approved for. A policy saying “approved AI tools may be used in accordance with this policy” without listing any tools gives a client nothing to test and reads as evasive. Where a tool is embedded in software you already licence, say so, because clients frequently miss that AI features arrive inside products they have already approved.

The list will date quickly. That is why it belongs in an appendix or a linked register rather than the policy body. The policy states the rule about approval; the register records the current answer. You then update a one-page register quarterly instead of reissuing the policy every time someone requests a new tool. Unapproved tools already in use are the harder problem, and our Shadow AI entry covers how unsanctioned usage enters an organisation.

Do we need an ISO 42001-aligned policy?

Only if you are pursuing certification or a client has asked for it explicitly. ISO 42001 is a management system standard, so an aligned policy is one component of a much larger documented system covering risk assessment, impact assessment, competence, monitoring and internal audit. Writing an ISO-shaped policy without the surrounding system produces a document that promises processes you do not run.

For a client questionnaire, write the short, accurate version now. If certification becomes a commercial requirement later, the policy is straightforward to rework once the management system exists around it. Building the paperwork first and the practice second is the most common sequencing error we correct. Whether certification is worth the cost at your size is covered in is ISO 42001 worth it.

Similar logic applies to the EU AI Act. The Act is not the frame for a staff-use policy, but do not dismiss it either: deployers carry an AI literacy obligation, which does reach how your staff use commercial AI tools, so competence and training belong in your thinking even where the Act is not driving the document. Check your own position against the Act’s text and your advisers’ reading of it.

Should we just ban AI instead?

A blanket ban is a legitimate position, but only if you can enforce it and are willing to police it. In practice, staff at organisations with a stated ban continue using consumer AI tools on personal devices for work tasks, which moves the same data outside your control while removing your visibility of it. You have traded a manageable risk for an invisible one.

The pressure is sharper in a small business, where one person may hold the only working knowledge of a client account and a tool saving them two hours a week is difficult to give up on instruction alone.

If you do ban, say what problem the ban addresses and when you will review it. A ban with a stated review date reads as a considered decision. An indefinite ban with no rationale tells a client you have not engaged with the question.

Who should own the policy?

One named role, with authority to approve or refuse a tool request. That is usually the ops director, the compliance lead or the head of technology depending on where decisions actually land. Committees suit larger organisations with enough volume to justify one; for an SME, a committee means requests wait for a monthly meeting and people route around the process.

Name the role in the document and put a real person behind it. Clients notice the difference between a policy that points to “the AI Governance Committee” and one that names an individual, with their job title beside their name.

How long should this take?

A first version is a half-day exercise if you already know which tools your people use. Most of the elapsed time goes on discovery: asking teams what they are using, which usually surfaces three or four tools nobody had recorded. Do that discovery properly, because a policy written from assumption will contradict what your staff describe if a client ever asks them directly.

Allow another week for review by whoever signs it. Do not let the exercise expand into a governance programme because a client asked one question.

What happens after we send it?

Date it, log the version and set a review interval you will honour. Six or twelve months is reasonable. Then tell your staff it exists, because a policy nobody has read is a document rather than a control.

The follow-up question, when it comes, is usually about verification: how do you know staff comply? Our AI Behaviour Verification service covers how that assurance layer works. Our Shadow AI discovery FAQ covers checking what staff are actually using in practice.

This page is general guidance drawn from our client work and is not legal advice. Take your own advice on your regulatory position before relying on it in a compliance document.