Your team already uses AI. It is time to write the policy.

If your firm has no written AI policy, it still has one. It is just different for every employee and contractor. The useful version fits on one page and answers four questions: what client data may go into which tools, when a client should be told, who owns AI-assisted work, and what has to be checked before anything ships. Write that version before the policy gets written for you by a preventable mistake.

Silence creates a different rule for every person

People do not stop using AI because the firm has not discussed it. They make reasonable guesses. One person pastes a client brief into a personal account. Another uses the approved business tool but assumes disclosure never matters. One treats generated copy as a rough draft. Somebody else gives it a quick proofread and sends it.

The agency ends up with inconsistent data handling, uneven review, and no shared answer when the client asks. A blanket ban usually fails too because AI features now sit inside ordinary writing, search, meeting, design, development, and productivity tools. Unrealistic rules tend to create quiet exceptions.

The policy has one practical job: make the safe path obvious enough to follow while the work is busy.

Question one: what client data can go into which tools?

List the approved tools and the account types people must use. A reviewed business account is not the same thing as an unknown public tool or a personal account. If one tool is approved for public research but not source files, say so.

Describe information in terms the team recognizes. Public material may be acceptable in an approved tool. Internal drafts may require a firm account. Confidential client information, credentials, legal material, personal data, or unreleased strategy may be prohibited or need named approval.

Give examples because “sensitive” means different things to different people. A published web page may be fine to analyze. An unannounced launch plan may not. A fictional brief can be tested. A real customer list cannot.

Uploading a document, image, recording, codebase, or spreadsheet is still sharing information. Remove details the task does not need.

Name one person or role that can answer questions quickly. A rule that takes three days to clarify will be worked around by lunchtime.

Question two: when should a client be told?

The answer depends on the contract, the client’s own rules, the significance of the use, and what a reasonable client would expect.

Disclosure matters more when AI materially creates a final asset, processes confidential information, generates a likeness or voice, influences an important recommendation, or changes the rights around the work. It may matter less when an approved tool organizes internal notes that a person later checks and rewrites.

Contracts and client instructions win. Put those restrictions where the delivery team will see them. A clause hidden in the agreement is not an operating process.

Give account leads approved language for explaining that selected tools support defined parts of the work while people remain responsible for strategy, review, and delivery.

If a client asks directly, answer directly. A clear description of the process protects trust better than an argument about whether the use technically counted.

Question three: who is accountable?

Every AI-assisted Deliverable needs a human owner. That person should be able to explain the source material, the tool’s role, what changed afterward, and why the final work meets the brief.

The model cannot own accountability. A fluent answer can contain false claims, missing context, borrowed language, or a recommendation that ignores the client. The agency still signed the statement of work.

Match review to risk. An internal summary may need a source check. Client copy needs factual, voice, and brief review. Code needs testing. Images and video may need rights, likeness, and brand review. Consequential material may need a subject expert.

Name the approver before work begins. Several people can contribute, but somebody still needs the final call. Shared production should not create shared ambiguity.

Question four: where is the quality line?

Polished output does not get a free pass. It has to meet the same standard as work created any other way.

The final Deliverable must answer the brief, use supportable facts, respect the client’s voice and constraints, contain no confidential material, and be reviewed in its final format. Resolve material uncertainty or state it clearly.

Return to primary sources for important claims. An assistant can cite the wrong page or summarize away the sentence that changes the meaning. The person approving the work should be able to trace the important facts.

Protect originality too. Ask what judgment, observation, or creative choice makes the work belong to this client. If the answer is nothing, the piece is not ready.

Make the policy easier than improvising

Keep the core policy to one page. Use a compact table for approved tools and data categories. Add examples of allowed, prohibited, and approval-required uses. Link out to deeper guidance instead of stuffing it into the main rule.

Introduce it in a short team conversation. One realistic example will reveal fuzzy language faster than another editing round.

Give people a simple way to report mistakes. If restricted information gets uploaded, contain the issue, preserve the facts, and follow the firm’s incident process. Punishing fast reporting teaches people to hide problems.

Cover contractors as well as employees. Include the policy in onboarding and agreements, and remove access when the work ends.

Update the edges, not the principles

Review the policy on a schedule and when a major tool or client requirement changes. Do not rewrite it for every model release. The four questions stay useful even while product names rotate.

Keep the approved-tool list and examples in a maintained section that can change without reopening the whole policy. Record the owner and last review date. Remove tools the firm no longer uses.

The principles are steady: share only what the task needs, tell clients when the use matters, keep a person accountable, and hold one quality standard. Writing them down makes the expectations visible before a mistake starts the conversation.

FAQ

Do we legally need an AI policy?

Requirements vary by location, industry, contract, data, and use. Get legal advice for your firm’s circumstances. Even when no single law says “write an AI policy,” duties involving privacy, confidentiality, employment, intellectual property, and client agreements may still apply. This article is operational guidance, not legal advice.

Should we disclose AI use to every client?

Not necessarily for every minor internal assist. Do not hide a use that the contract, client policy, or reasonable expectation makes material. Set a default and an escalation rule so delivery teams are not making the decision from scratch on every Job.

How do we enforce a policy without policing people?

Make compliance easier than improvisation. Provide approved tools, realistic examples, a fast place to ask, and review steps matched to risk. Include contractors and periodically review access and output. Encourage quick reporting when something goes wrong so the firm can respond.