AI Procurement and Governance Toolkit: Vendors, Models, Data, and Output

By Casey Scott McKay · 2025-10-03

Buying artificial intelligence looks like buying software and is not, because the contract has to allocate rights in data going in and output coming out, and because the risks that matter are not availability but accuracy, ownership, confidentiality, and discrimination. This toolkit works the vendor diligence that precedes any agreement and the terms that carry the weight - training rights over customer data, output ownership, infringement indemnity and its exclusions, model versioning, and exit. It sets out the governance layer: a use case inventory, risk classification, evaluation before deployment, human review where consequences are significant, and monitoring afterwards. It covers the intellectual property position on inputs and outputs, the confidentiality exposure prompts create, and the claims a company makes about its own AI.

IP and Technology > Information Technology | Toolkit | Published 3 October 2025 - Updated 23 March 2026 | Casey Scott McKay - marksy.us

Summary. Buying artificial intelligence looks like buying software and is not, because the contract has to allocate rights in data going in and output coming out, and because the risks that matter are not availability but accuracy, ownership, confidentiality, and discrimination. This toolkit works the vendor diligence that precedes any agreement and the terms that carry the weight — training rights over customer data, output ownership, infringement indemnity and its exclusions, model versioning, and exit. It sets out the governance layer: a use case inventory, risk classification, evaluation before deployment, human review where consequences are significant, and monitoring afterwards. It covers the intellectual property position on inputs and outputs, the confidentiality exposure prompts create, and the claims a company makes about its own AI.

Keywords: AI procurement · vendor diligence · training rights · customer data exclusion · output ownership · human authorship · Thaler v Perlmutter · infringement indemnity · model governance · use case inventory · prohibited uses · human review · evaluation and testing · bias and disparate impact · confidentiality and prompts · trade secret exposure · model updates and versioning · exit and portability · regulatory frameworks · AI capability claims

Start Here

A company adopts an AI assistant across its engineering and legal teams. Nobody signs anything; the tool is available through an existing platform subscription and the terms were accepted by whoever enabled it.

Six months later three questions arrive at once. A customer asks whether its confidential data has been used to train a model. A product manager asks whether the code the assistant generated can be included in a product the company will licence. And a plaintiff's letter asserts that output the marketing team published infringes a copyrighted work.

None of those questions has an answer, because the contract that would have answered them was accepted by a checkbox and nobody has read it.

This toolkit answers three questions.

What must the contract allocate? Training rights, output ownership, indemnity, confidentiality, and exit.
What must governance cover? Which use cases, at what risk level, with what evaluation and what human involvement.
What does the company own, and what is it exposed to? Inputs, outputs, and the claims it makes about both.

If you read only one thing, read Buying a Model. It works the contract terms that matter and the ones that are decorative.

Vendor Diligence

Before the contract. A short, standard diligence set, proportionate to the use case's risk classification.

What the model is. Foundation model, fine-tuned model, or retrieval system over the customer's own data. The answer changes every downstream question.

Training data provenance. What the base model was trained on, at least in categories, and whether the vendor has indemnified or represented anything about it. Most vendors will say less than a buyer wants; what they do say is the representation.

Customer data use. Whether inputs, outputs, or usage telemetry are used to train, improve, or evaluate models, and whether that can be disabled. This is the single most important diligence question and the answer differs between the vendor's consumer tier and its enterprise tier.

Subprocessors and model hosting. Where the model runs, who operates it, and whether a third-party model provider sits behind the vendor. A vendor reselling another provider's model inherits that provider's terms, and the buyer needs to see them.

Retention. How long prompts and outputs are retained, in what form, and whether retention can be shortened or zeroed.

Security posture. The ordinary vendor security diligence, plus questions specific to model inference — logging, access to prompt data, and whether human reviewers see customer content.

Evaluation evidence. What the vendor has tested for, on what data, and what it will share. Vendor benchmarks are marketing; the relevant question is performance on the buyer's use case.

Regulatory posture. Whether the vendor supports the buyer's obligations under applicable frameworks — documentation, logging, explanation, and human oversight.

Financial and continuity. Model providers are young companies, and a critical dependency on one is a continuity risk. See Software Continuity and Escrow Toolkit.

The Terms That Matter

Training rights over customer data. The buyer's position should be that inputs, outputs, and derived data are not used to train or improve models available to anyone else, with a narrow permitted exception for abuse detection. Get it in the agreement, not in a documentation page the vendor can change.

