AB-731 AI Transformation Leader Questions and Answers

Azure Machine Learning

Forecasting product demand from historical sales data is a predictive analytics / machine learning use case. It typically requires selecting an appropriate forecasting approach (for example, regression, tree-based methods, or time-series models), preparing and splitting historical data, training and validating the model, tuning hyperparameters, and then deploying the model for ongoing inference. The Microsoft service designed to support that end-to-end ML lifecycle is Azure Machine Learning, which is why it correctly completes the sentence.

Azure Machine Learning provides the tooling and infrastructure to: manage datasets, run training jobs on scalable compute, track experiments, compare model performance, register models, and operationalize them through managed endpoints and pipelines. This makes it well-suited for iterative forecasting work, where you may retrain on new data regularly, monitor drift, and update models as product lines, promotions, or seasonality patterns change.

The other options do not directly fit “train a model” for forecasting. Azure AI Search is an indexing/retrieval service used to search and ground generative AI responses, not for training predictive models. Azure OpenAI provides access to large language and multimodal models for generative tasks (drafting, summarizing, Q & A) and is not the primary platform for building classical forecasting models. Microsoft Foundry is a broader platform experience for building and governing AI apps and agents, but the specific service for training a forecasting model on historical sales data is Azure Machine Learning.

Microsoft Foundry is positioned as a unified, enterprise-grade platform that helps organizations build, deploy, scale, and govern AI apps and agents—especially generative AI solutions that need to work with business context and internal data. That directly aligns with A: Foundry provides a scalable platform for developing and deploying generative AI solutions. Microsoft describes Foundry as an interoperable platform that makes it easier to build, deploy, and scale AI apps and agents, while also providing centralized security and governance features for organizations.

B is incorrect because Foundry does not remove model choice/configuration; in fact, it supports selecting among models and using tools/frameworks to build solutions. You still choose appropriate model(s), configure endpoints, and design grounding and safety controls.

C and D are not the best characterization of Foundry’s primary benefit. While Foundry offers “friendly interfaces,” Microsoft primarily positions it for developers, model builders, and enterprise AI operations—not as a low-code platform for business users (that role is more commonly filled by Copilot Studio/Power Platform).

 Extract information from invoices and credit notes: Azure Document Intelligence in Foundry Tools

 Identify discussion topics in customer service call recordings: Azure AI Search

 Detect customer sentiment and opinions: Azure AI Search

To minimize development time, you should select services that provide prebuilt extraction and enrichment rather than building custom models.

For invoices and credit notes, the best fit is Azure Document Intelligence because it is purpose-built for intelligent document processing and includes prebuilt models (such as invoice-style extraction) that return structured fields (invoice number, vendor, totals, dates, line items). This directly satisfies “extract information” from financial documents without custom ML training.

For customer service call recordings, the raw input is audio, but the task is to identify “discussion topics,” which is an information discovery and text-enrichment problem once the calls are transcribed. Azure AI Search is the correct recommendation because it can index large collections of content and apply built-in AI enrichment (for example, key phrase extraction and entity extraction) to help derive and query “topics” across many records.

For sentiment and opinions, Azure AI Search is again the best choice in this constrained list because it can run built-in enrichment skills over ingested text (such as transcripts or notes) to annotate content with sentiment-related metadata and then make that enriched data searchable and filterable at scale. This approach delivers fast time-to-value: ingest → enrich → index → query, without standing up a custom training pipeline.

Preventing generative AI from accessing confidential or classified information is primarily a data access and classification control problem. The most effective broad solution is data governance (B)—the framework of policies and controls that ensures sensitive content is identified, classified, protected, and access is restricted using least privilege. Data governance includes information classification/sensitivity labels, access control reviews, secure sharing practices, data loss prevention (DLP), and auditing—controls that directly limit what data is available to the AI through permission trimming and policy enforcement.

An information barrier (A) policy is more specific: it’s intended to prevent communication and collaboration between defined user groups (often for regulatory/ethical walls). It does not comprehensively address document classification or restrict AI access to sensitive files across the tenant. A data retention policy (C) governs how long content is kept and when it’s deleted; it’s not a primary access-prevention mechanism. Communication monitoring (D) is a detection/oversight control; it can help identify risky activity, but it does not itself prevent access to confidential content by the AI.

Therefore, to prevent AI from surfacing confidential/classified data during summarization and analysis, you should recommend data governance as the primary control layer.

