Contracting. How AI gets bought.

A vehicle is a pre-negotiated path the government uses to buy. The contract is already there. The agency runs a task order against it. No vehicle, no order. Wrong vehicle, no order. This is the part that kills more deals than any technical objection.

Here are the vehicles you will actually see for AI work.

GSA MAS (Multiple Award Schedule)

The broadest vehicle. One long-term contract with GSA. Any federal agency can order off it.

AI work usually lands in two MAS categories: Information Technology (54151S for IT Professional Services, 54151HEAL for health IT, 511210 for software) and Professional Services. AI labeling and data services often sit under IT Professional Services.

Lead time to get on MAS: plan for 6 to 12 months from offer submission to award. Faster if your past performance and accounting system are already clean. Slower if either is not.

Good for: services, software resale, repeatable AI work. Not great for: pure research or prototype-only efforts.

SeaPort-NxG

Navy's main IDIQ for engineering and professional services. Multi-award, multi-billion ceiling. SeaPort-NxG is the heavyweight for Navy AI services because most Navy program offices already know how to write a task order against it.

If you do AI engineering, modeling, simulation, or analytics work for the Navy, SeaPort-NxG is the path your customer probably wants to use.

The pool has on-ramps. Watch sam.gov for them.

OASIS+

GSA's cross-agency vehicle for complex professional services. OASIS+ replaced the original OASIS. It went into use in 2024.

Status as of 2026-06; verify before citing in proposals. Last we tracked, OASIS+ had separate domains (Management and Advisory, Technical and Engineering, Research and Development, Logistics, Intelligence, Enterprise Solutions) with unrestricted and small business pools. Check GSA's OASIS+ page for the current domain list and on-ramp status before you reference it in a capture plan.

Good for: complex services where AI is one piece of a larger engineering or advisory effort.

SBIR / STTR

The phased R&D program. Funded by every agency with an R&D budget. The main entry point for AI startups.

• Phase I: feasibility. Small award (commonly $50K to $300K depending on agency and topic). Six to twelve months.
• Phase II: prototype. Larger award (commonly $1M to $2M, higher for some DoD topics). Eighteen to twenty-four months.
• Phase III: commercialization. No SBIR funding cap. Sole-source authority. Agencies can buy your Phase III work without re-competing it. This is the part most founders miss.

STTR is the same structure but requires a partnership with a research institution.

If you have not won a Phase I, you cannot skip to Phase II. Some agencies run Direct to Phase II under specific topics.

OTA (Other Transaction Authority)

A non-FAR path. Used for prototyping and research. The FAR is the Federal Acquisition Regulation, the rulebook that governs most federal buying. OTAs sit outside it.

Why DoD AI lives here: the FAR is built for known requirements and price competition. AI prototypes are neither. OTAs let DoD move fast, share IP flexibly, and bring in non-traditional vendors who would never tolerate a full FAR contract.

OTAs run through consortia (Tradewind for the DoD CDAO/CDO ecosystem, NSIN, DIU, AFWERX-adjacent paths, and others). Join a consortium, watch for prototype solicitations, respond fast.

A successful OTA prototype can transition to a production OTA or a follow-on production contract without re-competition under 10 USC 4022. That is the prize.

GWACs and 8(a) STARS III, CIO-SP4, Alliant 3

Government-Wide Acquisition Contracts. Like MAS but narrower and more competitive.

• 8(a) STARS III: GSA's small business GWAC for 8(a) firms. IT services including AI. Heavy use across civilian agencies.
• CIO-SP4: NIH's GWAC for health IT and broader IT services. Status as of 2026-06; CIO-SP4 had a long protest cycle. Verify the current award status before planning capture.
• Alliant 3: GSA's large-business GWAC for IT services. Successor to Alliant 2. Plan for high competition and high ceilings.

If your customer's contracting office prefers a GWAC, ask which one they use. Then check whether you are on it.

Decision table

