ChatGPT Enterprise Implementation 2026 — Entity Before Plan

A ChatGPT enterprise implementation review almost always opens with the same question — Business or Enterprise? Teams line up the per-seat prices, put the feature matrices side by side, and shape the whole thing into something a budget committee will sign. There is nothing wrong with that sequence in itself. But projects that run in that order tend to get stuck in roughly the same place about a year later. The plan can be changed afterwards. What was quietly settled one step earlier — which legal entity opened the workspace, and when — cannot be redrawn.

This article is written for readers at Japanese-owned manufacturers with operations in Thailand, and it works through how to decide the contracting entity and the boundary. There are price and feature comparison tables here too, but they are not the main act. The main act is a judgement that never even makes it onto a line of the approval request: whose name the first workspace is created under.

In a ChatGPT enterprise implementation, the plan is not what gets decided first

The plan is the reversible part

Start with the things you can change later.

Moving from ChatGPT Business to ChatGPT Enterprise is a contractual change. Adding seats, negotiating the unit price, stepping up to a higher tier of functionality — all of these can be moved at renewal time or inside a commercial discussion. The reverse is also on the table: dropping from Enterprise back to Business, or reducing seat count, is possible depending on contract terms. In other words, plan selection is the kind of decision where a wrong call can still be walked back.

Which is exactly why spending the bulk of your evaluation time on plan selection is a poor allocation. Time goes into the recoverable decision, and the unrecoverable one gets waved through unnoticed. We believe that is the most common shape of failure in generative AI rollout planning.

What you cannot change is the legal entity the workspace was created under

Corporate use of ChatGPT is organised around a unit called the workspace. A workspace has administrators, a domain attached to it, a legal entity paying the bill, and it accumulates the conversation history, custom GPTs, and uploaded knowledge belonging to the members inside it.

The problem is that some of the settings tied to a workspace can only be decided at the moment of creation. Data residency, covered below, is the textbook case — it cannot be bolted onto an existing workspace. On top of that, assets cannot be moved across workspaces.

The practical result is that the instant you stand up the first one, three things are effectively locked in.

• The contracting entity. Japan HQ, the Thai entity, or both. The contract itself can be changed, but the accumulated assets cannot be moved.
• Where data is stored. Data residency settings can only be applied to new workspaces.
• Where administration and accountability sit. Who reads the admin logs, and who explains matters to the regulator. Contractual allocation of responsibility can be rewritten, but accountability for what already happened stays where it was.

The common thread across all three is that there is no way back. The plan is reversible; the boundary is not. Reverse the order of evaluation and you end up spending your time on the reversible part while deciding the irreversible part on momentum. The approval request says nothing more than “ChatGPT Business, 40 seats,” and the entity the workspace was created under disappears between the lines, so it never becomes a discussion point in the approval meeting either.

Three reasons the contracting entity decision is irreversible

The three points below are all verifiable from published information. Individually each looks like an ordinary constraint. Stacked together, they produce a structure where the first move stays in effect until the end.

Reason 1 — data residency can only be set on a new workspace

As of reporting dated November 26, 2025, OpenAI has expanded the scope of data residency (region selection for stored data). The covered services are ChatGPT Enterprise, ChatGPT Edu, and the API Platform. The regions are the United Kingdom, Canada, Japan, South Korea, Singapore, India, Australia, the UAE, plus Europe and the United States.

The operational pressure point is the applicability condition. For ChatGPT Enterprise and ChatGPT Edu, data residency applies only to new workspaces. You cannot go back to a workspace that is already running and change the setting to “store data in Japan.”

What that single sentence means is that the order is fixed. The approach of starting small in the HQ workspace and adding a region selection later, if it turns out to be needed, does not work. If region selection is required, then the only route once you know it is required is to stand up a new workspace from scratch. And standing one up again carries the cost described in Reason 3.

Reason 2 — Thailand is not on the residency list, and the scope is storage only

For anyone working from a Thai site, the important detail is that Thailand does not appear in the region list above. In East, Southeast, and South Asia, the covered countries are Japan, Singapore, South Korea, and India (in the Middle East, the UAE is included). The option for a Thai entity to choose “stored in Thailand” does not exist at present.

