Azure OpenAI development

Azure OpenAI or OpenAI directly

The models are the same family. What differs is everything around them: who signs the contract, where data is processed, how users authenticate and how the service is limited. For a Microsoft-first company, those wrappers decide the project.

If you have no Azure presence and want to test an idea, start with the direct API, as described in our OpenAI API integration page. If your IT team already asks for Azure approval on everything, start here.

What we build on it

We have no client project in our work section that runs on Azure OpenAI, so we do not cite one. This section describes the builds we would deliver and how they are put together.

• A staff assistant that answers questions from policies, manuals and SharePoint libraries, showing the source file for every answer.
• Email and form triage that classifies requests, extracts fields and creates records in your CRM or ticket system.
• Report drafting from structured data, with a human editing step before anything leaves the building.
• Back-office automation that calls the model from Power Automate, Logic Apps or our own services. See AI automation.

Worked example: policy search that respects permissions

The common failure in internal search is that the assistant happily quotes a document the asker was never allowed to open. Here is how we avoid that on Azure.

1. Index with permissionsDocuments are chunked and indexed in Azure AI Search together with the groups allowed to read each one.
2. Identify the askerThe web app signs the user in through Entra ID and passes their group list to the search query as a filter.
3. Retrieve, then generateOnly chunks the user may read go into the prompt. The model is told to answer from those chunks and to say so when the answer is missing.
4. Cite and logEach answer lists its source documents. Queries and sources are logged to your workspace, with prompt text handled under your retention policy.
5. Test with real rolesWe test with an account from each department and confirm that restricted documents never appear in answers for the wrong role.

This design is dull on purpose. It is the retrieval filter, not the model prompt, that enforces access.

Gotchas that cost projects time

• You call a deployment name, not a model name. The deployment is created per resource, and the API version is part of the request. Mixing these up gives confusing 404 errors.
• Quota is measured in tokens per minute, per region, per subscription, per model. Splitting production and test across subscriptions can free capacity.
• Deployment types matter: standard regional, data zone, global and provisioned throughput have different price, residency and latency behavior. Choose on purpose.
• The default content filter can block legitimate business text, such as medical or legal wording, with a content_filter error. Tune it through the approved process and handle the error in code.
• Model versions are retired on a schedule. Auto-upgrade can change behavior without notice, so pin versions where outputs must stay stable.
• Region availability differs. Check that the model you need exists in the region your data rules allow, before you design around it.
• Abuse monitoring may involve storing prompts for a period. If your data is sensitive, ask Microsoft's process for modified monitoring early; approval takes time.

Timeline and what we need from you

Approvals are the usual cause of delay, not code. Starting the quota and security requests in the first week keeps the schedule intact. Your fixed quote includes this plan and the assumptions behind it. For wider context see our AI consulting service.