Internal Policy Search AI: A Safe Design for Thailand Operations

“Which version of the work rules is current?” “How many days in advance must leave be requested?” “Do the allowance conditions differ for expatriates and Thai staff?” An internal policy search AI can answer repetitive questions and make a clear business case for generative AI. Yet loading a folder of PDFs and obtaining fluent answers is not a production design. The real requirements are which version is searched, as of what date, under whose permissions, with what evidence, and where the answer returns to a human approver. This guide turns those requirements into an RFP, PoC and acceptance-test plan for Thailand and ASEAN operations.

Treat policy search AI as navigation, not an authority

The system’s job is to locate relevant passages in valid documents the user is allowed to read, then return an answer draft with evidence. It is not there to invent an exception or make an employment decision.

“When is a leave request due?” is a document-retrieval question. “Should we approve this late request because of the employee’s family circumstances?” is an approval decision. A single chat interface may receive both, but its behavior must differ: cite the rule for the first and hand the second to the named owner.

For the general RAG mechanism, multilingual search and cost layers, see RAG Implementation for Factories. For channel, language and rollout choices, see Chatbot Implementation Cost and Rollout. This article focuses on controlled documents, where a stale version or permission leak matters.

Why ordinary full-text search is not enough

Full-text search works when the query and document share the same terms. In a Thai operation, a worker may ask in Thai, while the governing policy is English and an explanatory notice is Japanese. Semantic retrieval and generated explanations help with paraphrases and cross-language questions.

Fluency also creates risk. A model may fill gaps with plausible wording. Therefore “natural conversation” is not an acceptance criterion by itself. Test whether the correct document was retrieved, expired versions were excluded, restricted content remained invisible, the citation supports the answer, and the response was correct.

Most failures begin in document state, not the model

A PoC can answer ten showcase questions and still be unsafe. Demonstrations usually use clean PDFs and obvious clauses. Production contains old and new policies in the same folder, temporary plant notices, exceptions in table footnotes and Thai scans with poor OCR.

Manage every document as a controlled record

At minimum, attach the following metadata.

A folder called “latest” is not metadata. If it contains three files named policy_final_v2_revised.pdf, neither a person nor AI can determine authority reliably. The DMS or SharePoint library should remain the source of truth; the search index is a derived view that follows it.

Show the answer date

The correct answer can change over time. Show “As of 2 September 2026” and “Based on HR-LEAVE-001 Rev.4, effective 1 July 2026.” If historical search is supported, separate it visibly from current search.

Logs should record the question time, document ID and revision, retrieved passages, index refresh time, and answer-service version. When a policy changes, this distinguishes an answer that was correct at the time from a genuine system error.

Build knowledge search AI around pre-retrieval authorization

A safe architecture separates authentication, authorization, retrieval, generation and audit. After login, the identity layer supplies only the attributes or groups needed—entity, site, department, employment class and role. Retrieval selects authorized documents first. Only those passages reach the model.

Searching everything and hiding later is too late

Do not search the entire repository and redact the final prose. Once restricted content reaches the model, it may appear in output, traces, logs or caches. Authorization belongs before or within retrieval.

Microsoft’s official documentation, current in August 2026, describes security-filter patterns that match user or group principals against document permissions. It also labels native ACL/RBAC and Purview approaches in the 2026-08-01-preview API as preview functionality and warns that external permission changes may take time to propagate. The lesson is not that one product is automatically safe. For any stack, specify the permission source, synchronization interval, failure mode and evidence.

OWASP LLM08:2025 identifies unauthorized access, cross-context leakage and poisoning risks in RAG and recommends permission-aware vector stores, source validation, classification and monitoring. Embeddings are not harmless anonymous numbers; govern them with the source content.

Acceptance conditions for security trimming

An RFP should require:

1. An unauthorized document never appears in candidates, citations, summaries or conversation history.
2. Transfers and group removals propagate within an agreed time.
3. If identity or permission lookup fails, retrieval returns zero results or a safe error—not all documents.
4. Administrator debugging is separate from ordinary use and fully audited.
5. Deleting a source also removes its chunks, embeddings, caches and governed logs.

Replace “near real time” with measurable language such as “within 15 minutes of the directory change,” “zero results on authorization failure,” and “immediate denial for a disabled account.”

Design citations around revision and passage, not just a link

A link to page one of a forty-page work rule does not let an employee verify the answer. Return title, document ID, revision, effective date, clause or page, supporting excerpt and persistent source link.

Measure retrieval, grounding and final answer separately

If the correct policy was retrieved but the answer is wrong, inspect prompt and context construction. If retrieval missed, fix chunks, metadata, OCR, query translation or ranking. Changing models without this diagnosis repeats the same defect at a higher price.

