The deputy HR manager wants an assistant that summarizes the quarter's medical leave records and performance reviews. IT already has a ChatGPT prototype ready, but the company's lawyer asks something nobody can answer: where does that data end up, and who else can read it?
That question stalls a lot of AI projects in Chile, and fairly so. You can use Azure OpenAI with sensitive data, but it isn't solved out of the box. It depends on how the model is deployed, who has access, and what your company does to comply with Law 21.719. Below we separate what Microsoft guarantees, what is left for you to configure, and what Chilean law will ask of you regardless.
What Azure OpenAI is today
Azure OpenAI is no longer sold as a standalone service. OpenAI models (and others) are deployed from Microsoft Foundry, Azure's AI platform, and Microsoft groups them as "models sold by Azure." In practice it is still what many teams know as Azure OpenAI: GPT models running inside your company's Azure subscription, under Azure's privacy terms rather than those of the consumer app.
Everything else in this article builds on that difference. For broader context on generative AI in Azure, see our article on Azure OpenAI.
What Microsoft commits not to do with your data
The Microsoft Foundry privacy documentation (updated May 2026) is explicit. The prompts you send and the responses you get:
- are not available to other customers;
- are not shared with OpenAI or other model providers;
- are not used to train foundation models without your permission or instruction;
- are not used to improve Microsoft or third-party products without your explicit authorization.
When you use features that store information (uploaded files, fine-tuning data, stored completions), that data stays in the Foundry resource inside your own Azure tenant, in the same geography as the resource, and you can delete it whenever you want. It is encrypted at rest with AES-256, and if your policy requires it you can use customer-managed keys (some preview features don't support them yet).
One point tends to get missed: abuse monitoring. Microsoft runs automated checks on prompts and responses to detect prohibited uses, and if something raises a flag, authorized Microsoft staff may review a sample. Managed customers can apply for modified abuse monitoring, which removes the storage and human review (automated review may continue). If you plan to process medical records or employee data, it's worth looking at that application from day one.
Where data is processed: the deployment type decides
For sensitive data this is the technical decision that matters most, and you make it when you create the model deployment. According to Microsoft's deployment types guide:
| Deployment type | Where prompts and responses are processed | When to consider it |
|---|---|---|
| Global (Standard or Provisioned) | Any Azure region where the model is deployed | Data with no location restrictions |
| Data Zone | Only within a Microsoft-defined zone: United States, European Union or Asia Pacific | When you need to keep processing within a block |
| Standard or Regional Provisioned | Within the Azure geography you chose | When processing location is a hard requirement |
In all three cases, data stored at rest stays in the geography you designated. What changes is where the processing happens.
Now the Chilean detail. Azure already has a region in Santiago, Chile Central, but model availability is published model by model and region by region, and there is no Latin American data zone. Most likely, to use a recent GPT model, your prompts will be processed outside Chile. Before designing the solution, check which models are available in which region and with which deployment type.
Private networking and access control
A well-chosen deployment with an endpoint open to the internet is still a risk. For workloads with sensitive data, we recommend at a minimum:
- Isolate the resource with private endpoints and disable public access. Microsoft documents this in its network isolation guide for Foundry.
- Authenticate with Microsoft Entra ID and managed identities instead of API keys pasted into config files.
- Assign least-privilege roles: developers don't need the same permissions as the production app.
- If the assistant queries internal documents (the pattern known as RAG), carry the source permissions into the search index. Otherwise the model may show an analyst a document they shouldn't see.
- Log who queries what. You'll need it for audits and for answering data subject requests.
None of these is switched on by default in every scenario. They are configuration work, and someone has to do it and keep it up.
What Law 21.719 requires when AI is involved
Law 21.719 takes effect on December 1, 2026. On September 1 the government proposed postponing it to December 1, 2027, and as of mid-October the initiative was still going through Congress. Until it passes, the legal date is the 2026 one. And a postponement would only move the calendar; the obligations stay the same.
For an AI project with personal data, this is what matters:
- Sensitive data: health, biometric data, union membership, socioeconomic status and others can only be processed with the data subject's express consent, apart from the exceptions the law lists.
- Impact assessment: if the processing may create a high risk (for example, sensitive data at scale or automated decisions with significant effects), the law requires an impact assessment before you start.
- International transfer: if prompts are processed outside Chile, that is a transfer, and it needs one of the legal routes the law provides: a country with an adequate level of protection, contractual clauses, binding corporate rules or other safeguards.
- Security by design: the controller must apply technical and organizational measures from the design stage. The settings in the previous section are exactly that, and it pays to document them.
Microsoft acts as your processor, but responsibility toward your customers and employees stays with your company. In this article on GDPR and Law 21.719 we explain the differences between the two, which helps if your organization already runs a European compliance program.
A short checklist before connecting real data
- Classify the data the assistant will use. If it doesn't need the national ID number or the diagnosis to answer, don't send them.
- Choose the deployment type based on where each kind of data may be processed.
- Set up private networking, Entra ID and roles before the pilot, not after.
- Decide whether to apply for modified abuse monitoring.
- Run the impact assessment if there is sensitive data or automated decision-making.
- Review Microsoft's contract and data protection addendum with your legal advisor, especially the transfer section.
Frequently asked questions
Does Azure OpenAI use my data to train OpenAI's models?
No. According to Microsoft, prompts and responses are not shared with OpenAI or used to train foundation models without your permission.
Can I guarantee my data is processed in Chile?
There is currently no Latin American data zone, and model availability in Chile Central varies by model. If processing happens elsewhere, treat it as an international transfer under Law 21.719.
Is using Azure OpenAI the same as using ChatGPT?
No. Azure OpenAI runs inside your company's Azure subscription, with network, identity and encryption controls managed by your own team.
How we approach it at Disrupsoft
We start by identifying which process is worth solving with AI and what data it really needs. Then we design the solution, deploy it on Azure with private networking, managed identities and the deployment type that fits your data, and keep tuning it in production. If you're evaluating a use case with sensitive information, take a look at our Azure AI service and let's talk before the first real record gets connected.
