AI Governance Policy for In-House Legal Teams: A 2026 Template

A general counsel I spoke with this spring told me her board had asked, on a Monday, for the company's "AI policy." She had a Slack channel, a procurement spreadsheet with three Copilot seats on it, and a memo from IT that started with the words "we are still evaluating." By Friday she had to present a policy to the audit committee. She did what most law departments did in 2024, which is grab the nearest open-source template, find-and-replace the company name, and hope nobody asked a follow-up.

The GCs who got ahead of this in 2025 did something different. They treated AI governance the way their predecessors treated SOX in 2003: not as a policy document, but as an operating discipline with quarterly board reporting, named owners, and a budget line. The 2026 ask from the audit committee is not "do we have an AI policy." It is "show me last quarter's AI incident log, your approved tools list with security review dates, and the training completion rate by department." If you cannot pull those three artifacts in an hour, the policy is not yet operating as governance.

This post gives a GC or legal ops lead three artifacts in one read: a defensible policy you can hand the audit committee on Friday, the regulatory map that justifies each clause line by line, and a six-month rollout plan so the policy actually operates instead of sitting in SharePoint.

What is an AI governance policy? It is a written rulebook that says which AI tools your people may use, what they may never feed into those tools, who gets told that AI was used, and what happens when an AI output is wrong. A usable in-house version is short (around 1,200 words), maps to the NIST AI Risk Management Framework, and is paired with a live approved-tools list. The template lower down is the legal AI use policy you can copy and adapt. It doubles as an AI acceptable use policy a law firm can run too; the eight components are the same.

TL;DR

Part of our in-house counsel guide series.