Grounding is an AI solution pattern used to improve response quality by ensuring the model’s output is based on trusted, relevant information provided at inference time, rather than relying only on what the model “remembers” from training. Therefore, C is correct: grounding anchors responses in specific data sources .

In practical deployments, grounding commonly uses retrieval (often called Retrieval Augmented Generation, or RAG) where the system first finds relevant content from approved sources—such as internal policy documents, product documentation, knowledge bases, or databases—and then includes that content in the prompt context sent to the model. Microsoft’s guidance describes grounding data as information supplied at inference time to help responses become more accurate and relevant because the model is guided by authoritative, up-to-date content that may not have been part of original training.

The other options do not define grounding. A relates to inclusion practices and diversity considerations, which are important for responsible AI but are not what grounding means. B describes transparency/explainability concepts. D relates to model evaluation/communication of limitations. Grounding is specifically about tying outputs to known sources, which reduces hallucinations and improves business trust in the generated responses.

crafting clear instructions to guide generative AI solutions in generating context-appropriate content.

Prompt engineering is fundamentally about how you communicate intent to a generative AI model so it produces outputs that meet business expectations. The best completion is “crafting clear instructions to guide generative AI solutions in generating context-appropriate content” because it captures the practical, day-to-day discipline: shaping the input (prompt) with the right task framing, constraints, context, and output format.

In real deployments, prompt engineering includes specifying the role and objective (for example, “act as a customer support agent”), providing the necessary context (product details, policy excerpts, audience), adding explicit requirements (tone, length, must/must-not statements), and defining structured output (JSON fields, bullet sections, headings). It can also include adding examples (few-shot prompting), clarifying what to do when information is missing, and instructing the model to cite only provided sources or to ask follow-up questions. These techniques reduce ambiguity, improve consistency, and lower the risk of hallucinations or off-brand responses.

The other options are not accurate definitions. “Integrating AI-powered tools into business workflows” describes solution adoption/integration, not prompt engineering. “Identifying and fixing errors in AI-generated content” is review/editing or quality assurance. “Designing, developing, and training generative AI models” is model development/ML engineering. Prompt engineering operates without changing model weights; it’s about steering model behavior through well-constructed instructions and context.

For a user to access organizational data from a mobile device, the user needs a Microsoft 365 Copilot license. No

To reason over your organizational data by using Microsoft Graph, you need a Microsoft 365 Copilot license. Yes

To use the Analyst agent, you need a Microsoft 365 Copilot license. Yes

Top of Form

Bottom of Form

The key distinction here is between Copilot Chat capabilities available with a standard Microsoft 365 subscription and the full Microsoft 365 Copilot add-on that enables richer, in-context experiences grounded in organizational data.

Mobile access to organizational data does not inherently require a Microsoft 365 Copilot license. Microsoft’s Microsoft 365 Copilot app (and related mobile experiences) can provide Copilot Chat for work/school accounts with a Microsoft 365 license, so simply accessing organizational content on a mobile device is not the same as having the paid Copilot add-on. The statement claims a Copilot license is required just to access org data from mobile, which is too broad—there are mobile Microsoft 365 apps that access org data without the Copilot add-on.

Reasoning over organizational data via Microsoft Graph is a core value proposition of Microsoft 365 Copilot. Microsoft documents explain that Microsoft 365 Copilot connects LLMs to your organization’s content and context through Microsoft Graph and generates responses “anchored” in organizational data. That deeper integration is tied to the Microsoft 365 Copilot experience (an add-on license).

Analyst is a “reasoning agent” within Microsoft 365 Copilot and Microsoft states that users with a Microsoft 365 Copilot license can use Analyst (with defined usage limits). Therefore, the Analyst agent requires the Microsoft 365 Copilot license.

Answer Area

Microsoft Copilot provides a single AI app that has identical features and experiences across all Microsoft products. Answer: No

Microsoft 365 Copilot delivers AI capabilities for business users that use Microsoft 365 apps. Answer: Yes

Microsoft Security Copilot helps companies understand risks and the organizational security posture. Answer: Yes

No — “Copilot” is an umbrella brand across Microsoft, but the experiences are not identical. Different Copilots target different workloads (productivity, security, development, business apps) and therefore expose different capabilities, connectors, permissions models, and admin controls. For example, Microsoft 365 Copilot is embedded in Word/Excel/PowerPoint/Outlook/Teams, while Security Copilot is built for SOC workflows and integrates with security tooling; they are intentionally not the same app with the same features.

