Skip to content
Article reader Listen + reading controls
LISTEN + READ YOUR WAY

Article reader

Preparing the reader…

0:00 0:00
Reading settings
Text size
100%

Federal AI Procurement Is a Risk-Management Control Plane

The Federal Artificial Intelligence Risk Management Act of 2024 proposed more than agency adoption of the NIST AI Risk Management Framework. It also contemplated acquisition support and contract language that would carry risk-management expectations into federal purchasing.

That may be the proposal’s most operationally important feature.

Federal agencies build some AI systems themselves, but they increasingly acquire models, cloud services, data, integrations, and AI-enabled products from vendors. If governance obligations stop at the agency boundary, agencies can remain publicly accountable for systems whose material evidence and operational control sit inside private contracts.

Procurement is therefore not an administrative step after AI policy. It is the control plane through which public accountability becomes enforceable across the supply chain.

The proposed H.R. 6936 would have required OMB guidance on agency use of the NIST AI Risk Management Framework, supported agency acquisition expertise, and addressed contractual implementation. The enduring design question is what evidence and rights an agency must obtain before it can responsibly depend on an external AI system.

Buying an Outcome Does Not Transfer Accountability

Vendors often possess deeper product knowledge than their government customers. That asymmetry does not transfer the agency’s legal, ethical, or mission responsibility.

An agency must still be able to determine:

  • whether the system is appropriate for the intended use;
  • how it was evaluated and under which conditions;
  • which data and components materially affect performance;
  • how users and affected people can challenge consequential outcomes;
  • when an update changes the risk profile;
  • whether the system is degrading or being misused;
  • and how the agency can suspend, investigate, replace, or retire it.

If a contract does not provide the information and control required to answer those questions, the acquisition has created an accountability gap.

Contract for Evidence, Not “Responsible AI”

Generic clauses requiring a contractor to follow responsible-AI principles are difficult to test and easy to satisfy rhetorically. Contract requirements should specify artifacts, access, performance, and decision rights proportionate to the use.

A high-impact acquisition may require:

Intended use and system boundary

The contractor documents supported and prohibited uses, material dependencies, user roles, affected populations, environmental assumptions, and downstream actions.

Provenance

The government receives sufficient information about model, software, data, and third-party components to understand origin, licensing, change history, and material risk. Proprietary protection may constrain disclosure, but it cannot make provenance irrelevant.

Evaluation evidence

The supplier provides test methods, representative conditions, results, uncertainty, subgroup analysis, human-factors findings, adversarial tests, and known limitations. The agency retains the right to perform or commission independent evaluation.

Observability

The system exposes logs, telemetry, versions, input and output provenance, override events, and performance indicators needed for monitoring and incident reconstruction, subject to lawful privacy and security controls.

Change control

Material model, data, policy, or orchestration changes are identified. The contract defines which changes require notice, renewed evidence, agency approval, or rollback capability.

Incident response

The supplier must report defined incidents and vulnerabilities within specified timelines, preserve evidence, support investigation, and remediate without suppressing legitimate disclosure.

Exit and portability

The agency can export government data, configurations, evaluation records, and other necessary artifacts; transition to another provider; and continue essential services during exit.

These requirements make framework adoption concrete.

“Commercially Available” Does Not Mean Evaluated for Government Use

Commercial AI services benefit from scale, talent, and rapid innovation. Their default operating assumptions may not match public-sector obligations.

A commercial provider may optimize for average user satisfaction while an agency needs consistent accessibility and nondiscrimination. A model endpoint may update frequently while a safety-impacting workflow needs version stability. Consumer terms may permit data use that conflicts with government privacy or records requirements. A provider may report global availability while an agency requires operation at a particular classification or in a disconnected environment.

Acquisition should separate general product maturity from fitness for the government’s intended context. The agency must map the commercial service into its own mission, legal, security, human, and operational system.

The Government Needs Technical Leverage, Not Maximum Ownership

The choice is not between proprietary products and government-owned software. Agencies can use commercial systems while preserving public leverage at critical boundaries.

