A client sent us a video last year of an AI assistant answering customer enquiries about stock availability. It was genuinely impressive. Someone typed a question in Malay, the assistant read it, checked a product list, and replied with the right item and the right price in about two seconds. The whole room had seen it. Everyone agreed it should go live.
Eight months later it was still not live.
Nothing had gone wrong in any dramatic way. The model had not degraded and nobody had cancelled the project. It simply sat between a working demonstration and a working system, and no one was responsible for the distance between those two things.
We now see this often enough that we treat it as the default outcome rather than the exception. The part of AI implementation that everybody plans for is choosing the tool and proving it can work. The part that decides whether anything ships is the unglamorous stretch afterwards: connecting the model to systems that were never designed for it, making it behave on messy real data, keeping the running cost sane, and deciding who is answerable when it gets something wrong.
This article is about that stretch, what we see break in it, and what it realistically costs to get across.
What AI genuinely does well before deployment
It is worth crediting the technology, because the demo is not a trick.
Modern language models are very good at the tasks a demo is built from. They read an unstructured message and work out what is being asked, pull the relevant fact out of a long document, and classify, summarise and rewrite with a consistency that a tired person cannot match at four in the afternoon. Given a clean input and a clear instruction, the output is often better than the manual version.
That capability is real, and it is why the first prototype takes days rather than months. We build prototypes this way ourselves.
The trouble is that a demo is a controlled environment, with one clean question, one tidy product list and one person watching. Production is none of those things, and almost everything that stalls an AI implementation in Malaysia lives in the difference.
Gap one: the demo ran on data that does not exist in your business
The product list in that stock enquiry demo was a clean spreadsheet someone had exported and tidied for the occasion. The live data was not like that.
The live data had the same item listed three times under slightly different names, because three staff had created it on three different days. It had prices that were correct in the system and wrong in practice, because the real price depended on which customer was asking. It had a stock figure that only meant something if you also knew what was sitting unrecorded in the back of the shop.
When we connected the assistant to that, it did exactly what it had been asked to do and gave confident, wrong answers, consistently, and in a tone that made staff trust it for the first week.
This is the most common reason an AI chatbot in Malaysia never leaves the pilot stage. The model is fine. The data underneath it was never in a state any system could have used, and nobody discovered that until the model started reading it out loud to customers.
Gap two: nobody owned the wiring between the model and your systems
The second gap is organisational rather than technical, which is why it survives so long.
The person who built the demo was usually a marketing lead, a technically curious operations manager, or an external consultant on a short engagement. They could call an API. They could not reasonably be expected to integrate that call into an inventory system, an accounting package and a WhatsApp number, handle what happens when one of those is down, and keep it running after they moved on. So the demo stopped at the edge of the existing stack and stayed there.
Globally this has produced an entire job title, the forward deployed engineer, whose whole purpose is closing that distance: an engineer who sits close to the customer’s real systems and takes frontier capability all the way into production. The title matters less than the observation behind it, which is that this work is a genuine engineering discipline rather than an afterthought somebody absorbs on top of another role. Most Malaysian SMEs do not need to hire such a person full time, but they do need someone to be doing that job.
Gap three: prompting was treated as the whole job
Prompt writing is the visible part of working with AI, so it gets mistaken for the entirety of it.
In practice a prompt is one component among several, and usually not the one that decides whether the system is reliable. The decisions that matter are quieter: which information gets put in front of the model for this particular question and where it is retrieved from, whether the answer should be generated at all or looked up from a source of truth, what the system does when it is not confident, and what it is forbidden to say without a human checking first.
A useful comparison here is retrieval versus fine-tuning, because clients are often told they need the second when they need the first. Retrieval, feeding the model the right record at the moment it answers, is what you want when the information changes often: prices, stock, policies, customer history. Fine-tuning, adjusting the model itself, is for when the style or format of the output must be consistent and the underlying facts rarely move. Most SME use cases we see are retrieval problems that were quoted as fine-tuning projects, and getting that choice wrong means paying a great deal to make a model memorise a price list that changed the following month.
Gap four: cost and speed were never tested at real volume
A demo answers one question at a time while someone watches. Production answers hundreds while nobody does.
Two things surface at that point. The first is latency. A two second response in a demo becomes eight seconds when the system has to check three sources first, and eight seconds is long enough for a customer on WhatsApp to give up and phone a competitor. The second is cost. Per query the figures look trivial, which is why nobody models them, but multiply a trivial figure by a busy December and it stops being trivial.
We have had to redesign systems after launch for both reasons, which is considerably more expensive than designing for volume in the first place. The fix is rarely exotic: cache what does not change, answer the simple questions with a lookup rather than a model call, and reserve the expensive path for the queries that actually need it. None of that is visible in a demo, because a demo has no volume.
Gap five: no one was accountable for accuracy after launch
The last gap is the one that quietly kills projects that cleared the first four.
An AI feature is not finished at launch in the way a booking form is finished at launch, because its behaviour drifts as the business changes around it. New products appear, a policy changes, a supplier is dropped, and the system keeps answering with confidence from the world as it was. Unless someone is reading a sample of real conversations every week, nobody finds out until a customer complains.
So the question we now ask before any build starts is a boring one. Who reads the output, how often, and what happens when they find something wrong? If there is no answer, we would rather narrow the scope until there is, because an unmonitored AI system does not fail loudly. It fails politely, at scale, for months.
What good AI implementation actually looks like
The process we use is deliberately slow at the start and fast afterwards.
- Pick one decision, not one department. Not “AI for customer service”. Something like “answer stock and price enquiries that arrive on WhatsApp outside office hours”. A scope you can describe in a sentence is a scope you can verify.
- Look at the data before anything else. Export what the system would actually read and go through it. Duplicate records, stale prices and unrecorded stock are found here, cheaply, or in production, expensively.
- Build the prototype, then immediately try to break it. Feed it the ugliest real messages you have, the ones with three questions in one sentence and two languages. The prototype exists to find the failure modes, not to impress anybody.
- Decide the architecture on evidence. Retrieval or generation, lookup or model call, what is cached, what a low confidence answer triggers. This is where the reliability is won.
- Connect it properly. Real integration with the systems you run, with defined behaviour when one of them is unavailable, so the answer is one honest apology rather than a confident invention.
- Set the accuracy routine before launch. Name the person, the sample size and the weekly slot. Fifteen minutes a week is usually enough and is the difference between a system that improves and one that rots.
- Launch narrow and widen on evidence. One channel, one category, one shift. Widen when the sample reads clean.
If you have a working demo sitting in a folder and no clear route to production, talk to us about what it would take before you commission anything larger.
What this means for Malaysian SMEs
Some realistic expectations from what we see in this market.
A scoping and data readiness review for a single AI use case, the step that tells you whether your data can support it at all, typically takes one to two weeks and lands between RM3,000 and RM8,000. You keep the findings whether or not you proceed.
A production AI build for one well scoped use case, integrated with the systems you already run and with a monitoring routine in place, usually runs RM15,000 to RM45,000. The range is driven almost entirely by how many systems have to be connected and how clean the data is, not by which model you use.
Running costs split in two. Model usage for a typical SME volume sits in the low hundreds of ringgit a month and is not usually the number that matters. Tooling and hosting around it sits between RM200 and RM1,500 per month, in line with most automation stacks we see.
Timelines: expect four to eight weeks from a signed scope to a narrow live launch, and treat anything promising two weeks for a fully integrated system with suspicion.
The quote to be careful of is the one that prices the model and the prompt work and contains nothing for integration, testing at volume or post launch monitoring. That is a quote for a demo. You already have a demo.
For businesses that want to see what a deployed workflow looks like before committing to a build, our AI solutions catalogue lists the workflows we have already productised.
Frequently asked questions
Why do most AI projects fail to reach production?
Because the work that gets them there was never assigned to anyone. The prototype proves the model can do the task, but integration with live systems, handling messy real data, controlling cost at volume and monitoring accuracy afterwards are separate engineering jobs. When nobody owns them, the project stalls at the demo rather than failing outright.
What is a forward deployed engineer?
It is an engineer who works close to a customer’s real systems and takes AI capability from prototype all the way into production, covering integration, data handling, performance and reliability. The role became common at AI companies because deployment turned out to need dedicated engineering rather than being a final step somebody squeezed in.
How much does AI implementation cost in Malaysia?
A scoping and data readiness review for one use case typically runs RM3,000 to RM8,000. A production build integrated with your existing systems usually falls between RM15,000 and RM45,000, depending mostly on the number of integrations and the state of your data. Ongoing tooling and hosting sits between RM200 and RM1,500 per month.
How long does AI implementation take?
Four to eight weeks from an agreed scope to a narrow live launch is realistic for a single well defined use case. A convincing prototype can be ready in days, which is precisely why timelines get underestimated. The weeks go into integration, testing against real data and setting up monitoring.
Do I need to clean my data before implementing AI?
Usually yes, at least for the specific records the system will read. You rarely need to clean everything. Duplicate product records, prices that do not reflect what customers are actually charged and stock figures that are wrong in the system are the three we find most often, and each one produces confident wrong answers rather than visible errors.
Should I use RAG or fine-tuning?
Retrieval, commonly called RAG, is right when the information changes often, which covers prices, stock, policies and customer records. Fine-tuning is for when the style or format of the output must be consistent and the underlying facts are stable. Most small business use cases are retrieval problems, and fine-tuning is frequently quoted where it is not needed.
Should I hire an AI developer in Malaysia or work with an agency?
It depends on how much work there is after the first system. Hiring makes sense when AI is central to your product and there will be continuous development. For a business implementing two or three internal use cases, an agency engagement with a defined handover and a monitoring routine is usually cheaper and gets to production faster, because the deployment experience is already there.
How is Flow Digital different from an AI tool vendor?
A vendor sells you capability and leaves the integration to you. We start by checking whether your data can support the use case at all, and we will tell you when the honest answer is a rule and a lookup rather than a model. We treat integration, volume testing and post launch accuracy as part of the build, because those are the parts that decide whether it stays live.
Get the system live, not just the demo
Flow Digital builds and deploys AI systems for Malaysian SMEs. We use AI in everything we deliver, which is why we are specific about what it takes to move one from a demonstration into daily use.
If the gaps above sound familiar, these are the pieces we handle:
- Data readiness review: going through the records the system would actually read, and reporting honestly on whether the use case is viable yet
- Integration with your existing systems: connecting the model to inventory, accounting, e-commerce and WhatsApp, with defined behaviour when something is unavailable
- Architecture decisions on evidence: retrieval or fine-tuning, model call or lookup, what gets cached, what a low confidence answer triggers
- Volume and cost testing before launch: proving the response time and the monthly bill hold up at your real traffic, not at demo traffic
- Post launch accuracy monitoring: a named owner, a weekly sample and a route for fixing what the sample finds
Find out more at flowdigital.my, or message us and we will look at your demo and tell you what stands between it and production.
Get in touch<br>WhatsApp: +6010 886 1055<br>Email: [email protected]<br>Start a WhatsApp conversation →
