Build versus buy versus partner for government AI

Partner: the agency co-develops with a university lab, a federally funded research center, or a nonprofit civic tech group (e.g., Code for America), often with shared IP and shared operational risk.

None of these is inherently superior. The right choice depends on three variables: how fast you need it, how much control you need over the logic, and how exposed you are to vendor lock-in (the state of being dependent on one vendor's proprietary systems such that switching costs become prohibitive).

Why procurement cycles matter more than the model itself

Most public sector AI failures are procurement failures, not algorithm failures.

A typical US state procurement cycle for a system like a Medicaid eligibility engine runs 18 to 36 months from RFP (Request for Proposal, the formal solicitation document) to go-live, per common GovTech industry estimates. Federal procurement under the FAR (Federal Acquisition Regulation) can be longer still. That timeline alone rules out "buy" for any agency facing an urgent mandate, such as a new federal reporting requirement with a six-month deadline.

Build sidesteps the RFP cycle but runs into a different clock: hiring. State government data science salaries typically lag private sector by 20 to 40% (rough market estimate), so agencies often need 6 to 12 months just to staff a competent in-house team, before writing a line of model code.

Partner models can move faster on the technical build (a university lab may already have a working prototype) but are often slower on data-sharing agreements, since MOUs (Memoranda of Understanding) with public universities go through their own legal review, and HIPAAHIPAAHealth Insurance Portability and Accountability Act, loi américaine imposant la protection des données de santé (PHI). Violations : amendes jusqu'à 1,9M$ par catégorie de violation. (Health Insurance Portability and Accountability Act) or state privacy statutes govern what Medicaid data can even leave the agency's servers.

Rule of thumb: if the deadline is regulatory and fixed, buy or partner with an entity that already has FedRAMP or StateRAMP authorization (the federal/state cloud security certification programs that pre-clear vendors for handling government data). If the deadline is flexible and the logic is core to your mission, build.

Vendor lock-in: the risk that shows up after the contract ends

Vendor lock-in in government AI usually takes three forms:

1. Data lock-in: the vendor's platform stores eligibility data in a proprietary schemaschemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.Voir la définition complète → that can't be easily exported.

2. Model lock-in: the decision logic is a black box, and the contract doesn't require documentation, explainability artifacts, or source code escrow.

3. Staff lock-in: only the vendor's employees understand the system, so the agency can't independently audit or modify it, and switching vendors means starting over.

For a Medicaid eligibility engine, lock-in is dangerous because these systems make decisions with due process implications. Under the Administrative Procedure Act and related state equivalents, a beneficiary denied coverage has a right to understand and appeal the basis for that denial. If your model is a vendor's undocumented black box, you cannot produce that explanation on demand. This has already been litigated: Arkansas's use of an automated tool to cut home care hours for disabled Medicaid beneficiaries was successfully challenged in court in the mid-2010s partly because the methodology wasn't adequately disclosed. The Electronic Privacy Information Center (EPIC) maintains public tracking of algorithmic accountability cases in government benefits systems, worth a look for anyone evaluating these deployments.

Contract clauses that reduce lock-in risk, regardless of build/buy/partner path:

• Source code and model artifact escrow (a neutral third party holds a copy, released if the vendor fails or the contract ends)
• Data portability requirements in open formats (CSV, JSON, not proprietary binaries)
• Explainability requirements: the vendor must produce a plain-language rationale for any adverse decision
• Right-to-audit clauses allowing independent technical review

A simple decision framework

| Factor | Favors Build | Favors Buy | Favors Partner |

|---|---|---|---|

| Time to deploy | Slow (12-24 mo) | Fast if pre-certified vendor exists | Medium, depends on MOU speed |

| Control over logic | High | Low unless contract mandates transparency | Medium to high |

| Upfront cost | High (staff, infra) | Lower upfront, ongoing licensing | Often grant-funded, lower cash cost |

| Long-term flexibility | High | Low without strong contract terms | Medium, depends on IP terms |

| Best for | Core mission logic, high litigation exposure | Commoditized tasks (document intake, scheduling) | Novel methods, research-grade problems |

For the Medicaid case: eligibility determination is high-stakes, litigation-exposed, and core to the agency's mission. That argues for build or a tightly-contracted partner model, not a black-box buy, even though buy is faster. A pragmatic middle path many states actually use: buy a vendor's workflow and case management platform (low legal risk, commoditized) while building or co-developing the actual eligibility scoring logic in-house or with a university lab, keeping the highest-stakes component auditable.

What "partner" actually looks like in practice

Partnering with a university lab is not free R&D. It comes with its own frictions: academic timelines don't match government fiscal years, publication incentives (researchers want to publish findings) can conflict with data confidentiality requirements, and IP ownership must be negotiated explicitly before the project starts, not after.

That said, several US states have used university partnerships successfully for lower-stakes, higher-innovation problems, such as forecasting Medicaid enrollment surges or detecting fraud patterns in claims data, where the cost of a wrong prediction is operational inefficiency rather than a due-process violation. This is the right risk profile for partnership: experimental, not adjudicative.

A simple way to size up the tradeoff quantitatively: estimate the total cost of ownership (TCO) over a five-year horizon, not just year-one licensing.

Buy scenario (illustrative, not a real quote):
Year 1 licensing + implementation: $2.0M
Years 2-5 licensing (annual):      $0.6M x 4 = $2.4M
Vendor switching cost (est. if locked in): $1.5M
5-year TCO: ~$5.9M

Build scenario (illustrative):
Team of 4 FTEs x $150K avg loaded cost x 5 years: $3.0M
Infrastructure (cloud, security review): $0.4M
5-year TCO: ~$3.4M, but with 12-18mo delay before go-live

This is illustrative math, not a benchmark, real figures vary enormously by state and vendor. The point of the exercise is procedural: force procurement teams to price in switching costs and delay costs, not just sticker price.

🎬 [VIDEO: "How Governments Buy Software (and Why It's So Hard)" - youtube.com/@codeforamerica - Code for America's explainer on public sector procurement friction and its effect on technology adoption, useful context for why buy cycles run long]

Key Takeaways

• Match the decision to the stakes: build or tightly-governed partner models for high-litigation, core-mission logic (like eligibility determination); buy for commoditized, lower-risk workflow tasks.
• Procurement timelines (often 18-36 months for US state RFPs) are frequently the real bottleneck, not model performance, so timeline pressure should shape the build/buy/partner choice as much as technical capability.
• Vendor lock-in has three flavors (data, model, staff); mitigate all three contractually with source code escrow, data portability clauses, and mandatory explainability, regardless of which path you choose.
• Partnership with universities works best for exploratory, non-adjudicative problems (forecasting, fraud pattern detection), not decisions with direct due-process consequences.
• Always calculate total cost of ownership over a 5-year horizon, including estimated switching costs, before comparing buy quotes against build estimates; year-one price alone is misleading.