AI Procurement Checklist: Use Case Review, Data Rights, Output Terms, Indemnity, Evaluation, and Monitoring

By Casey Scott McKay · 2025-10-23

This checklist procures a model service and then builds the controls that actually reduce the risk, which are not in the agreement. It opens by identifying the deployment shape, because the same contract term means different things for a hosted model, a retrieval deployment, and a fine-tuned one. It reviews the four definitions that determine what every operative clause reaches, drafts a training restriction covering fine-tuning, evaluation, abuse monitoring, and human review, and closes the aggregated-data carve-out that otherwise swallows it. It replaces the largely fictional output ownership negotiation with a covenant not to assert and provenance logging, reads the indemnity backwards from its carve-outs, and maps the subprocessor chain. It then gates use cases by consequence, writes the acceptable use policy that does the trade secret work, designs human review as the accuracy control, and stands up the evaluation suite that detects undisclosed model change.

IP and Technology > Information Technology | Checklist | Published 23 October 2025 - Updated 13 August 2026 | Casey Scott McKay - marksy.us

Summary. This checklist procures a model service and then builds the controls that actually reduce the risk, which are not in the agreement. It opens by identifying the deployment shape, because the same contract term means different things for a hosted model, a retrieval deployment, and a fine-tuned one. It reviews the four definitions that determine what every operative clause reaches, drafts a training restriction covering fine-tuning, evaluation, abuse monitoring, and human review, and closes the aggregated-data carve-out that otherwise swallows it. It replaces the largely fictional output ownership negotiation with a covenant not to assert and provenance logging, reads the indemnity backwards from its carve-outs, and maps the subprocessor chain. It then gates use cases by consequence, writes the acceptable use policy that does the trade secret work, designs human review as the accuracy control, and stands up the evaluation suite that detects undisclosed model change.

Keywords: deployment shape · definitions review · training restriction · aggregated data carve-out · covenant not to assert · provenance logging · indemnity carve-outs · training data provenance · model change notice · subprocessor mapping · human review disclosure · use case intake · consequence classification · regulated use routing · acceptable use policy · prohibited inputs · human review design · evaluation suite · shadow usage discovery · exit and deletion

How to use this checklist

| Phase | What it covers | |---|---| | 1 | Deployment shape | | 2 | The four definitions | | 3 | The training restriction | | 4 | The aggregated-data carve-out | | 5 | Output terms | | 6 | Provenance logging | | 7 | The indemnity, read backwards | | 8 | Training data provenance | | 9 | Model change | | 10 | Subprocessor mapping | | 11 | Human review disclosure | | 12 | The vendor question set | | 13 | Use case intake | | 14 | Consequence classification | | 15 | Regulated use routing | | 16 | The acceptable use policy | | 17 | Human review design | | 18 | The evaluation suite | | 19 | Shadow usage | | 20 | Exit and deletion | | 21 | Downstream obligations | | 22 | Ownership and review cycle |

Boxes marked [Gate] must clear before the service processes any company data.

The matter. A financial services company found its vendor's "Input" definition reached only material submitted through the interface, not through the retrieval connector its deployment plan required — and that the training restriction applied to a defined term excluding usage telemetry entirely.

Phase 1. Deployment shape

[ ] [Gate] Establish what is actually being bought, from the deployment team rather than the vendor.
[ ] Hosted general model. Prompts out, responses back, nothing persists. Risks: prompt confidentiality, output provenance, indemnity.
[ ] Retrieval augmentation. The customer's documents are indexed and supplied with each prompt. Confidentiality expands to the whole corpus; the indemnity's input carve-out becomes decisive; deletion must reach the index.
[ ] Fine-tuning. Customer data adjusts model weights. Nothing can be deleted by removing a record, and the training restriction is self-contradictory unless it distinguishes customer-dedicated tuning from general improvement.
[ ] Ask three questions: what data will the service see, how will it get there, and will anything be used to adjust the model.

Phase 2. The four definitions

