Restricting AI Service Access by Ownership: Is It Reasonable?

1. The Core Issue: From Geofencing to Governance Boundaries

An AI model provider recently announced new policy on supported regions, scheduled to take effect on November 12. Earlier rules mainly relied on the country or region where a user is located. The new rules also consider where a company is registered, where its headquarters is, and whether it is directly or indirectly controlled by parties in other jurisdictions. As a result, access to AI model services no longer depends only on where the person is. It increasingly depends on who controls the company and which jurisdiction governs it.

Based on public information, the restrictions generally cover three situations. First, the user is located in an unsupported country or region. Even if the user’s company is registered in a supported region, the user may still be affected. Second, the company is registered or headquartered in an unsupported country or region, so its employees and users may be restricted. Third, the company is registered in a supported region but is directly or indirectly controlled or actually controlled by individuals or companies from an unsupported region. Its employees and users may also fall under the restrictions.

The policy typically targets majority ownership or actual control. A small amount of shareholding from an unsupported region does not automatically trigger restrictions. A company registered in Singapore, the United States, or Europe may still fall within scope if its ownership structure and control relationships meet the relevant conditions. The policy also covers more than web access. It may include code assistance tools, collaboration tools, API interfaces, and model services provided through cloud platforms and authorized channels. A company that does not use the provider’s website directly cannot simply switch access channels to get around the rules.

From a technical governance perspective, this shifts access control from IP-based geolocation to organization-level identity verification. Providers may need to identify ultimate beneficiaries, control chains, voting rights, board composition, concerted action relationships, and even data flows and model usage scenarios. This raises the requirements for enterprise compliance, procurement, and architecture design.

2. Why It Happens: Security Concerns in the AI Service Supply Chain

AI model services are not ordinary IT tools. They involve computing resources, data processing, and model output, and they may be used for code generation, knowledge processing, automated decision-making, and business collaboration. When providing model capabilities, providers must assess multiple risks, including export controls, cross-border data transfers, model misuse, and contract performance. Restricting access based on ownership and control shifts part of this compliance risk to the customer admission stage.

The logic is understandable. If a provider cannot confirm a customer’s actual control relationships, or believes certain control relationships pose unacceptable national security risks, it may choose a more conservative access policy. However, “national security” alone does not make a restriction reasonable. Several questions need answers: Is the threat model clearly defined? Are the restrictions proportionate to the risks? Are the rules transparent and predictable? Do ordinary companies have a way to appeal and seek remedies?

3. Assessing Reasonableness: Separating National Security, Commercial Rules, and Enterprise Rights

1. National security: proportionality and risk tiering

From a national security perspective, restricting access to sensitive technologies, sensitive data, and sensitive uses is understandable. Reasonable boundaries should still be as precise as possible. For example, the rules can distinguish high-risk uses from general office use, training on sensitive data from ordinary code assistance, and actual control from minor financial investment. If shareholder origin is the only criterion, and the company’s actual operating location, data storage location, employee composition, business use, and compliance record are ignored, the result may be an overbroad, one-size-fits-all restriction.

A better approach is a risk tiering matrix. Low-risk scenarios rely on declarations and audits. Medium-risk scenarios require disclosure of control relationships, data classification, and log retention. Only high-risk scenarios enter stricter approval or restriction. This addresses security concerns without unnecessarily affecting ordinary business activity.

2. Commercial contracts: providers have freedom of choice, but rules should be transparent

Providers are free to choose their customers and set terms of use. However, changes to existing contracts should come with a reasonable notice period, data migration assistance, and a refund or compensation mechanism. When procuring model services, enterprises should review usage restriction clauses, policy change clauses, data deletion obligations, liability limits, and dispute resolution methods. If rules are opaque or change frequently, enterprise supply chains face more uncertainty.

3. Enterprise legitimate rights: overseas-registered companies should not be simply labeled

Should a company registered overseas, operating locally, and employing local staff lose eligibility to use an AI service only because its controlling shareholder comes from China? This is the core question. National security, commercial rules, and the legitimate rights of ordinary companies should be discussed separately. For ordinary companies, predictability and non-discrimination matter most. For providers, a clear compliance path is needed, such as control relationship declarations, use case descriptions, audit certifications, allowlists, or exemption mechanisms.

4. Enterprise Response: Compliance, Contracts, and Architecture in Parallel

Enterprises can start with the following checklist:

• Map the control structure: direct and indirect shareholdings, voting rights, board seats, ultimate controllers, and concerted action arrangements.
• Identify service coverage: web access, code assistance, collaboration tools, APIs, cloud platforms, and authorized channels.
• Review contract terms: usage restrictions, change notification, data deletion, migration assistance, and liability limits.
• Build a model gateway: unified interface, routing policy, fallback plans, key management, and audit logging.
• Strengthen data governance: classification and grading, cross-border assessment, masking of sensitive data, and cache and log retention.
• Manage supplier risk: evaluate multiple providers, abstract the calling interface, and assess self-hosted or open-source options. Also evaluate their compliance and capability limits.

The following pseudocode illustrates the logic of an access check. It is for illustration only and does not represent any vendor’s interface.

def is_service_allowed(user, org, policy):
    if user.region not in policy.supported_regions:
        return False
    if org.registration_region not in policy.supported_regions:
        return False
    if org.hq_region not in policy.supported_regions:
        return False
    controllers = resolve_ultimate_controllers(org)
    if any(c.region not in policy.supported_regions
           and c.ratio >= policy.majority_threshold
           for c in controllers):
        return False
    return True

Real decisions must also handle complex cases such as indirect control, voting power, board control, and concerted action. Enterprises should review these cases with legal counsel.

5. Conclusion: Reasonableness Depends on Proportionality, Transparency, and Remedies

Restricting AI service access by ownership structure reflects a shift in global AI governance, from geographic boundaries to organizational governance boundaries. National security can justify restrictions, but they should be as precise and transparent as possible, with appeal and exemption mechanisms retained. Commercial rules should be predictable, and contract changes should come with reasonable transition periods. The legitimate rights of ordinary companies also deserve serious consideration. For developers and enterprises, the most practical strategy is to build resilience into the model service supply chain. Abstract the calling layer, prepare replaceable alternatives, strengthen audit logging, classify data, and move compliance assessment into procurement and architecture design.