A working guide from Beeston Labs. Version date: 8 November 2026.
Use the brief for a proposed or existing AI use. Keep one concise register entry for each materially different use, with links to its assessment and decision. The same tool can have more than one use-case record.
Use-case brief
| Field | Your record |
|---|---|
| Use-case name and reference | |
| Business owner and contact | |
| Technical or supplier owner | |
| Current stage | Idea / experiment / limited trial / operating / retired |
| Purpose | Describe the work and the benefit sought |
| People using the system | Include external users if relevant |
| People affected by its outputs or actions | Include people who do not operate the system |
| Current alternative | How is the task handled without this AI use? |
| System and supplier | Product, model, service and relevant version |
| Inputs and sources | Data types, sources and permissions |
| Outputs and actions | What happens with the result? Can it change another system? |
| Processing locations and connections | Hosting, external services, connected tools and logs |
| Human role | Who checks, decides, overrides or intervenes? |
| Territory and intended market | Where is it supplied or used? |
| Important failure consequences | Describe the effect, not just “inaccuracy” |
| Operating limits | Excluded uses, users, data or environments |
| Existing evidence | Link to tests, supplier documents and relevant assessments |
| Questions still open | Include assumptions needing confirmation |
| Decision needed | What exactly is being requested, and from whom? |
Additional fields for physical AI
Record the environment, sensors, actuators or connected equipment, expected response time, relevant failure states and the action required outside the operating limits. Identify which safeguards are independent of the model and who owns the safety assessment. Do not reduce this to a general AI risk score.
For NVIDIA or Hailo deployments, identify the actual module or accelerator, host, runtime/toolchain and model build. Vendor family names alone will not identify the evaluated configuration.
Decision record
| Field | Your record |
|---|---|
| Decision | Proceed within scope / limited trial / further work / do not proceed |
| Decision owner and date | |
| Permitted use and configuration | |
| Required conditions | State how each will be checked |
| Unresolved issue, owner and next action | |
| Review date | |
| Change triggers | Purpose, model, supplier, data, users, integration or operating environment |
| Evidence links |
Register view
Use these columns in the organisation’s existing tool:
| Reference | Use | Owner | Stage | System/version | Decision | Conditions | Next review | Evidence link |
|---|---|---|---|---|---|---|---|---|
| EXAMPLE-01 | Draft internal support-ticket summaries | Service owner | Limited trial | Named service and assessed configuration | Limited trial only | Staff check against source; attachments excluded | Set at decision | Link to full brief |
The example is illustrative. Replace it with real records; do not count it as an approved organisational use.
Keep the register useful
Ask owners to update the record when a material change is proposed, not only during a scheduled review. Assign someone to check for records without owners or overdue decisions. Retire unused entries while retaining the decision history needed by the organisation.
Avoid storing confidential source data in the register itself. Link to controlled evidence locations and use the minimum description needed to understand the use.
This guide supports intake and ownership. It does not determine legal classification or replace a system-specific assessment.