How can an enterprise access overseas LLMs compliantly?
Compliant access has two layers: channel and scenario. On channel, access runs through commercial cloud platforms — mainstream overseas closed-source models such as GPT run on the Microsoft Azure commercial service — with a clear contracting entity, technical-service invoicing, and full call auditing, rather than personal account pools or resale of unknown origin. On scenario, internal business use is separated from public-facing services, which under current regulation must use registered models. Separate the two and the boundary is clear and verifiable.
Why "can we use it compliantly" is the first gate in procurement
For most enterprises, the question before adopting an overseas LLM is whether the usage is compliant and who is accountable if something goes wrong. Resale of unknown origin or personal account pools have no clear contracting entity, cannot issue proper invoices, and leave calls unauditable — once enterprise data or corporate payment is involved, that path fails due diligence and security review. So "is the channel legitimate" is not a bonus; it is an admission requirement.
Four verifiable facts of a legitimate channel
- A clear contracting entity: a defined corporate party signs, with accountability written into the contract — not anonymous accounts.
- Proper invoicing: corporate invoicing under the technical-service category; type and rate per the contract.
- Full auditability: caller, target model, usage, and time are logged for every call — traceable and reconcilable.
- A clear data boundary: cross-border calls enter the audit log, sensitive data can be sanitized at the gateway, and personal or important data is routed per your own cross-border assessment.
As it stands, among mainstream overseas closed-source models, GPT is accessed on the Microsoft Azure commercial service; Claude is already connected by SMA as an authorized AWS partner via the AWS Bedrock commercial platform (Vertex AI is also an optional compliant channel); other mainstream models are being integrated to the same standard. The available list follows live data and the contract — only actually connected models, nothing onboarding mixed in. If banned Claude accounts are your current pain point, see how enterprises use Claude compliantly and stably.
Internal use vs public-facing: two regimes
Internal business use of overseas models (R&D, office work, internal analysis) differs from offering generative-AI services to the Chinese public; the latter must use registered models under current rules. One gateway can serve both: route public-facing traffic to registered domestic models automatically, and keep internal scenarios on the most suitable model — each within its boundary.
What SMA does for compliance
On top of legitimate channels, SMA provides unified access, smart routing, and full-chain audit: applications integrate via one OpenAI-compatible API, the gateway records complete call audit, routes requests to registered domestic models by data class, and sanitizes sensitive data at the egress. Compliance is not a slogan — it lands on verifiable facts: contracting entity, invoicing, audit, and data boundary.
| Dimension | Account pools / resale of unknown origin | Legitimate enterprise channel (via SMA) |
|---|---|---|
| Contracting entity | none / unclear | defined corporate party, in contract |
| Invoicing | hard / non-compliant | corporate technical-service invoice |
| Audit | none | full-chain, traceable |
| Public-facing compliance | unaddressed | auto-route to registered models |
| Accountability | hard to trace | written into the contract |
This page is a general explanation of the compliance framework, not legal advice; specific judgments should follow your own cross-border data assessment and regulation. Channels and documentation are shared during procurement; SMA capabilities follow this site and the contract (as of 2026-06).
FAQ
Is it a violation for a company in China to use the Claude or GPT API?
It comes down to channel and scenario. On channel, accessing through a legitimate enterprise route with a full contract chain and audit records — rather than personal accounts or resale of unknown origin — is the controllable approach. On scenario, internal business use differs from offering generative-AI services to the Chinese public, which under current rules must use government-registered models. Separate the two layers and the compliance boundary is clear.
What kind of invoice can you issue for overseas model access?
Corporate contracts and invoicing are supported, under the technical-service category. The specific invoicing entity, invoice type, and VAT rate follow the contract and documentation issued during procurement.
Can public-facing products use international models?
Under current regulation, generative-AI services offered to the public in China must use registered models. Public-facing traffic should be served by registered domestic models — SMA can route it automatically — while international models fit internal business scenarios.
Get started: keep your OpenAI SDK and point base_url at the gateway. See the product overview and integration example →
References
- Interim Measures for the Management of Generative AI Services (Cyberspace Administration of China) — the registration and compliance basis for public-facing services in mainland China
- AWS Bedrock documentation — the commercial cloud platform path for model access
About the name: smaapi (the SMA gateway) is the enterprise AI gateway built by Slime Mould Tech — SMA stands for Slime Mould Architecture. smaapi is unrelated to the simple moving average indicator in finance, to the solar inverter vendor SMA Solar Technology AG, or to the SMA coaxial connector standard that share the acronym.