Skill.re
←
AI for Government
Proficient · M47 · lesson 47 of 53 · queued
Preview — browse every lesson free. Enroll to mark lessons complete, open partner links and save your progress. Login & enroll →
Third-Party AI Risk Management
📖
now learning

Third-Party AI Risk Management

15 min

Learning Objectives

After completing this lecture, you will be able to:

  • Understand the key concepts of third-party ai risk management in a government context
  • Connect third-party ai risk management to your agency's AI initiatives
  • Identify next steps for applying these concepts in your role

Key Topics Covered

-
Vendor risk assessment

-
Subcontractor oversight

-
Continuous monitoring of third-party 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 third-party ai risk management is essential for responsible, effective government AI adoption.

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

TRANSCRIPT: Third-Party AI Risk Management

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

Chapter: Chapter 2 -- Establishing an AI Governance Board

Learning Objectives: Assess third-party AI risks; implement vendor oversight; manage subcontractor compliance; establish continuous monitoring.

Government agencies rarely build AI systems entirely in-house. You use cloud providers for infrastructure, commercial ML platforms for model training, contractor firms for development, and consulting companies for guidance. Each third-party creates risks: they might mishandle data, deploy insecure systems, introduce biases, or fail to maintain systems. Managing third-party AI risks is one of the most critical and most neglected areas of government AI governance.

This lecture examines how to identify third-party AI risks, assess vendors rigorously, implement oversight mechanisms, and maintain continuous monitoring to catch problems before they become crises.

Purpose: Why Third-Party AI Risk Management Matters

The more of your AI system depends on third parties, the more risk you take on. A vendor's security failure becomes your security failure. A vendor's bias becomes your bias. A vendor's failure to maintain systems becomes your operational failure. Yet many government agencies have minimal oversight of third-party vendors.

Third-party AI risks are particularly acute because:

  • Vendors often have less stringent governance than government
  • Data flows to third parties outside government's direct control
  • You may not fully understand what vendors are doing with your data or models
  • Vendor failures (security breaches, service outages) directly impact government operations
  • Compliance with regulations (GDPR, CCPA, etc.) depends on vendor compliance

CORE CONCEPT 1: Identifying Third-Party AI Risks

Third-party risks fall into several categories:

Category 1: Data Risk

Vendors often have access to sensitive data (citizen data, government data, classified information). Risks include:

  • Data breaches: Vendor's security is inadequate; data stolen
  • Data misuse: Vendor uses government data for their own purposes
  • Data retention: Vendor retains data after contract ends
  • Data subject rights: Vendor can't fulfill citizen rights (right to access, deletion, etc.)

Example risk: You send citizen data to commercial cloud provider for training. Provider has a security breach. Citizens' data compromised.

Category 2: Model Risk

Vendors often train models using government data or deploy models affecting government operations. Risks include:

  • Model theft: Competitor steals model or vendor sells it to third parties
  • Model poisoning: Attacker corrupts training data, compromising model
  • Model bias: Vendor's model has unintended biases
  • Model quality: Vendor's model performs poorly or has unknown limitations

Example risk: You deploy vendor's AI system for benefits determination. System has undetected bias against protected group.

Category 3: Operational Risk

Vendors often operate systems affecting government operations. Risks include:

  • Service outages: Vendor's systems go down, affecting government operations
  • Inadequate support: Vendor doesn't respond to problems quickly
  • Change management: Vendor updates systems without adequate testing
  • Capacity: System doesn't scale to handle government's workload

Example risk: You rely on vendor's commercial ML platform. Platform has outage affecting all government users.

Category 4: Compliance Risk

Vendors often determine whether government meets legal/regulatory requirements. Risks include:

  • Regulatory non-compliance: Vendor's system doesn't meet regulatory requirements
  • Audit failure: Auditors conclude government's AI governance is inadequate because vendor lacks governance
  • Legal liability: Vendor's actions create legal liability for government
  • International compliance: Vendor doesn't comply with international requirements (EU AI Act, etc.)

