|
⬡ Shadow AI & Building Your Policy · Issue 4 of 5
|
|
|
Thursday · July 9, 2026 · Issue #038
Today we start building.
Before I get into the framework, one thing I want to be clear about: an AI policy is not a legal document. It doesn't need to be reviewed by a lawyer before it exists. It needs to be reviewed by a lawyer before it becomes binding on employees or clients in high-stakes ways — but the version you write this week is a governance starting point, not a legal instrument. Treat it that way and you'll actually write it. Try to make it bulletproof before publishing it and you'll spend six months on a document that never gets used.
If your firm handles regulated data — HIPAA, SEC, bar-covered — get your relevant counsel to review the final version before it goes live. For most professional services firms, that's one conversation, not a lengthy drafting process.
|
|
⬡ What a Good AI Policy Actually Does
A good AI policy answers four questions that your team is already asking informally — and answering inconsistently. Once the policy answers them clearly, people stop improvising:
① What AI tools am I allowed to use for work?
② What data can and can't I put into those tools?
③ What do I need to do before AI-generated content goes anywhere external?
④ What do I do when I'm not sure?
That's the whole job of the policy. Four questions. Answered clearly. The document that accomplishes that for your firm is a good AI policy — regardless of how long it is.
|
|
|
⬡ The Four Sections · What Goes In Each One
|
|
|
1
|
The Approved Tools List — and the Account Tier That Matters
|
Section one lists the AI tools your firm has reviewed and approved for work use. The tool name alone isn't enough — the specific account tier matters. "ChatGPT" is not a complete specification. "ChatGPT Team plan under the firm's enterprise account, with data controls configured to opt out of training" is.
This section also names tools that are explicitly not approved for work use — including the free consumer tiers of tools your firm may otherwise allow on business plans. Clarity here eliminates the "I assumed it was fine" response.
If your approved list is currently empty — you haven't reviewed any tools — that's okay. Name a date by which the first review will be completed, and in the meantime, state that no AI tool should be used with client or sensitive data until the approved list is published. A firm date is better than vague intent.
|
Common mistake to avoid
Listing tool categories ("AI writing tools") instead of specific approved tools. Vague categories give people permission to use whatever they want and call it compliant.
|
|
|
|
2
|
The Data Rules — Where Most Firms Get It Wrong
|
This is the section most firms either skip entirely or write so vaguely it provides no actual guidance. "Don't put sensitive data into AI tools" is not a data rule. It's a statement of intent that requires every team member to independently determine what counts as sensitive — and they will all answer that differently.
The data rules section needs to work with three concrete categories. Use language your whole team understands:
|
GREEN — Approved for any approved AI tool
Internal brainstorming, draft outlines using no client specifics, grammar and editing of non-confidential text, general research questions, creating templates and frameworks that don't reference specific clients or matters.
|
|
YELLOW — Requires approved enterprise-tier tool AND prior approval
Internal business data, non-client-specific financial information, internal strategic documents, personnel information that doesn't identify specific individuals. Requires checking with [designated person/role] before use and documenting the decision.
|
|
RED — Never enters any AI tool without explicit written authorization
Client names combined with any other client information, client financial data, health information of any kind, legal matters and case details, personnel records, any information explicitly marked confidential, passwords or access credentials, contracts under active negotiation.
|
|
Why the color framework works
People remember green/yellow/red. They don't remember a paragraph of nuanced guidance. The goal is instant recognition under deadline pressure — when someone is in a hurry is exactly when they're most likely to make a data decision without thinking. Make the decision automatic.
|
|
|
|
3
|
The Human Review Requirement — What It Covers and How to Document It
|
Section three specifies which AI-generated outputs require human review before leaving the firm, and what that review must accomplish. This section isn't about distrust of AI — it's about maintaining professional accountability for everything your firm puts into the world.
The categories that typically require documented review:
| → |
Any content sent to clients, including emails, reports, proposals, and summaries |
|
| → |
Any content submitted to regulators, courts, or official bodies |
|
| → |
Any analysis or recommendation that influences a client decision |
|
| → |
Any content that will become part of an official record |
|
The review doesn't need to be a lengthy sign-off process. It needs to be a documented one. The minimum: who reviewed it, when, and a brief note confirming accuracy. Your firm's existing workflow tools — a CRM note, a project management task, a shared doc — can accomplish this without creating a new system.
|
The distinction that matters
A policy that says "all AI output should be reviewed" is unenforceable. A policy that says "AI-assisted client deliverables require review before sending, documented in [specific system] by [specific role]" is auditable. Write the second kind.
|
|
|
|
4
|
The Escalation Path — What to Do When You're Not Sure
|
This is the section most policy templates omit entirely — and it's the most important one in practice. Edge cases happen constantly. Someone encounters a new tool. A client sends data they've already processed through AI. A situation arises that the policy doesn't clearly address.
If the policy doesn't tell people what to do when they're uncertain, they'll make an independent judgment call — using their own risk tolerance, under deadline pressure. That's how you end up with the Alex scenario from Tuesday.
The escalation path needs to be:
| ① |
A named person or role — not "management" or "your supervisor." A specific name or title that changes as the firm grows. |
|
| ② |
A response time — "within one business day" or "before the task proceeds." Clear enough that people know whether they can proceed or must wait. |
|
| ③ |
A default rule for when approval can't be reached in time — "when in doubt, don't use AI for that task" is clear. "Use your judgment" is not a policy. |
|
|
Common mistake to avoid
Making the escalation path so formal or time-consuming that people bypass it in practice. If asking for approval requires a meeting or a multi-step process, people will stop asking. The path should be a quick message or email to a specific person — fast enough that using it is easier than deciding alone.
|
|
|
|
📬 Tomorrow — Series Finale
Friday: Building Your AI Policy, Part 2 — including the complete one-page template you can adapt for your firm this week, implementation guidance for rolling it out to your team without making it feel like a compliance exercise, and the three things that make AI policies fail after they're published.
Want Jordan to help build your data classification matrix? It's the fastest part to get wrong and the most important to get right: thepromptory.com →
|
|
|