Your AI Copilot Just Briefed the CEO on Bad Data. Now What?

Emily Goh · 2026-11-04

It's 7:40 on a Tuesday morning. The CEO forwards you a message with one line on top: "Is this right?"

Below it is a neat summary from the AI assistant built into your CRM. Pipeline is up. Three enterprise deals are "on track to close this month." Win rate looks better than last quarter. It reads well. It sounds sure of itself.

You open the first deal. The close date was set five months ago and never moved. The second deal's owner left the company in August. The third is a renewal someone logged as new business.

So what are the risks of AI on dirty CRM data? The main one is not that AI makes errors. It's that AI turns bad records into confident, polished answers, faster than anyone can check them, and hands them straight to the people who make decisions. The AI wasn't broken. Nobody told it your rules. It read the fields as they are, with no idea what your team means by pipeline, closed won or "on track."

A polished summary hides the mess

A messy spreadsheet looks messy. You see blank cells, odd totals and a tab called "FINAL v3 (2)." People treat it with suspicion, and that suspicion is healthy.

An AI summary looks finished. Full sentences, a tidy tone, no visible gaps. Nothing in it says half the inputs were stale. So the warning signs disappear at the exact moment the number reaches the most senior person in the room.

You can fix this morning's three deals by lunch. The harder question is what stops the next briefing from doing the same thing.

The AI needs your rules, not just your data

Out of the box, an AI assistant knows your fields. It does not know your definitions.

It can see a field called Close Date. It can't know that, say, your team treats any close date more than 30 days in the past as stale. It can see a deal in "Proposal" stage. It can't know that Finance doesn't count it as pipeline until the proposal is signed off. It can see a deal type of "New Business." It can't know that renewals keep getting logged there by mistake.

Those rules are your guardrails: the written definitions your teams actually use, plus what a valid record looks like under each one. If you've never seen one written down, start with What a Data Guardrail Actually Looks Like.

Getting AI to respect guardrails is real work. In practice it means four things:

• Writing the rules down in plain language, including the exceptions everyone "just knows."
• Turning each rule into a check the AI or the system can run against every record.
• Testing it on your real data, finding where it gets things wrong, and correcting it. Then doing that again.
• Keeping it current. Definitions change. Fields get renamed. A new sales motion adds a stage. Every change means the checks need updating, and someone has to own that.

The first step is yours no matter what. Only your team can say what closed won means at your company, and leaving it unwritten is how forecasts break (see The Definition Nobody Writes Down Is the One That Breaks Your Forecast). The other three steps are where build versus buy comes in.

Building it yourself: what it really costs

A common first attempt at building it looks like this. Someone connects a general AI tool to the CRM, writes a long prompt full of definitions, and starts asking it questions. It works well enough in the demo.

Then the real costs show up.

It takes your best ops person. The person who knows your definitions best is usually the one who ends up teaching the AI, testing its answers and fixing its mistakes. That's time not spent on the pipeline itself.

It's never finished. Every new field, renamed stage or changed definition means re-testing. The work doesn't end at launch. It becomes a permanent part of someone's job.

It's hard to prove. When the CEO asks "is this right?", a homegrown setup often can't show which rule was applied, who approved it, or which records the answer came from. If you can't trace a number back, you can't defend it (more on that in If You Can't Trace a Number, You Can't Defend It).

It leaves when the builder does. If the one person who understood the prompt and the checks moves on, the knowledge goes with them.

None of this means building is wrong. If you have an ops engineer with spare time, a handful of metrics and definitions that rarely change, building can make sense. But be honest about whose time it uses, and for how long.

Buying it: what to ask

Buying means someone else has already spent the time teaching software how to check CRM data against business rules, and keeping that work current. Your team supplies the part only it can: the definitions.

Not every tool does this the same way. Five questions sort them quickly:

1. Whose definitions does it use? Yours, or a generic idea of "clean data"?
2. Does a person approve the rules before they're used?
3. Is every change to a rule recorded, with who changed it and when?
4. Can you see the records behind every finding, not just a score?
5. Does it change your CRM data, or only read it?

If a tool can't answer the first one clearly, it will give you the same problem as this morning's briefing: confident answers built on rules nobody at your company agreed to.

Where Gohvio fits

Gohvio is the buy option for this. You upload your own guardrails, the definitions your teams actually use, as a document. A person approves them, and each change is recorded with who changed it and when. Gohvio then checks your CRM data against those guardrails and shows what is broken, what it does to pipeline and forecast, and the rows behind every finding. It is read-only: it reads your CRM and does not write to it.

Your team writes the rules. Gohvio does the checking.

Stop debating your data. Start making evidence-based decisions.