Going one step further, what residency lets you specify is the location of data at rest only. According to the reporting, inference itself runs by default on infrastructure in the United States. So region selection controls where data is placed, but it is not a full control over where data is processed.

Put those two points together and the conclusion for a Thai entity is clear. The route of satisfying obligations under Thailand’s Personal Data Protection Act (PDPA) by choosing a storage location is simply not on offer. Choosing Singapore storage still produces a cross-border transfer, and so does choosing Japan storage. The question therefore moves away from storage location and towards the appropriate safeguards for cross-border transfer and the design of accountability, both covered below.

Reason 3 — conversation history, custom GPTs, and knowledge cannot cross workspaces

The third one is, in practice, the constraint that hurts most. There is no mechanism for carrying conversation history, custom GPTs, or uploaded knowledge from one workspace to another.

Six months to a year of serious use leaves a workspace with a meaningful stock of assets. The summarisation prompts quality control refined for inspection records, the quotation-comparison custom GPT purchasing built, the in-house terminology glossary production control accumulated. These are hard to price, and rebuilding them takes exactly as long as building them did.

A plan that says “ride on HQ’s Enterprise first, then split off into a standalone local workspace when we need to” changes its cost estimate at this point. The cost of separation is not the licence differential — it is the time spent rebuilding assets you have to throw away. Looked at the other way, it is also a cost that would never have arisen had you separated from the start.

Lining the three up again: region selection can only be applied at creation (Reason 1); there is no location in Thailand to apply it to in the first place (Reason 2); and if you want to apply it after the fact, the only way is to discard your assets (Reason 3). Because those three overlap, the contracting entity decision sits in territory where “we will think about it later” does not work.

The Business and Enterprise gap splits into a published part and an unpublished part

None of which means plan comparison can be ignored. If you are building a budget, you need the order of magnitude. What follows separates published figures from unpublished market levels, explicitly.

The published prices

ChatGPT Business pricing is published. It is USD 20 per seat per month on an annual contract, USD 25 per seat per month on a monthly contract, from a minimum of 2 seats. The annual-contract unit price was revised from USD 25 to USD 20 on April 2, 2026.

OpenAI also recommends moving to Enterprise above a headcount of 250 employees. Note that this is a recommendation based on employee headcount, not on seat count. The model company used later in this article has 300 employees with 40 seats deployed, so even with a small seat count it falls inside the recommended scale. We read a recommendation as a recommendation rather than a restriction, but it is safer to build budget headroom on the assumption that a higher-tier proposal will come up during renewal discussions.

The unpublished prices

ChatGPT Enterprise has no published price. It is quoted individually. Reporting covering 2026 deals puts it in a band of USD 45–75 per seat per month, with most landing in USD 50–60. Contracts are annual and prepaid as a rule.

On minimum seats, no official floor has been published. That said, procurement accounts repeatedly put an effective floor at around 150 seats. This point matters enough to state plainly: 150 seats is not a published contract condition — it is a market level observed from reporting and procurement practice. Individual negotiation may land below it, and it may equally result in a higher requirement. The estimates in this article treat 150 seats only as a reference level, never as a confirmed condition.

From an approval standpoint, the bottom-right cell of that table is the awkward one. With Enterprise, the amount is not fixed until a quote exists. As the modelling below shows, the gap between USD 45 and USD 75 becomes a substantial sum over five years.

What the extra money buys is governance, not intelligence

On feature differences, the most misunderstood point comes first. Neither Business nor Enterprise uses customer data to train models by default. They are identical here. Nor does output quality rise in proportion to the per-seat price.

The difference sits in the administration and control layer.

One note on how to read that table. What the extra money buys is not smarter output — it is governance. Being able to extract audit logs mechanically. Having a leaver’s access drop automatically in step with the HR system. Holding your own encryption keys. Those are the things carrying a price tag.

Which changes the logic of the approval request as well. “Enterprise is smarter” will not carry it. This is the kind of expenditure that can only be justified in the form of “when we are asked to explain ourselves in an audit, we can produce X through the log API.” Conversely, if you are not in a position that carries that accountability, Business is enough.

Note also that the presence or absence of SCIM feeds directly into operational effort. Without SCIM, an administrator moves seats in and out by hand every time someone joins or leaves. If your Thai site has departments with heavy staff turnover, that effort is not negligible. The estimates below fold this difference into the numbers as administrative labour.

