When AI should draft—and when it may send

List common messages and ask what would happen if one were wrong. A receipt acknowledging a submitted request usually has fewer consequences than a price quote, refund decision or statement about an appointment. Even a simple acknowledgment needs the correct recipient and accurate language.

NIST’s voluntary AI Risk Management Framework treats risk management as part of designing, using and evaluating AI systems. For a local business, a practical application is to connect review requirements to the consequences of each action rather than assuming one approval rule fits everything.

Let AI prepare a reply when staff must interpret a customer’s situation, confirm a price or resolve a complaint. Give the reviewer the relevant source information alongside the draft. A polished sentence is not evidence that the details are correct.

For example, a restaurant catering request might need an event date, guest count, venue and dietary information before anyone can quote. A useful assistant can summarize what is known and draft the next questions. It should not invent availability or turn an incomplete request into a confirmed booking.

If you choose automatic sending, start with a fixed purpose and approved wording. Specify the allowed audience, trigger, required fields, permitted claims and conditions that stop the send. Use the actual system result to decide whether an acknowledgment can say a request was received.

Separate an acknowledgment from a commitment. “Your request is in our review queue” means something different from “Your appointment is confirmed.” Match the message to the state your system can prove. Include a clear path to a person when the next step is uncertain.

• Block sending when the recipient is missing or ambiguous.
• Stop duplicate deliveries for the same event.
• Route unsupported questions to a person.
• Keep an accessible pause control and a record of sends.

Test with invented customer details in an isolated environment. Check wrong addresses, repeated events, missing fields and requests outside the approved topic. Review whether the system stops appropriately, not just whether the ideal response sounds friendly.

After launch, sample real outcomes under your access policy and track corrections or complaints. If staff spend more time repairing replies than reviewing drafts, reduce the automation level. Greater autonomy should follow demonstrated reliability, an accountable owner and a working fallback.