Aoife Whitfield is the Deputy Secretary for Technology Innovation at a state economic development agency, a $620 million portfolio of business development programs, a workforce of 340, and a mandate from the Governor to leverage AI to modernize the business climate. Her office was not large enough to build AI in-house. Her procurement timelines, where a standard IT solicitation took 14 months from requirements to contract, were too slow for the pace at which AI capabilities were evolving. Her legal team had concerns about every approach: buying an off-the-shelf AI product raised data sovereignty questions; partnering with a university raised IP ownership questions; engaging a startup raised financial viability questions; partnering with a large technology company raised conflict-of-interest and vendor lock-in questions. She spent most of a quarter mapping the partnership landscape before issuing a single solicitation. The map she produced, which defined four distinct partnership models, each with different risk profiles, different IP structures, and different conflict-of-interest requirements, has since become her agency's standard framework for any AI engagement with private-sector partners.

The quarter she spent mapping looked, from the outside, like delay. It was the opposite. Every one of her legal team's concerns was real, and every one of them attaches differently depending on which partnership structure you choose. An agency that skips the mapping does not avoid those questions. It simply meets them later, one at a time, in the middle of a live engagement, when the leverage to fix them has already been spent. This lesson is that map: what the models are, what each one does to intellectual property and oversight access, and which terms have to be settled before signature rather than after a dispute.

Why Government Partnerships for AI Are Structurally Different

Private-sector technology partnerships are governed primarily by contract. The parties negotiate terms that reflect their relative leverage, their respective risk tolerance, and their commercial objectives. If the terms do not serve one party, they renegotiate or walk away. That freedom is the baseline assumption a commercial partner brings into the room, and it explains most of the friction in early conversations with government. The vendor is not being difficult when it proposes a term your agency cannot accept. It is proposing something that would be entirely normal with any other customer, and nobody has yet explained why this customer is different.

Government partnerships for AI are governed by contract and by a layer of public law obligations that constrain the terms available to the government party. Procurement regulations require competitive solicitations above specified dollar thresholds. Ethics statutes restrict the flow of benefits and information between government officials and private-sector partners. FOIA, the Freedom of Information Act, and state sunshine laws may make aspects of the partnership, including contract terms that a commercial partner would treat as proprietary, available to public inspection. Civil rights statutes impose equity requirements on AI systems deployed by government that do not apply to commercial products generally.

These constraints are not barriers to partnership. They are the structural features that make a government AI partnership credible to the public and accountable to oversight. A partner who understands and accepts these constraints at the outset is a more durable partner than one who is surprised by them after the contract is signed. This is worth saying out loud in the first conversation, because a vendor whose commercial instinct is to treat every term as negotiable will discover otherwise at the worst possible moment, and the discovery usually arrives as a records request rather than as a negotiation.

Which specific regime applies is a question you have to answer before you draft anything. Federal acquisitions, state procurement codes and local purchasing rules differ, and an agency operating under one of them cannot borrow the clause set of another. Confirm with your counsel and your contracting officer which authorities govern the engagement you are contemplating, and confirm it before the requirements document is written, because the available structures narrow considerably once the solicitation is out.

The Four Partnership Models

Aoife's framework distinguishes four distinct models, each appropriate for different circumstances. What separates them is not the size of the deal or the type of organization on the other side. It is who builds, who owns, and who carries the risk if the capability turns out to be harder than anyone expected. Read each of the four below for those three answers, because the differences in IP structure, conflict exposure and exit position all follow from them. An agency that cannot say which of these four it is in has usually assembled a hybrid by accident, and the accidental hybrid is where the weakest terms live.

The commissioned development model is the most common. The government issues a procurement solicitation with defined requirements. The private-sector partner builds a system to meet those requirements. The government owns the deliverables. The partner provides the technical expertise and the development capacity. This model is appropriate when the government has well-defined requirements, when the system will be purpose-built to government specifications, and when the government needs to own and control the resulting product. The primary risk is requirements mismatch: government agencies often underspecify AI requirements, leading to systems that technically meet the contract but do not serve the operational need.

The licensed access model involves the government acquiring access to a commercial AI product under a licensing arrangement. The partner retains ownership of the underlying model and the technical infrastructure. The government receives a configured instance of the product with specific data and workflow integrations. This model is appropriate for commodity AI capabilities such as document summarization, language translation and general-purpose assistants, where the government's need is well-served by existing commercial products. The primary risks are vendor lock-in, where the government's data and workflows become embedded in a proprietary platform; data sovereignty, where the government's data is processed through a private infrastructure it does not control; and service continuity, since a vendor that changes pricing, deprecates a feature or goes out of business affects the government program directly.

