Start with the big picture: what you get, what the word cognitive means here, and what the service is not.

The word cognitive relates to thinking and understanding: seeing, hearing, reading, and making sense of the world. Cognitive Services are cloud services that give your software some of those human-like abilities. Each ability is offered as an API, which stands for application programming interface. An API is a menu of requests that one program can send to another. Your app sends a picture, and the API sends back a description. Your app sends an audio clip, and the API sends back the words that were spoken. You never see the complicated model that does the work, and you never train it yourself.

These services are called prebuilt or pre-trained. Microsoft has already taught the underlying models, using enormous amounts of data and powerful computers. You simply use them. That is very different from machine learning projects in which you gather your own data, train your own model, and host it yourself. The prebuilt route is much faster and cheaper for common tasks. When a prebuilt service is not quite right, many of them also allow customization, where you teach the model a little about your own special words or images without starting from scratch.

A short history

Microsoft Research spent many years teaching computers to recognize images and speech. In 2015 and 2016, Microsoft released a set of these abilities to developers under the name Project Oxford, which soon became Azure Cognitive Services. Over the years the family grew to include vision, speech, language, translation, form reading, and more. In 2023, Microsoft joined the family closely to its Azure OpenAI offering and rebranded the group as Azure AI Services. Some older services were retired and replaced by newer ones. For example, a language understanding tool called LUIS and a question tool called QnA Maker were replaced by newer language features. Because names and service lists keep changing, always check Microsoft’s current service list before you plan a project.

Every tool exists because something hurt. Here is the pain that Cognitive Services remove.

Suppose you want your app to read text from photographs of receipts. You could build this yourself. You would need thousands of labeled receipt photos, a machine learning expert, powerful graphics processors to train the model, weeks of experiments, and a hosting system that can answer quickly under heavy traffic. Then you would need to keep improving the model as new receipt designs appear. For one feature, that is a huge project. For a company that wants ten such features, it is out of reach.

Prebuilt services change the math. The model already exists and is already running on Microsoft’s computers around the world. It improves over time without you doing anything. Your job shrinks to a simple one: send the data, receive the answer, and decide what your app does with it. This lets small teams add features that once belonged only to giant technology companies.

Before you use any of the services, learn the small set of words Azure uses to organize them.

In Azure, almost everything you use is a resource, a named item that lives in your subscription and that you can configure and pay for. To use Cognitive Services, you create a resource of this family. There are two styles. A single-service resource gives you access to one service, such as Speech or Vision. A multi-service resource gives you one connection that works for many services at once, which is simpler when your app uses several of them. A single-service resource can have its own pricing and its own free tier, and is handy when you want to track costs or control access per service.

Every resource has an endpoint, which is its web address, the place your app sends requests. Endpoints belong to a region, the geographic area of Azure data centers, such as West Europe or East US, where your resource and its processing live. Choosing a region close to your users reduces delay, and choosing the right region can matter for rules about where data may be processed.

To prove who you are, a resource gives you two keys. A key is a long secret code that you send with each request, like a membership card. There are two so that you can change one without breaking your app: switch your app to key two, replace key one, and so on. A better and more modern alternative is to use Microsoft Entra ID with a managed identity, where your app proves its identity without any stored secret at all. We will look at this more closely later.

Finally, every resource has a pricing tier, also called an SKU. The Free tier, usually named F0, gives a small monthly allowance at no cost, perfect for learning and testing. The Standard tier, usually named S0, is pay as you go. Some services also offer commitment tiers, where you agree to a monthly amount of usage in return for a lower rate.

Now let us look at how an application, the Cognitive Services resource, and the models behind it fit together.

A typical design has four zones. First is your client, the part that collects the data: a mobile app, a website, a backend service, or a device in a factory. Second is your application backend, the code you run in Azure, in a function, a container, or a web app. It decides which service to call, holds the connection settings safely, and handles the answers. Third is the Cognitive Services resource, the managed front door that receives the request, checks who you are, applies limits, and counts usage. Fourth are the models, the trained systems on Microsoft’s computers that actually do the thinking.

Around these sit supporting services. Microsoft Entra ID proves identities. Azure Key Vault keeps secrets safe. Azure Monitor records metrics and logs. Azure Storage often holds the input files and the results. A private network can hide the whole path from the public internet.