[ ] [Gate] "Input" — broaden to any data made available to the service by or on behalf of the customer, however transmitted, including interfaces, application programming interfaces, connectors, integrations, and plug-ins.
- Trap. Limited to material submitted "through the interface," which excludes most enterprise data flows.
[ ] [Gate] "Output" — extend to intermediate representations, embeddings, indexes, summaries, and derived artifacts.
- Why. Ownership and indemnity both key off this term, and a narrow definition shrinks both.
[ ] "Customer Data" — confirm it includes usage telemetry, prompt metadata, and feedback signals if the training restriction keys off it.
[ ] "Service" — determine whether it means the model, the platform, or the vendor's business generally, since a restriction on improving "the Service" turns on it.
[ ] Apply the drafting test. Write one sentence describing what the vendor may do with a document an employee uploads to a retrieval integration. If the definitions do not answer it unambiguously, they are not finished.

Phase 3. The training restriction

[ ] [Gate] Prohibit use of Inputs, Outputs, and Customer Data to train, fine-tune, or improve any model other than one dedicated exclusively to the customer.
[ ] [Gate] Name the four carve-outs expressly: fine-tuning, evaluation and benchmarking, abuse and safety monitoring, and human review.
- Why. A restriction silent on these is narrower than the customer believes.
[ ] Bound abuse monitoring — a stated retention window, disclosed and accepted, after which inputs are deleted.
[ ] Confirm the service tier for every deployment, since consumer tiers usually train by default.
[ ] Record the privacy consequence. A vendor that trains is a controller as to that use under the state privacy statutes, which most processing riders do not contemplate. See the State Privacy Law Applicability and Readiness Checklist.
[ ] Record the confidentiality consequence. Material submitted to a service that trains has been disclosed, bearing on reasonable measures under 18 U.S.C. § 1839.

Phase 4. The aggregated-data carve-out

[ ] [Gate] Require irreversible de-identification, not merely aggregation.
[ ] Prohibit re-identification attempts.
[ ] Exclude reconstruction — the derived data must not permit reconstruction of any Input, Output, or customer-specific content.
[ ] State that the carve-out does not extend to training on customer-specific content in any form.
[ ] Understand why this matters. Almost every agreement contains this carve-out, and without these qualifiers it swallows Phase 3 entirely.

Phase 5. Output terms

[ ] Recognize what the standard clause does. "As between Customer and Vendor, Customer owns all Output" settles the vendor's position and confers nothing against the world.
[ ] Understand why. Copyright requires human authorship — the position in Thaler v. Perlmutter, with the patent analogue settled by Thaler v. Vidal under 35 U.S.C. § 101.
[ ] [Gate] Obtain a covenant not to assert, which does work the assignment cannot because it does not depend on any interest existing.
[ ] Obtain a warranty that no exclusive right in the same output has been granted to anyone else.
[ ] Obtain an acknowledgment that the customer may register copyright in its own contributions, with vendor cooperation under 17 U.S.C. § 201 and 17 U.S.C. § 204.
[ ] [Gate] Read the exclusivity disclaimer to the business. Nobody should build a brand asset on generated material assuming uniqueness.
[ ] Document human contribution for anything intended to be protected.

Phase 6. Provenance logging

[ ] [Gate] Log per generation: model identifier and version, Input, Output, requesting user, and timestamp.
[ ] Require the vendor to make it available and exportable, with a stated retention period.
[ ] Export on a schedule during the term, not at termination.
[ ] Retain for the applicable limitations periods.
[ ] Understand what depends on it. Every retrospective question — an infringement inquiry, an ownership question, a regulatory request, an incident investigation — is answerable only from this log.

Phase 7. The indemnity, read backwards