I'm doing this	Look at this vehicle
Selling AI services to multiple civilian agencies	GSA MAS
Engineering services for the Navy	SeaPort-NxG
Complex professional services where AI is one piece	OASIS+
Research prototype, small team, fast	SBIR/STTR or OTA
DoD AI prototype with non-traditional vendor angle	OTA via consortium
Small business IT services across civilian agencies	8(a) STARS III
Large IT services contract, full and open	Alliant 3
Health IT or NIH-adjacent	CIO-SP4 (verify status)
Selling SaaS to feds	MAS (and probably FedRAMP first)

One rule: do not chase a vehicle you are not on. Get on, then chase.

Read enough of these and the language stops looking strange. Each pattern below is a teaching skeleton, not a real solicitation. Use it to know what to expect.

Generic AI/ML services PWS

A Performance Work Statement tells the contractor what outcomes to deliver. The government writes the what. The contractor writes the how.

A modern AI services PWS usually has these sections:

1. Background. One or two paragraphs on the program. Why AI. What problem.
2. Scope. Bounded. "The contractor shall develop, deploy, and sustain machine learning models supporting [mission task] for [user population]."
3. Objectives. Outcome-level, not task-level. "Reduce manual review time for [artifact type] by 40 percent while maintaining accuracy at or above [baseline]."
4. Tasks. Numbered. Model development. Data engineering. Evaluation. Deployment. Monitoring. Sustainment. User training.
5. Deliverables. Each one named, with a due date and an acceptance standard. Model artifacts. System card. Evaluation report. Monitoring dashboard. SBOM. Incident response runbook.
6. Performance standards. Measurable. Latency. Accuracy. Uptime. Mean time to detect a model drift event. Mean time to roll back.
7. NIST AI RMF compliance. Reference to AI RMF 1.0 and the Generative AI Profile (NIST AI 600-1) where relevant.
8. Security and ATO. Reference to the system's impact level (FedRAMP Moderate, IL2, IL4, IL5, IL6) and the expected authorization path.
9. Data rights and IP. What the government gets. What the contractor keeps. Watch this section.
10. Personnel. Cleared vs uncleared. Key personnel named.
11. Period of performance. Base year and option years.
12. Place of performance. On-site, hybrid, or contractor facility.

If the PWS has none of sections 5, 6, or 7, ask questions during the Q&A period. Otherwise you are signing up for unbounded work.

Generic AI prototype SOO

A Statement of Objectives is shorter than a PWS. The government writes what they want. The contractor proposes how to do it. Common for OTAs.

A prototype SOO usually contains:

1. Mission need. One paragraph.
2. Objectives. Three to seven outcome statements. "Demonstrate a working prototype that ingests [data type] and produces [decision artifact] at operational latency in a representative environment."
3. Constraints. Classification level. Data sources. Integration points. Time bound.
4. Success criteria. What "done" looks like for the prototype phase. Often tied to a transition decision.
5. Transition path. What happens if it works. This is the line that signals whether a Phase III or production OTA is on the table.

A SOO is the contractor's chance to write the technical approach the way the technical team would actually build it. Use that.

Generic AI capability SOW (SBIR Phase II or task order)

A Statement of Work is the contractor's how. Often used inside SBIR Phase II proposals or under an IDIQ task order. Numbered, specific, and binding once awarded.

1. Objective. One sentence.
2. Technical approach. Architecture diagram. Model selection rationale. Data pipeline. Evaluation method.
3. Tasks and subtasks. Numbered, with effort estimates.
4. Schedule. Gantt or milestone list. Phase gates.
5. Deliverables. Same standard as the PWS list: each named, dated, and with an acceptance standard.
6. Government-furnished information and equipment. Data sets. Compute access. Cleared facility access.
7. Reporting. Monthly status. Quarterly technical review. Final report.

Where to find real ones, and how to read them in 30 minutes

sam.gov. The federal solicitation index. Search by NAICS code (541512 for computer systems design, 541511 for custom programming, 541715 for R&D, 541618 for other management consulting). Filter by notice type. Sources Sought tells you the government is shaping the requirement and wants to hear from industry. Solicitation means it is live. Combined Synopsis/Solicitation usually means a faster, simpler buy.