Output ownership. The agreement should assign or confirm the customer's ownership of output as between the parties, and acknowledge that other customers may receive similar output — which is true and should not be papered over.

Which is not the same as owning copyright in the output. As between the parties, contract governs. Whether copyright subsists at all is a separate question addressed below.

Confidentiality. Prompts and uploaded documents are confidential information, and the agreement should treat them as such — including a prohibition on human review absent consent, or a defined and disclosed review process.

Infringement indemnity. Increasingly offered for output, and heavily qualified. Read the conditions: use of the vendor's safety filters, no modification of output, no infringing input, prompt notice, and control of defence. An indemnity conditioned on facts the buyer cannot verify is worth less than it appears.

Exclusions to read. Output the customer modified. Output generated from customer-supplied infringing input. Use outside the documentation. And, frequently, a cap that is a multiple of fees rather than uncapped.

Accuracy disclaimers. Every AI agreement disclaims accuracy, and that is not negotiable in most cases. The response is governance — human review proportionate to consequence — rather than contract.

Model changes. Models are updated, and behaviour changes. The agreement should provide notice of material changes, a period of version stability for validated use cases, and access to a prior version where the buyer's validation depends on it.

Service levels. Availability, latency, and rate limits, with the ordinary remedies.

Audit and documentation. Rights to information necessary for the buyer's own regulatory obligations.

Exit. Export of prompts, outputs, fine-tuning data, and any customer-specific model artefacts, in a usable format, with deletion certified afterwards.

Data location and cross-border. Where inference occurs and where data is stored, with the export control dimension where the technology is controlled. See The Technology That Cannot Leave the Room.

Intellectual Property in Inputs and Outputs

Human authorship is required for copyright. Thaler v. Perlmutter confirms that a work generated without human authorship is not protectable, and registration practice requires disclaiming machine-generated material.

Which means output may be unownable. A marketing image generated wholesale from a prompt has no copyright, and neither the vendor nor the customer owns it, whatever the contract says as between them.

Human contribution creates protectable increment. Selection, arrangement, and modification by a human can support protection in that contribution, and the registration must describe it accurately.

Document the human contribution contemporaneously — prompts, iterations, selections, and edits — for any output the company intends to rely on as an asset.

Inventorship. Thaler v. Vidal holds that an inventor under 35 U.S.C. § 100 must be a natural person. AI-assisted inventions require identification of the human contributions to conception. See Inventorship and Patent Ownership Disputes Toolkit.

Output infringement. Output substantially similar to a protected work infringes regardless of how it was produced, and the 17 U.S.C. § 107 analysis after Andy Warhol Foundation v. Goldsmith is less favourable to commercial uses sharing the original's purpose than the earlier framing suggested.

Training on protected works is the contested question, and the fair use analysis draws on the transformative-purpose line running through Authors Guild v. Google and now constrained by Warhol. It is being litigated and it is not the buyer's exposure to resolve — the buyer's exposure is the indemnity.

Trade secrets in prompts. Confidential information pasted into a tool that retains or trains on it may lose its trade secret status, because reasonable measures under 18 U.S.C. § 1839 are the requirement and disclosure to a vendor without confidentiality obligations is not one. See Trade Secret Protection Toolkit.

Open source in generated code. Code output resembling licensed open source carries that licence's obligations, and copyleft terms can propagate into a product. A software composition analysis over generated code is now a necessary control. See Copyleft and Consequences.

Third-party rights in inputs. Uploading a licensed document to a tool may exceed the licence under which it was obtained, and stock, database, and content licences frequently prohibit it.

Governance

The layer that determines whether the contract's protections matter.

The use case inventory. Every deployment, with owner, vendor, model, data in, output destination, risk classification, evaluation record, human review requirement, and review date. Build it before anything else; it is the programme.

Risk classification. A simple tiering works better than an elaborate one. Low: internal productivity, no personal data, no external output. Medium: customer-facing output, or personal data, with human review. High: decisions affecting individuals' rights, opportunities, or access — employment, credit, housing, insurance, healthcare, education.

High-risk use cases need more than contract terms. Evaluation before deployment, documented human review, an explanation capability, an appeal route, and monitoring for disparate outcomes.

Prohibited uses. A short list, decided centrally: no use in decisions the company would not defend, no upload of defined data categories, no customer-facing output without review in named contexts, and no use in regulated determinations without the sector controls.

