Spring Cleaning Your Data

The more time I spend in the world of AI, the more I find myself thinking about the parts of the system no one talks about.

We're all caught in the tidal wave of AI. What we can build. What we can automate. The insights we can unlock.

But beneath that wave, there's something else forming.

A rip current around the integrity of your data and infrastructure.

Organizations are moving fast, pulled forward by momentum: but without the same level of diligence beneath the surface. Data isn't fully understood. Integrations aren't clearly defined. Infrastructure hasn't been pressure tested.

That's a significant risk, because while the wave creates excitement, the current determines whether you stay in control or get pulled off course.

The Strategic Shift

The shift isn't technical. It's about how we frame the problem. Most teams start by asking what AI can do for them: but that's not the right place to begin. The better question is what the system is actually capable of supporting. Without that understanding, you're not building intelligence. You're layering assumptions on top of assumptions.

This work starts with taking inventory: and not in a superficial way. It requires an honest look at what actually exists, not what you think exists or what outdated documentation suggests. You sit down and examine the system as it is today.

You begin asking where your data comes from, which sources are actively used versus passively collected, and where things are incomplete, inconsistent, or quietly breaking. Eventually, a more difficult question emerges: do you actually understand what this data represents across systems?

That's where things begin to unravel. The same field can carry different meanings depending on where you look. Schemas drift over time, and transformations happen in places no one revisits. What once felt aligned starts to reveal itself as fragmented.

What You Can Actually Trust

From there, attention shifts to integrations: not just whether they exist, but how they behave. You begin to notice how often systems sync, where delays appear, and what happens when something fails. It becomes clear that distortion rarely originates at the source. It happens in the movement between systems.

Once you see the system clearly, the next step is not to fix everything. It's to decide what you can trust. Not all data is equal. Some signals are reliable, some are directionally useful, and some are simply noise presented as signal.

You begin to pressure test what you have using simple criteria: Is the data complete and current? Are patterns consistent over time and across systems? Do the outputs align with how the real world behaves? If something fails in more than one of these areas, it should not be used to drive decisions.

Simplifying the Signal

At this point, things begin to simplify. Most systems are not lacking data: they are overwhelmed by it. The question shifts from what you can track to what you should track. You anchor your thinking in decisions. You ask what you are trying to enable and which signals directly influence those outcomes. Everything else starts to fall away.

In an order workflow, for example, you don't need every update. What matters is confirmation that something was received, confidence that it's progressing correctly, and clear signals when something is off. Everything else is secondary.

This naturally leads to a shift in how you think about documentation. It's no longer a static reference. It becomes a mechanism for maintaining alignment. Instead of documenting what the system is, you document what the data means, when it's valid, and when it should be trusted. Just as importantly, someone owns it. Without ownership, systems don't break all at once: they drift gradually.

Making Peace With What You Carry Forward

At some point, you have to make peace with what you carry forward. You're not going to fix everything, and that's not the goal. The goal is awareness. You begin making intentional decisions about what needs to be fixed now, what can be monitored, and what you're choosing to carry forward.

This distinction matters because unacknowledged tech debt is risk, while acknowledged tech debt is strategy.

Only after all of this do you come back to AI: and by then the question is clearer. Is the data reliable? Are integrations stable? Are definitions aligned? Would different teams interpret the same output the same way? If the answer to those questions is no, AI will not solve the problem. It will scale it.

This is where the operating model begins to shift. You stop thinking in terms of features and start thinking in terms of systems you can trust.

The wave of AI is coming regardless. You can't stop it. But you can decide how you enter it.