AI governance for companies without a governance department.

Enterprise AI governance frameworks assume dedicated staff to run them. A NIST AI RMF-style program or an ISO 42001 implementation assumes a risk committee, a documented review cadence with multiple stakeholders, and someone whose full-time job is tracking AI use across the company. That's the right investment at 5,000 employees. At 200 employees, the same framework becomes a document that gets written once for a board deck and never touched again, because there's no one to run the process it describes.

The result we see constantly: a 40-page AI policy PDF sitting in a shared drive, and engineers making real decisions about model choice and data handling with no idea the document exists. A policy nobody reads provides zero actual risk reduction. It just creates a false sense that governance is handled.

1. Data boundaries. Write down, in plain language, what data can and cannot be sent to an external AI model. Customer PII, health data, financial account numbers, anything under an NDA, these need an explicit yes or no, not a vague "use good judgment" clause. If the answer is "it depends," write down what it depends on.
2. Approved models and vendors. A short list of models and vendors cleared for business use, based on their data processing terms: no training on your inputs by default, clear data residency, an enterprise agreement in place. Anything not on the list requires a specific approval, not a blanket ban that gets quietly ignored.
3. Logging. Every AI call that touches customer data or influences a decision gets logged: input, output, model, timestamp, triggering user or system. This is the difference between answering an incident question in twenty minutes and spending a week reconstructing what happened from memory.
4. Review gates. Define what requires human review before it goes live or before an output reaches a customer: anything financial, anything customer-facing at scale, anything that could create legal exposure. Everything else can ship without a gate, which keeps the gate meaningful instead of a rubber stamp everyone routes around.
5. A named owner. One person, by name, accountable for the policy staying current and for being the point of contact when someone isn't sure if something's allowed. Usually this is the CTO or VP Engineering at this company size, because they can actually enforce technical rules like data boundaries and approved models.

Here's the sequence we run when installing this at a client:

1. Day 1 to 2: inventory. List every place AI is currently used across the company, sanctioned or not. This usually surfaces two or three tools nobody in leadership knew employees were using with company data.
2. Day 2 to 3: draft the five rules based on the inventory, in plain language, reviewed by legal only for the data boundary section, not the whole document. Legal review of a five-page document is fast; legal review of a forty-page one gets deprioritized for months.
3. Day 3 to 4: name the owner and get one page of enforcement authority in writing, meaning they can actually block a tool or a data flow without needing a committee vote.
4. Day 4 to 5: circulate and confirm every team lead has read the one page and knows who the owner is. A five-minute all-hands mention plus a pinned Slack message does more than a mandatory training module nobody finishes.
5. Ongoing: quarterly review of the five rules against new vendors, new use cases, and any incidents from the prior quarter.

That's the whole install. No committee, no annual audit cycle, no external certification required to start getting real risk reduction.

The popular advice aimed at this segment in 2026 is "adopt a recognized framework like ISO 42001 or NIST AI RMF early, so you're audit-ready when a customer or regulator asks." That's not wrong as a direction, but it's incomplete as a starting point for a 200-person company, because it front-loads process before the company has the underlying facts a framework assumes exist: an inventory of where AI touches customer data, a list of approved vendors, and functioning logs.

Skipping straight to framework adoption produces companies that can point at a certification badge but can't answer "which of our AI tools processed customer PII last month," because nobody built the logging first. The five-rule version is the prerequisite, not a substitute. Once a mid-market company has data boundaries defined, an approved vendor list, working logs, and a named owner, adopting a formal framework later, when the company has grown into needing one, is a much smaller lift because the underlying facts already exist.

"Review gate" sounds abstract until you write down what triggers one. In our client installs, the gate applies to:

• Any AI output that determines a price, a discount, a refund, or another financial term shown to a customer.
• Any AI-generated content published externally under the company's name without a human reading it first.
• Any AI action that writes to a production system with irreversible or hard-to-reverse effects, like sending an email or closing a support ticket.
• Any use of a new model or vendor not yet on the approved list.

Everything outside those four buckets can ship without a manual gate, provided it's logged. This is the same reversibility-and-blast-radius logic we use for agent autonomy design more broadly, covered in autonomy is a dial, not a switch. Governance and agent architecture are really the same discipline applied at different altitudes.

A written policy is only as good as the systems enforcing it. Data boundaries need to be enforced in code, not just in a document, which is why the auth and permission work in our MCP server builds treats access control as a technical requirement, not a policy suggestion. Logging needs to actually capture every AI call, which ties directly into the audit trail patterns in our agent observability field notes.

The named owner also needs visibility into what's actually running, which is a recurring gap we find in Claude implementation engagements: a policy exists, but nobody can currently produce a real-time list of every AI-touching workflow in production. Fixing that gap is usually a bigger unlock than rewriting the policy itself.

The companies that get burned aren't the ones with imperfect governance. They're the ones with none, who discover during a customer security questionnaire or a data incident that they can't answer basic questions: which vendors process customer data, who approved that vendor, what the retention policy is. Those questions kill enterprise deals and turn small incidents into board-level ones.

A one-page policy with five rules and a named owner answers all three questions in under a minute, which is usually all a customer's security team actually needs to see. If you're not sure your company could answer those questions today, that gap is exactly what we surface in the $1,000 AI Audit, alongside the rest of your production readiness picture.