The co-development model involves the government and a private partner jointly developing an AI system, with shared investment and shared ownership of the results. This model is appropriate for AI applications that the private partner also has commercial interest in, for example a transportation demand forecasting tool that both a state transportation department and a regional transit authority can use, and that the developer can commercialize for other state markets. IP ownership is a complex negotiation: the government typically retains a royalty-free license to use the jointly developed system, while the private partner retains commercialization rights outside the government's specific use case. Conflict-of-interest management is particularly important here, because the private partner's commercial incentives may not align with the government's program design objectives.

The research partnership model engages a university, a federal laboratory, or a research organization under a cooperative agreement or a sponsored research arrangement. The government provides funding, data access, and operational context; the research partner provides technical expertise and often produces published findings. This model is most appropriate for exploratory AI development, testing whether AI can solve a specific government problem, rather than for production deployment. The primary challenge is the timeline mismatch between academic research cycles, typically 12 to 36 months for a meaningful study, and government program needs.

Choosing Between the Models

The choice is driven by four questions, and Aoife asks them in order. First, do you know what you want built? If the requirements are still a hypothesis, a commissioned development contract will convert that hypothesis into a delivered system that meets the specification and misses the need. Second, does the capability already exist commercially in a form close enough to your use? If it does, building it bespoke spends public money to reproduce something you could configure, and the honest comparison is between configuration risk and construction risk rather than between buying and building in the abstract.

Third, does the partner have an independent commercial interest in the same capability? A yes points toward co-development and immediately raises the incentive question: the features that make the system commercially attractive elsewhere are not necessarily the features that serve your program, and someone on the government side has to own that tension explicitly. Fourth, is the question you are asking a research question? If nobody knows whether the approach works at all, a research partnership answers that at lower cost and lower commitment than a production contract, provided the program can live with the timeline.

Note what these questions do not turn on: the size or reputation of the partner. Aoife's legal team raised a distinct concern for each type of counterparty, from the startup's financial viability to the large technology company's lock-in and conflict exposure. None of those concerns selects a model. They tell you which terms you will have to negotiate hardest once the model is chosen, and which failure you are most exposed to if the relationship ends badly.

IP Ownership: The Non-Negotiables

Government agencies need to negotiate IP ownership provisions that protect the public investment and the public interest. The specific terms will vary by model, but three principles are non-negotiable in any government AI partnership. Treat them as the floor you do not trade below rather than as opening positions, and settle them before the relationship develops the momentum that makes hard terms awkward to raise. Each of the three protects a different thing: the public's investment in the system, the public's ability to hold it accountable, and the program's ability to survive the end of the relationship.

First, the government must retain ownership of, or perpetual royalty-free access to, any AI system trained on government data. Training data collected at public expense and under government authorities cannot become the exclusive property of a private partner. The reason is not commercial advantage. It is that the data was gathered from the public under legal authorities granted for public purposes, and a structure that converts it into a private asset has repurposed it without anyone deciding to. Note that this principle reaches the trained artifact as well as the raw records, because a model that learned from the data carries what it learned even when the underlying records never leave.

Second, the government must retain the right to audit or inspect the AI system, including access to documentation of training data, model architecture, and decision logic, for purposes of compliance review, inspector general investigation, or civil rights investigation. Proprietary claims cannot be used to block oversight access. This is the provision most often traded away quietly, because it is abstract at signature and concrete only later. The test to apply while drafting is simple: if an investigator asked tomorrow how this system reaches its decisions, could the agency answer without the partner's voluntary cooperation? If the answer depends on goodwill, the term is not strong enough.

Third, transition rights must be specified in advance. If the partnership ends, whether by contract expiration, non-renewal, or the vendor's exit from the market, the government must be able to continue operating the AI system or transition it to a new provider without losing access to the work product its funding produced. Specify what the government receives, in what format, and on what timeline, and specify it for the involuntary endings as well as the planned ones. A transition clause written only for orderly expiration does nothing in the scenario that actually strands a program.

What these three principles have in common is that none of them is self-executing. In federal acquisitions the Federal Acquisition Regulation supplies the clause framework for rights in data and custom development, and other jurisdictions have their own equivalents, but which rights the government actually holds depends on the clauses in your specific contract and how they were applied. Do not assume ownership follows from having paid for the work. Have counsel confirm the allocation in writing, in the agreement, before award, and read the partner's proposed terms for the quiet exception that swallows the rule: a definition of pre-existing intellectual property broad enough to cover everything delivered is the most common one.

