AI in engineering companies · The five levels of AI value
AI drafts, engineers decide
Ask a senior engineer how much of their week goes on documentation and you will rarely get a small number. Root-cause reports, service bulletins, change impact assessments, failure analysis updates, test plans, compliance files, responses to customers and regulators. All of it necessary. Much of it repetitive. Most of it written by the people whose time is most valuable elsewhere.
The fourth level of AI value in an engineering company is about that work. At this level, AI no longer just finds and assembles information. It produces the first draft of the documents engineering has to produce, and an engineer reviews, corrects and approves it. The AI drafts. The engineer decides.
The principle is simple. Getting it right is not.
What AI can draft
The candidates are documents that are frequent, follow a recognisable structure, and are built from information the organisation already holds:
- root-cause and corrective action reports
- service bulletins and technical notices
- updates to failure mode analyses after a new failure is understood
- change impact assessments, listing what a design or supplier change affects
- test plans and test cases for a fix or a new variant
- technical documentation for compliance, including the evidence files regulators expect
- first drafts of vulnerability notifications, where regulation imposes tight deadlines
- technical responses to customers, distributors and tenders
What they have in common is that the hard part is gathering and organising the facts, and the valuable part is the engineer's judgement about what they mean. Level 4 takes on the first and leaves the second where it belongs.
Our fault at level 4
Following the example used throughout this series: a recurring fault in a connected product.
By level 3, the organisation can see which units are affected, what they share, and what the telemetry shows. At level 4, the AI turns that into work. It drafts the investigation report, laid out in the organisation's own format, with every statement linked to the record it came from. It lists the affected products from the structured model. It drafts a service bulletin for the field, a proposed test to confirm the fix, and an update to the failure analysis. If the fault is a security vulnerability, it drafts the regulatory notification, which under the EU Cyber Resilience Act now has to be made within twenty-four hours of a manufacturer becoming aware that a vulnerability is being actively exploited.
The engineer's job becomes reviewing, challenging and deciding, rather than typing.
Why levels 1 to 3 come first
A draft is only as good as what it is drafted from. An AI that writes a root-cause report from inconsistent records, unmatched identifiers and partial telemetry will write a fluent, well-formatted, wrong report. It will not look wrong. That is the danger.
This is why I describe the levels as a ladder. Level 1 makes the documents findable, level 2 makes the facts reliable and linked, and level 3 brings in live evidence. Level 4 turns all of that into work products. Organisations that jump straight here with messy data simply produce confident mistakes faster.
Designing for review
The success of level 4 depends less on how well the AI writes and more on how easily an engineer can check what it wrote.
Every claim should carry its source. A reviewer should be able to see, for each statement, which record or document it came from, and check it in a click.
Uncertainty should be visible. Where the AI inferred something rather than found it, or where sources disagree, the draft should say so rather than smoothing it over.
Use the organisation's own formats. Templates, standards and house style should be built in, so the engineer is reviewing content rather than reformatting.
Check across models. One technique I use routinely is to have a second, different model review a draft for errors and omissions. Different models fail in different ways, and a disagreement between them is a useful signal about where to look. It is not a substitute for the engineer's review, but it improves what reaches them.
Keep a record. For each document, record what was generated, from which sources, what the engineer changed, and who approved it. That record is valuable for audit, and the pattern of changes shows exactly where the AI needs improving.
The risks at this level
Rubber-stamping. The most serious risk is not that the AI writes badly. It is that it writes well enough that reviewers stop reading carefully. People are known to over-trust automated output, particularly under time pressure. Review has to be designed as real work, with the reviewer's name on the result and time allowed for it.
Accountability. A document signed by an engineer is that engineer's document, however it was drafted. The organisation should be clear that AI drafting does not dilute professional responsibility, and that anyone signing must be in a position to stand behind every line.
External communication. Drafts that go to customers, regulators or the public deserve a higher bar than internal documents. Nothing should leave the organisation because an AI produced it and nobody stopped it.
Measuring the wrong thing. The measure of success is not how many documents the AI produced. It is how much skilled time was freed and whether quality held or improved. Track how much reviewers change each draft. If they change a great deal, the drafts are not yet saving time. If they change nothing, check that they are reading.
How to start
Pick one document type that is frequent, disliked and well-structured. In many engineering companies that is the root-cause report or the service bulletin.
Gather a set of past examples as the standard. Build the drafting around the organisation's template, with sources attached to every statement. Run it alongside the existing process for a month, with engineers comparing the AI draft with what they would have written. Measure review time and edit rate. Then decide, with evidence, whether to adopt it and what to do next.
Four things worth taking seriously
For engineering leaders: add up the senior engineering time spent on documentation each month. That number is the size of the opportunity at level 4.
For quality and compliance teams: AI drafting can improve consistency and completeness, but only if review is taken seriously. Build the review and the audit trail in from the start.
For engineers: the skill that matters at this level is critical review. Treat every AI draft as a capable junior colleague's work: often good, occasionally wrong in ways that look right.
For anyone considering AI that acts on its own: start here, with drafts and a person's signature. Autonomy can be extended later, one well-understood task at a time, once the record shows it has been earned.
I would be interested to hear which document your engineers would most like never to write from scratch again.
Further reading in this series
- Beyond search: the five levels of AI value in an engineering company (the overview)
- From documents to data: building an engineering model you own (level 2: structure)
- From what the manual says to what the product is doing (level 3: connect)
- Closing the loop: letting field data change the product (level 5: learn)
- Guardrails: autonomy is earned (agents series)