AI Governance Policy: A One-Page Template Mid-Market Can Defend

Updated for 2026. The one-page template still fits on one page, and it now lives inside a five-layer compliance stack and an agent-infrastructure inventory the board increasingly asks for by name. Read this with the five-layer AI compliance stack, the twelve agent-infrastructure pieces regulated buyers need, and trust architecture for regulated AI. Why long AI policies fail The longest AI policies we read are also the weakest. That is not a paradox; it is a pattern. We have reviewed AI governance documents at more than two dozen mid-market firms in the last year, regulated SaaS shops, multi-site healthcare groups, behavioral health providers, and professional-services firms with regulator-facing data. Documents past twenty pages were, almost without exception, the ones the firm could not defend in the next conversation with an auditor, a board committee, or its own employees. The ones that fit on a single page, when written deliberately to fit, held up. There are two failure modes for a long AI policy, and most documents we see have both. The first is that nobody reads it. An employee opens a 38-page AI Acceptable Use Policy on a Tuesday morning, scrolls through three pages of NIST citations and one section on "ethical principles," gives up, and goes back to pasting a customer call transcript into ChatGPT. That is not a training problem; it is a length problem. The policy was procurement-friendly, it satisfied the customer security questionnaire that asked "do you have a written AI policy", but it was operationally inert. When we ask employees to describe the AI rules at their firm, the median answer at firms with a 40-page policy is "I think there is one but I have not read it." At firms with a one-page policy: "yes, here is what I am allowed to use it for." The difference is not culture; it is whether the document is the right length to be remembered. The second failure mode is that the policy is too vague to act on, even by the people whose job is to enforce it. Long AI policies tend to be long because they hedge. They list seven principles of responsible AI, three categories of risk, four cross-functional committees, and a process diagram with eleven swim lanes. What they almost never include is a direct answer to the questions an employee actually has on a Tuesday morning: "can I use Claude for this client deliverable," "where do I log it," and "who do I ask if I am not sure." The General Counsel cannot enforce a policy whose load-bearing sentence is "AI use must be consistent with the firm's values." The CISO cannot audit against "appropriate human oversight." Vagueness does not protect the firm from a finding; it produces the finding. The 40-page policy is a procurement artifact. It exists because somebody on the buying side asked for one and somebody on the selling side wrote a long document to satisfy the ask. It is not, in any meaningful sense, governance. Real governance is the set of rules the firm can actually apply, in a specific situation, with a specific employee, on a specific Tuesday. That set of rules fits on one page when it is written honestly. What is on pages 2 through 40 is almost always one of three things: hedging that masks indecision, restatements of NIST or ISO that the firm has not internalized, or vendor-marketing language that crept in from a template. None of that survives questioning. The one-page version we use with clients is the result of compressing every long policy we have read down to the things that have to be in writing for the firm to be defensible in front of a regulator, an acquirer, an auditor, or its own counsel. There are five. The five things that have to be in writing Below are the five clauses that have to appear, in some form, in any AI governance policy a mid-market firm intends to defend. Each is one sentence in our template. We give the sentence here, plus what "in writing" actually means in practice, because every one of the five is the place where firms hand-wave themselves into a finding. 1. A named owner of AI risk for the firm. The policy must name a single role (not a committee). "In writing" means the role is named in the document, the person filling the role is named in a maintained register, and that person has the authority to say no. A policy that says "the AI Governance Committee will review use cases" without naming a deciding officer is not a policy; it is a meeting schedule. We expand on this in the next section because the named-owner question is where most mid-market firms get the design wrong. 2. A scoped list of approved AI use cases, separated into production and experiment. The policy must enumerate which AI tools are approved, for which categories of work, with which categories of data. "In writing" means a list, not a principle. "Employees may use approved AI tools for appropriate work tasks" gets you a finding. "Employees may use Claude (enterprise tier, our tenant) and Microsoft Copilot (M365 license, our tenant) for the use cases listed in Appendix A; all other tools require approval from the AI risk owner before use" is in writing. 3. A data classification rule that maps to the use case list. Public data, internal data, confidential data, and regulated data (PHI, PII under state privacy law, attorney-client privileged) are each addressed by name. "Employees should exercise judgment about what data they share with AI tools" is hand-waving and will be cited. "Confidential and regulated data may only be sent to AI tools listed in Appendix A as approved for that classification" is the rule a CISO can enforce. 4. A vendor BAA / DPA stance that governs procurement. The policy must state, in two sentences, what coverage every AI vendor must have before the firm uses them with anything beyond public data. "In writing" means the policy commits the firm to a procurement screen, not a "best efforts" review. We cover the exact two sentences in section 5. 5. An audit trail clause that names what gets logged, where, and for how long. The policy must specify what the firm logs, with what retention, with what access controls, and what immutability properties. "In writing" means specific durations and named systems, not "appropriate logs are maintained." We cover this clause in section 6 because it is the most-cited gap in the audits we read. Five clauses, one sentence each, plus the appendices the clauses reference. The full document, including the use case appendix and the data classification table, fits on one page set in 10-point body text. Everything else in a typical 40-page AI policy is either commentary on these five clauses, restatement of an external framework, or content that belongs in a separate document (procurement runbook, incident response plan, training materials). Those documents matter. They are not the policy. The policy is the five clauses; the rest is how the firm operationalizes them. Conflating the two is what produces the document the next auditor cites. The next four sections walk through the clauses where mid-market firms most often write themselves into a finding: ownership, scoped use cases, vendor posture, and audit trail. The data classification clause is mostly mechanical once the use case list is right, so we fold it into the use case section. Ownership: who actually owns AI risk in a 200-person firm We get asked, more often than any other governance question, "who should own AI in our firm." The answer most CIOs expect, and most outside counsel reflexively gives, is "the CISO." That answer is wrong in most mid-market organizations, and getting it wrong is expensive. Here is why the CISO-owns-AI default fails. The CISO's job is information security, which in a regulated mid-market firm is already a full-time-and-then-some role: vulnerability management, incident response, third-party risk, identity and access, audit prep, cyber insurance, sometimes physical security. Adding AI risk does two things, both bad. First, it overloads a function that is already understaffed in most firms below a thousand employees. Second, and more importantly, it scopes AI as a security problem when most of the AI decisions in a mid-market firm are not security decisions. They are use case decisions, data classification decisions, contract decisions, and workflow decisions. Pushing them to the CISO concentrates them in a function that does not own the underlying business processes, and the CISO's answer is then perceived as a security veto rather than as a business judgment, which produces the dynamic where the rest of the firm routes around the CISO. The named-owner pattern that works is to put AI risk ownership where the cross-functional authority already lives, with the CISO as a mandatory consultee on security-relevant decisions and the GC as a mandatory consultee on contract and regulatory decisions. The exact role varies with the firm. In a firm with a strong operating COO, AI risk ownership often sits with the COO because the COO already chairs cross-functional decisions about technology, vendors, and process change. In a firm with a Chief Compliance Officer (common in healthcare, behavioral health, and any firm with a regulated-program license), the CCO is usually right because the role already integrates regulatory posture, vendor diligence, and program audit. In a firm without either, most professional-services and SaaS firms below 200 employees, the GC is right, because the GC already carries the cross-functional posture for regulatory exposure and vendor contracts. The wrong owner is the CIO. The CIO usually owns the systems on which AI runs, but the CIO is, by definition, an interested party, the executive sponsor for most AI procurement and most internal AI builds, which means the CIO sits on the wrong side of the table for governance decisions about what should be approved. We have seen firms make the CIO the AI governance owner; in every case, the structure produced the predictable conflict, which then produced the predictable finding when the auditor asked who was second-guessing the CIO's procurement choices. The named-owner clause in our template reads something like: "The Chief Compliance Officer (or, in firms without a CCO, the General Counsel) owns AI risk decisions for the firm, including approval of use cases, vendors, and data classification mappings. The CISO is a mandatory consultee on security-relevant decisions; the General Counsel is a mandatory consultee on contract and regulatory decisions; the CIO is the executive sponsor and implementer." That sentence does three things. It names a single accountable role. It names the consultees so the owner cannot make decisions in isolation. And it separates ownership from sponsorship, which is the structural fix that prevents the CIO conflict. In practice: when a department wants to introduce a new AI tool, the ask goes to the named owner. The owner pings the CISO if the tool touches confidential or regulated data; the GC if the tool involves a contract beyond a click-through. The owner decides within a defined SLA, one week is what we recommend, and the decision goes on a register the board can see at quarterly review. That is governance, and it fits on one page. Scoped use cases: production vs experiment The single most-defensible thing a mid-market firm can do in its AI policy is separate two buckets of AI use cases, production and experiment, and apply different rules to each. Almost every policy we read collapses the two, which is why the policy ends up either too restrictive (and gets ignored on the experiment side) or too permissive (and produces findings on the production side). Production AI use cases are AI tools and workflows that touch customer data, regulated data, or any external-facing artifact (client deliverable, regulatory filing, product output). They require: explicit approval from the AI risk owner, named in the use case appendix; an executed contract with the vendor, including BAA / DPA where applicable; a documented data classification mapping; full audit trail per the clause in section 6; and an annual review. Production AI is a procurement artifact and a control-environment artifact. It belongs in the SOC 2 scope, the HIPAA Security Rule risk analysis, the cyber insurance application, and the M&A diligence pack. The list is short on purpose; we usually see five to fifteen production use cases at a 200-person mid-market firm. Experiment AI use cases are everything else: an analyst using Claude to brainstorm a memo outline, a manager drafting an internal email with Copilot, an engineer using a coding assistant for non-customer code, a marketer drafting a blog post for review. They require: the data classification rule (only public and internal data may go into approved-for-experiment tools), the named tools list (no rogue tools), and a lightweight self-attestation when the employee uses the tool for the first time. Experiment use cases do not require named-owner approval per use; they require approval of the tool, once, and then employees can use the approved tools for any experiment-class work consistent with the data rule. The promotion gate is the rule that turns an experiment into a production use case: "Any AI use case that begins to touch customer data, regulated data, or external-facing deliverables must be promoted to a production use case before such use; the promotion request goes to the AI risk owner and is decided within five business days." That sentence catches the most-common mid-market failure pattern, the workflow that started as a "let me just try this" experiment and quietly became a customer-facing production process without anybody noticing it had crossed a line. The audit trail expectation differs sharply between buckets. For experiment use cases, the audit trail is the tool's own log (Claude's enterprise console, Copilot's M365 audit log) plus the firm's identity log. That is enough, the data classification rule limits what can be in those logs to public and internal data, so the operational risk is bounded. For production use cases, the audit trail must be at the prompt level, retained per the firm's regulated-data retention schedule (typically six years for HIPAA, longer where state law applies), with access controls and immutability properties enumerated in the audit clause. Production AI without prompt-level audit is the most common finding we write up on the Diagnostic. Two buckets, two rules, one promotion gate. That is what lets the one-page policy be both restrictive (where the firm has real exposure) and permissive (where the firm wants broad employee adoption) at the same time. The vendor BAA / DPA stance, in two sentences The vendor posture clause is where most policies hide the most hand-waving behind the most words. We can replace the seven paragraphs we typically read with two sentences, and the two sentences are more enforceable. Sentence one: "Every AI vendor that processes confidential or regulated firm data must have a current executed BAA (where the data includes PHI), a current executed DPA (where the data includes personal data subject to state privacy law), and SOC 2 Type II attestation; vendors without all three are prohibited for confidential and regulated workloads regardless of feature fit." Sentence two: "Procurement screens every prospective AI vendor against the five-question screen in Appendix B before any data beyond public data is shared; the screen is filled in by the vendor, reviewed by the AI risk owner, and retained with the contract." That is the entire vendor stance. The five-question screen carries the operational weight, and the questions are the same every time: 1. Does the vendor's contract (BAA / DPA / MSA) cover the specific service lines and data types we will send? (Asking is necessary; reading the contract is the actual control.) 2. Does the vendor exclude our inputs from model training, by default and contractually? (For OpenAI direct API, this requires Zero Data Retention; for most other major vendors it is the default but must be confirmed in writing.) 3. What is the data residency commitment, enumerated by region in the contract addendum? (US-only is the default we recommend; cross-border processing introduces obligations most mid-market firms are not staffed to manage.) 4. Can we, the customer, retrieve prompt-level logs on demand for the retention period required by our regulated-data schedule? 5. What is the breach-notification SLA, and does it flow down to sub-processors (orchestration, vector DB, observability)? Five questions, one form, one retained record. The screen is the operational control the two-sentence policy clause references; it is also the control procurement can run without escalating every vendor to the AI risk owner, only the failures escalate. That is what makes the clause work at scale. Two sentences plus Appendix B replace the chapter of typical AI policy text that begins "the firm shall take reasonable steps to ensure that AI vendors maintain appropriate safeguards" and goes on for eight pages without becoming enforceable. The BAA chain audit and the five-question screen are the actual controls; the policy's job is to commit the firm to running them. The audit trail clause that survives scrutiny The audit trail clause is the most consistently weak clause in the policies we read, and the place where regulators find their easiest finding. The Security Rule under HIPAA requires audit trails of access to PHI; state privacy laws are increasingly explicit about access logs for personal data; SOC 2 Common Criteria require logical access logs that are not trivially deletable. None of these requirements is unfamiliar in a traditional system context. All of them get hand-waved when AI workflows are involved, because the engineering teams that build AI workflows often do not come from the same compliance lineage as the teams that built the EHR or the customer record system. The result is an audit log that captures the API call but not the prompt, or the prompt but not the user identity, or both but in a system the team can edit after the fact. The audit trail clause has to address four things, in writing, with specificity: Prompt-level retention. For production AI use cases, the firm logs the prompt content, the completion content, the model and version, the user identity (the actual end-user, not a service account), and the timestamp. The retention duration is the longer of the firm's regulated-data retention schedule and the contractual obligation to a customer or partner. For HIPAA contexts, six years. For most state privacy contexts, the longer of the relevant statute of limitations and the contractual term, which usually lands between five and seven years. Access controls on the log itself. Name who can read the log (typically the AI risk owner, the CISO, internal audit, and external auditors under engagement), require that access is itself logged (meta-logging), and state the protocol for read access during an investigation. "The log is in S3 and we have IAM" is not the clause; the clause names roles, meta-logging, and a quarterly access review. Retention duration. State a number, not a phrase. "For the period required by applicable law" is not a retention duration; it is an evasion. The number is what the system must enforce, and the system cannot enforce a phrase. State both the floor (regulatory minimum) and the cap (the longest hold absent a litigation hold); the cap matters because indefinite retention is its own liability under state privacy regimes. Immutability. The production AI audit log is configured with object-lock or equivalent immutability for the retention period, the immutability is enforced by the storage layer rather than by policy, and breaks in immutability (legal holds, retention-cap expirations) are themselves logged. This is the property that distinguishes a defensible log from a "we have logs" claim. An auditor's first move is to ask whether the operations team can edit or delete the log; if the answer is yes, the log fails the test. The clause in our template is one paragraph. It names the four properties, points at Appendix C for the system-level implementation (storage system, retention configuration, IAM policy, review cadence), and leaves implementation details where the operations team can update them as infrastructure evolves. The policy is the four properties; the appendix is the implementation. One more practical observation. This is also the clause that the firm's outside counsel should review most carefully, because it drives discovery posture in the event of litigation. An audit trail that retains prompt content for ten years is also a discovery surface for ten years. The right move is to engage counsel on the retention duration up front, at the time the policy is written, rather than after a complaint surfaces. Where the Diagnostic fits, and three actions a CIO can take this month When a mid-market firm engages us on the Diagnostic for Adopt-AI-Safely, the AI governance policy review is one of the workstreams in the 30-day audit. We pull the firm's current policy (or the absence of one), score it against the five-clause structure, run the firm's actual AI use against the policy as written, and produce a written report the CIO can hand to the board, the auditor, or the next vendor. The Diagnostic is a fixed-scope, fixed-price written assessment, two to three weeks, ten thousand dollars, and the policy piece produces, among other deliverables, a redlined one-page draft ready for the GC's final pass and the board's adoption. The Diagnostic is what this guide is designed to make optional. If the firm has the bandwidth to walk the five clauses internally, run the vendor screen against current AI vendors, and write the audit trail appendix from the four properties above, the policy can be drafted without us; we wrote the method to be reusable. We do think the Diagnostic is the highest-leverage way to produce the policy, the use case appendix, and the BAA chain register simultaneously. For firms without a spare three weeks of internal partner-and-CISO time, it is the cheapest path to a defensible posture. Three actions any CIO can take this month, regardless of whether they engage us: 1. Inventory every AI tool in use, approved or otherwise. Pull the procurement list, the M365 admin list, the SSO log, and a department-by-department survey. Compare them. The gap between the procurement list and the SSO log is the shadow-IT inventory; the gap between the SSO log and the survey is the personal-account inventory (employees using personal Claude or personal ChatGPT for work). Most firms cannot do this in an afternoon, that is the first finding. 2. Name the AI risk owner this quarter. Not the AI Governance Committee. Not "we are working on it." A single role, named in writing, with a memo from the CEO confirming the authority. Without a named owner, none of the rest of the policy work has anywhere to land. 3. Draft the one-page policy from the five clauses above and run it past counsel before it runs past the board. A draft that has gone through outside counsel for a focused two-hour review is harder to argue with than a draft that has not. If the firm's outside counsel does not have meaningful AI-policy experience, that is itself a finding, and a reason to engage counsel that does, before the policy is adopted rather than after the first complaint. Three actions, ninety days, no engagement required. If the inventory or the naming decision or the policy draft surfaces gaps the firm cannot close internally, or if the policy is large enough that getting it wrong is expensive (regulated-data exposure, customer-facing AI, M&A in flight), that is where the Diagnostic comes in. Two to three weeks, ten thousand dollars, written report and a redlined policy draft you keep regardless. The AI Governance One-Page Template download paired with this guide gives you the five clauses, the use case appendix table, the data classification mapping, the five-question vendor screen, and the audit trail appendix, formatted to fit on a single page when populated with the firm's specifics. Use it as the starting draft for the GC's review. Use it on the next AI procurement. Update it when the vendor landscape moves, and we will keep doing the same on our side.