A Singapore fintech company spends six months and significant budget building an AI model to predict customer churn. The data scientists are experienced. The model architecture is sound. The compute infrastructure is ready. The model goes live — and the predictions are unreliable. Not dramatically wrong, just inconsistent enough that the business cannot act on them with any confidence. Six months of work produces a dashboard that no one trusts.
The postmortem reveals the actual problem. Customer data across three systems was never fully reconciled. Event timestamps were recorded in different time zones across different platforms. A field that should have captured subscription tier was populated inconsistently — sometimes with a product code, sometimes with a label, sometimes left blank. The model was trained on this data and learned its patterns faithfully. The predictions were inconsistent because the data was inconsistent.
This story plays out repeatedly across Singapore’s business landscape as companies accelerate AI adoption. The problem is almost never the AI. It is the data that feeds it. This piece covers what a data foundation actually means, the specific failures that sink AI projects, and what fixing the foundation first — rather than the model — looks like in practice. It draws on the experience of Engine Analytics, a data and AI consultancy in Singapore that builds the data infrastructure AI projects depend on.
Most conversations about AI focus on the model layer — the algorithms, the compute, the training runs. The data foundation sits a level below all of this, and it is what determines whether the model layer can produce anything useful.
A data foundation for AI has four components. Data completeness: the model needs to see enough examples of what it is trying to predict or classify. Data accuracy: the labels and features in the training data need to reflect reality, not how reality was imperfectly recorded. Data consistency: the same concept needs to be represented the same way across all records and all time periods, not differently in each source system. And data recency: AI models making operational decisions need to train on data that reflects how the business operates today, not a snapshot from eighteen months ago before a key system migration.
When any of these four components is missing, the model learns to be wrong — not randomly wrong, but systematically wrong in ways that mirror the gaps in the underlying data. A churn model trained on incomplete customer interaction data will consistently underestimate churn for customers who interact through the channels that were not captured. A demand forecasting model trained on inconsistent SKU coding will produce forecasts that look reasonable in aggregate but are useless at the product level where decisions actually get made.
Siloed data that was never designed to be joined is the most fundamental. AI models need cross-functional views: customer records alongside transaction history alongside product data alongside support interactions. When these live in separate systems with different schemas, different identifiers, and different update schedules, producing a joined training dataset requires reconciliation work that is rarely scoped into an AI project at the outset — and when it is done hastily, the joins introduce errors that the model absorbs as signal.
Inconsistent historical data is a problem that surfaces specifically when training models that need to learn from the past. If the definition of a “converted customer” changed eighteen months ago, or product categories were restructured, or a new data source was added without historical records before a certain date — the training dataset has structural breaks that the model will learn from and replicate in its predictions. The model is not malfunctioning. It is accurately reflecting an incoherent history.
Missing ground truth stops AI projects before they produce anything. Supervised learning models — which cover the majority of practical business AI use cases — need labelled examples of the outcome they are trying to predict. If the business has never systematically recorded which leads converted, which support resolutions were satisfactory, or which recommendations led to a purchase, there is no ground truth to train on. Attempting to build supervised models without it produces systems that are solving a different problem than the one the business actually has.
Poor data governance means AI systems that work at launch become unreliable as the underlying data changes. If the pipeline feeding the model is not monitored for schema changes, volume drops, or field-level quality degradation, the model silently drifts as the data it was trained on diverges from the data it is now receiving. This is one of the hardest failure modes to detect — the model continues to produce outputs, those outputs just gradually become less accurate.
The natural response to a data foundation problem in an AI project is to work around it — clean the data just enough to run a first model, learn from the results, and fix the underlying issues in parallel. This approach feels pragmatic. In practice, it consistently produces AI systems that consume ongoing maintenance effort without delivering reliable value.
A model trained on incomplete or inconsistent data does not just produce wrong answers — it produces wrong answers in ways that are genuinely difficult to diagnose. The model appears to work. It generates predictions. It may even show acceptable accuracy metrics during evaluation, because the evaluation set has the same gaps as the training set. The problems surface in deployment, or after three months when the model silently degrades, or in exactly the edge cases the business most needs it to handle correctly.
Fixing the data foundation first does slow the timeline to the first model run. It does not slow the timeline to a model that reliably works. The organisations that move fastest on AI — in a way that produces durable business value rather than impressive demos that cannot be operationalised — treat the data foundation as the first deliverable. Not a prerequisite to be resolved later. The first deliverable.
A data foundation that can reliably support AI has a single source of truth for each core business entity. Customer records, product data, transaction history — each should have one authoritative, reconciled version that AI pipelines read from, rather than being assembled from multiple conflicting systems at training time. This does not require all data to live in one place. It requires a defined, governed layer where the reconciled version exists and where pipelines connect consistently.
It has consistent historical records with documented schema changes. When business definitions change — when a product category is restructured, or “active user” gets redefined, or a CRM migration changes how customer IDs are formatted — that change needs to be documented and applied consistently to historical data. AI models trained across an undocumented schema change will learn the break as a meaningful signal and build it into their predictions.
It has a monitoring layer that catches data quality degradation before it reaches the model. Schema changes in upstream systems, unexpected drops in record volume, new null rates in fields the model depends on — these need to be detected automatically and flagged immediately, not discovered when model outputs start looking unusual weeks later. And it separates raw data from transformed data: raw source records preserved exactly as they arrive, transformation logic version-controlled and auditable, features stored in a layer that is reproducible from scratch. This separation is the foundation of reliable AI operations, and it is covered in more depth in the article on what data engineering actually means for business leaders.
If your organisation has AI ambitions — or an AI project that is underperforming — the most valuable investment is almost always a better data foundation, not a better model. View our data and AI services, explore our project portfolio, or get in touch and we can assess where your current data foundation stands relative to the AI outcomes you are trying to achieve.
Engine Analytics is a data analytics company in Singapore that builds the data infrastructure AI needs to work reliably — pipelines, governed data layers, quality monitoring, and the consistency framework that keeps model inputs accurate over time.
— Engine Analytics | Singapore’s data and AI consultancy — building the data foundations that make AI deliver what it promises, not just what it demonstrates.
Most AI projects fail because of data problems, not algorithm problems. The training data is incomplete, inconsistent, or poorly labelled — so the model learns patterns that do not reflect reality. The fix is not a better model. It is a better data foundation built before the model is trained.
For a business with three to five primary data sources and moderate data quality issues, a foundational data layer that can reliably support AI training typically takes six to twelve weeks to build properly. Trying to shortcut this by cleaning data just enough to run a first model consistently produces systems that need to be rebuilt once the problems surface in production.