flowchart LR
    CL["Client app or device"] --> BE["Application backend"]
    BE -->|"authenticate"| ID["Microsoft Entra ID or key from Key Vault"]
    BE --> EP["Cognitive Services endpoint"]
    EP --> GW["Front door - auth and rate limits"]
    GW --> M1["Vision models"]
    GW --> M2["Speech models"]
    GW --> M3["Language models"]
    BE --> ST["Storage for inputs and results"]
    EP -.->|"metrics and logs"| MON["Azure Monitor"]
    

Read the diagram from left to right. The client never talks directly to the AI models. It talks to your backend, which holds the keys or identity. The backend calls the endpoint of your resource. The front door checks that you are allowed, applies limits to protect the shared system, and passes the request to the right model. The answer returns along the same path. Meanwhile, numbers about every call flow into Azure Monitor, so you can see usage, errors, and speed.

Vision services turn pictures and documents into text and facts your software can use.

The Azure AI Vision service looks at images and tells you what is in them. Its abilities fall into a few groups. Image analysis produces a caption for a picture, a list of tags such as “outdoor,” “dog,” or “bicycle,” and can find objects and people, giving each a position in the image. It can also create a smart thumbnail that crops around the most important part. Optical character recognition, shortened to OCR, reads printed and handwritten text from photographs, scans, and screenshots and returns it as plain text with the position of each word. This is the technology that lets you photograph a menu or a sign and copy the words.

Vision also offers abilities for video and space. Spatial analysis can count people entering a shop or measure how long they stand at a display, using camera streams and without identifying anyone. Another group, face technology, can detect that a face is present and describe attributes such as its position in the picture. Because faces involve strong privacy concerns, Microsoft restricts the more sensitive face features and requires an application and approval for them, a policy called Limited Access. We will return to this in the chapter on responsible use.

If the prebuilt abilities do not fit your needs, you can use a custom approach. For example, a manufacturer can show the service several hundred photos of good and defective parts, and obtain a model that spots defects on its own production line. This is more work than the prebuilt options but far less than training a model from nothing.

flowchart TB
    IMG["Image or video frame"] --> V["Vision service"]
    V --> C["Caption and tags"]
    V --> O["Object and people locations"]
    V --> T["Text through OCR"]
    V --> S["Smart thumbnail"]
    V --> SP["People counting with spatial analysis"]
    

Speech services convert between spoken sounds and written words, in many languages.

The Azure AI Speech service has four main abilities. Speech to text, also called transcription, listens to audio and writes down the words. It can do this in real time from a microphone, with words appearing as people speak, or in batch mode, where you submit many large recordings and collect the transcripts later. Text to speech does the opposite: it turns written words into natural sounding spoken audio, choosing from many voices and languages. Some voices are so natural that listeners may not realize they are synthetic, which is why strict rules apply to custom voices.

Speech translation combines listening and translating: a person speaks in one language and the service produces text or spoken audio in another. Speaker recognition, also available in some forms, can help tell who is speaking, which is useful for separating voices in a recorded meeting, a task called diarization. Another useful feature is pronunciation assessment, used in language learning apps to score how well a student pronounces words.

Real-time speech uses a continuous stream. The app opens a connection, sends audio in small pieces, and receives partial and final text as the person talks. For short phrases, a simpler one-shot request can be used, with a limit of about a minute of audio. For long recordings such as hour-long calls, use batch transcription.

Language services understand the meaning inside written text.

The Azure AI Language service gathers many text understanding abilities in one place. Each ability takes in text and returns structured facts. Sentiment analysis says whether a piece of text sounds positive, negative, or neutral, both for the whole text and for each sentence, and can link opinions to the things they describe, such as “the food was great but the service was slow.” Key phrase extraction picks out the main talking points. Named entity recognition finds real-world things in text, such as people, places, companies, dates, and amounts of money. Language detection says which language a text is written in.

Several abilities help with privacy and size. PII detection finds personally identifiable information, such as names, phone numbers, and account numbers, and can redact it, replacing the sensitive parts with masks. Summarization shortens long documents or conversations into a few sentences, which is a great fit for call center notes. Other abilities help your app converse: conversational language understanding works out what a user wants and the important details in their message, such as “book a table for four on Friday.” Custom question answering lets you feed in your own documents and frequently asked questions so users can ask questions in plain words. If the built-in categories do not fit, custom text classification and custom named entity recognition let you teach the service your own labels from examples.

Two services that handle the everyday business of paperwork and many languages.

