Secure Generative AI Environment | 3 Architectures Costed Over 5 Years

The generative AI usage policy went out months ago, and the floor is still working from personal accounts. Prohibition does not hold, for a simple reason. The official entry point is slower than the personal one. Choosing an architecture for a secure generative AI environment is therefore a decision about the speed of that entry point, not about how strictly the policy is worded. This article models a Japanese-owned manufacturing site in Chonburi, Thailand, with 620 employees, of whom 120 are white-collar staff and 60 seats are assumed to use generative AI in daily work, and puts the five-year total of three architectures side by side. Factory floor workers are out of scope because they have no assigned device. All amounts are in Thai baht, converted at 1 USD = 35 baht.

Why a written policy does not stop shadow AI

Over the past two years, a great many companies have circulated a policy containing the sentence “business data must not be entered into generative AI tools”. Ask around inside the same companies and you get the same answers every time. The meeting minutes are summarised on a personal account. The English translation goes through whichever tool is faster. Nobody is unaware of the rule. They know the rule and choose the faster option anyway.

The industry now has a name for this state, which is shadow AI. It means generative AI use that the company does not know about, meaning business data processed on accounts outside the control of the information systems function. As of 2026 this has stopped being a story about badly behaved employees and has been reclassified as a top-tier organisational risk.

Three primary sources point in the same direction

The Information-technology Promotion Agency (IPA) published its “Information Security 10 Major Threats 2026” on 29 January 2026. In the organisational category, first place went to ransomware attacks and second to attacks aimed at the supply chain and outsourcing partners. Third place went to cyber risk surrounding the use of AI, appearing on the list for the first time. Entering the ranking at number three on first appearance is itself a measure of how quickly the last year has moved.

Looked at from the adoption side, the “White Paper on Information and Communications 2026” published by the Ministry of Internal Affairs and Communications on 24 July 2026 reports that the share of people in Japan who have used generative AI has reached 58.8%. In the 2024 survey the figure was 26.7%, so it has more than doubled. The same white paper puts China at 93.6%, which places Japan on the low side, but the overall picture is that more than half the population has now tried these tools. On the corporate side, the concern most frequently cited after “we do not know how to use it effectively” is security risk such as leakage of internal information. More people are using it, and the concern has not gone away. That is where we stand.

Then there is the cost of getting it wrong. According to IBM’s “Cost of a Data Breach Report 2025”, 20% of the breaches studied involved shadow AI. One in five. Further, in breaches where shadow AI was a significant factor, an average of 670,000 USD, or 23,450,000 baht, was added on top of the normal cost of the breach. The same report puts the global average cost of a breach at 4,440,000 USD, or 155,400,000 baht. Where shadow AI is involved, the additional 23,450,000 baht sits on top of that. The report makes one more point that matters here. 97% of AI-related breaches involved organisations that lacked proper access controls.

Doing nothing is not a zero-cost option

The comparison to hold on to is the five-year total of Architecture A described later, which is 5,180,000 baht. Divide the 23,450,000 shadow AI premium by 5,180,000 and you get roughly 4.5 times. In other words, a single incident burns four and a half times what it costs to build and run an official entry point for five years, and that is only the premium. The base cost of the breach itself is a separate line.

Deferring the decision is not the free option. Deciding to accept the risk because the probability is low is a legitimate position, but even then the company should write down what exactly it has accepted. Circulating a policy and treating the matter as handled is not risk acceptance. It is abandoning measurement.

Why the policy itself cannot stop it

The reason is straightforward. A policy prohibits a behaviour without providing an alternative. For the person on the floor, the English email that arrived on Monday morning still has to be answered within ten minutes. A personal account opens in fifteen seconds. If the official entry point means filing a request and waiting three business days, walking to a dedicated terminal, or belonging to one approved department, no amount of severity in the policy will win that contest.

So the condition for stopping shadow AI is singular. The official entry point has to be faster and more convenient than a personal account. Until that condition is met, no architecture will close leak type 1 described later. Put the other way round, the criterion for selecting an architecture is not how secure it is but whether it is secure while remaining fast. We cover how to draft the policy itself separately in how to write a generative AI usage policy, but a policy takes effect after the entry point exists. It is not a substitute for one.

Three architectures for a secure generative AI environment

In practice there are three ways to build the official entry point. The choice determines both the structure of the cost and the range of risk that can actually be closed.

