1.4 Stakeholders, roles & the AI lifecycle

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:

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:

1. 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?
2. Data. Collect, label, and prepare training data. Touchpoint: data governance — provenance, quality, representativeness, lawful basis, minimization, and bias review of the dataset.
3. Build / train. Develop and train the model. Touchpoint: documentation of design choices, model cards, and secure development practices.
4. 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.
5. Deploy. Release into production, often with human oversight configured. Touchpoint: user notices/transparency, human-in-the-loop gates, and phased rollout controls.
6. 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.
7. 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.