AI Governance for Companies Building and Using AI

Scope

The Decisions Your Contracts Have to Make

The questions are not abstract. Enterprise buyers now send AI riders alongside their security questionnaires. Investors ask what the product was trained on. Acquirers ask who owns code written with an assistant. Each is answerable — but only if someone decided in advance and wrote it down. The work is making those decisions explicit and putting them where they will actually be read. Not sure where you stand? Our AI Governance Readiness Check is a short self-assessment.

AI vendor and API agreements

Before a model is in your product, someone should be able to answer what the provider may do with what you send it: whether your inputs train their model, who owns the outputs, what happens to your data when you leave, how much notice you get before a model version is deprecated underneath you, and what you are owed when the service degrades. These terms vary widely between providers and change often — the version you agreed to eighteen months ago is frequently not the version you are operating under now. We have written about the questions worth asking before signing an AI vendor agreement.

Rights in your training and reference data

If your product learns from data — customer data, licensed data, your own historical records — the question is what you were permitted to do with it. That means the terms you accepted when you collected it, the promises in your own privacy policy, and the actual scope of any data licence you signed. Companies most often discover a gap here during diligence, which is the most expensive moment to discover it. What your own policy already promises is the first place to look — see whether your privacy policy is out of date.

Customer-facing AI terms

What are you telling customers about the AI, and what have you committed to? Whether you disclose AI involvement and where, who owns the output, what happens when the output is wrong, what customers may not use it for, and how responsibility is allocated when something goes wrong downstream. Terms of use written before the AI feature existed usually do not answer any of these. See our note on AI terms in customer contracts.

Internal AI use policy

Your team is already using these tools. A workable policy answers which tools are approved, what categories of information never go into them — customer data, source code, unreleased plans, anything under NDA — who reviews AI-assisted work before it leaves the company, and what happens when the policy is not followed. Short and enforced beats comprehensive and ignored. Related: employee NDAs and AI tools, and what to watch when AI drafts your documents.

AI provisions in enterprise contracts

Procurement teams have started asking. Expect questions about training-data use, human review, model changes, subprocessors, and audit rights. The work is deciding in advance what the company can actually commit to and holding that line consistently — rather than conceding a different position in each deal because nobody wrote down the standard one. This sits alongside the rest of your SaaS and software agreements.

IP ownership when the product is built with AI

If engineers, contractors or designers used AI assistance, your contributor agreements and assignment documents should still produce a clean answer about what the company owns. This is the question investors and acquirers ask, and the answer is far easier to establish before the work ships than after. See intellectual property and IP risks for founders building with AI.

AI in hiring and employment decisions

Screening tools, scheduling systems, monitoring software and performance analytics increasingly involve AI, and the company using them owns the outcome regardless of who built them. The questions worth settling in advance: which decisions the tool influences and which it effectively makes, what a candidate or employee is told and when, who reviews an adverse outcome before it becomes final, what the vendor will and will not disclose about how the tool works, and what records exist if the decision is later questioned. This is an area where state law differs and where the rules have been moving — see AI in hiring in California and Texas and employment.

Agents that act on your behalf

An assistant that answers a question and an agent that takes an action raise different questions. If software books, buys, posts, files or negotiates on your behalf, someone should have decided in advance what it is authorised to do, what it may commit the company to and up to what value, when a human is required before it proceeds, whose terms it is operating under when it touches somebody else’s platform, and what record survives the transaction. The same questions run in reverse if a vendor’s agent acts inside your systems, or if agents are the traffic arriving at your product. See who is liable when an AI agent acts.

Engagements

How We Work

Most engagements start with a review of what is already in place: your vendor agreements, your customer-facing terms, whatever internal policy exists, and how the product actually uses AI in practice. That produces a short list of decisions the company needs to make, ranked by which ones a customer or investor will ask about first. If you would rather work through the ground yourself first, our AI legal checklist for startups covers the same territory.

From there the work is drafting — the terms, the policy, the contract language, and the assignment documents that make the answers hold up. For companies that want this handled continuously rather than project by project, see outside general counsel. If you are still forming, start with corporate formation. Where a sale or acquisition is on the horizon, these are the same answers a buyer asks for in diligence — see mergers and acquisitions.

Nadine Deeb is licensed in Arizona, California, and Texas, and works with technology companies across all three.