Architecture A, governed SaaS tenant — locking a purchased entry point

You take a finished AI service under a corporate contract and put the whole company on that one service. What you build is not an application but a control layer. SSO and conditional access block anything other than a company-issued account, DLP and sensitivity labels govern what can be pasted in, and usage logging makes it possible to trace who used what for which purpose.

The main advantage is speed. The interface already exists and the vendor keeps improving it. Time from decision to first use is the shortest of the three, and from the floor’s point of view the experience is usually the closest thing to a personal account. This is the architecture that satisfies the “official entry point is fast” condition most directly.

Its weaknesses are a fixed per-seat price and the fact that data is stored, as a rule, in the vendor’s tenant. Take Microsoft 365 Copilot as the reference point. It is 30 USD per user per month on an annual contract, with a base Microsoft 365 licence required separately, which at 35 baht to the dollar is 1,050 baht per month. That unit price stacks up seat by seat with nothing to blunt it. The practical rollout sequence is covered in how to roll out Microsoft Copilot.

Architecture B, API wrapper — building the entry point yourself

You contract for a corporate model API and put your own chat interface on top of it. Authentication connects to your internal directory, departmental permissions are defined in house, and audit logs land in your own storage. Adding RAG so the assistant can search internal documents and use them in its answers is the typical shape of this architecture.

There are three advantages. First, adding seats only adds token usage fees, so the larger the population the better the economics. Second, you can build work-specific behaviour, such as connections to internal documents or integration into approval workflows. Third, you choose the region where data is stored.

The weakness is that the interface, the permission model and the logging are all yours to build. Everything you build costs money up front, and everything you have built has to be maintained afterwards. The RAG layer is where that effort concentrates, which is why it carries 620,000 of the initial cost in the model below, covering 20,000 pages of internal documents.

Architecture C, private and self-hosted — keeping tokens inside

You run an open-weight LLM on your own GPU servers so that neither input nor output leaves the internal network. Technically this gives the strongest isolation available.

As the cost section shows, however, it comes to 2.1 times the cost of Architecture A while closing exactly one additional item out of five ways data leaks. C is not an architecture you choose on payback. You choose it as a necessary expense when a contract or a regulation genuinely says this data cannot leave the country. Choosing C without such a constraint produces the worst combination available, which is higher cost together with a worse day-to-day experience than either A or B.

Comparing five-year totals — 5,180,000, 5,728,100 and 10,863,040

From here the discussion is numerical. The model is the site described at the start, with 60 seats using generative AI. The five-year total is initial cost plus annual cost times five. Every baht figure below is a modelled estimate that TOMAS TECH has assembled from real project pricing. None of it is official statistics or industry survey data. Read it as a measuring stick for the quotations on your own desk.

Architecture A, governed SaaS tenant

Licences are 60 seats times 1,050 baht times 12 months, which is 756,000 baht a year, or 3,780,000 over five years. Against a five-year total of 5,180,000, that is 3,780,000 divided by 5,180,000, or 73%. More than seven tenths of the cost of Architecture A is licensing. The control layer itself, meaning the 680,000 initial and the 144,000 annual, amounts to only 680,000 plus 720,000, or 1,400,000, over five years.

Architecture B, API wrapper

The initial cost is close to 3.4 times that of A, but the annual cost of 685,620 is below A’s 900,000. You pay up front and recover it on the annual line.

Architecture C, private and self-hosted

Electricity assumes two servers at an average 1.2 kW, so 2.4 kW running 8,760 hours a year. That is 2.4 times 8,760, or 21,024 kWh, at 4.5 baht per kWh, giving 94,608 baht a year. For a GPU server, maintenance and operations staff are far larger line items than the electricity bill.

Line the five-year totals up and 10,863,040 divided by 5,180,000 is 2.1 times, a difference of 5,683,040 baht.

Benefit and payback, on assumptions common to all three

The benefit delivered on the floor is treated as identical across the three architectures. If 60 seats each save 15 minutes of working time a day, then

• 60 seats times 15 minutes times 20 days a month times 12 months = 216,000 minutes a year, or 3,600 hours a year
• At a white-collar hourly rate of 320 baht, 3,600 times 320 = 1,152,000 baht a year

Subtract each architecture’s annual cost from that annual benefit to get the annual net. Divide the initial cost by the annual net and you have the payback period.

