Renata Villanueva is a contracting officer at a federal agency procuring its first large AI system, a document-classification platform meant to triage 400,000 Freedom of Information Act requests a year. The vendor's standard contract arrived: 38 pages, polished, and quietly devastating. It claimed ownership of any data the agency fed the model. It capped the vendor's total liability at three months of fees, about $90,000, against a system that, if it mishandled sensitive records, could cost the agency far more than money. It allowed the vendor to change the model "from time to time" with no notice. And it had no exit clause; leaving meant abandoning two years of agency data trapped in the vendor's format. Renata had one negotiation to fix all of it. This lesson is the playbook she used.

Many government AI acquisitions fail not because the technology was bad but because the contract was. Unclear data ownership meant the agency could not migrate to another vendor. Vague performance commitments meant the vendor could claim it met its obligations while the system underperformed. A missing exit clause meant a bad relationship that could not be ended without enormous cost. Contract terms decide whether an acquisition succeeds or becomes an expensive trap. What follows is what to negotiate, why each term matters, and how to structure language that protects the agency while staying realistic about how vendors actually make money.

Why AI Contracts Are Not Ordinary IT Contracts

Renata's first instinct was to treat this like buying any software. That instinct is the trap. Traditional software is static: you buy it, you install it, it does the same thing tomorrow. AI systems are dynamic. They learn, they degrade, they require ongoing tuning, they need monitoring. That difference forces the contract to address dimensions traditional software contracts never touch: data ownership, model updates, performance degradation over time, and fairness monitoring after deployment. A clause set written for a finished product cannot govern a system that is still changing.

Three properties of AI reshape every clause. First, it feeds on your data, and that data may be sensitive, statutory, or constituent-owned, which makes control of it a central fight rather than a boilerplate matter. Second, it changes over time; the model the vendor demonstrated is not necessarily the model running next quarter. Third, it can be wrong in consequential ways, misclassifying a record or contributing to a denied benefit, which makes the liability question concrete rather than theoretical. Government agencies also hold data commercial buyers rarely handle: benefits applications, clearance information, tax records.

There is a fourth asymmetry that is easy to miss until it is too late. AI vendor relationships are often unequal in power. A vendor can end up controlling the system so completely that exiting requires rebuilding from scratch. Vendor lock-in is a known and recurring problem in AI acquisition, and contract negotiation is the stage at which you have leverage to reduce it. After signature you are negotiating from inside the trap, which is why the terms below are worth more attention than the demo that sold the system.

The Government Overlay

Government procurement operates inside a statutory framework. Federal acquisition runs on the Federal Acquisition Regulation (FAR) and, for defense, the Defense Federal Acquisition Regulation Supplement (DFARS). OMB guidance establishes policy requirements on top of that, and agency regulations add further layers. A contract that is perfectly sound commercially can still fail federal requirements. Which protections you actually hold depends on which provisions are incorporated into your contract, which is exactly why a contracting officer has to know what to invoke rather than assuming the framework operates on its own.

Government contracts are also public in a way commercial ones are not. If something goes wrong, the contract terms become evidence. Did you negotiate adequate performance guarantees? Are the exit procedures clear? Is data ownership unambiguous? Those questions arrive with an audience when a Congressional committee asks why an AI acquisition failed or an inspector general examines the acquisition. And government data carries public obligations of its own, with citizens holding rights under FOIA, the Privacy Act, and similar authorities. The contract has to protect public data while still letting the vendor operate, a balance commercial contracts routinely ignore.

Used well, the acquisition framework is not only a constraint on the contracting officer. It is authority. When the vendor pushed back on data rights, "the government's data rights are governed by the FAR, and this language conforms to it" was a far stronger position for Renata than "we would prefer different terms." The vendor's legal team is optimizing the document for the vendor's interests, which is their job. Nobody optimizes it for the agency's interests unless the agency does.

Battleground One: Data Rights and Ownership

This is where government AI contracts most often go wrong, and it is the clause to win first, because data once used to train a model cannot be un-used. The vendor's draft claimed broad rights to agency data and, worse, the right to use it to train its commercial models. Renata's redline established that the agency retains full ownership of all input data, output data, and derived data; that the vendor gets a narrow license to process it solely to deliver the contracted service; and that no agency data may be used to train, tune, or improve any model serving other customers.