[ ] [Gate] Read the carve-outs before the grant.
[ ] Customer inputs. If the claim arises from what the customer supplied, the indemnity does not apply — and retrieval and fine-tuned deployments are mostly input-derived, so this can swallow the grant.
[ ] Modification. Editing the output frequently voids it, in tension with the human-contribution advice at Phase 5. Raise the tension explicitly.
[ ] Filters and safety features. Conditioned on specified controls remaining enabled. Confirm which, and confirm the deployment does.
[ ] Knowledge. Continued use after notice of a claim is excluded.
[ ] Trademark and publicity, frequently outside the grant — and exactly where generated brand-adjacent material and likenesses create claims. See the Name, Image, and Likeness Clearance Checklist.
[ ] Caps. An indemnity capped at fees paid is not protection against statutory damages under 17 U.S.C. § 504.
[ ] [Gate] Ask for one covered example and one excluded example. A vendor that cannot produce both has drafted a grant it does not understand.

Phase 8. Training data provenance

[ ] Accept that no warranty is obtainable. The fair use question under 17 U.S.C. § 107 is unresolved against Andy Warhol Foundation v. Goldsmith, Google v. Oracle America, and Authors Guild v. Google.
[ ] Obtain category-level disclosure — licensed, public, or scraped.
[ ] Obtain a representation of no injunction or pending order affecting the model's availability.
[ ] Obtain notice obligations if the model must be withdrawn or retrained.
[ ] Obtain continuity commitments for the deployment.
[ ] Allocate the residual risk by deployment choice, not by drafting.

Phase 9. Model change

[ ] Request version pinning with a stated availability period.
[ ] Request change notice with lead time proportionate to the validation burden.
[ ] Request a material change definition — model, weights, system instructions, or safety filtering.
[ ] Request a performance floor on an agreed test set.
[ ] Expect refusal on all of these, and treat the refusal as making Phase 18 mandatory rather than optional.

Phase 10. Subprocessor mapping

[ ] [Gate] Ask who actually operates the model, which is frequently not the contracting vendor.
[ ] Map the chain: model builder, cloud provider, safety filtering service, human reviewers, evaluation and monitoring providers.
[ ] Ask where inference runs, and whether it can be constrained to a region.
[ ] Require a current subprocessor list with change notice.
[ ] Require flow-down of confidentiality and processing terms.
[ ] Map the chain against existing privacy and confidentiality commitments, including any made to the customer's own customers.

Phase 11. Human review disclosure

[ ] [Gate] Ask directly whether human review of interactions is performed.
[ ] Ask by whom — employees or contractors — and under what confidentiality obligations.
[ ] Ask whether it can be disabled, and at what tier.
[ ] Require obligations no less protective than the agreement's.
[ ] Reflect it in the acceptable use policy.
- Trap. A policy permitting confidential material in prompts has not accounted for a person reading them.

Phase 12. The vendor question set

Send in advance of negotiation; written answers are worth more than a month of redlines.

[ ] Every use made of Inputs and Outputs, by service tier.
[ ] Every third party with access, with purpose and retention.
[ ] One covered claim and one excluded claim under the indemnity.
[ ] Training data at category level, and any injunction or pending order.
[ ] Model change notice, lead time, and version pinning.
[ ] Termination deletion — what, when, with what confirmation, including indexes, embeddings, and fine-tuned weights.
[ ] Human review — performed, by whom, under what obligations, and can it be disabled.
[ ] Inference region and whether it can be constrained.
[ ] Treat a refusal to answer in writing as an input to whether the use case proceeds.

Phase 13. Use case intake

[ ] [Gate] Require a completed intake form before approval, written by the requesting team.
[ ] The use case in one paragraph — problem, inputs, output, and who sees it.
[ ] Data inventory — categories, source systems, and whether any is personal data, sensitive, third-party confidential, or trade secret.
[ ] Deployment shape, vendor, and tier.
[ ] Review design — who checks the output, what they check, what happens on disagreement.
[ ] Disclosure — whether output will be labelled as generated.
[ ] The decision — approved, conditioned, or refused; named decision-maker; date; conditions stated as obligations.
[ ] Give it a two-day service level, or teams route around it and create shadow usage.

Phase 14. Consequence classification

