Steven Power

Most organisations do not struggle with AI because the models are weak. They struggle because the systems feeding those models were never designed for consistency at scale.

That is why many AI initiatives stall after promising pilots. The issue is rarely the model alone. It is that the underlying architecture cannot reliably support consistent behaviour, explainability, and change at enterprise scale.

Before scaling AI, it is worth asking a more fundamental question: does the current architecture support how the organisation wants to operate, or does it simply reflect compromises made along the way?

Data quality challenges aren’t limited to legacy systems.

As organisations ingest more unstructured data, high-frequency records, and externally sourced information, ensuring quality at the point of entry becomes harder. Free-text fields, loosely validated inputs, delayed events, and noisy records are increasingly common.

Downstream checks help, but they can’t fully compensate for poor inputs.

Another common pattern emerges when data quality issues are discovered downstream.

In many organisations, engineers and analysts don’t own the source systems. Fixing data at the origin requires coordination, influence, and time. Fixing it downstream is faster and firmly within their control.

So they do what makes sense in the moment. They engineer around the problem.

Transformations are added. Rules are layered in. Pipelines compensate.

Most AI initiatives don’t fail loudly.
They don’t break on day one or collapse because the models are wrong.

Instead, they lose momentum. Outputs get questioned. Adoption slows. Confidence fades. Eventually, AI is blamed, even though the real problems were already there long before any models were trained.

In practice, AI readiness is rarely a tooling problem. It’s a data foundations problem. More specifically, it’s a small set of recurring data quality patterns that quietly undermine trust at scale.

These patterns are common. What’s less obvious is their hidden cost.