ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
AI impact assessment stakeholders are the people whose knowledge and interests shape whether an assessment is credible. A team that assesses a hiring model, a triage tool or a lending system entirely from behind a desk will list the harms it can imagine. Speaking to the people who use the system, and to those it is used on, reveals harms and benefits the team had never considered.
This guide explains who counts as a stakeholder, how to identify them, how to involve them proportionately and how to record their input so that it changes the assessment.
An impact assessment asks what an AI system could do to individuals, groups and society. The people best placed to answer are those who will experience the effects. Guidance on AI impact assessment, such as ISO/IEC 42005:2025, treats the identification of affected parties and their interests as a core part of the process; the listing is on iso.org. The EU AI Act likewise expects deployers of certain high-risk systems to consider the categories of people affected when carrying out a fundamental rights impact assessment; see our guide to the fundamental rights impact assessment.
Good stakeholder work also protects the organisation. Problems raised early are cheaper to fix than problems found by a regulator, journalist or court, and a record of consultation shows that the assessment was more than a formality.
| Category | Who they are | What they can tell you |
|---|---|---|
| Directly affected people | Applicants, customers, patients, employees scored or decided about | Real effects, fairness, ability to challenge |
| Users and operators | Staff who use the outputs to decide | How the tool is used in practice, over-reliance, workarounds |
| Indirectly affected groups | Families, communities, competitors, the public | Wider social, economic or environmental effects |
| Internal functions | Legal, privacy, security, HR, risk, product, data science | Legal duties, technical limits, controls |
| Suppliers and partners | Model providers, data suppliers, integrators | Documentation, limitations, changes |
| Independent voices | Domain experts, advocacy groups, regulators, ethicists | Blind spots and emerging concerns |
Start from the system’s purpose and data flows. Ask who provides data, who is scored or classified, who receives outputs, who acts on them and who bears the consequences. Then ask who is missing: people who are affected but not visible in the data, such as those excluded because the system does not work for them, or groups that face the system through an intermediary. A translation tool, for example, affects not only its users but the people whose language it handles poorly.
Pay particular attention to vulnerable groups: children, older people, people with disabilities, people in financial difficulty and those with limited digital access. Harms often concentrate there, and their voices are least likely to reach the project team.
Consultation should be proportionate to the impact. A low-impact internal tool may need only a review by the owner, a privacy specialist and a few users. A system that affects access to jobs, credit, housing or care deserves consultation with affected groups or their representatives. Use the outcome of your screening step to decide; our guide to AI impact assessment screening shows how to set the tiers.
Structured interviews with users and operators show how the system is used and where it fails. Workshops that bring together legal, technical and business staff help map harms, controls and gaps. Provide a clear brief, examples of the system’s outputs and questions such as: what would you do if the system were wrong, who would be hurt, and how would we know?
Surveys reach larger populations and can test whether people understand and accept the system. Combine them with qualitative methods, because surveys can miss unexpected concerns. Where the system serves the public, consider testing prototypes with representative users, including those from groups likely to be affected differently.
For higher-impact systems, an advisory panel or consultation with representative bodies, such as consumer groups or worker representatives, can supply challenge that internal staff cannot. Set out what is being decided, how their input will be used and how you will report back. Consultation that changes nothing quickly loses trust.
Domain experts and red teams can test the system for foreseeable misuse and failure modes. Their findings feed the impact assessment as much as the views of affected groups do. Our guide to the AI risk register shows how to record the resulting risks.
Free AI impact assessment (ISO 42005)
Who could this AI system affect, and how?
Screen the system against sensitive and prohibited uses, describe it, check the safeguards for fairness, transparency and oversight, and rate its impacts on people and society from 26 scenarios with ISO 42001 Annex A measures. Free, with findings.
Start the free AI impact assessment → or View premium report sample
Someone must own the engagement plan. The AI system owner is normally accountable for the assessment, but they should not run every conversation alone. A privacy or ethics specialist can lead sensitive consultations, a user researcher can design interviews and the governance lead can confirm that the results are in the record. Decide early who speaks to which group, who approves the questions, who receives the findings and who signs off the response, so that consultation does not stall between teams.
Allow enough time and budget. Meaningful engagement takes weeks, not days, and needs a place in the project plan before the design is fixed. Build it into the outcome of your screening step and your project gates.
Stakeholders will disagree. Customers may value speed, while advocacy groups worry about fairness; managers may want automation, while operators fear deskilling. Do not average the views. Record each position, the evidence behind it and the decision reached, including who took it and why. Where the decision goes against a stakeholder concern, state the safeguard or monitoring that accompanies it. The record of disagreement is part of the assessment’s value.
For each engagement, record the date, method, who took part or which group they represented, the main points, the response and any change to the design, controls or decision. Keep personal information to what is necessary, and protect the confidentiality of participants where needed. A short table in the assessment, linked to the risk register and the decision record, is enough. Our AI impact assessment example shows one way to structure it.
The following is a hypothetical example invented for illustration. A city housing agency plans a tool that prioritises repair requests. The project team lists stakeholders: tenants, repair teams, dispatchers, the housing manager, legal, data science, a tenants’ association and the software vendor. They interview six dispatchers and hold two sessions with tenants, one in the local language most commonly spoken in the area.
Tenants explain that many report problems by phone or through a neighbour and rarely use the app, so a model trained on app reports would under-prioritise them. Dispatchers say they would probably follow the ranking without checking. The team adds phone reports to the training data, requires dispatchers to review the lowest and highest ranked cases weekly and sets up a monitoring measure by neighbourhood. Without the consultation, both problems would have gone unnoticed.
Common failures include a stakeholder list that names only customers and regulators, consultation after the design is fixed, asking only those who support the project, ignoring operators, skipping vulnerable groups, treating a single survey as sufficient, not recording responses, taking no action on what is heard and never returning to stakeholders after launch. Another is treating supplier assurances as a substitute for hearing the people affected.
Revisit stakeholders when the system changes: a new use case, a new population, a model update or an incident. Set up a feedback channel so that users and affected people can report problems after launch, and feed what arrives into your reviews. Include the channel in your privacy and transparency information. Ongoing input is often the earliest warning that a system is not working as intended.
A structured report makes sure stakeholders are considered every time. The AI Impact Assessment Report and Workbook provides a report and workbook that cover affected parties, impacts and measures. Whichever tool you use, keep the same fields for every assessment so that engagement can be compared and reviewed across the portfolio.
Anyone who can affect or be affected by the system: people scored or decided about, users and operators, indirectly affected groups, internal functions, suppliers and independent experts.
Not always in the same depth. The level should match the impact. For systems affecting access to important services or rights, consultation with affected groups or representatives is strongly advisable.
Work through trusted intermediaries such as community organisations, offer several channels and languages, and go to where people are rather than expecting them to come to you.
Record the disagreement, the reasoning and any safeguards. Report back to those consulted and offer a channel for continued feedback.
When the system, data, use case or population changes, after incidents, and at planned reviews. Feedback from users after launch is an important trigger.
September 30, 2026
September 30, 2026
