As a civil engineer, I learned a basic rule early in my career: no matter how attractive a design seems on paper, the structure is only as good as the quality of its foundation, materials and construction controls. You don’t assess a structure by how beautiful its rendering is. You judge it by how well it can stand, function, and stay safe under real conditions.Today, I bring that same instinct into my work as a data professional. If I am honest, I once found the phrase AI first quite persuasive. It sounds ambitious, modern, and commercially sharp. It suggests movement. It tells a neat story about innovation. But the more time I have spent working across machine learning, analytics, and operational systems, the less convinced I have become by slogans.The lesson that stayed with meThe very first project that shaped my thinking was a fraud intelligence workflow I worked on. It was designed to support earlier and more confident risk detection by combining several sources of information, including transaction behaviour, customer activity patterns, support interactions, and geospatial signals.At the start, the work looked like a typical machine learning challenge. We had models to test, and performance targets to meet. Naturally, the assumption was that the most difficult part would be the modelling layer.It was not. The real challenge sat in the data itself.Data from different systems described the same customer differently. Some features looked sensible until we traced how they had been built. Some labels seemed usable until it became clear they reflected inconsistent internal processes rather than dependable truth. Before I ask about model choice, I now ask where the data came from. Before I call a system scalable, I ask whether the underlying data is trustworthy enough to support scale.The wider field is saying the same thingThis is not only a practitioner’s concern. Research and industry literature increasingly shows that strong AI outcomes depend not just on model design, but also on data quality, governance, and maintenance. The case for data-centric AI reflects this shift by treating data as central to reliable AI performance.This is clear in ACM’s work on data quality requirements in machine learning pipelines, which shows that quality matters across the ML lifecycle, and in research on data cascades in high-stakes AI, which shows how upstream data issues can lead to serious downstream harm. Work on automating exploratory data analysis and data quality tasks also reinforces the importance of data preparation as a core part of ML practice.This broader view is strengthened by Data Quality in the Age of AI, which connects data quality with governance, ethics, reproducibility, and trust, and by Google’s Hidden Technical Debt in Machine Learning Systems, which warns that ML systems become fragile when data dependencies and maintenance demands are overlooked. Industry sources make the same practical point. IBM highlights the importance of AI data quality for reliable model behaviour, PwC presents data governance as essential for trustworthy AI, and MIT Sloan Management Review argues that improving quality starts with preventing errors at the source.The false choiceThe AI-first versus data-first debate is often framed as a choice between speed and discipline. That is the wrong way to think about it. The real issue is whether an organisation can build AI capability while improving the data foundations that the capability depends on.| Approach | What it sounds like | What it gets right | What it is not getting right ||----|----|----|----|| AI-first | Moving quickly and proving value with models | Momentum, visibility, experimentation | Poor data quality, fragile trust || Data-first | Fixing the foundations before going ahead to build | Quality, structure, consistency | Slow deployment, delayed adoption || Balanced approach | Build and strengthen the data layer as the AI capability evolves | Credibility, adaptability, long term resilience | Requires patience, coordination, and strong leadership |Table 1. Comparing AI-first, data-first, and a balanced approachWhat balance means in this contextBalance doesn't mean waiting for perfect data. It means improving models and data together. It means moving fast enough to learn, but carefully enough to expose weak assumptions early. It means asking: Who owns this dataset? Are definitions consistent? How are labels checked? What is monitored beyond accuracy?| Common issue | What an immature team does | What a mature team does ||----|----|----|| Inconsistent records | Patches around the inconsistency in modelling code | Resolves key entity definitions || Weak labels | Treats labels as good enough because the model trains | Audits label quality and revisits generation logic || Poor lineage | Relies on tribal knowledge | Documents transformations and versions critical datasets || Fragmented ownership | Assumes someone else is responsible | Assigns clear accountability || Drift in production | Waits for complaints, performance drops | Monitors both data health and model behaviour continuously |Table 2. From immature data practices to mature AI readinessConclusionIf an organisation says it is AI first, I now hear a question rather than a promise: What supports that ambition? If the answer includes reliable data, clear ownership, and monitored quality, the ambition has substance. If not, it is usually branding. The organisations that scale well build, test, refine, and govern together. They understand that intelligence without trustworthy data is fragile. That is the balanced approach for scale. And in my experience, it is the one that lasts.\