Head-to-head comparison of the generative AI products themselves — who gets how many seats, which product to pick — is handled separately in Enterprise Generative AI Comparison 2026 — the seat design that separates an 11.2-year payback from 3.4 years. This article stays one step earlier, on the question of which legal entity’s workspace you run on.

What Thailand’s PDPA asks for is accountability, not a storage location

Since the residency route comes up empty, the question for a Thai site moves to the cross-border transfer framework. Legal interpretation is involved here, so verified facts and reservations are kept separate.

How Section 28 and Section 29 relate

Thailand’s Personal Data Protection Committee (PDPC) published its Section 28 and Section 29 notifications on December 25, 2023, and they came into force on March 24, 2024.

• Section 28 is the whitelist approach — it requires the destination country to have a legal regime and enforcement authority at least equivalent to Thailand’s Personal Data Protection Act (PDPA).
• Section 29 is the fallback where Section 28 is not met, and requires appropriate safeguards. Specifically, the contractual clauses are expected to include notification obligations to data subjects, purpose limitation, appropriate security measures, and incident reporting within 72 hours. Model clauses such as the ASEAN Model Contractual Clauses (MCC) and the EU Standard Contractual Clauses (SCC) are indicated as usable.

Further, commentary states that cross-border transfer is not limited to physical transfer and may include transfer over the internet. It is worth pinning down here that placing a server overseas is not the only thing that counts as a cross-border transfer. Pasting an internal document into ChatGPT from a browser may also be assessed as a transfer if that document contains personal data.

In April 2025 the rules were finalised, with recipients outside Thailand reportedly required to demonstrate a level of protection equivalent to the PDPA.

A reservation belongs here. Whether a specific operation is organised under Section 28 or Section 29, and which model clauses are appropriate, is a judgement involving legal interpretation and findings of fact. This article goes as far as organising published information; treat the actual design as conditional on confirmation by your legal counsel and your Data Protection Officer (DPO).

An HQ contract does not make the local entity’s responsibility disappear

This is the point most often misread in practice. It is tempting to frame it as “HQ holds the Enterprise contract, so the local entity is simply a user.”

But for personal data collected in Thailand, the party standing as controller at the point of collection is the Thai entity. Who pays for the licence and who bears controller responsibility for that data are likely to be treated as separate questions. So even when riding on an HQ contract, the local entity needs to be in a position to answer the following.

• Whose personal data, of what kind, enters the workspace by which route
• On what basis (Section 28 or Section 29) that transfer is justified
• Whether, in an incident, the reporting path within 72 hours actually connects through to the HQ side
• Whether, faced with an audit or a data subject request, local staff can reach the information they need to respond

The fourth is the substantive weakness of a shared-workspace arrangement. When the log API and the admin console both sit on the HQ side, local staff cannot verify anything about their own company’s data without asking HQ. Whatever the contractual allocation of responsibility says, the regulator and the data subject will approach the local entity. It is worth checking in advance whether your structure builds in a time lag at that point.

Where the gaps tend to open at the policy level is set out in Generative AI Usage Policy 2026 — four gaps where the HQ version fails at a Thai site. The places where translating the HQ policy verbatim leaves holes map almost one for one onto the four questions above.

Four models — which legal entity’s workspace do you run on

From here the options are organised into four. The key point is that they are cut along the contracting entity axis, not the plan axis (Business / Enterprise).

A. Riding on HQ Enterprise

HQ already holds an Enterprise workspace, and accounts for local staff are added into it. This is probably the arrangement Japanese-owned groups adopt most readily.

It suits cases where local use is an extension of HQ work. Referencing HQ technical documents, handling group-standard forms, mostly writing reports in Japanese. For that kind of use there is little need to separate the boundary, and you get the full benefit of Enterprise governance features.

It does not suit cases where personal data collected in Thailand is expected to be handled — HR records of Thai employees, local customer contact details, transaction records with local suppliers. The fourth question in the previous section becomes one the local entity cannot answer on its own.

Section 29 accountability may remain with the local entity even when the contract sits with HQ. That is the weak point of this arrangement, and it means the HQ IT department and the local administration department need to document the verification procedure and the communication path in advance.

