Last year a long-time client called me in a panic. They had spent six months and a healthy chunk of their budget “AI-powering” their customer onboarding flow. Management loved the demos. Meanwhile the thing was hallucinating shipping dates and suggesting product combinations that were illegal to sell. It was a technical failure and a brand problem at the same time.
They brought me in to “fix the prompt,” and my first instinct was the same: tighten the system instructions, add some few-shot examples, done. Wrong. I spent three days fighting the API before I understood that the prompt was never the problem. The context was. The model had no clear journey map to follow and was pulling from a messy, unvetted data source. What it lacked was a coherent AI UX strategy.
Why management often gets AI wrong
Your leadership team is not trying to break the product. They are reading the same hype cycles as everyone else, and to them efficiency, cost-cutting and “innovation” look like checkboxes. What they rarely see is the distance between a flashy demo and a production tool that solves a real user problem. Closing that gap is your job.
If you are a UX professional waiting for a “directive” on how to use AI, the decision is already being made without you, probably by someone who cannot tell a persona from a pizza. You have to lead this conversation, because you are the one who understands user intent and the high-judgment calls AI cannot automate yet. Across the projects I have worked on, the implementations that went well were run by the people who cared about why the feature existed.
Building guardrails in code
As a developer, what I tell my UX colleagues is that the strategy needs technical teeth. “Principles” on a slide are not enough, you need guardrails. In a WordPress or WooCommerce setup, for instance, you can hook into the AI response stream and validate it against your own business logic before the user ever sees it.
/**
* A simple guardrail to prevent AI from
* hallucinating specific forbidden keywords.
*/
function bbioon_validate_ai_response( $response_text ) {
$forbidden_terms = array( 'unlimited', 'free shipping forever', 'illegal' );
foreach ( $forbidden_terms as $term ) {
if ( stripos( $response_text, $term ) !== false ) {
return 'I am sorry, I cannot provide that information. Please contact support.';
}
}
return $response_text;
}
add_filter( 'bbioon_ai_assistant_output', 'bbioon_validate_ai_response' );This builds on something I read at Smashing Magazine about how UX leaders can take the wheel. Framing gets you further than arguing with the technology. Rather than asking for “more research,” tell management that research is how you “de-risk the AI investment.” That phrasing lands very differently in a boardroom.
Where the UX value sits now
The judgment calls are where your value sits now. AI will happily generate 50 layout variations, and it is terrible at knowing which one will not annoy an already frustrated user at 2:00 AM. That call is yours, along with translating business goals into something that does not read like a robot wrote it.
This gets complicated fast. If you are tired of untangling someone else’s build and just want the site working, drop my team a line. Odds are we have run into it before.
So are you going to define how your organization uses these tools, or wait to be told?
