Microsoft Foundry in Practice

Azure Responsible AI Standards Applied to Foundry

Teams arriving at Claude from other Azure AI services often expect a familiar switchboard of content-filter settings. For Claude on Foundry, the responsibility split is different — and it's documented, not accidental.

Claude 3P 101 · Updated July 2026 · Unofficial guide

Microsoft publishes Responsible AI documentation for the model families offered in Foundry, covering how each is operated, what safety systems apply, and how customer data is handled. For Claude, that documentation describes a three-party arrangement: Microsoft provides the platform, Anthropic operates the models and their safeguards, and you — the customer — own how the application behaves. Understanding where each line falls prevents both false comfort ("Azure filters everything") and duplicated effort.

The headline: no built-in content filtering at deployment time

Microsoft states plainly that Foundry does not provide built-in content filtering for Claude models at deployment time, and that customers should configure AI content safety during model inference themselves. If you have deployed other models in Foundry with Azure-side severity levels and category toggles, note the difference: Microsoft's docs describe no equivalent configurable filter settings for Claude deployments. Instead, Claude models in Foundry run with Anthropic's safety systems and safeguards, supported by Microsoft, and Microsoft's documentation points to Anthropic's own materials — including each model's system card, linked from the Foundry docs — for how harmful content is screened.

Those model-level safeguards are real and observable in the API. Claude Fable 5, for example, applies additional input and output classifiers for dual-use safeguard policies; when it refuses, the response comes back as HTTP 200 with stop_reason: "refusal", and refused input tokens are not billed. Your error handling should treat refusal as a normal, expected stop reason — not an exception path.

Terms you accept, and data handling you inherit

Two more pieces of the responsible-AI picture are contractual and architectural rather than technical. First, applications must comply with Anthropic's Acceptable Use Policy — the Anthropic terms are presented during deployment, and they, not Azure's generic terms alone, govern permissible use. Second, for both hosting options (Hosted on Azure and Hosted on Anthropic infrastructure), Anthropic remains the seller and operator and acts as an independent data processor for prompts and outputs. On Azure-hosted deployments, prompts and outputs are processed on Azure infrastructure and data at rest stays in your selected Azure geography; automatic safeguards may flag content for Anthropic Trust & Safety review, on an exceptions basis, for potential safety violations. Hosted-on-Anthropic deployments may process data outside Azure. None of this is a compliance conclusion for your industry — Claude on Foundry inherits your cloud provider's and Anthropic's documented postures, and you should confirm specifics with Microsoft and Anthropic for your regulatory context.

What your application layer must supply

Since the platform does not filter for you at deployment time, Microsoft's responsible-AI framing effectively hands your team a checklist:

LayerWho provides itYour action
Model-level safeguards, refusalsAnthropic (operated with Microsoft support)Handle stop_reason: "refusal" gracefully; read the model's system card
Deployment-time content filtersNot provided for ClaudeAdd inference-time content safety checks suited to your use case
Use-policy complianceAnthropic AUP + Microsoft termsMap your use cases against the AUP before launch
Application behaviorYouInput validation, output review, human oversight for high-stakes decisions, audit logging
Rule of thumb: treat Anthropic's built-in safeguards as a floor, not a policy engine. Anything your governance program promises — topic restrictions, PII handling, tone rules, escalation to humans — must be implemented and tested in your prompts and application code, because there is no Azure-side dial to turn for Claude.

Concretely, that means: screen inputs and outputs against your own content policy where the use case warrants it; log requests and refusals so misuse and drift are detectable; keep a human in the loop where outputs drive consequential decisions; and version and test your system prompts like the policy artifacts they are. These are application-layer disciplines this guide covers elsewhere — see content policy enforcement, human oversight design, and guardrail design in prompts.

Where to go next

For the adjacent Foundry specifics, read Foundry content filtering and Foundry beta caveats; for the broader program view, start at governance program foundations.

Sources