The AI Governance Gap: Why In-House Counsel Needs an AI Playbook

Do you know every AI tool running inside your organization right now?

Most people pause. A few say yes — and then immediately second-guess themselves.

And with folks vibe coding their own apps and agents, it's AI gone wild.

That's the governance gap. And it's the reason we hosted our recent webinar, Building Your AI Governance Playbook: A Practical Guide for In-House Counsel. The question is no longer whether AI is in your organization. According to McKinsey's State of AI 2025 report, 88% of companies are using AI in at least one business function — up from 78% just a year prior. Meanwhile, roughly 60% of vendor contracts now include AI-powered features by default, often quietly tucked into tools your team has been using for years.

The question legal professionals should be asking isn't whether to govern AI; it's whether legal can get ahead of it before problems show up as data incidents, vendor disputes, regulatory scrutiny…or even the loss of attorney-client privilege protection.

Start with Discovery, Not Policy

One of the most important mindset shifts I see in-house counsel need to make is to resist the urge to jump straight into drafting the policy. As we say at Sandstone, it's all about context. Before you can govern AI, you have to know what you're actually governing.

That means conducting an AI inventory — and it's not as simple as asking IT to send a list of AI tools. AI is showing up in all cloud-based productivity suites, suggesting email content, recording and transcribing your virtual meetings, and powering internal decision-making in HR screening, budget forecasting, and risk scoring.

It's also living in your legal tech stack — contract review tools, e-discovery platforms, legal research tools, regulatory monitoring software — which, if you're like most legal departments, has grown significantly over the last two years.

A practical AI inventory requires four steps:

Survey business unit leaders about the tools and vendors in use or under evaluation.

Audit procurement records and SaaS subscriptions (pro tip: Ask your finance team for a list of vendors that were paid over the last fiscal year).

Interview IT and engineering to surface internally built tools and API connections.

Review existing vendor agreements for AI provisions that may have been added with only notice from the vendor being an email that you never opened (pro tip: Prioritize your review based on risk tier — more on that later).

You'd be surprised how many vendors have quietly upgraded their products with generative AI features since the contract was signed and the tool was implemented. Most likely, it's almost all of them if the tool is cloud-based, due to market and customer pressure.

Not All AI Is Created Equal — Tier Your Risk

Once you have a picture of your AI landscape, the next step is building a risk framework that actually works. The mistake I see teams make is treating every AI deployment the same way, which either creates excessive bottlenecks for low-risk tools or, worse, gives high-risk tools the same cursory review as a basic productivity feature.

A tiered approach fixes this:

High-risk AI — think tools involved in hiring decisions, credit scoring, medical triage, facial recognition, or autonomous customer actions — warrants legal review, executive sign-off, a data processing addendum, security review, and a human oversight mandate.

Medium-risk AI, like customer-facing tools or vendor AI with data sharing in regulated contexts, still requires legal review and a DPA but allows for a lighter periodic review cycle.

Low-risk tools — general LLM use for drafting and summarization, internal analytics — can move through with basic policy acknowledgment, standard vendor vetting, and usage guidelines.

The risk tier framework also creates the backbone of your AI intake process. When a business unit wants to adopt a new AI tool, they submit a request, legal assigns a risk tier, and the appropriate approval workflows are triggered. It sounds simple, but a consistent intake process is one of the most powerful ways legal operations can prevent ad hoc AI adoption from outpacing governance.

Employee-built and internally developed AI tools using no-code platforms, API connections, automation workflows (e.g., Zapier, Make, n8n), or custom LLM integrations — require a separate and heightened level of scrutiny. Unlike vendor tools, these have no procurement contract, no data processing agreement, and often no defined owner. They frequently bypass IT visibility entirely. Because they can connect multiple internal systems to external LLM APIs, they present compounded data egress, confidentiality, and regulatory risk. These tools should be treated as at least medium-risk by default and must go through the same intake process as any third-party tool.

The Hidden Risk: Agentic AI and Cross-System Data Flows

The governance playbook covers vendor tools well, but one of the fastest-growing risk vectors is AI that employees build or configure themselves. When an employee creates an automation that pulls data from Salesforce, summarizes it using an external LLM API, and sends the result via email, data has crossed multiple system boundaries and potentially left the organization entirely — all without a procurement review, a DPA, or any legal sign-off.

There are four specific legal issues your playbook needs to address:

Data egress and privacy exposure. Many consumer-grade and developer-tier LLM APIs use inputs for model training by default, meaning employee-built agents may be inadvertently donating confidential company data — contracts, HR records, financial projections, intellectual property — to third-party model providers. This is not a hypothetical risk; it has already triggered regulatory investigations in multiple jurisdictions.

Multi-system data contamination. An agent that reads from multiple internal systems creates a data lineage that IT and legal have no real-time visibility into, making it impossible to honor deletion requests, respond to audits, or trace a breach.

