Walk through any company in the past year and the AI story usually starts before the strategy does. Someone has summarised a customer call in ChatGPT. A product manager has pasted a backlog into Claude. An analyst has asked Copilot to explain a spreadsheet they should probably not have uploaded anywhere.
None of this is malicious. People have found tools that make difficult work easier, and they are using them because the business has not given them an approved alternative that is equally useful.
The usual response is a policy that says no. Block the public sites, send a reminder about confidential information, and hope the problem has gone away.
It has not. It has just gone somewhere harder to see.
The AI problem is a control problem
Public AI tools are excellent at getting a first draft onto the page. They are also outside the controls most organisations already use to protect their data. The security team cannot consistently see what is being submitted. Legal cannot give a clear answer about where it is processed. A product owner cannot restrict an assistant to the documents it actually needs. And when a regulator, customer or board member asks who had access to what, the answer is often a policy document.
The risk is not that ChatGPT, Claude or Copilot are automatically unsafe. The risk is that a consumer account, a personal login or an unapproved browser tab is not an enterprise operating model. It does not give you your own identity boundary, your own network boundary, your own audit trail or a deployment choice your data-protection team can review.
That matters more in Europe. Data residency is now a procurement question. DORA, NIS2, sector regulation and customer contracts have made it one. A useful AI policy needs to answer more than whether people may use a tool. It needs to answer which data may reach it, who is allowed to ask, where the request is processed, and how the result is checked before it affects a customer or a decision.
Bans are not an AI strategy
You can ban every public assistant in the company. Your people will still see AI in the tools they buy, the suppliers they work with and the competitors they meet. The pressure does not disappear because the policy says no. It turns into shadow IT, and shadow IT is the least governable form of innovation there is.
The better question is: what would make the useful thing the safe thing?
For organisations already running on Azure, Azure AI Foundry is the answer. It gives the business the capability people are reaching for, while putting the model, the data connection and the operating controls back inside the Azure estate the company already governs.
What Azure AI Foundry changes
Foundry is not one chatbot. It is the platform for building and operating AI applications, assistants and agents. Your teams can choose an appropriate model, connect it to approved business data, test the quality of its answers and put it behind an application that uses your own identity and access model.
That is the difference between people copying sensitive information into a general-purpose prompt box and giving them a purpose-built assistant that knows only the documentation, product data or process it needs to know.
That operating model is the missing second half of AI Agents Done Right: From Experiment to Enterprise-Ready Platform, where we wrote about treating AI agents as infrastructure from day one.
The important capabilities are straightforward.
Choice without another platform. The model catalogue lets teams choose between Microsoft-backed and other suitable models for different jobs: summarising documents, answering questions over an approved knowledge base, classifying a request or helping a service desk. The model becomes a deliberate technical and commercial choice, not whichever public tool someone happened to open first.
Data stays part of your estate. For Models sold by Azure, Microsoft states that prompts, completions, embeddings and training data are not available to other customers or model providers, and are not used to train generative AI foundation models without your permission or instruction. That is a materially different contract from assuming a public tool behaves like a private enterprise service. The exact commitment still depends on the model and deployment path, so check it before approving a use case rather than treating a model catalogue as a blanket guarantee.
Identity and permissions remain yours. Microsoft Entra ID, role-based access control and managed identities mean a person or an agent gets only the permissions it needs. An HR assistant does not inherit access to finance. A product assistant does not need the whole document library. That sounds obvious, but it is the control that is missing when sensitive prompts leave through an unmanaged account.
The network does not become an afterthought. Private endpoints, virtual-network integration and Azure Policy can keep the workload within the same boundaries as the applications and data it serves. Keys belong in Key Vault. Access is logged. Policies can prevent a convenient but non-compliant configuration from quietly reaching production.
Quality and safety are operated, not assumed. Foundry gives teams evaluation, tracing and monitoring capabilities so they can test whether an assistant is accurate, grounded in the right sources and behaving as intended. Content Safety and Prompt Shields add another layer where an assistant handles external input. A model should be useful before it is released, observable after it is released, and stopped when it crosses a boundary. That is how software is run. AI should not get a special exemption.
Data locality is a design choice, not a logo
This is the part to take seriously. Running on Azure does not automatically mean every request stays in a specific country, or even in the EU. The deployment type matters.
A Global deployment can process prompts and responses in Azure locations around the world, even though data stored at rest remains in the Azure geography you selected. That may be the right choice for a low-risk, high-scale workload. It is not the choice to make by accident for customer records, regulated data or intellectual property.
For workloads that require EU processing, choose the model and deployment path accordingly. With a DataZone deployment created in an EU Member Nation, prompts and responses can be processed in that country or another EU Member Nation. Where the requirement is a particular Azure region, use a regional deployment and confirm the model's availability there. The difference belongs in the design record and the risk assessment, not buried in a platform team's configuration notes.
Stored data needs the same attention. Conversation history, uploaded files, vector indexes and application logs can all have their own retention and location characteristics. Foundry gives you the controls to design this properly; it does not remove the need to classify data, set retention rules and decide what should never be sent to a model at all.
In other words: data locality is not a marketing claim. It is an architecture decision that your security, legal and product teams can inspect.
Give people an approved way to use AI
The first use case does not need to be a grand transformation programme. Pick a job people are already doing in public tools: finding an answer in internal documentation, drafting a response from approved templates, summarising a case file, or classifying an incoming request.
Build one assistant around a small, approved data set. Give it a managed identity with least-privilege access. Keep the endpoint private where the workload requires it. Choose the correct regional or EU DataZone deployment. Test it with real but controlled examples. Log the results. Put a person at the point where its output becomes a customer communication, a financial decision or a system change.
Then the policy becomes easier to enforce, because it is no longer asking people to give up a useful capability. It is giving them the approved place to use it.
That is the real value of Azure AI Foundry. It is not a prettier prompt box. It is the enterprise AI platform for companies that want the speed their people can already see, without giving up control of the data, identity and locality that make the business theirs.
There's no one-size-fits-all approach to the cloud. That's why we meet you where you are.
The AI is already in your organisation. Deciding where it runs, on whose identity and under which controls is still yours to make, and it is easier made now than under an audit deadline. Schedule a direct conversation with DevOps Masterminds CTO Rinie Huijgen.
