GovCon Leads Radar — When 'safe AI' means knowing when it's wrong

The User Moment

Picture a GovCon seller opening their dashboard on a Tuesday morning. They’ve got twelve leads sitting in front of them, each one tagged with a tier — high confidence, worth a look, skip it — and a plain-language note explaining why. They trust that note enough to act on it in under a minute per lead. That’s the entire point of GovCon Leads Radar: turn a slow, manual cross-referencing slog into something a seller can triage over coffee.

Now picture the version of that morning where the note is wrong. Not wrong in an obvious, “the page crashed” way, but wrong in a way that sounds completely reasonable, cites a real contract signal, and quietly steers the seller toward pursuing a lead they should have skipped, or skipping one they should have chased. No error message. No red banner. Just a confident sentence that happens to be a little off.

That second scenario is the one that actually kept me up at night while designing this. Not “will the AI break?”; AIs break, that’s expected, and it’s recoverable. The real question was: what happens when it doesn’t break, but it’s still wrong, and the seller has no way of knowing?

The Design Problem

Here’s what made this genuinely hard: this product was built from day one on a simple promise: the AI proposes, the human decides. It never executes an outreach, never disqualifies a lead on its own, never takes an action a seller didn’t explicitly approve. That’s a good boundary, and I locked it early. But it created a blind spot I didn’t fully appreciate until I sat down to design the safety layer: if the AI never acts, does that mean it can’t cause harm?

Not exactly; it means the harm moves somewhere sneakier. . .into the seller’s head. If the AI’s explanation for why a lead is Tier 1 is subtly fabricated, or if it understates how serious a compliance flag actually is, the seller doesn’t know they’ve been misled. They just trust the wrong thing, once, and maybe don’t notice for months. That’s a much harder failure to catch than a crash, and a much worse one to explain to a paying customer after the fact.

The second, quieter risk sitting right next to it, which I’ve posted about previously: this product touches real people’s contact information — names, roles, government points of contact — pulled from public but still personal sources. Any safety design that only thought about “did the AI say something wrong” and ignored “did the AI leak something it shouldn’t have” would have been solving half the problem.

The Options

I considered a few different framings for what “safety” should even mean here, and I want to be honest about the ones I moved away from:

Option A — Prevention-first. Try to catch every possible way the AI could be wrong before it ever reaches the seller. This sounds responsible, but it’s a trap: you end up building an ever-expanding checklist that can never be complete, and you ship slower and slower chasing a guarantee you can’t actually make.

Option B — Treat it like a runaway-agent problem. A lot of AI safety writing assumes the danger is an autonomous system doing something it shouldn’t. That framing didn’t fit here at all — this product never autonomously executes anything consequential. Designing against a threat model that doesn’t exist would have wasted real design effort on the wrong risk.

Option C — Containment and recovery. Accept that the AI will sometimes be wrong, focus the engineering effort on (1) catching it fast when it happens and (2) making sure the failure never silently reaches a decision the seller didn’t know was compromised. This is the one I am building.

The Build

The version I am shipping centers on a simple idea: every piece of AI-generated text the seller sees has to earn its place on the screen, or it gets pulled before it ever renders. If the AI’s tier explanation makes a claim that can’t be traced back to an actual computed signal, it gets rejected — automatically, before the seller ever sees it — and the system falls back to a safe, non-misleading default instead. Same logic applies to anything touching a compliance flag: the system checks that the AI’s plain-language explanation actually matches the compliance category it’s describing, rather than trusting the narrative all on its own.

The part that surprised me was how much of the design ended up being about who gets to decide what happens next, not just what gets blocked. If something that looks like personal data shows up somewhere it shouldn’t, that’s not an engineering call: it goes straight to whoever owns privacy decisions for the product, with the authority to pull the AI-generated feature entirely and fall back to manual review until it’s resolved. If it’s a pattern of the ranking itself drifting, not a one-off glitch but something systematic, that’s a joint call between product and engineering, and it’s deliberately narrow: they can freeze the affected part and require a threshold adjustment, but they can’t just redesign the ranking logic on the spot. Different failures, different owners, different authority. . .because “something went wrong with the AI” is not one problem, it’s several, and treating them identically would have meant either overreacting to minor issues or underreacting to serious ones.

Finally, recovery mattered just as much as detection. Not every failure needs the same fix — a bad tier explanation just gets quietly re-rendered from a safe template; a personal-data exposure requires a much heavier response, including figuring out whether it needs to be formally reported. I didn’t want a one-size-fits-all “roll it back” button. I wanted the response to match the actual severity of what went wrong.

The Verdict

Does it solve the problem? Mostly, yes, but with one honest caveat. What this layer guarantees is that the system won’t silently let a fabricated or ungrounded claim reach a seller’s screen, and won’t let a personal-data slip go unnoticed or unowned. It does not, and cannot, guarantee that the seller’s judgment itself is always right; that was never the goal. The goal was narrower and more honest: make sure that when the AI is the thing steering a decision, it’s steering with something real, and make sure someone is accountable, fast, the moment it isn’t.

The part I’m most pleased with isn’t a clever prevention trick. It’s that the design assumes failure is normal and asks a much more useful question: when it happens, who notices, how fast, and what do they do about it. That’s a more honest promise to make to a paying customer than “our AI is never wrong,” and it’s one I can actually keep.

Your Turn

If you’re evaluating an AI tool for something as consequential as your sales pipeline: have you ever asked the vendor what happens the moment their AI is wrong — not if, but when? What did they say?