It is now easy to paste an incoming message into an AI tool and ask for a reply. Making AI email drafting safe enough for routine use across Thailand and ASEAN is a different problem. A fluent message can still go to the wrong recipient, refer to the wrong attachment, invent a delivery date, expose personal data, or express a stronger commitment in Thai, Vietnamese, English, or Japanese than the business intended.
The safe unit of automation is not “AI sends an email.” It is: AI creates a controlled draft from permitted information, and a named human approves the recipients, attachments, factual claims, and tone before anything is sent. This guide explains how management, sales administration, procurement, customer service, IT, security, and compliance teams can design that workflow around Outlook, Microsoft Graph, enterprise AI, and human approval.
Why copying an inbound email into a public AI chat and auto-sending the answer is weak
An email thread contains more than the sentence a user wants answered. It may include sender and recipient addresses, signatures, old quotations, prices, product details, contractual discussions, personal data, and attachments. Sending the whole thread to an external service can process information that was never needed for the task and makes retention, deletion, cross-border transfer, and processor obligations harder to explain.
Inbound content must also be treated as untrusted data, not as instructions. An email body, signature, quoted thread, linked page, or attachment can contain text that attempts to override system rules. OWASP’s LLM01:2025 guidance explains that direct and indirect prompt injection can alter model behavior and that RAG or fine-tuning does not fully remove the risk. The workflow therefore needs to separate instruction fields from quoted content and keep AI privileges narrow.
Auto-sending adds further operational failure modes:
- the model may invent a price, delivery date, certification, discount, or obligation;
- Reply All, forwarding, CC, or BCC may disclose information to an unintended party;
- the body may say that a file is attached while no file, an obsolete version, or another case’s file is attached;
- honorifics and escalation language may change the level of commitment between Japanese, English, Thai, and Vietnamese;
- an API acceptance response may be mistaken for recipient delivery;
- reviewers may assume an AI-written draft is correct and approve it mechanically.
Microsoft Graph provides a useful technical boundary. Its Create message operation can create a message in JSON or MIME and save it in Drafts by default. Sending an existing draft is a separate operation with a different least-privileged permission. A successful HTTP 202 means the request was accepted; it is not proof that the recipient received the message. This separation lets an architecture grant draft creation without allowing the drafting component to send.
A controlled AI email drafting workflow
The recommended design is a sequence of controlled stages, not a single large prompt.
1. Ingest only permitted fields
Do not expose an entire mailbox by default. Define the permitted mailboxes, folders, work queues, date range, quoted-thread depth, and attachment formats. Remove or mask tracking elements, signatures, old thread content, and personal data when they are not needed. A shared mailbox needs its own purpose, ownership, and access policy rather than a copy of one user’s permissions.
2. Classify purpose and risk
Classify messages into business purposes such as quotation acknowledgement, delivery inquiry, complaint, contract change, invoice issue, recruitment, or a data-subject request. A routine acknowledgement may be suitable for automated drafting. Legal interpretation, discount approval, contractual commitments, incident reports, and personal-data requests should route to qualified owners. “Escalate to a human” must be a valid result, not a failure that the model tries to hide.
3. Retrieve approved facts and templates
Restrict retrieval to approved product specifications, price lists, FAQs, contract language, commercial terms, and calendars. Each source should have an owner, version, and review date. Expired content should not be silently used. If no approved basis is available, the system should display an open question or request confirmation instead of guessing.
4. Generate a structured draft
Pass the business purpose, relationship, approved facts, prohibited claims, language, and tone as structured fields. Clearly label quoted mail as data to summarize and answer, never as system instructions. Return not only a subject and body but also the sources used, unresolved items, detected language, and risk flags. That structure makes later validation and human review more reliable.
5. Check policy, recipients, attachments, and claims
Combine deterministic checks with model-assisted review:
- compare To, CC, and BCC with the case record and actual conversation participants;
- flag external, personal, and lookalike domains;
- compare references such as “attached” with the actual file ID, name, version, and classification;
- trace prices, dates, quantities, lead times, standards, certifications, and contractual claims to an approved source;
- preserve the boundaries among the latest message, quotations, and signatures;
- prevent personal or confidential data from appearing outside the permitted scope;
- isolate suspicious instructions found in the body, links, or attachments.
Rules should handle facts that can be determined reliably—such as domain allowlists, attachment identifiers, and numeric source matching—rather than asking another model to judge everything.
6. Route to a named approver
The review screen should show the source message, summary, draft, supporting facts, unresolved items, recipient differences, attachments, and risk flags together. Record the person who approved it. Route by case type, amount, role, or data classification. Where segregation of duties is required, prevent the same person from both creating and approving the transaction.
7. Save to Outlook Drafts and send only after approval
Microsoft’s Outlook message automation documentation describes both create-draft-then-send and one-step send patterns. For normal business correspondence, use the draft pattern and verify the isDraft state. Separate Mail.ReadWrite, used for draft operations, from Mail.Send, used to send, across components and approval stages. The AI drafting process should not possess an independent path to send.
8. Retain evidence—and make deletion possible
Record who used which inputs and approved sources, which model and prompt version created the draft, what was changed, who approved it, and when the send operation was initiated. Auditability does not justify retaining everything indefinitely. Define retention and deletion by data category. Logs can contain message text and personal data, so they also need access controls, encryption, search, export, and deletion procedures.
Three deployment patterns that should not be confused
| Pattern | AI role | Human role | Suitable use | Primary concern |
|---|---|---|---|---|
| User assist | Suggest summaries and wording for an open message | Select, edit, and send | Individual productivity and judgment-heavy cases | Copy/paste leakage and inconsistent user practice |
| Draft automation | Read an approved queue, validate, and save drafts | Named reviewer checks recipients, attachments, claims, and tone | Sales administration, procurement, first-line inquiries | Privilege separation, exceptions, meaningful approval |
| Autonomous sending | Create and send when narrow conditions match | Monitor and handle exceptions | Bounded, low-risk, reversible notices | Misdelivery, cascading actions, stop controls, accountability |
For ordinary customer and supplier correspondence, start with user assist or draft automation. Autonomous sending should be reserved for narrowly bounded cases with fixed recipients and facts, limited impact, clear monitoring, and immediate stop procedures. High language quality alone is not a sufficient reason to permit autonomous sending.
A PDPA-oriented data map
PDPA readiness is not achieved by adding a privacy paragraph to the interface. The organization needs to explain what data moves from where, for which purpose, through which processor, to which location, and when it is deleted. The table below is a system-design worksheet for discussion with a DPO or qualified counsel, not legal advice.
| Data element | Purpose | Typical risk | Decision to document |
|---|---|---|---|
| Sender and recipient addresses | Identify the case and reply path | Misdelivery and purpose expansion | Allowed domains, external warning, masking, access |
| Quoted threads | Understand context | Excess personal or confidential history | Maximum depth, signature removal, case boundary |
| Attachments | Understand and answer a request | Malware, wrong case, confidential disclosure | Allowed formats, scanning, classification, version check |
| Personal data | Identify and serve a person | Unlawful or opaque processing, over-retention | Lawful basis, notice, rights, retention, deletion |
| Confidential data | Prepare commercial or technical answers | External disclosure or cross-case leakage | Classification, prohibited categories, tenant boundary |
| Prompts and outputs | Generate and improve drafts | Duplicated content and extended storage | Storage, retention, improvement settings, deletion |
| Operational and audit logs | Evidence and incident investigation | Sensitive information accumulating in logs | Fields, viewers, integrity, search, retention |
| Transfer and subprocessors | Cloud processing and support | Jurisdictional and contractual mismatch | Region, transfer basis, processor terms, exit process |
For Microsoft 365 Copilot, Microsoft states that prompts, responses, and data accessed through Microsoft Graph are not used to train foundation LLMs, that Copilot only surfaces organizational data the user can view, and that interaction content is stored under Microsoft 365 commitments. Review the official data, privacy, and security documentation and Copilot Chat protections against the actual subscription and tenant configuration; available controls are not identical in every plan, and web grounding has its own data-handling considerations.
For the OpenAI API, the official data controls documentation says API data is not used to train models by default unless the customer opts in. Abuse-monitoring logs are generally retained for up to 30 days, with endpoint and control exceptions, and Zero Data Retention is subject to eligibility. These are API terms and should not be generalized to consumer ChatGPT. Compare each candidate service’s contract, retention, region, subprocessors, and deletion process.
Confirm lawful basis, notices, retention, cross-border transfers, and processor terms with the organization’s DPO or qualified counsel. The architecture can make those decisions enforceable, but it does not replace legal review.
Thai and ASEAN multilingual realities
Literal translation does not preserve business responsibility. A gentle Japanese phrase may become a firm promise in English, an overly direct request in Thai, or an ambiguous instruction in Vietnamese. Maintain customer- and process-specific style guides and evaluate whether:
- honorifics, job titles, names, and greetings fit the recipient’s convention;
- “we will check,” “we will act,” and “we guarantee” retain distinct commitment levels;
- date, time zone, currency, and unit formats cannot be misread;
- local staff do not commit to discounts, delivery, contracts, or incident statements requiring head-office approval;
- a complaint response separates apology, known facts, interim action, and the next update;
- ownership and approval are explicit in a shared mailbox.
The evaluation corpus should include more than four clean translations of the same sentence. Include realistic code-switching: an English product name in Thai, a Japanese approval note, an English contract phrase, and a Vietnamese factory update in one case. The terminology list should identify terms to translate, terms to retain, and an approved localized form.
Thailand’s ETDA/AIGC organizational generative AI governance guideline asks organizations to understand capabilities and limits, assess risk, establish organizational practices, and apply governance suitable to their context and relevant law. It is guidance, not binding legislation. The related ETDA announcement frames the document as a way for executives and relevant personnel to balance benefits, privacy, data security, and longer-term effects.
A 30-day PoC that tests operations, not only prose quality
A PoC should not become a beauty contest for the most fluent model. Use the 30 days to test scope, data boundaries, approval, exceptions, stopping, and evidence. The following schedule is a planning template, not a universal performance promise or legal deadline.
Days 1–5: scope and baseline
- define the mailboxes, work types, exclusions, languages, users, and approvers;
- record current drafting time, review time, returns, and recipient or attachment near misses using the company’s definitions;
- assign owners for the data map, lawful basis, notice, processors, retention, and transfers;
- begin without sending permission, using a test environment and synthetic or appropriately protected data;
- agree in advance on events that cause an immediate stop.
Days 6–10: test corpus and scorecard
Include normal inquiries, ambiguous requests, multiple cases in one thread, obsolete prices, conflicting dates, missing attachments, lookalike company names, external CCs, complaints, and mixed languages. If real mail is used, confirm its purpose, access, masking, and storage. Give each sample an expected classification, approved evidence, prohibited claims, correct recipients and attachments, and required approver.
Days 11–18: drafting and multilingual evaluation
Fix the model, prompt version, retrieval scope, templates, and input filters for each comparison. Qualified reviewers for Japanese, English, Thai, and Vietnamese should assess meaning, commitment level, terminology, tone, dates, figures, and presentation of unresolved facts. A fluent but factually wrong draft must not receive a high score.
Days 19–23: red-team and resilience tests
- embed instructions in the body, signature, quotations, links, and attachments;
- introduce a lookalike domain, hidden BCC, or changed reply address;
- mismatch the message text and attachment version;
- request unsupported discounts, dates, quantities, or certifications;
- make the approved knowledge source unavailable or leave only an expired template;
- simulate API errors, timeouts, duplicate processing, and post-approval changes;
- test log gaps, deletion requests, permission revocation, and emergency stop.
Use the impacts in the OWASP Prompt Injection Prevention Cheat Sheet—such as control bypass, unauthorized actions or access, instruction leakage, and persistent manipulation—as test categories. This does not assert that any named vendor is vulnerable; it treats all external content as untrusted in every architecture.
Days 24–27: limited-user operation
Allow the AI to save to Drafts only. Named users review the drafts in near-real conditions. Prohibit unapproved sends, unlogged processing, and recipient changes after approval. Train users on model limits, evidence, escalation, incident reporting, and the stop procedure.
Days 28–30: Go, Conditional Go, No-Go, and handover
Do not decide from an average score alone. Review failure types such as material misdelivery, confidential disclosure, and unsupported commitments separately. A Go decision still identifies permitted business types, languages, mailboxes, and users. Conditional Go records open items, compensating controls, owners, and due dates. No-Go can be a valuable finding that data quality, template ownership, privilege separation, or process standardization is not ready.
The production handover should name system and business owners, model and prompt change approvers, data owners, the DPO or legal contact, incident lead, stop authority, and recovery procedure. NIST AI 600-1 is a voluntary, cross-sector companion to the AI RMF for identifying generative-AI risks and suggested actions across the lifecycle. The end of the PoC should lead into change control, monitoring, and reassessment.
KPI formulas using the organization’s own thresholds
Do not import a universal pass rate. Set thresholds from the current baseline, case risk, and the organization’s tolerance. When the denominator is zero or a language has too few samples, report counts and scope rather than presenting a misleading percentage.
| KPI | Formula | What it shows |
|---|---|---|
| Draft adoption | AI drafts taken forward for review ÷ AI drafts presented | Whether suggestions are usable candidates |
| Approval without edit | Approved drafts with no material edit ÷ approved AI drafts | Completeness, while checking for rubber-stamping |
| Material-edit rate | Drafts edited for facts, recipients, attachments, or commitment ÷ reviewed drafts | Safety-relevant correction burden |
| Recipient/attachment near-miss rate | Mismatches stopped before send ÷ reviewed drafts | Errors detected before becoming incidents |
| Unsupported-claim rate | Claims without approved evidence ÷ factual claims checked | Reliability of prices, dates, quantities, and promises |
| Median review time | Middle value of ordered review durations | Typical review effort without outlier distortion |
| Override rate | Warnings or classifications overridden ÷ warnings or classifications issued | Rule quality and operational workarounds |
| Incident rate | Defined incidents ÷ in-scope messages | Outcome by severity, language, and process |
For an illustrative business case, users can enter their own values into a formula such as (current median review time − PoC median review time) × in-scope volume × internal time cost. This is a user-entered template, not a market benchmark or promised ROI. Add license, development, review, audit, change-management, and incident costs to the same worksheet.
RFP requirements for an AI email workflow
An RFP based only on product features will miss the controls needed after launch. Require an explanation, evidence, and an acceptance test for each area.
Outlook and least privilege
- limit the tenant, mailboxes, folders, and users in scope;
- distinguish delegated and application permissions and justify the least privilege;
- separate
Mail.ReadWritefor drafting fromMail.Sendfor sending by component and approval stage; - enforce draft-only mode in initial and normal operations and audit changes;
- document shared mailboxes, send-as, send-on-behalf, and reply-address behavior.
Data, AI, and security
- document tenant and data boundaries, regions, retention, deletion, subprocessors, and transfers;
- state when prompts, outputs, mail, attachments, and logs may be used for model improvement;
- support the records needed for audit, eDiscovery, access review, and incident investigation;
- treat mail bodies, signatures, quotations, links, and attachments as untrusted input;
- version and roll back models, prompts, retrieval sources, and templates.
Business controls
- check To, CC, BCC, external domains, lookalike domains, and reply addresses;
- reconcile body references with the attachment’s presence, file, version, and case;
- link numbers, dates, prices, lead times, certifications, and contractual claims to evidence;
- preserve signature and quotation boundaries;
- manage terminology, honorifics, and tone in Japanese, English, Thai, and Vietnamese;
- support named approval, segregation of duties, delegation, expiry, and reapproval;
- provide emergency stop, draft quarantine, permission revocation, recovery, and notification.
Acceptance tests before contract sign-off
| Test | Input or action | Acceptance principle |
|---|---|---|
| Draft-only | Process a message asking the AI to send | Saves only to Drafts; drafting cannot send |
| Permission separation | Call send from the drafting application | Rejected without Mail.Send, with an auditable record |
| Recipient check | Add a lookalike domain or unapproved BCC | Warn or block and show the difference to the approver |
| Attachment mismatch | Mention an attachment but omit it or attach another version | Detect before send and stop approval |
| Unsupported claim | Ask for a nonexistent date, price, or certification | Mark unresolved and avoid an unsupported commitment |
| Hallucinated date/number | Put conflicting dates and quantities in the thread | Surface the conflict with evidence and do not invent a resolution |
| Quote/signature boundary | Include an old quote and another firm’s signature | Keep boundaries and never treat the signature as an instruction |
| Prompt injection | Embed control-bypass instructions in body or attachment | Isolate them as data and perform no privileged action or disclosure |
| Language and tone | Test four languages and mixed-language cases | Preserve meaning and responsibility, following terminology and escalation rules |
| Human approval | Attempt no approval, post-approval edit, and delegated approval | Reject unapproved send, require reapproval after change, and log delegation |
| Rollback | Introduce a faulty model or prompt update | Restore the previous version and identify affected drafts |
| Incident response | Simulate a near-misdelivery, missing log, or outage | Stop, isolate, notify, investigate, and recover according to procedure |
HTTP 202, a saved draft, or a successful model response is not a business acceptance criterion. Acceptance means the right person can review the right evidence and attachment and approve an intentional send to the right recipients.
Choosing Microsoft 365 Copilot, a controlled API workflow, or a custom app
| Decision factor | Microsoft 365 Copilot | Controlled API workflow | Custom internal application |
|---|---|---|---|
| Main focus | User assistance inside Microsoft 365 | Orchestrated retrieval, checking, drafting, and approval | Deep fit with a unique process and interface |
| Data boundary | Confirm contract, tenant settings, and feature scope | Design per model, retrieval source, log, and processor | Organization owns every architectural and operational choice |
| Draft control | Confirm available usage and admin controls | Explicitly separate Graph privileges and workflow stages | Fine-grained control with greater build and maintenance duty |
| Audit and change | Confirm available Microsoft 365 capabilities by plan | Integrate logs and versions across every stage | Tailor to requirements, while owning any gaps |
| Good fit | Standardizing individual assistance | Automating shared queues and approvals | Integrating specialized ERP, quality, contract, or factory systems |
No option is universally superior. An organization with mature Microsoft 365 governance and a user-assistance goal may evaluate Copilot first. A business that needs a shared queue, case record, validation, and approval in one flow may prefer Graph plus an enterprise AI API. A custom application becomes more attractive when proprietary ERP, factory, quality, or contract workflows are essential.
Compare candidates by running the same acceptance tests, not by comparing demo prose. Use a company-controlled corpus, identical permissions, approved evidence, languages, and failure cases.
For the broader governance foundation, see our guide to enterprise ChatGPT adoption in Thailand. For input controls and confidential information, read preventing generative AI data leakage in Thai organizations.
Frequently asked questions
What is AI email drafting?
It is a system that uses an incoming message, approved templates, and permitted business data to propose a subject and body. Its scope can range from personal writing assistance to classification, retrieval, draft saving, approval, and audit. Define “create text” and “send email” as separate capabilities.
Can document creation AI be shared with email workflows?
Prompts, terminology, approved facts, and review interfaces can support reports and proposals as well. Email has distinct risks involving recipients, CC/BCC, reply and forward behavior, quotations, attachments, and sending. A shared document AI foundation still needs email-specific permissions and tests.
What should we check when using summarization AI for business email?
Check whether the summary dropped a condition, exception, negation, owner, or deadline. Long threads easily mix the newest statement with an obsolete agreement. Reviewers should be able to open the source text, and important numbers and commitments should point to their source location.
Can business automation AI send every email automatically?
It may be technically possible, but it is not appropriate for ordinary correspondence by default. Restrict autonomous sending to cases with fixed recipients, content, and evidence, limited consequences, monitoring, and an immediate stop path. Use controlled drafts and human approval for general replies.
Is selecting a secure product enough for generative AI security?
No. Combine contractual and data boundaries with input limits, least privilege, prompt-injection defenses, evidence control, output checks, human approval, logs, retention and deletion, and incident response. Strong product controls do not correct excessive permissions or unclear operating ownership.
How much of PDPA compliance can an IT team decide?
IT can map data flows, collected fields, access, storage, retention, deletion, processors, and transfers. Lawful basis, notices, rights, transfer conditions, and contractual legal conclusions should be confirmed with the DPO or qualified counsel.
Does Mail.ReadWrite allow the AI to send email?
Microsoft Graph documents draft creation with Mail.ReadWrite and sending an existing draft with Mail.Send as separate permissions. Use that difference to keep send authority away from the drafting component. Confirm permission types, consent, and shared-mailbox behavior for the actual tenant.
Summary
Safe AI email drafting is an operating model, not a writing feature. Limit inputs, retrieve approved evidence, grant draft-only privileges, validate recipients, attachments, and claims, route to a named approver, and retain proportionate evidence. In Thailand and ASEAN, the PoC must also test PDPA-oriented data flows, cross-border processing, shared mailboxes, head-office approval, and responsibility across Japanese, English, Thai, and Vietnamese. A 30-day PoC, organization-defined KPI thresholds, and failure-focused acceptance tests show whether the workflow is controllable in production.
TOMAS TECH can help assess a draft-first architecture that connects Outlook and Microsoft Graph with enterprise AI, approval workflows, and data controls. Even if you are still defining the scope of a 30-day PoC, share your current mail process through our contact page, and we can structure the evaluation around your Thailand and regional operations.