[ ] Does the output inform a decision about a person?
[ ] Does it reach a customer or the public?
[ ] Does it enter a regulated process?
[ ] Does it become part of a product?
[ ] Each yes moves the request to a higher review track, and the first triggers Phase 15.
[ ] Record the classification, because it is the document a regulator asks for.

Phase 15. Regulated use routing

[ ] [Gate] Route any decision-about-a-person use case to sector counsel, not to procurement.
[ ] Check the deployer obligations under frameworks like Colo. Rev. Stat. § 6-1-1701, which attach to the customer regardless of the vendor agreement.
[ ] Check sector regimes: consumer reports under 15 U.S.C. § 1681b; financial under 15 U.S.C. § 6801; health under 45 C.F.R. § 164.502.
[ ] Check employment-adjacent uses separately, which should never arrive through procurement.
[ ] Confirm no capability claim exceeds what the deployment supports, since statements about the product are advertising claims under 15 U.S.C. § 45.

Phase 16. The acceptable use policy

[ ] [Gate] Write it before deployment.
[ ] Name the approved service and tier, and prohibit personal accounts and other services for company work.
[ ] Explain why — anything submitted leaves the company and may be stored, reviewed by a person, or used for training.
[ ] Name prohibited inputs specifically: personal data; trade secrets; source code outside an approved list; unreleased financials; third-party confidential material; regulated system records.
[ ] Name what is permitted, since a policy that only forbids leaves people guessing.
[ ] Scope the retrieval corpus to a defined document set rather than a whole drive.
[ ] Require output checking and generated-content labelling.
[ ] Name an escalation contact with a turnaround.
[ ] [Gate] Deliver it in person, once, with acknowledgment recorded. Reasonable measures under 18 U.S.C. § 1839(3) are practices, not documents.

Phase 17. Human review design

[ ] [Gate] Treat human review as the accuracy control, because no vendor warrants accuracy.
[ ] Design by consequence. Output informing a decision needs a reviewer who could have produced it; output drafting a first version needs a reviewer who will actually read it.
[ ] Define what the reviewer checks, rather than asking them to "review."
[ ] Define what happens on disagreement, including escalation.
[ ] Record the review — who, when, what changed.
[ ] Watch for review decay, where volume converts genuine review into rubber-stamping. Sample and audit.

Phase 18. The evaluation suite

[ ] [Gate] Build twenty to fifty tasks drawn from real usage, with expected outputs or an acceptance rubric.
[ ] Include adversarial cases — inputs that should be refused, historical error cases, and boundary cases for the approved use.
[ ] Include provenance-sensitive cases where the output should cite a source.
[ ] Run monthly, and after any vendor announcement.
[ ] Record results with the model version.
[ ] Define the failure threshold and the action in advance — re-validation, suspension, or escalation.
[ ] [Gate] Assign an owner. A suite nobody runs documents an intention that was not carried out.

Phase 19. Shadow usage

[ ] Accept that it exists, and that it is where confidentiality exposure concentrates.
[ ] [Gate] Provide a sanctioned alternative before prohibiting anything.
[ ] Discover what is in use — expense reports, network logs, and asking teams directly, which works better than a survey.
[ ] Bring significant tools under contract or block them.
[ ] Address contractors in engagement terms, prohibiting submission of company confidential material to unapproved services.
[ ] Measure success realistically — a sanctioned path good enough that the shadow path is not worth the friction.

Phase 20. Exit and deletion

[ ] Confirm prompts and configurations are the customer's work product, and strike any vendor claim to them.
[ ] Ask who owns fine-tuned weights and whether they are exportable. Usually not in usable form, which makes fine-tuning a lock-in decision.
[ ] [Gate] Require deletion of embeddings and indexes on termination, reaching backups and derived structures, with written confirmation and a deadline.
[ ] Export the provenance log on a schedule during the term.
[ ] Confirm the licence or covenant over output already in use survives termination.
[ ] Obtain transition assistance for a defined period at agreed rates.
[ ] Model the switching cost at procurement, since renewal leverage is near zero where the deployment cannot move.

