Practice piece · Responsible AI

Interest in AI got ahead of the capacity to review it

One way I design a Responsible AI intake that people outside technology can answer, cheap enough that people use it, and built to follow a use case past its first assessment. Shown through an invented college.

In shortInterest in AI use cases often grows faster than a central team can review them one at a time. My approach is a short self-assessment that the person responsible fills in themselves. Their answers decide which cases need an expert. It's an approach that has worked for me, not the only way to do it. The organization in it is invented.

Reading as

Approach: Self-assessment intake, answer-driven review paths, a record that follows the use case
Example: Wrenfield College, an invented college
Practised in: Enterprise data governance work

Schematic, with an invented college. Requests climb faster than one team can review them one case at a time, and the gap becomes a backlog.

Why it exists

Make declaring cheap enough that people do it

requestedintakeassessedreassessedrequested, and waiting for review

Governance needs to find out what AI is in use, spot risk early, and send each use case to the right people.

Why it matters · an invented example

At Wrenfield, one department is offered an AI feature in its student-support tool. Another wants AI in a product it's building with a partner. A third wants to add it to something it built itself. All three requests land on the same small review team.

Many directions

Interest arrived from every direction at once

At Wrenfield, teams were being offered AI in vendor tools, wanted to use it in products built with partners, and wanted to add it to things the college built itself.

The queue

More requests than reviewers

There was no version of a central team getting through that queue one case at a time. Interest grew faster than review capacity, which in my experience is common.

The cost of one gate

A uniform gate filters out the small cases

inferredIf declaring a small, low-risk piece of work costs as much as declaring a high-risk one, the small work stops being declared, or goes around the gate. The gate then only sees the cases people are still willing to bring to it.

The design question

Which cases need an expert at all?

The sponsor of a use case (the person responsible for it) completes the assessment themselves. Expert review happens only when their answers trigger it.

It is deliberately not an IT review, so anyone responsible for a use case can answer it.

Another way is expert review for every case. That can suit an organization with a handful of high-stakes use cases. It doesn't suit a queue that grows faster than the reviewers.

Where the requests came from

vendor toolsproducts built with partnersthe college's own builds →governance needs to see it

one review teamcan't take them one case at a time

One gate for every case · illustrative

effort to declare → Low-risknot declared Low-risknot declared Medium-riskfull review High-riskfull review

inferredSame cost for every case, so the small ones stop being declared.

Answers decide who needs an expert · illustrative

effort to declare → Low-riskself-assessment Low-riskself-assessment Medium-riskself-assessment High-riskself-assessmentexpert review

Expert time goes where the answers point.inferredCheap to declare, so small cases are more likely to be declared.

The intake

An intake anyone responsible for a use case can answer

requestedintakeassessedreassessedthe intake and the assessment

One front door, one self-assessment, and an answer for every submission.

Principles

Principles as everyday expectations

I start from the organization's own principles, turn each one into an everyday expectation, and give people a single self-assessment as the way in.

Wrenfield's five, invented for this page: fairness, transparency, accountability, privacy and safety.

The assessment

Questions about the work, not the technology

Most questions are yes or no. They ask what the AI does, who uses it, what data it touches and what decisions it informs.

A privacy screen sits alongside the principles, so privacy can follow up whatever the review path.

Describing a use case

A fill-in pattern and a worked example

Guidance with a fill-in pattern and a worked example steers people towards plain-language descriptions that make human oversight, personal data and impact on people visible, and away from technical architecture.

I use an AI assistant to check that guidance reads clearly to someone outside technology.

Triage

Every submission gets an answer

A workflow gives each submission a reference number, applies the rules (the logic that turns answers into a review path), and sends the submitter a notice: the review path, the reasoning and the next steps.

Expert review follows only when the answers call for it.

FrontPrinciples, one self-assessment (invented) fairnesstransparencyaccountabilityprivacysafety

