A municipal flood-tower helper’s hidden safety instructions would become an attack recipe if printed to every visitor. The desk still owes the public a plain-language this is an AI, here are its limits. Which tradeoff is that?
Select an answer to reveal the explanation.
Short Explanation
Think of hidden safety instructions that would become an attack recipe if posted, and a public still owed a plain-language this is AI, here are the limits. Do not leak internals. Still disclose the limits.
Full Explanation
The municipal flood-tower helper faces a real tension between model safety and stakeholder transparency. Hidden safety instructions that would become an attack recipe if printed to every visitor must stay protected. At the same time, the desk still owes the public a plain-language notice that this is an AI system and a clear statement of its limits. Responsible design discloses purpose and bounds without leaking internal defense prompts.
Printing the hidden instructions to every visitor fails because full leakage of safety scaffolding arms prompt-injection and jailbreak attempts. Telling the public nothing fails because silence denies people the right to know they are interacting with AI and where it can fail—especially in flood-tower contexts where over-trust is dangerous. Claiming there is no tradeoff and you can both leak internals and skip plain-language limits fails because that combines the worst of both worlds: attack surface and opacity to the public.
Exam caveat: public disclosure of limits is not the same as publishing system prompts, tool schemas, or refusal heuristics. Operational check: ship a short visitor-facing card (this is AI; it can be wrong; do not treat it as an official flood order) while storing safety instructions in a protected config path with change control, and verify the public card never mirrors the internal prompt text.