Yes — Microsoft 365 Copilot is specifically designed to deliver generative AI assistance for users working in Microsoft 365 applications. It enhances common business tasks such as drafting, summarizing, meeting recap, creating presentations, and working with documents and communications—directly inside the Microsoft 365 productivity suite.

Yes — Microsoft Security Copilot is focused on security operations and helps analysts understand threats, investigate incidents, and improve visibility into security posture. Its purpose is aligned with helping organizations interpret security signals and risk context more efficiently, which supports understanding organizational risk and posture.

Microsoft 365 Copilot is designed to work within the Microsoft 365 ecosystem and use organizational context that is already governed by Microsoft Entra ID, Microsoft 365 permissions, and compliance controls. By default, Copilot can use Microsoft Graph signals and content that exist in Microsoft 365 workloads the user already has access to—most commonly emails, files, meetings, and chats. That corresponds to A.

The key concept is permission-trimming: Copilot doesn’t magically gain access to everything; it can only surface or use data that the signed-in user is permitted to access in Microsoft 365. This is what makes Copilot valuable for productivity scenarios—summarizing email threads, drafting replies, generating meeting recaps, creating documents from your files, or pulling context from Teams chats—because those artifacts are already part of daily work and already subject to tenant policies.

The other options are not “by default” Microsoft Graph content for Copilot: B (file shares) typically requires additional integration or migration into Microsoft 365 repositories or indexing via connectors; it’s not inherently available. C is unrelated to Microsoft 365 tenant work data. D (public web) is not “information in Microsoft Graph”; web grounding is a separate capability and not the default Graph workload data source referenced here.

Answer Area

Microsoft 365 Copilot helps users create and analyze content in Microsoft 365 apps. Answer: Yes

Microsoft Copilot Studio can only be used to customize Microsoft 365 Copilot. Answer: No

Microsoft Security Copilot uses AI to assign sensitivity labels to documents. Answer: No

Yes — Microsoft 365 Copilot is built into Microsoft 365 apps (such as Word, Excel, PowerPoint, Outlook, and Teams) to help users draft, summarize, rewrite, and analyze work content. This includes creating documents and presentations, summarizing emails and meetings, and analyzing information in productivity workflows. That is its primary value proposition, so the statement is true.

No — Copilot Studio is not limited to customizing Microsoft 365 Copilot. It is used to build and manage agents (conversational experiences) and extend Copilot experiences by connecting to data and actions, creating custom topics/behaviors, and integrating business processes. While it can be used to extend Microsoft 365 Copilot (for example, via declarative agents and other extensibility paths), it is broader than “only customizing Microsoft 365 Copilot,” so the statement is false.

No — Assigning sensitivity labels to documents is primarily a Microsoft Purview Information Protection capability (manual labeling, default labeling, auto-labeling) rather than a core function of Microsoft Security Copilot. Security Copilot is focused on security operations (incident investigation, threat hunting, response guidance). Although AI can support security workflows, the specific act of assigning sensitivity labels to documents is not what Security Copilot is designed to do by default, making the statement false.

Microsoft Graph

Microsoft 365 Copilot connectors (built on Microsoft Graph connectors) are used to bring external, line-of-business content into the Microsoft 365 ecosystem by ingesting it into Microsoft Graph. Once connected, the content can be indexed and made discoverable through Microsoft Search and available for Copilot experiences, enabling users to use natural language prompts to find and summarize relevant LOB information—subject to permissions and governance controls.

The other choices don’t match how Copilot connectors are positioned. Azure AI Search is an Azure indexing/retrieval service used in custom RAG solutions, but Microsoft 365 Copilot connectors are specifically designed to surface external content through Microsoft 365 experiences via Graph. Microsoft Purview focuses on data governance, compliance, and risk management rather than being the primary ingestion target for Copilot connector content. SharePoint can store content, but the connector model is about indexing external systems into Microsoft Graph so the content becomes searchable and usable across Microsoft 365, not merely placing it into SharePoint as the destination.

So the correct completion is Microsoft Graph because that is the foundational data and indexing fabric Copilot uses to reason over organizational content with appropriate permission trimming.

uses reasoning capabilities to generate deep insights based on organizational data and the web.

The sentence is best completed by the option describing Researcher as a research-oriented reasoning agent that combines information from the web and your work data to produce deeper insights. Microsoft describes Researcher as an agent built into Microsoft 365 Copilot to tackle complex, multistep research and to help users gather, analyze, and summarize information from “the web, your work documents, or both,” producing a structured output that supports decision-making. That is exactly what the completion “uses reasoning capabilities to generate deep insights based on organizational data and the web” captures.

