Configure detection of sentiment, tone, safety issues, and sensitive content

Four detection needs that sound like one capability are served by three different services with three different statuses. Sentiment is an Azure Language feature — and a legacy one. Sensitive content means PII detection, which is core. Safety issues means Content Safety's harm categories. Getting the mapping right, and knowing which is legacy, is most of this objective.

Why This Matters

Sentiment and PII sit on opposite sides of the split. PII detection is core, "recommended for new development"; sentiment analysis and opinion mining is legacy, "supported for existing implementations".

"Safety" is a different service. Harm categories live in Content Safety with severity levels and thresholds, not in Azure Language.

PII has three surfaces and a preview. Text, conversation, and document PII — with anonymization (synthetic replacement) currently in preview.

Prerequisites

• The core/legacy split in Azure Language.
• The four harm categories and the safe/low/medium/high levels.
• That Content Understanding can classify against an enum.
• Container availability for on-premises deployment.

Learning Objectives

By the end of this lesson you will be able to:

1. Map each detection need to the correct service.
2. Configure PII detection across its three surfaces.
3. Apply sentiment analysis and opinion mining, with its legacy status.
4. Detect tone where no preconfigured feature exists.
5. Choose containers where data cannot leave the environment.

Building Blocks

PII detection — core. It "identifies entities in text and conversations (chat or transcripts) that are associated with individuals", across three surfaces:

The Document PII playground in Foundry is generally available, ships with "curated sample documents and expected outputs" for evaluating detection "without uploading your own data", and "uses the same Document PII model and policies as the production API, so results align with production behavior". Note the caveat: the "anonymization feature (synthetic replacement) is currently available in preview".

The documented use: "Detect and redact sensitive information such as PII and PHI" across "unstructured text, transcribed conversations, native documents".

Sentiment analysis and opinion mining — legacy. "Preconfigured features that help you understand public perception of your brand or topic. These features analyze text to identify positive or negative sentiments and can link them to specific elements within the text." Preconfigured means "the AI models it uses can't be changed".

Text analytics for health — core. "Extracts and labels relevant health information from unstructured text."

Content Safety. Four harm categories — Hate and Fairness, Sexual, Violence, Self-Harm — with "classification can be multi-labeled", four severity levels safe/low/medium/high, and a medium default threshold on both prompts and completions. Text supports the full 0–7 scale.

Containers exist for sentiment analysis, language detection, key phrase extraction, custom NER, text analytics for health, and summarization.

Deep Dive

Mapping the requirement to the service

Four phrasings recur, and each names one service.

"Identify customer sentiment in reviews." — sentiment analysis and opinion mining, which identifies "positive or negative sentiments" and can "link them to specific elements within the text". Opinion mining is the second half worth remembering: it attaches sentiment to a specific aspect, so a review can be positive about delivery and negative about packaging in one result.

"Redact personal information before storage." — PII detection, a core capability covering "PII and PHI" across text, conversations, and native documents.

"Block harmful content." — Content Safety, whose four harm categories and severity thresholds are a different service with different mechanics.

"Detect the tone of the message — frustrated, urgent, formal." — none of the above. Sentiment is positive or negative, not a tone taxonomy. A tone requirement means a generative approach: a Content Understanding classify field with an enum of your tone labels, or a prompt with a defined structure.

That last case is the reliable trap: a scenario asking for a nuanced emotional or stylistic label, with sentiment analysis among the options.

PII detection in depth

This is the core capability of the four, and the detail is examinable.

Three surfaces. Text PII for unstructured text. Conversation PII for "chat or transcripts" — relevant because conversational text carries identifiers across turns. Document PII for native formats (.pdf, .docx, .txt), which preserves the fact that documents have structure rather than being flattened first.

The playground is a genuine evaluation tool. It is generally available, ships with "curated sample documents and expected outputs", lets you "compare detection results across entity types before you transition to uploading real documents", and — the important part — "uses the same Document PII model and policies as the production API, so results align with production behavior". So evaluation there is predictive, not indicative.

Detection and anonymization are different maturities. Detection is generally available; the "anonymization feature (synthetic replacement)" is "currently available in preview". A compliance workflow that must replace identifiers with realistic substitutes is depending on a preview feature — which matters under a production-only constraint. Detect-and-redact is the GA path.

PHI is in scope. The documented use covers "PII and PHI", so health identifiers are handled here. That sits alongside text analytics for health, which extracts clinical information rather than identifying individuals — two different jobs on the same documents.

Sentiment, opinion mining, and their limits

Sentiment analysis identifies "positive or negative sentiments". Opinion mining links those sentiments "to specific elements within the text" — the aspect-level refinement.

Three limits shape design.