Written out at the level of detail a contract needs, initial ownership means government-provided input data such as citizen applications and historical decisions remains government property, the government retains the right to copy, transfer, back up, and migrate its own data, the vendor may not use government data for any purpose other than operating the contracted system, and the vendor may not use it to improve competing products or to sell services to competitors. All of this seems obvious stated plainly. It gets buried in vendor standard contracts precisely because it is obvious and therefore rarely read closely.

Derived data needs three categories distinguished rather than one. The trained model itself, meaning its weights and parameters, is typically vendor property with the government holding license rights. Training data used to build the model is typically vendor property when the vendor supplied it and government property when the government supplied it. Aggregated performance metrics, including accuracy, bias, and fairness reports, should be government property, and the vendor may not restrict government access to evaluation results. The line being drawn is between protecting genuine vendor intellectual property and preserving the government's ability to understand how its own system behaves.

Data residency is critical for many agencies and is frequently left blank. Where is the data stored: on premises, in the vendor's cloud, in a third party's cloud? If the vendor uses cloud infrastructure, which provider and which regions? The arrangement must meet the agency's residency requirements, since government data often cannot leave certain jurisdictions. Ask who has access while the data sits with the vendor, including vendor employees, subcontractors, and law enforcement acting under subpoena. Ask how often data is backed up, by whom, where, and who owns the backups. Each of those is a question with a contract answer or a gap.

Deletion and retention closes the loop. At contract end the vendor must delete government data or return it, on a defined timeline: immediately, within 30 days, within 90 days. The contract has to say which. Then it has to reach the copies that people forget: backups, redundant copies, data sitting in the vendor's logs and monitoring systems. The vendor must certify completion of deletion in writing. Treat that certificate as what it is: a representation you can enforce against later, not independent proof that every copy is gone, which is why the clause naming the backups and logs matters more than the certificate itself.

Finally, audit rights make the rest of the section verifiable. The government, or auditors it authorizes, may audit the vendor's data-handling practices, physically inspect facilities where government data is stored, and review the vendor's security logs and access records for government data. The vendor's own security contractors and subcontractors cannot block government access to audit results. Expect annual audits, and more often if there is a security incident. A data-rights clause without an audit right is a promise you have no mechanism to check.

Battleground Two: Intellectual Property

The tension here is real and worth naming honestly: the vendor needs to protect what makes its product a product, and the government needs to keep operating. Vendors typically own the base model, the architecture, and the training methodology, which is their competitive advantage. The government receives a perpetual license to use the model for the contracted purpose and cannot reverse-engineer or extract the model to compete with the vendor, which is a reasonable limit. What the government must secure is the right to continue using the model if the vendor relationship ends, and the right to use it with different data where agency purposes require it.

Custom development needs its own treatment. If the contract includes custom model development, define who owns the resulting model before work starts. Where the government funds development, the government should own the resulting intellectual property or hold an exclusive perpetual license; the line that matters is that improvements funded by the agency belong to the agency. Where the vendor funds development, the vendor may own the IP while the government retains the licenses it needs. Document what happens to custom development if the contract ends, and include background IP language acknowledging that the vendor can reuse methods and architectures learned on your project elsewhere.

Data science work product is the category most often surrendered by accident. The government should own the evaluation results, bias audits, and fairness reports, because those documents feed oversight and governance rather than product development. The vendor may own its proprietary testing methodology while the government owns the results of testing on government data, and the government retains the right to share bias and fairness audit results with oversight bodies including GAO and Congress. This is not an attempt to take vendor IP. It is the government's right to understand what it is buying with public money.

Export control deserves a line in the file even when it looks inapplicable. AI systems trained on certain data or built with certain algorithms can be export-controlled. If the system might cross a border, for example when a government scientist collaborates internationally, plan for it in the contract rather than discovering it later. Make the vendor responsible for export compliance where the system includes controlled IP. What you are avoiding is the surprise notification, months into operation, that the vendor was export-restricted all along.

Battleground Three: Liability and Indemnification

The $90,000 cap was the most dangerous term in the document. A liability cap limits what the vendor owes if its system causes harm, and three months of fees against a system handling sensitive records is not risk allocation. It is a transfer of risk to the taxpayer. Renata negotiated a tiered structure instead: a higher general cap, anchored in her opening at 24 months of fees, plus uncapped liability for data breaches, willful misconduct, and violations of law. Vendors resist this, and the breach carve-out is the one to hold the line on. As a reference point, a general cap around 12 months of fees, or a stated floor amount where that is greater, is a common commercial shape.