Written out, A is 680,000 divided by 252,000, or 2.7 years. B is 2,300,000 divided by 466,380, or 4.9 years. C is 5,340,000 divided by 47,392, or 112.7 years. The figure for C is not a typographical error. Against an annual benefit of 1,152,000 the annual cost is 1,104,608, leaving only 47,392 a year, which never repays the initial 5,340,000. C does not pay back in any practical sense. To repeat, the reason to choose C is not payback. It is the necessary cost of compliance when a contract or a regulation forbids the data from crossing a border.

Nine tenths of the cost sits outside the model usage fee

This is the core of the article. Of Architecture B’s five-year total of 5,728,100, how much would you guess is the model usage fee?

Building up Architecture B’s model usage fee from a single token

Following the assumptions in the ledger.

• 60 seats times 300 requests a month times 12 months = 216,000 requests a year
• Assume an average of 3,000 input tokens and 700 output tokens per request
• Annual input tokens = 216,000 times 3,000 = 648,000,000 tokens
• Annual output tokens = 216,000 times 700 = 151,200,000 tokens
• Input is priced at 2.50 USD per million tokens, which at 35 baht is 87.5 baht per million tokens
• Output is priced at 10.00 USD per million tokens, which at 35 baht is 350 baht per million tokens
• Input cost = 648 times 87.5 = 56,700 baht
• Output cost = 151.2 times 350 = 52,920 baht
• Total = 56,700 plus 52,920 = 109,620 baht a year

Over five years that is 548,100 baht. As a share of the five-year total, 548,100 divided by 5,728,100 is 9.6%.

The remaining 90.4% is not the price of a model. It is the chat UI build at 850,000, authentication and permissions at 230,000, audit logging and DLP filtering at 340,000, the RAG connection at 620,000, verification and training at 260,000, and on the annual line the cloud platform at 216,000 and maintenance and improvement at 360,000. Every one of those is the cost of consolidating and governing a single entry point.

This matters in practice because internal discussion drifts almost automatically towards which model is cheapest. Halve the model unit price and Architecture B’s five-year total falls only from 5,728,100 to 5,454,050, a reduction of 274,050, which is half of 548,100, and a reduction rate of 4.8%. How far you build the interface, the permission model and the logging affects cost roughly 9.4 times more than model selection does, since 90.4% divided by 9.6% is about 9.4.

At around 70 seats, A and B change places

Architecture A accumulates a licence per seat, while Architecture B adds only token usage as seats grow. Which one is cheaper is therefore a function of seat count. Let n be the number of seats.

• Architecture A five-year total = 1,400,000 + 63,000n
• The fixed part is the 680,000 initial plus 144,000 of annual log monitoring over five years, or 1,400,000
• The variable part is 1,050 baht times 12 months times 5 years, or 63,000 baht per seat
• Architecture B five-year total = 5,180,000 + 9,135n
• The fixed part is the 2,300,000 initial plus the cloud platform at 216,000 and maintenance at 360,000 over five years, or 5,180,000, which happens to equal Architecture A’s five-year total at 60 seats purely by coincidence
• The variable part is 109,620 divided by 60 seats, or 1,827 baht per seat per year, which is 9,135 baht per seat over five years

The two are equal when 63,000n minus 9,135n equals 5,180,000 minus 1,400,000, that is 53,865n = 3,780,000, so n = 70.2. The crossover is around 70 seats.

Choose B at a 30-seat site and you pay 2,164,050 baht more over five years. Choose A at a 100-seat site and you leave 1,606,500 baht on the table. The same “correct answer” reverses depending on the site.

The practical conclusion is that you should not decide on the basis of a single Thai site in isolation. If 50 seats in Thailand, 30 in Vietnam and 25 in Indonesia add up to 105 seats within the region, standing up one shared Architecture B is cheaper than contracting Architecture A site by site. Count the 70-seat crossover not as the seats at one site but as the seats that can share one entry point. A feature-level comparison of the individual services is collected in comparing enterprise generative AI services.

Five ways data leaks, and what each architecture closes

Having covered the money, the next question is what that money actually closes. Information leakage involving generative AI falls into five practical types.

Leak type 1, export to personal accounts — closed, conditionally

All three close it, but only on one condition, which is that the official entry point is faster than a personal account. Build an entry point that demands two-factor authentication on every login, opens only on a company-issued laptop, and takes 20 seconds to respond, and the floor will quietly go back to personal accounts. At that point the company is worse off than before, because the policy is being broken and nothing is being logged.

