A company adopts an AI tool the way it once adopted spreadsheets: someone finds it useful, and use spreads before anyone has written down the rules. Governance is the discipline of writing those rules down on purpose. This article is a checklist for the company that has decided to deploy AI and now has to do so responsibly.
The companies that reach an AI governance lawyer are rarely asking whether to use the technology; that decision is usually already made, and often made in several departments at once. They are asking how to keep the use defensible. A founder has a team running customer data through a model and wants to know what could go wrong. An operations lead has discovered four tools in use that no one approved. A general counsel has been handed a vendor's contract and asked to bless it by Friday. In each case the need is the same: a deliberate framework that turns scattered, informal use into something the business can stand behind.
This article stays on governance and oversight — the operational controls a company puts around the AI it deploys — rather than on doctrine. As an emerging technologies law firm in New York, the practice meets this question often, and this piece is a focused companion to the firm's broader treatment of AI law, contracts, copyright, and governance. It sends the question of who owns AI-generated output to the firm's separate article on that subject. What it covers is the working list: an inventory and a way to classify risk, written use policies and human oversight, vendor diligence, the handling of confidential and regulated data, bias and consumer-protection exposure, disclosure obligations, infringement risk, records and incident response, customer contracts, and the assignment of a clear owner.
It is general information, not legal advice. The law governing artificial intelligence is changing quickly — statutes, regulations, and agency positions are being added and revised across jurisdictions, and what is described here is general and stated as the landscape stands in 2026. The controls that fit a given company depend on its industry, the data it handles, the decisions it lets AI touch, and the law in force where it operates, and they have to be built with counsel rather than copied from a checklist alone. One theme runs through all of it: governance is documentation of a deliberate process, and the time to build it is before anyone outside the company asks to see it.
Start with an inventory and a way to rank risk
Governance begins with knowing what you have, and most companies do not. The first item on the checklist is an inventory: a written record of the AI systems in use across the business, who uses each one, what decisions each one informs or makes, and what data flows into and out of it. This includes the tools a company licenses deliberately and the ones that arrived quietly inside other software or that an employee began using without approval. An honest inventory is harder to assemble than it sounds, because informal use is by definition undocumented, but a control framework that does not know what it is governing protects nothing.
Once a company can see its systems, it has to rank them, because not every use of AI carries the same weight. A tool that drafts internal first drafts sits far from a tool that screens job applicants, scores creditworthiness, or shapes a decision that affects a person's livelihood or rights. A workable classification sorts uses by the stakes of the decision they touch and the sensitivity of the data they handle, so that oversight and diligence can be concentrated where the consequences are real rather than spread evenly across uses that do not need it. The point of classification is proportion: it puts the strongest controls where a mistake would cost the most.
The inventory and the risk ranking are not a one-time exercise, and treating them as a project to finish rather than a register to maintain is a common error. AI use inside a company changes as tools are added, as vendors change their features, and as employees find new applications, so the inventory has to be revisited on a schedule and updated when something material changes. A register that was accurate a year ago and has not been touched since is, in practice, a register that no longer describes the company. Keeping it current is part of the governance work.
A control framework that does not know what it is governing protects nothing — the inventory is the foundation the rest of the list is built on.
Write the use policy and keep a human in the loop
With the systems mapped, the next item is a written AI use policy — a document that tells employees, in plain terms, what they may and may not do with AI tools. Verbal understandings and assumed good sense do not survive contact with a workforce using tools at speed, and a policy that lives only in a manager's head cannot be enforced or shown to anyone later. A usable policy states which tools are approved for which purposes, what categories of data may never be entered into a third-party model, when human review is required before an AI-influenced output is relied upon, and who to ask when a situation falls outside the rules.
Running underneath the policy is the principle of human oversight, often described as keeping a human in the loop. The idea is that for decisions that carry real consequences, a person remains responsible for the outcome and reviews the AI's contribution before it takes effect, rather than letting the system act unchecked. The degree of oversight should track the risk ranking from the first section: a low-stakes drafting aid may need little, while a tool that touches employment, credit, eligibility, or anything affecting a person's rights calls for a person who can understand, question, and override what the system produces. Oversight is a defined point where a human can and must intervene.
Human oversight only works if it is real, and the failure mode worth naming is oversight that exists on paper but not in practice. A reviewer who rubber-stamps every output because the volume is high, or who lacks the information or authority to disagree with the system, provides the appearance of a human in the loop without the substance. For oversight to mean anything, the reviewer needs the time, the context, and the standing to reject or change what the system produced, treated by the company as a normal outcome rather than an obstacle. A policy that promises review and a workflow that makes real review impossible are a contradiction a regulator or a plaintiff will find.
Diligence on vendors and the data you put in
Most companies do not build their own models; they buy access to someone else's, which makes vendor and procurement diligence a central item on the checklist. Before a tool is adopted for work that matters, a company should understand the terms it is agreeing to — what the vendor may do with the inputs the company sends, whether those inputs are used to train or improve the model, what the vendor commits to on security, and whether the contract offers any indemnity for claims arising from the outputs. These are general points rather than a script, because terms differ sharply between vendors and between service tiers. The discipline is to read the actual terms and decide deliberately.
The diligence question that most directly belongs to governance is data: what a company is willing to put into a tool it does not control. The rule that prevents the most damage is also the simplest to state. Regulated data — personal information subject to privacy law, health or financial records, anything the company is legally obligated to safeguard — and privileged or confidential material should not be fed into a third-party model without a clear, considered basis for doing so and terms that permit it. Information entered into an external system may be retained, may be used to improve the model, and may pass beyond the company's control in ways that are difficult to reverse.
Privilege deserves a specific caution, because it is fragile and easily lost. The protection that keeps a company's communications with its lawyers confidential can be undermined when that material is disclosed to a third party, and routing privileged content through an outside AI service is the kind of disclosure that can put the protection at risk. Confidential business information — trade secrets, unreleased plans, sensitive contracts — carries the same concern: once it has left the company's control through a tool that may retain or reuse it, the company may not be able to claw it back. Vendor diligence and a clear rule against feeding regulated, privileged, or confidential data into third-party models are two halves of the same safeguard.
Regulated, privileged, or confidential material should not be fed into a third-party model without a considered basis and terms that permit it — exposure created this way is difficult to reverse.
Bias, disclosure, and infringement exposure
An AI system can produce outcomes that expose a company to claims of discrimination or unfair treatment, and this is among the areas where regulation has moved fastest. A model used to screen applicants, evaluate employees, set prices, or decide who receives an offer can produce results that disadvantage protected groups, and the company that deployed it can bear responsibility. Employment screening has drawn particular attention: New York City's rules on automated employment decision tools require employers using such tools to take defined steps — including a bias audit and notice to candidates — before relying on them. Those rules are described here in general terms and as they stand in 2026, with the precise scope a question for counsel.
Transparency is the next item, and it has two faces. The first is external disclosure: depending on the jurisdiction and the use, a company may be required to tell people when they are interacting with an AI system or when an automated tool is being used in a decision that affects them, and consumer-protection principles can make a misleading silence about AI's role a problem in its own right. The second is internal candor: a governance framework depends on the company knowing, and being able to show, where AI is genuinely in use. Marketing that overstates what a tool does, or quietly substitutes AI where a customer expected human judgment, creates exposure that turns on what the company represented.
Intellectual-property risk runs through both the inputs a company feeds a model and the outputs it relies on, and it belongs on the checklist as a matter of exposure rather than ownership. On the input side, supplying a model with material the company does not have the right to use can create infringement risk, and outputs can sometimes resemble protected works closely enough to raise a claim. The distinct question of whether the company can own and protect what an AI tool produces is governed by copyright's human-authorship requirement and is the subject of the firm's separate article on who owns AI-generated content. The practical step is to treat inputs and outputs as carrying infringement risk that has to be assessed.
Records, contracts, and a named owner
Governance that is not written down is difficult to prove, and the next item is records: an audit trail of the decisions a company makes about its AI use. That means documenting why a given tool was approved, what review it received, who signed off, and what supports the legitimacy of each significant use. When a regulator inquires, when an enterprise customer runs a vendor AI audit, or when a claim arises, the record of a deliberate process is itself a meaningful answer, and its absence leaves a company explaining decisions it cannot reconstruct. Paired with this is an incident-response plan — who does what when an AI system produces a harmful or erroneous outcome.
Customer-facing contracts are where a company's AI risk meets the people it serves, and they deserve deliberate attention. When a business delivers products or services that use AI, its agreements with customers should address that use rather than leave it to silence: who is responsible if an AI-influenced output is wrong, what the company represents about the role AI plays, and how liability is allocated when something goes amiss. A contract drafted before AI was part of the work, or one that is silent on it today, allocates these risks by default and often by accident. Saying plainly, in the contract, where the responsibility for AI-related outcomes sits is far cheaper to address in drafting than to resolve in a dispute.
The item that holds the rest together is accountability: someone has to own this. A governance framework that belongs to everyone in general belongs to no one in particular, and the checklist is only as durable as the person or committee charged with maintaining it. A company should name an owner — an individual or a small standing group — responsible for keeping the inventory current, enforcing the policy, overseeing vendor diligence, and revisiting the framework as the tools and the law change. The owner needs the authority to make the framework stick and a clear line to AI governance legal counsel for the questions that require it. Assigning that responsibility, in writing, is what turns a checklist into a practice.
A governance framework that belongs to everyone in general belongs to no one in particular — naming an owner is what turns a checklist into a practice.