Azure AI Document Intelligence

Businesses still run on forms: invoices, receipts, tax papers, identity cards, and contracts. Document Intelligence, formerly known as Form Recognizer, goes beyond plain OCR. It does not just read the words, it understands the structure of a document: which text is a heading, which numbers belong in a table, and which value belongs to which label. It offers prebuilt models for common documents, such as invoices, receipts, business cards, and identity documents, returning named fields like invoice number, vendor name, and total amount. It also offers a layout model that extracts text, tables, and checkboxes from any document, and custom models that you can train on a small number of your own sample forms so it learns your own special layouts.

Azure AI Translator

Translator converts text from one language to another, supporting a very large number of languages. It can detect the source language itself, translate to several target languages in a single call, and translate whole documents while keeping their formatting. A custom translator feature lets you provide your own example translations so the service learns your company’s special terms, such as product names that must never be translated. It can also transliterate, which means writing a word using a different alphabet without changing the language.

Beyond seeing, hearing, and reading, the family now includes services that guard content, find knowledge, and generate new text.

Azure AI Content Safety

Any app that lets people post text or images, or that shows machine-generated writing, needs a way to catch harmful material. Content Safety checks text and images for categories such as hate, sexual content, violence, and self-harm, and gives each a severity score. You choose how strict to be. An app for children can block even mild cases, while a news forum may allow more. It also offers tools to shield generative AI from attempts to trick it, often called prompt attacks, in which a user tries to make the system ignore its rules.

Azure AI Search

Azure AI Search, formerly Azure Cognitive Search, is a managed search engine for your own content. You load documents into an index, a structure built for very fast searching, and users can search it with keywords or with questions in plain words. It can also run skills during loading, which are small AI steps from the other Cognitive Services. For example, it can read text from scanned pages with OCR, detect languages, and extract names of people and places, then store all of that along with the document so that the search results are richer. This process is called AI enrichment.

Azure OpenAI Service

Azure OpenAI offers powerful large language models, systems trained on huge amounts of text that can write, summarize, answer questions, translate, and reason about text and sometimes images. It runs inside Azure with Azure’s security, networking, and compliance features. A common design called retrieval augmented generation, or RAG, pairs these models with search: the app first finds the most relevant pieces of your own documents using Azure AI Search, then hands them to the model, which writes an answer based on them. This keeps answers tied to your real information and reduces made-up facts.

flowchart LR
    U["User question"] --> APP["Application"]
    APP --> CS1["Content Safety check on the question"]
    CS1 --> SR["AI Search finds relevant passages"]
    SR --> LLM["Azure OpenAI writes an answer from the passages"]
    LLM --> CS2["Content Safety check on the answer"]
    CS2 --> ANS["Answer with sources"]
    

What actually happens, step by step, when your app asks the service a question? Let us follow one request.

Suppose your backend wants to analyze the sentiment of a customer review. First, your code builds a request: a small package of data, usually in a text format called JSON, containing the review text and some options. It sends this package over a secure connection, protected by TLS, the encryption that keeps web traffic private, to your resource’s endpoint. The request carries your proof of identity: either a key, or a token obtained for your managed identity.

The request arrives at Microsoft’s front door in the region of your resource. Here several checks happen before any AI model is touched. The system confirms the key or token is valid, that the resource exists and is allowed to use this feature, that the network rules permit this caller, and that you have not gone over your allowed rate, the number of requests per second. If any check fails, the request is rejected early, with a clear error code, so no model time is wasted. If all checks pass, the front door sends your request to a pool of computers running the right model. The model analyzes the text and produces a result. The front door counts one transaction for billing, writes metrics, and returns the answer to your backend as another JSON package.

sequenceDiagram
    participant App as Your backend
    participant Door as Service front door
    participant Model as AI model pool
    participant Mon as Monitoring and billing
    App->>Door: Send request over TLS with key or token
    Door->>Door: Check identity, network rules and rate limit
    Door->>Model: Forward the valid request
    Model-->>Door: Return analysis result
    Door->>Mon: Record usage and metrics
    Door-->>App: Send answer as JSON
    

Three styles of calling

For the asynchronous style, the pattern is the same across services. Your app submits the job and the service answers at once with an operation location, a web address where you can check progress. Your app then polls, meaning it checks that address every few seconds, until the status says succeeded. Then it fetches the result. Polling too fast wastes calls and may hit limits, so wait a sensible time between checks, or use a callback or event notification where the service offers one.