Example risk: You procure commercial AI service from vendor outside EU. Service doesn't comply with EU AI Act. EU regulators hold your agency accountable.

Category 5: Supply Chain Risk

Vendors often depend on other vendors. Risks include:

  • Sub-vendor failures: Vendor's vendor fails, affecting your system
  • Dependency chains: Failure at bottom of chain causes cascade failures
  • Open-source risk: Vendor uses open-source with vulnerabilities
  • Third-party models: Vendor uses third-party AI models with unknown characteristics

Example risk: Vendor trains model using open-source libraries. Library has vulnerability. Your system is vulnerable.

CORE CONCEPT 2: Vendor Assessment Framework

Before engaging vendors, conduct comprehensive assessment:

Assessment 1: Security Assessment

Evaluate vendor's security practices:

  • Is vendor SOC 2 Type II certified or equivalent?
  • What security controls do they implement?
  • What's their incident response process?
  • How do they handle data breaches?
  • What's their encryption, access control, logging approach?

Red flags:

  • No formal security certifications
  • Can't articulate security controls
  • No incident response plan
  • Minimal access controls
  • No encryption by default

Assessment 2: Data Governance Assessment

Evaluate vendor's data practices:

  • How do they handle government data?
  • What data retention policies do they have?
  • Can they delete data on request?
  • How do they handle data subject rights?
  • Do they comply with privacy regulations?

Red flags:

  • Vendor wants to retain government data after contract
  • Can't guarantee deletion of sensitive data
  • No data retention policy
  • Can't fulfill data subject rights
  • Unclear compliance with privacy law

Assessment 3: Technical Assessment

Evaluate vendor's technical capabilities:

  • What's their development methodology?
  • How do they test systems?
  • What's their model governance?
  • How do they handle deployment and operations?
  • What's their monitoring and alerting?

Red flags:

  • No formal testing methodology
  • No model governance
  • Minimal monitoring
  • Inadequate deployment procedures
  • No incident response for technical failures

Assessment 4: AI Governance Assessment

Evaluate vendor's AI-specific governance:

  • Do they test for bias?
  • Do they document fairness metrics?
  • Do they conduct adversarial testing?
  • Do they have transparency/explainability procedures?
  • Do they have AI incident response?

Red flags:

  • No fairness testing
  • Can't articulate fairness metrics
  • No adversarial testing
  • Claims "explainability not possible"
  • No AI-specific incident response

Assessment 5: Compliance Assessment

Evaluate vendor's compliance with applicable regulations:

  • GDPR compliance (if serving EU citizens)
  • CCPA compliance (if handling California resident data)
  • Industry-specific compliance (HIPAA for health, GLBA for finance, etc.)
  • Government standards (NIST CSF, ISO 27001, etc.)

Red flags:

  • No formal compliance program
  • Can't document compliance with applicable regulations
  • Won't undergo audits or certifications
  • Compliance appears to be afterthought

Assessment 6: Financial Assessment

Evaluate vendor's financial viability:

  • Is vendor financially stable?
  • What's their growth trajectory?
  • What's their customer base?
  • Are they dependent on government contracts?
  • Is pricing sustainable?

Red flags:

  • Vendor is startup with minimal funding
  • Pricing appears unsustainably low
  • Customer base is very small
  • Vendor dependent on government contracts
  • Recent negative financial news

CORE CONCEPT 3: Contract Requirements for Third-Party Management

Every vendor contract should include requirements managing third-party risks:

Requirement 1: Security Requirements

"Vendor shall implement security controls meeting [NIST CSF / ISO 27001 / equivalent standard]. Vendor shall: (a) undergo annual third-party security audits (SOC 2 Type II or equivalent); (b) report any security incidents affecting government data within [24] hours; (c) maintain encryption of sensitive data in transit and at rest; (d) implement access controls limiting access to authorized personnel only."

