AI Risk Readiness · Regulation

AI Risk Is Not a New Rulebook: What Your Existing Rules Already Require

A worked example from banking: the Bank of Thailand’s rules, clause by clause

Ask almost any regulated organisation whether it needs new rules for AI risk, and most people will say yes, or that they are waiting for them. Take banking, the most detailed written case. BOT’s AI guideline is written in “should” and sets no date, so it is easy to conclude that nothing is required yet. The binding IT risk notification says otherwise: it already asks the bank to know what it depends on, to manage the providers behind it, and to plan for their failure, including a worst-case outage on public cloud. AI fits inside all three. This chapter sets the two texts side by side, then shows where the same records sit in other regulated sectors.

Last reviewed against the regulators’ texts on 10 November 2026. Rules change; check the Sources at the end before you act on this chapter.
Infozense · 10 November 2026 · CIO · CISO · CRO · Chief Audit Executive · ~9 minutes

This series asks three questions of any organisation that uses AI: what AI do you depend on, what happens to your business when it fails, and can you show the answer to your risk committee and your auditor. Chapter 1 starts where a CRO starts: with the rules the organisation is already examined on.

Why this matters. Picture a bank whose customer-service assistant runs on a single external AI provider. Suppose that provider is unavailable in every region the bank uses, for a full business day. That day nobody asks what the AI guideline says. They ask whether the BCP for that service has this scenario.

For critical IT systems on public cloud, BOT’s IT risk notification already asks for that plan. Whether an LLM API counts as public cloud is each bank’s call. If the bank’s answer is yes, the plan has to exist before any outage.

Thailand has no AI-specific law in force. What exists is AI guidance from sector regulators, written in “should”: the Bank of Thailand’s for banks (September 2025), the OIC’s for insurers (November 2025) and the SEC’s framework for the capital market (August 2026). This chapter takes the banking case, because banks’ binding IT rules are written in the most detail, which makes the method easiest to see. The BOT document is its policy guideline on managing the risk of using AI, ธปท. ว. 5994/2568, issued on 12 September 2025.

It covers board accountability, data quality, model monitoring, hallucination, and AI-specific cyber threats. Every requirement in it is written with “ควร”, should. It sets no effective date. It does not ask for an AI register, and it does not address what happens when an AI provider fails.

So the common conclusion is that a Thai bank has nothing binding to do about AI risk yet, and no deadline. Stop at the AI guideline and that conclusion holds. It falls apart as soon as you read the rules the bank is actually examined on.

Who this is for

This chapter is written for the CIO, CDO, CISO or DPO of any regulated organisation in Thailand that uses AI, and for the CRO and chief audit executive who will read the result. That includes banks, insurers, securities firms, payment firms and critical information infrastructure organisations.

Whatever your sector, the check is the same: find the records your own rules already require, then see whether those records include the AI you use. The clauses in this chapter are BOT’s because banking is the worked example; read them for the method, not the numbers. Insurers and critical information infrastructure organisations keep the same three kinds of record under their own rules: an IT asset register, controls over outside providers, and a continuity plan. In some other sectors we found no sector rule, so start from the records your organisation keeps as normal practice. The section Other regulated sectors, near the end, shows which applies to you.

Two kinds of document

In the banking case, two documents matter, and they carry different weight: BOT’s AI guideline, written in “should”, and the binding IT risk notification the bank is examined on. Whatever your sector, sort your own documents the same way: an AI guideline written in “should”, if your regulator has issued one, and the binding rules you are already examined on. Mixing them up is the most common mistake in this conversation.

  • BOT’s AI guideline (ว. 5994/2568). A policy guideline written in “should”, with no effective date. Section 2 says it adds to the existing IT risk rules, the third-party risk guideline, the data governance policy and the market conduct rules. It does not replace any of them.
  • BOT’s IT risk notification (สกช. 5/2566) and its two attached guidelines. The notification is binding: clause 7 says institutions have a duty to comply. Its attachment 2 sets IT asset management, third-party, concentration and continuity duties, and the bank already sends BOT an annual IT risk self-assessment. The attached third-party risk management guideline (TPRM) is written in “should” and applied by risk level.

The useful question is not which of the two applies. For a Thai bank, both do. The useful question is what the binding rules already require that a reader of the AI guideline alone would miss.

The two texts side by side

The figure below sets the two BOT texts against the themes this chapter discusses. A filled marker means the text states an explicit expectation. A half marker means it is covered partly, or only through a general rule that is not written for AI. An empty marker means the text does not address it. The labels are short summaries, not quotations; the English labels are our translation of the Thai texts. Clause numbers point to the originals.