There are three measurable indicators for this condition. Seconds from opening the entry point to the first response, whether it works from a company-issued smartphone, and days from request to first use. Whether you may write “closed” in row 1 of that table is decided by those three numbers, not by the technical architecture.

Leak type 2, cross-border transfer of input data — can you choose where it is stored

Only C closes it unconditionally. A and B are conditional because it depends on whether data residency, meaning the storage region, can be selected, and on what the contract says.

As a concrete example, OpenAI’s data residency lets you select the storage location in Japan, India, Singapore and South Korea, covering ChatGPT Enterprise, Edu and the API. Thailand is not among the covered locations. For a Thai site, therefore, any input containing personal data necessarily leaves the country. That is where PDPA Sections 28 and 29 on cross-border transfer come in, covered in the next section.

Leak type 3, reading beyond one’s permissions — nothing closes without a permission review

A is conditional because a SaaS AI assistant inherits the existing permissions of shared folders and SharePoint exactly as they stand. The design is that whatever the person can open, the AI can read and summarise. That design is correct in itself. The problem is that in most companies, shared folder permissions no longer match reality.

With paper files, an outsider is unlikely to stumble across the salary table buried at the back of the HR folder. An AI assistant, asked about last year’s bonus trends, will read across every file it is permitted to see and answer. Better retrieval makes every hole in the permission model visible at once.

B is marked as closed because when you build the RAG layer yourself you explicitly define the document set the AI may reference, aligned to the business purpose. Even that is not automatic. Understand this row as the difference between having done a permission review and not having done one, rather than a difference between architectures. A closes it too, once the review is done.

Leak type 4, taking output at face value — no architecture closes this

Technology does not close this one. Run the model on a private GPU server and it will still produce wrong content in fluent prose. If anything, C raises the risk, because the feeling that it is safe since nothing leaves the building tends to erode the discipline of checking output.

In manufacturing the damaging cases look like this. Someone accepts a summarised specification and gets a drawing tolerance wrong. Someone asks the AI for an HS code for export paperwork and files it as given. Someone has the AI summarise the conditions for standards conformance and reflects that in inspection criteria without reading the source. All three sit squarely in the territory where generative AI is plausibly wrong.

The only countermeasure is a verification procedure. Specifically, put three things in writing. First, separate the work where AI output may go outside the company as it stands from the work where a human must check it against the source. Second, for work requiring source checking, record the name of the person who checked and the date. Third, treat figures, laws, standards and part numbers as four categories that must always be confirmed against primary sources, whatever the output says.

None of those three appear as a large number anywhere in the cost tables, yet this is the only one of the five leak types that money cannot solve. The companies that spend the most time debating architecture are the ones most likely to go live with this section still blank.

Leak type 5, residual access for leavers and contractors

All three close it, but only where the AI entry point is tied to internal identities. Create one shared account per department and pass it around and you leave a state in which a leaver can keep using it, and in which the logs cannot tell you who did what. IBM’s finding that 97% of AI-related breaches lacked proper access controls is pointing exactly here.

Contractors require a contractual response. Write into the outsourcing agreement that data obtained in the course of the work must not be used to train AI models, and set a review interval for contractor accounts. Both points apply to all three architectures.

Four additional issues at a Thailand site

Everything so far would hold in Japan as well. Operating in Thailand adds four further issues.

Issue 1, cross-border transfer under PDPA Sections 28 and 29

Thailand’s Personal Data Protection Act governs transfers of personal data out of the country in Sections 28 and 29. The practical difficulty is that the list of countries with adequacy status has still not been published. For now, therefore, transfers rely on standard contractual clauses (SCC), binding corporate rules (BCR), or explicit consent.

There has been progress. The Personal Data Protection Committee (PDPC) approved BCRs in April 2026, making them usable in practice. For Japanese-owned groups that move data between the Thai entity and the parent company, BCRs are a strong option.

What matters in the generative AI context is that entering data into an AI service can itself constitute a cross-border transfer. As noted above, OpenAI’s data residency does not cover Thailand. Check service by service whether the storage location can be placed inside Thailand. If you choose A or B, identify the work in which input includes personal data and decide in advance whether SCC, BCR or explicit consent will be the legal basis for each.

Issue 2, the PDPC draft AI guidelines of February 2026