There are two ways to prove who you are. One is easy and risky. The other is better.

The first way is the key, a secret code sent with each request. It is simple to start with and works from any programming language. But a key is like a house key that anyone can copy: if it leaks, anyone can use your resource until you replace it. A key also gives full power over the resource’s calls, with no way to say “only for reading.”

The second way is Microsoft Entra ID, the Azure identity system. Your application runs with a managed identity, an identity that Azure creates and manages for it, with no password to store. You give that identity a role, a named set of permissions, on the resource. Common roles include Cognitive Services User, which allows calling the services, and Cognitive Services Contributor, which also allows managing the resource. This approach is called role based access control. It lets you give each application exactly the access it needs, remove access in one place, and see in logs who did what. For this method, your resource usually needs a custom subdomain, a name unique to you in its endpoint address.

For the highest security, you can turn off local authentication on the resource, which disables keys completely, so that the only way in is through Entra ID. Where you must keep keys, store them in Azure Key Vault, give your app access to the vault through its managed identity, and rotate keys regularly, using the two-key design to switch without downtime.

Prebuilt models are general. Sometimes your words, forms, or pictures are special, and the model needs a little teaching.

Out of the box, a speech model might not know the names of your drugs, your product codes, or your regional accent. A document model might not know your own odd invoice layout. A text model might not know that “Falcon” means a product line in your company, not a bird. For such cases, many services let you customize the model by giving it examples. You do not build a new model. You adapt a strong existing one, which needs far less data and skill than full training.

A sensible order of effort

Sometimes the data cannot leave the building. Containers bring the service to the data instead.

A container is a sealed package that holds a program and everything it needs, so it runs the same way on any computer. Many Cognitive Services are offered as containers that you can run on your own servers, in other clouds, or on small devices at the edge. This is useful when your data is very sensitive and must stay on your premises, when your internet connection is slow or unreliable, or when you need extremely quick answers close to a machine on a factory floor. The container does the AI work locally, so the raw data, such as images or audio, does not travel to the cloud.

By default, these containers still contact Azure to report usage, which is how billing works. Only usage numbers are sent, not your content. For places with no internet access at all, a disconnected container mode is available for customers who sign a commitment plan, which allows running offline for a set period.

flowchart LR
    DEV["Camera or microphone on site"] --> CON["AI container on local server"]
    CON --> LOC["Local results and alerts"]
    CON -.->|"usage numbers only"| AZ["Azure billing"]
    

A resource that reads your customers’ words, faces, and documents deserves strong protection.

By default, a Cognitive Services resource has a public endpoint, reachable from the internet by anyone who holds valid credentials. Traffic is always encrypted in transit with TLS and data is encrypted at rest. For stronger protection you can narrow the doors in three steps. First, use the resource firewall to allow only chosen internet addresses. Second, allow only chosen virtual networks, which are your private networks in Azure. Third, use a private endpoint, which gives the resource a private address inside your own virtual network, and then turn off public network access entirely. With a private endpoint, your backend reaches the service over Microsoft’s private network and the service is invisible from the open internet.

Other security tools stack on top. Azure Key Vault stores any keys you must keep. Customer-managed keys, where supported, let you own the encryption keys used for your stored data and custom models. Azure Policy can enforce company rules, such as “all AI resources must use private endpoints and must have local keys disabled.” Microsoft Defender for Cloud can watch for suspicious activity such as sudden bursts of calls from odd places. And resource locks stop someone from deleting a resource by accident.

Powerful tools can cause harm when used carelessly. Responsible use is part of the design, not an afterthought.

Microsoft describes six principles for responsible AI: fairness, meaning treating people equally; reliability and safety, meaning working well and safely; privacy and security, meaning protecting data; inclusiveness, meaning serving people of all abilities and backgrounds; transparency, meaning being clear about what the system does and its limits; and accountability, meaning people remain responsible for outcomes. These principles show up in practical rules.

First, Limited Access. Some abilities, such as certain face features and custom synthetic voices, have high potential for misuse. Microsoft makes you apply and describe your use, and may refuse some uses. Second, transparency notes: for each service, Microsoft publishes a document that describes what it is good at, where it fails, and how to use it responsibly. Third, content filters are built into generative services and can be adjusted within limits. Fourth, human oversight: for decisions that affect people, such as hiring, lending, or health, a person should review the model’s suggestions.

