Almost every product team is being asked the same question right now: when are we adding AI? It is a reasonable question, but it usually skips a more important one. Adding AI to a product that works well is straightforward. Adding AI to a product that is not ready for it produces a demo that impresses in a meeting and falls apart in front of real users. AI-readiness is mostly about engineering and data — not about the model. Here is a practical check of whether your product is actually ready.
The short version: choosing a model is the easy part, and it is the part everyone focuses on. The hard part is everything around the model — whether your data is reachable and trustworthy, whether your architecture can hold a new service, whether you can see and measure what the AI does in production. Five things have to be true. They are all things you control, and none of them require AI to fix.
The honest framing: readiness is mostly not about AI
It is worth being blunt about this, because it changes where you spend your effort. When an AI feature works well in production, the model is rarely the reason — and when one fails, the model is rarely the reason either. The reasons are upstream: the AI could not reach the right data, or the data it reached was wrong; the architecture made the integration fragile; nobody could see what the feature was doing once users arrived; nobody had a way to tell whether its answers were any good. Every one of those is an ordinary engineering and data problem. The five checks below are really a readiness audit of your product as software — and a product that passes them is one where adding AI becomes calm, ordinary engineering rather than a gamble.
1. Your data is accessible and clean
AI features run on your data. A support assistant needs your help content and ticket history; a recommendation feature needs clean product and behaviour data; anything that answers questions about your business needs to reach the records that hold the answers. So the first question is brutally practical: can a new service actually get to that data, and is the data worth reaching?
Two failure modes show up here. The first is access — the data exists but is locked inside a system with no clean way in, scattered across exports, or trapped in formats nothing can query. The second is quality — the data is reachable but inconsistent, stale, full of duplicates and gaps. AI does not fix bad data; it repeats it back to users with total confidence, which is worse. If your data is hard to reach or not trustworthy, that is the first thing to fix, and it is a data-engineering job, not an AI job.
2. Your architecture can hold a new service
An AI feature is, in engineering terms, a new service: it takes input, calls a model, often retrieves data, and returns a result. The question is whether your current architecture can accept that new service cleanly — or whether bolting it on means rewiring half the product.
A product with reasonably clear boundaries can add an AI service as exactly that: a new service alongside the others, with a defined interface. A tightly tangled product, where everything depends on everything, has no clean place to attach one — so the AI logic gets jammed into an existing module, makes the tangle worse, and becomes almost impossible to test or change. You do not need a perfect architecture. You need somewhere clean to attach a new piece. If you do not have that, some focused modernisation of the relevant area comes before the AI work.
3. You can observe what happens in production
AI features behave differently from ordinary code. They are not strictly deterministic, their inputs are open-ended, and they meet situations in production that no one anticipated. That makes visibility non-negotiable. You need to be able to see what the feature is actually doing once real users reach it: what they asked, what the AI did, how long it took, what it cost, where it struggled.
A team that already has solid observability over its product can extend it to cover an AI feature. A team flying blind on its existing system will be doubly blind on the AI one — and a blind AI feature is one where you only learn it is failing when a customer complains. If you cannot currently see how your product behaves in production, building that visibility is a prerequisite, not a nice-to-have.
4. You have a way to measure quality — evals
This is the one most teams have never had to think about, and it is the one that separates a real AI feature from a demo. With ordinary code, a test passes or fails. With an AI feature, the output is language, and “is this answer good?” is a real, ongoing measurement question. The tool for it is an eval: a set of representative inputs with a defined notion of a good answer, run automatically, so you get a quality score you can track.
Evals are what let you change a prompt, swap a model, or adjust retrieval and actually know whether quality went up or down instead of guessing. Without them you are shipping changes to an AI feature blind. You do not need evals before you start, but you do need to accept that building them is part of building the feature — and a team comfortable with automated testing already has the instincts for it.
5. You have a real use case — and users ready for it
The last check is the least technical and the most often skipped. AI should be added to solve a genuine problem — a real source of friction, cost, or delay for your users — not to be able to say the product has AI. The strongest AI features come from a clear, specific problem: this task is slow, this question is asked constantly, this work is repetitive. The weakest come from “we should add AI somewhere.” If you cannot name the specific problem and the specific users it helps, the honest move is to find that first.
Why the demo-to-production gap is so wide
It is worth understanding why an AI feature can look excellent in a demo and still fall apart with real users, because the gap is exactly what the five checks are designed to close. A demo is run on inputs the builder chose, against data the builder prepared, in front of an audience who wants it to work. Production is none of those things. Real users ask questions in ways nobody anticipated, on data that is messier than the demo set, and they notice every wrong answer. The model is the same in both settings — so the model is not what changed.
What changed is everything around it. In the demo, the data was hand-picked and clean; in production, the AI has to reach whatever the live system actually holds. In the demo, nobody measured quality beyond “that looked right”; in production, quality is a number that moves and has to be tracked. In the demo, there was no need to see what happened after the answer; in production, you need to know what users asked, what the AI did, and where it struggled. A team that has done the five readiness checks has closed each of those gaps before launch. A team that has only chosen a good model has closed none of them, and will meet all of them at once, live, in front of customers. That is the demo-to-production gap, and it is an engineering and data gap, not a model gap.
A quick self-assessment
Run your product against the five honestly. Can a new service reach the data an AI feature would need, and is that data trustworthy? Is there a clean place in the architecture to attach a new service? Can you see how your product behaves in production today? Does your team have the testing discipline that evals depend on? And can you name the specific, real problem AI would solve? Five clear yeses means you are ready, and adding AI is ordinary engineering. A mix of yeses and noes is the more common — and more useful — result, because it tells you exactly what to do next.
What to do if you are not ready yet
Being not-yet-ready is not a problem; it is a plan. Every gap on the list is a normal, well-understood piece of work. Data that is hard to reach gets a clean access layer. Inconsistent data gets a quality pass. A tangled architecture gets the relevant area modernised so a service can attach. Missing observability gets built. A team without testing discipline builds it. That work is modernisation — and it is worth doing for its own sake, because every one of those improvements makes the product faster, safer, and cheaper to change, AI or no AI. The honest sequence for most teams is: modernise the foundation, which makes the product better today, and arrive at AI-readiness as a result. When the five are true, the AI work itself becomes the calm part. If you want help getting there — or building the AI feature once you are ready — that is exactly what our modernisation and AI engineering teams do.
Common questions
What does “AI-ready” actually mean?
AI-ready means the engineering and data foundation around a product can support an AI feature that holds up in front of real users — not just in a demo. Concretely, five things are true: a new service can reach the data it needs and that data is trustworthy; the architecture has a clean place to attach a new service; you can observe what happens in production; you have a way to measure answer quality with evals; and there is a real problem the AI genuinely solves. Notice that choosing a model is not on the list. AI-readiness is mostly ordinary engineering and data readiness.
Do we need to modernise before adding AI?
Often yes, at least in part — and that is usually good news, not bad. The things that make a product AI-ready (reachable clean data, an architecture you can attach a service to, production observability, testing discipline) are the same things that make any product faster, safer, and cheaper to change. So modernising the foundation is worth doing on its own merits, and AI-readiness arrives as a result. If your product already has those foundations, you can move straight to the AI work. If it does not, the honest sequence is to modernise the relevant areas first, then build the AI feature on solid ground.
Is our data good enough for AI?
It depends on two things: whether a new service can actually reach the data, and whether the data is trustworthy once reached. Data that is locked inside a system with no clean way in, or scattered across exports and incompatible formats, fails the access test. Data that is reachable but inconsistent, stale, duplicated, or full of gaps fails the quality test. AI does not fix bad data — it repeats it back to users confidently, which is worse than a blank. If either test fails, fixing the data is the first piece of work, and it is data engineering rather than AI.
Can we add AI to a legacy system?
Yes, but usually not by bolting it directly into the tangled part. An AI feature is a new service, and it needs a clean place to attach. With a legacy system, the practical path is to modernise the specific area the AI feature touches — give it reachable data and a clean interface — and then add the AI service against that modernised slice. You do not have to modernise the whole system first. You do have to make sure the AI feature is not jammed into the worst part of the codebase, where it cannot be tested, observed, or changed.
How long does it take to become AI-ready?
It depends entirely on which of the five checks you already pass. A product with clean reachable data, sensible architecture boundaries, and good observability is essentially ready now — the AI feature itself is the main work. A product missing several foundations needs those built first, and that is incremental modernisation work whose timeline depends on the system’s size and condition. The useful way to answer the question is to run the five-point self-assessment: it converts a vague “how long” into a concrete, ordered list of the specific gaps to close.
Wondering whether your product is ready for AI?
Tell us about the product and the AI feature you have in mind. We will give you an honest readiness read — what is in place, what is missing, and the order to fix it.