Learning Objectives

After completing this lecture, you will be able to:

• Understand the key concepts of working with ai vendors and contractors in a government context
• Connect working with ai vendors and contractors to your agency's AI initiatives
• Identify next steps for applying these concepts in your role

Key Topics Covered

-
Evaluating vendor capabilities

-
Questions to ask

-
Managing vendor relationships

-
Government-specific considerations

Why This Matters for Government

Government agencies face unique challenges when it comes to AI adoption. This lecture addresses these challenges head-on by providing analysts, project leads, team supervisors with the knowledge and frameworks needed to navigate AI in the public sector responsibly and effectively.

As part of the L2 (AI Practitioner) 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 working with ai vendors and contractors is essential for responsible, effective government AI adoption.

======================================================================

TRANSCRIPT: Working with AI Vendors and Contractors

======================================================================

Chapter: 4 -- AI Project Management

What you will learn:

• How to evaluate AI vendor capabilities and maturity
• How to assess vendor fairness and governance practices
• Critical questions to ask vendors
• Contract terms and conditions specific to AI projects
• Red flags that indicate vendor risk
• How to maintain government control and oversight
• How to manage vendor performance and vendor risk

Most government AI projects involve vendors or contractors. You're unlikely to build everything in-house. This creates a governance challenge: You need to ensure that external vendors build systems that meet your fairness, accuracy, and governance standards. You can't just contract for "an AI system" and assume you'll get something that works.

This lecture teaches you how to evaluate vendors, ask the right questions, negotiate contracts that protect government interests, and manage vendor relationships effectively. The goal is to ensure that you get systems that meet your standards and that you maintain government control and oversight throughout the process.

PURPOSE STATEMENT

Vendor management is critical to government AI project success. Bad vendor selection leads to poor systems, cost overruns, and governance failures. Good vendor management leads to systems that work, that meet fairness standards, and that you can maintain independently after the contract ends. This lecture teaches the skills and frameworks for managing vendor relationships effectively.

WHY THIS MATTERS FOR GOVERNMENT

Government agencies face particular challenges with AI vendors. First, the AI market is young and immature. Vendors make inflated claims about capabilities. Vendor promises about accuracy and fairness often don't materialize. Second, government has special obligations around fairness, transparency, and accountability that not all vendors understand or accept. Third, government agencies need to be independent of vendors--if the contract ends, you need to be able to maintain and update the system yourself. Vendors sometimes build systems that are impossible to maintain without them.

Additionally, government procurement rules create constraints. You can't just pick the vendor you like best. You have to follow FAR/DFARS regulations, go through competitive selection processes, and document your decisions. Understanding these constraints and how they interact with AI vendor management is critical.

ASSESSING VENDOR CAPABILITY

Before you sign a contract with an AI vendor, assess their actual capabilities.

EVALUATING TECHNICAL CAPABILITY

Questions to ask:

• What similar projects have you completed? (Ask for references and be willing to call them)
• Who will do the work? (Key person risk: if the main AI expert is critical, what happens if they leave?)
• What methodology will you use? (Are they following standard practices or inventing their own?)
• What tools and platforms will the system use? (Are these stable, well-supported technologies or experimental?)
• How will you handle the discovery that your initial approach doesn't work? (Do they have a process for pivoting?)

Red flags:

• "We've built this type of system before" (But can't show you comparable projects)
• All work will be done by a subcontractor (you're one layer removed from the actual builders)
• "We use proprietary methodology" (that no one else understands)
• Aggressive timeline estimates (claiming to deliver in 6 months what takes others 12)
• No mention of testing, validation, or monitoring

EVALUATING FAIRNESS AND GOVERNANCE MATURITY

This is where many vendors fall short. They have good technical skills but limited governance maturity.

Questions to ask:

• How do you address fairness and bias in your projects? (Do they have a process or is it ad-hoc?)
• What fairness metrics do you measure? (Can they name specific metrics?)
• Have you ever had to address fairness concerns? How? (Real examples indicate experience)
• How do you handle transparency and explainability? (Can they explain how systems make decisions?)
• What monitoring and alerting do you build into systems? (Or do they hand you a model and say "good luck"?)

Red flags:

• "Fairness isn't something we focus on--our systems are technically accurate" (This is wrong. Accuracy and fairness are separate)
• "We've never had fairness issues" (Suspicious. Every system that serves diverse populations has fairness considerations)
• "Fairness is your problem, not ours" (Indicates unwillingness to take responsibility)
• No mention of demographic performance analysis or bias testing
• Claims that "the system is objective so it can't be biased" (Misunderstands how bias enters systems)

CRITICAL QUESTIONS FOR AI VENDORS

Overview

During vendor evaluation, ask these questions. The quality of answers indicates vendor maturity.

QUESTION GROUP 1

• How will you work with us to refine requirements during the project?
• What will you do if you discover that achieving the success criteria we defined isn't possible with our data?
• How much discovery time do you budget before committing to a timeline?
• What happens if the data we provide is lower quality than expected?
• How will you involve our team in decision-making throughout the project?

QUESTION GROUP 2

• What testing methodology will you use?
• How will you test for fairness and bias?
• Will you do stratified testing across demographic groups?
• How will you validate that the system is ready for production?
• What documentation will you provide on testing methodology and results?
• Who validates test results--you or an independent third party?

QUESTION GROUP 3

• What monitoring will the system have once deployed?
• How will you alert us to performance degradation?
• How will humans override or review system decisions?
• What happens when the system encounters data it wasn't trained on?
• How do you plan for model retraining and updates?
• Will we be able to maintain this system ourselves after the contract ends, or are we dependent on you?

QUESTION GROUP 4

• How will we explain to the public how the system works?
• Can we see the factors that influence system decisions?
• How do you handle audit requests?
• What documentation will you provide for regulatory compliance?
• If the system is challenged legally, what evidence will we have that it was fair and accurate?

QUESTION GROUP 5

• What happens if the system fails after deployment?
• What's your rollback procedure?
• How do you handle incidents where the system makes harmful decisions?
• What's your contingency if the contract is terminated early?
• How will you support us if we need to fix problems after you've left?

RED FLAGS IN VENDOR PROPOSALS

Overview

Certain patterns in vendor proposals indicate high risk.

RED FLAG 1

"Our system will achieve 95%+ accuracy on your use case"

Why it's concerning: Accuracy claims should be conditional on data quality and based on comparable projects. Unconditional claims indicate either lack of understanding or deception.

What to do: Ask them to explain their basis for the claim. What data did they use? How is it comparable to your use case? Push back if they can't justify the claim.

RED FLAG 2

"We have a pre-built solution for your problem. We'll install it and you're done."

Why it's concerning: AI rarely works that way. Every deployment requires customization, validation, and governance setup. Claims of turn-key solutions indicate they don't understand the complexity.

What to do: Ask how they'll customize it to your data. Ask about validation. Assume you'll need 3-4 months of integration work after they hand off the system.

RED FLAG 3

The proposal is all about accuracy and speed. No mention of fairness, bias testing, or demographic analysis.

Why it's concerning: Either they don't think fairness matters (wrong) or they don't know how to handle it (also wrong).

What to do: Make fairness testing a contract requirement. Don't accept proposals that don't address it.

RED FLAG 4

"We'll build an AI system for fraud detection. Timeline: 6 months. Cost: $500K."

Why it's concerning: Good proposals include detailed scope, phased timelines, and clear decision points. Vague proposals indicate shallow analysis.

What to do: Require detailed sprint plans. Who does what work in which weeks? What's the MVP? What's the full rollout?

RED FLAG 5

"You'll need to keep us on retainer for ongoing maintenance and updates."

Why it's concerning: You'll be dependent on the vendor forever, unable to maintain the system independently.

What to do: Insist on knowledge transfer. Insist on systems and code that you can maintain independently. Budget for your own staff to learn and take over maintenance.

RED FLAG 6

The proposal includes deployment but no mention of monitoring, alerting, incident response, or ongoing maintenance.

Why it's concerning: The work doesn't actually end at deployment. You need monitoring and maintenance plans.

What to do: Make monitoring and incident response part of the contract. Define what "done" means and that it includes post-deployment support.

CONTRACT TERMS FOR AI PROJECTS

Overview

Standard government contracts need AI-specific terms.

KEY CONTRACT REQUIREMENTS

• FAIRNESS AND VALIDATION REQUIREMENTS
• System must pass fairness analysis before deployment (define what "pass" means)
• Demographic performance documentation required
• Bias testing methodology documented
• Government approval required before deployment
• DOCUMENTATION REQUIREMENTS
• Test plan and test results documented
• Model documentation including features used
• Data quality assessment
• Fairness analysis and results
• Monitoring plan
• Incident response procedures
• INDEPENDENCE AND MAINTENANCE
• All code and models must be government-owned
• Vendor must provide documentation for independent maintenance
• Knowledge transfer required (training your staff)
• Tools must be standard, not proprietary
• PERFORMANCE STANDARDS
• Specific accuracy metrics and thresholds
• Specific fairness metrics and thresholds
• System reliability and uptime requirements
• Response time requirements
• Support terms (how long will vendor support the system?)
• CHANGE MANAGEMENT
• Process for model updates and retraining
• Process for responding to performance degradation
• Process for making changes to system after deployment
• Vendor support for at least X months post-deployment
• LIABILITY AND INDEMNIFICATION
• What happens if the system causes harm? (liability allocation)
• What if the system violates civil rights? (indemnification)
• Insurance requirements
• Limitation of liability terms
• DATA OWNERSHIP AND PROTECTION
• Government owns all data
• Vendor cannot use government data for other purposes
• Data security requirements
• What happens to data when contract ends?

MANAGING VENDOR PERFORMANCE

Overview

Once you've signed a contract, manage the vendor relationship actively.

ONGOING VENDOR MANAGEMENT

Establish clear governance:

• Weekly or bi-weekly check-in meetings with vendor
• Clear escalation procedures if problems arise
• Defined decision-making authority (who approves changes?)

Monitor progress against commitments:

• Are they hitting sprint milestones?
• Are they engaging in requirements conversations or just building?
• Are they doing validation testing?
• Is fairness analysis happening or deferred?

Set clear expectations about what "done" means:

• Don't accept "here's the model, good luck"
• Require working system, documentation, monitoring setup, and knowledge transfer
• Define post-deployment support terms

Insist on transparency:

• You should see test results, not just summaries
• You should see fairness analysis, not promises that it's fair
• You should be involved in validation decisions
• You should have visibility to monitoring data once deployed

Prepare for the vendor relationship to end:

• Ensure your team has actually learned how to maintain the system
• Ensure code and documentation are clear enough that someone else can maintain it
• Do dry runs of maintenance with your team while vendor is still available
• Don't extend the vendor contract indefinitely out of convenience

ANTI-PATTERNS

ANTI-PATTERN 1

You receive a vendor proposal, leadership likes it, you sign the contract without detailed technical review. Vendor starts work and you discover the proposal was full of unrealistic promises.

How to avoid it: Have technical experts review proposals. Ask the hard questions. Don't accept vague proposals.

ANTI-PATTERN 2

First vendor says they can build what you want. You sign without considering alternatives. Later you discover other vendors would have been better.

How to avoid it: Use competitive procur ement processes. Evaluate multiple vendors. Compare approaches.

ANTI-PATTERN 3

You become dependent on the vendor. They're the only ones who understand the system. They can charge whatever they want for support.

How to avoid it: Invest in knowledge transfer. Insist on documentation. Build internal capability from the beginning.

ANTI-PATTERN 4

Accuracy testing happens throughout the project. Fairness testing is deferred until the end as a checkbox. Fairness problems are discovered at deployment when fixing them is expensive.

How to avoid it: Make fairness testing part of the iterative process. Test for fairness every sprint, not just at the end.

ANTI-PATTERN 5

Vendor says the model is ready to deploy. But monitoring isn't set up, documentation isn't complete, your team hasn't learned how to maintain it. You discover problems after "handoff."

How to avoid it: Define what "done" actually means. Include post-deployment support and knowledge transfer. Don't accept handoff until all of that is complete.

PRACTICE PROMPTS

EXERCISE 1

Develop a scorecard for evaluating AI vendor proposals. What criteria matter most? How would you score:

• Technical capability
• Fairness and governance maturity
• Approach to testing and validation
• Clarity of timeline and scope
• Risk mitigation

Weight the criteria. How would you aggregate scores?

EXERCISE 2

You're negotiating with a vendor. They propose:

• 6-month timeline for complete system
• You'll need to keep them for ongoing support
• Fairness testing is optional
• Model documentation will be "proprietary"

What's your response? What terms would you insist on?

EXERCISE 3

Write out the specific questions you'd ask in vendor interviews covering all five question groups. What answers would make you confident? What answers would concern you?

KEY TAKEAWAYS

• Vendor evaluation is as much about governance maturity as technical capability. Ask about fairness, testing, monitoring, and documentation.
• Vague vendor proposals are a red flag. Require detailed scope, sprint plans, and clear decision points.
• Fairness should be part of vendor requirements, not an afterthought. Make fairness testing and demographic analysis part of the contract.
• Avoid becoming dependent on vendors for ongoing maintenance. Insist on knowledge transfer and systems you can maintain independently.
• Contract terms matter. Include fairness requirements, documentation requirements, performance standards, and liability terms.
• Monitor vendor progress actively. Don't just check in at the end. Ensure they're meeting commitments throughout.
• Define what "done" means and don't accept incomplete work. Include post-deployment support and knowledge transfer in contract completion.
• Competitive procurement ensures you get the best vendor. Don't sign the first vendor that claims capability.

GLOSSARY

Vendor Capability Assessment: Evaluation of whether a vendor has the technical skills, governance maturity, and relevant experience to successfully deliver an AI project.

Key Person Risk: The risk that a project is dependent on one specific individual (expert), and project success is threatened if that person leaves.

Turn-Key Solution: A pre-built system that is sold as needing minimal customization or integration--a claiming that often indicates unrealistic vendor expectations.

Knowledge Transfer: Process by which vendor shares understanding of system architecture, maintenance procedures, and operational processes with government staff so they can maintain the system independently.

Proprietary Systems: Tools, code, or approaches that are owned and controlled by the vendor and cannot be modified or used independently by the client.

Vendor management is a critical governance function. The vendors you choose and how you manage them determines whether you get systems that work and that you can maintain. Good vendor management requires clear requirements, detailed contracts, active oversight, and knowledge transfer.

In practice, this means:

• You spend significant effort in vendor evaluation upfront
• You maintain active oversight throughout the project
• You insist on fairness testing and documentation
• You invest in your own team's capability so you're not dependent on vendors
• You treat the vendor relationship as a means to an end (capable system), not an end in itself

Agencies that manage vendors well get better systems and more control over those systems. Agencies that don't get locked into expensive vendor relationships and systems they can't maintain.

Reflect on a vendor relationship you've been part of (in government or elsewhere). What went well? What was challenging? How would better requirements or contract terms have improved the outcome? Use this reflection to develop intuition for what good vendor management looks like.

You've learned how to work with AI vendors and contractors effectively. The next lecture focuses on change management--how to help your organization actually use and adopt AI systems once they're deployed. Technical capability isn't enough; you also need organizational readiness. See you there.

Government AI CLUB Certification Program

Level 2: AI Ready | Working with AI Vendors and Contractors | Lecture 2.4.5

A GOVT.CLUB initiative

Visit: https://govt.club/learn/lectures/l2/245-working-with-vendors.html

======================================================================

<- 2.4.2 Requirements Gathering for AI
2.4.4 Testing and Validating AI Systems ->

Start Your CLUB Certification

This lecture is part of L2: AI Practitioner -- 40 hours of comprehensive government AI training.

Explore CLUB Certification

Related Lectures

L2
2.4.1 -- How AI Projects Differ from Traditional IT
60 min - Video + Comparison

L2
2.4.2 -- Requirements Gathering for AI
60 min - Workshop

L2
2.4.4 -- Testing and Validating AI Systems
60 min - Video + Lab