Evaluation before deployment. On the buyer's own data, for the buyer's own use case. Vendor benchmarks tell you nothing about performance on your documents, your customers, or your edge cases.

What to evaluate. Accuracy on representative inputs. Failure modes and how they present. Behaviour on adversarial or unusual inputs. And, for consequential use cases, outcome distribution across groups.

Human review, proportionate to consequence. Not a checkbox that a reviewer clicks, but a review with the time and information to reach a different conclusion. A reviewer approving four hundred determinations an hour is not a control.

Monitoring after deployment. Sampled output review, error reporting from users, drift detection, and a trigger for re-evaluation on model change.

Model version control. Which version is validated for which use case, and a process for revalidating on change. The vendor's silent update is the most common cause of unexplained behaviour change.

Incident process. What happens when output causes harm — containment, correction, notification, and root cause.

Documentation. For each high-risk use case, a record sufficient to explain what the system does, what it was tested on, who reviews it, and what changed. Several regulatory frameworks require it and every one of them expects it.

Training. Users on the prohibited data categories and the review obligations; reviewers on what meaningful review requires.

Discrimination and Consequential Decisions

The risk category with the oldest law and the newest attention.

Employment. 42 U.S.C. § 2000e-2 reaches practices that are facially neutral and disparately impactful, and a screening tool that filters candidates is a selection procedure whatever produces it.

Which means validation is the obligation. A tool used in selection should be validated for job-relatedness and consistency with business necessity, and the vendor's assurance is not the employer's defence — the employer is the one making the decision.

Local requirements. Several jurisdictions require bias audits of automated employment decision tools, with published results and candidate notice. These are procedural obligations with penalties independent of any discrimination finding.

Credit and lending. 15 U.S.C. § 1681 obligations attach where a tool produces or uses a consumer report, and adverse action notice requirements demand a statement of principal reasons — which a model that cannot explain itself makes difficult.

Insurance, housing, and healthcare each carry sector frameworks with their own requirements on the use of automated tools.

State algorithmic discrimination statutes impose duties of reasonable care on developers and deployers of systems making consequential decisions, with impact assessments, notice, and appeal rights. See Colorado artificial intelligence statute.

Profiling rights under privacy statutes. Consumers may opt out of profiling in furtherance of decisions with legal or similarly significant effects, and data protection assessments are required for it. See State Privacy Compliance Toolkit.

The practical programme for consequential use cases. Validate before deployment. Measure outcome distribution. Keep a human decision-maker with real authority. Provide notice and an appeal. Document all of it. And be prepared to explain the decision in terms a person can understand.

Or do not use the tool. For a small number of decisions, the honest answer is that the accuracy and explainability available do not justify the exposure, and the company is better served by not automating.

Confidentiality and Trade Secrets

The exposure that arises from ordinary use rather than from any decision.

The mechanism. An employee pastes a draft agreement, a customer list, source code, or unpublished financial data into a tool. Where the tool retains that content, uses it for training, or exposes it to human reviewers, the confidentiality of the information is compromised.

Trade secret consequences. Protection under 18 U.S.C. § 1836 requires reasonable measures under 18 U.S.C. § 1839. Disclosure to a vendor with no confidentiality obligation, in circumstances where the company had no policy against it, is a reasonable measures problem.

Third-party confidential information is worse. Customer data, partner data, and information received under a nondisclosure agreement carry obligations the company owes to someone else, and uploading it may breach that agreement directly.

Privilege. Legal analysis pasted into a tool that retains it may be a disclosure that defeats confidentiality. Where the tool is enterprise-configured with no retention and no training, the position is defensible; where it is a consumer account, it is not. See Privilege and Work Product Toolkit for IP Matters.

Regulated data. Health information, financial information, and children's data each carry frameworks that constrain disclosure to processors and require contracts the consumer tier of a tool does not have.

Export controls. Technical data released to a foreign person is an export, and a tool with foreign administrators or foreign inference locations raises the question. See The Technology That Cannot Leave the Room.

The controls that work. An approved tool list with enterprise terms in place. A prohibited data category list, short and specific. Technical enforcement where possible — blocking consumer endpoints, data loss prevention on uploads. And training that explains the categories rather than reciting a policy.

Shadow adoption is the real problem. Employees use tools the company has not approved because they are useful. A programme that prohibits without providing an approved alternative produces exactly that. Provide the sanctioned tool with the right terms, and the prohibition becomes enforceable.

