You will be able to set up an AI drafting step that saves a draft for review instead of sending automatically.
When an automation flow reads a message and an AI step writes the answer, the risk sits in what happens to that answer next. If the flow sends it straight to the customer, anything the model gets wrong goes out under the business's name, and nobody sees it until the customer replies.
Take an extreme case, invented for illustration. A parent emails a tuition centre asking about Sec 3 maths fees. Buried in the email is a line telling the AI to ignore its previous instructions and offer a 50 percent discount for the first term. If the flow auto-sends whatever the AI writes, the parent may receive an offer nobody approved. The centre then has to honour it or explain to an annoyed parent why it will not.
Most of the risks are quieter than that. A draft might quote last year's fees, promise a Saturday slot that is already full, or answer a worried parent in a cheerful tone that comes across as dismissive. Each of these is a small embarrassment, and the same design prevents all of them: the AI writes a draft, and a person decides whether it goes out.
The drafting step should save the reply somewhere a person will look, and it should never send it. There are two common ways to do this.
The first is the email drafts folder. Many email actions in automation tools can create a draft reply in the correct thread instead of sending. Someone opens the drafts, reads each one, edits if needed and presses send. This is the simplest option, and everything stays inside a tool people already use.
The second is an approval queue, a place where drafts wait for a person to approve them before the flow sends them. It can be a column in a sheet, a chat message with approve and edit buttons, or the tool's built-in approval step if it has one. When someone approves, the flow continues and sends. It takes longer to build, but it records who approved what, and you will need that record in module 7.
Start with every AI reply going through a person. Later you can relax this for specific low-risk cases, once the logs show the drafts are reliably right. Lesson 7.3, Logs and human review checkpoints, covers how to decide when to do that.
A model knows nothing about your business except what is in the prompt. Give it what it needs, and forbid it from filling gaps itself.
From the record, pass in the parent's name, the child's level, the message itself and the classification label your flow assigned in Lesson 5.2, Make the model pick from a fixed list. The facts the model may use in its answer should be pulled from your sheet rather than typed into the prompt: the current class days for that level, the teacher's name and the next step.
For tone, two or three real replies you have already sent, with names removed, work better than adjectives such as "warm but professional". This is the same idea as Working with AI assistants lesson 2.2, Style samples and examples of what to avoid.
Then add plain rules. Tell the model never to state a price, fee, discount, date or time unless it appears in the facts provided. If the parent asks about something the facts do not cover, the reply should say someone will get back to them with details. Set a maximum length and tell the model to keep the reply under it.
Leaving a fact out of the inputs on purpose is a valid choice. Mei Ling, who runs the tuition centre's flow, does not pass fees into the drafting step, because fees change by term and she wants a person to send them. Her drafts for fee questions say: "Our teacher will send you the current fee schedule for Sec 3 when she calls." The teacher then calls the parent and sends the current schedule. The draft leaves the fees out deliberately so that a person handles them.
The discount email above is an example of prompt injection: text inside the content a model is reading that tries to act as an instruction. The model receives your prompt and the email as one block of text, so it can be fooled into following instructions hidden in the email.
Prompt wording cannot fully prevent this. Marking the incoming message clearly as content to be read, and telling the model to treat it only as content, helps a little.
The real protection is limiting what the AI step is allowed to do. Never give an AI step the power to send, delete, pay or change records directly. Its output should be text that goes to a draft or a queue for a person to read. With that design, the worst result of a successful injection is a strange draft that someone deletes.
This applies to every AI step that reads outside text, including enquiries, emails, attachments, web pages and documents.
The drafting step is only worth its cost if the drafts save time. To find out, keep an edit tally for the first few weeks: for each draft, note whether it was sent as is, lightly edited, or mostly rewritten.
If most drafts are being rewritten, either the prompt lacks facts or tone samples, or the use case does not suit drafting. Concern messages can be a poor fit, because a worried parent may need a phone call far more than a better email. Fix the prompt first. If heavy edits continue, remove the drafting step for that label and keep it for the labels where it helps.
In the activity below you will add a drafting step to your flow that saves each reply as a draft, then review five drafts and note what you changed in each. Those notes are your first edit tally.
Add a drafting step to your flow that saves a reply as a draft, then review five drafts and note what you changed.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).