The other dropdown options are better matches for different tools/agents: “creates visual dashboards from structured data in Excel and Power BI” is more aligned to BI/reporting workflows; “generates a pivot table and performs time series forecasting” is spreadsheet/analytics functionality; and “performs complex, multi-step, data analysis and code execution tasks over arbitrary datasets” is the hallmark positioning of the Analyst agent (“virtual data scientist”) rather than Researcher. Researcher’s differentiator is deep research across both organizational context and the open web, while Analyst’s differentiator is data analysis and computation.

The correct answer is B. Testing the AI solution to identify and mitigate unfair or inconsistent outcomes directly supports Microsoft responsible AI principles, especially fairness, reliability and safety, accountability, and inclusiveness. Before deployment, organizations should evaluate whether the system behaves consistently across different user groups, avoids discriminatory outcomes, and produces safe and reliable outputs. Automatically approving or rejecting loan applications increases risk unless strong governance and human oversight are in place. Collecting personal data can increase privacy exposure if it is not necessary and controlled. Prioritizing model performance alone is also insufficient because a technically accurate model can still produce biased, unsafe, or non-transparent outcomes. Responsible AI requires evaluation, mitigation, oversight, and monitoring.

Answer Area

A text-to-image generator can be used to translate content into other languages. Answer: No

A predictive analytics model can generate new marketing content for a company’s online ads. Answer: No

A generative AI chatbot can engage customers in personalized conversations and recommend products. Answer: Yes

No — A text-to-image generator’s primary function is to create images from text prompts , not translate text between languages. Translation is a natural language processing task typically handled by language models or dedicated translation services. A text-to-image model could illustrate translated content (e.g., generate an image based on a translated prompt), but it is not the tool used to perform the translation itself.

No — Predictive analytics models are designed to predict outcomes (forecasts, probabilities, classifications) from historical patterns, such as predicting click-through rate, churn, or next-quarter demand. They are not designed to create new ad copy or marketing creatives. Generating new marketing content is a generative AI capability (text generation), not predictive analytics.

Yes — A generative AI chatbot is well-suited to interactive, natural-language conversations . With access to product catalogs and business rules, it can ask clarifying questions, tailor responses to customer needs, and recommend products (for example, suggesting tents based on group size, season, and budget). This combines conversational generation with retrieval/recommendation logic behind the scenes, enabling personalized customer engagement at scale.

For scanned invoices, the requirement is structured field extraction (invoice number/ID, vendor, totals) from document images or PDFs at scale. The best fit is Azure Document Intelligence because it is purpose-built for document processing and provides prebuilt invoice models that combine OCR with layout/structure understanding to extract common invoice fields into a structured output. Microsoft’s invoice model is explicitly designed to analyze invoices (including scanned images) and return key fields and line items in structured form, which directly maps to this scenario.

Azure Vision (B) can perform OCR and basic image analysis, but OCR alone typically returns text without robust invoice-specific field interpretation (e.g., reliably identifying “Invoice ID” vs. “Order ID,” totals vs. subtotals, vendor vs. ship-to). Document Intelligence is optimized for advanced document structure extraction and is therefore the “best” single recommendation.

Azure AI Search (C) focuses on indexing and retrieval/knowledge mining across a corpus; it’s not the primary service for extracting invoice fields for downstream processing. Azure Machine Learning (D) could be used to build a custom model, but that adds cost and time compared with a prebuilt invoice extractor designed for this document type.

The requirement is to analyze text and identify “people, locations, and companies” mentioned in news articles. This is a classic Named Entity Recognition (NER) / entity extraction scenario, which falls under natural language processing. Azure Language in Foundry Tools is the correct choice because it provides text analytics capabilities that detect and categorize entities in unstructured text—commonly including Person, Location, and Organization. This enables downstream experiences such as topic tagging, search filters (e.g., “all articles mentioning Company X”), trend dashboards (top people/places mentioned this week), and improved content discovery.

The other options do not match the requirement. Content Safety focuses on moderating harmful or policy-violating content (for example, hate, violence, self-harm, sexual content) and is not the primary tool for extracting named entities. Azure Vision is for analyzing images and performing OCR; it would only be relevant if the articles were images or scans, but the task here is entity extraction from text articles. Azure Speech is for speech-to-text, text-to-speech, and audio analysis; it would be used if your input were audio recordings rather than written articles.