Phase 21. Downstream obligations

[ ] Map what the customer has promised its own customers against what the vendor has promised it.
[ ] Check three mismatches: training restrictions, accuracy warranties, and indemnity scope. A customer cannot pass through more than it holds.
[ ] Resolve the mismatch before the downstream contract is signed.
[ ] In diligence, ask for vendor agreements with definitions and training restrictions; the use case inventory with approval records; the acceptable use policy and acknowledgments; provenance logs; evaluation results; and regulated-use sign-offs.
[ ] Price the switching cost where fine-tuning created lock-in, and the exposure from ungoverned use cases.

Phase 22. Ownership and review cycle

[ ] [Gate] Name one owner across legal, security, procurement, and the deployment team.
[ ] Monthly: run the evaluation suite; record results.
[ ] Quarterly: check the subprocessor list for changes; sample the human review for decay; review new use case intakes.
[ ] Annually: refresh the acceptable use policy; re-run shadow usage discovery; re-read the agreement against current deployment shape; confirm logging retention still covers the limitations periods.
[ ] On trigger: a new use case, a new vendor or tier, a change in deployment shape, a vendor model announcement, or any regulated-use proposal.
[ ] Report three numbers: approved use cases with completed intake records; evaluation runs completed on schedule; and identifiers of ungoverned services found in the last discovery sweep.

Outcome. The definitions review found "Input" limited to interface submissions, which did not reach the planned retrieval connector, and a training restriction keyed to a "Customer Data" definition excluding usage telemetry. Both were broadened. The training restriction was extended to fine-tuning, evaluation, abuse monitoring, and human review, with a disclosed thirty-day abuse-monitoring window accepted. The aggregated-data carve-out was qualified with irreversible de-identification and a no-reconstruction clause. No provenance warranty, version pinning, benchmark floor, or uncapped indemnity was obtained — all refused, as expected. The deployment design did the rest: two use cases approved, one refused and routed to sector counsel because it scored customer communications for risk; mandatory human review before send on the customer-facing use; an acceptable use policy naming prohibited inputs and scoping the retrieval corpus to a defined document set; and a forty-task evaluation suite run monthly, which detected an unannounced behaviour change at month five and triggered re-validation before anything reached a customer. Four days of legal effort on the agreement, six on the deployment design.

Phase 23. Model clause language

Starting points for Phases 2 to 6. Adapt them; keep the structure.

Definitions.

"Input" means any data, content, or material made available to the Service by or on behalf of Customer, however transmitted, including through the user interface, application programming interfaces, connectors, integrations, and plug-ins.

"Output" means any data, content, or material generated by the Service in response to an Input, including intermediate representations, embeddings, indexes, summaries, and derived artifacts.

[ ] "However transmitted" plus the enumerated channels closes the connector gap.
[ ] The Output tail is what makes ownership and indemnity reach retrieval artifacts.

Training restriction.

Vendor will not use Inputs, Outputs, or Customer Data to train, fine-tune, evaluate, benchmark, or otherwise develop or improve any model, service, or product, other than a model dedicated exclusively to Customer. This restriction applies to abuse and safety monitoring and to human review, except that Vendor may retain Inputs solely for abuse monitoring for no more than thirty days, after which they will be deleted.

[ ] The enumerated verbs close the four carve-outs vendors rely on.
[ ] A disclosed abuse-monitoring exception is better than a silent one.

Aggregated data.

Vendor may use data derived from Customer's use of the Service in aggregated and irreversibly de-identified form, provided such data does not include, and cannot be used to reconstruct, any Input, Output, or Customer-specific content, and Vendor will not attempt re-identification.

Covenant not to assert.

Vendor covenants not to assert against Customer, its affiliates, or its customers any right, title, or interest in or to any Output, and will not challenge Customer's use of Output on the basis of any right Vendor holds.

Provenance.