An AI partnership that makes the government dependent on a private partner's continued cooperation for system access, data retrieval, or compliance documentation is not a partnership. It is a hostage arrangement with procurement paperwork, and the moment you discover it is the moment you have the least leverage to change it.

Data Sovereignty and the Records Question

Data sovereignty appears in this lesson as a risk of the licensed access model, and it deserves unpacking, because it is the concern Aoife's legal team raised first about buying an off-the-shelf product. The question is not only where servers physically sit. It is whose infrastructure processes government records, under whose jurisdiction, subject to whose access, and with what visibility for the agency. An arrangement can be entirely lawful and still leave an agency unable to say precisely where a citizen's record was processed, who at the provider could reach it, and what happened to derived data such as logs, embeddings and usage telemetry.

Ask those questions during the solicitation rather than during an incident. What data leaves the agency boundary, in what form, and for what purpose. What the provider retains after processing and for how long. Whether government data is used to improve the provider's general product, which is a purpose the agency has to decide on deliberately rather than accept in a default term. Who at the provider can access the data, under what controls, and how the agency would learn of an inappropriate access. These are contract terms and configuration choices, and both are far easier to set before the workflows are built on top of them.

The records dimension runs alongside. Government records held in a partner's system are still government records, which means retention schedules, records requests and litigation holds reach them. If the agency cannot search, export or preserve what sits in the partner's platform, it has a records problem regardless of how well the AI performs. Build the retrieval and preservation capability into the agreement, and confirm with your records officer and counsel which obligations attach before the first dataset moves.

Conflict of Interest Management

Government AI partnerships create potential conflicts of interest that must be managed proactively. The most common scenarios are: a government official who participated in the AI procurement subsequently joins the private-sector partner; a private-sector partner that has a financial interest in the AI system's outputs helps the government design the evaluation criteria for those outputs; and a co-development partner with commercial interests uses access to government data or operations to develop capabilities it then commercializes without the government's knowledge.

Conflict management requires written policies that define the specific behaviors that are restricted, clear disclosure requirements for government officials and contractor personnel who may have relevant financial interests, and periodic reviews during the partnership to identify whether new conflicts have emerged as the partnership scope has evolved. The periodic review is the part agencies skip. A conflict analysis done at award describes the relationship as it was on that day, and partnerships change: scope expands, personnel move, data access widens, and a structure that was clean at signature can become a problem without anyone making a decision.

Two of these scenarios deserve particular care because they are easy to rationalize. The partner helping design the evaluation criteria for its own system is often framed as the partner being helpful, and the technical expertise really does sit on their side. The answer is not to refuse their input but to ensure the government owns the criteria, that someone independent of the partner reviews them, and that the record shows who wrote what. The post-employment scenario is governed by ethics rules that vary by jurisdiction and are not a matter for the program office to interpret. Route it to your ethics official early, in writing, and follow the answer you get.

What the Agreement Has to Say

By the time a partnership reaches signature, a specific set of questions should already have written answers in the agreement itself rather than in a shared understanding. Who owns what, including anything the system learns from government data. Who can audit, on what notice, with access to which artifacts. What happens to the system, the data and the documentation if the partnership ends for any reason, including the partner ceasing to exist. Which conflicts have been disclosed, who reviewed them, and what restrictions were imposed as a result. And who on the government side owns each of those questions after award.

Aoife's framework was used for five subsequent partnerships, and none of them produced an inspector general finding. That is a genuinely good record and it is worth reading precisely. It is evidence that a structured approach to model selection, IP terms and conflict review avoided the failures those controls were designed to prevent, in five engagements, at one agency. It is not a guarantee that the framework prevents findings, and it is not a reason to skip the analysis on the sixth partnership because the first five went well. The value of the map is that it forces the questions to be asked each time, not that it answers them once.

Anti-Patterns