Therefore, to identify key entities (people, locations, companies) from daily news article text, the best recommendation is Azure Language in Foundry Tools.

A common reason models degrade after being successful in production is data drift (also called concept drift). Over time, the distribution of input data changes—for example, customer behavior shifts, product catalog changes, seasonality changes, new categories appear, sensors get recalibrated, or business processes evolve. When the model sees data that differs from what it was trained on, its predictions can become less accurate. This is exactly what option A describes and is the most likely “six months later” cause.

Option B is not a primary explanation for reduced predictive accuracy. More compute can improve throughput/latency, but it does not inherently improve correctness of predictions. If anything, compute constraints typically cause timeouts or slower responses, not a systematic accuracy drop.

Option C (trained incorrectly) would usually manifest earlier—poor performance from the start—unless the “incorrectness” is that the model was trained on a snapshot that later became stale (which again maps back to drift). The correct operational response is to monitor for drift, validate performance regularly, and retrain/refresh the model using newer representative data and updated features/labels.

Answer Area

Extracting structured data from forms and invoices: Answer: Azure Document Intelligence in Foundry Tools

Summarizing written content from business reports: Answer: Azure Language in Foundry Tools

Generating descriptive text for uploaded images: Answer: Azure Vision in Foundry Tools

These three tasks align to three different Azure AI capability families: document processing, language understanding/generation, and computer vision.

Forms and invoices are semi-structured documents where the business need is to extract specific fields (IDs, names, totals, dates) reliably into structured output. Azure Document Intelligence is designed for intelligent document processing and includes prebuilt models (such as invoices) as well as custom extraction options, making it the correct choice for structured data extraction from documents.

Summarizing written business reports is an NLP task focused on compressing long text into key points, themes, and action items. Azure Language provides language processing capabilities (including summarization features within language service capabilities), so it is the best fit for summarization scenarios.

Generating descriptive text for images (image captioning/description) is a computer vision task. Azure Vision can analyze uploaded images and return descriptions/captions and other visual insights, which directly matches the requirement to produce descriptive text from images.

Microsoft 365 Copilot connectors are used to bring external line-of-business and third-party content into the Microsoft 365 ecosystem so Copilot can use that information in supported experiences. Connectors help make data from systems outside Microsoft 365 discoverable and usable through Microsoft Graph-based indexing, while still respecting permissions and governance controls. This allows users to ask natural-language questions and receive answers grounded in business data from connected systems. Image and video analysis is associated with vision services, not Copilot connectors. Security incident summaries are aligned with Microsoft Security Copilot. Suggested email replies are a Microsoft 365 Copilot productivity feature in Outlook, not the primary purpose of connectors.

Answer Area

Prompt engineering changes how a generative AI model was trained. Answer: No

Prompt engineering focuses on designing clear, concise, and context-rich instructions. Answer: Yes

Effective prompt engineering involves maximizing the number of tokens used in each request. Answer: No

No — Prompt engineering does not modify model weights or retrain the model. It is an inference-time technique: you steer outputs by improving the instructions and context you send to the model. Changing how a model was trained would involve pretraining, fine-tuning, or other training methods—separate from prompt engineering.

Yes — The primary goal of prompt engineering is to reduce ambiguity and variability by providing clear instructions, the right context, and explicit output constraints. This often includes specifying role and task, providing necessary facts or grounding text, defining format (bullets, JSON, headings), and adding examples (few-shot) when helpful. Well-constructed prompts improve consistency, relevance, and usefulness of outputs.

No — Good prompt engineering does not mean “use as many tokens as possible.” In fact, using unnecessary tokens can increase cost and may degrade quality by adding noise. Effective prompts are typically as short as possible but as long as necessary: enough context to achieve accuracy and alignment, but not bloated. Token discipline matters because most pricing is token-based and long contexts can dilute attention over what’s most important.

When AI adoption spans multiple business units, the primary risk is fragmented delivery: inconsistent standards, duplicated spend, uneven risk controls, and misalignment with enterprise strategy. Establishing an AI council (D) is the best approach because it creates a cross-functional governance mechanism that aligns AI initiatives to business priorities while enforcing Responsible AI practices consistently.

An AI council typically includes senior stakeholders from business leadership, IT, security, legal, compliance, privacy, data, and HR. Its role is to define AI principles and guardrails, approve high-impact use cases, set policy for data usage and access, establish evaluation and monitoring requirements, and coordinate change management and training. This also enables portfolio management—deciding which projects to prioritize, reuse, or stop—so AI investments map to measurable business outcomes.

