Getting your data in order before you let AI agents loose on it

There is a moment in almost every AI project where someone says "but first we need to sort out the data." What follows is usually a proposal to migrate or consolidate systems, a number with six figures in it, and a decision to postpone the whole thing. That sequence is so common it is nearly a ritual.

It is also, in most cases, the wrong diagnosis.

Your data is probably not dirty, it is unlabelled

When a company of eighty people says its data is a mess, what is usually true is narrower and much more fixable. The records exist. They are largely accurate, because the business runs on them and errors get noticed. The problem is that nothing anywhere states what they mean.

A field called status_2 contains the values A, B, C and X. Everyone in operations knows X means the order was cancelled by the customer rather than by us, which matters enormously for reporting and not at all for shipping. That knowledge exists in three people's heads and in no schema. A human reading the table guesses wrong; a model reading the table guesses wrong with more confidence and at higher volume.

That is not dirty data. That is undocumented meaning, and the fix is different, cheaper and faster.

A filing cabinet. The question is not whether the data exists, but whether a system can tell what it means.

What an agent actually needs

A useful way to think about it: an AI agent working with your data needs the same things a competent new employee would need in their first week, and for the same reasons.

What the fields mean. Not the column name, the business meaning. What counts as a customer, what counts as an order, when a record becomes final.

Which source wins. Almost every company has the same figure in two places that disagree. People resolve this automatically by knowing which one is trusted for what. A system has no way to know that unless someone says so.

What is out of bounds. Which fields contain personal data, which records may not leave the building, which tables are historical junk nobody cleaned up. Without this, an agent will happily use all of it.

What good looks like. A rough sense of plausible ranges, so an obviously wrong answer can be caught before it reaches a customer rather than after.

None of those four require moving a single record.

What an agent needs, and what happens without it

None of the four requires moving a single record, and all four are things a competent new employee would be told in their first week. That comparison is the whole point: you are not preparing data for a machine, you are writing down what you would otherwise have to explain out loud.

The semantic layer, in plain terms

This is what a semantische laag is for. Rather than restructuring your systems, you put a description over them: a definition of each concept the business uses, which system is authoritative for it, and what the rules are. Your ERP stays exactly as it is. Your CRM stays exactly as it is. What changes is that there is now one place that says what everything means, and both people and systems can read it.

The practical advantages at this company size are the reason we work this way rather than the theory being elegant. You are not taking a business-critical system offline. You are not betting the year on a migration project. And if you later decide to replace the ERP, the definitions survive the replacement, because they describe your business rather than that vendor's schema. That portability is the same argument as everywhere else in our stack: keep the thing that carries meaning separate from the thing that happens to store it today.

Network cabling. A semantic layer sits over your systems rather than replacing them.

Where to start, concretely

Do not start with all your data. Start with the data behind the one opportunity you actually intend to build, from your priority matrix. For that one use case:

One. List the fields it touches. Usually fewer than thirty. This alone often reveals that two of them mean the same thing and disagree.

Two. Write one sentence per field, in business language. If nobody can write that sentence, you have found something important: a field whose meaning is genuinely contested inside the company. Resolve it now, because an agent will otherwise pick one interpretation silently.

Three. Name the authoritative source per concept. One line each. This is the highest-value hour in the whole exercise.

Four. Mark what is personal data. Not for the AI Act specifically, which is a separate regime from privacy law, but because it determines what may be sent where, and that decision is much easier before a tool is running than after.

Why doing it this way survives the next project too

The reason we push this order rather than a migration is not only cost. A migration produces a cleaner system and no documented meaning, so the second AI project rediscovers the same questions from scratch. Writing the meaning down produces an asset that every subsequent project reuses, including projects that have nothing to do with AI, like finally getting reporting to agree with itself.

It also means the honest answer to "is our data ready for AI" stops being a feeling and becomes checkable. Either the thirty fields behind your first use case are described or they are not, and you can see which in an afternoon.

About this page

The semantic-layer approach described here matches the semantische laag definition on this site and is the method Radical uses in practice: describe meaning over existing systems rather than migrating them. The four-item list of what an agent needs is our own framing. The point that AI Act obligations and privacy law are separate regimes is stated deliberately, because the two are frequently conflated. Written by Radical's own team; no client data was used.