• Choosing the partner before choosing the model. An agency meets a capable vendor, gets excited, and reverse-engineers a structure to fit them. The model should follow from what you need built and who has commercial interest in it. Picking the counterparty first means every subsequent term is negotiated from the weaker position of already having decided.
• Assuming ownership because you paid. Funding the work does not settle rights in it. What the government holds depends on the clauses in the specific agreement, and a broad definition of the partner's pre-existing intellectual property can quietly cover most of what gets delivered. Confirm the allocation with counsel in writing before award.
• Accepting proprietary claims as a limit on oversight. A partner asserting trade secrecy over training data or decision logic is asserting that the agency cannot answer an inspector general, a civil rights investigator or a court. Preserve inspection rights in the agreement explicitly, because the assertion arrives when the investigation does.
• Leaving transition rights to the end of the relationship. Exit terms negotiated during a dispute are negotiated with no leverage. Specify in advance what the government receives, in what format, and on what timeline, if the partnership ends for any reason, including the partner going out of business.
• Treating the conflict analysis as a one-time filing. The disclosure completed at award describes a relationship that has since changed. Scope grows, staff move between the parties, and data access widens. Without a periodic review, the first notice of a conflict is an external one.
• Letting the partner define success. When the entity with a financial interest in the system's outputs also writes the evaluation criteria for those outputs, the evaluation stops being independent regardless of anyone's good faith. Take the technical input, own the criteria, and have someone independent review them.

Practice Prompts

• Classify your current engagements. Take every AI-related agreement your agency holds and place each into one of the four models. For any that do not fit cleanly, write down why. A hybrid nobody chose deliberately is usually where the IP and exit terms are weakest.
• Run the four questions. For an AI capability your agency needs in the next year, answer in order: do we know what we want built, does it already exist commercially, does a partner have independent commercial interest, and is this actually a research question? Recommend a model on the basis of the answers and state what you would negotiate hardest.
• Stress the exit. Pick one live partnership and write what would happen if the partner ceased operations without warning. What do you hold, what can you retrieve, and what would you need to keep the service running? Turn the gaps into proposed contract language.
• Audit the audit rights. Read the oversight and inspection provisions of one agreement. Could you obtain documentation of training data, model architecture and decision logic to answer an investigation? If not, draft the amendment and identify who has authority to seek it.
• Refresh a conflict review. Take a partnership that has been running for more than a year and redo the conflict analysis against today's scope, personnel and data access rather than the arrangement at award. Report any change to your ethics official in writing.

Reflection

Consider the AI partnerships your agency currently holds. Which model does each one actually follow, as opposed to what the solicitation called it? If a partner's system produced a disparate outcome tomorrow and an investigator asked how the model was trained, could you answer without the partner's cooperation? What would it take to move your largest AI capability to a different provider, and how long would the service be degraded while you did? Who reviews conflicts after award, and when did they last look? And where in your current portfolio would you make a different structural choice if you were starting over today?

Glossary

• Commissioned development. A partnership in which the government specifies requirements, the partner builds to them, and the government owns the resulting deliverables.
• Licensed access. A partnership in which the government acquires configured access to a commercial AI product while the partner retains the underlying model and infrastructure.
• Co-development. Joint development with shared investment and negotiated ownership, typically leaving the government a royalty-free use license and the partner commercialization rights outside the government's use case.
• Research partnership. A cooperative or sponsored research arrangement with a university, laboratory or research organization, suited to exploratory work rather than production deployment.
• Vendor lock-in. The condition in which government data, workflows and institutional practice are so embedded in a proprietary platform that changing providers is impractical, removing the agency's leverage over price and service.
• Data sovereignty. The question of whose infrastructure and whose jurisdiction the government's data is processed under, and what control the agency retains over it.
• Transition rights. Contract provisions specifying what the government receives, in what form, and on what timeline if the partnership ends, so the system can continue operating or move to another provider.

Related Lessons

• Working with AI Vendors and Contractors covers the day-to-day relationship management that begins once a model is selected.
• AI Contract Negotiation goes deeper into the specific terms that implement the non-negotiables described here.
• Vendor Lock-In Prevention addresses the licensed access risk in detail, including data portability and exit planning.
• Federal Acquisition of AI: FAR/DFARS covers the federal clause framework for agencies operating under it.
• Academic and Research Partnerships expands the research model, including publication and timeline management.
• Data Sharing Agreements for AI handles the data terms that sit underneath any partnership involving government records.
• Third-Party AI Risk Management covers the ongoing risk posture of systems your agency depends on but does not run.

Closing

The quarter Aoife spent before issuing a solicitation bought her agency something durable: a way of deciding, each time, which structure fits the problem and which terms have to be settled before signature. Her legal team's four concerns did not disappear. They became questions with a place in the process, asked while the agency still had the leverage to act on the answers. That is the practical difference between a partnership program and a sequence of individually negotiated escapes from problems the agency created for itself.