Performance failure needs its own remedy chain. A specific service-level agreement defines acceptable performance; the contract then has to say what happens when accuracy drops below the committed level, whether that means vendor credits, fee reduction, a right to terminate, or all three. It also has to cover slow degradation, where performance is fine at launch and declines quietly afterward, which is the failure mode most likely to go unremedied because no single day looks bad enough to escalate. Include remediation timelines: if performance drops, the vendor has 30 days to fix it or the government can terminate.

Security breaches carry the most asymmetric consequences. The vendor is liable for security failures caused by vendor negligence, as distinct from government negligence. The vendor must notify the government within 24 hours of discovering a breach. The vendor bears the cost of breach notification where state privacy laws require it. The vendor maintains cyber liability insurance, typically in the range of $5 million to $10 million for government contracts. And the liability cap must not be written so that it prevents recovery of data breach costs, which is the whole point of carving breach out of the cap in the first place.

Fairness and bias belong in the liability section, not only in the governance section. The vendor warrants that the system meets the fairness standards documented at contract signing. If a post-deployment audit reveals material fairness violations, the vendor is responsible for remediation, and the government holds a right to terminate if the violations cannot be remedied. Where the system causes a civil rights violation and a citizen sues, the contract should indemnify the government. This is one of the terms vendors are least accustomed to seeing, which is a reason to raise it early rather than in the final round.

Third-party IP infringement is the more familiar indemnity and should not be dropped in favor of the newer ones. The vendor warrants that the system does not infringe third-party patents, copyrights, or trade secrets; indemnifies the government against infringement claims and related costs; and is responsible for defending the government if it is sued for infringement. The standard exception applies: if the government modifies the system and the modification causes the infringement, that is the government's responsibility. Note also that the cap on the vendor's liability should not apply to the government's indemnification claims or to data protection claims.

Battleground Four: Service Levels That Bind

The vendor's draft promised "commercially reasonable efforts," which is a phrase that means whatever the vendor later says it meant. Renata replaced it with numbers: an uptime commitment, a defined accuracy floor for classification with a quarterly measurement method, response times by support tier, and service credits when targets are missed. An SLA without a financial consequence is a wish. The measurement method matters as much as the number, because an undefined measurement period lets a vendor choose the window that makes the result look best.

Availability should state the target and the period. Government systems commonly need 99.5% availability during business hours, or 99.9% where round-the-clock operation is required. Say whether uptime is measured monthly, quarterly, or annually. Say that planned maintenance does not count against uptime, and make the vendor responsible for infrastructure redundancy and failover. Performance needs the same treatment: a latency requirement expressed as a percentile, for example 95% of requests processed within a specified number of seconds, and a throughput figure the system must sustain at peak, both tested under realistic load rather than in a quiet lab.

Support response times should be tiered by severity with both a response clock and a resolution clock. A Severity 1 issue, meaning the system is completely down, gets a response within 1 hour and resolution within 4 hours. Severity 2, a degraded system, gets a response within 4 hours and resolution within 1 business day. Severity 3, a minor issue, gets a response within 1 business day. One clause carries more weight than the numbers: the government defines severity. If the vendor can downgrade your incident, every other number in the tier table is negotiable after the fact.

Escalation and remediation give the SLA teeth. Name your primary contact, the vendor manager the issue escalates to if the primary contact does not respond, and the vendor executive sponsor above that, with a clear timeline at each level. For remediation, service credits of 5% of monthly fees where uptime falls between 99% and 99.5%, and 10% where it falls below 99%, give the vendor a reason to care. Add a right to terminate without penalty if uptime is below 95% for two consecutive months, and a right to engage third-party support if the vendor cannot meet the SLA. Service credits must not cap the government's right to terminate.

Battleground Five: Exit and Transition

The missing exit clause was a slow-motion hostage situation. Renata added a data portability and transition assistance clause: on termination for any reason, the vendor must return all agency data in a documented, non-proprietary format within 30 days, provide reasonable transition support to a successor, and certify deletion of agency data from its systems afterward. Behind that sits the more basic right: the government can terminate at any point rather than only at renewal, without needing to show cause, on a notice period of 30 to 90 days, with shorter being better for the government.