Requirement 2: Data Rights and Retention

"Vendor shall: (a) use government data only for purposes authorized by this contract; (b) not use government data for vendor's own purposes or derivative products; (c) maintain data only for duration of contract plus [30] days retention period; (d) return or destroy all government data upon contract termination; (e) provide government with signed certification confirming data deletion."

Requirement 3: Data Subject Rights

"Vendor shall: (a) fulfill data subject access requests within [15] business days; (b) fulfill data deletion requests within [30] days; (c) comply with data subject rights under [GDPR / CCPA / applicable law]; (d) not limit government's ability to fulfill data subject rights; (e) document and report any data subject requests to government."

Requirement 4: Subcontractor Management

"Vendor shall: (a) document all subcontractors having access to government data; (b) obtain government approval before engaging subcontractors; (c) require subcontractors to meet same security and data handling requirements as vendor; (d) remain accountable for subcontractor compliance; (e) audit subcontractors for compliance at least annually."

Requirement 5: Transparency and Auditability

"Vendor shall: (a) provide government with access to system logs and audit trails; (b) document all data accessed by vendor personnel; (c) provide government with regular compliance certification; (d) permit government and government-authorized auditors to audit vendor's practices; (e) document any changes to systems affecting government data."

Requirement 6: Incident Response and Reporting

"Vendor shall: (a) maintain documented incident response procedures; (b) notify government of any incident affecting government data within [24] hours; (c) provide government with incident investigation details within [5] business days; (d) cooperate with government investigations; (e) provide remediation plan for preventing recurrence."

Requirement 7: Service Level Agreements (SLAs)

"Vendor shall maintain: (a) Availability: System available [99.9]% of time measured monthly; (b) Performance: Response time <[X] milliseconds for [Y]% of requests; (c) Support: Critical issues addressed within [4] hours, non-critical within [24] hours; (d) Remedies: If vendor fails to meet SLAs, government receives service credits equal to [X]% of monthly fees for each [Y]% of missed availability."

Requirement 8: AI Governance and Fairness

"Vendor shall: (a) test systems for bias and document results quarterly; (b) maintain transparency documentation explaining how AI system works; (c) implement explainability mechanisms allowing government to understand AI decisions; (d) document model limitations and failure modes; (e) maintain model provenance documentation."

CORE CONCEPT 4: Continuous Vendor Monitoring

Assessment at contract start is insufficient. Ongoing monitoring catches problems early:

Monitoring 1: Performance Monitoring

Track vendor's operational performance:

  • Are SLAs being met? (uptime, performance, support response time)
  • Is system reliable or experiencing frequent outages?
  • What's the ticket resolution rate? How quickly are issues fixed?
  • Are there recurring issues indicating systemic problems?

Action: If vendor consistently misses SLAs, escalate and demand improvement plan.

Monitoring 2: Security Monitoring

Track vendor's security posture:

  • Has vendor had security incidents? What was response?
  • Are vendor's security certifications current?
  • Has vendor undergone recent security audits? What were findings?
  • Are vendor's security practices improving or declining?

Action: If vendor has concerning security issues, require remediation plan or consider switching vendors.

Monitoring 3: Compliance Monitoring

Track vendor's regulatory compliance:

  • Does vendor remain compliant with applicable regulations?
  • Have there been regulatory findings or violations?
  • Are compliance certifications (SOC 2, ISO 27001, etc.) current?
  • Is vendor maintaining documented compliance?

Action: If vendor fails compliance audits, require corrective action.

Monitoring 4: Financial Monitoring

Track vendor's financial health:

  • Is vendor financially stable?
  • Have there been major corporate changes?
  • Is vendor's pricing sustainable?
  • Are there signs of financial distress?

Action: If vendor's financial health declines, develop contingency plan in case vendor fails.

Monitoring 5: Data Handling Monitoring

