You're building an AI governance committee and need a structured way to bring diverse voices into the room. This isn't about symbolic inclusion, it's about gathering actual input that shapes decisions before they're made.
This script provides a repeatable process for stakeholder engagement sessions. It helps uncover power dynamics, map resistance points, and document what people truly need from your AI systems. Use it when designing governance frameworks, evaluating high-risk AI deployments, or conducting AI System Impact Assessments under ISO/IEC 42005.
Purpose of This Template
This facilitation script is for structured stakeholder engagement sessions. It's designed for AI governance teams who need to:
- Include affected communities in AI system design and oversight decisions
- Document stakeholder input for conformity assessments under the EU AI Act
- Meet stakeholder engagement requirements in ISO/IEC 42001 (clause 5.2.2)
- Identify contextual risk factors that desk research won't catch
- Build an audit trail showing you consulted people beyond your usual compliance circle
The script runs a 90-minute session. You'll leave with documented concerns, a power-mapping exercise, and a prioritized list of governance gaps your committee needs to address.
Prerequisites
Before running this session, ensure you have:
- Identified stakeholder groups: Don't just invite "users." Map who's affected, end users, workers whose jobs the system touches, communities subject to automated decisions, and people who maintain or monitor the system.
- A specific AI system or decision in scope: Stakeholders can't provide useful input on "our AI strategy." They can tell you what's wrong with a hiring algorithm or a content moderation model.
- Decision authority in the room: If those running this session can't act on what they hear, you're performing consultation theater. Bring someone with budget or veto power.
- A note-taker who isn't facilitating: You need verbatim quotes and a separate person tracking themes.
The Script
Opening (10 minutes)
Facilitator: "We're here because [specific AI system or governance decision] affects your work, your community, or decisions made about you. This session isn't about explaining what we've already decided. It's about understanding what you need from this system and what risks you see that we might not.
Three ground rules: First, if something we're doing concentrates power in the wrong hands, say so. Second, if you think this system shouldn't exist at all, that's a valid input. Third, we're documenting everything you say, and you'll see how it influenced the final decision.
Who's in the room and why you're here: [Go around, 30 seconds each.]"
Exercise 1: Power Mapping (25 minutes)
Facilitator: "We're going to map who holds power over this AI system right now. I'm putting four quadrants on the board:
- Decides: Who approves whether this system gets built, deployed, or changed?
- Operates: Who runs it day-to-day, monitors it, or fixes it when it breaks?
- Affected: Whose life, work, or rights does this system touch?
- Can Refuse: Who can say no to this system or opt out without penalty?
Take five minutes individually. Write names, roles, or groups in each quadrant. Then we'll compare."
[After individual work]: "Now let's build a shared map. Call out what you wrote. I'll mark overlaps and gaps."
Key questions to surface:
- Are the people in "Affected" also in "Decides"? If not, why not?
- Is anyone in "Can Refuse"? If that quadrant is empty, you've identified a governance gap.
- Who's in "Operates" but has no input into "Decides"? That's where you'll find implementation resistance later.
Exercise 2: Risk and Harm Identification (30 minutes)
Facilitator: "Now we're going to list harms this system could cause. Not theoretical harms, specific things that could go wrong for you or people like you.
Use this structure: 'If [system behavior], then [consequence for me/my community], because [context we might not know about].'
Example: 'If the system flags my application for manual review based on my address, then I wait three extra weeks for a decision, because I live in a neighborhood that's been historically redlined and your algorithm learned that pattern.'"
[Collect inputs on a visible board. Group similar harms. Then:]
"Which of these harms would be hardest to detect after the system is deployed? Mark those with a star. Which ones would be hardest to reverse once they happen? Mark those with a triangle."
Document: Every harm statement verbatim, plus the markers. These become your contextual risk factors for ISO/IEC 23894 risk assessments and your impact assessment inputs for ISO/IEC 42005.
Exercise 3: Refusal and Alternatives (15 minutes)
Facilitator: "If you could refuse this system or demand an alternative, what would that look like?
Three options:
- 'Don't build this system at all.'
- 'Build it differently.' (Describe how.)
- 'Let me opt out without penalty.' (Describe what penalty-free means.)
You can pick more than one. Write it down, then we'll hear from everyone."
[Go around the room. No debate, just documentation.]
Why this matters: If multiple stakeholders say "don't build it," and you build it anyway, you need to document why you proceeded and what risk controls you added to address their concerns. That's your evidence trail for Annex A control 6.1.1.3 (AI-specific controls) in ISO/IEC 42001.
Closing: Accountability Loop (10 minutes)
Facilitator: "Here's what happens next. Within two weeks, you'll receive:
- A summary of what we heard today
- Which inputs are changing our approach
- Which inputs we're not acting on and why
- Who to contact if the system causes the harms you identified
We'll reconvene in [specific timeframe] after the system is deployed to review whether the controls we put in place worked."
[Collect contact information. Confirm follow-up date.]
How to Customize It
For high-risk AI systems under the EU AI Act: Add a section in Exercise 2 specifically asking about fundamental rights impacts (Articles 9 and 26). Ask: "Could this system affect your ability to access housing, employment, education, public services, or legal protections?"
For vendor model risk: If you're evaluating an outsourced model, add a question in Exercise 1: "Who at the vendor can we escalate to if this system harms you?" If stakeholders don't know, that's a vendor due diligence gap.
For AI systems affecting workers: Add a question in Exercise 3: "If you had to work alongside this system every day, what would you need to trust it?" Document the answers. They'll tell you what your Instructions for Use (EU AI Act Article 13) need to include.
For General-Purpose AI Models with Systemic Risk: If you're a foundation model provider, run this session with downstream deployers, not just end users. Ask: "What could go wrong at scale that wouldn't show up in a single deployment?"
Validation Steps
After the session, check whether you have:
Documented power asymmetries: Did you identify who's in "Affected" but not in "Decides"? If you didn't find any, you didn't probe hard enough.
Actionable harm statements: Can you map each harm to a specific risk control or mitigation measure? If not, go back and ask clarifying questions.
A closed-loop accountability plan: Do stakeholders know when and how they'll hear back from you? Did you schedule the follow-up session?
Evidence for your AI Management System: Can you show an auditor that you consulted affected parties before deploying a high-risk system? This script's output becomes your stakeholder engagement record for ISO/IEC 42001 clause 9.1 (monitoring and measurement).
If you're preparing for an AI System Impact Assessment or a Data Protection Impact Assessment, attach the session notes as Validation Evidence. If stakeholders told you "don't build this" and you proceeded anyway, document your risk-benefit analysis and the additional controls you implemented. That's not just a good practice, it's your defense if the system causes harm later and someone asks whether you knew better.