Vendor will make available to Customer, and Customer may export, a record for each generation comprising the model identifier and version, the Input, the Output, the requesting user, and the timestamp, retained for no less than [period].

Material change.

Vendor will give Customer no less than [period] prior written notice of any Material Change, meaning a change to the model, its weights, its system instructions, or its safety filtering that could reasonably be expected to alter Output for Customer's use cases.

[ ] Frequently refused; the refusal makes Phase 18 mandatory.

Phase 24. Rewrite reference

| Written | Rewritten | |---|---| | "Input means data Customer submits through the Service interface." | "...made available to the Service by or on behalf of Customer, however transmitted, including connectors and integrations." | | "Vendor will not use Customer Data for training." | "...to train, fine-tune, evaluate, benchmark, or otherwise improve any model," with abuse monitoring and human review named. | | "Vendor may use aggregated data." | "...aggregated and irreversibly de-identified... cannot be used to reconstruct... no re-identification attempts." | | "Customer owns all Output." | Retain, and add a covenant not to assert plus provenance obligations. | | "Vendor will indemnify Customer against claims that Output infringes." | Read the carve-outs; negotiate removal of the modification carve-out for ordinary editing and a defined list of required filters. | | "Vendor may update the Service from time to time." | Add a Material Change definition and a re-evaluation right, or accept and build the evaluation suite. | | "Vendor will delete Customer Data on termination." | "...including embeddings, indexes, and fine-tuned weights, from production and backups, within [period], with written confirmation." | | Confidentiality clause silent on human review | Human review disclosed, bounded, and covered by obligations no less protective than the agreement's. |

[ ] Run every vendor form through this table before the first call.

Phase 25. Evidence and record request

Assemble during the term, not at the point of need.

[ ] The executed agreement with all definitions, orders, and incorporated policies as they stood on each relevant date.
[ ] The vendor's written answers to the Phase 12 question set.
[ ] The subprocessor list, every version, with change notices received.
[ ] Provenance logs, exported on schedule.
[ ] Use case intake forms and approval decisions, with conditions.
[ ] Consequence classifications and any sector counsel sign-offs.
[ ] The acceptable use policy, every version, with acknowledgment records.
[ ] Human review records — who reviewed what, when, and what changed.
[ ] Evaluation suite results, by model version, with any threshold failures and the action taken.
[ ] Shadow usage discovery results and remediation.
[ ] Deletion confirmations on any terminated deployment.
[ ] Downstream commitments made to the customer's own customers, mapped against vendor terms.

Why this belongs here. Almost every retrospective question — an infringement inquiry, a regulatory request, a customer complaint about an output, an ownership question in diligence — is answerable only from the provenance log and the approval records, and neither exists unless someone required them at procurement.

Phase 26. Use-case-type boxes

Run the base checklist, then the boxes for the use case in play.

Internal document summarization.

[ ] Scope the retrieval corpus to a defined document set, not a whole drive.
[ ] Confirm the corpus contains no third-party confidential material received under obligation.
[ ] Confirm index deletion reaches the corpus on termination.
[ ] Lower review burden justified; logging still mandatory.

Customer-facing drafting.

[ ] Mandatory human review before send, by someone who could have produced the output.
[ ] Generated-content labelling decision made explicitly.
[ ] Trademark and publicity indemnity gap assessed, since output may reference third-party brands or people.
[ ] Advertising claim review where the output makes product statements under 15 U.S.C. § 45.

Code generation.

[ ] Confirm whether the model was trained on code under copyleft terms, and what the vendor will say about it.
[ ] Confirm source code is on the approved-input list, or is not.
[ ] Run generated code through the open source compliance process, since provenance is unknown. See the Software Copyright Checklist.
[ ] Log the generation alongside the commit.

Search and knowledge retrieval.

[ ] Require citation to source in the output, and test it in the evaluation suite.
[ ] Confirm access controls flow through — a retrieval system that ignores document permissions is a data breach waiting to be reported.
[ ] Confirm deletion requests reach the index.

