04Insights · AI

AI governance for a 20-person company: the minimum viable policy

6 min read

Without clear rules about what data can go into which tools, you're exposing client confidentiality and work product to unnecessary risk every time someone on your team pastes into ChatGPT. This isn't a hypothetical. It's happening today in service firms and law offices across DFW—quietly, repeatedly, with no incident report filed because no one knew it was an incident. You don't need enterprise-grade governance to stop it. You need two pages of actual rules that your team will read, remember, and follow.

What enterprise frameworks get wrong—and why SMBs stay unprotected

Enterprise AI policies are built for organizations with 500 or more people, dedicated legal counsel, and a compliance team whose only job is policy enforcement. When a 20-person firm downloads one of those templates, fills in the company name, and prints it out, one of two things happens. Either no one reads it because it's 40 pages of definitions and escalation matrices. Or someone reads it, gets confused about which section applies to them, and goes back to doing whatever they were doing before.

The cruel irony: a policy that doesn't change behavior creates legal liability without creating protection. You've now documented that you had an AI governance framework—but when a client discovers their financial statements ended up in a model's training corpus, your printed policy won't save you.

The real constraint for a DFW SMB isn't regulatory compliance, at least not yet. It's preventing data leaks and protecting client work product. That's a simpler problem. It requires a simpler solution. Fewer words, more specificity, one clear rule per scenario.

The four things that actually matter: data, tools, review, response

A minimum viable AI policy for a 20-person company covers exactly four topics. Everything else is filler.

Data classification. Draw one line. On one side: off-limits. Contracts, financial statements, medical records, client communications, proprietary source code, legal work product, personnel files. On the other side: fair game. Industry research, publicly available documentation, general writing tasks, internal brainstorming. Don't write "sensitive client information"—write the actual categories. Your paralegal or account manager needs to recognize the rule when they're staring at their keyboard, not after they've re-read the policy document.

Tool whitelist. Name the specific models your team can use. ChatGPT with your organization's enterprise account—yes. That new trending AI startup your intern read about—no. Approved tools only. This isn't security theater. It's liability containment. Enterprise tiers of established models have data processing agreements you can actually point to. Unlisted tools don't. The whitelist also solves the churn problem: write it vendor-neutral at the category level ("approved enterprise AI tools, listed in the internal wiki") and you only update the wiki when tools change, not the policy itself.

Accountability. Someone—usually you, your COO, or a senior practice lead—reviews AI-generated work product before it ships to clients. Not everything. Focus on anything that touches a client deliverable, a legal filing, a financial recommendation, or external communications. The review doesn't need to be deep. It needs to happen. The point is that no AI output goes out the door without a human signature attached to it. When something is wrong, you catch it before the client does.

Incident response. Define what happens when someone pastes client data into a non-approved tool by mistake—because they will. The response process matters more than the policy language. Document the incident internally. Assess what data was exposed and to which tool. Notify affected clients if your engagement agreement or applicable law requires it. Log the lesson. Move on. The goal is a response that doesn't involve panic or improvisation. Teams that have never written this down discover what they're missing at the worst possible moment.

How to write it in two pages and actually have people follow it

Concrete examples beat abstract categories every time. Don't write "sensitive client information"—write "contracts, medical records, financial statements, and attorney-client communications." Your team needs to recognize the rule when it's relevant, not decode it. If you're running a law firm, name the specific document types. If you're running a marketing agency, name what client assets are off-limits. Generic language gives your team cover to make bad judgment calls. Specific language removes the ambiguity.

Assign one person as the policy owner. Not an enforcer—an owner. Their job is to answer questions, approve exceptions, and update the document when something breaks. You want adoption, not compliance theater. An enforcement mindset turns your team into policy avoiders. An ownership mindset turns your policy owner into a resource people actually consult.

Review the policy quarterly, not annually. AI tooling changes faster than any annual review cycle can track. More importantly, your policy should incorporate what you actually learned when something almost went wrong last quarter—not what a template said when you first wrote it. The quarterly review doesn't need to take more than an hour. If nothing happened and nothing changed, you're done in fifteen minutes.

Keep the whole document to two pages. If it's longer than two pages, you've added something that isn't essential. Cut it. A policy your team reads and remembers in two pages does more work than a comprehensive framework that lives in a shared drive no one opens.

If you're running a service business or law firm in DFW where client confidentiality and work product liability are the real stakes, we can help you build this framework in a single conversation. The gap between policy and actual behavior is where exposure lives. We've helped firms close that gap without generating irrelevant bureaucracy. If that's the problem you're working on, schedule an intro call and bring a specific scenario—what your team is already using AI for, and where you're not sure the guardrails are holding.

Want this kind of thinking applied to your situation?