Track vendor's data practices:

  • How much government data does vendor hold?
  • How long is data retained?
  • Has vendor had data breaches?
  • Is vendor deleting data as required?
  • Are data subject requests being fulfilled?

Action: If vendor isn't meeting data handling requirements, require immediate remediation.

Monitoring 6: Fairness and AI Performance Monitoring

Track vendor system's AI performance:

  • Is system fairness stable or degrading?
  • Are there complaints about bias?
  • Is system performance (accuracy, latency) stable?
  • Are there unexplained performance changes?

Action: If system performance degrades, require vendor to investigate and remediate.

Monitoring Cadence

  • Monthly: Performance metrics (uptime, response time), security incidents, service tickets
  • Quarterly: Compliance certifications, security audit status, fairness metrics
  • Annually: Comprehensive vendor assessment, compliance audit, security audit, financial review

CORE CONCEPT 5: Subcontractor Management

Vendors often use subcontractors (other vendors to do work). You're liable for subcontractor failures even though subcontractors aren't in your contracts.

Subcontractor Risk Management:

Step 1: Document All Subcontractors

Require vendor to provide:

  • List of all subcontractors having access to government data
  • What each subcontractor does
  • What data/systems they have access to
  • Where subcontractors operate (geographic location)

Step 2: Apply Same Requirements to Subcontractors

Vendor contract should state: "Vendor shall require subcontractors to meet same security, data handling, compliance, and AI governance requirements as vendor."

Step 3: Audit Subcontractors

Vendor should audit subcontractors annually to ensure compliance. Government should audit vendor's subcontractor audits.

Step 4: Manage Subcontractor Changes

Require vendor to notify government before changing subcontractors and to obtain government approval.

Example Risk: Vendor outsources data processing to subcontractor in jurisdiction with weak privacy protections. Subcontractor has data breach. You're liable even though you never contracted with subcontractor.

Use Case 1: Cloud Provider Risk Management

Scenario: Government agency uses commercial cloud provider (AWS, Azure, GCP) for AI system development and deployment. Needs comprehensive vendor management.

Risk Assessment:

  • Major cloud providers are relatively low-risk (strong security, established governance) but remain significant risks (data exposure, service outages, compliance issues)
  • Government must establish governance boundaries: what can cloud provider access? How long can they retain data? What compliance requirements apply?

Vendor Management Approach:

  • Security Requirements
  • Require vendor to maintain SOC 2 Type II certification (annual audit)
  • Require vendor to implement NIST CSF controls
  • Require vendor to report security incidents within 24 hours
  • Require vendor to maintain encryption of data in transit and at rest
  • Data Governance
  • Government specifies: Data can be used only for this specific project
  • Require vendor to delete data within 30 days of contract end
  • Prohibit vendor from using government data for vendor's own ML model training
  • Require vendor to provide audit logs showing who accessed what data when
  • Compliance
  • If serving EU citizens: Require GDPR compliance; require Standard Contractual Clauses for data transfers
  • Require vendor to undergo annual third-party compliance audits
  • Require vendor to maintain current compliance certifications
  • Monitoring
  • Monthly: Review service metrics (uptime, performance); review security incident reports
  • Quarterly: Review vendor's SOC 2 audit findings; review fairness metrics of systems operating on cloud
  • Annually: Comprehensive vendor assessment; negotiate contract renewals

Outcome: Cloud provider remains primary infrastructure; government has clear governance ensuring security and compliance.

Use Case 2: ML Platform Vendor Risk Management

Scenario: Government agency procures commercial ML platform (vendor-provided platform for training and deploying models). Platform is critical to multiple government AI systems. Needs careful vendor management.

Risk Assessment:

  • Medium-to-high risk: Platform is critical; failure affects all dependent systems
  • Platform vendor has access to training data, models, and system logs
  • Platform vendor makes updates affecting all users; updates could introduce security vulnerabilities or reduce performance