A table comparing two Bank of Thailand texts across nine themes, with a filled, half or empty marker in each cell. Columns: the AI guideline, written as should; and the binding IT risk notification with its third-party guideline. Board accountability: AI guideline explicit; IT notification partly, through the bank's own materiality criteria. Inventory or register: AI guideline not addressed; IT notification explicit, through the IT asset register and the third-party register. Risk tiering: both partly. Data and PDPA: AI guideline explicit; IT notification partly. Monitoring and change: AI guideline explicit; IT notification partly, through notice of major IT change. Third parties, concentration and exit: AI guideline partly; IT notification explicit. Contingency: AI guideline not addressed; IT notification explicit, including an all-region outage plan for critical IT systems on public cloud. Incident reporting: AI guideline not addressed; IT notification explicit. Dates: AI guideline none; IT notification an annual self-assessment. Where the AI guideline is silent on inventory, contingency and incident reporting, the row is highlighted: not in the AI guideline, required by the IT risk notification. A timeline along the bottom: 2023, the binding IT risk notification; 2025, the AI guideline, which adds to the IT risk rules; today, both apply. Whether an LLM API counts as public cloud is each bank's interpretation. ตารางเปรียบเทียบเกณฑ์ของธนาคารแห่งประเทศไทยสองฉบับใน 9 หัวข้อ แต่ละช่องมีเครื่องหมายเต็ม ครึ่ง หรือว่าง คอลัมน์แรกคือแนวนโยบาย AI ซึ่งใช้ถ้อยคำ “ควร” คอลัมน์ที่สองคือประกาศความเสี่ยงด้าน IT ที่มีผลผูกพันพร้อมแนวปฏิบัติด้านบุคคลภายนอก การกำกับดูแลโดยคณะกรรมการ: แนวนโยบาย AI ระบุชัดเจน ประกาศระบุบางส่วนผ่านเกณฑ์จัดระดับความสำคัญของธนาคาร ทะเบียน: แนวนโยบาย AI ไม่ได้กล่าวถึง ประกาศระบุชัดเจนผ่านทะเบียนทรัพย์สินด้าน IT และทะเบียนบุคคลภายนอก การจัดระดับความเสี่ยง: ทั้งสองฉบับระบุบางส่วน ข้อมูลและ PDPA: แนวนโยบาย AI ระบุชัดเจน ประกาศระบุบางส่วน การติดตามผลและการเปลี่ยนแปลง: แนวนโยบาย AI ระบุชัดเจน ประกาศระบุบางส่วนผ่านการแจ้งการเปลี่ยนแปลง IT ที่สำคัญ บุคคลภายนอก การกระจุกตัว และการยุติบริการ: แนวนโยบาย AI ระบุบางส่วน ประกาศระบุชัดเจน แผนสำรอง: แนวนโยบาย AI ไม่ได้กล่าวถึง ประกาศระบุชัดเจน รวมถึงแผนรองรับกรณีทุก region หยุดชะงักสำหรับระบบงานสำคัญบนคลาวด์สาธารณะ การรายงานเหตุการณ์: แนวนโยบาย AI ไม่ได้กล่าวถึง ประกาศระบุชัดเจน กรอบเวลา: แนวนโยบาย AI ไม่ระบุ ประกาศกำหนดการประเมินตนเองทุกปี การนับ LLM API เป็นบริการคลาวด์สาธารณะหรือไม่ เป็นการวินิจฉัยของแต่ละธนาคาร แถวที่แนวนโยบาย AI ไม่ได้กล่าวถึงเรื่องทะเบียน แผนสำรอง และการรายงานเหตุการณ์ ถูกเน้นไว้ว่าไม่อยู่ในแนวนโยบาย AI แต่ประกาศด้าน IT กำหนดไว้แล้ว เส้นเวลาด้านล่าง: พ.ศ. 2566 ประกาศความเสี่ยงด้าน IT ที่มีผลผูกพัน พ.ศ. 2568 แนวนโยบาย AI ซึ่งเป็นส่วนเพิ่มเติมจากเกณฑ์ด้าน IT และปัจจุบันใช้ทั้งสองฉบับ

Read the column for the IT risk notification first. That is where the binding duties are, and it is fuller than most people expect. Two findings stand out.

Finding one: the register already exists. It just has no AI in it.

Attachment 2, clause 1 of the IT risk notification requires the bank to keep a register of IT assets that identifies them completely. That is a binding duty.

The TPRM guideline, clause 7.4, expects a register of the third parties the bank uses, connects to, or gives access to its data. That one is written in “should”.