Be precise about what an exit right does. It is a contractual commitment you can hold a vendor to. It is not a technical mechanism that makes the system portable. A vendor can comply fully with a termination clause and still leave you with data in a format nobody else ingests, a model you cannot run, and staff who only know the old interface. That is why the transition clauses have to be written alongside the termination right: the vendor must cooperate in transitioning to an alternate system or back to a manual process, train government staff on system operation where needed, provide documentation of the system, models, and configuration, keep the system running during the transition period, typically 30 to 60 days, and handle data extraction and delivery in the agreed format.

Data portability then gets its own specifics so it cannot be satisfied nominally. The government receives a copy of all government data at contract end, in a standard format such as CSV or JSON rather than a vendor proprietary format, extracted and delivered at no additional cost, within a maximum of 30 days, with the vendor certifying that all government data has been delivered. Model transition is harder and the contract should offer alternatives: the vendor provides model weights where feasible, or a perpetual license to run the model at no additional cost, or documentation sufficient for the government to rebuild a functionally equivalent model. What is feasible genuinely depends on the architecture, and some models transfer far more easily than others.

Competitive restrictions close the back door. The vendor cannot use government data or work product to compete with the government. It cannot advertise that it built the system for your agency without permission. It can learn from the experience, which is unavoidable and reasonable, but it cannot transfer specific government insights to competitors, on a non-compete period typically running 1 to 2 years after contract end. Note how this interacts with the no-training restriction: the promise not to train on your data binds the service the contract names, so if the vendor moves you to a differently named tier or product, confirm in writing that the restriction moved with you.

Battleground Six: Model Change and Transparency

The "change from time to time" clause meant the agency could be running a different, untested model with no warning. Renata required advance written notice of material model changes, the agency's right to test before changes apply to production, and documentation of model version, training-data provenance at a defined level, and known limitations. This is the clause that distinguishes an AI contract from a software contract most sharply, because in ordinary software a silent backend change is a patch, while here it can alter which records get classified as exempt.

Notice is only useful if the agency does something with it. Pair the notice requirement with a named recipient, a testing window long enough to run your acceptance suite, and a documented decision about whether to accept the change. Otherwise the notice arrives in a shared inbox, nobody has an obligation to read it, and the contractual right converts into an email trail proving the agency was told. The right to test is the substance; the notice is the trigger.

Verification: Monitoring and Audit Rights

Everything above is a promise until you can measure it. Performance monitoring gives the government, or a contractor acting for it, the right to monitor system performance metrics, with the vendor providing a real-time or near-real-time dashboard covering uptime and performance, a monthly performance report documenting SLA compliance, and disclosure of issues, incidents, and concerning trends. Fairness monitoring requires the vendor to run quarterly fairness audits against metrics the government defines, deliver results in writing, and explain root cause and remediation when metrics degrade, with the government retaining the right to commission an independent third-party fairness audit.

Security and compliance audits work the same way at a different layer. The government may engage a third party to audit the vendor's security practices, and the audit may include penetration testing with notice, security assessment, and code review; the vendor must cooperate and cannot refuse access. Audit results are shared with the government rather than published, unless a breach occurs. Separately, the government or an inspector general may audit compliance with the contract terms themselves, inspecting facilities, reviewing documentation, and interviewing vendor staff, with the vendor required to maintain records sufficient to demonstrate compliance. Expect annual audits and special audits when concerns arise.

Budget for this rather than assuming it is free. The government pays for its own monitoring, while the dashboards and reports the vendor must furnish are part of the contract cost. Third-party fairness and security audits are typically paid for by the government and should be in the acquisition budget from the start. The vendor is responsible for its own staff time in cooperating. An audit right nobody funds is exercised once, in the year after something goes wrong.

Running the Negotiation

Renata's tactical move was to separate the six battlegrounds into walk-away terms and tradeable terms before she sat down. Walk-aways: agency data ownership, the no-training restriction, uncapped breach liability, and the exit and data-return clause. These protect against irreversible harm. Tradeables: the exact uptime percentage, the precise general liability multiple, the length of the notice period. Knowing which was which let her concede gracefully on the tradeables to win the walk-aways, and signaled to the vendor that she knew the difference, which changed how the rest of the conversation went.

