AI Consulting: take a working pilot into daily use
We take an AI use case that works in a demonstration and make it work on an ordinary day: on live data, inside the process, approved by the people who answer for risk, and owned by someone who can switch it off.
In brief
AI Consulting moves an AI use case from a working pilot into the systems and routines a business runs on. We decide which use cases deserve to run, draw the route to production before building, build inside the tools people already use, and hand each one to a named owner who can run it, and stop it, without us.
On this page
Which of your pilots should still be running next year?
You may be the head of AI with a pilot that impressed the board and no date for going live. You may be the CIO who inherited pilots from other departments, each with a sponsor who believes theirs is the one to fund. Or you may be a product owner told to put AI into a workflow, with a vendor demonstration as the only starting point.
In each case someone has to decide which of these becomes part of how the business runs, and the pilot results do not settle it. We work with the person who carries that decision. Usually that is the sponsor, with the leader of the team that will use the output and the security or risk lead who answers for what goes live, in the same room from the first week. Where they have not met, introducing them is our first piece of work.
Why does a model that passed its test fail on an ordinary Monday?
A pilot is a sound way to learn whether a model can do a task. It is built to be quick, so it borrows. A hand-cleaned extract stands in for the live feed, volunteers for a whole department, a separate screen for the working process, and the label of a test for the security review. None of that is a fault. It becomes one when the result is read as proof that the business can run the thing.
On the first ordinary Monday in production the borrowed conditions are gone. Data arrives late and mistyped. The people who were glad to help are back in their own jobs. Whoever answers for privacy sees the design for the first time and asks questions it cannot answer without rework. The output sits in a view nobody opens.
So the work is not to improve the model. It is to replace each borrowed condition with a real one, and to decide who pays for it, before anyone builds.
The pilot proved the model can do the task. Nothing in it proved that anyone is answerable for the result.
That is the gap this work closes.
Which decisions do we settle before anything is built, and who takes them?
Each row is a decision that otherwise gets made by default, late, by whoever happens to be nearest. We put every one in writing with a name against it.
| Decision | Taken by | What exists once it is taken |
|---|---|---|
| Whether the use case goes ahead | The sponsor, on the written scoring | A scoring sheet with the reasons for every use case kept and every one dropped |
| Where the output enters the work | The head of the function that uses it | A one-page description of the step, the person at it, and what they do when they disagree with the output |
| What the model reads and writes | The technology lead with the data owner | A data-flow design naming each system, field and access route, and how each one fails |
| What risk and security need to see | The risk or security lead | Written conditions for going live, agreed against the design instead of the finished build |
| What happens when the model is wrong or unreachable | The owner, with the function head | A fallback procedure and the threshold at which it starts |
| When the old route stops | The sponsor | A stop date, and the person who enforces it |
| Who runs it after we leave | The sponsor names, the owner accepts | A run book, monitoring thresholds, an escalation path and a retirement rule |
How an engagement runs, in order
- 01
Triage
Pilots and ideas are scored on the decision they improve, the state of the data and who would own them.
- 02
Draw the route
Technology and risk agree the design with us before any build starts.
- 03
Build in the work
On live data, inside the tools people already use, with the process and roles changed alongside.
- 04
Run beside, then switch off
For a set period the system and the old route run together, the owner at the controls and us watching. Then the old route stops on the agreed date.
- 05
Hand over
The owner receives the run book. We stay for the first full cycle of real use.
A pattern we are called into
A reply assistant that worked for the volunteers
A retailer's customer service team pilots an assistant that drafts replies to customer emails. It runs on a hand-picked set of past messages and a group of agents who wanted to try it. Drafts are judged good, the closing review is warm, and the sponsor asks when it can go live.
- The route. We trace where a draft would appear. It sits in a separate window, while agents answer in the ticketing tool, so using a draft means copying it across. Order status answers depend on a field the warehouse system fills late.
- Risk at design. The privacy lead asks where customer details go and how long the vendor keeps them. The answers go into the design, where a change costs a conversation.
- The build. Drafts appear in the reply box. The head of service decides which categories agents must still write by hand, and the rule goes in the run book.
- Running beside. An owner in service operations reads a weekly sample of edited drafts.
- The switch. The separate window and the private folder of saved replies are retired on the agreed date.
Where it endsDrafting is part of how replies are written. An operations lead reads the sample each week and can pause the assistant, and the retailer can say which categories it never touches. Whether it saves time depends on the mix of enquiries, so the scope set the acceptance test before the build.
When is this the right help, and when is it not?
It fits when
- A pilot exists or a use case is chosen, and the open question is how it runs for real
- A sponsor can enforce a stop date on the old route
- Technology, risk and the using function will sit in one room
- You would rather retire a weak use case, reasons recorded, than keep it alive
Look elsewhere when
- You have no use case yet and need a direction first. AI Strategy comes before this
- The aim is a new AI product sold to customers, which is product development
- You want a vendor to operate the system for you indefinitely
- The pilot has no business owner and nobody will accept the role
This route costs attention. The sponsor decides things earlier than they would like, and the owner gives time to the design before there is anything to look at. What you get for it is a go-live that does not depend on goodwill.
What do we need from you, and where does our part end?
The sponsor decides the scoring and the stop date, and holds the date when someone asks for more time. The named owner gives regular time during design, because nobody else can write their run book. A technology lead opens access to the systems the use case touches. The risk or security lead agrees review conditions against a design instead of a finished build.
Model and platform contracts stay with you unless the scope says otherwise. We write acceptance criteria into the scope and do not promise financial returns or a level of model performance. After handover the owner runs the system; support from us can be added to the scope.
Can you test your own pilot before you speak to anyone?
Short assessments let you look at your position first, one for the organization and one for a single pilot. The playbook walks one use case from pilot to go-live, and the field note on handovers describes the rehearsal we use before a project team leaves.
What do buyers ask before they bring us a pilot?
Can you work with the AI platform we already bought?
Usually, yes. We review the platform when we score use cases and recommend a change only when it blocks the use case or your owner cannot run it. A platform limit often turns out to be an integration or data problem that a different platform would inherit.
We already have a pilot. Do we start over?
No. The scoring step decides whether the pilot moves to production, needs rework or retires, using the same written criteria as any new idea. A pilot that retires with its reasons recorded is a useful result, because the next proposal starts further ahead.
Who runs the system after you leave?
The owner you name during the work, supported by the ownership pack: run book, monitoring thresholds, escalation path and retirement rule. Support from us can be added to the scope, but the design assumes your owner can run it without us.
Do you build the models or advise on them?
Both, depending on the scope. Some use cases need a configured platform, some a custom model, and some neither. The scoring step decides on the evidence, and we write the choice and its reasons down so your team can revisit it.
How do you decide that a use case should be dropped?
We drop a use case when the decision it improves is small, the data it needs cannot be made reliable in reasonable time, or nobody will accept ownership. The reasons go on the scoring sheet, so the idea can come back if one of those facts changes.
Related
Have a pilot that should already be in production?
Describe what you are weighing in a few lines. A senior practitioner replies with a suggested first conversation.