Read plainly, an AI model, an AI agent and an AI feature switched on inside licensed software are IT assets, and an AI provider is a third party. That is our reading, not a BOT statement. The bank’s own asset policy sets how fine-grained the register is. So the question for a bank is not whether it must create an AI register. It is whether the registers it already keeps cover AI completely.

The practical step is therefore small and unglamorous. Add AI rows and an “is this AI” marker to the registers the bank already maintains. Then check how many of them have a named owner.

Finding two: the full-outage plan is already a binding duty. Is your AI inside it?

Attachment 2, clause 10.4 of the IT risk notification requires the bank to prepare for events with serious impact, so that it can keep serving customers and operating.

Clause 10.5.9 goes further for critical IT systems (the notification’s Thai term is ระบบงานเทคโนโลยีสารสนเทศที่มีนัยสำคัญ, literally significant IT systems) that run on public cloud. The bank needs a BCP and an IT disaster recovery plan for worst cases. These include an outage of the provider’s systems in the region the bank uses, and an outage of every region it uses.

Clause 10.2 adds concentration risk and vendor lock-in from relying on any single provider. Clause 7.1 makes the flexibility to change provider a selection criterion.

Now put an LLM API underneath a critical IT system. If that API counts as public cloud computing under attachment 2, clause 10.5, the all-region outage plan is not a future expectation. It is a duty the bank already has.

Whether it counts is a matter of interpretation, and the bank decides it with its own compliance function. The first check does not depend on the answer. Open the BIA and BCP and look for the external AI services behind critical processes. If the bank treats the API as public cloud and they are not there, it cannot claim to meet clause 10.5.9 for those systems. If it does not, clause 10.4 still asks whether the BCP covers an event with serious impact, and a missing dependency is a gap there.

The honest limit

This chapter reads published texts. It is not legal advice, and it does not predict what any regulator will do next.

  • The clauses in the main body are BOT’s. The IT risk notification applies to financial institutions and specialised financial institutions; the AI guideline also covers regulated payment firms. The chapter does not analyse other regulators’ rules clause by clause. Other regulated sectors, near the end, names the records other rules require and where we found none.
  • It does not cover model risk in depth. BOT’s current rules include no rule dedicated to model risk. A bank’s own model risk policy may have been written for risk and credit models. Check whether it reaches generative AI and vendor AI, and whether any model inventory the bank keeps includes them.
  • It does not decide whether an LLM API counts as public cloud under clause 10.5. That is each bank’s call.

If your compliance function reads any of these texts differently, its reading wins for your organisation. This chapter is a starting point for that conversation, not a substitute for it.

The bottom line

No regulated organisation needs a new AI framework or a new committee to start. In the banking case, the bank already keeps an IT asset register, a third-party register, a BIA and a BCP that its rules require or expect. The work is to make those records see the AI the organisation already uses.

The next chapter turns this into eight questions a risk committee can ask management, each answered with a number from one of those records.

Where to start

Take one critical process that uses an external AI service. Find it in the IT asset register, the third-party register, the BIA and the BCP. Write down which of the four records name the AI service, and who owns each row.

If all four do, your registers already see AI and the next chapter will be quick. If some do not, you have found your first gap without buying anything.

Other regulated sectors

The clauses above are BOT’s and bind banks. This is what we found elsewhere, in each regulator’s own texts.

  • Insurers (OIC). The OIC’s IT risk notification for life insurers (2020, in force from 1 January 2021) requires an IT asset register (clause 16 (1)), criteria for selecting outside providers with contracts and service level agreements, monitored regularly (clause 23), and an IT continuity plan with a written disaster recovery plan tested at least once a year (clause 25). We have not read the non-life notification; it is reported to follow the same structure.
  • Critical information infrastructure (NCSA). The NCSA code of practice binds state agencies and CII organisations for their critical services. It requires an asset inventory (21.1.1), keeps accountability with the organisation when work is outsourced (21.4.1 to 21.4.2), and requires a BCP that reviews outside providers’ plans (25.1.1), exercised at least once a year (25.1.2). Services that are not designated critical fall outside it.
  • Capital market (SEC). The SEC’s revised AI governance framework for the capital market (August 2026) recommends that firms record each AI use case in an AI inventory (2.3 and appendix 4). It is guidance, written in “should”.
  • Other sectors. For energy, aviation, ports and listed non-financial companies, we found no sector rule on IT asset registers, third parties or continuity. The base is the NCSA code where the organisation runs a designated critical service, and the Personal Data Protection Act for personal data.