A handful of principles generalize beyond her file. Have templates ready so you are proposing language rather than reacting to it. Identify your non-negotiables before the first meeting, not during it. Understand what vendors actually care about, usually term length, scope, and exclusivity, and trade against those deliberately: a vendor may accept better exit terms in exchange for a longer term. Get your legal team involved early rather than at signature. Build monitoring and measurement into the document itself. Plan the exit before the contract starts. And document everything, because a verbal assurance loses to contract language every time.

Be collaborative but firm, and explain why terms matter rather than simply asserting them. Some vendors will push back, and part of the skill is recognizing a reasonable compromise. But treat refusal itself as information. A vendor that will not clarify data ownership, will not grant audit rights, and will not commit to measurable performance is telling you something about its confidence in its own product and practices, and it is telling you before you sign rather than after.

A Usable Artifact: The AI Contract Redline Checklist

Take this into any AI procurement negotiation. For each term, know your walk-away position before the meeting rather than discovering it under pressure at the table.

The Outcome

Renata did not win every point. She conceded 99.5% uptime instead of her opening 99.9%, and an 18-month liability multiple instead of 24. But she won all four walk-aways: the agency owned its data, the vendor could not train on it, breaches were uncapped, and the agency could leave with its data intact. The negotiation took three sessions. The protection it bought will outlast the contract, and it will outlast Renata, which is the actual test of contract work in government.

Anti-Patterns

• Accepting the vendor's standard contract as a starting point you cannot move. Vendor standard contracts optimize for vendor protection, because vendor legal teams wrote them for that purpose. The result is vague data rights language, high termination penalties, minimal audit rights, and unclear exit procedures. Expect to negotiate. Bring the government's contract template even in simplified form, state your non-negotiables plainly, and know what you are trading.
• Deferring data rights because they are less interesting than model performance. Data rights sit in legal boilerplate and are easy to postpone. The bill arrives after deployment, when the agency discovers it cannot migrate because the language is ambiguous, or when the vendor asserts an ongoing right to use government data after the contract ends. Have counsel draft a detailed data rights section, negotiate residency, specify deletion, and require certification of data handling practices.
• Vague performance SLAs. When the contract defines good performance loosely, the vendor claims compliance while the system underperforms. "Reasonable availability" and "best efforts" survive a system that is down two days a month. Define measurable targets with a stated measurement period, attach service credits, add a right to terminate for repeated failure, and require transparent real-time reporting.
• Long lock-in terms bought with a discount. A multi-year commitment priced attractively becomes two more years at full cost when the system disappoints. Insist on a right to terminate without cause after the first year on a short notice period. Flexibility costs money, because vendors price short-term risk, and a shorter term is still better than a long one with termination penalties.
• Leaving security and compliance to a promise instead of a clause. Contracts that do not address FISMA, FedRAMP, audit rights, or security incident response produce the same story every time: the system deploys, the security audit finds gaps, and the vendor says it did not understand the requirement. Have the security team review before signature, require documented practices rather than assurances, require certification or equivalent, write incident response procedures into the contract, and budget for ongoing assessment.
• Treating a security certification as a data-use restriction. A FedRAMP authorization speaks to the security posture of an environment that has been assessed and authorized. It says nothing about what the vendor may do with your data inside that environment. If you need a no-training restriction, a residency requirement, or a deletion obligation, each has to appear as its own contract term. Reading a compliance badge as consent management is one of the most common substitutions in AI procurement.
• Believing an exit clause makes the system portable. An exit right is a commitment you can enforce, not a technical property of the system. Without the transition, format, documentation, and model-continuation clauses beside it, a vendor can honor the termination clause exactly and still leave you unable to operate. Judge your exit position by asking what you would actually be running 90 days after termination, not by whether the clause exists.
• Reading a no-training promise as broader than the words. A commitment that agency data will not train the vendor's models applies to the service the contract covers. It does not automatically follow you into a differently named product tier, a newly acquired subsidiary, or a successor service, and it is not the same as a commitment about retention or about subcontractor access. Get the covered services named, and re-confirm in writing at every renewal, migration, or rebrand.
• Accepting a deletion certificate as verification. Certification is an attestation you can act on if it turns out to be false. It is not an inspection. The clauses that make it meaningful are the ones naming backups, redundant copies, logs, and monitoring systems, together with the audit right that lets you check. A certificate covering only the primary system is technically accurate and practically empty.

Practice Prompts