Vendor Management Approach:

  • Security Assessment and Ongoing Monitoring
  • Require vendor to maintain SOC 2 Type II certification
  • Require vendor to demonstrate NIST Cybersecurity Framework compliance
  • Quarterly: Review vendor's security incident reports; assess any incidents affecting government systems
  • Data Governance
  • Establish clear data boundaries: Government owns all training data and models
  • Prohibit vendor from using government data for their own purposes or to train vendor products
  • Require vendor to implement data isolation: Government's data/models isolated from other customers
  • Require vendor to delete all government data upon contract end
  • Subcontractor Management
  • Require vendor to document all subcontractors
  • Common issue: ML platform vendors use cloud providers (AWS, Azure, GCP). Ensure cloud provider also meets your requirements
  • Require vendor to audit subcontractors for compliance
  • Performance and Availability
  • Establish SLAs: Platform must be available 99.9% of time; performance must meet targets
  • Monitor monthly: Is vendor meeting SLAs? If not, what's impact?
  • If vendor frequently misses SLAs, escalate and demand improvement or switch vendors
  • AI Governance
  • Require vendor to document platform's fairness characteristics (known biases, performance across demographic groups)
  • Require vendor to document platform's model interpretability (how explainable are trained models?)
  • Monitor: Do systems trained on vendor's platform have unexpected biases?

Outcome: Platform remains reliable vendor infrastructure; government maintains clear governance ensuring security, compliance, and performance.

Anti-Pattern 1: Inadequate Vendor Assessment

Risk: You engage vendors without proper assessment, discovering problems only after systems are in production.

Why this happens: Pressure to move quickly. Assessment takes time. You engage vendor before completing assessment.

What goes wrong:

  • Vendor is incompetent or untrustworthy
  • Vendor's systems are insecure
  • Vendor mishandles government data
  • Vendor doesn't comply with regulations
  • You discover problems too late to switch vendors

How to avoid:

  • Never engage vendors without comprehensive assessment
  • Assessment should include security, data governance, compliance, technical capability, financial viability
  • Require references from other government agencies who use vendor
  • Require vendor to undergo third-party audits or certifications

Anti-Pattern 2: Ignoring Subcontractor Risks

Risk: Vendor uses subcontractors you haven't vetted. Subcontractor fails or mishandles data. You're liable.

Why this happens: You contract with vendor but don't ask who their subcontractors are. Vendor uses vendors you would have rejected.

What goes wrong:

  • Subcontractor has data breach
  • Subcontractor is incompetent
  • Subcontractor is in hostile foreign jurisdiction
  • You're liable even though you never contracted with them

How to avoid:

  • Require vendor to document all subcontractors
  • Require government approval before vendor engages subcontractors
  • Require vendor to impose same requirements on subcontractors as you impose on vendor
  • Audit vendor's subcontractors

Anti-Pattern 3: No Continuous Monitoring

Risk: After contract start, you don't monitor vendor, discovering problems months or years later.

Why this happens: Assessment is one-time. Vendors aren't monitored continuously. Problems accumulate.

What goes wrong:

  • Vendor's security posture degrades
  • Vendor has security breaches you don't know about
  • Vendor stops meeting SLAs
  • Vendor violates compliance requirements

How to avoid:

  • Implement continuous monitoring (monthly, quarterly, annually)
  • Track performance metrics, security incidents, compliance status
  • Review monitoring results regularly
  • Escalate problems immediately rather than allowing them to accumulate

Practice Prompt 1: Vendor Assessment

Conduct assessment of a vendor you currently use or are considering:

  • Security: Does vendor meet security standards? What certifications do they have?
  • Data Governance: How does vendor handle government data? Can they delete it?
  • Compliance: Does vendor comply with relevant regulations?
  • Technical: What's vendor's technical capability?
  • Financial: Is vendor financially viable?

Rate each area 1-5 (1=inadequate, 5=excellent). Would you contract with this vendor?

Practice Prompt 2: Contract Requirements

