How to Vet an AI Vendor for Government Work: A Contracting Officer's Checklist

Vetting an AI vendor for government work is harder than vetting a traditional IT services vendor — and harder than most contracting officers have been trained for. The reasons are technical (AI capabilities are easy to claim and hard to verify), regulatory (the governance landscape is new and shifting), and structural (AI vendors often have less past performance than the work demands). This checklist isn't a replacement for the standard responsibility determination — it's an AI-specific overlay on top of it.

1. Verify the basics — actually verify them

Start with the credentials the vendor claims on their website or capabilities statement. The UEI should resolve to an active SAM.gov record. The CAGE code should match. SDVOSB status should be verifiable in SBA VetCert, not just stated by the vendor. NAICS codes should align to the work being procured. Stated contract vehicles should be confirmable in publicly available databases.

This step takes ten minutes and rules out a surprising number of vendors. If a self-described SDVOSB AI vendor isn't VetCert-verified, the conversation ends there.

2. Demand specific past performance — not "experience"

"Experience implementing AI for government" is a marketing claim. Past performance is a contract number, an agency point of contact, a CPARS rating, a period of performance, and a measurable outcome. For new SDVOSBs without federal past performance, acceptable substitutes include commercial-sector engagements with named clients willing to serve as references, prior personnel experience documented in key-personnel resumes, and small initial federal awards still in performance.

Absence of meaningful past performance isn't automatically disqualifying — but it requires the CO to compensate elsewhere, typically through more rigorous technical evaluation, smaller initial scope, or stronger contract structure.

3. Probe the AI governance posture

Ask the vendor to describe, in writing, their approach to the NIST AI RMF. The answer should distinguish between the four functions (Govern, Map, Measure, Manage) and provide concrete examples of artifacts they produce under each. A vendor who can produce sample Map documentation from a prior engagement is operating in RMF reality; a vendor who says "we follow the framework" without artifacts is selling marketing copy.

Ask specifically about subgroup performance evaluation, adversarial robustness testing, and drift monitoring. These are the AI-specific practices that distinguish capable vendors from competent traditional IT vendors who have rebranded as AI vendors.

4. Test data handling and CUI capability

For any engagement involving CUI, sensitive PII, or classified material, the vendor must demonstrate compliance with the applicable framework — typically NIST SP 800-171 for CUI, FedRAMP authorization for cloud-hosted services at the appropriate impact level, and stricter standards as classification rises.

"Compliance" should be evidenced, not asserted. Request a current System Security Plan, a recent independent assessment, or — at minimum — a written description of the vendor's data handling architecture with the controls applied. Vendors who can't produce documentation should not be handling sensitive data.

5. Examine the model transparency posture

Under OMB M-25-22, government acquisition of AI requires vendor transparency on training data, model architecture, and outputs. The vendor's posture on each is informative.

Ask: what training data was used? What is the provenance of that data? Were rights cleared for the data's use? What happens to government inputs and outputs — are they used to retrain models, retained by the vendor, or kept exclusively in the agency environment? Who owns the embeddings, fine-tuning artifacts, and derivative work?

Vendors with clean, defensible answers to these questions are usable. Vendors who deflect, claim trade secret, or provide answers that don't survive a follow-up question are not.

6. Stress-test the exit strategy

Vendor lock-in is the most expensive AI procurement mistake. Before award, the contract should specify what happens at termination or non-renewal: data return formats, model artifact ownership, embedding portability, retraining rights, transition assistance obligations.

Ask the vendor to describe a hypothetical transition to a successor vendor. A capable vendor will have a clean, rehearsed answer. A vendor who can't articulate the exit hasn't thought about it — which is itself the answer.

7. Validate the team, not just the company

AI work is people-intensive. The technical lead, the program manager, the compliance owner — these individuals materially determine performance outcomes. Request key-personnel resumes. Confirm that the named personnel will actually staff the engagement and aren't just resume window dressing. Validate professional certifications relevant to the work (PMP, CISSP, vendor-specific AI credentials).

For small AI vendors, the named team is often the company. That's not a disqualifier — but it's worth confirming.

8. Read the Capability Statement test

A vendor's capability statement is a one-to-two page document that tells you almost everything about how seriously they take government work. The presence and quality of this document is an unusually reliable signal.

A serious AI vendor has a polished capability statement available on their website and willing to email it within hours of a request. It includes all vendor identifiers, NAICS codes, core competencies in concrete terms, differentiators, past performance summaries, and contract access information. A vendor without a capability statement, or with one that takes weeks to produce, is signaling that government work is a side hustle, not a primary focus.

Red flags to walk away from

Three patterns warrant ending the conversation immediately.

The first is opacity on model behavior — vendors who refuse to describe how their AI makes decisions, what data it was trained on, or how it handles inputs are unsuitable for government work regardless of capability.

The second is contractual aggression around data and IP — vendors whose default contract terms claim ownership of agency inputs, outputs, or derivative work are positioning for lock-in that costs the agency dearly downstream.

The third is dismissiveness about governance — vendors who treat NIST AI RMF, OMB requirements, or accessibility obligations as inconveniences rather than legitimate operating constraints will produce work that fails oversight review.

How to structure RFI and RFQ questions

For sources-sought notices and RFIs, the most useful questions ask vendors to demonstrate rather than assert. "Describe your NIST AI RMF implementation approach" produces marketing copy. "Provide a redacted sample Map artifact from a prior engagement" produces evidence. "Describe your past performance with FOIA AI" produces narrative. "Provide three contract numbers, agency POCs, and CPARS ratings for FOIA-related AI work" produces ground truth.

The bottom line

AI vendor vetting is harder than traditional IT vendor vetting, but it follows the same principle: verify what you can verify, demand evidence for what you can't verify directly, and walk away from vendors who can't or won't produce it. The agencies that get AI procurement right are the ones that invest in the vetting at the front of the engagement — and save themselves the cost of unwinding it later.