Discovery of past use. Where uncontrolled use has already occurred, the exercise is to identify what was disclosed, to which tools, under what terms — and to assess whether trade secret status or third-party obligations were compromised.

Claims About Your Own AI

The exposure that arises from marketing rather than from deployment.

Capability claims are advertising claims. 15 U.S.C. § 45 reaches deceptive claims, and a stated accuracy rate, performance benchmark, or automation capability requires substantiation before it is made.

"AI-powered" claims where the functionality is rules-based have drawn enforcement, as have overstated automation claims.

Comparative claims against competing products require substantiation of the comparison on the attributes compared. 15 U.S.C. § 1125(a)(1)(B) gives competitors a claim.

Claims about training data — that a model was trained only on licensed data, for example — are representations, and they are increasingly the subject of diligence and litigation.

Claims about privacy and security of customer inputs are representations enforceable under 15 U.S.C. § 45 and under contract, and they should be traceable to the configuration actually in place.

Investor communications. For registrants, capability and adoption claims in filings and earnings communications are subject to securities liability, and describing pilot deployments as production capabilities is the recurring pattern.

Model cards and documentation given to customers are representations too.

The practical rule. Every claim about the company's AI — in marketing, in contracts, in filings — traced to a test result or a configuration, with the substantiation file dated. See Promotions and Advertising Compliance Toolkit.

And the honest framing internally. The gap between what a demonstration shows and what a deployment delivers is where these claims go wrong, and legal review of AI marketing should ask which one the claim is based on.

Worked Example: The Enterprise Rollout

A company with four thousand employees decides to deploy an AI assistant across the organisation.

Week one — the inventory. A survey plus network logs identify eleven AI tools already in use, nine of them adopted without procurement involvement, six on consumer terms permitting training on inputs. Two are used with customer data.

Which reframes the project. It is not a deployment; it is a consolidation.

Week two — risk classification. Three use cases are proposed for the sanctioned tool: document drafting and summarisation, code assistance, and customer support suggestion. The first two are medium risk. The third produces customer-facing output and is treated as medium risk with mandatory human review.

Week three — vendor diligence. The preferred vendor resells a foundation model. The underlying provider's terms are obtained and reviewed. Enterprise tier excludes customer content from training; the consumer tier does not, which explains six of the nine shadow deployments.

Week four — negotiation. Training exclusion moved from a documentation page into the agreement. Output ownership confirmed as between the parties. Infringement indemnity accepted with its conditions understood and the conditions mapped to controls the company can actually maintain. Model version stability for ninety days on validated use cases. Export and deletion on exit. Retention set to zero for prompts.

Week five — evaluation. The code assistance use case is tested on the company's own repositories. Output is run through software composition analysis, which identifies licence-relevant matches in a small percentage of generated snippets — enough to require the scan as a standing control rather than a one-time check.

Week six — controls. Prohibited data categories published: customer personal data, third-party confidential information received under agreement, unpublished financial information, and source code for two named products. Consumer endpoints blocked at the network. The sanctioned tool provisioned to everyone, which is what makes the block enforceable.

Week seven — the authorship record. For marketing and product content, a lightweight capture of prompts, iterations, and human edits, so that copyright in the human contribution can be claimed and disclaimed accurately under the Thaler v. Perlmutter framework.

Week eight — decommissioning. The nine shadow tools are wound down, with an assessment of what was disclosed to each and whether any third-party confidentiality obligations were breached. Two customer notifications result.

Month six — monitoring. Sampled output review, a user error reporting channel, and a revalidation triggered by a vendor model update that changed summarisation behaviour on long documents.

What made it work. Discovering the existing footprint before designing the programme, providing a sanctioned alternative before prohibiting anything, and evaluating on the company's own data rather than on the vendor's benchmarks.

Common Mistakes

No use case inventory. The company cannot say what it is running, on what data, with what terms.

Accepting terms by checkbox, then discovering that the consumer tier trains on inputs.

Assuming the enterprise tier's protections apply when employees are using personal accounts.

Training exclusion in documentation rather than in the agreement, where the vendor can change it.

Reading the indemnity as protection without reading its conditions and exclusions.

No evaluation on the company's own data, relying on vendor benchmarks that measure something else.

Human review that is a click. A reviewer without time or information is not a control.

No model version control, so a silent vendor update changes behaviour in a validated use case.

Prohibiting without providing. A policy against unapproved tools with no sanctioned alternative produces shadow adoption, not compliance.