Output liability. When an agent acts autonomously — sending communications, generating reports, or making recommendations — the question of who owns the output and who is liable for errors is unanswered by most current policies.

Orphaned tools. When the employee who built the agent leaves the company, the tool often keeps running with no defined owner, no update process, and credentials that may never be rotated.

Your AI governance playbook needs to address this directly: require employees to disclose and register any internally built AI tool or automation before deployment, apply data classification rules to determine what can flow where, and prohibit connecting systems containing regulated data (PII, privileged communications, trade secrets) to unapproved external APIs.

What Actually Goes in the Playbook

An AI governance playbook is not a single policy document. It's a living framework that includes several interconnected components, including:

An AI use policy covering acceptable and prohibited uses, including employee use of third-party AI tools.

A living AI inventory register — not a one-time snapshot, but a maintained record of every tool, vendor, use case, risk tier, and owner.

A standard vendor AI addendum covering data use, model training restrictions, output ownership, and liability allocation.

A risk assessment template that maps to your tier framework, an incident response protocol with clear escalation paths, and employee training materials that give people practical guidance on what they can and can't do.

Two additional documents are essential, given the rise of employee-built tools.

An internal build policy, separate from the vendor AI addendum, should specify which systems employees are permitted to connect to external AI services, what approval is required before deploying any internally built AI tool or agent, and what disclosure obligations apply. Without this, the vendor-focused addendum leaves a significant gap.

A data classification and permissible flow matrix: a simple chart that maps data types (public, internal, confidential, regulated, attorney-client privileged) against permissible AI systems (approved enterprise tools, approved external APIs with DPAs, and prohibited destinations). This gives employees a clear decision-making tool and gives legal a defensible policy framework if a breach or regulatory inquiry occurs.

Crucially, the playbook needs built-in maintenance cycles. AI governance isn't a project you complete and check off. That means quarterly reviews of the AI inventory for new tools and updated risk tiers, annual full-playbook reviews for regulatory changes, re-as; annual full-playbook reviews for regulatory changes; reassessments whenever a vendor updates their terms of service; post-incident reviews that feed back into the protocols;sessment whenever a vendor updates their terms of service, post-incident reviews that feed back into the protocols, and rapid review cycles when new regulations drop.

Employee-built tool incidents require their own response protocol. Unlike a vendor breach — where you have a contract, a notification obligation, and a point of contact — an internal agent exposure often surfaces after data has already left the organization, with no defined owner and no guarantee the tool is even in your inventory. The protocol should cover four things: a rapid containment checklist (revoke API keys, disable integrations, notify IT); a compressed assessment timeline of 24-48 hours rather than the standard 72; a process for tracing what data was exposed and to which third-party systems; and clear criteria for when a privilege review is triggered.

Getting Executive Buy-In — Speak Their Language

A lot of in-house counsel I talk to have the governance instincts right, but struggle to get executive support before something goes wrong. The key is translating the legal and risk rationale into terms that resonate with leadership: risk quantification, revenue impact, and competitive positioning.

Show executives what ungoverned AI costs — lost deals due to not meeting customer requirements, AI errors, bias claims, and regulatory fines are measurable numbers, not hypotheticals. Frame strong AI governance as a customer and partner trust signal, because enterprise customers and regulated industry partners increasingly audit their vendors' AI governance practices. And reframe governance as a speed enabler, not a speed bump.

A clear, tiered approval pathway streamlines how business units get to yes on new tools — fast-track for low-risk, predictable for everything else. That's not legal slowing down innovation — that's legal making it possible to move faster.

There is one more dimension executives need to understand: ungoverned employee-built AI is not just a technical risk — it's a culture and accountability problem. Governance only works if there are proportionate, consistently applied consequences for circumventing it. Help executives see that an employee who deploys an unauthorized agent connecting to client data systems creates the same category of exposure as an employee who sends a privileged document to a personal email account. The playbook should include a clear escalation path for violations, graduated consequences that reflect the severity of the risk created, and an amnesty window at launch during which employees can self-disclose existing unauthorized tools without penalty. That last point is critical: it is far better to have employees come forward during discovery than to find out about a tool after an incident.

Legal's Role Is to Make "Yes" Easier

This is the shift I most want in-house counsel to internalize. The reactive version of legal gets called in after a tool is already deployed, reviews things in isolation, governs by prohibition, and earns a reputation as a bottleneck. The proactive version gets involved in AI strategy from day one, builds scalable review frameworks that create fast-track approvals for low-risk tools, and makes legal work more strategic — not just faster.

If I had to distill everything from our webinar into one call to action, it would be this: Identify your highest-risk existing AI tools and go from there. If you're seeking a starting point for a framework, you're in luck — use the 30/60/90 plan below.

The governance gap is real — but it's closable. And legal is exactly the right function to drive closing it.

.This post is adapted from Sandstone's webinar, "Building Your AI Governance Playbook: A Practical Guide for In-House Counsel." Want to watch the full recording? Click here to access it on Vimeo.