“I cannot determine that” can be a successful result

If no accessible policy states a special bonus for three years’ service, the safe answer is: “I cannot confirm this in the valid documents available to you; please contact HR.” Test absent answers, missing conditions and conflicting rules—not only answerable questions. Score three valid outcomes: answer, ask a clarifying question, or escalate.

Set the approval boundary for an employee-rules chatbot

Information and decision-making must remain distinct.

Queries about discipline, health, unions, evaluations or dismissal can make the log sensitive even when the policy document is not. Do not keep full conversations indefinitely “for improvement.” Define purpose, viewers, retention, masking and deletion.

Separate the authoritative text from the explanation language

Thai users may query Japanese or English policies. Display the source language, explanation language, and whether the translation is informational. A generated translation must not appear more authoritative than the approved original.

Maintain an approved glossary for terms such as probation, severance pay and working day. HR or local counsel should approve legally meaningful Thai equivalents; the model should not improvise them.

Thailand PDPA is a data-flow question, not merely a cloud question

Thailand’s Personal Data Protection Act covers information that can identify a person directly or indirectly. A generic work rule may look non-personal, yet an appendix may list names, an employee may type health or family circumstances, and logs may bind employee IDs to sensitive questions.

Map the complete flow:

1. Where documents originate.
2. Where OCR, embeddings, indexing and inference occur.
3. Who can view queries, responses, feedback and audit logs, and when they are deleted.
4. What processors and subprocessors handle.
5. Whether any model/service-improvement setting uses the data.

The lawful basis, notice, processor terms, overseas transfer, retention and data-subject rights must be assessed against the real design by the DPO or Thai legal adviser. This article does not certify any architecture as PDPA-compliant.

ETDA’s August 2024 Generative AI Governance Guideline for Organizations covers benefits, limitations, risks, implementation and governance as one lifecycle. On 1 July 2026, ETDA further emphasized evaluation, testing, audit and continual improvement. For policy search, that means converting governance from a memo into leakage tests, error review and measured revision-refresh time.

Turn the PoC from an answer demo into acceptance testing

A PoC should reduce uncertainty in a controlled scope, not produce a video of ten correct answers. Fix the departments, documents, users, languages and excluded decisions, then agree pass/fail criteria before implementation.

Build a representative test set

Include:

• simple questions explicitly answered in the current revision;
• multi-condition questions;
• tables, footnotes and annexes;
• Thai questions against Japanese documents;
• questions whose answer differs in the old revision;
• permission-positive and permission-negative pairs;
• questions with no answer;
• requests that require human judgment;
• abbreviations, typos and paraphrases;
• prompt-injection text embedded in a document.

For every question, predefine the expected document/revision, acceptable answer, prohibited answer, needed clarification and escalation owner. This becomes the gold set.

Example acceptance metrics

These figures are an illustrative design for a 100-question PoC, not an industry standard.

An overall 95% can hide five dangerous failures. Weight severity; make critical errors and permission leaks zero-tolerance.

Translate NIST’s lifecycle into evidence

NIST AI 600-1 is a voluntary cross-sector GenAI risk profile, not Thai law. It is useful as an operating structure:

• Govern: owners, prohibited uses, approvers and change control.
• Map: users, affected people, documents, data flows and consequences.
• Measure: answer, evidence, authorization, refusal, latency and language performance.
• Manage: prioritize by severity and define stop, fix and retest procedures.

Putting “NIST-aligned” in an RFP is insufficient. Ask who reviews which evidence and when.

What to require in the RFP

“Accuracy above 90%” is not comparable without population, scoring method, language and difficulty. Require reproducible results on your own set. If a proposal depends on preview features, require a fallback, change-cost assumptions and permission-sync limitations.

An eight-week PoC and a transparent cost model

The following example assumes one site, three languages, 300 policy files and 50 users. It is not a TOMAS TECH price list or market statistic. OCR quality, DMS APIs, identity integration and document cleanliness will change it.

To avoid presenting a fictional market price, compare proposals with a percentage allocation where the total budget equals 100: document preparation/OCR 15%, retrieval/answer prototype 35%, identity and permissions 20%, test design/execution 20%, and operations/training 10%. This is a completeness model, not a price benchmark. It assumes an existing DMS API, no specialist handwriting OCR and no core-system writeback.

Clean documents reduce preparation. Complex exception groups, permissions composed from several systems, or historical search increase authorization and testing. Ask vendors to state document count, language count, permission-pattern count, gold-set size and retest cycles as quantities so changes remain traceable. LLM token price alone does not determine project cost.

Production operations: retest whenever controlled inputs change

