How to Conduct an AI Ethics Impact Assessment: A Step-by-Step Guide for Product Teams

Most teams ship a model with a fairness metric, a privacy review, and a vague memory of someone raising a concern in a planning meeting. Then the harm shows up sideways: a resume screener quietly downranks anyone who took a career break, or a support triage system keeps routing older customers to the slowest queue. Nobody chose those outcomes. They emerged from a label definition, a threshold, and a data gap no one examined.

An ethics impact assessment is the practice of hunting for those outcomes before launch, while the design is still soft enough to change. It is not a philosophy seminar and it does not need a committee. It needs a structured afternoon and follow-through. Here is a process that holds up.

Before You Start: Scope, Timing, and Who Is in the Room

Run the assessment once you know roughly what the system will do and what decision it feeds, but before the model architecture is locked. Earlier is cheaper. If the feature is already in beta, you can still run it, but expect to find problems that are now expensive.

Pick a facilitator who does not own the launch date. A product manager with a quarterly commitment will unconsciously steer toward "acceptable." Someone from a neighbouring team, a research lead, or a staff engineer with no delivery stake works well.

Invite, at minimum:

• An engineer and a data scientist who can speak to what the model actually does.
• Someone from legal, privacy, or compliance, in an advisory role.
• Support, operations, or moderation staff who handle the fallout when things go wrong.
• A domain expert who understands the real-world decision being automated.
• At least one person outside the team, ideally including someone from an affected group. Pay them for their time if they are not staff.

A note on scope: this is a risk-finding exercise, not a legal opinion. If your feature touches credit, employment, housing, health, or education, get qualified counsel involved separately.

Step 1: Map Who Is Affected and Who Carries the Cost

Draw the decision being made, not the model. Who acts on the output? What happens to the person on the other side? Then list everyone with a stake:

• Subjects: the people the system scores, ranks, filters, or flags.
• Operators: staff who must interpret, override, or clean up after the output.
• Bystanders: people affected indirectly, such as families or communities.
• Data contributors: people whose behaviour or content trained the system, often without knowing.

Then ask the question that exposes most ethical problems: who benefits when the system is right, and who pays when it is wrong? If those are different groups, accuracy numbers will not settle the argument.

Step 2: Build a Risk Register From Concrete Failure Stories

Abstract principles like "fairness" produce abstract discussions. Write short narratives instead. Aim for six to ten along the lines of: A gig worker with an unusual schedule pattern is flagged as fraudulent and loses access to work for a week with no explanation.

Good prompts to generate them:

1. What happens when the input looks nothing like the training distribution?
2. Which group is smallest in the data, and what could go wrong specifically for them?
3. What does a confidently wrong prediction cost the person on the receiving end?
4. What happens if this score becomes the only input to the decision?
5. What if this system is repurposed next year for something it was not built for?

Tag each story with the interest it threatens: dignity, autonomy, fairness, privacy, safety, contestability, labour, or environmental cost. Tags help you spot clusters, and clusters are where you should spend your mitigation budget.

Step 3: Score Risks Without Pretending to Be Precise

Use five factors, each rated low, medium, or high rather than a decimal:

• Likelihood: how often this failure would occur in normal operation.
• Severity: how much harm per incident.
• Reversibility: can the affected person recover, or is the damage permanent?
• Scale: how many people, and how unevenly distributed.
• Detectability: would you even know it happened?

Write one sentence of justification for every rating. A score without a reason is a number someone will argue with later. And when two people disagree by more than one band, do not average it away, record the disagreement. That gap usually points at a missing piece of evidence, which is more useful than a tidy consensus.

Step 4: Turn Mitigations Into Commitments With Owners and Dates

Work down this list and stop as high as you can. The strongest mitigations change the decision itself.

1. Change the decision. Keep a human in the loop for consequential cases, or narrow what the system is allowed to influence.
2. Change the design or data. Add abstention for low-confidence cases, rebalance labels, adjust thresholds for the group most at risk.
3. Add guardrails. Mandatory review queues, rate limits, appeals paths, plain-language explanations.
4. Monitor and disclose. Logging, dashboards segmented by group, published limitations, staff training.

Every mitigation gets a name, a date, and evidence that it worked. "We will be careful" is not a mitigation. If a risk stays high after mitigation, the honest output of the assessment is a recommendation not to ship that part of the feature.

Step 5: Set Review Triggers and Keep the Paper Trail

A one-time assessment decays. Store the finished document next to the product spec, version it, and re-open it when any of these happen: the training data drifts, a new population starts using the feature, someone proposes a new use case, the model is retrained, an incident occurs, or a regulator moves. A thirty-minute review is usually enough for small changes.

An assessment that ends with the same feature, the same thresholds, and no named owners did not change anything. It just produced a document.

Make It Boring, Then Make It Routine

The teams that do this well treat it as ordinary engineering hygiene, not a moral reckoning. Keep a one-page template, run the workshop in ninety minutes, keep the same scoring bands so results are comparable across features, and review your open mitigations in the same meeting where you track bugs. Do it twice and it stops feeling like an interrogation.

The measure of success is not a beautiful risk register. It is a product decision that changed because someone in the room finally asked what happens to the person on the other end of the score.

Photo: sakibmia24 / Pixabay