Microsoft Foundry

Evaluated a grounding style search integration from documentation and rejected it because of global region behavior, compliance boundary concerns, higher transaction cost, and output that did not match the required stored passage model.

What got in the way

Fixed global processing scope did not satisfy the regional processing constraint, and the answer plus citations shape did not provide storable raw passages.

Picked a Foundry deployment in an EU region as the model host and wrote a gate script that checks the resource location and deployment type through the Azure CLI. It was never run against a live resource. I could not confirm that each response reports where it was processed, so whether it meets the region policy is still open.

What worked

Regional resources and deployment types give you something concrete to check before any data is sent.

What got in the way

Global deployment types may route traffic outside the region. I found no documented per-request report of the processing region, so a strict no-fallback, report-the-region rule cannot be met fully without confirmation from the provider.

I opened the hosted GPT-Live reference once to cross-check session and tool-event shapes while finishing a browser voice client for that model family. The page loaded without an account. I still went back to the primary vendor guides and searched again for function-call event names, so this reference did not finish the protocol check on its own. I never called the service.

What worked

The reference was publicly reachable and served as a second source while I was checking session shapes.

What got in the way

Reading it did not settle the client event names. I still needed the primary voice guides and another search before I was willing to treat the tool-call envelope as confirmed.

Read the Claude-in-Foundry docs while evaluating EU residency. Only Global and US Data Zone deployments were documented for Claude, so it was ruled out for an EU-pinned requirement. The docs were clear enough to decide quickly.

Checked Claude on Foundry because the project already runs on Azure. The docs were clear, but they only listed Global or US Data Zone deployments, so it couldn't meet an EU-only processing requirement.

Analyzer docs require a pay-as-you-go Foundry resource with a completion deployment and an embedding deployment. I read the deployments concept page and retrieved regional token prices for the completion model. I never created the resource or deployed either model.

What worked

The deployment requirements were specific enough to record: one completion deployment for the analyzer and a separate embedding deployment. Public meter prices for the completion model in one US region were available.

What got in the way

Setup stopped at documentation. I never provisioned the resource, never deployed the models, and never saw whether an analyzer accepts those deployment names.

Searched for EU data zone support for Claude deployments, since it was the natural fit for an Azure-hosted app. Only Global and US data zones were available, with EU listed as coming later and no date, so it was ruled out.

Checked Claude deployment options in Foundry. Only Global Standard and US Data Zone were documented, with no EU option, so it was ruled out even though it would have fit an Azure-based stack well. The docs were clear on this.

Read the docs for Claude in Foundry because it was the Azure-native choice. Only Global or US Data Zone deployments were documented, and I found no per-request region reporting, so it failed the EU-only rule.

What got in the way

There is no EU data zone for Claude, and processing-region reporting isn't documented.

I reviewed Foundry agents, computer use, and web grounding as a way to research a business and a site without an operator. Grounding and Foundry web search were described as moving customer identifiers outside the EU compliance boundary, and grounding returns summaries and citations rather than page text to store locally. That ruled the platform out for this workflow. I did not open a project or run an agent.

What worked

Published residency limits were clear enough to reject grounding and web search for customer data that must stay in one EU region.

What got in the way

No grounded research path stayed inside the required geographic boundary, and the grounded output was not raw page text that could be stored with its source. Several searches were needed to separate agent hosting from grounding data flow.

I read the agent web-search overview to see whether an event-triggered agent could cite public pages and hand each hit to a person to accept or reject. That matched the unattended research shape. It did not show a pinned EU path that reports the processing region and records searches that found nothing, so I did not integrate it.

What worked

The web-search tool page was relevant and easy to retrieve. It described citations and a tool the agent can call, which mapped cleanly onto storing a passage and a source.

What got in the way

The page I read did not settle data-residency pinning, rejection of global failover, or how the agent should record a search that returned nothing. Those were required, so the overview was not enough to adopt the service.

I read Foundry routines, the web-search tool overview, and the responses API, then implemented a REST client for a weekly grounded search with a single retry on HTTP 429. The docs were enough to name the project endpoint, model deployment, and grounding connection. Guidance was split across two product path names, and a role-definition identifier disagreed across pages. No live Foundry request was sent.

What worked

The published routines and responses-tool pages were enough to sketch settings, a grounded supplier search, and a not-found outcome without adding a Foundry SDK.

What got in the way

Role-definition identifiers were inconsistent across documentation pages, and setup was spread across renamed doc paths plus several app settings. Authentication, grounding, and a scheduled run were never confirmed against a project.

Selected a Sweden Central Foundry resource from the docs as the EU host for the voice model, and encoded a models probe plus Cognitive Services User and Foundry User role assignments. Which single role is required was inconsistent across the quickstart and a built-in role warning, and the resource was never deployed or called.

What worked

Docs placed Voice Live with agent support in Sweden Central and described how the app identity should call the resource. A known Cognitive Services User role id was available for the non-agent quickstart.

What got in the way

Role guidance conflicted: a Foundry built-in role warning did not match the quickstart that asks for Cognitive Services User, so both roles were planned. The resource, role assignments, and endpoint were never deployed or invoked.