Policies, organization structures, permissions, models and search services change. Define regression scope for each change.

1. The policy owner approves the source and records effective/expiry dates.
2. Ingestion refreshes the index and validates count, failures and permissions.
3. Automated tests check representative questions and ensure old revisions do not return.
4. HR reviews critical answers before release.
5. Review no-answer, low-rating and escalation logs; separate missing content from retrieval defects.
6. Re-run the same gold set after model or embedding changes.

Do not use adoption alone as the KPI. Track self-service resolution, escalation categories, evidence-opening rate, zero stale answers, zero permission incidents and revision-refresh SLA.

Define RACI for every controlled revision

The policy custodian is Responsible for DMS registration and metadata; the department head is Accountable for approving the revision’s entry into force; labor, legal and information security are Consulted; the help desk and user departments are Informed. The search operator must reproduce an approved state but must not approve policy meaning. Emergency notices need a separate path with mandatory validity dates, site, superseded document ID and approver, plus an alert if automatic expiry would leave no valid source.

Derive audit logs from purpose, not maximum retention

Audit logs should be derived from purpose, not from a desire to retain everything. Separate access events, quality samples and incident detail. A routine event can contain pseudonymous user ID, time, document/revision, allow/deny result and correlation ID without the full sensitive question. If quality review needs full text, set a period and sample rate, mask sensitive terms and restrict reviewers.

Rehearse a policy revision before go-live

Before go-live, rehearse a fictitious Rev.4-to-Rev.5 change: pre-effective, post-effective, historical lookup, permission change and withdrawal. Measure DMS-to-index time, exclusion of the old version from current answers, correct historical behavior, citation switch and rollback. Include this evidence in the production decision.

FAQ

How is internal policy search AI different from enterprise search?

Enterprise search mainly returns documents. Policy search AI can handle paraphrases and languages and explain a relevant passage. Because it generates prose, it also needs citation, revision, effective date, refusal and escalation controls.

Does knowledge search AI eliminate wrong answers?

No. RAG can ground answers in internal documents, but retrieval errors, stale versions, OCR defects, conflicts and generation mistakes remain. Measure retrieval, grounding and answer separately.

Can an employee-rules chatbot comply with Thailand PDPA?

The product name cannot answer that. Assess where personal data appears in documents, queries, answers, IDs and logs; then review purpose, lawful basis, notice, processors, location, retention and rights with the DPO or Thai counsel.

Can generative document search preserve department permissions?

Yes, with design and testing. Match user principals to document permissions before retrieval. Test sync delay, transfers, termination, lookup failure and administrative access, and confirm fail-closed behavior.

How many files justify RAG?

File count alone is insufficient. Consider volume, refresh frequency, permissions, languages, latency and citation requirements. A small stable set may be simpler as curated FAQ or fixed context.

How should we decide whether a PoC passed?

Agree retrieval, citation, critical-error, leakage, refusal, refresh and latency thresholds in advance. Use old-version, no-permission, no-answer, cross-language and human-judgment cases—not only showcase questions.

Conclusion: six decisions before requesting proposals

Decide: the authoritative document/revision; the answer date; who may retrieve what; the citation granularity; what AI may answer versus escalate; and which negative tests determine acceptance. Then the RFP compares governable operating designs, not fluent demos.

TOMAS TECH can help Thailand operations inventory multilingual policies, map permissions, build the PoC gold set and turn acceptance conditions into an RFP before product selection. If you are still defining scope, share the approximate document count, languages and user groups through our contact form.

References

• Thailand Royal Gazette, Personal Data Protection Act B.E. 2562 (2019): https://ratchakitcha.soc.go.th/documents/17082307.pdf
• ETDA, Generative AI Governance Guideline for Organizations (August 2024): https://www.etda.or.th/getattachment/6050a4b7-defd-4dba-8cbc-ff6a444a3d08/20240910_GenerativeAIGovernanceGuideline_Vol1_AIGC.pdf.aspx
• ETDA, AI Governance is a condition for using AI today (1 July 2026): https://www.etda.or.th/th/pr-news/Future_AiGov.aspx
• NIST AI 600-1 (published 26 July 2024; page updated 8 April 2026): https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence
• OWASP LLM08:2025: https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/
• Microsoft Learn, Document-Level Access Control (accessed 2 September 2026; preview caveats apply): https://learn.microsoft.com/en-us/azure/search/search-document-level-access-overview
• Microsoft Learn, Security Filter Pattern (updated 24 August 2026): https://learn.microsoft.com/en-us/azure/search/search-security-trimming-for-azure-search

This article reflects public information available on 2 September 2026 and is general technical and operational guidance, not legal advice.