06 — Risks & mitigations

The dangerous failure is not an error message. It is a confident, well-formatted wrong answer.

Each risk carries a mitigation that is a design decision, and a signal you can actually watch. Likelihood and impact are our starting judgements for this class of system, not findings about a specific estate.
6.1

Likelihood × consequence

Executive

All risks placed on one map. Hover or tap a marker to read it.

SevereConsequenceLow
LowLikelihoodHigh

Hover or tap a marker to read it.

6.2Technical risksImplementation
6.3

User and adoption risks

A technically correct system nobody uses, or uses correctly, has the same business value as one that doesn't work.

U1

Over-trust in generated explanations

HLHI

Because figures are correct, users extend the same confidence to the prose and its caveats.

Signal

Users quoting narrative text in decisions; feedback disputing explanation rather than figures.

Mitigation

Visual separation of figures from narrative; citations on every claim; explicit as-of/scope labelling; no causal language without a cited source.

U2

Under-adoption after an enthusiastic launch

HLMI

Usage falls away because the assistant refuses too often or sits outside existing tools.

Signal

Week-four repeat-use well below week-one; high refusal rate with a thin measure catalogue.

Mitigation

Deploy inside the existing collaboration surface; publish the in-scope question list; convert unanswered-but-reasonable questions into a certification backlog.

U3

Automation that does not match the real process

MLMI

The documented process differs from what people actually do; automation forces a worse workflow.

Signal

High manual-fallback usage; exception volume above the design assumption.

Mitigation

Observe the real task before designing; baseline cycle time and exceptions; pilot with the people who perform it; keep a manual path available.

U4

Unclear boundaries between systems

MLMI

Users cannot tell which surface is authoritative, so they cross-check against a spreadsheet anyway.

Signal

Continued heavy use of the artefact the new capability was meant to replace.

Mitigation

One authoritative surface per question type, stated in the interface; deliberate deprecation of superseded reports.

6.4

Project and organisational risks

Executive

In our experience of this class of programme, these decide the outcome more often than the engineering does.

P1

No owner for a definition

HLHI

Nobody is empowered to decide what a contested metric means; the decision escalates repeatedly.

Signal

Open-decision list growing faster than it closes; the same question raised in two reviews.

Mitigation

Named owner per subject area with documented tie-break authority; contested definitions logged as open decisions with owner and date.

P2

Access latency dominating the schedule

HLHI

Elapsed time to obtain environment, data and identity access exceeds the build effort it blocks.

Signal

Any access request open beyond its agreed date; team on prep tasks with no path to real data.

Mitigation

Access requests raised day one alongside discovery; minimal viable access list; representative non-production data as fallback.

P3

Hidden logic in legacy models

HLMI

A spreadsheet contains rules no current owner can justify, discovered during parity testing.

Signal

Parity deviations clustering in one rule area; rising unresolved rule questions.

Mitigation

Explicit rule-adjudication time in the plan; unresolved rules logged, never guessed; phase one reproduces existing behaviour exactly.

P4

Scope expansion by demo

HLMI

A promising demo generates commitments to capabilities whose foundations do not exist.

Signal

Commitments appearing in reporting that are not in the backlog.

Mitigation

Every demo labelled real / stubbed / missing; new requests entered as backlog items with dependencies; a uniform definition of done.

P5

Key-person dependency

MLMI

One person holds the working model of the system and its history.

Signal

Any component only one person has deployed; runbooks never executed by a second person.

Mitigation

Decision records written as work happens; rotation of release/eval duties; runbooks rehearsed by a second person; pairing on high-context components.

P6

Quality apparatus deprioritised under delivery pressure

HLHI

Evaluation, tracing and documentation are deferred to make a date.

Signal

Features shipping without committed evaluation cases; growing reluctance to change a prompt or model.

Mitigation

Evaluation and tracing are part of the definition of done; the first slice includes them so cost is visible in the first estimate.

6.5

How risk is managed in practice

Design decisionsignals over status reports

Each risk above has a signal that can be instrumented or counted, reviewed monthly against the same dashboard the quality metrics use.

Whywhy we state risks this early

Naming failure modes before starting is how the architecture gets shaped. If a mitigation here is judged unnecessary, the corresponding design can be simplified — a conversation worth having explicitly.