1. Build your term list. For an AI acquisition your agency is contemplating, identify the ten contract terms that matter most across five goals: protecting government data and privacy, ensuring your right to operate the system long-term, holding the vendor accountable for performance, enabling exit if the relationship fails, and protecting against security breaches or civil rights violations. For each, write what the contract should say, even if it is only two or three sentences.
2. Redline a hostile draft. A vendor's standard license agreement includes: the vendor retains all data and may use it for system improvement; the government has limited termination rights and must give one year of notice; the vendor is liable only for direct damages, capped at one month of fees; the vendor owns all models, source code, and documentation; and performance is measured by vendor-selected metrics reported quarterly. For each clause write what you would propose instead, then mark where you would compromise and where you would not.
3. Draft the SLA. Write specific, measurable service levels for an AI system your agency is acquiring, covering availability, performance in latency and throughput, support response times by severity, remediation procedures, and the service credits or termination rights that attach to non-compliance. State the measurement period for every number.
4. Plan the exit. Assume the contract ends and you must transition to an alternate vendor or back to a manual process. Define the termination notice period, the transition period duration, the data migration process and timeline, the documentation and training the vendor must provide, the vendor's ongoing responsibilities during transition, and the final payment structure, including whether the vendor discounts the final month on early termination.
5. Write the data clause. Draft contract language covering government data ownership and retention rights, the vendor's data security obligations, data residency requirements if your agency has them, breach notification procedures specifying what is reported, when, and to whom, audit rights for the government to inspect data handling, and the data deletion or return procedure at contract end.

Reflection

Take an AI contract your agency holds or expects to negotiate. What are your genuine non-negotiables, and could you state them in one sentence each to a vendor tomorrow? What would happen to your agency if this vendor went out of business, and is the contract clear about transition in that scenario rather than only in a voluntary termination? Which data security terms matter most to you, and are they actually in the document or only in the proposal? How would you measure whether the vendor is meeting its service levels, and who does the measuring? If you wanted to switch vendors after two years, what specifically would you have to rebuild? And what are you willing to trade to secure better terms on the things you cannot afford to lose?

Glossary

• Indemnification. The vendor agrees to defend and compensate the government against specific liabilities such as IP infringement, security breach, or civil rights violation. In effect the vendor insures the government against those risks.
• Perpetual license. The right to continue using something after the contract period ends. Critical in government acquisitions, where you want the right to keep running a model after the vendor relationship is over.
• Service level agreement (SLA). The contract section that defines acceptable performance numerically, including uptime targets, performance metrics, support response times, and remediation procedures.
• Service credits. Financial reductions the vendor owes when it misses an SLA target. They create an incentive; they are not a substitute for a termination right.
• Termination for cause. Ending the contract because the vendor failed to meet its obligations, through poor performance, a data breach, or similar. Typically carries no penalty to the government.
• Termination without cause. Ending the contract for convenience rather than fault. Usually requires a notice period, but the government holds the right unilaterally.
• Transition services. The support the vendor must provide during hand-off to an alternate vendor or to a manual process, including documentation, training, data migration, and continued operation through the transition period.
• Vendor lock-in. The situation where switching to an alternate vendor is prohibitively costly or impossible because of contract terms, data formats, or system design. Good contracts reduce it; no contract clause eliminates it on its own.
• Background IP. Methods, architectures, and know-how the vendor brings to or develops during your project and may reuse in other work, distinguished from the deliverables your agency funded.

Related Lessons

This lesson assumes the acquisition framework covered in Federal Acquisition of AI: FAR/DFARS and follows the selection work in AI Vendor Evaluation Methodology and Evaluating AI Vendor Claims. The terms you negotiate here should trace back to the requirements written in Writing AI Requirements in RFPs and SOWs. After signature, Managing AI Vendor Performance covers exercising the SLA and audit rights this lesson negotiates, Vendor Lock-In Prevention goes deeper on portability beyond the exit clause, Third-Party AI Risk Management addresses the subcontractor and supply-chain exposure behind the data-residency questions, and Insurance and Liability for Government AI extends the liability and indemnification discussion.

Closing

Contract negotiation is where procurement strategy meets legal reality. The best technology will not save a bad contract, and the most rigorous evaluation will not rescue a vendor relationship whose terms are vague. Government AI adoption succeeds when contracts reflect the agency's operational and governance needs, protect sensitive data rigorously, and include a realistic path out if the relationship does not work. None of that is mysterious. It is a list of decisions someone has to make before signature rather than after.