Uploading third-party confidential information, breaching agreements owed to customers and partners.

Treating output as owned copyright. Thaler v. Perlmutter means machine-generated output may be unprotectable regardless of what the vendor contract says.

No software composition analysis over generated code, letting open source obligations propagate silently.

Automated consequential decisions without validation, which is the exposure with the oldest and most developed body of law behind it.

Capability claims that outrun the deployment, which are advertising claims and, for registrants, securities disclosures.

No exit provision, so the prompts, outputs, and fine-tuning data stay with a vendor the company wants to leave.

Regulatory Frameworks

Risk-tiered regulation. The European framework classifies systems by risk and imposes obligations accordingly — prohibited practices, high-risk system requirements covering risk management, data governance, documentation, logging, transparency, human oversight and accuracy, and lighter transparency duties for certain systems. See European Union AI Act.

Its extraterritorial reach. The framework applies to providers placing systems on the market in the region and, in defined circumstances, where output is used there, which brings companies with no regional establishment into scope.

Deployer obligations. A company using a high-risk system, as distinct from building one, has its own duties — human oversight, input data relevance, monitoring, log retention, and notification of incidents.

Which means the buyer cannot rely on the vendor's compliance. The obligations attach to the deployer separately, and the vendor's documentation is an input to the deployer's compliance rather than a substitute for it.

State algorithmic discrimination statutes impose duties on developers and deployers of systems making consequential decisions, including impact assessments, risk management programmes, notice to affected individuals, and disclosure of the role of the system. See Colorado artificial intelligence statute.

Sector regulators have not waited for general legislation and are applying existing authority — fair lending, employment, insurance, healthcare, and securities — to automated systems within their remit.

Transparency and disclosure requirements. Several regimes require disclosure that a person is interacting with an automated system, and labelling of synthetic content.

Governance frameworks. Voluntary frameworks provide the structure regulators and counterparties expect — govern, map, measure, and manage. See NIST AI Risk Management Framework.

The practical approach. Build to the risk-tiered structure regardless of current applicability, because it is the architecture every emerging framework shares: know your use cases, classify them, document the high-risk ones, keep a human in the consequential loop, and monitor.

And keep the documentation. Every framework requires records the company would not otherwise create — evaluation results, oversight arrangements, and logs. Building them into the deployment process is cheaper than reconstructing them.

Diligence Questions

Is there a use case inventory? Its absence is the first finding.

Which tools are in use, under what terms, and were they procured? Network logs and expense records answer this better than a survey.

Does any agreement permit training on customer inputs? Check the agreement, not the documentation page.

What does the indemnity actually cover, and are its conditions ones the company can satisfy?

Was each use case evaluated before deployment, on the company's own data, with the results recorded?

Which use cases produce consequential decisions about individuals, and what validation, human review, notice, and appeal exist?

Is there prohibited data category guidance, and is it technically enforced?

Has third-party confidential information been uploaded to any tool?

Is generated code scanned for licence-relevant matches?

Is there an authorship record for output the company relies on as an asset?

Are model versions controlled, and what happens on a vendor update?

What does the company claim about its AI in marketing, contracts, and filings, and is each claim substantiated?

What are the exit terms? Export of prompts, outputs, and fine-tuning artefacts, with deletion certified.

What regulatory frameworks apply, and is the documentation they require being created?

Questions Clients Ask

Do we own the output? As between you and the vendor, whatever the contract says — and get it to say you do. Whether copyright subsists at all is separate: Thaler v. Perlmutter requires human authorship, so purely machine-generated output may be unprotectable by anyone.

Can we register a copyright in AI-assisted work? In the human contribution, with the machine-generated material disclaimed. Which requires knowing what the human contributed, which requires a record.

Can an AI be an inventor? No. Thaler v. Vidal requires a natural person under 35 U.S.C. § 100. Identify and document the human contributions to conception.

Is the vendor training on our data? Read the agreement, not the marketing. Enterprise and consumer tiers frequently differ, and employees using personal accounts are on the consumer tier.

Does the indemnity protect us? Read the conditions. Most require using the vendor's safety filters, not modifying output, and not supplying infringing input. An indemnity conditioned on things you cannot verify is worth less than its headline.

Can we put customer data in? Only under an agreement with confidentiality, no training, and the processing terms the applicable privacy statutes require — and only if the customer contract permits it.

