Skill.re
Federal Acquisition of AI: FAR/DFARS
Learning Objectives
After completing this lecture, you will be able to:
- Understand the key concepts of federal acquisition of ai: far/dfars in a government context
- Participate in structured workshop activities with real-world scenarios
- Connect federal acquisition of ai: far/dfars to your agency's AI initiatives
- Identify next steps for applying these concepts in your role
Key Topics Covered
-
Acquisition planning for AI
-
FAR Part 12 commercial items
-
DFARS for defense AI
Why This Matters for Government
Overview
Government agencies face unique challenges when it comes to AI adoption. This lecture addresses these challenges head-on by providing senior managers, procurement officers, program directors with the knowledge and frameworks needed to navigate AI in the public sector responsibly and effectively.
As part of the L3 (AI Strategist) curriculum, this lecture builds on the foundational principle that every AI system in government ultimately serves citizens. Whether you are working with AI tools daily or setting strategy for your agency, understanding federal acquisition of ai: far/dfars is essential for responsible, effective government AI adoption.
======================================================================
TRANSCRIPT: Federal Acquisition of AI: FAR/DFARS
======================================================================
Chapter: Chapter 2 -- Establishing an AI Governance Board
Learning Objectives: Understand AI-relevant FAR/DFARS requirements; develop AI procurement strategies; draft AI contract language; manage vendor relationships.
Acquiring AI systems is fundamentally different from acquiring traditional software. Traditional software has clear specifications and measurable performance criteria. AI systems are probabilistic--they produce outputs within statistical ranges rather than exact results. Traditional software implementation is relatively predictable; AI implementation involves significant experimentation and iteration. These differences create challenges for federal procurement that FAR (Federal Acquisition Regulation) and DFARS (Defense Federal Acquisition Regulation Supplement) weren't originally designed to address.
This lecture walks you through acquiring AI systems under existing federal regulations, highlighting AI-specific considerations that aren't addressed explicitly in FAR/DFARS. We'll examine how to structure AI contracts, what clauses are essential, how to evaluate vendor proposals for AI systems, and how to manage vendor performance over time.
Purpose: Why AI Procurement Is Different
Federal procurement is built around clear specifications and measurable deliverables. When you procure a building, you specify dimensions, materials, and performance standards. The contractor delivers exactly what was specified. When you procure software, you specify functional requirements and acceptance criteria. If the software meets specifications, you accept it.
AI procurement is messier. You can't perfectly specify how an AI system will behave because AI systems are trained (not fully programmed). You can't achieve perfect accuracy because accuracy involves trade-offs (higher accuracy might mean slower performance or more bias). You can't guarantee specific performance on novel data because ML systems generalize imperfectly.
This creates a fundamental tension: Federal procurement requires clear specifications and acceptance criteria, but AI systems are inherently uncertain. The art of AI procurement is managing this tension by being clear about what you can specify (data requirements, testing protocols, fairness thresholds) while acknowledging what you can't (exact accuracy on all edge cases).
CORE CONCEPT 1: AI-Relevant FAR and DFARS Clauses
Federal acquisition is governed by FAR (applicable to all federal agencies) and DFARS (additional requirements for Department of Defense). Neither has AI-specific clauses, but several existing clauses apply to AI procurements:
Key FAR Clauses for AI:
FAR 52.204-15 (Service Contract Act Labor Standards)
Applies to service contracts over $2,500. If you're procuring consulting services to develop AI (e.g., hiring a contractor to build an AI system), labor standards apply.
FAR 52.212-4 (Contract Terms and Conditions--Commercial Items)
For commercial AI products/services, this clause governs terms. For off-the-shelf AI systems, you'll reference this clause.
FAR 52.227-2 (Notice of Rights to Inventions Made With Government Funding)
Applies to contracts involving development or inventive activity. Important for AI development contracts--who owns the AI model? If you're developing a new AI system using federal funds, this clause governs IP ownership.
FAR 52.227-9 (Patent Rights)
Specifies patent rights when government funds development. For AI development contracts, critical to clarify who holds patents on the resulting AI system.
FAR 52.229-3 (Data Rights)
Specifies what data you own after contract completion. Critical for AI systems--you should own training data, model weights, and performance data at contract end.
FAR 52.247-64 (Preference for Privately Owned U.S.-Flag Vessels)
Applies to sea transportation. Unlikely relevant for most AI procurements unless your AI system processes data on vessels.
Key DFARS Clauses for AI:
DFARS 252.204-7007 (Supply Chain Risk Management)
Requires contractor to implement cybersecurity and supply chain risk management. For AI systems, this includes protecting AI models from theft/poisoning, protecting training data, managing subcontractor risks.
DFARS 252.204-7009 (Nist Cybersecurity Standards)
Requires compliance with NIST cybersecurity standards. For AI, this means your AI system architecture should implement NIST Cybersecurity Framework controls.
DFARS 252.204-7012 (Safeguarding Covered Defense Information and Cybersecurity Incident Reporting)
Requires reporting of cybersecurity incidents. If your AI system experiences adversarial attacks or data poisoning, reporting required.
DFARS 252.227-7013 (Rights in Technical Data)
Specifies rights to technical data developed under contract. For AI development contracts, clarifies who owns technical documentation, models, and technical data.
DFARS 252.227-7014 (Rights in Noncommercial Computer Software and Noncommercial Computer Software Documentation)
Specifies rights to software developed under contract. Critical for custom AI development--clarifies government's rights to the resulting AI code and models.
CORE CONCEPT 2: Structuring AI Procurements
How you structure an AI procurement dramatically affects outcomes. Key decisions:
Decision 1: Buy vs. Build vs. Hybrid
Buy: Procure off-the-shelf AI products (e.g., commercial language models, commercial ML platforms, commercial AI services from major cloud providers)
Advantages: Faster, lower initial cost, vendor provides support, vendor maintains security/privacy compliance
Disadvantages: Less control, system may not match requirements exactly, may require customization anyway
Appropriate when: You need standard capabilities (language processing, image recognition, sentiment analysis) that commercial products provide well.
Build: Develop custom AI system through contract with AI development firm
Advantages: System tailored to your exact requirements, you own resulting AI system, can be optimized for your use case
Disadvantages: More expensive, longer timeline, more risk, requires you to manage vendor carefully
Appropriate when: Your requirements are unique, commercial products don't meet your needs, you need complete control.
Hybrid: Start with commercial product, customize it through contract with vendor
Advantages: Combines benefits of buy and build, reduces risk compared to full custom build, often cost-effective
Disadvantages: Requires careful vendor management, can get complex if customization is extensive
Appropriate when: Commercial product provides 70-80% of what you need, but requires significant customization.
Decision 2: Task Order vs. Blanket Purchase Agreement (BPA)
Single Task Order: Issue contract for specific AI project with defined scope, timeline, deliverables
Advantages: Clear scope, easier to manage, well-suited for well-defined projects
Disadvantages: Need to re-compete if you need similar work later, may not be efficient for ongoing work
BPA: Establish agreement with vendor(s) allowing you to issue task orders repeatedly without re-competition
Advantages: Faster issuance of task orders, vendor familiarity, efficient for ongoing work
Disadvantages: Requires careful vendor management, may lock you into vendor if other vendors aren't on BPA
Decision 3: Fixed-Price vs. Cost-Plus Contracts
Fixed-Price: Vendor agrees to specific deliverables for fixed price. Vendor absorbs cost overruns; you absorb performance risk.
Appropriate for: Well-defined projects with clear requirements and low technical uncertainty.
Problem for AI: AI projects are inherently uncertain. Vendor may underbid, then deliver poor-quality system rather than lose money.
Cost-Plus: Vendor bills actual costs plus fee. You absorb cost risk; vendor absorbs performance risk.
Appropriate for: Uncertain projects where you can't specify exact requirements upfront. Vendor provides best-effort delivery.
Better for AI: Accommodates inherent uncertainty of AI development. Incentivizes vendor to do good work rather than cut corners.
Hybrid Approach: Fixed-price for well-defined deliverables (training data curation, system documentation), cost-plus for development work where requirements may evolve.
CORE CONCEPT 3: Critical Clauses for AI Contracts
When procuring AI systems, include specific contract language addressing AI-unique challenges:
Clause 1: Data Rights
Essential clause specifying what happens to data at contract end. Standard language:
"Contractor shall provide Government with: (1) All training data used to develop the AI system, organized and documented per [standard]; (2) Sufficient documentation to understand data sources, quality, and characteristics; (3) All test data used to evaluate system performance; (4) Documentation of data preprocessing and feature engineering steps; (5) All data governance and quality assurance documentation."
Why this matters: If you don't specify, vendor may retain training data, preventing you from retraining or auditing the system later.
Clause 2: Model Rights and Access
Specifies your rights to the AI model itself. Standard language:
"Contractor shall provide Government with: (1) Complete AI model code (whether open-source or proprietary); (2) Model weights/parameters in standard format; (3) Sufficient documentation to deploy and retrain the model; (4) Complete training logs and hyperparameter documentation; (5) All source code used in model development; (6) Rights to use the model for government purposes, including audit and testing."
Why this matters: You can't audit, improve, or redeploy the system if you don't have access to the model.
Clause 3: Performance and Fairness Metrics
Specifies metrics the system must achieve. Standard language:
"AI System shall meet the following performance standards: (1) Accuracy: [X]% on [test dataset]; (2) Fairness: Disparate impact 10% requires investigation"
- Transparency: "System shall provide sentiment score and top 3 factors contributing to classification for each feedback item"
- Testing Requirements: "Vendor shall conduct user acceptance testing with 5 government staff; government approval required before system deployment"
Management Approach:
- Monthly performance reviews examining accuracy, processing volume, user feedback
- Quarterly fairness audits analyzing results by feedback source
- Contract includes 30-day warranty--if system fails to meet specs after initial deployment, vendor provides free fixes
Outcome: System deployed successfully, providing agency with systematic sentiment analysis of citizen feedback. Integration completed on schedule and on budget.
Use Case 2: Cost-Plus Development Contract for Custom AI System
Scenario: Defense department needs to develop custom AI system for analyzing satellite imagery to detect military equipment. Agency awards 24-month cost-plus development contract.
Contract Structure:
- Type: Cost-plus contract with fixed management fee
- Vendor: AI development firm specializing in computer vision
- Deliverable: Operational AI system detecting military equipment in imagery
- Cost: Estimated $2M + management fee (vendor absorbs scope changes within contract)
Critical Clauses Included:
- Data Rights: "Government owns all training imagery, model, code, and documentation"
- Model Provenance: "Vendor documents all open-source models, dependencies, and their versions; documents supply chain risks"
- Performance Metrics: "System shall achieve 95% detection accuracy on labeled test set; false positive rate <2%; latency <100ms per image"
- Security Requirements: "System resilient to adversarial image perturbations; vendor documents defenses against model extraction attacks"
- Fairness/Robustness: "System tested on imagery from diverse geographies, lighting conditions, seasons; performance documented across conditions"
- Post-Deployment: "For 12 months post-deployment, vendor monitors system performance, provides recommendations for improvement, conducts quarterly retraining if accuracy degrades"
- Testing and Validation: "Vendor conducts adversarial testing, robustness testing, and operational validation; government approves testing plan before execution"
Management Approach:
- Weekly technical reviews examining progress on model development
- Monthly vendor reporting on accuracy metrics against test set
- Quarterly fairness/robustness assessments
- Government technical representative embedded with vendor team
- Staged acceptance: Prototype (month 6), Alpha version (month 12), Beta version (month 18), Final (month 24)
Outcome: Operational system delivered on timeline and within budget. Strong government understanding of system capabilities and limitations. Post-deployment support ensures system maintains performance as new imagery types encountered.
Anti-Pattern 1: Inadequate Technical Review During Contract Execution
Risk: You accept vendor deliverables without rigorously evaluating whether they meet requirements.
Why this happens: Government lacks AI expertise to evaluate vendor work. Vendor claims deliverables are "complete" and government, lacking expertise, accepts.
What goes wrong:
- System doesn't meet performance requirements but government doesn't know
- Vendor cut corners (minimal testing, inadequate documentation) but government doesn't catch it
- You inherit a weak system that later fails
- Rebuilding the system is expensive
How to avoid:
- Require government technical representative involved throughout development
- Conduct independent technical reviews (monthly or quarterly)
- Build acceptance testing into contract requiring government sign-off
- Don't accept deliverables unless you can independently verify they meet specs
- Be willing to reject inadequate deliverables even if it extends timeline
Anti-Pattern 2: Over-Specifying Technical Requirements
Risk: You specify exact algorithms, data sources, or implementation details, limiting vendor flexibility and innovation.
Why this happens: Desire to maintain control. You try to specify exactly how system should be built.
What goes wrong:
- Vendor can't adapt to changing requirements because they're locked into specifications
- Vendor won't suggest better approaches because spec forbids them
- Innovation is discouraged
- Vendor focuses on meeting specs literally, not on delivering good system
How to avoid:
- Specify what you need (requirements), not how to build it (implementation)
- Allow vendor flexibility in approach
- Evaluate alternative technical approaches during development
- Encourage vendor to propose innovations
- Focus on performance specifications, not technical specifications
Anti-Pattern 3: Inadequate Data Rights and IP Provisions
Risk: Contract doesn't clearly specify who owns data, models, and code, leading to disputes post-contract.
Why this happens: Procurers focus on functional requirements and miss legal/IP issues. Data rights are "boring" compared to performance specs.
What goes wrong:
- After contract ends, vendor won't provide model or training data
- You can't retrain system or audit it
- You're dependent on vendor for ongoing support even after contract
- Trying to use system for different purpose requires renegotiating with vendor
How to avoid:
- Include comprehensive data rights clause
- Specify you own all training data, models, code, and documentation
- Specify format that data/models must be provided in
- Make data/model rights non-negotiable--don't accept "vendor property" arguments
- Document ownership explicitly in contract
Anti-Pattern 4: Inadequate Fairness and Testing Requirements
Risk: You don't require fairness testing or robust testing, system deployed with unknown biases.
Why this happens: Focus on core functionality over fairness. Testing perceived as "nice to have" rather than required.
What goes wrong:
- System develops biases affecting protected groups
- You discover bias only after citizens complain
- System must be shut down for fixing, causing operational disruption
- Legal liability for biased system
How to avoid:
- Make fairness testing mandatory, not optional
- Specify fairness metrics in contract
- Require vendor to document testing methodologies and results
- Require independent bias audits (by government or third party)
- Don't accept "unfixable" bias--require vendor to remediate
Practice Prompt 1: Procurement Strategy
Design an AI procurement strategy for a government capability you're familiar with:
- Buy vs. Build: Should you buy commercial solution, build custom, or hybrid? Why?
- Contract Type: Fixed-price or cost-plus? Why?
- Evaluation Criteria: What factors matter most for this procurement?
- Risk Management: What are the biggest risks? How will you mitigate them?
Practice Prompt 2: Contract Language Draft
Draft contract language for a critical fairness and data rights clause:
- Specify what fairness metrics the system must meet
- Specify what data rights government will have
- Specify what testing fairness vendor must conduct
- Specify what happens if fairness testing reveals bias
Practice Prompt 3: Vendor Performance Assessment
Develop a monthly vendor performance assessment form:
- What metrics will you track? (schedule, quality, testing, etc.)
- How will you measure each metric?
- What's acceptable performance? What's concerning?
- What would trigger escalation?
Practice Prompt 4: Technical Evaluation Framework
Create a framework for evaluating AI vendor proposals:
- What technical criteria matter most?
- How will you score each criterion?
- What are red flags that would downgrade a proposal?
- What questions will you ask vendors about their approach?
Key Takeaways
- AI Procurement Requires Adapted FAR/DFARS Language: Standard clauses don't fully address AI-specific issues. Include clauses on data rights, model access, fairness metrics, testing requirements, and supply chain risks.
- Specify What You Need, Not How to Build It: Require performance specifications (accuracy, fairness, latency) rather than technical specifications (specific algorithms, specific data sources). Give vendors flexibility in approach.
- Data and Model Rights Are Essential: Contract must clearly specify government owns training data, models, code, and documentation. Without these rights, you're dependent on vendor.
- Fairness Testing Is Mandatory: Include fairness testing requirements in contract. Require vendor documentation of testing methodology and results. Don't accept "fairness not possible."
- Testing and Validation Take Time: Budget time for thorough testing. Don't accept deliverables without independent verification they meet specs. Common mistake: rushing deployment without adequate testing.
- Post-Deployment Support Matters: Include post-deployment monitoring and support in contract. AI systems degrade over time. Vendor should remain engaged ensuring system maintains performance.
- Build Government Technical Capacity: To effectively manage AI vendors, you need government staff who understand AI. Investing in government technical expertise is prerequisite for effective procurement.
Glossary
FAR: Federal Acquisition Regulation governing procurement by all federal agencies.
DFARS: Defense Federal Acquisition Regulation Supplement; additional procurement rules for Department of Defense.
Fixed-Price Contract: Vendor agrees to deliverables for fixed price. Vendor absorbs cost overruns.
Cost-Plus Contract: Vendor bills actual costs plus management fee. Government absorbs cost risk.
Data Rights: Specifications for what data government owns/controls after contract completion.
IP Rights: Intellectual property rights--who owns patents, copyrights, and other intellectual property created under contract.
Acceptance Criteria: Objective specifications system must meet for government to accept deliverables.
Task Order: Specific procurement request issued under pre-existing contract or BPA.
Federal AI procurement is in transition. Current regulations (FAR/DFARS) were written before AI became prevalent. They don't explicitly address AI-specific issues like fairness, explainability, or supply chain risks. Effective government procurers are adapting regulations to address AI-specific concerns while maintaining compliance with existing rules.
The key is viewing the contract as a collaboration tool rather than just a legal document. Well-drafted contracts clarify expectations, ensure vendor delivers what you need, and protect government interests. Poorly-drafted contracts create disputes, lead to inadequate deliverables, and constrain your ability to maintain systems after deployment.
- Have you procured AI systems? What worked? What didn't?
- For a hypothetical AI procurement, what would be your top 5 contract requirements? Why those?
- How would you evaluate vendor proposals for AI systems? What would disqualify a vendor?
- What's the biggest challenge in procuring AI systems from your perspective?
Procurement is where policy meets practice. Well-designed procurement strategies ensure you acquire AI systems that meet your actual needs, perform reliably, and comply with governance requirements. Effective AI procurement requires clear thinking about what you need, realistic evaluation of vendor capabilities, and rigorous oversight during development.
Government AI CLUB Certification Program
Level 3: AI Practitioner | Federal Acquisition of AI: FAR/DFARS | Lecture 2.4
A GOVT.CLUB initiative.
<- 3.2.11 International Standards: EU AI Act and OECD
3.3.2 AI Vendor Evaluation Methodology ->
Start Your CLUB Certification
This lecture is part of L3: AI Strategist -- 80 hours of comprehensive government AI training.
Explore CLUB Certification
Related Lectures
L3
3.3.2 -- AI Vendor Evaluation Methodology
90 min - Workshop + Scorecard
L3
3.3.3 -- Writing AI Requirements in RFPs and SOWs
120 min - Workshop + Templates
L3
3.3.4 -- Evaluating AI Vendor Claims
60 min - Workshop + Checklist