Wherever you sit, run the check from Where to start against the records your own rules name: one critical process, one external AI service, and which records name it. Where no rule names a record, run it against the records your organisation already keeps as normal practice.

Other supervisors reach the same conclusion

This chapter’s conclusion, that AI belongs in records organisations already keep, is not ours alone. These texts say the same in their own terms. We cite them as corroboration, not as rules that apply to you.

  • OIC, AI guideline for insurers (November 2025). It states that it adds to the notifications and guidelines already in force. It asks insurers to assess regularly how far they depend on external AI providers, including concentration risk (1.4.2), and to consider a kill switch, prepare and test a contingency plan, including switching to another system, and prepare an exit plan (1.4.3). It is written mostly in “should”.
  • NCSA code of practice. The asset inventory it requires must record the dependencies between assets (21.1.1 (ฉ)). For a CII organisation, that field is a place to record the external AI service behind a critical service, under a binding duty.
  • MAS, Singapore. Its AI guidelines let a financial institution build its AI inventory by extending registers it already keeps (4.6, footnote 23).
  • EBA, European Union. After mapping the EU AI Act against EU banking law, the EBA found no immediate need for new or revised EBA guidelines, because existing law “already provides a comprehensive framework to manage risks”. The exercise focused on AI used for creditworthiness assessment and credit scoring, and the EBA states that it “does not represent guidance or supervisory expectations”.

Sources

The texts this chapter cites, as each regulator published them on the date of this article. Where this article’s wording differs from the original texts, the originals govern.

  • Bank of Thailand. แนวนโยบาย เรื่อง การบริหารจัดการความเสี่ยงของการใช้งานระบบปัญญาประดิษฐ์ (ว. 5994/2568), 12 September 2025. PDF, Thai
  • Bank of Thailand. ประกาศ ที่ สกช. 5/2566 เรื่อง หลักเกณฑ์การกำกับดูแลความเสี่ยงด้านเทคโนโลยีสารสนเทศ (Information Technology Risk) ของสถาบันการเงินและสถาบันการเงินเฉพาะกิจ, with its attachments and the two attached guidelines (IT risk management; third-party risk management), circular ฝตท.(01) ว. 20/2566, 9 November 2023. PDF, Thai
  • Office of Insurance Commission. ประกาศคณะกรรมการกำกับและส่งเสริมการประกอบธุรกิจประกันภัย เรื่อง หลักเกณฑ์การกำกับดูแลและบริหารจัดการความเสี่ยงด้านเทคโนโลยีสารสนเทศของบริษัทประกันชีวิต พ.ศ. 2563, in force 1 January 2021. PDF, Thai
  • Office of Insurance Commission. แนวปฏิบัติ เรื่อง การกำกับดูแลการใช้งานปัญญาประดิษฐ์ สำหรับบริษัทประกันภัย (AI Governance Guideline), November 2025. PDF, Thai
  • National Cyber Security Committee. ประกาศคณะกรรมการกำกับดูแลด้านความมั่นคงปลอดภัยไซเบอร์ เรื่อง ประมวลแนวทางปฏิบัติและกรอบมาตรฐานด้านการรักษาความมั่นคงปลอดภัยไซเบอร์ สำหรับหน่วยงานของรัฐและหน่วยงานโครงสร้างพื้นฐานสำคัญทางสารสนเทศ พ.ศ. 2564, Royal Gazette, 6 September 2021. PDF, Thai
  • Securities and Exchange Commission, Thailand. กรอบการกำกับดูแลการใช้งานปัญญาประดิษฐ์ในภาคตลาดทุน ฉบับปรับปรุงครั้งที่ 1 (AI Governance Framework and Handbook, 1st Revised Edition), August 2026. PDF, Thai
  • พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (Personal Data Protection Act B.E. 2562). PDF, Thai
  • Monetary Authority of Singapore. Guidelines on Artificial Intelligence Risk Management, 7 October 2026. PDF, English
  • European Banking Authority. AI Act implications for the EU banking sector (factsheet on the EBA’s AI Act mapping exercise), November 2025. PDF, English

This article is general information about regulatory texts as published on the review date above. It is not legal, regulatory or compliance advice, and reading it does not create a client relationship. Each organisation must read the original texts and decide how they apply, with its own compliance function and advisers. INFOZENSE accepts no liability for decisions made on the basis of this article.

AI Risk Readiness

Do your registers see the AI you already use?

Bring one critical process. We will go through which of your existing records name the AI behind it, and which do not, under the rules that apply to you.

Let's talk →

Read about AI Risk Readiness →

contact@infozense.com  |  +66-82-242-4008  |  Bangkok, Thailand