Lean Accountability FrameworkAbout

The Lean AI Accountability Framework

Guidance for teams using AI in their day to day work

Why this exists

This guidance helps teams be clear about when AI was used, what it helped with, and who is responsible for the final work.

It keeps responsibility with people.

It is not here to:

It is not here to:

Who should use this

This applies to anyone involved in digital delivery, including:

It applies to work outputs, not individuals.

Ground rules

Someone always owns the work

AI can help, but a person is always responsible for the final output and what it’s used for.

Match the effort to the risk

If the work could affect users, policy, or operations, be clearer about how AI was used.

Don’t focus on the tool

Which AI tool you used is less important than what you used it for and what decisions were made by people.

Treat AI like any other tool

If AI meaningfully shaped the work, say so.

AI accountability note (required)

If AI played a meaningful role in creating something, add a short accountability note close to the work.

Use whatever format fits the space, but follow this structure.

What to include

AI:
Assisted: true
Tools: "<tool name>"
Role: "<what the tool helped with>"
Human accountable: "<name or role>"
Confidence Level: "<high | medium | low>"
Date Created: "<DD/MM/YYYY>"

Add more detail when it matters

Use these when the work is higher risk or more visible.

AI:
Tools: "<tool name>"
Provider: "<organisation>"
Risks_considered:- "<risk>"
Limitations:- "<known limitation>"
Review Status: "<reviewed | reviewed and amended | exploratory>"
Last Updated: "<DD/MM/YYYY>"

The indentation used helps to see the relationship between connected values.

How to describe AI use

Always be clear about:

  • what the AI helped with
  • what it did not do

Keep it short and specific.

Examples that work

Research

AI was used to group and summarise interview notes.

The researcher reviewed the outputs and wrote the findings.

Product

AI was used to draft early problem statements and acceptance criteria.

The team decided priorities and scope.

Design

AI was used to suggest content options and accessibility improvements.

The designer made the final decisions.

Engineering

AI was used to suggest code changes.

All code was reviewed, tested, and approved by a person.

Examples that don’t work

“AI was used”

“Generated by AI”

“AI-assisted”

Confidence levels

Every AI-assisted output must include a confidence level.

  • High: checked against trusted sources or real data
  • Medium: reviewed, but not fully validated
  • Low: early, exploratory, or draft work

Every AI-assisted output must include a confidence level.

  • policy decisions
  • eligibility rules
  • public-facing guidance

until it has been reviewed again.

Risks

Keep this brief. If the work could affect users or decisions, note any risks you considered, such as:

  • accuracy
  • bias or missing perspectives
  • policy or legal meaning
  • accessibility or potential harm

This is a short note, not a formal risk process.

Where this applies

Use this for things like:

  • research reports
  • design work
  • product specs
  • tickets and delivery notes
  • code and technical decisions
  • content drafts
  • presentations

Put the accountability note as close to the work as possible.

What this guidance avoids

To keep it usable, this does not require:

  • listing models in detail
  • saving prompts
  • getting approval to use AI
  • tracking individual behaviour
  • long disclaimers

If it becomes heavy, people will stop using it.

Quick sense check

Someone new to the work should be able to answer:

  • Was AI involved?
  • What did it help with?
  • Who owns the outcome?
  • How confident should I be?

If they cannot, the work is not finished.