Opinion — CLOUD Act and Law 21,719: the sovereignty dilemma few Chilean boards are discussing (yet)

The use of artificial intelligence inside Chilean companies triggers a jurisdictional dilemma that boards rarely record in their minutes. Analysis of the structural tension between the US CLOUD Act and Chile's Law 21,719, and of the architectural decisions that tension requires the board to document before each deployment.

The opinions expressed in this column belong to its authors and do not constitute legal advice on a specific matter. The opinions are those of the firm, not of any individual author. Contributors to this analysis: Eduardo Anguita Osorio, María Victoria Smith and Ángel Anguita Osorio.

The starting point

Nearly every Chilean company running a language model in production today relies on a provider domiciled in the United States: OpenAI, Anthropic, Microsoft (Azure OpenAI), Amazon (Bedrock), or Google (Vertex). That decision is usually treated as a product choice, not as a governance choice. The omission matters: under the CLOUD Act, that choice can expose the organization's data, its clients' data, and its employees' data to demands issued by US authorities, where the provider is subject to that jurisdiction.

The dilemma that rarely makes it into board minutes is the following: deploying AI with market-leading providers usually means accepting, at minimum, a level of exposure to US jurisdiction over the data processed by the system. Opting for jurisdictional independence reduces, today, what the system can do. That decision exists and is already being made, but rarely with the board in the room.

What the CLOUD Act requires

The Clarifying Lawful Overseas Use of Data Act of 2018 authorizes US authorities to compel a service provider under US jurisdiction to disclose data stored or processed in its infrastructure, regardless of the physical country where that data resides. The rule can reach providers, subsidiaries, or entities under US control or jurisdiction, depending on the contractual, corporate, and technical structure of the service. In practice, a US court order can require disclosure of Chilean data hosted in a European or South American data center if the provider answers to a US parent.

The instrument includes a relevant accessory tool: the gag order. The provider may be legally barred from notifying the affected client for the period set by the authority. That means a Chilean company might not be informed in a timely manner of a demand or access by a foreign authority, where the provider is legally barred from notifying it.

What Law 21,719 requires

Law 21,719, in force since 1 December 2026, keeps with the data controller duties that are not extinguished by the mere engagement of a technology provider: accountability, records of processing activities, impact assessment for large-scale or sensitive processing, breach notification, and respect for the data subject's right not to be subject to solely automated decisions with legal or similarly significant effect. Faced with compelled access by a foreign authority, that set remains enforceable against the Chilean controller.

Three friction points become immediate. First, when the use case involves sensitive data under Article 2(g) of Law 21,719 (health, biometric, detailed socioeconomic situation, data of children and adolescents, among others), the model exposes that data to the reach of the CLOUD Act without the company being able to claim informed consent from the data subject for that flow. Second, the existence of a notification ban can hinder or temporarily prevent the traceability, assessment, and eventual communication of relevant incidents or access events to the Agency and to data subjects. Third, attorney-client privilege and the duty of confidentiality toward clients and employees are structurally compromised when prompts and outputs are processed by a system subject to foreign compulsion.

The false comfort of an EU or LatAm region

