A risk committee that asks "are we managing AI risk?" will hear yes. The answer is honest and it proves nothing. A committee that asks how many AI components sit in the IT asset register, and how many have a named owner, gets a number or a silence. Both are useful. This chapter gives questions of the second kind. Each points to a record a regulated organisation already keeps, and to the evidence that answers it.
Chapter 1 showed that the rules an organisation is already examined on ask it to know what it depends on, to manage the providers behind it, and to plan for their failure, and that the AI it uses belongs inside those duties. This chapter turns that into questions a committee can ask and the evidence that answers each one. It ends with five questions you can answer yourself today.
Why this matters. Ask management one question: if our main AI provider were unavailable tomorrow, which of our processes would stop? An organisation that records its AI dependencies answers from the record, in minutes. One that does not starts making phone calls, and the answer it reaches by the afternoon is a guess.
A risk committee does not want to discover which kind of organisation it oversees during an outage. These questions let it find out on an ordinary Tuesday.
Risk committees are good at asking about credit, liquidity and operational loss. They have practice, and they know what a good answer looks like.
AI is newer. The questions tend to come out general: do we have a policy, is someone responsible, are we compliant. Each of these invites a confident yes, and none of them can be checked.
The fix is not more questions. It is a different kind of question: one that can only be answered with a number, taken from a record that already exists.
Members of the risk committee or audit committee of any regulated organisation in Thailand that uses AI, the CRO and chief audit executive who brief them, and the CIO or CDO who will be asked to answer.
The clause references are BOT’s, because banking is the worked example, as in Chapter 1. The questions themselves work for any organisation that keeps an IT asset register, a register of outside providers, a BIA and a BCP. Chapter 1’s section Other regulated sectors shows where insurers and critical information infrastructure organisations find the same records under their own rules.
Answers to a governance question sit on four rungs. Only the top rung answers a committee question.
Each question below asks for a number from a record. If management cannot give the number, the committee has not received a bad answer. It has received the finding.
Most of the questions follow the thread of Chapter 1: what AI the organisation depends on, and what happens when it changes or fails. Three reach further: personal data (question 5), what AI agents can do without a person (question 7) and customer complaints (question 10). They are less about continuity, but a committee that oversees AI risk has to be able to answer them too.
Why it matters. Most regulated organisations must keep an IT asset register, and the AI they run is part of their IT. Read plainly, a model and an agent are IT assets; that is our reading, not a regulator’s statement. In practice the register often lists the application that uses AI, not the model or agent behind it, and banks may keep in-house models in a separate model inventory. If the count is zero, the register is likely incomplete, or it records AI only at the level of the application; ask which. Two separate counts matter because they fail differently: a model can be wrong, an agent can act. Owners matter because an unowned row has nobody to switch it off. The keys these services use are counted in question 7. Banking example: BOT’s IT risk notification makes the register binding and requires it to identify IT assets completely (attachment 2, clause 1).
Evidence that answers it. The register extract, and the model inventory where one exists, filtered to AI, with owner and last-updated date per row. Then sample two rows and trace each one to the running system.
Why it matters. This is the most common way AI arrives without a purchase order. A vendor adds an AI feature to the office suite, the CRM or the service desk. An administrator switches it on, and the organisation’s data starts reaching a model through a contract nobody re-read. A later chapter in this series covers this route, AI that arrives inside licensed software, in detail.
Evidence that answers it. For each licensed service, a dated export of the AI feature settings and AI add-on licences from its admin console, set against the register. The console shows the current state only, so the export date matters.
Why it matters. An approved-tools list only works if someone checks it against use. Naming the report matters as much as the count. "We block it" is a claim. A block report is evidence.
Evidence that answers it. A web proxy, DNS, firewall or cloud access security report for known generative AI domains, counted by service and by department, not by named employee. Smaller organisations may not be able to split by department; say so rather than estimate.
Why it matters. Every regulated organisation has some way of deciding which systems and changes matter most: a criticality rating, a materiality rating, a list of critical services. Those ratings decide which controls, approvals and reports apply. In practice they are applied to systems, so an AI use case is usually rated through the application it runs on; a use case that sits in no rated system was never tested against any of them. The risk register or self-assessment is the second check. It is kept by process, not by use case, so the question is whether the process risk names the AI at all. If it does not, the AI risk sits outside the risk management the board relies on. Banking example: under clause 9 of BOT’s IT risk notification, each bank sets its own materiality criteria, approved by a committee the board delegates and reviewed every year. Those criteria decide whether a change needs advance notice to BOT (commercial banks, clause 10.1.1) or BOT’s permission (specialised financial institutions, clause 10.1.2).
Evidence that answers it. The approved rating criteria with their last review, the list of AI use cases with the rated system each runs on, and the risk register or self-assessment entries that name the AI, with owner and last review date.
Why it matters. For most risk committees, where personal data goes is the first question about AI, and the Personal Data Protection Act applies in every sector. An AI service that receives personal data but is missing from the record of processing is a gap the data protection officer will recognise at once. The record of processing usually names the software, not the AI feature inside it, and it does not hold contract terms: location, retention and training use sit in the data processing agreement or the contract, kept by legal or procurement. The training-use term matters because it decides whether the data stays inside the service the organisation bought. Banking example: BOT’s AI guideline expects access control, masking and similar safeguards for personal data used with AI (ส่วนที่ 2 (1.3)), and states that providers must comply with personal data protection law (Q&A 4).
Evidence that answers it. The record of processing filtered to AI services, and for each one the data processing agreement or contract clause that states the processing location, the retention period and the training-use term, with its date.
Why it matters. An AI provider is an outside provider like any other, and most rules on outsourcing expect the organisation to know who its providers are and to assess them. AI providers can arrive through a developer’s card or a SaaS upgrade, and some are reached only through another vendor, so they are easy to miss. One provider behind several material use cases is a single point of failure. Banking example: BOT’s third-party risk management guideline expects a register of third parties (clause 7.4) and an assessment, before use and periodically, of lock-in to a single provider and of concentration risk, including concentration through subcontractors (clause 7.1 (8) and (9)). Concentration and lock-in are also binding concerns under attachment 2, clause 10.2 of the IT risk notification.
Evidence that answers it. The third-party register filtered to AI providers, with the vendor each is reached through; the assessment file for each material one, with its date; and the list of material use cases with the provider each depends on.
Why it matters. An AI that answers questions can be wrong. An AI that acts can be wrong at scale before anyone notices. The number of agents that act without approval, and the access they hold, is the size of that exposure. Agent accounts and AI provider keys are easy to leave out of access reviews because no person logs in with them; many reviews cover human administrator accounts only, and keys often sit outside any inventory. Banking example: BOT’s IT risk notification requires strict control of privileged accounts (attachment 2, clause 3.1). BOT’s AI guideline says banks may consider a person in or over the loop for decisions that are strategic or affect customers directly (ส่วนที่ 1 (3.2)); it is written as an option, not a requirement.
Evidence that answers it. The access review extract for AI service accounts, and the secrets store listing for AI provider keys, each with owner, scope and last rotation; and for each agent, from its configuration or design documents, the systems it can write to, whether a person approves each action, and where its actions are logged.
Why it matters. A model change can alter every answer a service gives while the service stays up. Some changes the organisation makes; others arrive from the provider, sometimes without notice. A change that was not tested against the previous version is a change nobody can explain afterwards. The denominator matters too: systems that call a model version the provider can change at will are exposed to changes nobody records. Banking example: BOT’s AI guideline expects model performance and the reliability of its results to be tested and monitored before and after use, continuously (ส่วนที่ 2 (2.2)). Whether a model change to a material system needs advance notice to BOT under clauses 9 and 10.1 is each bank’s own call.
Evidence that answers it. The change log filtered to AI, with the before-and-after test result for each change, and the model validation record where the organisation has one; the provider change notices received; and the number of systems running on a model version the provider can change without notice. A count of zero provider updates usually means nobody is watching, not that nothing changed.
Why it matters. A continuity plan covers what the BIA names. The BIA usually names the application, not the AI service underneath it, so the dependency has to be traced through the application. A process whose AI dependency is missing has no plan for the day that AI is unavailable. "Tested" is the word that matters: an alternative that exists only on paper fails on the day it is needed. Banking example: attachment 2, clause 10.5.9 of BOT’s IT risk notification requires worst-case plans for critical IT systems on public cloud, including an outage of every region in use. Whether an LLM API counts as public cloud is each bank’s own interpretation; the question above does not depend on the answer.
Evidence that answers it. BIA entries, with the AI service behind each application they name, the BCP or IT DR chapter with the provider-outage scenario, and the report and date of the last test.
Why it matters. Many regulated organisations must report serious IT incidents to their regulator. An AI incident is wider than an outage. It includes wrong output at scale, and a provider model change that alters outputs. The incident log holds only what someone detected; complaints are the outside detector. The complaint log is kept by customer service or the conduct function, not IT, and it is coded by product and channel, so AI rarely appears as a cause. If neither log has an AI category, these events are either missed or filed as something else, and nobody asks whether they met the reporting threshold. A count of zero here usually means the logs cannot see AI, not that nothing happened. Banking example: clause 10.3 of BOT’s IT risk notification requires prompt reporting to BOT of significant IT incidents, and BOT’s AI guideline expects customers to be told when they are dealing with AI (ส่วนที่ 1 (3.3)).
Evidence that answers it. An incident classification that includes AI, the incident log and the complaint log filtered to AI, and for each incident the recorded decision on whether it met the reporting threshold.
The questions lean on about a dozen records: the IT asset register (and the model inventory where one exists), the third-party register, the rating criteria and the risk register or risk and control self-assessment, the record of processing and the data processing agreements, the access review and the secrets store, the change log, the BIA, the BCP and IT DR test records, the incident log and the complaint log. Two of these, the record of processing and the complaint log, are kept outside IT, so not every answer comes from the CIO’s team. Two answers come from settings and reports rather than registers (questions 2 and 3), one rung lower but still dated evidence. No new framework is needed. The work is to make each record see AI. For the three records that sector rules name most often, the table after the figure shows where each one comes from for banks, life insurers and critical information infrastructure organisations.
| Record | Banks (BOT) | Life insurers (OIC) | Critical information infrastructure (NCSA code) |
|---|---|---|---|
| IT asset register | IT risk notification, attachment 2, clause 1 | IT risk notification 2020, clause 16 (1) | Asset inventory, including dependencies between assets, 21.1.1 and 21.1.1 (ฉ) |
| Outside providers | Third-party risk guideline, clauses 7.1 and 7.4 | Provider selection, contracts and monitoring, clause 23 | Accountability stays with the organisation when work is outsourced, 21.4.1 to 21.4.2 |
| Continuity plan | Attachment 2, clauses 10.4 and 10.5.9 | IT continuity plan, DR plan tested at least once a year, clause 25 | BCP that reviews providers’ plans, exercised at least once a year, 25.1.1 to 25.1.2 |
We have not read the non-life insurance notification; it is reported to follow the same structure. The NCSA code binds state agencies and CII organisations for their designated critical services only.
Notice that no question asks whether the organisation has an AI policy. A policy is worth having, and sector AI guidelines expect one; BOT’s does (ส่วนที่ 1 (1.1)). But a policy is a document, the second rung. A committee that already holds the policy needs to know whether the registers reflect it.
For the evidence an AI platform itself should leave behind, see You Say Your AI Is Governed. Six Months Later, Can You Show It?.
These five are not the committee questions above. They are yes-or-no questions you answer yourself, from what you know today, to see roughly where you stand before the committee asks for numbers. They are lettered A to E so that they are not mixed up with questions 1 to 10.
There is no score. After you answer, you will see what your pattern of answers usually means, and nothing else. Your answers are not stored unless you choose to send them to us.
A. An AI use that matters but has no row in the risk register sits outside the risk management your board relies on, and nobody is in a position to switch it off.
A. You have this record. Check that those risk-register rows are reviewed on the same cycle as your other risks.
B. This is the base the other four answers rest on. AI features switched on inside licensed software are the part most registers miss. The next chapter lists what a register should contain.
B. You have this record. Check that it includes AI switched on inside licensed software, the part most registers miss.
C. If you cannot see which processes share a provider, cloud or region, a fallback may fail together with the service it protects.
C. You have this record. Check that your fallbacks do not share the provider, cloud or region of the service they protect.
D. A plan that says "revert to manual" without a practised playbook is a hope, not a plan.
D. You have this record. Check the date of the last practice: a manual mode nobody has used this year may not work on the day.
E. The PDPA applies today to personal data that reaches an AI service, whatever your sector. The record of processing activities is where your DPO will look first.
E. You have this record. Check that it states where the data is processed and whether the provider may use it to train its models.
You have records for all five. The next useful step is to check that those records agree with each other: that the process in your BCP is the same one in your register, with the same provider and the same owner. That is where gaps usually hide in organisations that have done the groundwork.
Some of your answers are "I don't know". That is not a bad result. It means the information exists somewhere in your organisation but is not in a record anyone can open. Finding out who could answer is a good first step, and usually a quick one.
Your answers show where your existing risk management already reaches AI and where it does not yet. The gaps are usually closed by adding AI to records you already keep, not by building something new. The committee questions above show which record answers which question.
This is a self-reported reading, not an assessment. It is based only on your answers, which we have not seen.
Talk to us about your answers →Read about AI Risk Readiness →
These questions test whether records exist and are complete. They do not test whether the controls behind the records work. A register row can be current while the switch test it records was poorly designed. Nor do they test fairness or the quality of AI output directly; they test whether harm was detected and recorded. Those need their own review.
The banking examples cite BOT’s texts; the table also cites the insurance and critical information infrastructure texts we have read. Other sectors will map the same questions to their own rules, and where no rule names a record, to the records the organisation keeps as normal practice. If your compliance function reads any of these texts differently, its reading wins for your organisation.
A committee does not need to understand transformer models to oversee AI risk. It needs a handful of numbers and the discipline to ask for them again next quarter.
Most of the numbers will be hard to produce the first time. That is not a failure of the committee or of management. It shows exactly where the records stop seeing AI. The next chapter describes what an AI inventory should contain, so that the numbers become easy to produce.
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.
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.
