Azure AI Language

About Azure AI Language

Azure AI Language is Microsoft's managed natural language processing service for applications that need to detect, classify, summarize, redact, or understand written language without building every model from scratch. Microsoft currently presents the service as Azure Language in Foundry Tools. Its core capabilities include PII detection, language detection, prebuilt and custom named entity recognition, and Text Analytics for Health. Established legacy capabilities include sentiment analysis, key phrase extraction, conversational language understanding, question answering, orchestration, custom text classification, entity linking, and summarization. The service is available through Microsoft Foundry, REST APIs, client libraries, and selected container deployments. Microsoft now also exposes Azure Language capabilities to AI agents through an Azure Language MCP server and prebuilt Language agents.

What can Azure AI Language do?

Azure AI Language is a collection of specialized NLP capabilities rather than one general-purpose model. Microsoft's current documentation separates actively evolving core capabilities from legacy capabilities that remain supported for existing implementations. Core capabilities include PII detection, language detection, prebuilt and custom named entity recognition, and Text Analytics for Health. Legacy capabilities include Conversational Language Understanding, custom text classification, entity linking, key phrase extraction, orchestration workflow, question answering, sentiment analysis and opinion mining, and summarization.

This lifecycle distinction matters for new projects. Microsoft recommends core capabilities for new development and long-term planning. Legacy capabilities remain supported for established workloads, but buyers should verify the status of the exact feature they want before making it a long-term dependency. Synthetic replacement anonymization for text PII is currently a preview feature, so it should not be treated as generally available simply because other PII capabilities are production ready.

What changed with Microsoft Foundry, MCP, and Language agents?

Microsoft now positions Azure Language inside Microsoft Foundry while keeping REST APIs and client libraries available for application integration. The current Azure Language overview also documents an Azure Language MCP server that can expose Language capabilities to AI agents through Model Context Protocol. Microsoft provides a remote server through the Foundry Tool Catalog and a local server option for self-hosted environments.

Microsoft also documents prebuilt Azure Language agents. The Intent Routing agent is designed to route conversational flows based on user intent, while the Exact Question Answering agent is designed for controlled, exact responses to important business questions. These additions do not turn Azure Language into a general-purpose reasoning model. They provide more structured ways to use Language capabilities inside agent workflows where bounded outputs, governance, and predictable behavior matter.

How is Azure AI Language different from Translator and Azure OpenAI?

Azure AI Language is focused on understanding and analyzing text. Azure Translator is the better fit when the primary task is translating text or documents between languages. Azure OpenAI or other Foundry model deployments are more appropriate when an application needs open-ended generation, broad reasoning, rewriting, tool use, or long-context synthesis rather than a bounded NLP operation.

A dedicated Language API can be easier to govern when the required output is structured, such as entities, language labels, PII categories, classifications, sentiment, or defined summaries. A generative model can be more flexible, but it introduces prompt design, model selection, token-based pricing, and different evaluation requirements. Buyers should choose the narrowest service that reliably solves the job.

How does Azure AI Language pricing work?

Pricing was checked on August 29, 2026 using Microsoft's current Azure Language pricing page. Many Language capabilities are metered by text records, and Microsoft defines one text record as up to 1,000 characters for those meters. The Free web tier includes limited shared monthly usage for eligible capabilities, while paid Standard usage varies by capability and volume. Microsoft also lists commitment tiers for some larger predictable workloads.

Custom features can introduce separate training or model-hosting charges, and question answering scenarios can require an Azure AI Search resource. This means total solution cost may include dependent Azure services rather than only Language API calls. Pricing varies by feature, agreement, region, and currency, so a single universal per-request price would be misleading.

What service limits should buyers plan for?

Microsoft's current limits for preconfigured Language features are specific enough that production teams should design around the exact API they use. For synchronous preconfigured features other than Text Analytics for Health, a document can contain up to 5,120 text elements. Asynchronous requests can contain up to 125,000 characters across all submitted documents, with a maximum of 25 documents. The maximum request size for preconfigured features is 1 MB.

Document counts also vary by capability. Microsoft currently lists up to 1,000 documents per language-detection request, 10 for sentiment analysis or opinion mining, 5 for named entity recognition or text PII detection, and 25 for document summarization. For Text Analytics for Health, the web API supports up to 25 documents per request while the container supports up to 1,000, subject to the documented character limits.

