The AI steering cycle: measure, review, decide
The AI steering cycle is a method for steering an organisation's AI transformation on evidence, against goals set first. Council after council, leadership's AI council measures every AI use case, reviews what moved, and decides what to build, scale, automate or stop.
It is written for the executive accountable for the AI transformation, and for the council chair or head of AI who runs the cycle. Quilane is the app that carries the measure, review and record steps. Leadership, through its council, decides. The method itself is free to use, with or without Quilane.
Last updated
Stop as much as you scale
An AI council's job is to stop things as much as to scale them. A council that only scales, or only hears updates, is not steering. Stopping is a decision, not a failure.
The evidence speaks in gaps, not scores. The line an executive committee needs is often a gap: "we built level 3, but we work at level 2". Or the reverse, when teams adopt use cases built elsewhere. Quilane shows both readings, for every department and for the whole organisation.
Evidence means nothing until it is read against something. So goals come first. Before the first council, leadership writes the few outcomes AI is for; each department, then each team, says how it serves them. Goals go down, evidence comes up, and the council is where they meet.
"to go from individual usages to organisational gains, at every level of the organisation"
The framework at a glance
One loop, run every council: measure, review, decide. Goals sit above it. Four decisions leave it.
- Know where you start (Stage 0).
A quick baseline, taken before the goals are set.
- Set the goals (Stage 1).
The prerequisite. Every measure is read against them.
- Measure (Stages 2 and 5).
Map where AI really works, and capture value against what was expected.
- Review (Stage 6).
Each council starts from what moved since the last one.
- Decide (Stage 6).
Each use case leaves with one of four decisions: build, scale, automate or stop.
- Build
- Scale
- Automate
- Stop
Beside the loop sits what makes the cycle mean something: a system people can work in (Stage 3), and people who climb one level at a time, with proof (Stage 4). Without them, the measures describe noise.
In one minute. Set a few goals first. Then, every council, measure, review and decide. Each use case leaves with build, scale, automate or stop, and you stop as readily as you scale.
Stage 0. Know where you start
Method
Before setting goals, take a quick, honest reading of where your organisation stands: which foundations of steering are in place, and which of the four decisions it already takes. The baseline informs the goals. It does not replace them, and it is not the map.
The foundations
- Goals. Are your AI goals written as outcomes, each with a baseline, a target date and an owner? Does each level know which goals it carries?
- Map. Could you show leadership every AI use case by department, and what the person still does in each?
- System. Can people's AI tools reach the company knowledge and data their work needs? Do shared methods have owners?
- People. Did guidance by role follow access? Is progress shown by observable results?
- Value. Do you compare actual value with expected value, or rely on usage and estimates of time saved?
- Governing body. Does a council meet on a rhythm, start from what moved, and decide, each decision with a reason and an owner?
The four decisions
- Which of build, scale, automate and stop has your organisation actually done: not started, started case by case, or repeatable?
- When it decided, what weighed most: a goal and evidence, or requests and activity counts?
- How sure are you that you could show the evidence behind your last decision to scale or stop a use case?
A useful baseline fits on one dated page. Each foundation is marked in place, started, not yet, or not known. Each decision is marked not started, started or repeatable. What is not known is written down as something to find out, not guessed. Three things to address first become inputs to the goals.
Common failure. Skipping straight to tools or goals without knowing what exists. Guessing instead of writing "not known". Taking the baseline for the map, or for a maturity rating.
| Item | Stage 0, Know where you start | Stage 2, Map where AI really works |
|---|---|---|
| Level | The organisation as a whole | Every use case, in every department |
| Source | Leaders' own answers, indicative | Usage, costs and proposals imported from files, measured the same way everywhere |
| Time | A few minutes | A piece of work, then repeated each cycle |
| Output | A profile of foundations and decisions; what to find out | Maturity, adoption and capture per use case; department maturity, Built and Used |
| Who carries it | Your organisation | Quilane, at launch |
Quilane, at launch. Nothing. Quilane does not measure this baseline. It is your organisation's own reading.
Stage 1. Set the goals
Method
Decide what AI is for, in your organisation's own terms, before any tool or use case is discussed. The goals are what the council reads its evidence against. The Stage 0 baseline tells you what they must address.
Key questions
- Organisation: which few outcomes should AI serve, such as growth, cost, risk, speed or quality, and how will we know?
- Department: which of those goals does it carry, and which of its processes should change?
- Team: which recurring tasks serve that goal, and what result is expected of each use case?
- Person: what does my own work need to do better?
What good looks like. A few goals at the top, stated as outcomes, each with a baseline, a target date and an owner. "Licences rolled out" and "people trained" are activities, not goals. Departments link their goals to the organisation's and agree them both ways: a proposal from below is attached to a goal, or flagged as unattached. Department objectives can read: use cases at the level their work justifies, value spread across more teams, duplicated methods merged, feedback fixed within a set time.
Common failure. "Use more AI" as the goal. Activities counted as progress. Use cases that tie to no goal.
How to measure. Is each goal an outcome with a baseline, a target date and an owner? What share of active use cases is attached to a goal? Your organisation counts this.
Quilane, at launch. Capture is measured as actual value against expected value. New proposals are grouped by business purpose, and their usage waits until the council accepts them. So before accepting one, the council can ask which goal it serves. The goals themselves live in your own documents: Quilane does not hold goals or targets.
Stage 2. Map where AI really works
Quilane, at launch
Measure before you build. Before rolling out anything new, see every use case in every department: who uses AI, for what, and at which level. The first move is a map, not a tool rollout.
Key questions
- Which AI use cases exist, in which departments, and which cross departments?
- For each one, what does the person still do, and what should they do, given the work?
- At what level did we build, and at what level do people actually work?
- Where are we paying for access that nobody uses?
Quilane, at launch. One shared view of every AI use case across departments. Each use case is measured on three separate questions: maturity, adoption and capture. Maturity has four levels, defined by the human's role:
| Level | Decisive question | The human's role |
|---|---|---|
| L1 Manual | Does the AI only answer one step? | The human does the work |
| L2 Semi-auto | Does the AI draft a deliverable the human finishes? | The human iterates and finishes |
| L3 Agentic | Does the AI plan and chain the steps? | The human validates once, before use |
| L4 Autonomous | Is the output used without prior validation? | The human audits after and handles exceptions |
Each client can rename the levels and change their descriptions. There are always four.
Department maturity has two readings, for every department and the whole organisation. They answer two different questions. Built is the capability you have put in place: the average level of the live, adopted use cases a department owns. What level have we industrialised? Used is the level people actually work at: the level of the use cases its people actually used in the last 30 days, weighted by people. At what level do we really work? A Global department holds cross-department use cases and shows which departments use them.
Method. Maturity is a gap, never a target.
| Gap | What it compares | Who reads it |
|---|---|---|
| Built against Used | The level a department has built, against the level its people work at. It runs both ways: built above used, or used above built | Quilane shows both readings; the council reads the gap |
| Actual against justified | The level a use case is at, against the level its work justifies | Your organisation decides and records the justified level |
Do not read either average as a target. A department whose use cases sit at the levels their work justifies is on course, whatever its average. L4 is not for everyone. Access that is barely used is not a maturity level: it is an adoption gap.
Common failure. Counting seats and calling it maturity. One organisation-wide score that hides the spread between departments. Reading conversations to find out what happens.
Stage 3. Prepare the system
Method
Before asking people to move up, make sure the system around them works, or each person reinvents the same thing alone. People's AI tools reach the company knowledge and data their work needs. Ways of working used by several people have an owner, and people search before they build. When a shared method breaks, people flag it to its owner rather than work around it. The common failure: approval gates that slow everything while unowned copies multiply.
Quilane, at launch. The shared view of every use case is where a team checks what already exists before proposing a new one. Quilane lists use cases; it does not manage methods, prompts or data connections.
Stage 4. Raise the level, one level at a time, with proof
Method
Help people move from doing everything themselves to directing and checking the work. Then help each use case climb towards the level its work justifies.
Key questions
- Do people check output before it leaves?
- Does each use case move up only when a result shows it?
- Is use spread across teams, or carried by a few people?
"From doer to pilot." Here "pilot" names the person's role, as in a cockpit. The person moves from producing everything to briefing, reviewing and deciding; from searching to asking the right question; from speed to judgement.
Four reflexes before anything leaves. Question: is it answering the right question? Challenge: ask for the opposite view. Validate: check every number and its source. Judge: would I sign this? Your name is on everything that leaves; the AI's never is.
The climb. One level at a time, with proof: a concrete, observable result at the end of each step, not a self-assessment. Breadth before depth: when a few people carry most of the value, spread it rather than push the same few further.
Read the gap before building higher. When a department's Built reading sits above its Used reading, "we built level 3; we work at level 2", check what sits behind it before building higher. Quilane shows the two readings; it does not show the cause.
Common failure. A launch session followed by "each to their own". Pushing everyone towards L4. Self-reported confidence taken as progress.
Quilane, at launch. Each use case's maturity level shows the human's role as practised, and the Used reading shows the level people actually work at. Use cases that are frequent, proven and still manual are flagged as agent candidates, which the council confirms or rejects with a reason. Where the organisation has opened "My AI", each person can see their own adoption, time saved and maturity there, and nobody else can; it is optional for each employee (see "Goals reach every person" below).
Stage 5. Capture the value, on the line and not at the station
Quilane, at launch, for the measure; Method for the rest
Turn individual time saved into organisational value. Measure value against what was expected, not the hours people believe they saved. Capture drives the decisions to scale and to stop.
Key questions
- Is each use case capturing the value we expected?
- Who set the expected value, and who confirms the actual value?
- Who receives this team's output, and can the next link in the chain absorb it?
- Where does the time we save go?
The proposer sets the expected value, and the council accepts it when it decides to build. The department owner, not the proposer, confirms the actual value.
Method. Optimise the line, not the station. One team going much faster changes nothing if the next link does not move. Producing is free; reading is not. Reinvest saved time on purpose, closer to customers, in sharper decisions, in systems the team reuses, or it leaks into more of the same.
Built above Used: the level in place is higher than the level people work at. Used above Built: people work at a higher level than their department's own use cases, on use cases other departments or the Global department own. The gap is one place to look; Quilane does not show why value falls short.
Common failure. Adding self-reported minutes saved and calling it return. The proposer marking their own use case a success. One fast team creating a queue downstream.
Quilane, at launch. Capture per use case, actual value against expected value. Value captured, cost per tool, net value, return and idle spend over the last 12 months. Quilane shows these figures; it does not prove that AI caused a result.
Stage 6. Review and decide: build, scale, automate, stop
Quilane, at launch, for review and record; Method for the decision
On a fixed rhythm, leadership reads what moved against the goals and decides what to build, scale, automate or stop.
The council meets monthly: short enough that a set number of councils means months, not years; long enough for file-based imports and a change to show.
Key questions
- What moved since the last council?
- Which use cases serve a goal and capture value?
- Where did we build a level people do not use, and where do people use more than we built?
- Which reach too few people, and which should end?
The four decisions (Method, informed by what Quilane shows)
- Build
- Scale
- Automate
- Stop
| Decision | Signals the council may weigh (method guidance, not rules) | What Quilane shows |
|---|---|---|
| Build | A proposal with a clear business purpose, attached to a goal, accepted with its expected value; or a department whose people work above what it has built | Proposals grouped by business purpose; their usage waits until the council accepts them; Used above Built |
| Scale | Capture close to or above expected value where used, while adoption is still short; people in other departments already working with it | The three measures; the Global department, showing which departments already use a cross-department use case; Used above Built |
| Automate | Frequent, proven and still manual | Agent candidates, which the council confirms or rejects with a reason |
| Stop | The stop rule below; spend with little recorded use; no goal served | The three measures; idle spend; the Used reading, with Built above Used as one place to look |
Consider stopping a use case when its capture stays persistently below expected value and its adoption does not move, over a set number of councils. Your organisation sets that number.
Method. Either the council controls the reallocation of AI spend, or it only hears updates. Record each decision with a reason and an owner, and send it back to the teams concerned.
Common failure. A steering group that hears updates and controls no budget. Decisions going to the loudest department. Trials that never end.
Quilane, at launch. A council agenda and a "since last council" view: what moved, what needs a decision, rule changes. Roles of chair, ambassador and viewer, enforced on the server. A change log of who changed what, when, from and to. Quilane records a reason for agent candidates; record other decisions in your own tools.
The ask, per audience
Method
Each cycle, the council says what it expects of each audience.
- Every employee: one thing shipped each cycle, and a step up when a result shows it.
- Managers: protect the time, run a short show-and-tell, nominate a use case.
- Ambassadors: run help sessions, unblock people first, and raise blockers to the council.
- Leadership: make connections and shared methods the default, and reallocate unused access after a set period.
Goals reach every person; reporting stops at the department
The method reaches every person, through their own goals and reflexes. Quilane's reporting does not. At launch, Quilane reports to leadership and the council by use case and by department, never per person. There is no per-person view for the council.
| Level | Goal question (Method) | What is measured, and who sees it |
|---|---|---|
| Organisation | Which few outcomes is AI for? | The council, in Quilane: spend against value across all use cases; the Built and Used readings for the whole organisation. Progress on the goals: your own measures |
| Department | Which goals does this department carry? | The council, in Quilane: department maturity in both readings; adoption and capture of its use cases |
| Use case | What is it for, who should it reach, what value is expected? | The council, in Quilane: maturity, adoption and capture |
| Person | What do I need from AI in my own work? | The person only, in "My AI" |
In "My AI", each employee sees their own adoption, time saved and maturity, and nobody else does: not their manager, not the council. It is optional for each employee, who can hide their usage at any time. An organisation opens it only after its impact assessment, works council information and employee notice.
No conversation content is stored. Employees appear in usage only under pseudonymised identifiers, and people counts under a minimum group size are never shown to viewers. For the Used reading only, there is a stricter floor: it is never shown when it rests on fewer than 5 people, to anyone, the council included. Employees who turn on "Hide my usage" are excluded from it.
Why it is built this way. Because Quilane reports nothing per person to leadership or the council at launch, HR, the data protection officer and the works council can agree how usage will be reported before any usage is reported. Adoption counted seat by seat and person by person turns usage into a question about individuals. Read by use case and department, it stays a question about the work. Goal progress is kept apart from rating people: the method gives no individual performance rating.
What the evidence says
These findings support the method's choices. None of them proves that the method works.
- Few companies show value yet.
In a survey of 1,000 executives published in 2024, 74 % of companies had not yet shown tangible value from AI. The leaders pursued about half as many opportunities as their less advanced peers and put 70 % of their resources into people and processes. Self-reported; how leaders allocate effort, not proof of outcomes.
Source: BCG, 24 October 2024
- Few redesign the work.
Only 30 % of organisations are redesigning key processes around AI. Leader-reported, 3,235 respondents.
Source: Deloitte, The State of AI in the Enterprise: The Untapped Edge
- Perceived speed is not measured speed.
In a randomised trial, experienced developers took 19 % longer with AI tools, yet afterwards estimated they had been about 20 % faster. 16 developers, early-2025 tools.
Source: METR
- Outcomes, not activities.
Key results describe outcomes, not activities. OKRs are not synonymous with performance evaluation, and low grades should be viewed as data for the next cycle.
Source: Google, re:Work guide to OKRs
What this framework does not claim
- It is not a proven recipe. We know of no controlled study showing that an organisation-level AI framework causes better results. This one is a disciplined way to look and to decide.
- It does not prove that AI caused a business result. Capture is actual value against expected value.
- It is not a one-off maturity model. Stage 0 is a starting reading, not a rating. Maturity is read per use case, as one of three measures, and the cycle repeats.
- It is not employee monitoring, and it gives no individual performance rating.
- It is not an AI governance or compliance framework, and it gives no legal advice.
- Quilane does not decide. Leadership decides, through its council.
- Quilane is not a consultancy. The method is free to use without it.
Quilane, at launch, and your organisation
| Stage | Quilane, at launch | Your organisation |
|---|---|---|
| 0. Know where you start | Nothing | The baseline, with the checklist above |
| 1. Set the goals | An expected value on every use case; proposals grouped by business purpose, accepted by the council | The goals, at every level, with baselines, target dates and owners |
| 2. Map where AI really works | One shared view of every use case; maturity, adoption and capture; department maturity, Built and Used; the Global department; file-based imports | The justified level of each use case |
| 3. Prepare the system | The shared view, to check what exists before proposing | Access to knowledge and data; owned, shared methods |
| 4. Raise the level | Maturity per use case; the Used reading; agent candidates; "My AI" for each person, privately, where the organisation has opened it, and optional for each employee | Guidance, the four reflexes, proof at each step |
| 5. Capture the value | Capture; value captured, cost per tool, net value, return and idle spend over 12 months | Who sets and who confirms value; the line; reinvesting time |
| 6. Review and decide | The council agenda; "since last council"; roles; the change log; agent candidates with a reason | The decisions, their reasons and owners; the cadence; the stop rule; budget authority |
Book a maturity review
A maturity review is a demo conversation. We walk through the steering cycle on the sample workspace, starting from where you say your organisation stands on the Stage 0 questions. It is not a consulting engagement, and it does not measure your organisation. Quilane is available at launch.