The Safe Way to Use AI in High-Stakes Work

A safe AI deployment begins by narrowing the job.

That is the clearest lesson in the Superior Court of Québec's evaluation of its 98-day artificial intelligence pilot, published in April 2026.

The pilot involved 22 judges and nine specialised AI agents. The court did not ask the systems to exercise judicial judgment. It restricted them to preparatory and support tasks, required judges to verify every output, and kept the deployment inside a secure institutional environment.

The design also included continuous evaluation and reversibility. The court could assess the use, change the conditions, or stop the experiment.

The pilot produced 479 writing-assistant sessions, with 94% engagement. In the final survey, 84% of respondents said AI was compatible with judicial work if a clear governance framework existed. A further 89% said they would be comfortable continuing to use it within a well-defined framework.

Those figures matter. The stronger lesson sits in the operating design behind them.

Define the boundary before measuring the benefit

Organisations often begin an AI deployment with a broad outcome such as productivity, efficiency or automation.

That creates a measurement problem before the system is even in use. If the task is unclear, the organisation cannot tell whether the system has improved the work, changed the risk, or simply moved responsibility somewhere less visible.

The Québec court started with a narrower question: what work could an AI system support without taking over the judgment that belonged to a judge?

That question creates a usable boundary.

The system can assist with defined preparation. The judge remains responsible for the decision. The output must be checked. The institution retains the ability to review and reverse the deployment.

This is a better starting point for high-stakes work because it makes authority visible.

Separate assistance from judgment

A useful AI deployment does not need to remove human judgment to create value.

In regulated environments, the more important design decision is often the separation between recommendation and authority.

An AI system may organise information, identify relevant material, produce a first draft, or surface a possible inconsistency. Those functions can reduce friction without transferring the consequential decision to the system.

The boundary must be explicit. A system that prepares material is operating under a different control model from one that determines an outcome.

That distinction applies across financial services.

An AI assistant might prepare a claims file for review. It might classify documents in an investment operation. It might identify transactions that deserve investigation. Those uses still require a clear statement of what the system can do, what it cannot do, and who owns the final judgment.

If the organisation cannot answer those questions, the deployment is not ready for scale.

Build verification into the work

The Québec pilot required judges to verify every output.

That requirement is more important than a general instruction to use AI responsibly. It connects the control to the action.

Verification needs an object. The reviewer must know what to check, what evidence to use, and what to do when the output cannot be supported.

A practical verification design should establish:

• the source material the system was allowed to use
• the parts of the output that require human review
• the standard for accepting or correcting the output
• the record kept when a material change is made
• the escalation path when the reviewer cannot resolve an issue

This is operational work. A policy statement does not create verification on its own.

The reviewer also needs enough time and authority to challenge the result. If a team is measured only on throughput, a control that requires careful review will be treated as an obstacle.

The operating model has to make the safe behaviour possible.

Measure use, not just output

The court reported 479 writing-assistant sessions and 94% engagement. Those figures show that the system was used. They do not, on their own, prove that the system improved judgment or reduced risk.

That is why AI evaluations need more than an adoption figure.

A useful evaluation should examine at least four dimensions:

1. Whether the system performed the permitted task.
2. Whether the output met the required quality standard.
3. Whether the human reviewer could detect and correct errors.
4. Whether the workflow remained accountable when the system was wrong.

The last point is easy to miss. A system can appear accurate while making the surrounding process harder to understand.

The evaluation should therefore include the work around the model. Did people know when to challenge the output? Could they explain the decision afterwards? Did the system create new approval steps or hidden dependencies?

The court's approach gives regulated organisations a useful pattern: measure the technology inside the work, not in isolation from it.

Keep the deployment reversible

Reversibility changes the quality of a decision.

When a deployment is treated as permanent, teams tend to defend the original choice. Problems become exceptions to manage rather than evidence that the design needs to change.

A reversible deployment creates a different discipline. The organisation can test a defined use, observe the result, and stop when the conditions are no longer acceptable.

That requires a practical stop condition.

The organisation should know which signals would trigger review, restriction or withdrawal. Those signals might include an error pattern, a change in the underlying data, an inability to verify outputs, or evidence that responsibility has become unclear.

Reversibility also protects the institution from mistaking early use for proof of readiness.

A successful pilot answers a bounded question. It does not automatically justify expansion into a different task, population or risk class.

Design the authority before the automation

The court's pilot offers a useful rule for every regulated AI programme:

Design the boundary of authority before designing the scale of automation.

That means deciding:

• what the system is allowed to do
• what remains outside its authority
• who is accountable for the consequence
• how the output will be checked
• which evidence supports continued use
• when the organisation will stop or reverse the deployment

These decisions are not paperwork added after the technology is selected. They are part of the system.

The model may change. The interface may change. The workflow may change.

The question of authority cannot remain undefined while those changes happen.

High-stakes institutions do not make AI safe by asking for more confidence from the model. They make it safer by giving the model less authority, giving the reviewer a real responsibility, and making the conditions visible to everyone involved.

The Superior Court of Québec did not prove that AI should run judicial work.

It demonstrated something more useful: AI can support consequential work when the institution defines the boundary first, verifies what crosses it, and keeps the decision under accountable human control.