Leverage includes:

  • the right to evaluate independently;
  • access to material operational data and telemetry;
  • stable, documented interfaces;
  • model and service version identification;
  • export and migration mechanisms;
  • government control of mission-specific policy and knowledge;
  • competition among integrators or model providers;
  • and contractual remedies when evidence or performance fails.

An agency may not need model weights. It does need to know which model produced a consequential output, whether that model differs from the evaluated version, and what recourse exists if the supplier withdraws it.

Evaluation Must Continue After Award

Traditional source selection evaluates proposals before contract award. AI systems change after award because models, data, user behavior, threats, and context change.

Contracts should fund a continuing evidence cycle:

  1. establish a baseline against the existing process;
  2. evaluate in a controlled and representative environment;
  3. deploy to a bounded scope;
  4. observe performance, human reliance, and impacts;
  5. revise or constrain the system;
  6. expand only when evidence supports expansion;
  7. reassess after material change;
  8. retire when benefits no longer justify cost and risk.

Payment structures can reinforce this cycle. Agencies can tie increments to verified evidence, operational outcomes, observability, and successful transition rather than to delivery of features alone.

Acquisition Expertise Must Be Multidisciplinary

The 2024 proposal recognized the need for AI acquisition expertise. That expertise cannot be reduced to technical fluency or a specialist contracting vehicle.

An effective acquisition team needs:

  • mission and product leadership;
  • data and AI engineering;
  • cybersecurity and privacy;
  • human factors, accessibility, and civil rights;
  • legal and policy analysis;
  • test and evaluation;
  • contracting and intellectual property;
  • operations and incident response;
  • and representatives of affected users or communities.

The team must collaborate before the solicitation is written. Once a requirement or contract boundary is fixed, many governance choices become expensive to change.

Standard Clauses Need Risk-Based Tailoring

Government-wide model language can reduce duplication and establish a floor. One-size-fits-all requirements can also burden low-risk uses while remaining too weak for high-impact systems.

A modular clause library is preferable. Requirements can be selected based on:

  • consequence and reversibility of decisions;
  • scale and affected populations;
  • model autonomy and tool access;
  • sensitivity of data;
  • adversarial exposure;
  • difficulty of human review;
  • rate of system change;
  • and availability of alternatives or remedy.

The OMB M-24-10 memorandum later provided minimum practices for rights-impacting and safety-impacting AI. Acquisition policy should translate those obligations into supplier evidence and operating rights, not assume agencies can fulfill them after purchasing an opaque service.

Measure the Health of the Vendor Relationship

Procurement success is not just on-time delivery or user adoption. Agencies should monitor whether the relationship preserves governance capacity:

  • Can the agency reproduce material evaluation results?
  • How quickly are incidents detected and reported?
  • What percentage of consequential changes arrive with adequate evidence?
  • Can government teams access and interpret operational telemetry?
  • How long would migration to an alternative provider take?
  • Are interfaces and data formats genuinely portable?
  • Does the supplier resolve findings without controlling the definition of success?

These are indicators of institutional resilience.

The Strategic Inference

Federal AI regulation will be only as effective as the contracts through which agencies obtain capability. Policies can assign responsibility to an agency, but procurement determines whether the agency retains the evidence and leverage required to exercise it.

The objective is not to make every vendor disclose every proprietary detail. It is to ensure that public institutions do not become accountable in name and blind in practice.

When contracts specify evidence, observability, change control, incident support, portability, and independent evaluation, procurement becomes a mechanism for trustworthy innovation. When they purchase an outcome while leaving the supplier in exclusive control of the system’s knowledge, risk management becomes an aspiration outside the technical boundary.

This essay was substantially revised in July 2026 to replace the original duplicate legislative summary with a distinct analysis of acquisition and supplier governance.

For organizations designing AI procurement, delivery, and assurance as one operating system, my practical work is available through Xendev Labs and my broader portfolio.

References

READER-NEUTRAL SUBSCRIPTION

Follow Field Notes via RSS.

Copy this address into the RSS reader you already use. New notes will appear there automatically—no account, email address, or tracking required.

Open the feed