SponsorAnswer mostly yes/no questions what it doeswho uses itdata it touchesdecisions it informsprivacy screen

SponsorDescribe it in plain language human oversightpersonal dataimpact on peopleclarity checked with AI

FlowReference number, then rules

NoticeReview path, reasoning and next steps

ExpertReview, only when answers trigger it

The notice · schematic

ReferenceReview pathWhyNext steps See one built from your answers ↓

Honest answers

Designing for answers people can actually give

requestedintakeassessedreassessedan assessment, as Wrenfield runs it

Three ideas I build into the assessment itself. The panel lets you try them.

Everything here is invented. Wrenfield, its questions, field names, rules and review paths are made up for this page. Nothing you choose leaves this page.

Review paths

The answers set the path, not the person

Wrenfield's rules work out a review path from the answers: self-serve, light review or full review. On any path, answers can also send the use case to privacy. The submitter never picks their own path.

Unsure

“Unsure” is a signal that needs review

An unsure answer isn't counted as a no. The system names the specific questions the submitter was unsure about, so reviewers have something concrete to follow up.

Set an answer the rules depend on to Unsure, such as whether it informs decisions about students, and the path becomes a range instead of a guess.

Stated vs computed

What people said, kept apart from what the system worked out

I keep what the person said apart from what the system worked out, with a naming convention for fields, so the line between them stays visible in the record.

In the panel, the left column is what the person said and the right column is what the system worked out.

The panel shows the idea with answer.* and derived.* prefixes, invented for this page.

The pattern · invented questions

Is it already in use? Yes
Does it inform decisions about students or applicants? Yes
Does a person review its output before anyone acts on it? Yes
Does it use personal information? Unsure
Will students or the public interact with it directly? No

ResultLight review

Privacy: follow-upExpert review: triggered

Unsure on: Does it use personal information? Each one goes to a reviewer to follow up.

You've just assessed something already running. That's an assessment after the fact.

answerwhat the person said

answer.already_in_use = Already in use: yes
answer.student_decisions = Informs decisions about students: yes
answer.human_review = A person reviews output first: yes
answer.personal_data = Uses personal information: unsure
answer.public_facing = Students use it directly: no

derivedwhat the system worked out

derived.review_path = Review path: light review
derived.privacy_routing = Privacy routing: follow-up
derived.expert_review = Expert review: triggered

The notice

What the submitter gets back

This is the notice your answers above would send: a reference number, a review path, the reasons and the next steps. Change an answer and it rewrites itself.

The notice this would send · invented

SubjectYour AI use case: Light review, expert review triggered

Reference

REF-4478 (invented)

Review path

Light review

Why

It informs decisions about students or applicants.
You were unsure on 1 question.

Privacy

Privacy will follow up on your unsure answer.

Next steps

An expert reviewer will follow up on the points above.

Limits: this reflects the answers given. Where expert review is triggered, the reviewer decides what happens next.

By responsibility

Documented by what each part is responsible for

requestedintakeassessedreassessedinside one assessment

I describe a service by what each part is responsible for, not by which platform it runs on, and label each part as verified, documented or planned.

The swap test

The meaning lives in the decision logic

inferredReplacing the workflow tool would barely change the service. Replacing the decision logic would make it a different service.

In plain terms: the tool that moves the form around matters much less than the rules that decide the path.

Authority

Authority assigned per piece of information

I map which part holds authority for each kind of information: the original response, the computed result, the governance record and the notice sent.

No single system gets labelled the source of truth for everything.

For each kind of record, exactly one place holds the official copy.

Status labels

A record that says how sure it is

Every claim in the architecture record carries a status: verified, documented or planned.

The record stays provisional until it's checked against the running system.

Swap test · invented · inferred

Your answersYYY?N Workflow tool Decision rules Review pathLight review

The current setup. Swap the tool, then the rules.

Swap one part at a time. Edit your answers ↑

