Azure OpenAI
Azure OpenAI Service gives you the same GPT and embedding models you'd get from OpenAI directly, but wrapped in Azure's enterprise controls: data residency, private networking, Entra ID auth, and a contractual commitment that your prompts are not used to train models. For a regulated .NET shop, that wrapper is often the whole reason the project is allowed to ship.

Deployments, not just models
A subtle but important difference: with Azure OpenAI you don't call a model by name β you call a
deployment. A deployment is a named instance of a model (for example, a gpt-4o deployment
called chat-prod) provisioned in a specific region with its own capacity and quota. This matters
because:
- Regional data residency is set at deployment time. You can pin a deployment to a region whose compliance rules you need (e.g. an EU region for GDPR-sensitive data), and inference stays there.
- Versioning is explicit. You choose when to move a deployment to a newer model version, so a vendor update never silently changes your behavior in production.
- Capacity is yours. Provisioned throughput gives predictable latency under load.
Enterprise auth and safety
Two features make Azure OpenAI feel "enterprise" rather than "an API key in an env var":
- Entra ID + managed identity β your app authenticates with its managed identity instead of a static key. The credential is rotated by the platform and scoped with role-based access control, so a leaked config file can't leak a working key.
- Content filters β every deployment runs Azure's content filtering on prompts and completions, scoring categories like hate, violence, and self-harm. You can tune severity thresholds per deployment, and pair it with Azure AI Content Safety for stricter gating.
It's still an OpenAI-compatible API
The architecturally crucial fact: Azure OpenAI speaks an OpenAI-compatible API. The request and
response shapes for chat completions and embeddings are the same; only the endpoint URL,
authentication, and the deployment name differ. In .NET, the Azure.AI.OpenAI SDK and the
official OpenAI SDK expose nearly identical surfaces, and abstraction layers like Semantic Kernel
hide even that.
For LyraLearn this means Azure OpenAI is a drop-in provider. The app already calls embeddings
and chat through IEmbeddingService and IChatCompletionService; registering an Azure-backed
implementation and pointing config at a deployment is all it takes. No use-case, no prompt, and no
business logic changes β the model became a config swap, exactly as the architecture intended.