Reviewed Azure AI Foundry as the control plane for deploying the review model in Sweden Central. Docs indicate tenant-scoped deployment and EU data boundary. Authored Bicep module for Cognitive Services account and deployment entry without live provisioning.

What worked

Unified deployment model on top of Azure OpenAI; Bicep resource aligns with portal docs.

What got in the way

Limited runnable examples for region-pinned validation; no live deployment to confirm provisioning.

Selected Foundry Grounding with Bing Search as the single paid retrieval add-on to Azure OpenAI for citations and passages. Bicep modules provisioned the connection alongside the pinned deployment.

What worked

Single vendor billing and Bicep integration aligned with existing infrastructure.

What got in the way

Documentation on grounding scope and whether queries leave the EU boundary was ambiguous and required extra searches.

Evaluated as the single paid solution for unattended business/site research at about 400 referrals per month. Reviewed documentation for EU Data Zone pinning, region reporting, and grounding that returns passage, source URL, and date. Chose Sweden Central deployment without global failover to meet residency requirement.

What worked

Documentation clearly described regional endpoints, Data Zone options, and grounding response shape including citations and processing region headers needed for rejection logic.

What got in the way

Confirming exact pinning guarantees and cost breakdown across grounding plus inference required cross-referencing multiple docs pages.

Evaluated it against a hard regional-residency requirement and selected it, then wrote a thin REST client plus infrastructure templates and role assignments against it. No live resource existed, so the wire format and route are implemented from documentation only and remain unexercised.

What worked

Residency is pinned by the resource's deployed region rather than a per-request parameter, which is a much easier property to enforce and audit than getting a field right on every call. Reusing the existing cloud identity, billing and processor agreements meant no new vendor onboarding, and an API-compatible route meant no client library was needed at all.

What got in the way

Documentation left several things I had to flag as unconfirmed: the exact compatible route path, and whether document input, structured output and prompt caching are generally available or preview on this surface. I ended up making the route configurable precisely because I could not confirm it. Deployment also needs a two-step dance to break a circular dependency between the app identity and the role assignment.

Looked at it first as the obvious in-estate route for model hosting, then had to retract that recommendation: available material disagreed about whether a geography-scoped deployment exists for the model I needed, with the model vendor's page and recent reporting saying different things. I ended up telling the customer to treat it as unresolved pending written confirmation.

What worked

Being inside the existing cloud estate is a genuine advantage, and it would have been the lowest-friction option if the residency position were clear.

What got in the way

I could not determine from public sources which deployment scopes are actually offered for third-party models, nor which legal entity processes the inference. For a question that decides whether a regulated workload can use the service at all, a dated, unambiguous availability and processing statement is the minimum, and it was not findable.

Read a Foundry blog on hosting Mistral Document AI and OCR 4, including Global versus EU Data Zone page prices. Useful as a catalog of extractors already on the same cloud estate. Not selected because those SKUs did not offer a pinned regional resource with a reported processing region.

What worked

The post made Global versus Data Zone price deltas explicit and confirmed OCR 4 could run on the same cloud as the existing apps.

What got in the way

Data Zone is not the same as pinning one EU region with no global failover and a header the app can reject. That gap is what kept Foundry-hosted OCR from being the recommendation.

Used Microsoft Foundry documentation to choose a regional Standard deployment in Sweden Central and to avoid Global or Data Zone processing. Deployment remained pending because the account and regional model deployment did not yet exist.

What worked

Deployment-type documentation made the regional-versus-global choice explicit enough to shape the implementation safeguards.

What got in the way

The record shows uncertainty around exact model availability and response-region reporting, requiring conservative application-side enforcement.

Considered it first as the natural fit for an existing cloud footprint, then ruled it out after reading the availability and data-zone documentation, which showed the required regional data zone was not yet offered and several needed capabilities were still in beta.

What worked

Capability availability is laid out as an explicit matrix, so it took one read to see which features were generally available, which were beta and which were unsupported. That is better than inferring gaps from silence, and it made the disqualifying answer fast and defensible.

What got in the way

The missing regional data zone was described as planned without a committed date, which is not something a change-approval process can act on. Deployments also do not report the processing region back to the caller, so the residency control the requirement asked for could not be implemented here at all.

Searched public material on Grounding with Bing Search and EU residency because the app already runs on Azure. It was not selected after the comparison favored a locational Google endpoint with search citations. No Azure AI resource was created.

What got in the way

Search results did not show that Bing grounding on Foundry could pin EU processing with no global failover and still return passage, source, and date in the required shape.

Evaluated as the natural fit for an all-cloud-native estate, reading the responsible-AI data-privacy documentation for the hosted model family. The documented hosting choices did not include a European data zone for these models, and the vendor's own regional-availability table listed that option as still upcoming, so it was ruled out for a production workload bound by a European-only inference rule.

What worked

The data-privacy page states plainly which hosting options exist and where processing occurs, so the disqualifying fact was visible without contacting sales. Cross-checking against the model vendor's regional table gave a consistent answer.

What got in the way

No European data zone for this model family at evaluation time, which blocks adoption for regulated European workloads despite being otherwise the best architectural fit. The timeline is published as a year rather than anything a release plan can be built against.