A frequent response from legal teams is to select European or South American deployment regions and log the risk as mitigated. The geographic residency of the data reduces some vectors (latency, the regional provider's contractual framework, local certifications) but does not neutralize the CLOUD Act. The rule attaches to the provider's jurisdiction, not to the physical location of the server. As long as the parent answers to US law, region is a relevant technical decision, but not necessarily sufficient to resolve the jurisdictional risk.

EU- and Asia-domiciled providers

Stepping outside the reach of the CLOUD Act requires a change of jurisdiction, not of region. Alternatives with parent companies outside the United States deserve an honest mapping.

EU-domiciled providers (Mistral AI in France, Aleph Alpha in Germany, and services built on those model families) operate under the General Data Protection Regulation and, in principle, are not subject to the CLOUD Act by that condition alone, without prejudice to reviewing their corporate structure, subprocessors, infrastructure, and ties to US providers. International transfer from Chile still requires analysis under Law 21,719 and the equivalent mechanisms the Agency adopts, but the structural jurisdictional conflict disappears. The cost is real: a narrower model catalog than the US commercial frontier, a smaller commercial footprint in Chile, a thinner integration ecosystem, and higher latency in many cases.

Asia-domiciled providers require a clear distinction. Models with parents in the People's Republic of China (Alibaba's Qwen, DeepSeek, 01.AI's Yi) are subject to that country's Data Security Law and National Intelligence Law, which authorize compelled access by Chinese authorities under a less transparent framework than the US one. The question is not whether jurisdictional risk exists, but which jurisdiction is being chosen. For sensitive data and for use cases with regulatory exposure in Chile, a Chinese parent can generate a distinct jurisdictional risk, but one functionally comparable in terms of potential state access demands. Providers domiciled in Japan, South Korea, or Singapore present less asymmetric profiles, but with catalog and local presence that remain limited.

The practical takeaway is the following. When the priority is jurisdictional independence from the United States without giving up a mature commercial provider, European models are today the alternative with the best capability/risk ratio. When the priority is maximum sovereignty over sensitive data, the first pattern (local deployment with open models) remains the defensible option, although the weights involved usually originate in Europe or China, which makes license and provenance analysis relevant. Chinese-parent models are a legitimate choice for use cases without sensitive Chilean personal data and with low regulatory impact, not for processing a patient's medical record, a client's case file, or an employee's payroll data.

What the contract does not save

Data processing addenda (DPAs) and international transfer clauses, including the EU Standard Contractual Clauses and the equivalent mechanisms the Chilean Agency adopts, are necessary but do not resolve the conflict. A private contract does not exempt a provider from complying with a binding court order issued by the authority of its jurisdiction. That is why the contract does not eliminate the risk, although it can improve traceability, the allocation of responsibilities, and the controller's diligence position. What the contract should secure is documented traceability: government-access transparency reports, Zero Data Retention commitments where the product tier allows it, prohibition of customer data use for training, and notification obligations as soon as the provider is legally able to comply. That documentation sustains diligence before the Agency and before the board.

On the technical plane there are also measures that narrow the exposure: strong encryption in transit and at rest, customer-controlled key management, and confidential-computing architectures in which not even the provider itself has access to memory at runtime, such as AWS Nitro or equivalent offerings. These measures do not replace the jurisdictional analysis, but they can materially reduce what a provider is in a position to disclose when faced with a demand.

Local, private, public: the architectural decision

The operational question that follows is one of architecture, not marketing. Three patterns cover most cases.

1. Local deployment with open models

Llama, Mistral, Qwen, or Chilean models in development, on owned infrastructure or with a Chilean provider. Maximizes sovereignty, demands internal technical staff and compute capacity, and works with models today less capable than the commercial frontier.

2. Private-cloud deployment with a US provider under an enterprise tier

Claude Enterprise, ChatGPT Enterprise, dedicated Azure OpenAI, Bedrock with isolated accounts, combined with Zero Data Retention commitments. Reduces secondary-use risk and improves contractual position, but does not neutralize the CLOUD Act. The classification must be verified case by case, because processing, retention, training, and residency conditions can vary by product, configuration, contract, and region.

3. Public API use with no enterprise tier

Maximum capability, weakest legal position, and the path most commercial teams default to when legal is not in the room.

The correct decision depends on the sensitivity of the data and the regulatory impact of the use case. Sensitive data, data protected by attorney-client privilege, data of children and adolescents, and use cases that trigger solely automated decision-making under Law 21,719 rarely justify the third pattern. Analytical use cases on non-sensitive, properly anonymized data may reasonably operate under the second pattern with the right contract. In regulated sectors, operators of vital importance, or entities with heightened duties of continuity, confidentiality, and security, Law 21,663 can tilt the analysis toward more controlled, segregated, or sovereign architectures, depending on the system and the critical perimeter involved.

The decision to implement artificial intelligence in a company should not be documented solely as a technology decision. It should be traced as a decision on data processing, vendor selection, security architecture, international transfer, and corporate governance. The relevant question is not only which model to use, but which data will be processed, under which jurisdiction the provider will operate, which contractual and technical controls exist, and who approved that decision within the organization.

What the board must be able to show

Before the Data Protection Agency, before the Financial Market Commission, and before its own internal audit, the board must be able to show a file, not an intention. That file includes:

• Identification of the internal owner of the system.
• Impact assessment where applicable.
• Due diligence of the provider with explicit CLOUD Act analysis.
• The documented architectural decision, with a trace of who approved it and on what assumptions.
• DPA with the reinforced annexes that match the contracted tier.
• Policy on sensitive prompts and outputs.
• Response procedure for notification of access by a foreign authority.

The existence of that file is what separates a defensible decision from an omission.

Closing

The CLOUD Act and Law 21,719 are unlikely to converge diplomatically in the near horizon. The tension is structural and will persist. The answer is not to avoid AI, nor to trust that the contract will resolve the conflict, but to install specific governance over the use of AI inside the company. That governance means the board approves an AI use policy, defines vendor-selection criteria by data sensitivity, designates an internal owner with a cross-functional mandate over legal, technology, and security, and demands periodic reporting on systems in production. Without that structure, commercial or technology teams make the jurisdictional decision by default, without traceability and without counterweight. Implementing AI governance today, before the next deployment, draws the line between an exposed company and a company that is defensible before the Agency, before the board, and before the data subject. The question is not only which model to use, but which data will be processed, under which jurisdiction, with which controls, and with whose approval.

Extended analysis of the regulatory framework at AI & Company and applied case study on the use of Claude and ChatGPT at Implementing AI in the Company. For a review applied to your organization, contact the firm.