If you take one thing into your next engagement, take the ordering. Decide the model from what you need and who wants it commercially. Settle ownership, oversight access and transition rights in the agreement. Review conflicts on a schedule rather than at award. None of this makes a partnership succeed, and none of it substitutes for a partner who can actually build the thing. It does mean that when the relationship changes, and it will, the agency is negotiating from a position it chose rather than one it inherited.

Key Takeaways

• Government AI partnerships operate under public law constraints that commercial partnerships do not. Procurement regulations, ethics statutes, FOIA, and civil rights requirements constrain the terms available to government parties. Partners who understand these constraints at the outset are more durable partners.
• The four partnership models have distinct risk profiles. Commissioned development, licensed access, co-development, and research partnerships each have different IP ownership structures, different conflict-of-interest requirements, and different appropriate use cases.
• Choose the model from the problem, not from the partner. Whether the requirements are known, whether the capability already exists commercially, whether the partner has independent commercial interest, and whether the question is a research question are what select the structure.
• Vendor lock-in in licensed access models creates service continuity risk. When government data and workflows are embedded in a proprietary commercial platform, pricing changes, feature deprecations, or vendor failure can disrupt government programs with no easy exit.
• The government must retain audit access regardless of proprietary claims. Any AI partnership agreement must explicitly preserve the government's right to audit the system, including documentation of training data and decision logic, for compliance review and oversight purposes.
• Rights follow the clauses, not the funding. Paying for the work does not by itself settle ownership. Have counsel confirm in writing what the specific agreement allocates, and read the partner's definition of pre-existing intellectual property closely.
• Transition rights must be specified before the partnership begins. The conditions under which the government can exit and continue operating the AI system, or move it to a new provider, must be negotiated in the original agreement, not after a dispute arises.
• Conflict-of-interest policies must be updated as partnership scope evolves. Conflicts that did not exist when a partnership began may emerge as the scope of work, the data access arrangements, or the personnel involved change, so the review has to recur rather than sit in the award file.

Frequently Asked Questions

Our procurement timeline is far too slow for the pace of AI. How do we fix that inside the partnership choice? You mostly cannot fix the timeline by choosing a model, and it is worth being clear about that rather than hoping a structure will absorb the delay. What the model choice does affect is what you are committing to at the end of the timeline. A research partnership or a tightly scoped licensed access arrangement lets an agency learn something real while a longer competitive process runs for the production capability. Raise the timeline problem with your contracting officer as its own problem, in its own forum, rather than solving it by picking a looser structure.

The partner says its training data and model architecture are trade secrets. Is that the end of the conversation? It is the start of one. Oversight access is a term you negotiate before award, not a concession you seek afterward, and an agency that cannot document how a system was trained cannot answer an inspector general, a civil rights investigator or a court. There are ways to protect genuinely proprietary material while preserving inspection, including controlled review arrangements, but they have to be written into the agreement. A partner who will not accept any inspection route is telling you something useful about the partnership.

Can we let the vendor help write the evaluation criteria? They know the technology better than we do. Take their technical input and keep ownership of the criteria. The problem is not bad faith; it is that an entity with a financial interest in the outputs will frame success in terms its system meets, and everyone involved will find that framing reasonable. Have someone independent of the partner review the criteria, document who contributed what, and make sure the person signing off on the evaluation does not depend on the partner for their understanding of it.

The partner treats its pricing and terms as confidential. Can we agree to that? Confidentiality expectations and disclosure obligations are not the same thing, and the agency should not promise more than it can deliver. Aspects of a government partnership, including terms a commercial partner would treat as proprietary, may be subject to public inspection under FOIA or state sunshine laws. Tell the partner that early, route any specific confidentiality request to counsel and to whoever handles records requests, and avoid a contractual promise your agency may be legally unable to keep. A partner surprised by a disclosure after signature is a partner you will be litigating with.

What if the partner goes out of business? That is precisely what transition rights are for, and it is why they belong in the original agreement. Decide in advance what the government receives, in what format, and how quickly: the data, the trained artifacts where the agreement allocates them to you, the documentation, and enough operational knowledge to keep the service running or hand it to a successor. Then test the assumption once, on paper, before you need it. An exit clause nobody has ever exercised is a hypothesis.

Does a well-structured agreement make the partnership safe? No. It makes specific failures less likely and gives the agency a position to negotiate from when things change. Aoife's five subsequent partnerships produced no inspector general finding, which is real evidence that the approach works at one agency across five engagements, not proof that structure prevents problems. The controls still have to be exercised: the audit right used, the conflict review actually run, the exit terms tested. An agreement is a set of options, and options expire unexposed.