AI does not fix bad data. It exposes it

There is a thoughtful piece going round this week, written by the group CEO of an international IP firm, arguing that most firms are not ready for AI. His central claim is that AI does not solve operational fragmentation. In many cases it exposes it. A firm cannot build real AI capability on unclear data ownership, inconsistent definitions, duplicated records, and reporting that depends on local spreadsheets only one person fully understands.

I agree with him. I agree because I learned the same lesson the expensive way, on my own platform, this year.

TMGuard is a UK trademark monitoring and intelligence platform. The core promise is simple to state and hard to keep: watch the registers, and tell the customer when something that could affect their brand appears. Earlier this year that promise had quietly drifted from reality. The monitoring customers were paying for was not producing what it should have, and nothing in the system was checking that it was. No customer was harmed and no opposition deadline was missed. But the gap existed, it had existed for a while, and we did not know it was there.

That is the part worth sitting with. Not that something broke, because things break. The uncomfortable part is that the platform looked like it was working. The dashboards were green. The product gave confident output. And confident output that nobody has verified is the most dangerous state a data product can be in, precisely because it raises no alarm.

The instinct in that situation is to reach for a better algorithm. That instinct is wrong. The fix was not a cleverer model. It was a month of work that does not appear in any vendor presentation.

First, the data itself had to be correct. We found and corrected over a million data rows that carried the wrong values, including opposition deadlines that a date-arithmetic bug had pushed days later than the statute allows. In a product whose entire job is to protect a legal deadline, a deadline that is silently wrong is the worst possible failure. Every corrected row was backed up first and verified afterwards.

Second, the data had to mean one thing. We removed several million duplicate records and added a constraint at the database level so that the same duplication can never happen again. Before that change, the same applicant could exist many times over, which quietly corrupts any count, any ranking, any piece of intelligence built on top. You cannot reason about data that does not agree with itself.

Third, and this is the part I would push every firm towards, the system now checks its own promises. Every morning it runs a set of invariants against the live data and emails me when one of them is not being kept. Is every published mark carrying a correct deadline. Is each register actually advancing on schedule. Did every scheduled job complete. Is the matching engine running, not just present in the codebase. The rule we adopted is that every core promise the product makes to a customer must map to an automated check, and every time we find a silent failure, the fix ships with the check that would have caught it.

That immune system earned its keep almost immediately. In its first three mornings of operation it flagged three separate real issues, each one caught by the system before any customer noticed. One was a register that had silently stopped updating. One was the matching engine having quietly stalled. One was a background process that had never run since a recent change. None of these would have announced themselves. All three would have sat invisible for weeks in the version of the platform that only looked healthy.

This is the difference the article is really pointing at. There will soon be very little distinction between firms that use AI and firms that do not, because everyone will use it. The distinction that lasts is between treating AI as a productivity layer bolted onto whatever data you already have, and building the foundation that makes AI trustworthy underneath it.

The foundation is the boring part. It is clean data, integrated systems, definitions that hold across the whole business, and something that tells you when any of it breaks. It is not exciting and it does not demonstrate well. But it is the thing that decides if your AI produces intelligence or produces plausible-looking output that no one has checked.

For an IP firm the stakes are specific. A client portfolio spans trademarks, renewals, oppositions, recordals, watches, and enforcement across many jurisdictions over many years. Structured well, that activity becomes a strategic asset: you can see where a client is expanding, where a renewal is at risk, where a relationship could deepen. Structured poorly, the same work stays trapped in silos, and the firm knows more than its systems can ever show. AI does not change which of those two situations you are in. It only makes the gap between them more visible.

I would rather run a system that admits when it is wrong than one that looks impressive and is quietly inaccurate. Building the first kind took longer and was far less satisfying than shipping a new feature would have been. It is also the only version I would put a customer's brand behind.

The question for any firm exploring AI is not which tool to buy. It is the harder one underneath: what would AI need to know about us to be useful, and do we trust the data well enough to let it answer.