Risk Quantification and Capital Allocation — Operating Quantum Computers

Quantum platform work competes for scarce capital: QPU access, specialized engineers, lab equipment, cloud budget, executive attention, and customer trust. Risk management must therefore become quantitative enough to guide allocation.

NIST SP 800-30 frames risk assessment as a way to give leaders information needed to determine courses of action [R199]. For quantum platforms, that information must include technical uncertainty, scientific uncertainty, vendor uncertainty, operational reliability, and opportunity cost.

Diagram loads as you read

Risk Quantification and Capital Allocation · Figure 1

View diagram source

flowchart TB
    Portfolio[Quantum portfolio] --> Technical[Technical risk]
    Portfolio --> Scientific[Scientific risk]
    Portfolio --> Operational[Operational risk]
    Portfolio --> Security[Security risk]
    Portfolio --> Vendor[Vendor risk]
    Portfolio --> Economic[Economic risk]
    Technical --> Capital[Capital allocation]
    Scientific --> Capital
    Operational --> Capital
    Security --> Capital
    Vendor --> Capital
    Economic --> Capital

Risk register is not enough

A risk register is necessary, but insufficient. It often becomes a parking lot for concerns. Capital allocation needs ranked, comparable, decision-linked risk.

Diagram loads as you read

Risk register is not enough · Figure 2

View diagram source

flowchart LR
    Risk[Risk item] --> Probability[Probability]
    Risk --> Impact[Impact]
    Risk --> Exposure[Exposure]
    Risk --> Mitigation[Mitigation cost]
    Risk --> Owner[Owner]
    Risk --> Trigger[Trigger]
    Exposure --> Decision[Fund, defer, transfer, accept, or kill]
    Mitigation --> Decision

A useful risk entry includes a trigger and a decision. Without those, it is not operational.

Quantum-specific risk classes

Risk class	Example
calibration risk	workload depends on unstable target behavior
compiler risk	optimization changes semantics or performance
evidence risk	result cannot be reproduced or audited
provider risk	queue, pricing, access, or API changes
algorithm risk	classical baseline improves faster than quantum result
governance risk	export, privacy, contractual, or publication limits
talent risk	critical workflow depends on one expert

Diagram loads as you read

Quantum-specific risk classes · Figure 3

View diagram source

flowchart TB
    QR[Quantum risk] --> Calibration
    QR --> Compiler
    QR --> Evidence
    QR --> Provider
    QR --> Algorithm
    QR --> Governance
    QR --> Talent

Exposure model

A simple model is often enough:

Diagram loads as you read

Exposure model · Figure 4

View diagram source

flowchart LR
    P[Probability] --> E[Expected exposure]
    I[Impact] --> E
    T[Time sensitivity] --> E
    M[Mitigation cost] --> ROI[Mitigation ROI]
    E --> ROI

The point is not false precision. The point is comparability. A rough exposure model is better than unrelated narratives.

Capital allocation loop

Diagram loads as you read

Capital allocation loop · Figure 5

View diagram source

sequenceDiagram
    participant Team
    participant Portfolio
    participant Finance
    participant Board
    Team->>Portfolio: submit risk-adjusted request
    Portfolio->>Finance: estimate cost and exposure
    Finance-->>Portfolio: budget view
    Portfolio->>Board: options with tradeoffs
    Board-->>Team: fund, defer, pivot, or stop

Funding should go to work that reduces uncertainty, increases reusable capability, or advances a gated portfolio objective. It should not automatically go to the loudest demo.

Risk burndown

Risk burndown is more useful than milestone reporting.

Diagram loads as you read

Risk burndown · Figure 6

View diagram source

flowchart LR
    Baseline[Baseline exposure] --> Mitigation1[Mitigation 1]
    Mitigation1 --> Mitigation2[Mitigation 2]
    Mitigation2 --> Residual[Residual exposure]
    Residual --> Decision{Acceptable?}
    Decision -- yes --> Advance[Advance gate]
    Decision -- no --> More[More mitigation or kill]

A portfolio should report what uncertainty was reduced, not just what activities occurred.

Reserve strategy

Quantum work needs reserves because the platform depends on external schedules and physical variability.

Diagram loads as you read

Reserve strategy · Figure 7

View diagram source

flowchart TB
    Reserve[Portfolio reserve] --> Shot[Shot reserve]
    Reserve --> Queue[Queue reserve]
    Reserve --> Review[Review reserve]
    Reserve --> ReRun[Re-run reserve]
    Reserve --> Vendor[Provider contingency]

A program with no reserve will either skip validation or miss commitments. Both are worse than acknowledging uncertainty at the start.

Practical rule

Do not ask “how much quantum should we fund?” Ask “which uncertainty should we buy down next, and what decision becomes possible if it is reduced?”