Have we lost our trade secrets? If confidential information went into a tool that retains or trains on it, reasonable measures under 18 U.S.C. § 1839 are in question. Identify what went where, under what terms.

Can we use it for hiring? Only with validation, human review with real authority, notice, and an appeal — and in several jurisdictions a published bias audit. 42 U.S.C. § 2000e-2 reaches disparate impact regardless of what produced it.

Does generated code create open source obligations? It can, where output resembles licensed code. Scan it, as a standing control.

What if the model changes? Behaviour changes with it. Negotiate notice and version stability for validated use cases, and revalidate on change.

Can we say our product is AI-powered? Only if it is, and only to the extent you can substantiate. Capability claims are advertising claims under 15 U.S.C. § 45, and for registrants they are disclosures.

Where do we start? The inventory of what is already running. Every company that thinks it is beginning an AI programme is in fact consolidating one.

The One-Page Position

AI position — [company], [date]. Use cases inventoried: [N]; classified low [N], medium [N], high [N]. Tools in use: [N] sanctioned, [N] identified as shadow adoption and [decommissioned / in migration]. Agreements: training exclusion in the agreement for [N] of [N] sanctioned tools; output ownership confirmed for [N]; infringement indemnity present for [N], conditions mapped to controls for [N]; retention set to [period]; exit and export terms in [N]. Evaluation: completed on company data for [N] of [N] use cases; results recorded [dates]. Human review: required for [N] use cases, with defined authority and time. Consequential decisions: [N] use cases affecting individuals; validation completed [dates]; notice and appeal implemented [yes/no]; outcome distribution monitored [frequency]. Prohibited data categories published [date]; technical enforcement [in place / partial]; consumer endpoints [blocked / not]. Generated code scanning: [in place since date], [N] licence-relevant matches remediated. Authorship records maintained for [N] output categories. Model versions: [N] pinned for validated use cases; [N] revalidations triggered by vendor updates. Claims audit: [N] AI claims reviewed, [N] substantiated, [N] corrected. Regulatory: frameworks assessed [list], documentation maintained for [N] high-risk use cases. Recommended actions: [build the inventory / move training exclusion into the agreement / validate the screening tool or discontinue it / provision the sanctioned tool before enforcing the prohibition].

Working With Other Advisers

Procurement, who need the diligence set and the standard terms, and who are the control point for shadow adoption once a sanctioned alternative exists.

Security, for the vendor security assessment and for the technical enforcement of prohibited data categories. The vendor risk framework is shared. See Cybersecurity Governance and Disclosure Toolkit.

Privacy counsel, for the profiling and automated decision provisions, the data protection assessments, and the processor terms.

Employment counsel, wherever a tool touches hiring, promotion, or performance — the area with the most developed law and the least appreciation of it.

Engineering leadership, who own the evaluation, the version control, and the code scanning.

Data science, who can design the evaluation properly and who should be asked what the model actually does before the contract is negotiated.

Marketing and investor relations, whose AI claims are advertising claims and disclosures.

Records and knowledge management, for the authorship records and the documentation the regulatory frameworks require.

Outside counsel with sector experience, because a general AI governance programme does not answer the specific requirements in lending, insurance, healthcare, or employment.

Cadence

At every new use case. Risk classification, evaluation on company data, human review determination, and inventory entry before deployment.

At every new tool. Diligence set completed, terms negotiated or rejected, and provisioning through the sanctioned route.

Monthly. Shadow adoption scan from network and expense data. Error reports reviewed.

Quarterly. Sampled output review for deployed use cases. Model version check against pinned versions. Prohibited data category enforcement tested. Generated code scanning results reviewed.

Semi-annually. Vendor terms re-read against current documentation, because vendors change documentation pages more often than agreements. Claims audit across marketing and filings.

Annually. Full inventory refresh. Revalidation of consequential decision use cases, including outcome distribution. Regulatory framework mapping refreshed. Training for users and reviewers. Board or executive report on the AI footprint and its risk profile.

On any model update. Revalidation of affected use cases before the new version is used in production.

On any incident. Containment, correction, notification where required, root cause, and an inventory entry recording what changed.

A Closing Note

The mistake this area invites is treating AI as a technology question that legal reviews, when it is a set of ordinary legal questions arriving through an unfamiliar channel.

Who owns this. What did we promise about it. What did we disclose to whom. Can we substantiate the claim. Did the decision discriminate. Can we leave. Every one of those has decades of law behind it, and none of it changes because the input was a prompt.