Authority by information type

original responsecomputed resultgovernance recordnotice sent

→one authoritative home for each

one source of truth for everything

Architecture record · component status

verifieddocumentedplanned

provisional until checked against the running system

This page does the same to itself. Its main claims are graded in What it can claim ↓

observeddocument-supportedinferred

Between assessments

A use case outlives its first assessment

requestedintakeassessedreassessedafter the notice, and between assessments

Two questions I ask of any intake before it launches. Both are about what it keeps once it has answered.

Identity

Can it tell this is the same use case?

A reference number names a submission, not the use case. Without a lasting ID that follows a use case through every assessment, a reassessment can't be linked back to the earlier one.

Without that link, an intake stays a queue of submissions instead of becoming an inventory. Try it with the notice you got above.

What an inventory record adds: a persistent ID, plus the overview, data, logic and governance details that public AI registers publish for each system, kept up to date as it changes.

Decisions

Does it keep what the reviewer decided?

The rules produce a recommendation. A person makes the decision. I record both with the use case, because an intake that keeps only its recommendation can't show whether its routing works.

1identitySame use case, new reference

Your notice

REF-4478

Light review · privacy follow-up

use-case ID none

your answers, plus one change

A year later

REF-5509

Full review · privacy follow-up

Since then (invented): nobody reviews its output first.

use-case ID none

To you, it's the same use case. To the record, REF-4478 and REF-5509 are two unrelated submissions. Its path moved from light review to full review, and nothing here can connect the two.

An inventory record would carry one persistent ID across both.

2decisionRecommendation, then decision

recommendation computed→reviewer decides→both kept with the use case

What it's for

An intake people use, built to follow a use case through its life

Cheap to declare

The person responsible answers for their own work, gets a notice straight away, and expert time goes where the answers point.

Built for the second assessment

A persistent use-case ID and a recorded review decision, so over time the intake becomes an inventory.

An assessment is an event, but a use case has a life. I design the intake to model both.

What it can claim

What this story can support, and what it can't yet

I graded these myself. Each claim is either visible on this page, backed by a linked public source, or my professional judgement, which this page doesn't test.

Claims register · 11 claims, and how well each is supported

observed: Visible on this page. You can check it here.
document-supported: Established by a linked public source.
inferred: My practice: professional judgement, not tested here.

Claims register
Evidence	Claim	What supports it
inferred	In my practice, a gate that costs the same for every case filters out the small ones.	My practice. Not measured.
document-supported	Self-completed questionnaires that compute an impact level are an established public-sector pattern.	Government of Canada, Algorithmic Impact Assessment tool: a questionnaire whose score sets one of four impact levels.
inferred	In my experience, letting answers decide who needs an expert saves expert time without letting risky cases through.	My practice. Testing it needs the review decisions recorded, which is one reason I design for that.
observed	In the panel, the answers set the review path. The submitter can't pick it.	The panel above.
observed	An unsure answer is tried both ways, so the path becomes a range and the question is named for follow-up.	The panel above.
observed	What the person said and what the system worked out are kept in separate columns.	The panel above.
inferred	In my practice, a service's meaning lives in its decision rules, not its workflow tool.	My practice. The swap demo illustrates the argument; it doesn't test it.
inferred	In my practice, one authoritative home for each kind of record has worked better than one source of truth for everything.	My practice.
observed	Without a persistent ID, the same use case assessed twice becomes two unrelated submissions.	The reassessment demo above.
document-supported	Public AI registers keep a record per tool and update it when the tool changes.	UK government, Algorithmic Transparency Recording Standard guidance: records are updated and republished when substantive details change.
inferred	In my practice, an intake that keeps only its recommendation can't show whether its routing works.	My practice.

Mine

The approach, the invented example, the writing and the interactive pieces.

Where I've practised it

I've used this approach in enterprise data governance work.

AI

I build pages like this with AI assistants and check everything they produce.