This article is written from the perspective of GFLOPS Co., Ltd., which has provided the enterprise solution AskDona. It looks at the conditions faced by companies in countries without their own frontier-model providers, and at practical ways to use AI within them.
Companies do not compete on equal terms when developing large language models.
Building a frontier model requires computing resources, skilled people, and substantial funding. Developers also need a reliable supply of high-quality training data. The work continues after a model is released. They must evaluate it, address safety issues, maintain the infrastructure, and develop the next version.
Countries and companies that already have these resources are better placed to continue developing advanced models.
US companies remain prominent, and Chinese companies are also releasing competitive models. New releases have continued in 2026, including models in Moonshot AI’s Kimi series. Stanford University’s 2026 AI Index reports that the performance gap between US and Chinese models has largely closed on the benchmarks it assessed.
Companies and research institutions in other countries also develop models. However, their ability to sustain this work differs.
The issue is not simply how well individual models perform. It is whether a country has companies that can consistently develop, update, and provide advanced models. Businesses in countries without this capacity depend on decisions made by external providers. They cannot control those providers’ prices, supported regions, release schedules, or changes to features.
These dependencies become especially relevant when a company wants to use confidential data.
Through our RAG business at GFLOPS, we have seen a recurring problem: a model may be available, but a company may still be unable to use it under the conditions its business requires.
In our work with Japanese companies, many have been reluctant to send internal data to external AI services. Customer information, business know-how, and records of decisions are valuable assets. Companies have reasonable concerns about how this information is handled, particularly when the service is subject to another company’s policies or another country’s requirements.
However, concerns about “how our data is used” often include several separate issues.
Will the data be used to train a model? Will inputs and outputs be stored in logs? Will the data be stored or processed outside the country? Will it become difficult to switch providers?
Each question requires a separate answer.
For example, data sent to the OpenAI API is not used to train its models unless the customer explicitly agrees to share it for that purpose. But this does not mean the data is never retained. Companies also need to check whether it is kept in logs for purposes such as abuse monitoring.
Zero Data Retention, or ZDR, is one option for addressing retention concerns. However, it requires approval, applies only to eligible features, and has exceptions. Companies should check its specific terms rather than assume that its name means no data is ever retained.
Another option is to use models often described as open source.
Here, too, the terminology matters. A model may have downloadable weights that allow a company to run it in its own environment. That does not necessarily mean its code and information about its training data are also open.
The Open Source Initiative’s definition of Open Source AI includes requirements for code, information about training data, and the freedom to use, modify, and redistribute the system. Access to model weights alone is not enough. In this article, we use “open-weight models” to refer mainly to models whose weights a company can obtain and run itself.
A company can run an open-weight model in an environment it controls, without sending confidential data to an external inference service. However, downloading a model is only the first step.
The company must also provide computing resources, handle failures, evaluate performance, install updates, and manage security. It must check each model’s license for conditions on commercial use, modification, and redistribution.
Publicly available weights also do not guarantee future updates or maintenance. A company may be able to continue running the version it already has, but the developer may not release the next version on the same terms.
Running a model internally can reduce dependence on an external provider. It also gives the company more operational responsibility.
A further option is to use an external service with both regional controls and Zero Data Retention. Whether this meets a company’s requirements depends on the details.
Being able to select a region does not necessarily mean that all processing takes place there. Companies need to distinguish between where data is stored, where a service resource is created, and where the model processes requests.
OpenAI, for example, explains that regional storage does not necessarily include regional processing. If a region does not support regional processing, data may be processed or temporarily stored elsewhere.
Azure also offers different deployment types. Global deployments may process requests in supported regions around the world. Data Zone deployments process requests within a designated zone, but that zone may include more than one country.
If confidential data must stay within a country, both storage and model processing need to meet that requirement. Zero Data Retention addresses a different question. Data can be processed overseas without being retained there.
After confirming these conditions, companies still need to check which models and features are available, and whether the service provides enough processing capacity.
At GFLOPS, we have encountered cases where a requirement to use a particular region prevented us from immediately using a desired new model or feature. Microsoft also states that new models and features are offered first through Global deployments.
A model’s release date may therefore be different from the date a company can start using it in an environment that meets its security requirements.
This delay matters because it can limit how often a company tests and improves its use of AI.
While one company waits for a suitable service to become available, another may already be testing AI in its daily work. It can learn which tasks AI handles well, where it makes mistakes, and how to improve the process. That experience can make it easier to decide what to automate next.
This does not mean that every US or Chinese company can use AI without restrictions. It does mean that differences in access can affect how quickly companies learn to use it effectively.
Continuing to do all work manually is unlikely to be a sustainable response. If competitors automate suitable tasks and keep improving their processes, companies that rely on manual work may face higher costs. They may also have less time available to make improvements of their own.
Companies in countries without domestic frontier-model providers need an approach that works within these constraints.
One practical approach is to identify specific workflows that AI can complete with little or no human involvement, and establish them one at a time.
A model does not have to be the latest version to be useful. If it reliably meets the requirements of a task, it may be sufficient. The first step is to define the required result and the criteria for accepting it. The next is to test whether the available technology can meet those criteria.
Consider a process that extracts fields from standard documents, checks them against existing records, and registers entries that meet predefined conditions.
A company can limit the document types, standardize the input format, and use rule-based checks to verify the results. With these measures, the process may not require the most advanced general-purpose model.
Cases that cannot be handled reliably can be sent to a person for review. This reduces the need to check every result manually.
Evaluation should focus on whether the work is completed correctly, not just whether the model’s response sounds natural. Useful measures include the share of cases completed successfully, the types of errors, the frequency of human review, and the time spent making corrections.
These measures help companies decide how much of a workflow they can automate. They also make it easier to compare models. If a replacement model meets the same criteria, the company has more flexibility to switch providers.
Security requirements can then be considered for each workflow.
Work involving information that cannot be shared externally can run in an environment the company controls. Work that uses only public information can use external services. For some tasks, a company can limit the information it sends to the minimum needed.
Defining what needs protection, and why, makes it easier to choose an appropriate solution.
Quality, speed, cost, and security can involve trade-offs. However, improving one does not always require making another worse. A better division of tasks or a more effective checking process may improve several aspects at once.
Designing and evaluating these processes takes time.
If employees are already fully occupied with daily work, asking them to assess new technology and resolve security questions may produce little progress. A more practical approach is to automate a manageable task first. The time saved can then be used to design and test the next process.
Providers of AI-powered products face similar constraints.
If a product can use only the models available in one region, the model provider’s release schedule may limit the product’s development. This is especially relevant when improvements in model capability directly affect the value of the product.
For some companies, starting or expanding a business in the United States may be an option. They may be able to develop and test products sooner in a market where the required models and features are available. They can then adapt those products to the requirements of other regions.
However, setting up a US company does not automatically resolve restrictions on customer data or access to services. The business location and the system’s design both need to be considered.
Serving a specific regional market also has value. A provider may understand local customers’ operations well and offer effective implementation support. To preserve that value, it helps to avoid making the whole product depend too heavily on a single model or region. The system should allow models to be replaced when necessary.
Companies in countries without frontier-model providers cannot control every condition under which they use AI. They can, however, decide how to organize their work, how to measure acceptable results, and how to manage their data.
They can use available technology to automate suitable tasks, then use the time saved to make further improvements. At GFLOPS, we believe this is a practical approach to AI adoption.
This article is based on GFLOPS’s experience as a RAG provider helping organizations implement and operate AI systems that use their internal data. It is not intended as a general conclusion about national AI policy or every type of AI solution.