In February 2026 the PDPC published draft guidelines on personal data protection in the development and use of AI. Two points bite in practice. First, data processing agreements should include a prohibition on using the data for model training. Second, high-risk AI should be subject to a data protection impact assessment (DPIA).

The first is a one-line check on the vendor contract. Corporate plans generally state that input data is not used for training, but distinguish carefully between a statement in the published terms of service and a statement in your own signed agreement. The DPIA point applies where AI is used in ways that affect individual rights, such as HR evaluation or credit decisions. Summarising meeting minutes or translating documents would not normally qualify as high risk.

Issue 3, the NCSA AI security guidelines of September 2025

The National Cyber Security Agency (NCSA) issued AI security guidelines in September 2025. Their content is aligned with ISO/IEC 42001:2023 and the NIST AI Risk Management Framework, so they read less as a set of local requirements than as a bridge to international standards.

The practical implication is that records kept in line with ISO/IEC 42001 for AI management can be used directly to explain yourself in Thailand. If the parent company is already pursuing or maintaining ISO/IEC 42001, the Thai site does not need to build a separate framework.

Issue 4, the Thai AI bill has not been enacted

This is where the most confusion sits. The Electronic Transactions Development Agency (ETDA) published a new Draft Act on Artificial Intelligence on 2 July 2026 and ran a public hearing of roughly 30 days. The law has not been enacted. It remains at draft stage.

The draft contemplates risk-based classification, transparency obligations for AI-generated material, liability for damage caused by AI, and administrative fines of 1 million to 5 million baht.

Note carefully that this is a different law from Vietnam’s AI law. Commentary conflating the two is in circulation, and you will find material citing the Vietnamese position as though it described Thailand. If you see a document stating that an AI law is in force in Thailand, check the source and the date first.

In practical terms there is no need to design against a law that has not passed. That said, the direction shown in the draft, meaning risk classification, transparency, liability and recordkeeping, does not conflict materially with ISO/IEC 42001 or the PDPC draft guidelines. What you should be putting in place now is not compliance with statutory text but the ability to explain which work uses AI, who verifies the output, and where the logs are kept. With that in hand, adapting once the law passes is a matter of the delta.

A 90-day sequence for standing up the official entry point

This is what happens after the architecture is chosen. The principle is unchanged, which is that making the official entry point faster than a personal account comes first. Get the sequence wrong and the controls go live ahead of the service, and the floor walks away.

Days 1 to 30, measure reality and choose the architecture

The first task is not revising the policy. It is measurement.

First, count the seats. Not the whole headcount. The number of people who will use generative AI in daily work. In the model site, that is 60 seats out of 120 white-collar staff within 620 employees. Factory workers are out of scope because they carry no device. Which side of the 70-seat crossover that count falls on largely settles the choice between A and B.

Second, find out what it is being used for today. State explicitly that the exercise will not be used for discipline, then collect use cases by department. In most cases four uses account for the bulk of it, which are translation, summarisation, drafting email and writing up minutes. Whether those four run quickly decides whether the entry point succeeds.

Third, identify the work that constitutes a cross-border transfer. Pin down the tasks whose input contains personal data, such as HR, supplier contact details and customer contacts, and decide whether SCC, BCR or explicit consent will provide the basis. This is the one item that requires legal and HR involvement, so start it early.

Days 31 to 60, build the entry point and review permissions

For Architecture A this means SSO and conditional access, DLP and the logging platform. For Architecture B, the interface, authentication, logging and RAG are all under construction.

Alongside that, the permission review for leak type 3 is mandatory. What the AI can read equals what employees can read. Produce a department-by-department list of who can currently open which shared folders and SharePoint sites, and correct whatever does not match reality. The work is unglamorous, but without it leak type 3 stays open regardless of architecture.

This is also the period in which you document the verification procedure for leak type 4. The list of work requiring source checking, how the check is recorded, and the rule that figures, laws, standards and part numbers are always confirmed against primary sources. One page is enough.

Days 61 to 90, measure speed and align the policy afterwards

Once the entry point is running, the first thing to measure is not the adoption rate but the speed. Seconds from login to first response, whether it can be used from a company-issued smartphone, and days from request to first use. Unless those three beat the personal account, adoption will not rise. Tightening the policy while adoption stays flat simply pushes people back to shadow AI.

