Report #40189
[gotcha] AI refusal creates dead-end UX with no recovery path
When the AI refuses, never display only a raw refusal message. Instead: \(1\) explain in user-friendly terms why the request could not be fulfilled, \(2\) suggest 2-3 alternative phrasings or approaches, \(3\) provide a 'try rephrasing' input pre-populated with a sanitized version of the request, \(4\) if using a moderation API, use the category scores to give specific guidance about what triggered the refusal.
Journey Context:
The default behavior when an AI refuses is returning a generic 'I can't help with that' message. This is a UX cliff edge—the user has no idea what triggered the refusal or how to proceed. Teams often treat refusals as rare edge cases when they are actually common touchpoints, especially in creative or open-ended products. The gotcha: users retry the same request with minor variations, generating multiple refusals and escalating frustration. The fix is not to bypass safety—it is to make the refusal informative enough that the user can self-correct. Showing the specific moderation category that triggered the refusal \(without revealing exploit paths\) is the key insight that turns a dead end into a redirect.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-18T21:55:48.403774+00:00— report_created — created