Decision support about a person.

[ ] [Gate] Route to sector counsel; do not approve through procurement.
[ ] Map deployer obligations under Colo. Rev. Stat. § 6-1-1701 and the applicable sector regime.
[ ] Document the human decision-maker's actual role, since a rubber-stamp is not human review.
[ ] Assess adverse action notice requirements where they apply.

Voice, image, or likeness generation.

[ ] Publicity rights analysis before any output depicting a person. See the Digital Replica Checklist.
[ ] Confirm the indemnity's publicity carve-out and price the gap.
[ ] Consent and licensing for any real person's voice or likeness.

Phase 27. The ninety-day standing-up

[ ] Days 1-5. Deployment shape identified. Vendor question set sent with the request for proposal.
[ ] Days 5-12. Definitions review. Vendor answers assessed. Use case intake completed by the requesting team.
[ ] Days 10-20. Consequence classification and routing. Regulated uses to sector counsel.
[ ] Days 15-30. Training restriction, aggregated-data carve-out, covenant not to assert, provenance obligations, and indemnity carve-out negotiation.
[ ] Days 25-35. Subprocessor chain mapped against existing privacy and confidentiality commitments, including downstream ones.
[ ] Days 30-45. Acceptable use policy drafted, approved service and tier confirmed, delivery scheduled.
[ ] Days 40-55. Human review design agreed with the business owner. Logging requirements specified to the deployment team.
[ ] Days 50-70. Evaluation suite built with the requesting team; baseline run recorded; owner named.
[ ] Days 65-80. Shadow usage discovery run. Significant tools brought under contract or blocked.
[ ] Days 80-90. Downstream commitment mapping. Review cycle calendared. Baseline numbers reported.

What is deliberately deferred. A comprehensive inventory of every model-adjacent feature in every product the company already buys. That is a long tail with diminishing returns; prioritise the deployments that see confidential material or produce customer-facing output.

Phase 28. Where the exposure actually sits

Ranked, because the ranking is not what a contract review would suggest, and the ranking should drive where the effort goes.

[ ] Highest: an ungated use case informing a decision about a person. Sector rules and deployer obligations apply regardless of the agreement, and no indemnity reaches them.
[ ] High: confidential material in prompts, particularly through consumer-tier services used without approval. Disclosure undermines the reasonable-measures element under 18 U.S.C. § 1839.
[ ] High: unlabelled generated content in customer-facing material, a deception question under 15 U.S.C. § 45 and increasingly a disclosure requirement.
[ ] Moderate: output infringement, which the indemnity nominally addresses and which therefore receives disproportionate attention.
[ ] Moderate: personal data in inputs, engaging the state privacy statutes and a controller analysis where the vendor trains.
[ ] Moderate: accuracy failures reaching a customer, controlled by review design rather than by any contract term.
[ ] Lower: ownership of output — genuinely uncertain, rarely consequential, and the term that consumes the most negotiating time.
[ ] Lowest: training data provenance — real, unallocatable, and outside the customer's control, which is a reason to manage it by deployment choice rather than by pursuing a warranty no vendor will give.
[ ] [Gate] Reallocate effort to match this ranking. A legal team that does so will reduce more risk in a week than in a month of redlines.

Phase 29. What to accept, push on, and walk from

[ ] Accept without argument: no accuracy warranty; a general liability cap at fees paid, provided the indemnity is uncoupled; a published rather than negotiated subprocessor list; deprecation on notice; bounded and disclosed abuse monitoring.
[ ] Push hard, and usually win: the Input and Output definitions; a training restriction naming fine-tuning, evaluation, abuse monitoring, and human review; the irreversibly-de-identified qualifier on aggregated data; a covenant not to assert; confidentiality flow-down to human reviewers; deletion confirmation with a deadline.
[ ] Push, and usually lose: version pinning; a performance floor; any training data provenance warranty; an uncapped indemnity; meaningful change notice. Ask anyway — the refusals identify which customer-side controls are mandatory.
[ ] [Gate] Walk from, or refuse the use case: a vendor that will not answer the training question in writing; a vendor that cannot say who has access to inputs; an indemnity whose carve-outs leave nothing inside the grant, where the vendor cannot describe a covered claim; a consumer-tier service proposed for personal or confidential data; and any regulated use case where the vendor cannot support the deployer obligations the sector imposes.
[ ] Frame the outcome honestly for the business. Most negotiations end with substantially the vendor's paper on the terms that cannot move, having improved the four or five that can — which is a good outcome, provided the effort saved goes into gating, the policy, and the evaluation suite.

