Algorithmic impact assessment
Decide which impacts should be investigated before and after deployment
When an agent may materially affect people or business outcomes, this area becomes relevant. For the product and responsible AI sponsor, the concern is specific: assessment describes intended benefits without examining who bears errors or loses recourse. The governance implementation design starts from that consequence and follows the relevant evidence through the customer workflow. Impact assessment should connect system behaviour to people and processes. The proposed work should distinguish anticipated effects from observed results and should involve qualified domain or legal review where the use creates professional obligations.
Connect the operating question to inspectable evidence
- Product and responsible AI sponsor
- Owns the bounded decision and the consequence of acting.
- Affected stakeholder map
- Defines the starting context for the proposed work.
- Distribution of consequences
- Exposes the first material uncertainty to examine.
- Mitigation and monitoring plan
- Carries unresolved conditions into an accountable next action.
Decision at stake
Decide which impacts should be investigated before and after deployment
Make the decision explicit
- Product and responsible AI sponsor
- An agent may materially affect people or business outcomes.
- Decision
- Which impacts should be investigated before and after deployment.
- Distribution of consequences
- Use affected stakeholder map to establish the relevant starting condition.
For the product and responsible AI sponsor, this becomes relevant when an agent may materially affect people or business outcomes. The immediate decision is which impacts should be investigated before and after deployment. The scope should be narrow enough that the governance owners can identify a meaningful alternative, including continuing the current approach if the available evidence already supports it.
The practical failure to challenge is that assessment describes intended benefits without examining who bears errors or loses recourse. That concern gives the work a concrete direction: establish what the relevant boundary should do, inspect how it behaves or would operate, and identify the owner of any gap. It should not be diluted into a broad transformation exercise before the specific question has been answered.
Coverage
Examine distribution of consequences alongside contestability and correction
Keep the review distinctions visible
- Distribution of consequences
- Compare who receives the benefit with who bears the possible harm.
- Contestability and correction
- Identify how an affected person can challenge and correct a decision.
- Outcome measurement
- Connect the mitigation to an observable outcome for the affected group.
Distribution of consequences
For this scope, distribution of consequences should be examined alongside affected stakeholder map. Map how the agent’s output changes decisions, access, workload, or treatment for affected people. Include intended benefits and plausible harms, labelling anticipated effects as hypotheses. The assessment should follow the consequence beyond model output to the human or organisational process in which it is used.
Contestability and correction
For this scope, contestability and correction should be examined alongside workflow decisions. Examine whether affected people can understand, contest, and correct a material error through the intended workflow. The proposed work should identify practical barriers and accountable owners. Where the use requires professional or legal judgement, qualified specialists must define the relevant obligations and boundaries.
Outcome measurement
For this scope, outcome measurement should be examined alongside evidence of possible benefits and harms. Design measurement for outcomes that matter to the stated impact question. Keep baseline, comparator, and data limitations visible. An assessment can identify plausible pathways and proposed controls before deployment, while observed impact claims require later evidence rather than assumptions about the intended benefit.
Prerequisites
Start with affected stakeholder map
Give each input a specific job
- Affected stakeholder map
- Defines the operating boundary.
- Workflow decisions
- Examine contestability and correction.
- Evidence of possible benefits and harms
- Shows conditions affecting outcome measurement.
- Policy or risk owner
- Confirm access and a reviewer who can resolve gaps.
The starting material is affected stakeholder map, workflow decisions, and evidence of possible benefits and harms. Review these together rather than assuming one document tells the whole story. A stated rule may differ from a configured behaviour, and a proposed responsibility may not yet have an available owner. Identify those differences before selecting the detailed work.
Participation should include an accountable policy or risk owner, relevant system owners, and qualified legal or domain reviewers when interpretation is needed. The customer should define which information and environments may be used. Synthetic or sanitised examples can support preparation when they preserve the relevant behaviour; if they omit a material dependency, record the limitation and agree how the missing evidence would be obtained.
How the work proceeds
Follow the requirement into an accountable operating practice
Follow the evidence through the work
- Distribution of consequences
Use affected stakeholder map to define the decision criteria.
- Contestability and correction
Inspect workflow decisions and retain observations that challenge the expected result.
- Outcome measurement
Use evidence of possible benefits and harms to identify unresolved conditions and a responsible owner.
- Mitigation and monitoring plan
Link the recommendation to its evidence, remaining limits and next validation condition.
Map how an agent output changes a human or organisational decision. Identify who may benefit, who may be disadvantaged, how errors are noticed, and what correction or recourse exists. The proposed assessment should use stakeholder evidence where available and label anticipated harms or benefits as hypotheses until observed.
A practical first slice would focus on distribution of consequences and then follow its consequences into contestability and correction. Keep outcome measurement visible as a separate review question rather than assuming it is satisfied by the first result. The governance owners should record observations, competing explanations, and changes to the original assumptions. A second reviewer can challenge whether the evidence supports the recommendation and whether an apparently successful example omitted the condition that matters most.
Indicative artefacts
Use mitigation and monitoring plan to make the next action explicit
Every artefact needs an operating use
Illustrative working format
- Impact assessment draft
- Boundary — affected stakeholder map.
- Stakeholder and harm pathway map
- Findings about contestability and correction.
- Mitigation and monitoring plan
- Action on outcome measurement.
Indicative outputs include impact assessment draft, stakeholder and harm pathway map, and mitigation and monitoring plan. Their form should follow the decision and the customer’s existing operating records. The first should establish the assessed boundary and relevant observations; the second should make material gaps or dependencies inspectable; the third should identify the action, owner, and evidence needed to revisit the decision.
Acceptance should be tested through use: can the responsible owner explain what was examined, identify an unresolved issue, and act on the next step without reconstructing the whole engagement? Findings should preserve counterevidence and limits. A polished document is insufficient if it does not help resolve the customer’s specific question.
Illustrative scenario
Service priority changes: wider-use condition
Examine the constructed decision boundary
Illustrative scenario
- Service priority changes
An agent's ordering decisions may alter when different users receive help.
- Treatment and challenge
Compare request categories and the route for contesting a mistake.
- Wider-use condition
Add measurement or review where needed; an uneventful sample does not establish no harm.
Consider an illustrative situation in which an agent prioritises service requests and may change how quickly different users receive help. This is a constructed example, not a client engagement or an observed Softlander outcome.
For service-request prioritisation, an illustrative analysis would examine whether different request types receive different treatment and how users can challenge a mistake. The output could recommend measurement and review controls before wider use. It should not claim the absence of harm simply because an initial test set showed no problem.
The useful learning would be the difference between the expected behaviour and the behaviour or responsibility actually demonstrated. If the exercise leaves outcome measurement unresolved, that should remain a named next step. A recommendation to narrow the scope, improve a prerequisite, or hold the decision can be appropriate when the example exposes a material dependency.
Scope and authority
Governance evidence supports decisions within defined professional limits
Keep analytical work separate from decision authority
- Operating requirements and evidence mapping
- Can include impact assessment draft.
- Policy or risk owner
- Authorised policy owners decide; qualified specialists interpret professional requirements.
- Legal conclusions and certification decisions
- Cannot be inferred from stakeholder and harm pathway map.
This work supports governance preparation and operating evidence. It does not provide legal advice, determine regulatory compliance, award certification, or replace a formal audit. Authorised customer owners retain policy, release, and residual-risk decisions.
Ways to engage
Related engagement scopes
AI Privacy Engineering Review
Trace personal data through your agent workflow. Examine collection, memory, retrieval, tool access and retention against your agreed requirements.
AI Governance Operating System
Make AI oversight part of daily operations. Connect inventories, accountable owners, change decisions and evidence into a workable governance process.
Continue exploring
Related insights and resources
Governing agent decisions
Governance becomes useful when it changes a decision. Connect each agent workflow to an accountable owner, explicit operating conditions, proportionate evidence and a practical route for exceptions and withdrawal.
Protecting agent data and memory
An agent's information footprint extends beyond the conversation. Map the copies, derived records and retrieval paths that influence future actions, then connect each to purpose, access, retention and verifiable handling.
AI agents in legal operations: assistance without invented authority
Legal agents can organize evidence and prepare work, but professional judgement, client authority and verified legal positions cannot be delegated by interface.