Search terms that surface AI work: "artificial intelligence," "machine learning," "natural language processing," "computer vision," "large language model," "generative AI," "model evaluation," "MLOps," "AI RMF."

USASpending.gov. Past awards. Search the agency, search the NAICS, look at who won and for how much. This tells you the real budget for similar work.

GovWin and other paid trackers. Show shaping activity earlier than sam.gov. Worth it if you are doing serious capture.

Read in 30 minutes:

1. Cover page and instructions (5 minutes). Vehicle. Deadline. Page limit. Evaluation factors.
2. PWS or SOO (15 minutes). What do they want. What are the acceptance criteria. Where is the data.
3. Section L and Section M (10 minutes). Instructions to offerors and evaluation criteria. These tell you exactly how the government will grade your proposal. Write to them.

If the solicitation has no clear evaluation factors, that is a bid/no-bid signal.

The 10 evaluation phrases that mean "we expect you to know NIST AI RMF"

Few solicitations name NIST AI RMF directly. Many describe it without naming it. Watch for these phrases:

1. "Trustworthy AI characteristics" or "trustworthy AI principles."
2. "AI system documentation" or "model documentation" with no further detail (they mean system cards and model cards).
3. "Bias assessment and mitigation plan."
4. "Continuous monitoring of model performance" or "model drift detection."
5. "Human oversight" or "human-in-the-loop controls."
6. "AI risk management plan" or "AI risk register."
7. "Transparency and explainability requirements."
8. "Pre-deployment testing" or "red team evaluation."
9. "Incident reporting for AI-related harms."
10. "Lifecycle approach to AI assurance" (this one is almost always a direct echo of the AI RMF Govern/Map/Measure/Manage functions).

If you see three or more of these in one solicitation, the evaluator is looking for AI RMF in your response even if the document does not name it.

A modern AI work statement has a recognizable shape. The clauses below show up across DoD, civilian, and IC solicitations. Know them by name. Know what they ask for. Know what they cost to deliver.

AI-specific clauses that should appear

NIST AI RMF compliance

What the words usually say: "The contractor shall align AI development and deployment activities with the NIST AI Risk Management Framework (AI RMF 1.0) and applicable profiles, including the Generative AI Profile (NIST AI 600-1) where applicable."

What it means for the engineer: You will produce artifacts mapped to the Govern, Map, Measure, and Manage functions. Expect to deliver an AI risk register, a system inventory, a measurement plan with metrics, and a management plan with controls. Most teams underestimate the Govern artifacts.

Model documentation (system card)

What the words usually say: "The contractor shall deliver model documentation describing intended use, training data provenance, evaluation results, known limitations, and operational constraints."

What it means: A system card or model card per model. Template it once. Reuse it. Update it on every retrain.

Evaluation plan with measurable acceptance criteria

What the words usually say: "The contractor shall propose and execute an evaluation plan with quantitative acceptance criteria for accuracy, fairness, robustness, and safety."

What it means: Numbers. Thresholds. A test set that is not the training set. A held-out evaluation environment. If the solicitation does not name the thresholds, you propose them. The government will hold you to whatever you propose.

Monitoring and observability

What the words usually say: "The contractor shall implement continuous monitoring of model performance and detect drift, degradation, and anomalous behavior in operation."

What it means: A dashboard. Alerts. A scheduled re-evaluation cadence. A defined drift threshold that triggers retraining. Goes deeper in expert/05.

Incident response

What the words usually say: "The contractor shall maintain an incident response plan covering AI-specific failure modes and report incidents to the government within [X] hours of detection."

What it means: A runbook for prompt injection, data leakage, model output failures, and harmful content. A named on-call. A reporting form. Practice it.

SBOM delivery

What the words usually say: "The contractor shall deliver a Software Bill of Materials in CycloneDX or SPDX format for all delivered software, including model artifacts and dependencies."

What it means: Generate the SBOM in your build pipeline. Deliver it as a contract artifact. Update it on every release. EO 14028 and follow-on guidance made this standard.