You have the authority to insist on terms that protect your agency. Use it deliberately, negotiate fairly, and keep the distinction Renata drew between what you can trade and what you cannot recover. A percentage point of uptime is recoverable. Data used to train someone else's model is not.

Key Takeaways

• AI contracts are not software contracts. The system feeds on your data, changes over time, and can fail consequentially, which reshapes the data, liability, and transparency terms and adds obligations traditional licensing never covered.
• Win data rights first. Keep ownership of all input, output, and derived data, ban training on your data with the covered services named, and settle residency, deletion, and audit access in the same section. Once data has trained a model, it cannot be untrained.
• Refuse a tiny liability cap. Hold for uncapped liability on data breaches, willful misconduct, and violations of law. A three-month cap is not risk allocation; it transfers risk to the taxpayer.
• Make service levels numeric and enforceable. Replace "reasonable efforts" with uptime, accuracy, latency, and response figures, each with a stated measurement period, backed by service credits and a termination right. Keep the power to classify severity on your side.
• Secure the exit, then make it real. Termination without cause, open-format data return within a fixed window, transition assistance, and model continuation options. The clause is enforceable; portability still has to be engineered.
• Buy verification, not assurances. Audit rights over data handling, security, and fairness, with the vendor obliged to cooperate, and a budget line for the third-party audits you intend to commission.
• Separate walk-aways from tradeables before you negotiate. Concede the percentages to win the irreversible protections, and let the vendor see that you know which is which.
• Use the FAR and DFARS as authority, not just constraint. The acquisition framework backs your strongest positions, but only the provisions actually incorporated into your contract will protect you.
• Exit flexibility beats a long-term discount. A shorter contract with a real termination right is worth more than a multi-year price break that leaves you paying for a system you no longer trust.

Frequently Asked Questions

The vendor says its contract is non-negotiable. Is it? Treat that as an opening position rather than a fact. Vendor standard terms are drafted to protect the vendor, and negotiating them is normal. What helps is bringing your own template, even a simplified one, stating your non-negotiables at the start, and offering something the vendor values in exchange, most often term length or scope. If a vendor genuinely will not clarify data ownership, grant audit rights, or commit to measurable performance, that refusal is itself a finding about the product.

Does a FedRAMP authorization mean my data is safe from being used for training? No. Those are different questions. An authorization addresses the security posture of an assessed environment. What the vendor may do with your data inside that environment is set by the data-use terms of your contract. If you need a training restriction, a residency requirement, or a deletion obligation, each has to be written as its own clause. Compliance certifications and data-use restrictions are frequently conflated, and the conflation always favors the party that did not have to write the clause.

If the contract has an exit clause, are we protected against lock-in? Partially. An exit clause gives you a commitment you can enforce, which is real and worth having. It does not make the system portable. Ask what you would actually be operating 90 days after termination: do you have the data in a format a successor can ingest, documentation of the configuration, a way to keep running or rebuild the model, and staff who could run the alternative? Those come from the transition, portability, and model-continuation clauses, not from the right to terminate itself.

How large should the liability cap be? The lesson's negotiator anchored at 24 months of fees and settled at 18, against a vendor opening of three months, and a general cap around 12 months of fees or a stated floor, whichever is greater, is a common commercial shape. The number matters less than the carve-outs. Uncapped liability for data breach, willful misconduct, and violations of law is the part to defend, along with language ensuring the cap does not reach the government's indemnification claims or data protection claims.

What if the vendor will not accept a 24-hour breach notification clock? Understand what you are being asked to give up before you trade it. Notification timing drives your own downstream obligations, including notifying affected individuals and oversight bodies, and a slower vendor clock consumes time you do not control. If the vendor pushes back, look for the reason: an inability to detect quickly is a different problem from an unwillingness to commit. Consider tightening the definition of discovery and requiring interim notice on suspicion rather than lengthening the clock.

We are a small agency without a dedicated acquisition legal team. Where do we start? Start with the four terms that protect against irreversible harm: data ownership, the no-training restriction, uncapped breach liability, and the exit with data return. Those are the ones you cannot fix after signature. Get legal involved early rather than at signature, use the redline checklist above to structure the conversation, and be explicit with the vendor about which terms you are prepared to trade. You will not win everything, and you do not need to.