- Your stakeholder register is incomplete if it only lists people involved in the project. NIST AI RMF distinguishes users who interact with the system from affected individuals who experience its impacts without ever touching it. Both groups need to be identified and actively engaged.
- EU AI Act Article 27 requires deployers of high-risk AI to complete a Fundamental Rights Impact Assessment identifying which groups of people are likely to be affected — before deployment. This is a structured identification requirement, and it belongs in your project plan.
- Engaging affected communities is not a one-time activity. NIST AI RMF MAP 5.1 and 5.2 require regular ongoing engagement and feedback integration throughout the lifecycle — not only during design.
- EU AI Act Article 86 gives affected people the right to a clear explanation of any AI-based decision that significantly affects them. Designing the explanation mechanism is a project deliverable. If it's not in scope from the start, it usually doesn't get built.
Stakeholder management is familiar territory for any PM — identify stakeholders, assess their interest and influence, plan your engagement, communicate throughout. All of that still applies for AI projects. What changes is who counts as a stakeholder.
AI systems affect people who will never appear on your stakeholder register. The loan applicant who never speaks to a human. The job seeker filtered out before any human sees their resume. The customer whose service calls are being scored. None of these people are your users or sponsors — but your system's decisions may shape their lives. Under the EU AI Act, telling them about that and giving them a way to challenge it is a legal obligation.
The Expanded Stakeholder Universe
Traditional stakeholder analysis covers the people involved in the project. AI projects require thinking about people affected by the system — a very different set. Conflating the two is one of the most common governance gaps in AI project management.
Traditional Project Stakeholders
These still matter and your existing engagement approach applies.
| Stakeholder | Role |
|---|---|
| Sponsor | Provides funding and authority; accountable for strategic direction |
| Business owner | Accountable for business outcomes and operational impact |
| Project team | Builds the system; carries the most direct influence over design decisions |
| End users | Operates the deployed system; primary source of usability feedback |
| IT/Operations | Maintains and supports; critical input on integration and monitoring feasibility |
| Legal/Compliance | Advises on regulatory requirements; must be engaged early, not only at gate reviews |
AI-Specific Stakeholders
These groups need to be explicitly added to your register. NIST AI RMF distinguishes between end users (who interact with the system) and affected individuals and communities (who experience its consequences). Both require active identification and ongoing engagement throughout the lifecycle.
| Stakeholder | Why They Matter for AI Governance |
|---|---|
| Affected individuals | People subject to AI decisions who may never interact with the system directly — loan applicants, job seekers, benefits recipients. EU AI Act Article 86 gives them a right to explanation of decisions that significantly affect them. |
| Affected communities | Groups that may experience differential impacts — often visible only through disaggregated performance analysis, not individual feedback. UNESCO's AI Ethics Recommendation requires measures to allow meaningful participation by marginalised groups. |
| Data subjects | People whose data trains or feeds the system. They may have consented to data collection for a different purpose than the AI use you are now implementing — a consent and provenance question, not only a privacy one. |
| Domain experts | Provide context that your technical team cannot generate internally. NIST AI RMF MAP 1.6 notes that targeted consultation with subject matter experts can help identify potential negative impacts not previously considered. |
| AI ethics/governance | Internal review and oversight function — if your organization has one. If it doesn't, this is a gap to flag to your sponsor, not a gap to work around. |
| Regulators | External oversight, sector-specific compliance obligations, and in some cases mandatory pre-deployment notification — EU AI Act Article 27 requires deployers to notify market surveillance authorities of fundamental rights impact assessment results. |
| Downstream deployers | Organizations that integrate your AI into their own systems inherit outputs you produced. Their use cases may create impacts you did not anticipate when you built the system. |
Identifying Affected Parties
The stakeholders who are hardest to identify are often the ones who matter most. They have no direct relationship with your project, no seat at the table, and no reason to reach out. You have to actively go and find them.
Questions to Surface Affected Parties
Work through these questions systematically at project initiation, and revisit them as scope evolves.
| Dimension | Questions to Ask |
|---|---|
| Decision scope | What decisions will this system make or influence? Who is subject to those decisions? Who benefits from favorable decisions, and who is harmed by unfavorable ones? |
| Data sources | Whose data trains the system? Whose data feeds it in operation? Did those people consent to this use of their data, or was it collected for a different purpose? |
| Differential impact | Could certain groups experience systematically different outcomes? Who is underrepresented in training data? Who might be disadvantaged by design assumptions built into the system? |
| Downstream effects | Who else uses the system's outputs? What decisions do they make based on those outputs? Who is affected by those downstream decisions, and does your project have visibility of that chain? |
Worked Example: AI Hiring Tool
The same system has multiple, distinct affected party categories — each requiring a different engagement approach.
| Stakeholder Type | Who They Are in an AI Hiring Context |
|---|---|
| End users | Recruiters using the tool day-to-day — traditional stakeholders, engaged through user research and training |
| Affected individuals | All job applicants screened by the system, including those who never know they were filtered out |
| Affected communities | Groups underrepresented in training data; people with non-traditional career paths; candidates from geographies or backgrounds the training data didn't adequately cover |
| Data subjects | Employees whose historical performance data trained the model — they did not consent to being training data for a hiring algorithm |
| Domain experts | Industrial-organizational psychologists; employment lawyers; labour relations specialists |
| Regulators | Equal employment opportunity bodies; state civil rights agencies; data protection authorities |
EU AI Act Article 27 requires deployers of high-risk AI to complete a Fundamental Rights Impact Assessment before deployment. It must identify which categories of people are likely to be affected and what specific risks of harm they face. The stakeholder categories in the hiring example above are exactly what that assessment needs to produce.
Engagement Methods
Not all stakeholders need the same type of engagement. The right approach depends on how much they're affected, what level of participation makes sense, and where in the project lifecycle their input is most relevant.
Engagement Levels
Match the depth of engagement to the stakeholder. How much are they affected? How much can your organization meaningfully incorporate their input? Those two questions determine the appropriate level.
| Level | Description | When to Use |
|---|---|---|
| Inform | One-way communication about the project and system | Low-influence stakeholders; general awareness of a system's existence and purpose |
| Consult | Gather input, feedback, or concerns; you retain decision authority | Subject matter experts; affected communities providing input on design choices |
| Involve | Active participation in specific decisions; input shapes outcomes | Key stakeholders with legitimate interests in how the system is designed |
| Collaborate | Partnership in design and implementation; shared decision-making | High-influence, high-interest stakeholders; governance bodies |
| Empower | Delegate decision authority to the stakeholder | Ethics review boards; formal oversight bodies with sanctioned authority |
NIST AI RMF warns specifically against participation washing — consulting communities without their input actually changing anything. To have governance value, engagement needs to be honest about its scope: what decisions it can influence, and what has already been decided. People can tell the difference.
Methods by Stakeholder Type
| Stakeholder Type | Recommended Engagement Methods |
|---|---|
| Internal teams and sponsors | Standard project communication — status reports, steering committee, design reviews, and formal decision gates. No change from conventional PM practice. |
| End users | User research and usability testing during design; training and change management pre-deployment; structured feedback channels post-deployment. Feedback must be integrated into system updates, not only acknowledged. |
| Affected individuals and communities | Focus groups with representative populations; public comment periods for high-impact systems; community advisory boards with ongoing engagement (not one-off consultation); user studies conducted with informed consent and appropriate compensation per NIST AI 600-1. |
| Domain experts | Consultation during design to identify impacts not visible to the technical team; review of system outputs and edge cases during testing; participation in TEVV activities where their domain knowledge is material to interpreting results. |
| Regulators | Proactive engagement where mandatory (EU AI Act Article 27 notification); documentation and transparency practices that satisfy disclosure obligations; structured incident reporting on the cadence required by applicable regulation. |
The Positionality Exercise
NIST AI RMF recommends examining your own team's perspective and potential blind spots as a formal part of stakeholder engagement. This is not a DEI exercise bolted onto governance — it is a risk identification exercise. The people who build a system determine what gets tested, whose use cases are treated as the default, and which edge cases are visible enough to be addressed.
A homogeneous team doesn't miss things through negligence — it misses things because those failure modes are invisible from a single vantage point. NIST AI 600-1 calls for diverse red teams precisely because who is on the team determines what gets found.
| Question | What It Surfaces |
|---|---|
| Who is on our team, and what perspectives do we bring? | The default assumptions that are likely to be embedded invisibly in design decisions — about who the user is, what a normal input looks like, what a good outcome means |
| Whose perspectives are missing? | The populations whose use cases are most likely to produce edge cases, failure modes, or disparate outcomes that the current team won't anticipate |
| What assumptions are we making about users and affected parties? | Unstated design decisions that should be explicit and reviewed — assumptions about literacy, language, internet access, document types, workflow patterns |
| How might our backgrounds shape the system's design? | Embedded values that the system will put into practice, often without anyone explicitly deciding that it should |
| Are we representative of the populations affected by this system? | Whether the team has standing to make design decisions on behalf of the affected population, or whether external input is necessary to fill the gap |
The goal isn't a perfectly diverse team — it's recognizing where the blind spots are and actively seeking the perspectives that are missing. Every gap you identify becomes a project input: who else needs to be in the room, and when?
Feedback Mechanisms
Engagement doesn't end when the system goes live. You need ongoing channels for people to report problems and contest decisions. NIST AI RMF MEASURE 3.3 is explicit: feedback from affected parties must be integrated into your evaluation metrics. A feedback channel isn't a customer service feature — it's a governance tool.
Structured Feedback Approaches
NIST AI 600-1 identifies four approaches that serve different purposes and deployment stages.
| Approach | When and How to Use It |
|---|---|
| Participatory engagement | Focus groups, user studies, surveys — used in early design stages to gather input on intended use, potential impacts, and design choices. Best carried out by personnel with expertise in qualitative methods who can translate community feedback for technical audiences. |
| Field testing | Structured evaluation of how people interact with the system in realistic conditions, with real users rather than internal testers. Surfaces issues that controlled testing misses. Requires informed consent and human subjects protections where applicable. |
| Red-teaming | Structured adversarial exercises to identify potential harms. NIST AI 600-1 requires demographically diverse red teams because team composition determines what gets found. Results require analysis before incorporation into governance decisions. |
| Production feedback channels | Ongoing mechanisms for users and affected parties to report problems after deployment. Must be accessible, offer anonymity options where retaliation is a risk, include a defined response process, and close the loop with those who raised issues. |
Feedback Channel Design Requirements
A feedback channel that people cannot access, or fear using, or that produces no visible response, has no governance value. Design choices matter.
| Design Element | What It Requires in Practice |
|---|---|
| Accessibility | Can affected parties actually reach the channel? Is it available in relevant languages, accessible to people with disabilities, reachable without requiring system account creation? |
| Anonymity options | Will people fear retaliation for reporting problems? Employees reporting AI-related concerns about workplace systems face particular risk. Anonymity mechanisms must be genuine, not nominal. |
| Response process | How will feedback be triaged, assessed, and addressed? Who owns the response? What is the SLA? A feedback channel with no documented response process is a liability, not a governance mechanism. |
| Closure loop | How will you communicate back to those who raised issues? Affected parties who report a problem and hear nothing will not report again — and silence signals the channel is performative. |
| Integration with system updates | How does feedback inform model updates, policy changes, or operational adjustments? MEASURE 3.3 requires feedback to be integrated into evaluation metrics, not siloed in a support queue. |
Communication Planning
Your communication plan has to cover more than project status. Regulatory frameworks define specific disclosures that must happen — what must be communicated, to whom, and when. These are legal requirements, not optional transparency gestures.
Required Communications by Framework
| Communication Type | Framework Requirement |
|---|---|
| Notification that AI is involved in a decision | EU AI Act Recital 93: deployers of high-risk AI systems must inform affected persons that they are subject to the use of a high-risk AI system, including its intended purpose and the type of decisions it supports. |
| Right to explanation | EU AI Act Article 86: affected persons have the right to a clear and meaningful explanation of the role of the AI system in any decision that produces legal effects or significantly affects their health, safety, or fundamental rights. The deployer must provide this on request. |
| Worker notification | EU AI Act Recital 92: employers have an information obligation to workers or their representatives regarding planned deployment of high-risk AI systems at the workplace — in addition to existing national labour law obligations. |
| Regulator notification | EU AI Act Article 27: deployers who perform a Fundamental Rights Impact Assessment must notify the results to the relevant market surveillance authority. |
| Incident communication | NIST AI RMF MANAGE 4.1 and EU AI Act post-market monitoring obligations: how will you communicate when things go wrong, to users, affected parties, and regulators, and on what timeline? |
Tailoring Communication by Audience
The same facts need to be communicated very differently depending on the audience. What makes sense for an executive decision doesn't make sense for someone trying to understand why the AI made a decision about them.
| Audience | Communication Needs |
|---|---|
| Executives | Risk profile, compliance status, business impact, residual risks accepted — sufficient to support informed governance decisions without requiring technical depth |
| Technical teams | System specifications, performance metrics against defined thresholds, known limitations, monitoring requirements — sufficient to build, maintain, and improve the system responsibly |
| End users | How to use the system effectively, how to override or escalate, when the system's output should not be trusted without verification — practical operational guidance, not a manual |
| Affected parties | What the system does, how it affects them specifically, what the grounds were for a decision about them, and how to contest that decision — EU AI Act Article 86 sets the standard: clear and meaningful, not technical |
| Regulators | Technical documentation, TEVV results, fundamental rights impact assessment, incident reports, and compliance evidence — in the form and on the timeline that applicable law requires |
Continuous Engagement
Stakeholder engagement isn't a project phase that closes — it's a continuous process. NIST AI RMF is explicit: meaningful engagement starts at the very beginning of commissioning and runs through the end of the lifecycle.
The reasons for this are structural. AI systems can drift and change behavior over time — communities not experiencing adverse outcomes at deployment may experience them after model updates or data distribution shifts. New affected parties may emerge as use expands. Regulations evolve. Incidents reveal previously unknown impacts. And affected communities may not surface concerns immediately; trust must be built before concerns are shared, which takes time and consistent follow-through.
NIST AI RMF MEASURE 4.3 requires that consultations with affected communities produce measurable outputs — documented improvements or identified declines in performance. Consultation that doesn't feed back into anything has no governance value.
| Ongoing Touchpoint | What It Should Produce |
|---|---|
| Regular review of feedback channels | Documented assessment of whether feedback is being received, triaged, and addressed — and whether the volume or content signals emerging issues not visible in performance metrics |
| Periodic consultation with affected communities | Updated understanding of how the system is actually experienced, not how it was designed to be experienced — these diverge over time |
| Post-incident engagement with impacted parties | Explanation of what happened, what is being done, and how affected parties can seek redress — required by EU AI Act complaint handling obligations |
| Annual stakeholder reassessment | Identification of new affected parties as scope evolves; reassessment of whether existing engagement methods are still reaching the right people in the right ways |
Right-Sizing This for Your Situation
Scale engagement to system risk. A low-risk internal tool doesn't need the same engagement infrastructure as a public-facing system making consequential decisions about people's employment, credit, housing, or healthcare.
You don't have formal AI stakeholder engagement processes yet. Start with a two-question exercise at project initiation: who is subject to this system's decisions, and who has no direct relationship with your project but is affected by its outputs? Document those groups by name. Then establish a basic feedback channel before go-live — even a structured intake form with a defined owner is better than nothing. For high-risk systems, the EU AI Act Article 27 Fundamental Rights Impact Assessment stakeholder identification step is non-negotiable; treat it as a required initiation deliverable.
You're moving from ad hoc engagement to a repeatable process. Build a stakeholder analysis template that explicitly separates project stakeholders from affected parties, and assign engagement levels using the Inform / Consult / Involve / Collaborate / Empower framework. Design your feedback channels to be genuinely accessible — think about language, anonymity, and what happens after someone submits feedback. Wire feedback outputs into your MEASURE function metrics so consultation actually changes something.
Your AI stakeholder engagement should be integrated with — not parallel to — your enterprise stakeholder management, compliance, and community engagement infrastructure. If your organization runs multiple AI systems affecting overlapping communities, you need portfolio-level engagement approaches, not system-by-system repetition. Map which EU AI Act disclosure obligations apply to each deployment and build the required communications into your standard project deliverable set, not as last-minute additions.
The AI Governance Advisor can help you work through stakeholder mapping, affected party identification, and communication planning for your specific deployment context.
h2('Framework References'),
- EU AI Act (2024) — Articles 27 and 86, Recitals 92 and 93. Fundamental Rights Impact Assessment, right to explanation, worker notification, and regulator notification obligations.
- NIST AI RMF 1.0 — MAP 1.6, MAP 5.1, MAP 5.2, MEASURE 3.3, MEASURE 4.3, MANAGE 4.1. Affected party identification, ongoing community engagement, feedback integration, and incident communication.
- NIST AI 600-1 GenAI Profile (2024) — Participatory engagement, field testing, and diverse red-teaming as structured feedback approaches for generative AI deployments.
- UNESCO Recommendation on the Ethics of AI (2021) — Inclusive participation principles; engagement with marginalised groups who may not self-identify as stakeholders.
- PMI CPMAI Guide (2025) — Phases I and IV. Stakeholder impact assessment including affected community identification, and community feedback mechanisms as project deliverables.
This article is part of AIPMO’s PM Practice series. See also: The AI Project Charter | AI Impact Assessments | Human Oversight in AI Systems