Start AI adoption with one bounded workflow, a real baseline, clear human approval and evidence to support a stop, improve or expand decision.
Measure one bounded workflow before scaling.
Use AI to prepare, retrieve, compare and structure. Keep a named competent person responsible for facts, assumptions, decisions and commitments.
“AI transformation” sounds decisive. It can also hide a weak starting point. A business may buy several tools, appoint champions and run training before it has shown that one real workflow can be improved safely, measurably and sustainably.
For an engineering or technical business, a better first move is smaller: choose one frequent, understood workflow and prove whether an AI-assisted first pass creates useful capacity without weakening quality, traceability or accountability.
This is not a lack of ambition. It is how the organisation learns what the technology, data, controls and users actually require before multiplying uncertainty across departments.
Start with work, not with an AI feature
A promising pilot begins with a visible operational problem. Perhaps experienced engineers repeatedly search several folders for approved data. A sales engineer rebuilds the same enquiry brief from emails and attachments. A project manager spends an hour comparing document revisions and extracting actions.
Describe the current method before proposing the new one:
- What triggers the work?
- Who performs and approves it?
- Which inputs and systems are used?
- Where do delays, repetition and errors occur?
- What does an acceptable output contain?
- What happens when information is missing?
- Which decisions must remain human?
NIST’s AI Risk Management Framework starts its Map function with context, intended purpose, users, assumptions and limitations. It also provides for an initial decision about whether an AI solution is appropriate at all.[1] That order matters. Technology availability is not evidence of business need.
Choose a bounded first workflow
A strong first candidate is frequent enough to measure, narrow enough to control and useful enough for staff or customers to notice. Its inputs and acceptable outputs should be understandable to people who already perform the task.
Examples include:
- retrieving relevant passages from an approved internal document set;
- assembling a first-pass technical enquiry brief;
- comparing two revisions and listing apparent changes;
- structuring meeting actions for human confirmation;
- preparing a report outline and evidence checklist;
- checking an RFQ pack for specified missing information.
Avoid a first pilot that makes autonomous safety decisions, commits prices, sends unapproved customer advice, processes poorly understood sensitive data or spans many inconsistent systems. High consequence, ambiguity and weak verification are reasons to narrow the scope, add controls or choose a different task.
Draw the human line before building
Write down what the AI may do and what it may not do.
For a technical enquiry brief, the assistant might extract customer requirements, list attachments, flag missing units and draft questions. A named engineer still checks the source material, resolves ambiguity and approves the brief. Commercial staff approve price and delivery. Legal or data protection specialists decide their own matters. No generated text becomes an engineering, commercial, legal, privacy, safety or customer commitment merely because it appears in the workflow.
The UK Government’s introduction to AI assurance calls for clear accountability across the AI life cycle, named responsibility, escalation routes and quality assurance throughout that life cycle.[2] These are operating requirements, not additions to bolt on after a successful demonstration.
Establish a baseline before claiming improvement
Measure the current workflow on representative cases. Depending on the task, record:
- elapsed time and active expert time;
- number and severity of corrections;
- missing or wrongly transferred information;
- time spent finding source material;
- turnaround experienced by the next person or customer;
- rework caused downstream;
- current privacy, access or security incidents.
Then define acceptance criteria for the pilot. “Produces a good summary” is too vague. A better criterion might require every extracted requirement to link to its source location, all mandatory fields to be present or explicitly marked missing, and no external message to be sent without approval.
NIST says AI systems should be tested before deployment and regularly in operation. Its Measure function calls for documented test sets and metrics, comparisons with benchmarks, assessment in conditions similar to deployment and input from domain experts.[1] The baseline turns enthusiasm into a comparison that can be challenged.
Test normal, edge and failure cases
A pilot should not be a staged demonstration built from the cleanest example. Use real patterns with controlled data, including difficult cases:
- a complete, well-structured input;
- missing attachments or fields;
- conflicting values across documents;
- an obsolete or superseded source;
- unusual units, tables or scanned material;
- content outside the agreed knowledge boundary;
- sensitive information the user should not access;
- an outage or model response that cannot be verified.
Record the output, corrections, user effort and failure behaviour. Confirm that the assistant abstains or escalates when it should. Test the whole workflow, including permissions, interfaces, review and handover, not only the quality of a model’s prose.
Include privacy and legal checks at the right time
A narrow pilot is not exempt from data protection. It makes the information flows easier to inspect.
The ICO says deployment involving personal data should be driven by evidence of a problem and a reasoned case that AI is a sensible solution, rather than by technology availability. Its guidance also calls for early assessment, meaningful human involvement, auditable documentation and ongoing review. The page currently notes that the guidance is under review following the Data (Use and Access) Act, so current legal advice and updated ICO material must be checked for a live project.[3]
That limitation is important. A pilot report can record what was tested and observed. It cannot declare universal legal compliance or suitability outside its scope.
Decide: stop, improve or expand
The result of a pilot is a decision, not an obligation to scale.
Stop if the workflow does not create useful value, the data cannot be controlled, verification consumes the saved time or the residual risk is unacceptable.
Improve if the mechanism is useful but retrieval, permissions, instructions, user interface or acceptance checks need work.
Expand only when the workflow meets its criteria, users can operate it, ownership and support are clear, and the next use case has been assessed on its own merits.
Expansion should preserve rollback, monitoring and change control. Models, source documents, user behaviour and connected systems change. A result measured on one version and one task does not prove every future configuration.
What one workflow teaches you
A controlled pilot reveals more than whether a model can produce an answer. It shows:
- where the source data really lives;
- which exceptions experienced staff handle silently;
- how much review is genuinely needed;
- whether saved time is released or moved elsewhere;
- what access, logging and support cost;
- where users trust the tool too much or too little;
- which evidence is needed before the next investment.
Those findings form a better transformation plan than a generic list of AI opportunities. They replace assumed scale with an observed operating pattern.
Create capacity without giving up control
Ekyos helps engineering and technical businesses map one repetitive workflow, define the human boundary, build the smallest useful AI-assisted system and test it against the current method. The output is a documented stop, improve or expand decision, not a promised percentage saving.
A suitable first conversation is about one task your experienced people repeat each week. Any pilot or wider implementation remains subject to project-specific competence, data protection, security, insurance, legal, commercial, safety, support and customer approval requirements.
Discuss one repetitive technical workflow
Ekyos can help map the current work, define the human approval boundary and test one bounded workflow against an agreed baseline. No autonomous engineering approval, pricing or customer commitment is implied.
