Resources / Compliance
An AI acceptable use policy your firm can adapt
The AI acceptable use policy we give our own clients, published in full. Take it, change the bits that do not fit, and put it in front of your people.
This is the AI acceptable use policy we give our own clients, published in full on this page — free to read, copy or print, with nothing hidden behind a form. A policy nobody can read is not much use to anyone.
Take it, change the parts that do not fit your firm, and put it in front of your people. It is a starting point, not a finished document.
This is a practical operational template, not legal, regulatory or data-protection advice. Your firm’s obligations depend on its circumstances, clients, systems and intended use of AI. Read it before you adopt it, and take advice where the stakes justify it.
Two notes before you use it. Where the policy says Techsperience, substitute your own IT provider if you have one, or the internal role that will do that review. And if you want to know which parts of it matter most for your firm right now, the Law Firm AI Readiness Check scores exactly these areas in about six minutes.
Purpose
Artificial intelligence tools can improve productivity, assist with research, generate content, summarise information, support coding and automate repetitive tasks. They also introduce risks: data leakage, incorrect outputs, insecure automation, intellectual property exposure, regulatory breaches and uncontrolled system access.
This policy defines how AI may be used safely within the firm. The aim is not to block AI use, but to ensure it is used in a controlled, secure and responsible way.
Scope
This policy applies to all employees, contractors, temporary workers, third-party users and any person using firm systems or data.
It applies to web-based AI tools, Microsoft 365 Copilot and similar business AI assistants, browser extensions, SaaS applications with built-in AI features, AI coding tools, chatbots, automation platforms, locally installed AI tools, custom-built AI integrations, and APIs connected to AI models.
What counts as an AI tool
For this policy, an AI tool means any system that can generate, summarise, classify, interpret, predict, automate or make recommendations using machine learning or artificial intelligence.
Examples include ChatGPT, Microsoft Copilot, Google Gemini, Claude, Perplexity, AI meeting-note tools, transcription services, coding assistants, image generators, automation tools, and AI features embedded in applications you already own.
That last category matters more than people expect. Most firms acquire their first AI tool without deciding to, because a supplier switched a feature on.
Core principles
Data protection first. Sensitive, confidential, personal, internal or client data must not be entered into unapproved AI systems.
Human accountability. AI may assist decision-making, but responsibility remains with the person using it.
Verify before use. AI outputs must be checked for accuracy before being relied upon or shared.
Least privilege. AI tools must only have access to the minimum data and systems required.
Isolation before integration. AI systems must be tested in isolated environments before being connected to business systems.
No shadow AI. AI tools must not be introduced, connected or deployed without visibility and approval where required.
Approved and unapproved tools
An AI tool may be used where it has been reviewed and approved. Approval means someone can answer all of the following:
- Who provides the tool?
- Where is data processed?
- Is data stored, and for how long?
- Is data used to train the provider’s models?
- What security controls are available?
- Can access be managed centrally?
- Can usage be audited?
- Can data be deleted?
- Is there a commercial or enterprise agreement in place?
If those questions cannot be answered, the tool is not approved — regardless of how useful it is.
Unapproved tools must not be used with client data, personal data, confidential firm data, internal documents, credentials, source code containing business logic, financial information, HR information, security information, data exported from firm systems, or the contents of mailboxes.
They may be used for general, non-sensitive tasks: brainstorming, rewriting non-confidential text, or learning general concepts.
Information that must never go into an unapproved AI tool
Across the firm
- Personal data, and special category personal data
- Passwords, API keys, MFA codes, access tokens or other secrets
- IT and infrastructure information — network diagrams, system configurations, security tooling, monitoring and backup arrangements
- Vulnerability reports, penetration test results or security incident details
- Internal financial data, payroll or HR records
- Board papers, partnership agreements, or anything commercially sensitive
- Internal email threads containing any of the above
- Anything classified as confidential or restricted
Specific to a law firm
- Matter files, or any document taken from a live matter
- Client identities linked to the nature of their instruction
- Anything covered by legal professional privilege — counsel’s opinions, advice notes, privileged correspondence
- Draft pleadings, witness statements and court bundles
- Client money records, ledgers and completion statements
- AML and KYC documentation, including source-of-funds evidence
- Conflict-check data, and information barrier arrangements
- Medical records and expert reports in personal injury, clinical negligence or family matters
- Wills, lasting powers of attorney, trust deeds and estate information
- Undertakings given or received
- Anything covered by a client’s outside counsel guidelines or panel terms, particularly where those terms say something about AI
The simple version: if the information would not be safe to post publicly, it must not go into an unapproved AI tool.
Permitted use
- Drafting non-sensitive emails
- Improving grammar or tone
- Creating outlines
- Generating ideas
- Summarising public information
- Explaining general concepts
- Producing first drafts of policies or templates
- Generating sample text using fictional data
- Assisting with non-sensitive code examples
- Producing marketing ideas containing no confidential information
Restricted use — approval required
- AI tools processing internal firm data
- AI tools processing client or matter data
- AI tools connected to email, document management, practice or case management, time recording and billing, finance, HR, or any other system holding client information
- AI tools producing external client correspondence, or anything that leaves the firm on its letterhead
- AI tools making recommendations that affect clients, staff, the firm’s finances, legal matters or security
- AI tools used for recruitment, HR, disciplinary or performance decisions
- AI tools generating or executing scripts
- AI tools embedded in a live business process rather than used ad hoc
- AI tools automating actions without human review
Prohibited use
The following are prohibited unless explicitly approved in writing by senior management following a risk assessment:
- Uploading client or personal data to unapproved AI tools
- Connecting AI tools directly to live firm systems without approval
- Allowing AI to make final decisions without human review
- Allowing AI to send external communications automatically
- Allowing AI to create, modify, delete or move business data without oversight
- Allowing AI to change security settings, or to reach administrative areas of any system
- Allowing AI to access the systems that keep the firm secure, backed up or logged in, without review
- Running AI-generated scripts on live systems
- Using AI to bypass firm security controls
- Using AI to monitor staff without approval
- Using AI to generate misleading, deceptive, harmful, discriminatory or unlawful content
- Using AI for legal, medical, financial or regulatory advice without qualified review
Test in isolation before connecting anything
Any AI tool, integration or automation must be tried in isolation before it touches live systems or real client information.
An isolated environment is one with no access to live matter files, client data, the firm’s document or case management system, mailboxes, the accounts or client money systems, HR records, administrative logins, or the systems that keep the firm secure and backed up.
In practice that usually means one of the following:
- A separate test tenant or trial account
- A closed matter with names and identifying details removed
- Entirely invented data
- A demonstration environment provided by the supplier
Testing should establish that the tool reaches only the information you intended, sends nothing outside the firm, takes no action without being asked, keeps nothing it does not need, produces output a person can check, and can be turned off quickly.
Containment boundaries
A containment boundary is the limit of what an AI system can access, process, influence or change. Examples:
- A specific sandbox tenant
- A defined dataset
- A single test mailbox
- A single file library, separate from the live one
- A read-only knowledge base
- A restricted user account
- A defined workflow with manual approval gates
AI systems must not cross those boundaries without approval. Crossings to watch for include moving data from a secure environment into an unapproved AI tool, connecting a test workflow to live email, connecting AI to a client system without authorisation, granting access to every SharePoint site when one library is needed, using an administrator login, running AI-generated scripts on machines people work on, processing several clients’ matters in one shared workspace, or letting AI reach the systems that keep the firm secure, backed up or logged in without review.
Default position: AI may observe only what it has explicitly been permitted to observe, and may act only where a human has approved the action.
Treat imported code, scripts and prompts as untrusted
All AI-generated code, externally sourced scripts, community templates, GitHub examples, Stack Overflow snippets, automation recipes, browser extensions and prompt packs are untrusted until reviewed.
Before use, establish what the code does, what it connects to, what data it reads or writes, whether it sends data externally, whether it downloads further code, whether it contains hidden endpoints, whether it needs elevated permissions, whether it stores credentials, whether it logs sensitive data, whether it changes security settings, and whether it can be rolled back.
Prohibited in all cases:
- Copying and running scripts straight onto live systems
- Running unknown scripts as administrator
- Running AI-generated code without review
- Allowing AI to generate and execute code automatically
- Using scripts containing hardcoded credentials or contacting unknown domains
- Using scripts that disable security controls, or alter firewall, identity, backup or endpoint protection settings without approval
Human review and accountability
AI outputs must be reviewed by a competent human before being relied upon. That applies to emails, reports, policies, contracts, technical advice, code, scripts, security recommendations, client communications, financial analysis, HR content, compliance documentation, and any decision affecting people or clients.
The reviewer is responsible for checking accuracy, completeness, bias, tone, confidentiality, legal and regulatory implications, appropriateness for the audience, and whether the output contains invented facts or unsupported claims.
The last of those is the one that catches people out. Confident, well-formatted and wrong is the characteristic failure mode.
Risk categories
| Category | Examples | Requirement |
|---|---|---|
| Low | General brainstorming, drafting non-sensitive text, rewriting public content, fictional examples, summarising public information | User discretion, plus output review |
| Medium | Internal non-sensitive information, internal process documents, anonymised analysis, anything tested away from live systems, internal workflows with human review | Manager approval, and IT review where firm systems or data are involved |
| High | Client or matter data, personal data, firm systems, decisions affecting clients or staff, anything connected to a live system, workflows that act on their own | Formal AI Usage Request, risk assessment, and approval before use |
| Prohibited or exceptional | AI with administrator access, access to the systems that keep the firm secure, final decisions about people, external communications sent automatically, unsupervised changes to live systems, regulated data processed without controls | Not permitted unless formally approved by senior leadership after risk assessment |
Approval process
An AI Usage Request must be completed before introducing a new AI tool, connecting AI to firm systems, processing internal or client data with AI, using AI for automation, running AI-generated scripts against firm systems, putting AI into day-to-day use, or changing the scope of a tool already in use.
No high-risk AI use may proceed without approval.
Reporting concerns and incidents
Report immediately if:
- Sensitive data has been entered into an AI tool
- Client data has been uploaded to an AI system
- An AI tool has been connected to the wrong system
- AI has produced harmful, misleading or inappropriate content
- AI has taken an unauthorised action
- AI-generated code has caused unexpected behaviour
- Anyone is unsure whether a particular use is safe
That last one matters. Most firms find out about a problem because somebody asked a question, and people only ask when asking is welcome.
Reports go to your manager, your internal IT contact, or your IT provider.
Policy review
Review this policy at least annually, and sooner where new AI tools are introduced, regulations change, business systems change, a security incident occurs, client requirements change, or your provider recommends it.
AI products change what they do with your data on their own schedule, not yours. A policy written this year describes a product that may not exist in the same form next year.
Using this well
A policy is the first control, not the whole of it. It tells people where the line is; it does not stop anyone crossing it. The firms that handle AI well pair the written position with three practical things: someone named who owns the decision, permissions tight enough that a tool cannot surface what it should not, and a route for people to ask questions without feeling stupid.
If you want to know where your firm currently stands across all of that, the Law Firm AI Readiness Check scores it in about six minutes, free, with no email required to see the result.
Want to see how this works in practice?
We give this policy to the firms whose technology we run, and help them put it into practice — approving tools, drawing the boundaries, and reviewing it as the technology and the firm change.
Those firms also get access to our AI portal, where the policy stops being a document and becomes something you can see working across the firm. It is available to clients only — get in touch if you would like a look at it.
Frequently asked
Common questions on this topic.
Can we use this policy as it is?
You can, but you should not. Read it through and change what does not match how your firm works — the approval routes, the named contacts, and the risk categories in particular. A policy that describes someone else’s firm is worse than no policy, because it gives false comfort and nobody follows it.
Does having an AI policy satisfy the SRA?
The SRA does not mandate a specific AI policy. It expects firms to protect client confidentiality, supervise work properly and manage risk — obligations that apply whether or not AI is involved. A written policy is evidence that you have thought about it, which is useful when a client or regulator asks. It is not a substitute for actually controlling what happens.
Our staff are already using ChatGPT. Is it too late for a policy?
No, and that is the normal starting position. Almost every firm has more AI in use than it thinks. A policy that acknowledges existing use and sets boundaries is far more effective than one written as though nobody has started yet — people ignore rules that pretend not to describe reality.
Do we need a different policy for Microsoft 365 Copilot?
Not a separate policy, but Copilot deserves particular attention within it. Copilot inherits each user’s existing permissions, so it surfaces whatever that person could already have found. That makes permissions and access reviews the controlling factor, which is why they appear in the policy and in our AI Readiness Check as critical items.
Who should own this policy?
One named person with the authority to approve or refuse a tool. Splitting it between IT, risk and the partnership usually means nobody owns it. The policy is only as good as the person who can say no.
Related reading