Phase 30. Three sentences worth saying

[ ] To procurement, at the outset. "The agreement is not the deliverable. Send the vendor these eight questions with the request for proposal, and give me ten minutes with whoever knows how the data will actually reach the service."
[ ] To the business owner, at approval. "No vendor warrants that the output is correct, and the agreement says the output may not be unique. Your review design is the accuracy control, and you should not build a brand asset on generated material."
[ ] To everyone who will use it, once and in person. "Anything you put into this leaves the company. Here is what you may not put in, and here is who to ask when you are not sure."
[ ] Repeat the third one annually, and after any change of approved service or tier. It is the only control in this checklist that depends on people rather than on systems, and it is the one that decays fastest.

Key Authorities at a Glance

| Authority | Proposition | |---|---| | 17 U.S.C. § 102 | Originality and authorship | | 17 U.S.C. § 106 | Rights implicated by training and output | | 17 U.S.C. § 107 | Fair use, unresolved for training | | 17 U.S.C. § 201 | Ownership vests in the author | | 17 U.S.C. § 204 | Writing required to transfer | | 17 U.S.C. § 504 | Statutory damages | | 17 U.S.C. § 512 | Safe harbor for hosted output | | Andy Warhol Foundation v. Goldsmith | Transformative purpose narrowed | | Google v. Oracle America | Intermediate copying | | Authors Guild v. Google | Search index reasoning | | Thaler v. Vidal | Inventor must be a natural person | | Thaler v. Perlmutter | Human authorship for copyright | | 35 U.S.C. § 101 | Patentable subject matter | | 18 U.S.C. § 1839 | Reasonable measures; disclosure | | 18 U.S.C. § 1836 | Misappropriation claim | | 15 U.S.C. § 45 | Deceptive capability claims | | Colo. Rev. Stat. § 6-1-1701 | Deployer obligations | | Cal. Civ. Code § 1798.140 | Controller and processor definitions | | Cal. Civ. Code § 1798.121 | Sensitive data limits | | 15 U.S.C. § 6801 | Financial sector constraints | | 45 C.F.R. § 164.502 | Health information constraints | | 15 U.S.C. § 1681b | Consumer report uses | | 15 U.S.C. § 1125 | Trademark exposure from output |

The five things people get wrong

Negotiating the agreement without knowing the deployment shape. A restriction saying the vendor will not train on customer data is coherent for a hosted model, needs qualification for a retrieval deployment, and is self-contradictory for fine-tuning. Most agreements are drafted for the first and signed for the third.

Accepting the definitions. "Input" limited to interface submissions excludes connectors and integrations, which in an enterprise deployment is most of the material at risk — and every operative term reaches only what the definitions permit.

Spending weeks on output ownership and none on provenance logging. The ownership clause settles the vendor's position and confers nothing against the world, because raw machine output is unlikely to be protectable. The log of model, version, prompt, and timestamp is what makes every later question answerable.

Reading the indemnity before its carve-outs. If the claim arises from customer inputs, or the output was edited, or a filter was disabled, the grant frequently does not apply — and enterprise deployments are mostly input-derived.

Treating this as a contract review. The largest exposures are deployment decisions — which use cases, which inputs, which review layer — and the smallest are drafting decisions. A perfectly negotiated agreement with an ungated deployment is worse than a mediocre agreement with a well-designed one.