Two of us will be on stand 25 both days, and neither of us works in sales. We're the people who'd do the assessment and run the build. Give us twenty minutes on the stand, or catch us at the Monday evening reception, and you'll leave with a first answer you can take back to the plant.
Venkat and Prasobh — on the stand both days
Before anyone writes code, we work out what an AI use case really costs: the build, the running, the people still checking its output, the governance around it. Then we set that against what it saves. Six of eight don't survive. The ones that do, we build with AI running through our own lifecycle, and keep governed from intake to retirement.
Cost, governance overhead and payback for each opportunity. A risk tier caps how much runs unattended. Go or no-go, number attached.
AI in the spec, the code, the tests and the deploy. Eval gates before anything goes live. About half the hands-on effort.
Real volumes, real accuracy, real review hours. That result funds the next build, or stops it.
Most AI ideas don't survive their own business case.
Licences, hosting, support, the people keeping it alive. We map every app in the estate and put a number on each one, then move them in governed waves: lift what can be lifted, rebuild only what must, retire the rest. The saving shows up in year two and keeps stacking after that.
24 apps: 14 lifted, 7 rebuilt, 3 retired. The cost of the move itself is in the number.
Every AI vendor can tell you what they'd build. The more useful thing is being told what not to build, and then having someone move the line so more of your ideas make it over.
Assay, our proprietary tool for the Decide phase, works out what a use case really costs (build, running, review, governance) and sets it against what it saves. Six times out of eight the answer is don't build it.
AI runs through our own build process, so a project takes about half the hands-on effort. Halve the cost of building and the borderline ideas suddenly clear the bar.
Governance goes in as a line in the business case, not as an afterthought. That's what keeps the number in beat one honest.
Accountable is the number. Accelerated is what moves it. Governed is why you can trust it.
Three stages. The interesting part is that it goes round again: what a system actually does once it's live decides whether the next one gets funded, or stopped.
Most AI ideas don't survive their own business case
Most AI ideas don't survive their own business case.
Pick a process shape. The bars show roughly where the cost lands and whether the governance-and-review line eats the saving. The chart underneath shows how the net position builds up, year by year. The numbers are illustrative. The shape of the answer is not.
Takes one process apart and works out what automating it would really cost over a realistic period: the build, the running, the people still checking output, the governance and evidence a live system needs. Then it sets that against what it saves.
A risk level for each step, which caps how much of the process may run without a person. That constraint changes the cost, and the cost changes the answer. It's the reason the number can be trusted.
A number and a decision. Go, with the business case attached. Or don't, with the reason. Six times out of eight it's the second one, and that is the most useful thing we'll ever tell you.
What moves the governance line: the risk tier of each step, and how much of it may run without a person. A safety-relevant decision keeps a human on every output. That is the cost most cases forget to count.
Not the build. Not the licences. The evidence, the monitoring and the human checks that have to sit around a live system. Most business cases leave that line out, and it's usually the one that turns a confident yes into a no. We put it in. That's what makes a yes from us worth having.
Requirements, design, development, testing, code review, DevSecOps. AI does the heavy lifting at every stage and a named engineer signs off each one. We don't sell the speed on its own. It matters because it halves the build line in the Assay case, and that is what lets the borderline ideas above clear the bar.
Autocomplete is one stage out of six. The real lift is in the requirements nobody wants to write, the tests nobody wants to maintain, the review queue, and the pipeline work underneath all of it.
The AI proposes, a named engineer approves. Merges, releases and infrastructure changes never pass on their own. A plant system is the wrong place to find out what happens if they did.
SBOM and provenance attached, deployed through your own CI/CD into your own environment. The evidence falls out of shipping. Nobody has to run a separate project to produce it.
This is the lever in Decide. Halve the build cost and the borderline case in the assessment above clears the bar. The AI SDLC in full →
Real volumes, real accuracy, real review hours. Once the system is live we run the Assay model again, this time on what it actually did, and put the result in front of the sponsor. That result funds the next build or stops it.
What this means today: at agreed points after go-live we re-run the assessment on your numbers and report what we find. An always-on, automated version of the same check is on our roadmap. We don't sell it as if it were live.
Not the volume in the business case. The number of drawings, requests or reports the system actually handled, and what happened to the ones it couldn't.
Sampled and checked by a person against the launch baseline, so a quiet drift shows up as a number on a report before it shows up as a complaint from the line.
The hours someone still spends checking output. It decided the case in Decide, so it's the line we watch hardest in Run.
A planning application, a drawing pipeline, an assistant over plant data: the trust layer is the same for all of them. Ordinary controls were never written for a model that drifts, an output nobody re-checks, or a prompt turned against you. So every AI system we build runs a nine-phase lifecycle with eight documented go/no-go gates, structured on the NIST AI RMF functions and mapped to the EU AI Act and ISO/IEC 42001. Governance here is a design constraint, not a countdown.
Classify the system against the EU AI Act and NIST AI RMF, name what it touches on the line and who owns it, inventory the data with recorded provenance, then set the risk tier that decides how hard the rest of the lifecycle has to work — and how much may run without a person.
Verbatim from the certificate scope “Information Security Management System covering Software Development Services encompassing AI, Data & Analytics, Cloud & DevOps and Digital Engineering including supporting functions such as Finance, IT, Administration and Human Resources.”
Verify the certificate on Certipedia ↗ Opens TÜV Rheinland's register in a new tab · no login, no gateFive engagements, described rather than named. Each has its own case study.
For a Fortune 500 Tier 1 automotive safety supplier, the applications and data its European and global plants run on day to day:
For a European engineering and inspection enterprise: sensor thresholds tracked against equipment wear, so the limit a plant runs to reflects the state the equipment is actually in.
For a global automotive components group: master data management across plants and product lines, and the engineering drawings that used to be keyed in by hand now digitized, structured and searchable.
For a Fortune 50 automotive OEM: a connected-car-to-smart-home bridge. The vehicle's position against a home boundary drives presets for lights, HVAC and the garage door, through a home control unit and a cloud layer, either automatically or once the owner confirms. Two phones per home, presence resolved between them, and a manual override that always wins.
For a global industrial automation maker's customers: register machines by model and serial, raise service, spare-part and repair requests against the installed base, confirm out-of-warranty charges by OTP, and track every request through to closure. An admin panel runs the back office.
Applications and data first, AI where the number says so. Every AI idea that sits on top of this work goes through Assay before anyone builds it.
You don't need an AI idea. You need the thing that costs you money every day. These are the shapes we see most often on a plant's list.
Specifications sitting in scanned files that somebody keys into a system by hand, every day.
Usually a goThe one that has sat on a list for three years because nobody could justify the fix, or prove it wasn't worth doing.
Often the surpriseWhere the delay is finding out what a change touches, not making it.
Usually borderlineWhere the real question is what actually has to be rebuilt and what can just be lifted.
Starts with a mapSomething else? Fine. Name it and we'll tell you straight whether it's worth automating, including when it isn't. Name one process →
Tell us the one thing in your operation everyone agrees is broken and nobody has fixed. We come back with a straight view on whether automating it is worth the money, including when it isn't. That's the first question Assay asks, and the answer is the best signal either of us will get out of a first call.
Book a 30-minute discovery call with one of the founders. Bring the process, we'll bring the questions. No sales team, just the people who'd do the assessment and run the build.
Book a 30-minute discovery call → 30 minutes · no deck · a working conversationFour fields. One line about the process is enough. We'll come back within two working days with a first view and a question or two.
One of us will come back to you within two working days with a first view, and a question or two if we need them.