Draft contract requirements for critical vendor engagement:

  • Security requirements: What security standards must vendor meet?
  • Data rights: What data rights does government have?
  • Compliance: What regulations must vendor comply with?
  • Subcontractor management: How will vendor manage subcontractors?
  • Monitoring: How will you monitor vendor?

Practice Prompt 3: Monitoring Plan

Develop quarterly monitoring plan for a critical vendor:

  • What metrics will you track? (uptime, security, compliance, etc.)
  • How often will you monitor? (monthly, quarterly, annually)
  • What are acceptable ranges for each metric?
  • What triggers escalation?
  • Who reviews monitoring results?

Key Takeaways

  • Third-Party Risks Are Real: Vendor failures directly impact government. Take vendor management seriously.
  • Comprehensive Assessment Before Contract: Assess vendor security, data governance, compliance, technical capability, and financial viability before engaging.
  • Include AI Governance Requirements: Require vendors to test for bias, maintain fairness metrics, document explainability, and manage AI-specific risks.
  • Data Rights Are Non-Negotiable: Contract must specify government owns data and vendor can't use it after contract ends.
  • Continuous Monitoring Catches Problems Early: Monthly and quarterly monitoring catches vendor issues before they become crises.
  • Manage Subcontractors: Vendor's vendors create risks you're liable for. Require vendor to assess and monitor subcontractors.
  • Be Willing to Switch Vendors: If vendor consistently fails to meet requirements, switch. Staying with problematic vendors is riskier than switching.

Glossary

Third-Party Risk: Risk created by engagement with external vendor or contractor.

Vendor Assessment: Comprehensive evaluation of vendor's security, compliance, technical capability, and financial viability before engagement.

SOC 2 Type II: Third-party security audit verifying vendor's security controls are effective over time.

Data Retention: How long vendor maintains government data after contract completion.

Data Subject Rights: Citizens' rights under privacy law (right to access, deletion, explanation, etc.).

SLA: Service Level Agreement specifying vendor's performance commitments (availability, response time, etc.).

Subcontractor: Vendor hired by your vendor to perform work.

Third-party AI risk management is foundational to government AI governance. If you can't govern third-party vendors, you can't govern your AI systems. The most sophisticated government AI governance is undermined by poor vendor management.

The key insight is that vendors aren't just service providers--they're extensions of your governance. When you engage a vendor, you're extending your governance boundary to include them. Poor vendor governance is governance failure on your part.

Organizations that manage vendors well do four things consistently: (1) comprehensive assessment before engagement, (2) clear contractual requirements addressing risks, (3) continuous monitoring catching problems early, and (4) willingness to switch vendors when they consistently fail. These practices catch problems before they become crises.

  • Which vendors are critical to your AI systems? What risks does each create?
  • For your highest-risk vendor, how robust is your governance? What's missing?
  • If a critical vendor failed today (service outage, data breach, compliance violation), what would be impact?
  • Are you monitoring vendors continuously or only at contract start?

Effective third-party AI risk management prevents crises before they happen. It requires upfront work (assessment, contracting, monitoring setup) but prevents expensive problems later. The agencies managing vendors effectively are investing time upfront to save time and trouble later.

Government AI CLUB Certification Program

Level 3: AI Practitioner | Third-Party AI Risk Management | Lecture 2.5

A GOVT.CLUB initiative.

<- 3.2.9 AI Audit Preparation
3.2.11 International Standards: EU AI Act and OECD ->

Start Your CLUB Certification

This lecture is part of L3: AI Strategist -- 80 hours of comprehensive government AI training.

Explore CLUB Certification

L3
3.2.1 -- Establishing an AI Governance Board
90 min - Lecture + Charter Template

L3
3.2.2 -- OMB M-24-10 Deep Dive: Full Implementation
120 min - Workshop

L3
3.2.3 -- OMB M-24-18 and AI Procurement Governance
90 min - Lecture + Workshop