On data privacy, Microsoft states that for these services your data belongs to you and is not used to train the base models that serve other customers. Some services keep inputs briefly for processing, abuse monitoring, or to deliver features such as custom models, and the details differ from service to service, so read the data handling notes for each one and the options for turning off logging where they exist. Choose the region carefully, since your data is processed in the region of the resource, which matters for laws about where data may be handled.

The service is shared by many customers. Good designs expect limits and failures and plan for them.

Most services state an availability target, often about 99.9 percent, which allows nearly nine hours of downtime in a year. The exact number varies by service, so check each one. A request can fail for several reasons, and it helps to know the codes. A client error, starting with the digit four, means something is wrong with your request, such as a bad key or too large a file. A server error, starting with the digit five, means a problem on the service side, often short-lived. A special client error, 429 Too Many Requests, means you went over your rate limit. Each resource has quotas, limits on requests per second or per minute, and some services also limit the sizes of files and the length of text.

The standard answer to temporary failures and rate limits is a retry with exponential backoff. Your app waits a short time, tries again, waits twice as long if it fails again, and so on, with a small random variation called jitter so that many clients do not all retry at the same instant. Many responses include a header telling you how many seconds to wait, and a good client honors it. The official software kits from Microsoft already include sensible retry behavior, which you should keep switched on.

For protection against a whole region having trouble, deploy two resources in two regions, usually a pair of regions in the same geography. Your app sends calls to the main region and automatically switches to the second one when errors continue. Put a front layer such as Azure API Management, Azure Front Door, or your own failover code in charge of the switch. Remember that custom models, custom vocabularies, and search indexes must exist in both regions, so keep their training data and setup in source control, so you can recreate them quickly.

flowchart TB
    APP["Your application"] --> GW["API Management or failover logic"]
    GW -->|"normal traffic"| R1["AI resource - region one"]
    GW -.->|"on repeated failure"| R2["AI resource - region two"]
    R1 --> M1["Custom models in region one"]
    R2 --> M2["Copy of custom models in region two"]
    

Failure scenarios and recovery

You cannot manage what you cannot see. Azure gives you numbers for every resource.

The main tool is Azure Monitor, Azure’s central place for numbers, charts, and alerts. A metric is a measurement taken over time. For Cognitive Services, useful metrics include the total number of calls, the number of successful calls, the counts of client errors and server errors, the latency or time each call took, and the number of blocked calls caused by rate limits. Other measures depend on the service, for example characters translated, audio seconds processed, or tokens used by language models, where a token is a small piece of a word.

For deeper detail, turn on diagnostic settings to send logs to a Log Analytics workspace, a searchable store with a query language. The request logs show when each call happened, which operation it was, how long it took, and its result code, without storing the content of your data. Set alerts so that the right person is told when error counts rise, latency climbs, or usage jumps unexpectedly. A sudden spike in calls may be a feature launch, a bug that loops, or a stolen key, and you want to know within minutes, not at the end of the month.

Many teams also place Azure API Management in front of their AI resources. It becomes a single, controlled door: it holds the keys or identity, applies per-team limits, caches repeated answers, records who used what for charging back costs, and gives one place to add policies, such as removing sensitive data before a request goes out.

Fast AI features feel magical. Slow ones feel broken. A few habits make the difference.

The time a user waits has several parts: the trip across the network to the service, the time the request waits for its turn, the time the model thinks, and the trip back. Tuning begins by measuring each part, so you do not guess. Most of the controllable delay sits in four places.

For generative models, speed also depends on the length of the prompt and the length of the answer, both measured in tokens. A shorter prompt with only the passages that matter, and a limit on answer length, makes responses faster and cheaper. For steady, high-volume use, some generative services offer provisioned throughput, which reserves a fixed amount of capacity for you so that speed stays predictable instead of varying with the load of other customers.

Pay-per-use is gentle for small projects and can surprise large ones. Understand the meter.

Almost every service is billed by a unit of work, and the unit differs by service. Vision and many document features charge per transaction, usually priced per thousand. Language features charge per text record, often a chunk of a thousand characters. Speech charges per hour of audio for transcription and per million characters for synthesized voice. Translator charges per million characters. Generative models charge per token, with input and output tokens priced differently. Prices change, so confirm them on the current price list for your region.