What you discard when you move is substantial. If you separate into B (local entity standalone), there is no way to move local members’ conversation history, the custom GPTs grown locally, or uploaded knowledge. The longer the arrangement has been running, the more you discard.

B. Local entity on Business alone

The Thai entity contracts for ChatGPT Business itself and holds its own workspace. Since it can start from a minimum of 2 seats, the initial barrier is the lowest of the four.

It suits cases where use is self-contained within Thailand. Document drafting by local staff, translation between Thai and Japanese, drafts for local customer correspondence. Administration sits with the local IT or administration department, and they can read their own logs. It is a structure where the four questions above can be answered without outside help.

It does not suit scales where the absence of SCIM starts to bite. Heavy joiner-leaver traffic, frequent departmental moves, seats being lent back and forth. In that environment, manual permission management becomes a breeding ground for incidents. It also fails the requirement if you are in a position where an audit asks for CMEK or an IP allowlist.

Section 29 accountability is easier to organise here, since the contracting entity and the administrator are the same party. That does not make the responsibility lighter, though — the cross-border transfer still occurs in exactly the same way. Because data residency is unavailable, arrangement B still needs a Section 29 design.

What you discard when you move arises in the same way if you move towards A. Because assets built in a standalone local workspace are tightly bound to local work, however, riding on HQ later means rebuilding them on the HQ side, which tends to meet stronger psychological resistance.

C. Coexistence (HQ Enterprise + local Business)

An arrangement split by use case. HQ-linked work runs on HQ Enterprise, work involving local personal data runs on local Business.

It suits cases where both types of work genuinely exist and the dividing criterion can be written down. You need a criterion staff can apply without hesitation — “work touching HQ technical documents goes here; work touching Thai employee information goes there.”

It does not suit cases where that criterion cannot be written. Having two boundaries also means an incident where something is thrown to the wrong side can happen. And once it has, which side it landed on is hard to trace after the fact.

Section 29 accountability is organised differently depending on which workspace each piece of work passed through. This is the arrangement with the heaviest record-keeping burden.

What you discard when you move is the assets of whichever side you consolidate away from. The moment you decide to converge on A or B, one set of history is lost.

Note that the strongest reason to choose this arrangement is not cost — it is that it can be justified as an intermediate stage of a migration. For a company already running the equivalent of A that wants to carve out only the handling of local personal data, C is a realistic landing point.

D. API + in-house UI

Rather than the ChatGPT interface, you build your own UI on the API Platform. The API Platform is included among the services covered by data residency alongside Enterprise and Edu (though, again, Thailand is not among the covered regions).

It suits cases where connecting to business systems is the primary aim. Letting it reference production management data, combining it with internal document search, embedding it inside an existing operational screen. Because billing is usage-based rather than per-seat, it also suits use cases with many users each using it lightly. Most enquiries that arrive under the heading of an internal AI build in fact describe this model D. The requirement is not a general-purpose chat interface — it is getting answers grounded in the company’s own data.

It does not suit cases where it is expected to replace general-purpose chat. Reproducing what the ChatGPT interface offers takes real development, and you then have to keep pace with feature additions upstream.

Section 29 accountability gets heavier, if anything. Building your own UI means log retention, access control, and the handling of inputs all become your own design responsibility. The more design freedom you gain, the more there is to account for.

What you discard when you move is the UI you developed and the operational assets around it. Decide to converge on ChatGPT itself and the build cost stays on the books, unrecovered.

Why “local entity on Enterprise alone” is not among the four models

This question comes up naturally, so it is worth addressing directly. If the Thai entity contracts for Enterprise itself, the contracting entity and the administrator both sit locally, and you get the governance features too. In principle it is the cleanest reasoning of all.

The problem is seat count. No floor has been published, but applying the roughly 150 seats repeatedly reported in procurement practice, it stops making sense for a company that only deploys 40 seats. Hypothetically, a five-year contract for 150 seats at USD 55 comes to USD 495,000 in seat costs alone. Divided across the 40 people who actually use it, that is USD 206.25 per person per month. At USD 50 it is USD 187.50 per month; at USD 60, USD 225.00.

This calculation shows what follows if a 150-seat floor applies, and since that floor is not a published condition, individual negotiation may still make it work. Even so, it is not an arrangement you can put into an approval request as a standard assumption, which is why it is left out of the four models here. If you do want to consider local-entity Enterprise at a 40-seat scale, the commercial discussion starts with confirming the seat-count condition.

