English
JapaneseIn late 2024, the engineering leadership of a leading Japanese commercial vehicle group sat down with a question that decided more than a deployment. Where exactly should artificial intelligence stop, and where should the technician’s authority begin?
The technology to push AI further into the diagnostic process was available. The business case existed. The implementation team had built systems with broader scope before. What the group decided that week and how they reasoned about it is the reason their Technician Co-Pilot has been in production for over a year while comparable rollouts at other organizations are still struggling to leave proof-of-concept.
The story of that deployment is not a technology story. It is a story about a design choice. The choice was the boundary.
The Problem – Knowledge inaccessible at the speed the work demands
Heavy-duty commercial vehicle servicing has a recurring problem with one root cause. A modern truck pulls into the service bay with potentially hundreds of trouble codes, a service history that may live in three different systems, engineering bulletins that have accumulated across the model’s production lifetime, and a customer expectation that the vehicle will be back on the road within a defined window.
The technician, the only person legally and operationally accountable for the diagnostic and repair decision has to integrate all of this, fast. The reference material exists. The expertise exists. But neither is at the technician’s fingertips in the moment. The result is variability in time-to-diagnosis, variability in first-time-fix rate, and slow knowledge transfer from senior technicians to newer ones.
The Design Question
The group’s engineering leadership did not open the discussion with “what can AI do?” They opened it with a different question:
What is the technician’s job, exactly, and what part of it cannot be delegated to a machine?
The answer they arrived at was specific and operational. The technician’s accountable work is to diagnose, decide, approve, release, and sign. Each of those acts carries regulatory weight, safety implications, and customer trust. None of them can be outsourced to a system whose reasoning cannot be fully audited or whose behaviour can drift between updates.
Everything around those acts – retrieval, comparison, synthesis, similar-case lookup is high-value but not accountable work. It is exactly the kind of work that consumes a technician’s time without conferring authority. And it is exactly where intelligence helps.
The boundary decision – AI retrieves, the technician decides
From that distinction, the boundary was drawn explicitly. AI retrieves. The technician decides.
What AI does: in response to technician queries, the Technician Co-Pilot retrieves relevant service procedures, similar historical cases, applicable engineering bulletins, and contextual diagnostic information from the knowledge base. It returns this material at the speed of conversation.
What AI does NOT do: make the diagnostic decision. Approve the repair. Release the vehicle. Sign the service record. Generate the customer-facing repair authorization. These are excluded from the AI’s scope by design, not by oversight.
Figure 1 · The four pillars behind the boundary decision.
How it works in practice
A vehicle arrives. The technician begins the inspection. When a diagnostic situation requires reference material, the technician queries the Co-Pilot. The query can be in natural language, in the technician’s working language, with whatever context is at hand.
The Co-Pilot returns: relevant service procedures, similar past cases that were resolved, engineering bulletins, and dealer notes on this specific vehicle’s service history. It returns this in seconds, in a format the technician can scan without leaving the work.
The technician reads, decides, acts. The diagnosis is theirs. The repair authorization is theirs. The signature is theirs. The Co-Pilot is, throughout, a faster way of getting to the information the technician would otherwise be looking up, not a substitute for what the technician does with it.
Figure 2 · Workflow showing where AI enters and where it stops.
Adoption outcomes – the boundary built the trust
The deployment is now over a year in production. Two outcomes are worth naming.
The first is straightforward. Time-to-diagnosis has measurably improved. First-time-fix rate has improved for the diagnostic categories where reference material was previously hardest to retrieve.
The second is the more telling one. Adoption among technicians was meaningfully higher than comparable AI rollouts at other organizations where AI had been positioned as a substitute, an “expert system,” or a partner with decision authority. Several senior technicians who had been skeptical of AI in service environments became some of the system’s strongest users.
The boundary built the trust. Technicians adopted the system faster because it stayed in its lane. It made their judgment better, not redundant.
What this means for other operational AI deployments
The Technician Co-Pilot is one example of a broader principle. The AI deployments that survive contact with operational reality for years, not quarters, tend to share a single design choice: the boundary between AI work and accountable human work was decided before the technology was built. Not after. Not retroactively. Before.
That sequence – boundary first, technology second, is what allows operational systems to absorb AI without losing the discipline they were built on. Quality first. Safety first. Accountability preserved.
The most useful question a CIO can ask of any operational AI project is not “what will AI do here?” It is “what will AI deliberately not do here and why?” The teams that can answer the second question with precision are the teams whose deployments last.
A year on, the question that opened the deployment, where should AI stop, and where should the technician’s authority begin? – is the same question that explains why the deployment is still working today.
The boundary was the design.