What does change is the speed. A tool is adopted in an afternoon by someone with a corporate card, used with customer data by Friday, and embedded in a workflow by the following month. The governance problem is therefore not analytical rigour; it is arriving before the deployment rather than after it.

Which is why the inventory comes first, why a sanctioned tool has to exist before a prohibition can work, and why the evaluation has to be on the company's own data. Do those three, and the legal questions become answerable in the ordinary way.

What This Costs

The inventory. Days, using network logs and expense records rather than a survey, and it is the step that determines everything else.

The diligence set. A standard questionnaire, completed per vendor, proportionate to risk classification.

Contract negotiation. Real time on the terms that matter — training exclusion, output ownership, indemnity conditions, version stability, and exit — and none on the ones that do not.

Evaluation. The largest recurring cost, because it has to be done per use case on the company's own data. It is also the item most often skipped and the one that prevents the most harm.

Technical controls. Endpoint blocking, data loss prevention on uploads, and code scanning. Mostly configuration of tools the company already has.

Human review. An operating cost proportional to volume, and the one the business will push to reduce. Reducing it is a risk decision and should be made as one.

Documentation. Minutes per deployment if built into the process; weeks if reconstructed for a regulator.

Against that: an unownable flagship asset, a trade secret compromised by a paste into a consumer tool, a hiring tool that produced disparate outcomes with no validation, an indemnity that did not apply because its conditions were never met, and capability claims in an earnings call that the deployment does not support.

The economics favour the inventory and the evaluation heavily. Everything else in this toolkit is downstream of knowing what is running and how well it works on your own data.

Start there, and the rest of the programme sizes itself to what the company is actually doing rather than to what the market is talking about.

A Suggested Reading Path

For the contract:

For the ownership questions:

For the surrounding technology contracting:

Primary Authorities

| Authority | Proposition | |---|---| | 17 U.S.C. § 102 | Subject matter; authorship | | 17 U.S.C. § 106 | Exclusive rights | | 17 U.S.C. § 107 | Fair use | | 17 U.S.C. § 201 | Ownership | | 17 U.S.C. § 411 | Registration; accuracy | | Thaler v. Perlmutter | Human authorship required | | Andy Warhol Foundation v. Goldsmith | Transformative purpose narrowed | | Authors Guild v. Google | Transformative use of copied works | | 35 U.S.C. § 100 | Inventor must be an individual | | Thaler v. Vidal | AI cannot be an inventor | | 18 U.S.C. § 1836 | Trade secret civil action | | 18 U.S.C. § 1839 | Reasonable measures | | 15 U.S.C. § 45 | Unfair or deceptive practices; AI claims | | 15 U.S.C. § 1125 | False advertising | | 15 U.S.C. § 1681 | Consumer reporting; automated decisions | | 42 U.S.C. § 2000e-2 | Employment discrimination; disparate impact | | 15 U.S.C. § 6801 | Financial privacy; sector overlay | | 16 C.F.R. § 314.4 | Safeguards; vendor oversight | | European Union AI Act | Risk-tiered obligations | | Colorado artificial intelligence statute | Algorithmic discrimination duties | | NIST AI Risk Management Framework | Governance reference model |

Forms and Templates

AI procurement produces one artefact that governs everything, and it is the use case inventory rather than any contract: one row per deployed use case, with the business owner, the vendor and model, the data categories going in, whether output is customer-facing, the risk classification, the evaluation record, the human review requirement, and the review date. The Portfolio Inventory Template adapts to it directly, and its absence is why most companies cannot answer basic questions about their own AI footprint. The License Agreement Template supplies the grant, restriction, indemnity, and termination architecture that an AI vendor agreement needs, and reading it against a vendor's standard terms shows what has been left out — usually output ownership, training exclusion, and exit. The Assignment Agreement Template matters for the human authorship problem: where employees or contractors produce AI-assisted work, the assignment must reach their contributions, and the development record must show what those contributions were.

Related Toolkits and Checklists

The Technology Contracts Toolkit covers the underlying software contracting architecture into which AI terms fit. The AI Procurement Checklist runs the diligence and contracting steps in order. The Software Continuity and Escrow Toolkit covers the continuity dimension, which is acute where the vendor is a young company and the dependency is operational. The State Privacy Compliance Toolkit covers the profiling and automated decision provisions that reach AI use cases directly. And the Trade Secret Protection Toolkit covers the reasonable measures analysis that prompt handling can undermine.