Comparing five-year TCO across the four models

What follows is a thought experiment. The assumptions are stated, and the formulas are disclosed.

Model company assumptions

Everything below consists of assumption values set by the author, not data from a real company. They are different in nature from the published figures cited so far (Business pricing, the Enterprise market level, feature differences, residency, PDPA).

All calculations are performed in USD, and the THB conversion applies “×33.1” once, to the final total only. Individual line items are deliberately not converted along the way, because each additional conversion adds rounding error and misreading.

The seat breakdown for model C is 10 HQ Enterprise seats + 30 local Business seats = 40 seats in total (no duplicate holdings for people with dual roles). For model D’s usage-based API spend, the assumption is USD 8 per month per seat-equivalent. That too is an assumption value, and actual consumption varies widely by use case.

Five-year totals and breakdown

The formula for each line comes first.

• A seat cost: 40 seats × USD 55 × 12 months × 5 years = USD 132,000
• B seat cost: 40 seats × USD 20 × 12 months × 5 years = USD 48,000
• C seat cost: (10 seats × USD 55 × 60 months) + (30 seats × USD 20 × 60 months) = 33,000 + 36,000 = USD 69,000
• D API usage: 40 seat-equivalents × USD 8 × 12 months × 5 years = USD 19,200

Internal labour splits into initial setup and ongoing administration. The rate is a flat USD 15/hour.

• Initial setup: A 40 hours = 600 / B 60 hours = 900 / C 100 hours = 1,500 / D 200 hours = 3,000 (USD)
• Ongoing administration (hours per month × 60 months): A 3 hours = 2,700 / B 5 hours = 4,500 / C 8 hours = 7,200 / D 16 hours = 14,400 (USD)

A has the smallest ongoing effort because seat issuance is handled by asking HQ. B is larger because there is no SCIM and joiners and leavers are processed by hand; C is larger because there are two boundaries; D is the largest because you run and monitor your own UI. D also carries outsourced costs — an initial build of USD 30,000 and annual maintenance of USD 5,000 × 5 years = USD 25,000. Maintenance is assumed to accrue at full rate from the first year of the build (under a phased contract, the first year would be smaller than this).

It is worth also looking at how this appears year by year. Approvals go through annual budgets, so separating the first year from subsequent years fits practice better.

The bottom row matches the table above. D alone spikes in the first year and then becomes the lightest from the second year on. The assessment of D is decided almost entirely by how you view the USD 30,000 initial build assumption. That figure can double or halve depending on requirements, so in a real decision, drop your own quotation in there and recalculate.

How much the Enterprise price band moves the total

With Enterprise, the unit price is not fixed until a quote arrives. Feeding the reported USD 45–75 band straight through to the totals gives the following.

What deserves attention is the width itself. Looking only at A’s seat cost, it is USD 108,000 at USD 45 and USD 180,000 at USD 75. The gap is USD 72,000, which exceeds B’s entire five-year total of USD 53,400.

Meaning that if you are considering A, the conclusion can turn on “what number comes back in the quote” before it turns on “Enterprise or not.” Push A through approval as the default path before the quote arrives, and there is no way back when the unit price comes in high. Calculate the total for arrangement B before you request the Enterprise quote. That ordering alone gives you one more piece of leverage in the negotiation.

C is far less sensitive to the unit price. Because it carries only 10 Enterprise seats, the spread across the whole USD 45–75 band stays at USD 18,000. If you want to contain unit-price uncertainty, C holds its own as an option on that basis.

Converting the gap into hours

A difference in money is not a decision criterion by itself. What the difference is exchanged for has to be expressed in a common unit. Here we divide by the internal labour rate of USD 15/hour and convert to hours.

• A − B: a gap of USD 81,900. Divided by USD 15/hour, that is 5,460 hours. Divided again across 40 seats and 60 months, it is 2.275 hours per seat per month.
• C − B: a gap of USD 24,300. That is 1,620 hours, or 0.675 hours per seat per month.
• D − B: a gap of USD 38,200. That is approximately 2,547 hours, or approximately 1.06 hours per seat per month.

