Three Conditions for Operator-Led AI Transformation

011. Clear scope and accountability

Separate what a team may change, what needs business approval, and what technology, legal, or security owners control. When authority is vague, teams either run risky experiments or change nothing at all.

Draw the line by who the change affects, not by how big it looks. A change that stays inside the team's own procedures or checklists can sit with the team. Anything that touches journal entries, payments, or documents sent to customers affects financial figures or people outside the company, so it goes through an approver.

Fixing accountability first matters because results arrive unevenly. In IPA's DX Trends 2026, covering 1,799 Japanese companies surveyed between 17 April and 12 June 2026, 60.8% reported achieving the objectives they had set for their DX work. Those results concentrate in data digitisation and process efficiency; new business creation and enterprise value showed limited progress. The same survey found 85.5% reporting a shortage of people to drive the work.

Read against that result, process efficiency is the most realistic first target for operator-led work. To turn the time it frees into the next improvement, decide up front who may decide what, in writing. Fill in the table below for each department, and treat any change you are unsure about as the stricter tier.

02Experiment plan template and a worked example

Give each improvement a process owner, and capture the objective, metric, data boundary, and stop condition in a short plan. Keep it to one page and always include a stop condition. Without one, an experiment that is not working keeps running and keeps consuming the team's time.

Do not skip the "data not used" line. Stating what stays out gives the approver something concrete to judge and speeds up the tier decision.

The following is a fictional example. It imagines an accounting team using AI to help match incoming invoices against the vendor master before raising payment requests. Any counts or periods in it only show how to fill in the form; they are not results from a real company.

The point to notice is that the AI output never changes journal entries or payments directly. The AI proposes matching results; the clerk still raises the payment request. Designed this way, the experiment fits within Tier A. If you later want AI to produce the payment data itself, treat that as Tier B and get approval first. For a step-by-step path that tackles key-person dependency and controls together, see the accounting roadmap.

# Experiment plan
- Name:
- Process owner (name, role):
- Process in scope (trigger -> completion):
- Objective (what should improve):
- Metric (including how it is measured):
- Data used (type and where it is stored):
- Data not used:
- Authority tier (A / B / C) and approver:
- Who checks the AI output, and how:
- Period (start - end):
- Stop condition (stop if this happens):
- What is left behind (procedure, template, lessons):

# Experiment plan (fictional example)
- Name: Assisted matching of invoices against the vendor master
- Process owner: Lead for payments in the accounting team
- Process in scope: invoice received -> matched against vendor master -> payment request created
- Objective: catch easily missed differences (bank details, payment terms, rounding in invoice amounts) before the payment request is raised
- Metric: missed differences (e.g. count the ones the team only notices at month-end), time spent matching (e.g. minutes per invoice, logged by the team)
- Data used: invoice images; vendor code and payment-terms columns from the vendor master
- Data not used: full bank account numbers, individual staff evaluations
- Authority tier: A (the AI only proposes matching results; it never changes journal entries or payment requests)
- Checking the output: the team reviews each proposal and only invoices they judge to differ go through the existing exception steps
- Period: e.g. one month-end close
- Stop condition: evidence that AI proposals were copied without review / data sent to a service the company has not approved
- What is left behind: a checklist of matching points, the prompts used, the invoice formats that did not work

032. Learning through real work

Generic prompting lessons rarely change operations. Use the participants' own workflows and exception cases: map the current steps, the judgment criteria, and the exceptions, then build a small assist.

Pick training material from work the participants will do again next week. What they map in the session can be used straight away, so they test what they learned inside real work. To find candidate processes, use the method in our process inventory guide.

Practice data handling, privacy, intellectual property, and output verification through concrete scenarios rather than abstract prohibitions. In the session, have participants answer questions like these in their own words and say which tier of the authority table each one falls into.

The prompt below helps map a process as it runs today. Because it is written to ask questions back, it draws out the judgment criteria and exceptions people usually keep in their heads. The resulting table can be copied straight into the "process in scope" and "checking the output" lines of the experiment plan.

• May I paste an invoice showing a vendor's bank account number into an AI service the company has not approved?
• May I copy AI-generated matching results into a payment request without checking them?
• May I reuse text from another company's public material verbatim in our internal procedure?
• May I ask AI to summarize a sheet containing employee names and evaluation comments?

You are helping me document a business process. Ask me questions as you go.

Process: {process name}
Role of the person doing it: {e.g. payments clerk in accounting}
Frequency and volume: {e.g. every month-end, rough count is fine}

Steps:
1. List the current process in order, from the trigger to completion. Do not fill gaps with guesses; ask me instead.
2. For each step, separate where the person makes a judgment from the criteria they use.
3. List the cases treated as exceptions and how each is handled.
4. Suggest steps where AI could assist, and for each one say who checks the output and how.

Constraint: do not handle real data such as personal names, vendor names, or bank account numbers. If you need an example, ask using placeholders such as "Vendor A".
Output: a table with six columns: step, owner, judgment criteria, exceptions, AI assist candidate, how the output is checked.

043. Improvement is recognized as work

When improvement sits outside normal duties, it stops during busy periods. Reserve time for experimentation and recognize quality, reuse, and knowledge sharing, not saved hours alone.

A failed experiment that preserves its assumptions and learning is still an organizational asset. Sharing only the successes pushes risks out of sight.

Put experiment time on each person's weekly calendar as a fixed block that their manager has approved as working time. If you do not define what gets evaluated, only experiments with large time savings get reported. Use a review sheet like the one below, with columns beyond hours saved, and add one row per experiment.

Experiments marked "stop" in the next-decision column belong on the sheet too. When the reason for stopping is recorded, another team does not have to repeat the same experiment.

05Operate a cross-functional community

Connect operators, process owners, IT, legal, and security in a regular review. Give people one place to ask, so similar improvements can be reused instead of rebuilt.

A central team should provide templates, shared data, and quality gates instead of building every solution itself. A quality gate is the set of checks an improvement passes before it becomes standard procedure: whether a person reviews the output, whether the stop condition was respected, and whether the data used stayed within its tier.

Running the review in the order below keeps decisions from slipping. Making the authority table a standing agenda item turns each borderline case into a rule for next time.

06Stand up the loop in 90 days

Define problems and guardrails in the first 30 days, run two or three experiments in the next 30, and establish evaluation and reuse in the final 30.

Prove one full cycle from proposal to standardization before optimizing for volume. You can tell the cycle is complete when at least one experiment has reached standardization and the reasons behind any stopped experiments are on record.