Revising the policy comes last. Stand up the entry point, then write the policy as instructions for using that entry point. Reverse the order and all that gets circulated is a list of prohibitions, leaving the floor on personal accounts because no alternative exists.

The completion criteria at day 90 are these four. The entry point is consolidated into one. Who used what for which purpose can be traced in the logs. The permission review is finished. And the verification procedure for leak type 4 exists as a document that the people doing the affected work have actually read.

Frequently asked questions

What is a secure generative AI environment?

It is an environment in which the company has consolidated the way employees reach generative AI into one entry point, so that authentication, permissions, logging and the location where data is stored are all visible to the company. The important part is that this is provision of an alternative, not a prohibition mechanism. If the official entry point is not faster and more convenient than a personal account, the environment will go unused and shadow AI will remain.

How much does building an internal AI environment cost?

For the 60-seat model site, the five-year totals are 5,180,000 baht for Architecture A, the governed SaaS tenant, 5,728,100 baht for Architecture B, the API wrapper, and 10,863,040 baht for Architecture C, private and self-hosted. These are TOMAS TECH modelled figures, not published statistics. When reading your own quotation, look past the total and ask what is in there besides the model usage fee. In Architecture B, 90.4% of the five-year total sits outside the model usage fee.

Do we need a private, self-hosted LLM?

In most cases, no. Architecture C is 10,863,040 over five years, which is 2.1 times Architecture A, a difference of 5,683,040, and what that buys is closing exactly one of the five leak types, namely cross-border transfer of input data. Payback is 112.7 years, meaning it does not pay back in practice. C is justified when a contract or a regulation genuinely forbids the data from leaving the country. Choose it without such a constraint and you have multiplied cost by 2.1 while making the experience worse for the people using it.

Is a generative AI usage policy on its own enough?

No. A policy prohibits a behaviour without providing an alternative. IBM’s 2025 report found that 20% of breaches involved shadow AI, and that breaches in which shadow AI was a significant factor carried an average of 670,000 USD, or 23,450,000 baht, on top of the normal cost. That is 4.5 times Architecture A’s five-year total of 5,180,000. A policy takes effect after the entry point exists. It is not a substitute for one.

Do we already have to comply with the Thai AI law?

As of August 2026 there is no enacted AI law in Thailand. ETDA published a new Draft Act on Artificial Intelligence on 2 July 2026 and ran a public hearing of roughly 30 days. The draft contemplates risk-based classification, transparency obligations for AI-generated material, liability for AI-caused damage, and administrative fines of 1 million to 5 million baht. Do not confuse it with Vietnam’s AI law, which has reached the stage of being in force. What you must comply with today is the PDPA, including Sections 28 and 29 on cross-border transfer, and the PDPC guidelines published in February 2026 remain at draft stage.

Can we build the generative AI environment at an overseas site first?

Yes, but be careful how you count the seats. The crossover at which A and B swap places is around 70 seats, and that is counted as the seats that can share one entry point. At 50 seats in Thailand alone, A is the better answer, but if 30 seats in Vietnam and 25 in Indonesia bring the total to 105, one shared Architecture B is cheaper over five years, as the 100-seat comparison shows with B cheaper by 1,606,500. Conversely, building a separate Architecture B at each site duplicates the 2,300,000 initial cost site by site. Starting at one site is fine, provided you build it so the other sites can be added later.

Summary

Shadow AI is not stopped by policy. It stops only when the official entry point is faster and more convenient than a personal account. So what has to be decided is not how strict the policy should be, but which architecture the official entry point is built on.

And the cost difference between architectures does not appear where most people expect it, in the model usage fee. Of Architecture B’s five-year total of 5,728,100, the model usage fee is only 548,100, which is 9.6%. The remaining 90.4% is authentication, logging, permissions, RAG and maintenance, which is to say the control cost of consolidating the entry point into one. Architecture A is the mirror image, with 73%, or 3,780,000, of its 5,180,000 five-year total being licences. That structural difference is what produces the reversal by seat count, with A and B swapping places at around 70 seats, since A is 2,164,050 cheaper at 30 seats and B is 1,606,500 cheaper at 100 seats.

Architecture C, private and self-hosted, is 10,863,040 over five years, 2.1 times Architecture A, with a payback of 112.7 years that never actually arrives, and all it adds is closing one of the five leak types, the cross-border transfer of input data. And leak type 4, taking output at face value, is closed by none of A, B or C. The only way to close it is not technical. It is a verification procedure setting out who checks what before it enters the work.

