Designing a register for organisational AI use
Independent concept project. An AIC-initiated concept and prototype; pilot outcomes have not yet been measured.
AIC UK Ltd developed a concept for recording how organisations use AI, why they use it and what changes they expect it to bring. The work turns a broad licensing proposition into a declaration journey that policy teams and businesses can inspect.
The question behind the project
AI can enter an organisation through an individual assistant, a purchased software feature, a bespoke application or a service sold to customers. A company-level “yes” to AI use leaves important questions unanswered: which activity is affected, who relies on the output, what authority does the system have and who is responsible for its use?
AIC’s starting belief was that the UK should have a clearer record of organisational AI activity, potentially within a future licensing arrangement. The design task was to make that belief concrete enough to examine. What would an organisation declare? How much detail would be useful? What could an analyst reasonably infer from the answers?
Defining the reporting unit
We centred the concept on a material use case. Registering only a model would miss the business purpose. Registering every interaction would create a different service, with a much larger reporting and privacy burden.
The proposed record therefore connects an organisation to a specific activity. It describes the purpose, commercial model, degree of automation, data categories, expected effects and accountable role. Different uses can produce separate records even when they rely on the same underlying model.
This choice matters for analysis. A consultancy using AI to draft internal notes and the same consultancy selling an automated client-facing service should not be collapsed into one undifferentiated record. Nor should a supplier’s own sector be mistaken for the sectors buying its service.
Making uncertainty visible
Workforce effects are often discussed with more confidence than the evidence supports. The concept asks an organisation to distinguish its expectation from its measurement. A forecast of reduced task demand is different from an observed staffing change, and neither on its own establishes a wider industry effect.
The declaration journey includes explicit uncertainty. An organisation can indicate that an effect is not yet known or that an assessment has not been completed. For a live pilot, those responses would help analysts understand the quality of the dataset and identify where follow-up is needed.
The declaration journey
The prototype groups the task into four stages: organisation, AI use, effects and controls, then review. Each stage asks for a coherent set of information. The summary allows the visitor to inspect the fictional declaration before completing the demonstration.
The completion screen explains the status of the result and offers a downloadable demonstration record. Entered values remain within the page’s working memory and clear on refresh. The demonstration does not send those form values to AIC or a government register.
That constraint keeps the prototype focused on the reporting model. A production service would need organisation verification, access control, record updates and audit history. Those capabilities require a separate delivery design and cannot be inferred from a working form.
Showing what the records might support
An illustrative dashboard allows the visitor to change a sector filter and inspect sample counts. Its role is to make the relationship between declarations and aggregate questions understandable. The sample records are fictional and are labelled accordingly.
The demonstration deliberately avoids a score claiming to predict industry collapse. Before such a system could support real analysis, its definitions, participation and comparison methods would have to be tested. A future analyst would need to distinguish organisation counts from use-case counts and forecasts from observed outcomes.
Keeping the service’s identity clear
A credible public-service interface can create an impression of official authority. We therefore used AIC attribution and explicit prototype labels. The demonstration issues neither legal permission nor a safety assessment.
Public-sector design guidance and transparency practice are useful references. They do not make an independent product a government service. The project treats that boundary as part of the service design, because visitors need to understand who is collecting information and why.
What the project has produced
The reviewable output is a defined product proposition, a guided declaration demonstration, a summary and download flow, and illustrative sector analysis. The work also establishes the questions a live pilot would need to answer about scope, data quality, operating cost and usefulness.
The prototype provides a basis for discussion. It does not establish improved compliance, reduced reporting time, prevented harms or policy impact. Those outcomes would need to be measured in a real deployment.
The next test
AIC proposes a 12-week pilot with a target of 50 organisations across five sectors. The pilot would examine whether participants understand the reporting boundary, can complete the declaration without extensive support and can keep the record accurate when their use changes.
Analysts would assess whether the records answer useful questions and whether the same information could be obtained more cheaply through existing surveys or returns. Findings should include fields to remove, groups missing from the sample and reasons organisations decline to participate.
The project gives that evaluation a starting point: a service that can be inspected, challenged and improved before decisions about mandatory registration, licensing or charges are made.