Here is how to read that. If you pick A over B, you need to be able to explain that Enterprise governance features and SCIM are worth 2.275 hours per seat per month. That is not an estimate of the benefit — it is the height of the bar the approval request has to clear.

This conversion is only a way of restating the cost gap in a familiar unit; it is not a claim that “choosing A saves 2.275 hours a month.” The direction runs the other way. The gap exists first, and it is on us to supply the reasons that justify it.

Why no payback period appears here

This article does not produce an investment payback period. There is one reason. We have no published data to ground the denominator, the hours saved per seat.

We could put a number there if we wanted to. Assume “5 hours saved per person per month” and you can build a tidy table where every model pays back within a few years. But what that table shows is not the economics of ChatGPT — it is the consequence of the assumption we chose. Presenting a calculation whose payback period doubles or halves on a single assumption as if it were decision material is not something we consider honest.

What you can use instead is the hurdle conversion in the previous section. Rather than estimating the benefit, put out first what benefit would be required to justify this cost gap. Then put your own pilot results into the numerator and decide. In that order, you avoid the accident where the assumption manufactures the conclusion.

One further note on the baseline. This model treats the current state (no generative AI deployed) as a single baseline, and discusses benefit only as the delta from it. Adding up “labour cost freed up” and “overtime reduced” as separate lines is the classic way of counting the same benefit twice, so it is avoided here.

The order of operations — four questions to settle first

Now to turn all of this into a practical sequence. There are four questions to answer before comparing plans.

Question 1 — will personal data collected in Thailand enter it

This is the first fork. If you can say with confidence that it will not, your options widen. If it will, or if you cannot rule out that it might, arrangements that place the administrator and the records on the local side (B, C, D) take priority.

The judgement has to be made on “is there a route by which it could end up in there,” not on “do we plan to put it in there.” Pasting HR records in, having a customer enquiry email summarised, throwing in minutes containing a supplier contact’s name. Enumerating the routes that arise naturally in day-to-day use is, in substance, the whole of this question.

Question 2 — when do you stand it up

As set out in Reason 1, data residency can only be set on a new workspace. So you cannot build a schedule on the premise of “adding region selection later if it turns out we need it.”

There are two realistic approaches. If you can determine that region selection is required, stand the workspace up under that condition from the start. If you cannot yet determine it, decide up front that you will test on a throwaway evaluation workspace and stand production up separately. The bad outcome is the pattern where the workspace built for evaluation drifts into being production. That is the most common one.

Question 3 — who becomes the administrator

Decide who accesses the admin console, extracts logs, and moves seats in and out. If you choose the shared arrangement (A), the procedure and turnaround time for local staff to raise a request with HQ needs to be documented in advance.

There is a large difference between a request that comes back the next day and one that takes a week. Given the 72-hour incident reporting in the Section 29 notification, a path that takes a week to confirm anything may not meet the requirement.

Question 4 — what do you keep

List what will be discarded on migration, in advance. Conversation history, custom GPTs, uploaded knowledge. Taking as given that these cannot be moved, design where to keep things on the assumption that they cannot be moved.

The realistic mitigation is to hold the important prompts and knowledge outside the workspace — on a shared drive or an internal wiki — as the authoritative copy, and put duplicates into the workspace. It adds effort, but it sharply reduces the cost of a decision to rebuild the workspace. Getting that practice to stick is the hardest part, and it connects directly to the adoption problems covered in Four Reasons Generative AI Training Fails to Stick.

Restating the four questions alongside what happens if you proceed without settling them gives the following.

• Leave Question 1 (will personal data enter it) unsettled, and local data flows in while you are still on the shared arrangement; by the time you notice, separation is required. The cost of separation is as set out in Reason 3.
• Leave Question 2 (when to stand it up) unsettled, and the evaluation workspace drifts into production, removing any room to choose region selection.
• Leave Question 3 (who is administrator) unsettled, and in an incident the local entity cannot establish the facts on its own, turning it into a race against the reporting deadline.
• Leave Question 4 (what to keep) unsettled, and you rebuild your knowledge every time the arrangement changes.

None of these cost money to settle. What they cost is the time to get the right people in a room and agree.

The split with Microsoft 365 Copilot comes down to where things live

At companies already on Microsoft 365, a comparison with Microsoft 365 Copilot always comes up. It is not the subject of this article, so it is touched on only from the boundary angle.