• Most US-based in-house law departments with regulated customers, EU exposure, or operations in Illinois, NYC, or Colorado need a written AI governance policy in 2026. The pressure is converging: SEC disclosure expectations, NIST AI RMF as the de facto standard, the EU AI Act phasing in through August 2026, Illinois HB 3773, NYC Local Law 144, and a volatile state-law layer (Colorado's hard-law AI Act was repealed before it took effect and a White House push to preempt state AI laws is live).
• Anchor the policy to the NIST AI RMF, not to any single statute's checklist. Colorado proved a state duty can be written, delayed, and repealed inside eighteen months. A framework-based policy survives that churn; a statute-checklist policy has to be re-papered every legislative session.
• Eight components are non-negotiable: approved tools list, prohibited uses, disclosure obligations, sub-processor due diligence, training, audit logs, incident response, and vendor risk management with an AI addendum.
• The template at the end of this post is roughly 1,200 words and is meant to be adapted, not adopted. The hard work is the inventory and the enforcement, not the prose.
• Over-restriction kills adoption and pushes lawyers to personal accounts. Under-restriction loses privilege the first time someone pastes a board deck into a consumer chatbot. The right posture sits in the middle and is enforced by tooling, not honor system.

Why 2026 is the year the policy stopped being optional

The 2024 conventional wisdom on AI governance was "wait and see." Boards asked, and most GCs answered with a one-pager that said the team was monitoring developments. That answer is no longer survivable. Seven things changed.

SEC disclosure expectations. The SEC has not issued an AI-specific rule, but it has been consistently signaling that AI-related risks belong in risk factors and MD&A where material, and that material AI incidents may need to be reported under Item 1.05 of Form 8-K (the cybersecurity disclosure rule adopted in July 2023). Erik Gerding, then Director of the SEC's Division of Corporation Finance, gave the December 2023 speech on AI-washing that put the bar in plain English. If you tell investors AI is core to the business, expect the staff to ask how you govern it. A written policy is the first thing they want to see.

NIST AI Risk Management Framework 1.0. Published January 2023 as NIST AI 100-1, the framework is voluntary, and it has nevertheless become the reference standard the way NIST 800-53 became the cybersecurity reference. Federal vendors are being asked to map to it under OMB M-24-10. State agencies are citing it. If you write a policy that does not at minimum echo the AI RMF's four functions (Govern, Map, Measure, Manage), your auditor will notice and your enterprise customers' security questionnaires will notice harder.

EU AI Act. Regulation (EU) 2024/1689 entered into force August 1, 2024. The prohibited-practices provisions in Article 5 took effect February 2, 2025. The general-purpose AI model obligations in Chapter V kicked in August 2, 2025. The big one, the high-risk-system obligations in Chapter III, becomes applicable August 2, 2026. The Act applies extraterritorially under Article 2 to providers and deployers outside the EU when the output is used in the EU. If your company has a single EU customer or a single EU employee whose performance review involves an AI tool, the Act reaches you. A US-only governance policy is a serious gap for any multinational, and the conformity assessment timelines for Annex III systems give you less runway than the August 2026 date suggests.

Colorado, and why the churn is the real lesson. Colorado SB 24-205, signed May 17, 2024, was going to be the first comprehensive US state AI law: a duty of reasonable care on deployers of "high-risk artificial intelligence systems," a mandatory risk management program, annual impact assessments, and the NIST AI RMF named as a safe harbor. It never took effect. A special-session bill, SB 25B-004, signed by Governor Polis on August 28, 2025, pushed the February 1, 2026 date to June 30, 2026. Then SB 26-189, signed May 14, 2026 and effective January 1, 2027, repealed and replaced the whole statute. The new law drops the duty of care, the risk management program, and the impact assessments. What survives is lighter: pre-use notice before an automated system materially influences a consequential decision, an adverse-outcome explanation to the consumer within 30 days, meaningful human review, and developer documentation. Enforcement sits with the Colorado Attorney General, there is no private right of action, and covered entities keep compliance records for three years. The lesson is not that Colorado stopped mattering. It is that a state duty was written, delayed, and gutted inside eighteen months. A policy pinned to one statute's checklist ages out in a single legislative session. Anchor to the NIST AI RMF, which survived the churn, and let the statute-specific disclosures hang off it.

Illinois HB 3773. Signed August 9, 2024, amending the Illinois Human Rights Act effective January 1, 2026. Employers using AI in recruitment, hiring, promotion, discharge, or other employment decisions must notify employees and may not use AI that has the effect of discriminating against protected classes. The statute pulls HR squarely into the law department's AI governance scope.

NYC Local Law 144 of 2021 (effective enforcement July 5, 2023). Requires a bias audit of any automated employment decision tool used to screen candidates or employees in NYC, plus notice to candidates. The DCWP rules are detailed and the enforcement is real. Anyone hiring in NYC needs this in the policy.

The White House National Policy Framework for AI. Released March 20, 2026, the framework recommends targeted federal preemption of state AI laws that impose "undue burdens," while preserving state police powers and each state's control over its own AI use. It is a set of legislative recommendations, not a rule, and Congress has not enacted it. What it tells a GC is that the state-law patchwork you are drafting against is itself unstable: Colorado retreated, a federal preemption push is now on the table, and other state bills keep moving. You cannot re-paper a governance program every time a legislature blinks. That instability is the strongest argument for a framework-based policy over a statute-checklist policy.

That is federal disclosure pressure, a de facto standard, an extraterritorial EU regime, two live employment statutes, and a state-law layer that is still being rewritten in 2026. The "wait and see" stance burns out under any one of them. For most multi-state and multinational employers, the policy stopped being optional somewhere in late 2025, and the churn since has only raised the cost of not having one.

Two industry signals make the timing concrete. First, the enterprise AI contracting market has shifted hard on indemnity. Microsoft's Copilot Copyright Commitment (September 2023) was the opening move; by mid-2025 the standard enterprise AI vendor contract carries some form of IP-output indemnity, though the carve-outs are where the work happens. A law department that signs a Copilot or Claude Enterprise deal in 2026 without negotiating the indemnity exclusion list is leaving the protection on the table. Second, the cyber-insurance market started asking AI-specific questions on the 2025 renewal cycle. Brokers I have talked to say AI governance attestations are now a standard underwriting input, and a missing or stale policy is showing up as a premium driver. The "we are still evaluating" memo costs real money now.

The 8 components of a defensible in-house AI policy

A 2026 in-house AI policy needs these eight components. Any policy missing one is a draft and will not hold up to an audit-committee review.

Before the eight clauses, give people a one-glance rule for what is allowed. A three-tier classification (the same red/yellow/green split most legal AI governance frameworks now use) does more day-to-day work than any paragraph in the policy:

The eight components below turn that tier rule into something an auditor can test.

1. Approved AI tools list. A written list of the specific products the company permits, with a one-line security-review status for each. "Microsoft 365 Copilot, enterprise tenant, DPA executed 2026-03." Not "approved generative AI tools." The list is the policy's teeth. Anything not on the list is prohibited by default. A request process to add a tool sits next to the list. The legal ops manager owns the list; the GC signs off on additions. The list lives on the intranet next to the approved-software register so IT and legal are reading the same document, not two drifting versions.

2. Prohibited uses. A short, specific list of inputs that may never be pasted into any AI tool, even an approved one, without elevated controls. The non-negotiable five are: client or customer personally identifiable information; employee PII and personnel-file content; M&A deal documents (letters of intent, term sheets, due diligence working papers); board minutes and board-pack materials; and any document subject to a litigation hold or under attorney-client privilege in draft form. The list should also call out anything containing trade secret formulae, source code marked confidential, and unannounced financial results.

3. Disclosure requirements. Who must be told the company is using AI, and when. Three audiences: customers and clients (especially for B2B contracts where the customer reasonably expects human review); employees (HR uses, performance management, monitoring); and the board (annual report from the GC on AI deployment, incidents, and policy compliance). Map each disclosure obligation to the statute that drives it: Colorado consumer pre-use notice under SB 26-189 (effective January 1, 2027), Illinois employee notice under HB 3773, NYC candidate notice under Local Law 144, EU AI Act transparency obligations under Article 50.

4. Sub-processor due diligence. Every approved AI tool runs on a stack of sub-processors. The policy needs a process for evaluating that stack: who provides the model, where inference runs, how long inputs are retained, whether the vendor uses your inputs for training. The DPA (data processing agreement) is the artifact, and it needs an AI-specific addendum covering training opt-out, output ownership, indemnity for IP infringement in outputs, and audit rights tied to the AI RMF. The negotiation friction is real: hyperscalers will give you the indemnity but push back hard on the model-disclosure clause, while smaller AI vendors will give you the disclosure but try to carve out indemnity for "user-directed" outputs. The carve-out is the trap. A "user-directed" exception swallows most generative-AI use cases the moment a lawyer types a prompt.

5. Training requirements. Annual mandatory training for all employees touching an AI tool, plus role-based deep dives for legal, HR, engineering, and procurement. The training must cover prohibited uses, escalation paths, and the company's posture on accuracy verification. Completion is tracked. Non-completion means access is revoked. ABA Formal Opinion 512 (July 2024) on a lawyer's duty of competence with generative AI is the reference point for the legal-team module.

6. Audit logs and retention. Every AI interaction in an enterprise tool is logged at the tenant level. Retention period stated in writing, defaulting to seven years to align with most document-retention schedules. The legal hold process must include AI audit logs. Spoliation arguments around AI prompts and outputs are already showing up in commercial litigation; the policy needs to anticipate them. The operational pattern that works: legal ops pulls a quarterly sample of prompts from the Copilot or Claude Enterprise admin console, cross-checks against the prohibited-uses list, and reports anonymized findings in the GC's quarterly compliance memo. The sample is small (50 to 100 interactions) but its existence does most of the deterrence work.

7. Incident response for AI errors. Treat material AI errors the same way you treat data breaches: a runbook, a named owner, a clock. A "material AI error" is defined by the policy and at minimum includes (a) an output relied on in a regulatory filing that turns out to be wrong, (b) an output disclosed to a customer that turns out to be wrong, (c) discovery of training-data contamination by privileged or PII inputs, (d) any AI-related issue that triggers an Item 1.05 analysis. The runbook walks from detection to triage to disclosure to remediation, with the GC as final decision-maker on external notification.

8. Vendor risk management with an AI addendum. The procurement intake form gets an "uses AI?" question. A "yes" routes the contract through a vendor risk review that includes the DPA plus the AI addendum from component 4. No AI vendor signs without it. Existing vendor relationships that turn on AI mid-contract trigger a re-paper.

Those are the eight. Before the prose, one structural point: a policy with eight components and no named owners is a wish list. Every component needs one accountable signer, one team that does the work, and a short consulted list. The GC signs off on all eight, but the GC does not maintain the tools list or negotiate the addendum.

The next section is the prose you can lift.

Try Vaquill AI on your matterBook a demo

The template

Adapt this. Do not adopt it. The names, jurisdictions, and tool list are placeholders. The structure tracks the eight components above. The reason to publish a template at all is that most law departments are not stuck on the prose; they are stuck on the political question of who owns each component. Reading a working draft makes the ownership conversation concrete in a way an abstract checklist does not.

[Company] Artificial Intelligence Acceptable Use and Governance Policy

Effective Date: [date]. Owner: General Counsel. Review cadence: annually, or upon material change in law or company AI usage.

1. Purpose and Scope. This policy governs the use of artificial intelligence ("AI") tools by [Company] personnel in connection with company business. It applies to all employees, contractors, and agents. "AI tools" includes generative AI assistants, large-language-model products, machine-learning models used in decision support, and any automated system that produces output relied upon for company decisions. The policy is mapped to the NIST AI Risk Management Framework (AI 100-1, January 2023) and is designed to satisfy obligations under the EU AI Act (Regulation (EU) 2024/1689), Colorado's automated-decision disclosure law (SB 26-189, effective January 1, 2027), Illinois HB 3773, and NYC Local Law 144 of 2021, where applicable.

2. Approved Tools. Personnel may use only AI tools on the Approved AI Tools List maintained by Legal Operations. The current list, with security-review status and approved use cases, is published at [intranet link]. Use of any AI tool not on the list, including personal accounts of otherwise-approved tools, is prohibited. Requests to add a tool follow the AI Intake Process at [intranet link] and require GC sign-off after security and privacy review.

3. Prohibited Uses. Even with an approved tool, personnel shall not input, paste, or upload the following without prior written approval from the GC: (a) personally identifiable information of customers, prospects, or third parties; (b) employee PII or content from personnel files; (c) M&A deal documents, including letters of intent, term sheets, due diligence working papers, and draft transaction agreements; (d) board minutes, board materials, and pre-release financial information; (e) documents subject to a litigation hold or attorney-client privileged drafts; (f) trade secrets, source code marked confidential, or unannounced product information. Personnel uncertain whether a given input is prohibited shall consult Legal before submission.

4. Disclosure Obligations. [Company] will disclose AI usage to (a) customers in commercial agreements where AI materially affects the service delivered; (b) consumers in Colorado before an automated system materially influences a consequential decision, in compliance with Colorado SB 26-189; (c) employees when AI is used in recruitment, hiring, promotion, discharge, or other employment decisions, in compliance with the Illinois Human Rights Act as amended by HB 3773; (d) candidates and employees in NYC subject to automated employment decision tools, in compliance with NYC Local Law 144 and DCWP rules; (e) EU-based individuals where required under Article 50 of the EU AI Act; and (f) the Board annually through the GC's AI governance report.

5. Sub-Processor Due Diligence. No AI vendor will be onboarded without execution of [Company]'s standard Data Processing Addendum and AI Addendum. The AI Addendum requires: (a) confirmation that [Company] inputs will not be used to train the vendor's models without express written consent; (b) defined input and output retention periods; (c) indemnity for third-party intellectual-property claims arising from outputs; (d) audit rights tied to the vendor's AI RMF mapping or equivalent; (e) sub-processor disclosure and change notification.

6. Training. All personnel with access to an approved AI tool must complete annual AI Acceptable Use training. Personnel in Legal, HR, Engineering, Finance, and Procurement must complete role-based training in addition. Training tracks include guidance derived from ABA Formal Opinion 512 (2024) for the legal team and disclosure-and-human-review training for personnel responsible for automated decisions in regulated jurisdictions. Non-completion within 30 days of assignment results in revocation of AI tool access.

7. Audit Logs and Retention. All approved AI tools must support tenant-level logging of prompts, outputs, and user identifiers. Logs are retained for seven (7) years and are subject to the company's legal hold process. Personnel shall not use AI features that bypass tenant logging, including incognito or guest sessions of approved tools.

8. Incident Response. A material AI incident triggers the AI Incident Response Runbook, owned by the GC with delegated execution to the Privacy Officer. Material incidents include: (a) reliance on an AI output in a regulatory filing or public disclosure that proves inaccurate; (b) disclosure of an AI output to a customer that proves inaccurate and is material; (c) inadvertent submission of prohibited inputs (Section 3) to an AI tool; (d) any AI-related event requiring evaluation under Item 1.05 of Form 8-K. The runbook governs detection, containment, internal escalation, customer or regulatory notification, and remediation.

9. Vendor Risk Management. Procurement intake includes a mandatory "Does this product use AI to deliver any function?" field. A "yes" routes the contract to Vendor Risk Review including DPA and AI Addendum execution. Mid-contract additions of AI features by an existing vendor trigger re-paper.

10. Enforcement. Violations of this policy may result in discipline up to and including termination, in accordance with [Company]'s Code of Conduct. Repeat violations are reported to the Audit Committee in the GC's quarterly compliance report.

That is the body of the policy. Real implementations add a definitions section, a cross-reference appendix, and signature blocks. Keep the spine.

Six-month rollout

A policy in SharePoint is not governance. The rollout is the governance. The plan below is what works for a mid-size company (200 to 2,000 employees) with a law department of three to ten.

Month 1: inventory and risk assessment. Stop debating the policy. Find the AI. Survey every department. Pull the SaaS spend report. Search the network for known AI domains. Most law departments find three to five times the AI tools they thought were in use. Categorize each by data class touched (public, internal, confidential, regulated) and produce a risk register that maps to the AI RMF "Map" function.

Month 2-3: policy draft and DPA-plus-addendum. Draft using the template above, with the actual approved tools list filled in. Run the draft through Privacy, IT Security, HR, and Procurement in parallel. The AI Addendum is the hardest piece; budget two weeks of vendor negotiation per major incumbent. Hyperscalers (Microsoft, Google, AWS) have standard terms now; smaller vendors negotiate. Board approval of the policy itself, not just the eight-component summary.

Month 4: training launch. Roll out the all-hands module first (45 minutes, async). Then role-based modules in waves: Legal first because they need to enforce, then HR, then Engineering, then everyone else. Track completion in the LMS. Tie compensation review to completion.

Month 5: enforcement. Turn off shadow IT. Disable AI features in tools not on the approved list, in collaboration with IT. The first quarter of enforcement always produces complaints; route them through the AI Intake Process so a "no" becomes a documented "no" rather than a culture-poisoning rejection. The pattern that works in practice: legal ops runs a weekly intake queue, IT bulk-enforces DLP rules against the consumer AI domain list (chat.openai.com, claude.ai, gemini.google.com, perplexity.ai, and the long tail), and HR flags new-hire onboarding to include the AI policy attestation alongside the standard Code of Conduct sign-off. One mid-market SaaS GC I work with caught a finance analyst pasting a draft 10-Q section into a personal Claude account on day three of DLP rollout; the policy had been live for four months and the analyst had genuinely never read it. Enforcement surfaces what training missed. Publish the first incident report internally even if there were no formal incidents; the cadence matters more than the content.

Month 6: audit. Independent review by an outside firm or by Internal Audit. Map findings back to the eight components and the AI RMF functions. Update the policy. Report to the Audit Committee. Cycle restarts.

The cadence problem nobody talks about

The deeper reason enterprise AI governance fails has nothing to do with the policy text. It is a cadence mismatch. Law departments review policies annually. Procurement reviews vendors quarterly. The AI vendor landscape ships material new features every two to three weeks. A policy approved in Q1 is referencing a Copilot feature set that no longer exists by Q3, and the audit committee never sees the gap.

The fix is structural, not editorial. Pick a fast-moving artifact (the approved tools list with security-review dates) and put it on a 30-day review cycle. Pick a slow-moving artifact (the policy text itself) and leave it on annual. The board sees the slow document; legal ops maintains the fast one. The intake form is the bridge: every new tool request triggers a delta review against the current approved list, and the request is the unit of governance instead of the policy document. This is the practice that distinguishes the law departments where governance functions from the ones where it lives on paper.

Two pitfalls that sink real deployments

Over-restriction kills adoption and pushes work into shadow accounts. The GC who locks down everything to ChatGPT Enterprise and prohibits Copilot, Claude, Gemini, and every coding assistant gets a workforce that uses their personal Gmail accounts to log into the consumer versions. Now the company has zero logs, zero audit trail, and zero defensible position if an incident happens. The right posture allows enough tools that the work can actually get done inside the perimeter. Three to five approved tools across the major workflows (general assistant, coding assistant, research assistant, design assistant) is a realistic floor for most companies.

Under-restriction loses privilege the first time someone pastes a board deck into a consumer chatbot. This one is harder to feel until it happens. A senior lawyer drafts a memo, pastes the relevant section into a free consumer chatbot for a "polish pass," and the input flows to the vendor's training data per the consumer terms of service. The privilege analysis after that is unpleasant. The discoverability analysis is worse. Section 3 of the template, the prohibited-uses list, is the technical fix; tenant-level enterprise tooling is the structural fix. Both have to be in place.

The policy is the easy part. The inventory, the addendum negotiation, the training cadence, and the enforcement against a workforce that genuinely needs AI to do their jobs are the hard parts. The document is what lets you defend everything else when the regulator or board asks.

A point that gets missed in most governance writeups: the eight components above do not actually protect you from the most likely failure mode, which is a quietly wrong AI output relied upon in a regulatory filing or a customer communication. That risk is governed by verification posture, not policy text. The policy says "verify before relying"; the question is whether the law department has the workflow tooling to actually verify at the speed the work demands. Tooling that grounds outputs in primary statute text, surfaces source citations inline, and exposes audit logs for every research step is the operational complement to the written policy.

If you want a one-hour test of your own program, take the eight-component checklist above, score your current policy against it, then pull last quarter's AI incident log and approved-tools register. The gaps will be obvious. Vaquill AI gives a law department grounded research and inline citation verification so the "verify before relying" clause is something the workflow enforces, not just something the policy hopes for. See legal research.

FAQ

What is an AI governance policy? It is a written document that controls how a company uses AI: which tools are approved, what data may never go into them, who must be told AI was used, and how the company responds when an output is wrong. For an in-house legal team it maps to the NIST AI Risk Management Framework and is paired with a live approved-tools list. The version most GCs ship is around 1,200 words plus appendices.

What should an AI governance policy include? Eight components: an approved AI tools list, prohibited uses, disclosure obligations, sub-processor due diligence, training, audit logs and retention, incident response, and vendor risk management with an AI addendum. A policy missing any one will not survive an audit-committee review. The template in this post is structured around all eight.

What is the difference between an AI governance policy and an AI acceptable use policy? They overlap heavily. An AI acceptable use policy focuses on the user-facing rules: what an employee may and may not do with AI tools. An AI governance policy is broader, adding the vendor, audit, incident, and board-reporting machinery around those rules. The template here is written as one document covering both, which is why it is titled an Acceptable Use and Governance Policy.

Does a law firm need a different AI policy than an in-house legal team? The eight components are the same. The differences are at the edges: a law firm leans harder on client confidentiality, court-disclosure duties, and billing for AI-assisted work, while an in-house team leans on employee/HR uses and board reporting. ABA Formal Opinion 512 (July 2024) is the shared reference point for the lawyer's duty of competence. Adapt the same template for either.

Can lawyers paste confidential documents into ChatGPT or Claude? Not into the consumer versions. A free or personal account's terms generally let the vendor keep and train on your inputs, which can waive privilege and create discovery problems. Enterprise tenants with a signed DPA and a no-training commitment are a different matter and are the only AI tools a policy should approve for confidential work. See where your legal AI data actually goes.

Do in-house teams have to follow ABA Formal Opinion 512? In-house lawyers are still licensed and bound by their state's rules of professional conduct, which track the ABA Model Rules that Opinion 512 interprets. So the competence, confidentiality, and supervision duties apply to in-house practice even without a client relationship in the traditional firm sense. Build the legal-team training module around it.

How long does it take to roll out an AI governance policy? About six months for a mid-size company: month 1 inventory, months 2 to 3 policy draft plus DPA and AI addendum, month 4 training, month 5 enforcement, month 6 audit. The drafting is fast. The inventory, the vendor-addendum negotiation, and enforcing against a workforce that needs AI to do its job are the slow parts.

Is a written AI policy legally required? It depends on where you operate, and the state-law answer moved in 2026. Colorado's original AI Act would have required deployers of high-risk systems to keep a risk management policy and program, but that provision was repealed before it ever took effect and replaced by SB 26-189 (effective January 1, 2027), which drops the risk-management mandate for a lighter disclosure regime. The EU AI Act still imposes governance duties on deployers of high-risk systems extraterritorially. Outside a hard statutory trigger, a written policy is not strictly mandatory, but it is now a standard cyber-insurance and enterprise-security-questionnaire input, so most regulated or multinational employers need one in practice.

Colorado repealed its AI Act and the White House wants to preempt state laws. Do I still need a policy? Yes. The regulatory ground shifting is the argument for a policy, not against one. Colorado's hard-law duty was gutted by SB 26-189 before it bound anyone, and the March 2026 White House framework recommends preempting "unduly burdensome" state AI laws, but that is a legislative proposal Congress has not passed. The EU AI Act, the SEC's disclosure posture, Illinois HB 3773, and NYC Local Law 144 are all still live, and cyber-insurers and enterprise customers ask for an attestation regardless of the statutory picture. Build the policy on the NIST AI RMF so it holds through the churn, and treat the statute-specific disclosures as a thin, swappable layer on top.

For related operational playbooks, see Building an Internal Legal Copilot for Your In-House Team, Rolling Out Legal AI to Your Team, the AI compliance check for CCPA, GDPR, and SOX, and SEC Cybersecurity Disclosure (Item 1.05): A GC Playbook.

Arshita Anand

Co-Founder & CEO · Attorney

Arshita leads product and strategy at Vaquill, building the legal AI suite that solo, small-firm, and in-house US lawyers use to run a matter end to end.