AI in engineering companies · The five levels of AI value

From what the manual says to what the product is doing

Catherine Ives-YimPublished 27 September 2026 · 6 min read

The first two levels of AI value in an engineering company work with what the organisation already has on file: its documents, and the structured facts extracted from them. The third level is different in kind. It connects AI to the live systems where the product's actual behaviour is recorded: telemetry, service tickets, manufacturing and build records, test results.

That changes the question AI can answer. At the first level, a support engineer can ask what the manual says about a symptom. At the third, they can ask why this particular unit, in this customer's hands, is failing today, and get an answer drawn from the unit's own history.

It is also the level where the risks change, because AI is now looking at live operational data, often including personal data, rather than at a library of documents.

What "connect" means

In a connected product company, the systems that matter are usually:

the telemetry or device management platform, holding what each unit reports
the service and support system, holding what customers and engineers have said
manufacturing and build records, holding what each unit was made from
product lifecycle management, holding designs, versions and changes
test systems, holding what was measured and whether it passed
source control and release records, holding what software went where

Connecting AI to them does not mean giving it the keys to every database. It means giving it a defined set of tools: specific, controlled ways to ask each system a question, such as "fetch the last thirty days of fault codes for this unit" or "list open tickets for this product variant". The AI decides which questions to ask. The tools decide what it is allowed to see.

Our fault at level 3

Following the example used throughout this series: a connected product is showing a recurring fault in the field.

A customer reports a problem. The support engineer asks the AI assistant about the unit. The assistant retrieves its build record and finds it contains a component from a particular batch. It checks the firmware history and sees an update last month. It pulls the recent telemetry and finds the fault codes began two days after that update. It compares this with the structured history from level 2 and finds eleven other units with the same batch and firmware, four of which have already reported similar symptoms. It retrieves the relevant diagnostic procedure from the manuals.

The support engineer has, in a couple of minutes, what would previously have taken a series of requests to three departments, if it happened at all.

I built this pattern into the connected vehicle platform I designed: continuous telemetry, on-demand high-rate data during a live ride, and the ability for a support agent to see what the customer's app is seeing, in real time. What AI adds is the ability to bring all of that together and reason across it in plain language, instead of an engineer assembling it by hand.

Where the value is

Diagnosis. Faster, better-informed diagnosis of individual units, with fewer unnecessary returns and fewer repeat visits.

Support quality. Every support agent works with the context that previously only the most experienced engineers could assemble.

Engineering investigation. When engineering is asked to look at a problem, it starts with the evidence already gathered, rather than a request for data that takes a week to arrive.

Proactive service. Once the connections exist, it becomes possible to ask which other customers are likely to be affected, and to contact them before they call.

Why level 2 must come first

The most common reason level 3 projects struggle is that the systems do not agree about what they are describing. The telemetry platform identifies a unit by one number, the service system by the customer's order reference, and manufacturing by a serial printed on the chassis. Firmware versions are written differently in each. Component batches may not be recorded at all.

An AI assistant can sometimes bridge these gaps by inference, but an engineering diagnosis should not rest on a guess about whether two records describe the same unit. The structured model from level 2, with its agreed identifiers and links, is what makes level 3 reliable. This is why I describe the levels as a ladder rather than a menu.

The risks that are new at this level

Access control. An AI assistant that can query every system on behalf of anyone who asks has quietly bypassed the organisation's permissions. The assistant should see only what the person asking is allowed to see, and every query it makes should be recorded.

Read before write. At this level, the AI should look and not touch. Changing records, pushing configurations or contacting customers belongs at level 4, with a person approving each action.

Personal data. Telemetry often includes location, usage patterns and account details. That brings data protection law squarely into the design: minimising what is retrieved, controlling where it is processed, and deciding which model may see it. This is where the choice discussed in Where should your AI live? stops being a policy preference and becomes an engineering requirement. Many organisations will reasonably process customer telemetry on UK-hosted or local models while using frontier cloud models for work that does not involve it.

Untrusted text. Service tickets and customer messages are written by people outside the organisation. Text that reaches an AI assistant can contain instructions, deliberately or otherwise, and an assistant with access to internal systems must be built so that nothing a customer writes can direct what it does. This is a real and underestimated risk, and it is one more reason to keep AI at this level read-only.

Partial evidence. If one system is unavailable or out of date, the AI may reason confidently from incomplete data. It should always show what it looked at, what it could not reach, and how current each source was.

Connectivity. Workshops, test cells and field sites do not always have reliable connections. An assistant that only works with a cloud connection may be absent exactly where it is needed. Local models have a practical role here.

How to start

Begin with one connection and one type of question. A good first step is read-only access to service tickets and telemetry for a single product line, answering one question: "What do we know about this unit?"

Measure something that matters, such as time to diagnosis or the proportion of units returned with no fault found. Record every query. Review the answers with experienced engineers for the first few weeks. Then add the next system.

Four things worth taking seriously

For engineering and service leaders: the most valuable information about your product is what it is doing in the field. Level 3 is how you put it in front of the people who need it, when they need it.

For IT and security teams: treat an AI assistant as a new kind of user with its own permissions, its own audit trail and its own attack surface. Design for that from the start.

For data protection leads: connecting AI to customer telemetry is a new processing activity. Assess it as one.

For anyone planning this work: fix the identifiers first. An assistant that cannot be sure two records describe the same unit is an assistant you cannot trust.

I would be interested to hear how long it takes in your organisation to assemble the full picture of a single failing unit, and how many people are involved.