Microsoft 365 Copilot runs inside the existing Microsoft 365 tenant. That means no decision to create a new workspace arises — you use the tenant, an existing boundary, as it stands. Put the other way, the permission settings inside the tenant become the reference scope of the generative AI directly, so the question shifts to auditing access rights. That is covered in detail in How to Approach a Microsoft Copilot Implementation in 2026 — cost and the pressure points of permission design.

Summarised from this article’s perspective, the difference is that Copilot uses a boundary that already exists, whereas corporate use of ChatGPT draws a new one. The former saves you the work of drawing a boundary, at the price of exposing whatever coarseness exists in your current permission design. The latter lets you choose the boundary, at the price of that choice becoming irreversibly fixed. Which is more favourable depends on how well organised the permissions in your existing tenant already are.

For the infrastructure side — what changes in cost and in the scope you can protect depending on where you put what — see Secure Generative AI Environments 2026 — three architectures, their cost, and what each protects. How AI adoption fits together across a Thai operation as a whole is set out in AI Adoption in Thailand 2026.

Pre-implementation checklist

These are the items to confirm before signing, extracted from the content of this article.

Frequently asked questions

How much does a ChatGPT enterprise implementation cost?

ChatGPT Business has published pricing — USD 20 per seat per month (annual contract), USD 25 per seat per month (monthly contract), from a minimum of 2 seats. ChatGPT Enterprise has no published price and is quoted individually; reporting on 2026 deals puts it at USD 45–75 per seat per month, with most landing in USD 50–60.

Estimating five-year totals for the model company in this article (Japanese-owned manufacturer in Thailand, 300 employees, 40 seats deployed) and including internal labour gives A, riding on HQ Enterprise, USD 135,300; B, local entity on Business alone, USD 53,400; C, coexistence, USD 77,700; and D, API + in-house UI, USD 91,600 (all assuming an Enterprise unit price of USD 55). Converted to THB (×33.1) those are approximately THB 4,478,430, THB 1,767,540, THB 2,571,870, and THB 3,031,960 respectively. Licence costs alone spread the gap further, but because some arrangements — D in particular — are dominated by internal labour and build cost, comparing per-seat prices alone does not settle the ranking.

What is the difference between Business and Enterprise?

It is governance features, not output quality. Neither uses customer data to train models by default. Business also supports SAML / OIDC SSO and domain verification.

What only Enterprise has is SCIM automated provisioning, customer-managed encryption keys (CMEK), an IP allowlist, data residency, the compliance API / log API, a 24/7/365 SLA, and ISO 27001. So the selection criterion is not “do we need it to be smarter” but “do we need to handle audit logs and permission automation mechanically.”

How should a Thai site handle this under the PDPA?

First, data residency does not solve it. Thailand is not among OpenAI’s residency regions (in Asia the list is Japan, Singapore, South Korea, and India), and the scope covers stored data (at rest) only, with inference reported to run by default on US infrastructure.

The question therefore moves to the cross-border transfer framework. The PDPC’s Section 28 and Section 29 notifications were published on December 25, 2023, and came into force on March 24, 2024. If the destination country has a legal regime at least equivalent, Section 28 applies; if not, you work through the appropriate safeguards under Section 29 (contractual clauses covering notification to data subjects, purpose limitation, appropriate security measures, and incident reporting within 72 hours, with model clauses such as the ASEAN MCC or EU SCC usable). The interpretation that transfer over the internet may also be assessed as a cross-border transfer carries weight in practice. Because organising a specific case involves legal interpretation, treat this as conditional on confirmation by your legal counsel and your Data Protection Officer (DPO).

Should we ride on HQ’s Enterprise contract?

If the use case does not involve personal data collected in Thailand, it is a reasonable choice. The local entity gets to use those governance features within the scope of the HQ contract without signing its own Enterprise deal, and local operational effort is minimised. The seat cost does not disappear, though — across the group it lands at the highest level of the four models, as the estimates here show. It is a question of allocation, of whether the local entity or HQ carries it.

If the use case does involve such data, you need to build the verification procedure first. Because the admin console and the log API both sit on the HQ side, local staff cannot verify anything about their own data without going through HQ. We would suggest testing in advance whether that path can keep up in a situation requiring reporting within 72 hours.