Data handling

What the words usually say: "The contractor shall handle all government data in accordance with the applicable security categorization and shall not use government data to train models or services outside the scope of this contract without written authorization."

What it means: No training on government data for your commercial product. No third-party API calls that send government data to a non-authorized service. This clause is where a lot of AI contracts die in execution.

IP and data rights

What the words usually say: Varies widely. Look for "Government Purpose Rights," "Unlimited Rights," "Restricted Rights," or specific DFARS clauses (252.227-7013, 7014, 7015 for DoD).

What it means: Who owns the model weights. Who owns the training data. Who owns the fine-tuned adapter. Who can the government share it with. Read this section twice. Negotiate it before award, not after.

Red flags: push back during Q&A

• "Evolving accuracy" without thresholds. Language like "the contractor shall continuously improve model accuracy over the period of performance" with no numbers. Unbounded. Ask for a target and a baseline.
• IP handoffs that take your model weights. Default DFARS clauses can grant Government Purpose Rights to anything developed under the contract. If your base model is commercial, write that in. Mark your pre-existing IP. Negotiate.
• No acceptance criteria on bias or fairness. If the PWS asks for "fair" or "unbiased" AI with no metric and no test set, you cannot pass the test. Ask for the metric.
• Government-furnished data "to be provided." If the data is not in hand at award, your schedule will slip. Build a data-delay clause into your proposal.
• Authorization to Operate "by the contractor." The contractor supports the ATO. The government grants it. If the PWS makes you responsible for the ATO outcome, push back. Goes deeper in expert/08.
• Open-ended monitoring "forever." Sustainment without a defined re-baseline event is a trap. Tie monitoring obligations to model versions and contract option years.

PWS vs SOO vs SOW

	PWS	SOO	SOW
Stands for	Performance Work Statement	Statement of Objectives	Statement of Work
Written by	Government	Government	Contractor (proposal) or Government (task order)
Describes	Required outcomes and performance standards	High-level objectives	Specific tasks and methods
Vehicle home	FAR-based services contracts, IDIQ task orders	OTAs, some FAR R&D	SBIR, IDIQ task orders, R&D contracts
Favors	Government (defines acceptance)	Contractor (defines approach)	Contractor (defines tasks)
Risk to contractor	Acceptance criteria binding	Approach freedom, scope creep risk	Task list binding
Best for	Repeatable services	Prototypes and exploration	Defined R&D or build efforts

The practical rule: if the government wrote a PWS, deliver to the standard. If the government wrote a SOO, write the SOW yourself and make it favor your approach. If you are writing a SOW under a task order, be specific enough to be paid and broad enough to absorb minor pivots.

Sample acceptance criteria language for AI deliverables

Reusable patterns. Edit the bracketed values.

1. Accuracy threshold. "The delivered model shall achieve [precision >= 0.90, recall >= 0.85] on the government-furnished held-out test set, measured at the [class-level / population-level] and reported in the Evaluation Report. The test set shall not be available to the contractor during model training."

2. Drift detection. "The contractor shall implement drift detection that triggers an alert when [population stability index > 0.2] or [accuracy drops more than 5 percentage points from baseline] on a [weekly] basis. Alerts shall be acknowledged within [4 business hours]."

3. Latency. "At a sustained load of [N requests per second], the model shall return responses within [P95 < 500 ms, P99 < 1500 ms] measured at the API gateway over a [24-hour] window."

4. Fairness. "The model shall be evaluated for disparate impact across [protected attribute] groups defined in [Attachment X]. Differences in [false positive rate / false negative rate] across groups shall not exceed [X percentage points]. Results shall be reported in the System Card."

5. Documentation completeness. "Each delivered model shall include a System Card per the template in [Attachment Y] covering intended use, training data provenance, evaluation results, known limitations, monitoring approach, and incident response contacts. Models without a complete System Card shall not be accepted for production deployment."

These patterns are not the only way to write acceptance criteria. They are a way that holds up.