Rate limits differ by tier and feature. Microsoft's current preconfigured-feature guidance lists S or multi-service resources at up to 1,000 requests per second and 1,000 per minute, while S0 and F0 are listed at 100 requests per second and 300 per minute. Customizable features such as Conversational Language Understanding have their own limits. For example, Microsoft currently documents up to 500 CLU projects per resource, prediction API calls up to 1,000 per minute, and up to 50,000 utterances per CLU project.

What changed in Azure AI Language during 2026?

Microsoft continues to move Azure Language authoring and testing into Microsoft Foundry. The current Azure Language overview was updated July 21, 2026 and now documents MCP integration and Azure Language agents alongside the core and legacy capability split. Language Studio is scheduled for retirement on March 20, 2027. Microsoft states that after that date the Language Studio portal will no longer be available, while existing projects, data, and service endpoints remain unaffected.

This is a tooling transition rather than a retirement of Azure Language itself. Teams still using Language Studio should plan the authoring and testing migration to Microsoft Foundry, while separately evaluating the lifecycle of the specific Language capability their application depends on. Older LUIS workloads should follow Microsoft's current migration guidance toward Conversational Language Understanding.

How should security and privacy be handled?

Azure Language can process highly sensitive text, so access and data handling should be designed before production use. Organizations should use Azure security controls appropriate to their workload, keep credentials out of client applications, rotate keys where keys are used, and use private networking controls when the deployment requires network isolation.

PII detection can help identify and redact personal information, but it does not replace an organization's data-classification, retention, legal, or access-control policies. Teams handling regulated data should verify feature availability, supported regions, data residency requirements, and any preview terms before deployment. Model output should also be evaluated on representative data because entity recognition, PII detection, sentiment, classification, and summarization can produce incorrect or incomplete results.

Where does Azure AI Language fit in an application architecture?

A common architecture places Azure Language behind an application API, workflow, or event-processing layer. Text can arrive from a website, support system, document pipeline, call transcription, or internal application. The application sends only the content needed by the selected Language capability and then stores, searches, routes, or acts on the structured result.

The current MCP server adds another integration pattern for agent systems. Teams can expose selected Language tools to an agent through the remote Foundry Tool Catalog option or a locally hosted MCP server. That approach is useful when an agent needs a bounded NLP operation, such as detecting PII or extracting entities, without asking a general-purpose model to imitate a specialist API. Traditional REST and SDK integration remains appropriate for deterministic application flows.

What are the main limitations?

Azure AI Language does not guarantee perfect interpretation. Entity recognition, PII detection, classification, sentiment analysis, question answering, and summarization can all produce incorrect or incomplete results, especially with ambiguous language, domain jargon, poor text quality, or languages with less model coverage. Custom models require representative labeled data and ongoing evaluation. Preview capabilities can change faster than generally available APIs.

The service is also not a general-purpose reasoning engine. If a workflow needs broad reasoning, long-context synthesis, free-form generation, or complex tool orchestration, Azure OpenAI or another Foundry model deployment may fit better. Service limits are feature-specific, so teams should not assume that throughput or request sizes documented for one Language capability apply to another.

Who should choose Azure AI Language?

Azure AI Language is a strong fit for teams that need managed NLP APIs, Azure governance, and predictable structured outputs. It is especially relevant for privacy workflows, entity extraction, language detection, healthcare text analysis, classification, and established applications already using supported legacy capabilities such as sentiment analysis, question answering, or conversational understanding.

It is also useful when an AI agent needs specialist language-processing tools through MCP instead of relying entirely on a general-purpose model. Organizations already standardized on Azure can keep networking, identity, monitoring, and billing in the same cloud environment while choosing between direct APIs, client libraries, containers for supported capabilities, Foundry experiences, or MCP integration.

Who should choose something else?

Choose Azure Translator when translation is the primary requirement. Choose Azure OpenAI or another Foundry model deployment when the application needs generative responses, broad reasoning, rewriting, long-context synthesis, or flexible tool use. Choose a self-hosted NLP stack when offline operation, model portability, or full deployment control matters more than managed-service convenience. For simple deterministic rules or keyword matching, a full NLP service may add unnecessary cost and complexity.

For a new project, also check whether the required Language capability is classified by Microsoft as core or legacy. If it is legacy, compare the long-term architecture against current Foundry alternatives before making it a central dependency.