What the Microsoft Foundry Claude question actually taught us

Every few weeks someone asks a version of the same question: “Can I use [AI tool] for [data]?” It sounds simple. It isn’t. Behind that question are three separate problems wearing the same trench coat: a legal risk question, a technical residency question, and a trust question. Most guidance documents answer one of the three and call it done. Here’s what it looks like when you actually chase all three down, using a real example: whether Claude, run through Microsoft’s Azure AI Foundry, is safe for university data.

The three questions people are actually asking

When staff, faculty, or a data governance committee ask “is this AI tool safe,” they’re really asking:

Is this legal? Colorado passed an AI law in 2026 that targets high-risk uses: employment, housing, financial services, health care. The EU AI Act goes further and treats profiling as high-risk on its own. Our legal counsel’s read: start with what Colorado requires, then decide where to over-comply. Employment is the sharpest edge here. Workday is currently being sued over AI use in hiring, and it’s a live reminder that even a well-intentioned use (comparing employee self-evaluations for consistency, say) can land you in a high-risk category you didn’t think you were in.

Where does the data actually go? This is the one people assume is settled and usually isn’t. “It’s a Microsoft product” and “it runs on Microsoft infrastructure” are not the same claim, and vendors are inconsistent about which one they mean.

Can you trust what a privacy toggle tells you? Incognito mode, private browsing, “don’t train on my data” checkboxes: these create a feeling of safety that outruns what they actually guarantee. Our counsel’s line, which I now say constantly: vendors can still retain flagged content for review, privacy settings or not.

None of these questions are answerable by reading a vendor’s marketing page. You have to go source by source. Which is what we did.

The Foundry Claude example

Anthropic’s Claude models are available through Azure AI Foundry, which matters to us because our Claude usage flows through an API gateway sitting on our Microsoft enterprise agreement. The assumption inside that setup was reasonable: it’s Microsoft infrastructure, it’s covered by our Microsoft data processing agreement, done.

That assumption was wrong, and the reason why is a good case study in reading past a vendor’s summary paragraph.

Anthropic is the data processor, not Microsoft. Regardless of which hosting option you pick, Anthropic operates the model inference and is the independent processor of your prompts and completions under Anthropic’s own commercial terms. Microsoft’s enterprise agreement covers the infrastructure, identity, and billing layer around Foundry. It does not extend to what happens to your prompt once it reaches the model. This is a real difference from Azure OpenAI, where Microsoft is the processor end to end.

“Hosted on Azure” is new, and it’s the fix. Foundry Claude launched in preview running entirely on Anthropic’s own hardware, which could mean your data left your region regardless of what you configured. As of general availability on July 1, 2026, there are two hosting options: the new default, “Hosted on Azure” (ingress, API calls, and GPU inference all happen inside Azure, data at rest stays in your chosen Azure geography), and the legacy “Hosted on Anthropic infrastructure” (the old preview path, data may leave your region). Which option a given deployment uses is now the single most consequential setting in the whole configuration, and it’s easy to get wrong if nobody goes back to check it after GA.

Even the vendors’ own docs disagree with each other. Microsoft’s documentation says GPU inference for “Hosted on Azure” runs on Azure hardware. Anthropic’s own third-party integration notes say Claude models run on Anthropic’s infrastructure. Both are technically defensible depending on how you define “runs,” but if you’re trying to write a data governance policy, that kind of internal contradiction between two vendors describing the same product is a flag to escalate, not something to paper over with a footnote.

Zero data retention is not a checkbox. You can request that Anthropic not retain your prompts after the call completes, but on Foundry this has to be arranged in writing between your Microsoft account team and Anthropic. It is not something you turn on in the portal. Treat every deployment as retaining data until you have that confirmation on paper.

Safety review still happens, even with retention off. Anthropic runs automated classifiers on every request looking for policy violations. Flagged content can go to human review at Anthropic, and confirmed violations get retained for up to two years for abuse monitoring, independent of your retention settings. This is the part most people don’t expect: “zero data retention” describes your prompt history, not the safety layer sitting on top of it.

What we came up with

We mapped this to the four data classification levels our university system already uses (public, internal, confidential, restricted) and landed here:

Public and internal data: fine on Foundry Claude today, hosted on Azure, no special approval needed.
Confidential data (personnel records, assessment data, most PII): conditionally fine, but only once zero data retention is confirmed in writing for that specific subscription, and only with data governance committee sign-off.
Restricted data (biometric data, controlled unclassified information, Social Security numbers, financial account numbers): not through Foundry Claude, full stop, unless someone produces a signed data protection arrangement that specifically covers it.

We also flagged a narrower but nastier problem: a small set of Anthropic’s models come with mandatory retention and no zero-retention option available, on any platform. If your organization has a standing zero-retention agreement, using one of those specific models silently requires you to turn retention back on for it. That’s the kind of setting nobody notices until an audit finds it, so it’s now something we check explicitly during any Claude deployment, not an assumption we make.

None of this makes Foundry Claude unusable. It makes it usable with the right defaults and the right paperwork, which is a very different thing than “it’s Microsoft, so it’s covered.”

The pattern, not just the example

The real point isn’t Claude specifically; it’s the method. Every AI tool question that shows up at a university has the same three layers underneath it, and skipping any one of them gets you a wrong answer that sounds confident:

What does the law actually require for this use case, not the general case.
Where does the data physically go, and who is the processor once it gets there, regardless of whose logo is on the product.
What do the privacy settings actually guarantee, versus what they imply.

We’re now building this into how we vet AI tools before they touch university data: a short checklist, a data steward as the approval gate instead of individual discretion, and default template language disclosing AI use wherever it applies. None of that is exciting. It’s also the difference between a governance program that catches the Foundry Claude problem before it becomes an incident, and one that finds out from a vendor’s fine print after the fact.

If your institution is working through the same kind of question, I’d like to compare notes. Find me on the about page.