Your AI project won't stall on the model. It will stall on the data.

In 2015 I built the portal architecture for Totvs Fluig on AWS, distributed across several continents. In 2018 I sent almost three million emails in six days during a Black Friday. At Aprova Digital, as CTO, I led the technology of an operation that reaches twenty-one million people a year in more than seventy municipalities.

I say this for one reason only: in none of those projects was the hard problem the algorithm. It was always the data.

The hype changed, the acronym changed, the math is the same.

Why AI makes it worse

Traditional systems live comfortably with bad data. They show the empty field, a person looks at it, works it out from context and moves on. The error stays contained in the head of whoever is using it.

A language model doesn't do that. It fills the gap. Given an incomplete record, it produces a complete and confident answer, because it was trained to generate plausible text, not to stop. The result is that bad data, which used to sit quietly in a table, now goes out in writing, nicely phrased, straight to the customer.

AI did not create your company's data problem. It just removed the person who used to compensate for it by eye.

The four problems that show up first

Duplicates. The same customer with three records, because they came in through a listings portal, the website and a referral. The agent treats all three as different people, and the customer gets the same message three times with slightly different names.

Stale data. Price, inventory, deadlines. In a sales operation, the field that is wrong today is the field that generates the promise the company will have to take back tomorrow.

Free-text fields. Every CRM has a notes field where the most important information about the deal lives, written in shorthand, with no standard, mixing facts with the salesperson's impressions. It is the richest data and the hardest to use.

Missing source. Without knowing where a lead came from, no prioritization rule works, and every report on the agent's results turns into an argument about attribution.

What you can do without stopping everything

The usual reaction is to set up a twelve-month data governance project. In most companies that project never ends, and while it doesn't end, no AI happens.

There is a shorter path.

Pick a single flow. One channel, one product, one type of service.

List the fields that flow actually uses. Not the ones that exist. The ones the agent will read to make decisions. Usually there are fewer than ten.

Clean only those fields, and name an owner for each one. An owner is a person, not a department.

Put the agent to work on that flow and treat each of its mistakes as a symptom. When it gets something wrong, the first question is not which prompt to tweak, it is which field was wrong.

That cycle teaches you more about your operation in three weeks than a three-month assessment. And it has a big political advantage: it delivers visible results while it tidies the house, instead of asking for a year of faith.

The good side effect

There is something almost nobody anticipates. Putting an AI agent into an operation is the cheapest and most honest diagnosis there is of the quality of your data and the clarity of your processes.

It has no patience, no common sense and doesn't fill gaps with experience. It does exactly what the available information allows. Wherever it fails repeatedly, there is a poorly defined process underneath.

Companies that understand this use their first months of AI as an X-ray. Companies that don't spend those months fighting the prompt.

The takeaway

The model is a commodity and gets cheaper every year. The good ones are one click away for any of your competitors.

Your operation's data is not. It is the only asset in this story that nobody can buy off the shelf, and it is what decides whether AI becomes results or becomes one more project that quietly stopped working without ever having failed.