There are three kinds of plan. The free tier gives a small monthly allowance, good for tests but not for production because of its tight limits. The pay-as-you-go tier is the default for real use, where you pay for exactly what you use. Commitment tiers offer a lower rate if you agree to pay for a fixed amount each month, which saves money when your usage is steady and predictable. For generative models there is also provisioned throughput, billed for reserved capacity whether you use it or not.

No tool is right for everything. A fair look at both sides helps you choose with open eyes.

The big trade-offs

Speed versus control. A prebuilt service gives you results this week, while a custom model gives finer control but takes much longer. Cost per call versus fixed cost. At low volume, pay-per-use is cheapest. At very high steady volume, owning your own model or buying commitment tiers may be better. Cloud convenience versus data residency. The cloud is easiest, and containers keep data on site at the price of more management. Accuracy versus fairness. A model that is accurate on average may be less accurate for some groups, so testing and human review matter. Generality versus specialization. General models handle many cases adequately, while custom models excel on your narrow ones.

Proven recipes for building with these services, and a guide for when something else fits better.

Pattern: the document processing pipeline

This is the most common pattern in business. A document lands in storage, an event wakes a small program, the program calls Document Intelligence to read it, and the structured result is stored in a database and indexed for search. Low-confidence results go to a human review queue.

flowchart LR
    UP["Document uploaded to storage"] --> EV["Storage event"]
    EV --> FN["Function app"]
    FN --> DI["Document Intelligence reads fields"]
    DI --> CHK["Confidence check"]
    CHK -->|"high"| DB["Database and search index"]
    CHK -->|"low"| HR["Human review queue"]
    HR --> DB
    

Pattern: the voice analytics pipeline

Recorded calls are transcribed by Speech, personal data is masked by Language, and sentiment, topics, and summaries are extracted. The results feed a dashboard and a quality team.

flowchart LR
    AUD["Call recordings"] --> SP["Speech batch transcription"]
    SP --> PII["Language masks personal data"]
    PII --> SN["Sentiment, topics and summary"]
    SN --> DASH["Dashboard for managers"]
    SN --> ALR["Alerts for angry customers"]
    

Choosing among approaches

An anti-pattern is a habit that looks sensible but leads to pain.

A short checklist that separates calm operations from late-night emergencies.

Common mistakes

• Mixing up resource regions. A resource in a faraway region adds delay, and some features are not available in every region.
• Forgetting the custom subdomain. Entra ID sign-in often needs it, and errors can be confusing.
• Sending oversized inputs. Large files fail with size errors, or waste time and money.
• Ignoring language settings. A wrong or missing language hint lowers accuracy for speech and text.
• No test set. Without examples kept apart, you cannot tell if a change made things better.
• Treating the model as a database. Models do not store your facts. Use search and your own data stores for facts.
• Skipping private DNS. With private endpoints, wrong name resolution sends traffic to the blocked public path.

Where do these services shine in practice?

Yes, in practice. Microsoft renamed the family from Azure Cognitive Services to Azure AI Services. Older names still appear in many documents and discussions.

No. For prebuilt abilities you send data to an API and use the result. Customization needs more care but still far less expertise than building a model from scratch.

A multi-service resource gives one key and endpoint for many services. A single-service resource is for one service and gives separate billing, access control, and sometimes a free tier.

Use Microsoft Entra ID with a managed identity and role based access. If you must use keys, store them in Key Vault, rotate them, and consider disabling local keys.

You sent more requests than your limit allows. Wait, retry with exponential backoff, smooth the traffic with a queue, or request a higher quota.

Microsoft states that customer data is not used to train the base models for other customers. Details on retention and monitoring vary by service, so read each service’s data privacy notes.

For many services, yes, by running containers locally. Some even support disconnected use with a commitment plan. Check that the exact feature you need is offered as a container.

Create a private endpoint in your virtual network, set up the matching private DNS, and turn off public network access on the resource.

Try custom vocabulary or custom models where the service supports them, such as custom speech, custom translator, or custom extraction models for documents.

Cache results, trim inputs, batch requests, choose the right feature, use commitment tiers for steady loads, tag resources, and set budgets with alerts.

A common design pairs Azure AI Search to find relevant passages with Azure OpenAI to write answers, and Content Safety to check inputs and outputs.

Microsoft announces retirement dates in advance and usually points to a replacement. Watch the announcements and plan migration before the date, because old APIs eventually stop working.