Meanwhile, doing nothing is not free. IBM’s 2025 report found 20% of breaches involved shadow AI, with an average of 23,450,000 baht added to breaches in which shadow AI was involved. That is 4.5 times Architecture A’s five-year total. One incident reverses the ranking.

TOMAS TECH is happy to talk through nothing more than which architecture fits your situation, if that is the stage you are at. Tell us three things, which are how you count the seats, which work would constitute a cross-border transfer, and how your existing SharePoint permissions would flow into an AI assistant, and we can usually indicate on the spot whether A or B is the reasonable landing point and whether there is a real reason to consider C. There is no need to have decided on a rollout. Get in touch through our contact form.

References

1. Information-technology Promotion Agency (IPA), “Information Security 10 Major Threats 2026”, published 29 January 2026

https://www.ipa.go.jp/pressrelease/2025/press20260129.html

Referenced for the organisational ranking in which ransomware attacks took first place, attacks on the supply chain and outsourcing partners took second, and cyber risk surrounding the use of AI entered the list for the first time at third.

2. IBM, “Cost of a Data Breach Report 2025”

https://www.ibm.com/reports/data-breach

Referenced for the findings that 20% of breaches involved shadow AI, that breaches in which shadow AI was a significant factor carried an average of 670,000 USD on top of the normal cost, that the global average cost of a breach was 4,440,000 USD, and that 97% of AI-related breaches lacked proper access controls.

3. Ministry of Internal Affairs and Communications, “White Paper on Information and Communications 2026”, published 24 July 2026

https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r07/html/nd112220.html

Referenced for the finding that the share of people in Japan who have used generative AI reached 58.8%, against 26.7% in the 2024 survey, that the figure for China was 93.6%, and that the corporate concern cited after not knowing how to use it effectively was security risk such as leakage of internal information.

4. Mondaq, “Thailand Releases New Draft Artificial Intelligence Act”

https://www.mondaq.com/it-and-internet/1811290/thailand-releases-new-draft-artificial-intelligence-act

Referenced for the facts that ETDA published a new draft on 2 July 2026 and ran a public hearing of roughly 30 days, that the law has not been enacted, and that the draft contemplates risk-based classification, transparency obligations for AI-generated material, liability for AI-caused damage, and administrative fines of 1 million to 5 million baht.

5. Tilleke & Gibbins, “Comprehensive Policy — Thailand’s AI Governance Framework”

https://www.tilleke.com/insights/comprehensive-policy-thailands-ai-governance-framework/

Referenced for the point that the Personal Data Protection Committee (PDPC) published draft guidelines on personal data protection in the development and use of AI in February 2026, proposing that data processing agreements include a prohibition on use for model training and that high-risk AI be subject to a data protection impact assessment (DPIA).

6. Tilleke & Gibbins, same source, on the AI security guidelines of the National Cyber Security Agency (NCSA)

https://www.tilleke.com/insights/comprehensive-policy-thailands-ai-governance-framework/

Referenced for the point that the AI security guidelines issued by the NCSA in September 2025 are structured to align with ISO/IEC 42001:2023 and the NIST AI Risk Management Framework.

7. Baker McKenzie, “Thailand — PDPC Approved BCRs for Cross-Border Transfers”

https://www.bakermckenzie.com/en/insight/publications/2026/04/thailand-pdpc-approved-bcrs-for-cross-border-transfers

Referenced for the facts that the PDPC approved binding corporate rules (BCR) in April 2026, making them usable in practice, and that because the list of countries with adequacy status has not been published, transfers in practice rely on standard contractual clauses (SCC), BCRs or explicit consent. PDPA Sections 28 and 29 govern cross-border transfer.

8. OpenAI, “Introducing data residency in Asia”

https://openai.com/index/introducing-data-residency-in-asia/

Referenced for the facts that ChatGPT Enterprise, Edu and the API allow the storage location to be selected in Japan, India, Singapore and South Korea, and that data residency inside Thailand is not covered.

9. Microsoft, “Microsoft 365 Copilot”

https://www.microsoft.com/en-us/microsoft-365/copilot/business

Referenced for the price of Microsoft 365 Copilot at 30 USD per user per month on an annual contract, with a base Microsoft 365 licence required separately, converted at 35 baht to give 1,050 baht per month and used as the per-seat licence price in Architecture A.