The other options are weaker: A encourages siloed deployments and inconsistent risk management. B centralizes too narrowly in IT; Responsible AI requires broader accountability than a single function. C can help delivery capacity but does not replace internal governance; vendors still need direction, controls, and oversight from the organization.

Azure AI Search provides an indexing and retrieval layer that makes large, distributed document collections searchable in a consistent way. The key benefit in an information discovery scenario is that it can index content from many sources and then retrieve relevant documents/passages using rich query capabilities, including natural language-style queries and semantic ranking. That directly aligns with B.

This retrieval capability is foundational for RAG architectures: the system uses Azure AI Search to find the best matching content, then supplies those results to a generative model so the answer is grounded in organizational knowledge. That improves relevance and reduces hallucinations because the model is guided by retrieved evidence.

Option A is the opposite of what you want—Search is used precisely to reference existing data. C is more aligned to workflow automation platforms (Logic Apps/Power Automate) and document processing services. D describes fine-tuning, which is a different approach; Azure AI Search improves discovery and grounding through retrieval, not by changing model weights.

Answer Area

A manufacturer can use Azure Vision in Foundry Tools to identify product defects on an assembly line. Answer: Yes

A logistics company can use Azure Vision in Foundry Tools to recognize package shipping labels. Answer: Yes

The HR department at your company can only use Azure Vision in Foundry Tools to extract written content from Microsoft Word files. Answer: No

Azure Vision in Foundry Tools provides computer vision capabilities to analyze images, including identifying visual features and reading text with OCR. Because it is designed to “analyze images” and support vision scenarios, it can be applied to manufacturing quality inspection use cases where the goal is to detect anomalies/defects from images captured on a production line. This aligns with statement 1 being Yes.

Statement 2 is also Yes because recognizing shipping labels is fundamentally text extraction from images (often plus some layout/field parsing). Azure Vision supports optical character recognition (OCR) to read printed text from images, and Microsoft documentation explicitly notes OCR can extract text from images such as product labels and similar real-world text surfaces—making shipping labels a direct fit.

Statement 3 is No because it is incorrectly restrictive. Azure Vision is not limited to extracting written content from Word documents, nor is OCR restricted to Word files. Vision capabilities apply broadly to images (and, depending on the capability, various document/image inputs) for tasks like image analysis and text recognition. HR could use it for many scenarios such as extracting text from scanned images, photos, or other visual inputs—not “only” Word files.

To align an AI customer support agent with Microsoft’s Responsible AI principles, two high-impact actions are fairness/inclusiveness validation and transparency to users. B is correct because testing for inclusive and culturally sensitive responses directly supports fairness and helps reduce harm. In practice, you evaluate responses across diverse user personas, languages/dialects, accessibility scenarios, and sensitive contexts. You look for biased assumptions, stereotyping, exclusionary language, and disparate quality of service. This also implies ongoing monitoring because model behavior can drift as prompts, knowledge sources, and user inputs evolve.

E is correct because a clear disclaimer supports transparency: customers should know they are interacting with an AI system, understand the type of assistance it can provide, and know what to do if the response is incorrect or they need a human. A disclosure is also a practical risk-control that reduces overreliance and sets expectations about limitations.

The other options are not best for Responsible AI alignment: A (retain all conversations) can conflict with privacy/data minimization; retention must be justified and governed, not automatic. C (operate independently) undermines accountability and human oversight. D (multiple purposes) increases scope and risk rather than improving responsible use.

The strongest privacy risk mitigation for analyzing customer feedback is to minimize personal data exposure while preserving the analytical value of the text. A is best because anonymizing (or de-identifying) the dataset removes direct identifiers (names, emails, phone numbers, addresses, account IDs) and reduces the likelihood of privacy breaches, unauthorized re-identification, or inadvertent leakage in model outputs. This aligns with privacy-by-design and the general principle of data minimization: only retain the information necessary for the business purpose.

B is usually impractical and undermines business value and auditability; organizations often need retention windows for validation, traceability, and improvement. C is not the best privacy mitigation: keeping data attributable to individuals increases privacy exposure; while deletion-on-request is important for compliance, it’s not the primary mechanism to reduce privacy risk during analysis. D is explicitly poor practice; privacy reviews should occur throughout the lifecycle (requirements, design, data acquisition, testing, deployment, monitoring), not only at the end. Therefore, anonymizing/removing PII at the source is the best first-line approach.