From AI pilot to operational use: Designing for trust in public services

When we build an AI application, the question “does it work?” needs a precise answer. Extracting a clause from a contract is one test. Giving someone enough context to assess that clause and use it in their work is another.

That distinction sits at the heart of moving AI into public services. A demonstration can show technical capability. An operational application has to accommodate the people, responsibilities and exceptions that surround a task.

Our work with Surrey County Council on contract analysis for local government reorganisation brings those requirements into focus.

A specific problem to solve

Reorganisation requires councils to understand how existing contractual arrangements may be affected by organisational change. The relevant information sits within documents that vary in structure and wording.

Working with Surrey, we used Collective, Whitespace’s sovereign AI operating system, to support analysis across 1000s of contracts. The scope included identifying termination provisions and extracting information relating to inter-authority agreements.

This gave the application a defined purpose. Rather than asking it to provide a broad assessment of every contract, the work focused on particular information that reviewers needed to examine.

From a product perspective, that scope is important. It gives users a clear expectation of what the application should produce and gives the delivery team a basis for evaluating its performance.

The finding is only part of the output

For this kind of work, the interface needs to answer an obvious follow-up question: where did that come from?

The Surrey application presented structured findings with confidence levels and references to relevant clauses, within a review workflow. Users could examine the source material behind a finding rather than rely on an isolated answer.

Confidence levels also need careful treatment. They can help direct a reviewer’s attention, but they should not be presented as a guarantee of correctness. The supporting text remains essential, particularly where contractual language is ambiguous or requires specialist interpretation.

These are consequential product choices. They affect how much work someone must do to check an output, and whether the application fits the task they are responsible for completing.

What belongs in the platform?

The Surrey work used the Client Access Release of Collective. It illustrates a wider product question: which requirements are shared across applications, and which belong to an individual workflow?

Access controls, policy enforcement and auditability are recurring requirements. Collective provides a foundation for addressing them. The information being extracted, the way findings are presented, and the review process need to reflect the particular use case.

Keeping those responsibilities clear helps us develop applications around users’ needs while building on common platform capabilities. It also avoids assuming that an application designed for one team will transfer unchanged to another.

Earn the next stage of adoption

A completed batch of analysis is evidence to examine, rather than automatic justification for a wider rollout.

Before expanding scope, a team needs to understand what the application missed, which findings required correction and how much effort users spent reviewing them. Different document types or working practices may expose requirements that were absent from the initial task.

For a product team, the next useful question is therefore specific: what have we learnt that gives us confidence to extend this application’s use?

Answering that well gives public sector organisations a firmer basis for investment and gives delivery teams a clear direction for the next release.