It is preconfigured. "The AI models it uses can't be changed", so there is no training your own sentiment categories. A domain where "expensive" is neutral rather than negative cannot be taught.

It is legacy. Supported for existing implementations; a new build should weigh a generative alternative, particularly since a schema-driven approach can produce sentiment and tone and a rationale in one pass with confidence scores.

The taxonomy is fixed to polarity. Positive, negative, neutral, mixed — not urgency, formality, frustration, or intent. Those need a vocabulary you define.

Where sentiment analysis remains strongly indicated: an existing implementation, a need for consistent polarity scoring at scale with no setup, and — notably — an on-premises requirement, since sentiment analysis has a container and a generative approach generally does not offer that.

Composing the checks

Real pipelines run several of these together, and order matters.

Detect and redact PII first where downstream processing is generative, so identifiers do not enter a model's context unnecessarily. That is a data-minimisation argument as much as a compliance one.

Run safety checks at the boundary. Content Safety's filters apply at the model deployment, defaulting to medium on prompts and completions, and they classify harmful content — not sentiment, not tone, and not sensitive information. A negative review is not harmful content, and a document full of national identifiers is not either.

Run analytical detection on the redacted text. Sentiment, tone, and topic work fine on text with identifiers removed, and keeping that order limits exposure.

Route on confidence. Where a schema-driven approach is used, confidence scores from 0 to 1 allow the uncertain cases to reach a human rather than reviewing everything.

The framing to carry: PII is about individuals, harm categories are about content, sentiment is about polarity, and tone is about a vocabulary you define. Four questions, four answers.

Worked Examples

Example 1 — redacting call transcripts. A contact centre must remove personal information from transcripts before analysis, replacing identifiers with realistic substitutes.

Conversation PII, which covers "chat or transcripts" and is a core capability spanning "PII and PHI". The realistic-substitute requirement is anonymization (synthetic replacement), which is "currently available in preview" — so under a production-only constraint, detect-and-redact is the GA path and synthetic replacement is not yet available for reliance.

Example 2 — detecting frustration. A team wants to flag messages where the customer sounds frustrated or the request is urgent.

Not sentiment analysis — that identifies "positive or negative sentiments", a polarity scale, and is preconfigured so it cannot be taught new labels. Define the vocabulary yourself: a Content Understanding classify field with an enum such as , plus a generate field for the rationale and confidence for routing.

Example 3 — sentiment on-premises. A bank must score review sentiment without data leaving its environment.

Sentiment analysis has a container, alongside language detection, key phrase extraction, custom NER, text analytics for health, and summarization — used to "bring the service closer to your data for compliance, security, or other operational reasons". Its legacy status is acceptable here because the container requirement is decisive; a generative alternative does not offer the same on-premises path.

Visual Explanations

Need to service:

Pipeline order:

Common Mistakes

Using sentiment analysis for tone. It is polarity, not emotion.

Trying to train sentiment categories. It is preconfigured.

Assuming sentiment is core. It is legacy; PII detection is core.

Treating harm categories as sentiment. A negative review is not harmful content.

Relying on synthetic replacement in production. Anonymization is preview.

Flattening documents before PII detection. Document PII handles native formats.

Confusing PII detection with text analytics for health. Individuals against clinical content.

Assuming any feature can run in a container. The list is specific.

Running analysis before redaction and exposing identifiers unnecessarily.

Practice Exercises

1. Map each to a service: frustration; a national insurance number; graphic violence; a negative product review.
2. Name PII detection's three surfaces and say which part is preview.
3. What does opinion mining add to sentiment analysis, and what can neither do?
4. Why might a legacy feature still be the right answer?
5. Give a sensible order for PII, safety, and analytical checks, with the reason.

Summary & Concept Map

Four detection needs resolve to three services. PII detection is core, covers "PII and PHI" across text, conversation, and document surfaces, has a GA playground that mirrors production behaviour, and offers detection as GA while anonymization by synthetic replacement is preview. Sentiment analysis and opinion mining is legacy and preconfigured — polarity, with opinion mining linking sentiment to specific elements — so it cannot be taught new categories, though its container can make it decisive under residency constraints. Content Safety handles harmful content through four categories at safe/low/medium/high, defaulting to medium on prompts and completions. And tone — frustration, urgency, formality — has no preconfigured feature at all, so it needs a classify field with your own enum plus a rationale and confidence-based routing.

Sources and freshness

Written against current Microsoft Learn documentation for the AI-103 skills measured (16 April 2026), reviewed 2026-08-20. Microsoft Learn controls every changing product contract — availability, preview status, quotas, limits, regional support, naming, and retirement dates all move independently of this lesson. Where a scenario turns on a specific number or a GA/preview boundary, confirm it against the product's own page before relying on it.