1.4 Stakeholders, roles & the AI lifecycle

IAPP Artificial Intelligence Governance Professional AIGP

Track your progress as you read

Finished sections get a check mark.

1 Overview & AI Governance Foundations

1.1 AIGP exam facts & study strategy 1.2 What AI is: ML, deep learning & generative AI 1.3 Responsible AI principles 1.4 Stakeholders, roles & the AI lifecycle

2 Laws & Regulations Applying to AI

2.1 Existing law applied to AI: privacy, data protection & IP 2.2 Discrimination, consumer protection & liability 2.3 AI-specific laws: the EU AI Act & the US landscape

3 Standards & Frameworks

3.1 The OECD AI Principles 3.2 The NIST AI Risk Management Framework 3.3 ISO/IEC standards & assurance/audit

4 Governing AI Development

4.1 Use-case definition & impact/risk assessment 4.2 Design & build controls 4.3 Data governance: quality, bias & provenance 4.4 Training, testing & release readiness

5 Governing AI Deployment & Use

5.1 Deployment decisions & human oversight 5.2 Vendor & third-party risk review 5.3 Post-market monitoring & incident response 5.4 User controls, transparency & downstream-harm mitigation

6 Operationalizing AI Governance

6.1 Building an AI governance program & maturity models 6.2 Documentation, traceability & continuous improvement

1.4 Stakeholders, roles & the AI lifecycle

Key Takeaways Explain This Topic AI

The EU AI Act distinguishes providers (who develop and place systems on the market) from deployers (who use them under their authority).

Affected individuals bear the consequences of AI outputs without being parties to the contract, which is why contestability and redress exist.

Value-chain roles can shift: a deployer that substantially modifies or rebrands a high-risk system can take on provider obligations.

Internal governance follows three lines: model/product owners operate, risk/compliance/privacy/legal oversee, and internal audit independently assures.

Governance touchpoints attach to every lifecycle stage from plan/design through data, build, test, deploy, monitor, and retire, with monitoring catching drift.

Last updated: July 2026

The AI value chain and its actors

AI governance depends on knowing who does what , because obligations and accountability attach to specific roles. Emerging law, especially the EU AI Act, draws sharp lines between actors in the AI value chain:

Provider (developer). The entity that develops an AI system (or has one developed) and places it on the market or puts it into service under its own name. Providers bear the heaviest obligations — building in risk management, documentation, data governance, and transparency before release.

Deployer (user). The entity that uses an AI system under its authority in a professional context (the Act's term is "deployer"; earlier drafts said "user"). Deployers must use systems as intended, ensure human oversight, and monitor operation — a bank using a vendor's credit model is a deployer.

Affected individuals. The people subject to an AI system's outputs — applicants, patients, defendants, consumers. They are not parties to the contract but bear the consequences, which is why contestability and redress exist.

Data providers. Parties supplying the training or input data. Data provenance, licensing, quality, and consent flow from them and shape downstream risk.

Other value-chain roles the exam may reference include importers and distributors (who place or make available systems in a market), plus the distinction between a general-purpose/foundation-model provider and the downstream developer who fine-tunes or embeds it. A crucial governance point: roles can shift. If a deployer substantially modifies a high-risk system or puts its own name on it, it can take on provider obligations. Getting the role right determines who is accountable.

Internal governance roles

Inside an organization, responsible AI is a team sport, usually structured along the "three lines" model. Key roles:

• Role Governance responsibility
• Board / senior leadership Set risk appetite, approve AI policy, hold ultimate accountability
• AI governance committee Cross-functional body that reviews use cases, sets standards, escalates
• Model / product owner Accountable for a specific system across its lifecycle (first line)
• Data science / engineering Build, test, and document models (first line)
• Risk & compliance Assess and monitor risk against policy and law (second line)
• Privacy office Data protection, DPIAs, lawful data use (second line)
• Legal Interpret obligations, negotiate contracts, manage liability (second line)
• Security Protect models and data from attack (second line)
• Internal audit / assurance Independently verify that controls work (third line)

The pattern mirrors mature risk programs: the first line owns and operates the system, the second line sets policy and oversees, and the third line independently assures. Many organizations also appoint a senior accountable individual (sometimes a Chief AI Officer) and use the AI governance committee as the forum where legal, privacy, security, ethics, and business perspectives meet before a system is approved. Clear, RACI-style ownership prevents the accountability gaps that responsible-AI principles warn against.

The AI system lifecycle and governance touchpoints

Governance is most effective when it is built into every stage of the AI lifecycle rather than bolted on at the end — a "governance by design" approach echoing privacy by design. A representative lifecycle and its touchpoints:

Plan / design. Define the problem, intended use, and success criteria. Touchpoint: initial risk triage and an impact assessment — is this use prohibited, high-risk, or low-risk? Should it be built at all?

Data. Collect, label, and prepare training data. Touchpoint: data governance — provenance, quality, representativeness, lawful basis, minimization, and bias review of the dataset.

Build / train. Develop and train the model. Touchpoint: documentation of design choices, model cards, and secure development practices.

Test / validate. Evaluate performance, fairness, robustness, and security. Touchpoint: bias and accuracy testing against defined metrics, red-teaming, and a go/no-go review before release.

Deploy. Release into production, often with human oversight configured. Touchpoint: user notices/transparency, human-in-the-loop gates, and phased rollout controls.

Monitor / operate. Run the system and watch it over time. Touchpoint: ongoing monitoring for drift , performance decay, incidents, and new bias; feedback and contestability channels; periodic re-assessment.

Retire / decommission. End-of-life the system. Touchpoint: data retention/deletion, record-keeping, and managing dependencies that relied on it.

Two ideas make this domain exam-relevant. First, risk is not static : a model that was fair and accurate at launch can degrade as the world changes (data or concept drift ), which is why monitoring and re-validation are mandatory, not optional. Second, touchpoints map to roles : the data stage engages the privacy office and data providers; the test stage engages risk and the model owner; the monitor stage engages operations and audit. A well-run program assigns a named owner and a documented control at every stage, creating the audit trail that accountability and law require. Note too that the lifecycle is a loop, not a straight line : monitoring often surfaces a problem that sends the system back to the data or build stage for retraining, so governance controls must be applied iteratively rather than once. For the exam, practice reading a scenario and immediately identifying three things: which actor (provider vs. deployer), which lifecycle stage , and which governance role should act. That triangulation — actor, stage, role — is the practical skill this domain certifies.