And if you later unwind the shared arrangement, conversation history, custom GPTs, and knowledge cannot be moved. Since the longer it runs the more you discard, a plan of “start on the shared workspace and split later” needs that separation cost built in from the outset.

Is ChatGPT training necessary?

If training means teaching people how to write prompts, the priority is not especially high. What is needed from this article’s perspective is putting staff in a position where they can decide without hesitation what may go into which workspace. Particularly if you choose the coexistence arrangement (C), there are two boundaries, so sharing the decision criterion is itself the core of operations.

The typical reason training fails to stick is that the content is too generic to connect to the company’s actual work. That point is worked through in Four Reasons Generative AI Training Fails to Stick.

Summary

What a ChatGPT enterprise implementation really settles is not the plan choice between Business and Enterprise. It is which legal entity opens the workspace, and when. The plan can be changed later; the boundary, in practice, cannot be redrawn afterwards.

There are three grounds for that irreversibility. First, data residency can only be set on new ChatGPT Enterprise / Edu workspaces and cannot be added to an existing workspace after the fact. Second, Thailand is not among the residency regions (in Asia the list is Japan, Singapore, South Korea, and India), and the scope covers stored data only, with inference running by default on US infrastructure — so there is no route to discharging PDPA obligations by choosing a storage location. Third, conversation history, custom GPTs, and knowledge cannot cross workspaces, so changing the arrangement later means discarding everything built up until then.

On cost, the estimates for the model company (300 employees, 40 seats deployed, 5 years) came out at A, riding on HQ Enterprise, USD 135,300; B, local entity on Business alone, USD 53,400; C, coexistence, USD 77,700; and D, API + in-house UI, USD 91,600. But the Enterprise unit price band (USD 45–75) alone moves A between USD 111,300 and USD 183,300, and that USD 72,000 spread exceeds B’s five-year total of USD 53,400. Calculating the total for arrangement B before you request the Enterprise quote pays off in both the negotiation and the approval process.

Among Japanese companies, generative AI use and promotion stood at 87% as of spring 2026 (up 11 points on the previous survey), with those not started or having abandoned it at just 4% (PwC Japan). In Thailand, more than 70% of organisations have adopted it or plan to (ETDA survey). The debate over whether to adopt is, statistically at least, approaching a conclusion. What remains is the design question of where to draw the boundary.

There is no need to rush. Just answer the four questions in this article before you stand up the first workspace. That alone avoids most of the situations where, a year from now, there is no way back.

TOMAS TECH is based in Bangkok and supports Japanese-owned manufacturers across factory IT, OT/IoT, and factory automation. On corporate use of ChatGPT, we can also get involved at the stage before product selection — working out roughly where the workspace should sit between HQ and the local entity, and by what routes local personal data could enter it. That includes how it should be divided against an existing Microsoft 365 environment, and how site-specific circumstances change the picture. You are welcome to reach us through our contact page.

References

• eesel AI | ChatGPT for Work pricing — https://www.eesel.ai/blog/chatgpt-work-pricing
• Carly | ChatGPT Business — https://www.usecarly.com/blog/chatgpt-business/
• Inference.net | ChatGPT Enterprise Pricing — https://inference.net/content/chatgpt-enterprise-pricing/
• Computerworld | OpenAI expands data residency for enterprise customers (November 26, 2025) — https://www.computerworld.com/article/4096675/openai-expands-data-residency-for-enterprise-customers.html
• OpenAI | Introducing data residency in Asia — https://openai.com/index/introducing-data-residency-in-asia/
• TMI Associates | Thailand PDPA notifications on cross-border transfer — https://www.tmi.gr.jp/eyes/blog/2024/15449.html
• Technica Zen | Cross-border transfer rules under Thailand’s PDPA — https://m.technica-zen.com/13839/
• th-biz.com | Thailand legal update — https://th-biz.com/law-202604/
• PwC Japan | Generative AI survey, spring 2026 — https://www.pwc.com/jp/ja/knowledge/thoughtleadership/generative-ai-survey2026.html
• JCIPO | Generative AI adoption trends in Thailand (ETDA survey) — https://www.jcipo.org/theme34/
• Trading Economics | Thailand Currency (as of August 11, 2026) — https://tradingeconomics.com/thailand/currency