Saying No to an Unsafe Request
Identify and address unsafe requests during Forward Deployed Engineer (FDE) interviews by recognizing actions that compromise safety, explaining the associated risks in terms relevant to the customer, and proposing practical alternatives. Evaluate requests presented as efficiency improvements to identify potential safety concerns, particularly in high-risk environments such as healthcare. Clearly state which actions must be declined, justify the decision by emphasizing patient safety, and recommend safer approaches that support the customer's objectives. Navigate discussions involving organizational policies, mission alignment, and customer expectations while maintaining appropriate safety boundaries. Demonstrate sound judgment by balancing customer needs with safety requirements and developing solutions that achieve operational goals without introducing unacceptable risks.
This FDE interview exercise presents a customer who asks for something that you shouldn’t build. The interviewer isn’t testing whether you can refuse; anyone can say no. They’re testing whether you can name the exact action that crosses the line, explain why in the customer’s own terms, and leave with a plan the customer still wants. Lakeside’s sponsor now gives you that moment: file AI-generated notes automatically and let clinicians correct them later.
How do you recognize the line?
Unsafe requests rarely announce themselves. They usually arrive as a cost or speed fix with a safeguard attached that doesn’t do anything. Four signals should make you stop and look closely:
A human decision disappears before a high-stakes action: OpenAI’s usage policies prohibit automating high-stakes actions in sensitive areas, including medical settings, without human review. Filing a note without a clinician’s decision is exactly that.
The model takes on a professional’s role: The draft starts deciding care, or the product implies the AI holds clinical credentials.
Data moves without approval: Recording, transcription, or a new vendor goes ahead before Lakeside’s privacy team has approved it and signed the agreements it needs.
A label stands in for a control: “AI-generated” tags, disclaimers, and later corrections describe the risk without preventing it.
The sponsor’s request hits the first and fourth signals at once. The usage policies also say their rules don’t substitute for legal requirements, professional duties, or ethical obligations. So the policy is one reason to refuse, alongside Lakeside’s own duties to its patients, and the sponsor accepting the risk settles neither.
What does the replay show?
The interviewer adds evidence. Lakeside replayed nine test encounters through the sponsor’s shortcut, writing each draft to a mock record without review. One note was written with “No known medication allergies,” although the source had no allergy history. Another was written with a fever claim that reversed the source’s “no fever.” Nobody has checked the other seven for safety, so they count as unknown, not clean.
Two bad writes in nine attempts isn’t a production error rate, but it’s enough to show the mechanism: the shortcut skips the review step, so nothing stops these sentences ...