AI Workloads and Responsible AI for Microsoft AI-900 to AI-901 Azure AI Fundamentals: Concepts, Scenarios, and Study Priorities

 

Microsoft retired AI-900 on June 30, 2026, so current Microsoft Certified: Azure AI Fundamentals preparation must target AI-901. The transition matters for this topic because AI workloads and responsible AI still form a major conceptual foundation, but they now sit beside a much stronger implementation emphasis in Microsoft Foundry. Microsoft currently assigns 40-45% of AI-901 to identifying AI concepts and capabilities and 55-60% to implementing AI solutions by using Microsoft Foundry.

The durable skill is therefore not memorizing a list of workloads. It is recognizing the shape of a business problem, selecting an appropriate AI capability, understanding what the system should receive and return, and identifying responsible-AI concerns before implementation decisions become expensive. Those habits transfer across product names and interface changes.

This guide builds that reasoning from first principles. It treats generative AI, agentic AI, text analysis, speech, computer vision, image generation, and information extraction as distinct workload patterns, then connects them to fairness, reliability and safety, privacy and security, inclusiveness, transparency, and accountability.

Start with the workload contract, not the product name

An AI workload is easier to reason about when you describe three things: the input, the transformation, and the required output. Product names come later.

Suppose a company receives 20,000 customer comments and wants to know whether each comment is positive, neutral, or negative. The input is text. The transformation is opinion classification. The output is a sentiment result. That is a text-analysis workload.

Suppose a field technician uploads a photograph of equipment and asks what visible indicator is illuminated. The input is an image plus a question. The transformation is visual interpretation. The output is a description or answer grounded in the visible content. That is a computer-vision or multimodal understanding workload.

Suppose a marketing team enters a description and wants a new illustration. The input is text. The transformation is generative visual synthesis. The output is a new image. That is image generation, not image analysis.

This input-transformation-output pattern should become automatic. It prevents the most common conceptual error in AI fundamentals study: choosing a technology because its name sounds related to the industry rather than because its capability matches the requirement.

Generative AI: create or transform content with controlled expectations

Generative AI produces new content such as text, code, images, or other media based on input and context. A generative system can summarize, rewrite, answer questions, draft content, or create new representations. The important conceptual point is that generated output is probabilistic, not a guaranteed lookup from a database.

That distinction drives responsible use. A fluent answer can be incorrect. A generated summary can omit a material detail. A model can infer something unsupported by the source. Therefore a good design pairs generative capability with appropriate grounding, evaluation, validation, disclosure, or human review depending on the consequence of error.

Consider an internal policy assistant. Employees ask questions and the assistant returns concise answers. The generative workload is obvious, but the responsible-AI analysis should immediately ask: can the system expose restricted policy? How will it handle uncertainty? Should it cite or point to supporting material? How are outdated policy versions prevented from influencing answers? Who owns escalation when the model cannot answer confidently?

Reliability and safety are central because the answer may affect employment or compliance decisions. Privacy and security matter because internal documents may have access restrictions. Transparency matters because users should know they are interacting with AI and should understand limitations. Accountability matters because someone must own the system, its data, and its escalation process.

This is a better way to study responsible AI than memorizing a principle next to a one-line definition.

Agentic AI: when the system does more than respond

Agentic AI adds goal-oriented behavior, tools, or actions beyond a single model response. The defining question is not “does it chat?” A normal chat application can be generative without being an agent. Ask instead whether the system is expected to pursue a task, use tools, maintain task context, or take actions on behalf of the user.

Imagine an IT support assistant that only explains how to reset a password. A direct model interaction may be enough. Now change the requirement: the system should inspect an approved knowledge source, verify whether a user is eligible for a reset, open a ticket if self-service fails, and route the ticket to the correct queue. The tool use and multi-step action pattern makes agentic design more relevant.

Responsible-AI concerns become more operational as autonomy grows. Privacy and security govern what systems and data the agent may access. Reliability and safety govern which actions are safe to automate. Transparency should make it clear when an agent is acting, not merely suggesting. Accountability requires ownership of permissions, logs, exceptions, and outcomes.

A strong design also asks when *not* to use an agent. If a deterministic workflow or simple model call satisfies the requirement, additional agent complexity may increase cost and governance burden without adding value.

Text analysis: classify, identify, and condense language

When a scenario involves language, first classify the outcome. A sentiment workload assigns an opinion signal rather than extracting facts. A key-phrase workload surfaces the terms that carry the subject matter. Named-entity recognition looks for structured categories such as organizations, people, products, or places. Summarization produces a shorter representation of the source while trying to retain the information that matters. These capabilities may operate on the same text, but they answer different questions.

These outputs are not interchangeable. A customer-service manager may want sentiment to prioritize negative experiences, entities to identify product names, key phrases to identify common issues, and summaries to help agents review long cases. One document can therefore support several text-analysis outputs, each serving a different operational need.

Scenario reasoning should begin with the business decision. If the user asks “which products are mentioned?”, sentiment is irrelevant. If the user asks “which comments express dissatisfaction?”, entity detection alone is not enough. If the user asks “give me the three main points from this report,” summarization fits better than simple keyword extraction.

Responsible use depends on consequence. Sentiment analysis used only for broad trend reporting carries different risk from sentiment used to deny a customer escalation. Entity extraction from public product reviews has different privacy implications from extracting names and medical details from support messages.

Do not treat workload classification as a purely technical decision. The same capability can be low risk or high impact depending on how the output is used.

Speech recognition and speech synthesis: two opposite directions

Speech workloads become easier when you track direction. Speech recognition takes audio and produces text or another machine-usable representation. Speech synthesis takes text and produces spoken audio.

A voice assistant often uses both. The user speaks, recognition converts the audio into text, a model or application decides on a response, and synthesis turns that response into audio. If the assistant gives the wrong answer, you should ask which stage failed. Was the user misheard? Did the model reason poorly? Was the correct text synthesized incorrectly?

That layered view is important for reliability. Accents, background noise, microphone quality, domain-specific terms, or multiple speakers can affect recognition. Synthesis can raise accessibility and disclosure considerations, especially if a generated voice could be mistaken for a human or a particular person.

Inclusiveness is especially relevant. A speech system that performs well only for a narrow set of voices is not equally useful to all users. Responsible design requires testing with the actual population and use conditions, not only a clean demonstration recording.

Computer vision: interpret existing visual information

Computer-vision and multimodal understanding workloads analyze visual input. A user may ask the system to identify objects, interpret a chart, describe a scene, read visible text, or answer a question about an uploaded image.

The key boundary is evidence. A model may be capable of inferring plausible context, but the application should distinguish what is visibly supported from what is guessed. In a maintenance scenario, saying “a red indicator is illuminated” may be supported by the image. Saying “the compressor has failed” may require evidence the image does not provide.

Reliability and safety become critical when visual output influences physical action. A casual photo-description app can tolerate a different error rate from a system used in industrial inspection. Privacy and security also matter because images can contain faces, badges, screens, addresses, documents, or other sensitive information.

A good practice scenario is to ask one question that is directly answerable from an image and one that invites speculation. Compare the responses and decide what instruction or validation would reduce unsupported inference.

Image generation: create a visual, do not confuse it with analysis

Image generation reverses the direction of a visual-understanding workload. The input is usually a text prompt or other conditioning information; the output is a newly generated image.

A business may use image generation for concept art, draft marketing visuals, product ideation, storyboarding, or synthetic examples. The technical capability is easy to recognize, but responsible use requires more than checking whether the image looks attractive.

Evaluate whether the output follows the requested content, whether it creates misleading details, whether it introduces inappropriate or unsafe material, and whether the workflow respects applicable rights and policies. Transparency may matter if viewers could reasonably assume a generated image documents a real event.

Study image generation with explicit criteria. Ask for a composition with defined objects, positions, or characteristics. Then evaluate each requirement. This trains you to think like an implementer rather than like a casual user.

Information extraction: turn unstructured content into structured data

Information extraction deserves special attention in current AI-901 preparation. Microsoft’s current skills include extracting information from documents and forms, images, audio, and video by using Content Understanding in Foundry Tools, as well as building a lightweight application that uses information-extraction capabilities.

The defining output is structured information. If an invoice is processed, the result might contain invoice number, supplier, date, currency, tax, and total. If a support call is processed, the result might contain caller intent, product, issue category, and requested action. If a video is processed, the result might capture defined events or attributes where supported.

That is different from summarization. A summary gives a concise narrative. Structured extraction returns fields that downstream software can validate, store, or route.

Responsible use requires attention to missing and incorrect fields. A fluent paragraph can be read by a person who notices ambiguity; structured data may flow automatically into another system. Therefore reliability, validation, confidence handling, and human review can become more important when extraction feeds a consequential process.

Practice with imperfect inputs. A clean form proves the happy path. A rotated scan, noisy audio clip, missing field, or ambiguous image teaches you where validation matters.

Responsible AI principle 1: fairness

Fairness asks whether an AI system creates systematically different or unjust outcomes across people or groups. It is not limited to one model type. A generative assistant can produce biased recommendations. A speech system can recognize some accents less accurately. A vision model can perform differently across populations. An agent can automate a process that embeds unfair policy.

When analyzing fairness, avoid vague statements such as “make sure the model is fair.” Ask what decision is affected, which users could be treated differently, what data or evaluation would reveal the difference, and what mitigation is realistic.

For a hiring assistant, compare recommendation outcomes across relevant groups and ensure the system does not use protected characteristics or proxies inappropriately. For speech recognition, evaluate error rates across representative speakers. For customer support routing, check whether language patterns cause some users to receive lower-priority treatment.

The exam-level skill is scenario recognition and sound mitigation reasoning, not building a full fairness research program.

Responsible AI principle 2: reliability and safety

Reliability means the system behaves consistently enough for its intended purpose. Safety means failures do not create unacceptable harm. The required standard depends on consequence.

A generative brainstorming tool can tolerate creative variation. A system that gives medication guidance cannot. A visual defect assistant used only to suggest areas for human inspection has a different safety profile from one that automatically shuts down equipment.

Reliability work includes evaluating representative inputs, handling uncertainty, detecting unsupported output, validating structured data, defining fallbacks, and monitoring behavior. Safety can require human approval, restricted actions, escalation, or deliberately limiting the system’s scope.

A useful exam habit is to ask, “What happens when the AI is wrong?” The answer often reveals which safeguards matter.

Responsible AI principle 3: privacy and security

AI solutions may process prompts, documents, images, audio, video, or tool-access data that contain sensitive information. Privacy asks whether data is collected, used, retained, and exposed appropriately. Security asks whether resources, identities, endpoints, and actions are protected from unauthorized use.

In a document-extraction workflow, do not focus only on extraction accuracy. Ask who can upload documents, where the content is processed, who can view results, and whether extracted fields expose confidential information. In an agent, consider what tools the agent can call and what permissions the executing identity possesses.

Prompt content itself can be sensitive. A user may paste customer records, source code, internal strategy, or credentials. Responsible design should not assume that “it is only a prompt” makes the data harmless.

For AI-901 preparation, connect these questions to the resource context of the small applications you build.

Responsible AI principle 4: inclusiveness

Inclusiveness asks whether people with different abilities, languages, environments, and contexts can use the solution effectively. It often overlaps with fairness but is not identical.

A voice-only interface can exclude users who cannot speak or hear comfortably. A visual application without accessible text alternatives may exclude users with visual impairments. A complex generated answer can be unusable for an audience that needs plain language.

Scenario questions may not always use the word “inclusiveness.” Look for barriers to participation. A strong response proposes an alternative input or output mode, accessible design, representative testing, or language support rather than treating accessibility as an afterthought.

Responsible AI principle 5: transparency

Transparency means users and stakeholders can understand that AI is involved, what the system is intended to do, what limitations matter, and how outputs should be interpreted.

Transparency does not require exposing every internal model detail. It can mean labeling generated content, explaining that an answer may require verification, identifying the source of supporting information, or making clear that an agent may take certain actions.

A support assistant that confidently fabricates policy is not made responsible merely by adding “AI-generated” to the footer, but disclosure still matters. Transparency works with reliability and accountability; it does not replace them.

Responsible AI principle 6: accountability

Accountability asks who is responsible for the system, its decisions, its access, its monitoring, and its failures. AI does not remove ownership.

For a simple text classifier, accountability may mean defining who reviews misclassification and approves model changes. For an agent with tools, it includes who approves tool permissions, which actions require human confirmation, what logs are retained, and who handles incidents.

When an exam scenario describes a high-impact or autonomous action, accountability should be near the top of your analysis.

Scenario 1: a multilingual customer-support triage system

A company wants to analyze incoming support messages in multiple languages. It needs to identify sentiment, product names, urgency indicators, and a short summary for human agents.

The workload is primarily text analysis with several outputs. Sentiment identifies opinion, entity detection can identify products, and summarization condenses the case. If the system also generates a recommended response, generative AI enters the design.

Fairness and inclusiveness require checking whether performance is consistent across languages and writing styles. Reliability matters because incorrect urgency could delay important cases. Privacy matters because support messages can contain personal data. Transparency may require telling agents which fields are AI-generated. Accountability belongs with the team that defines routing rules and reviews errors.

A good candidate separates each AI output from the downstream business rule. “Route strongly negative messages to senior support” is application logic. The AI output does not itself define the organization’s escalation policy.

Scenario 2: a field-service visual assistant

A technician photographs a machine panel and asks a question by voice. The application recognizes the spoken question, interprets the image, produces a response, and optionally speaks the response aloud.

This is a composed workflow: speech recognition, multimodal visual understanding, generative response, and speech synthesis. The scenario tests whether you can reason about stages rather than call everything “multimodal AI.”

Reliability and safety are critical if the answer could influence maintenance action. The design should restrict unsupported inference and may require human confirmation for risky steps. Privacy and security matter if images reveal facility information. Inclusiveness includes alternative text input/output for users who cannot use voice comfortably.

If the requirement later adds “open a maintenance ticket automatically,” agentic behavior and tool governance become relevant.

Scenario 3: automated claims intake

An insurer receives forms, damage photographs, voice notes, and short videos. The goal is to extract claimant identity, policy number, incident date, location, described damage, and other structured fields for human review.

The dominant workload is information extraction across modalities. A weak answer says “use generative AI because the content is unstructured.” A stronger answer identifies that the downstream process needs fields, not just fluent text.

Reliability matters because wrong fields can affect a claim. Privacy and security are central because the data is sensitive. Transparency should distinguish extracted information from verified facts. Accountability requires an owner for validation and exception handling. Fairness becomes material if extracted or inferred information influences claim treatment across groups.

The safest design avoids inferring facts that are not supported by the source media and flags missing information for review.

Scenario 4: an HR policy assistant with action capability

An HR assistant initially answers questions from approved policy material. Later, the organization wants it to open leave requests and route exceptions to HR.

The first version is mainly a grounded generative application. The second introduces agentic action. That change should trigger a new security and accountability review. The agent now needs permissions, action boundaries, logs, and confirmation rules.

A responsible design might allow the assistant to prepare a leave request but require user confirmation before submission. It might prohibit the agent from approving its own exception. It should clearly distinguish policy explanation from official HR decisions.

This scenario illustrates an important study principle: responsible-AI analysis changes when system capability changes.

Scenario 5: product concept-image generation

A design team wants to generate early concept images from text descriptions. Image generation is appropriate because the desired output is a new visual.

Reliability is evaluated against design requirements rather than factual truth alone: does the image include the requested components and avoid prohibited details? Transparency may matter when generated images are shared outside the design team. Privacy may matter if prompts contain unreleased product information. Accountability includes review before a concept is treated as an approved design.

If the team instead uploads an existing prototype photograph and asks the system to identify visible defects, the workload has changed to visual understanding. The industry is the same; the input-output contract changed.

Build a workload decision table

Create a study table with five columns: business requirement, input, required output, workload, and primary responsible-AI concern. Fill it with at least twenty scenarios from different industries.

Do not use product names in the business requirement column. Force yourself to identify the workload first. Then add the Microsoft Foundry-oriented implementation you would practice.

For example:

• “Convert a customer phone message into text” -> audio input, text output, speech recognition, with inclusiveness and reliability concerns.
• “Create a product illustration from a description” -> text input, image output, image generation, with transparency and review concerns.
• “Return invoice date and total as fields” -> document/image input, structured output, information extraction, with reliability and privacy concerns.
• “Complete a multi-step support task using approved tools” -> task input, action-oriented output, agentic AI, with security and accountability concerns.

This table becomes far more valuable than a glossary because it trains selection.

Connect conceptual study to Foundry implementation

Because AI-901 emphasizes implementation, every workload should have at least one lightweight practical counterpart. Deploy and interact with a model. Build a small chat client. Create a simple agent. Exercise text and speech. Use a multimodal model with an image. Generate an image. Extract structured information from a document or other supported media.

The conceptual question for each exercise is the same: why is this the correct workload, and what responsible-AI concern would change how you deploy it?

If you complete a lab without being able to answer those questions, the implementation has become mechanical.

Use legacy AI-900 practice carefully

Older AI-900 questions can still be useful for transferable concepts such as workload recognition and responsible AI. Use Azure AI Fundamentals practice questions only as a legacy diagnostic, not as proof of complete AI-901 readiness.

When a question tests a concept that remains current, explain the answer and then add an implementation follow-up. If the question asks about sentiment, ask how you would build a small text-analysis exercise today. If it asks about responsible AI, apply the principle to a Foundry-based solution you have actually built.

The purpose is to connect old conceptual practice to the current skills, not to pretend the retired exam and current exam are identical.

Study priorities for this topic

First, make workload classification automatic. You should be able to distinguish generative AI, agentic AI, text analysis, speech recognition, speech synthesis, visual understanding, image generation, and information extraction from short business requirements.

Second, learn responsible AI through scenarios. For each workload, identify the principle most likely to be material and propose a concrete mitigation.

Third, practice capability boundaries. Know when a direct model call is simpler than an agent, when extraction is better than summarization, when visual understanding differs from image generation, and when recognition differs from synthesis.

Fourth, build small implementations. The current exam expects more than vocabulary. Hands-on work should reinforce the same conceptual decisions.

Fifth, integrate. Create mixed scenarios that require two or more workload stages and analyze which responsible-AI concern appears at each stage.

The AI-901 readiness matrix is useful when you want to score these areas independently rather than assume strong theory means strong implementation.

A final mental model

Think of every AI solution as a chain of decisions. What is the business requirement? What input exists? What output is required? Which workload transforms one into the other? Which model or capability class fits? How will it be implemented in the current Microsoft environment? What could go wrong? Which responsible-AI principles are material? What validation or human oversight is appropriate? Who owns the outcome?

That chain is more durable than memorizing a catalog. It works for a one-step sentiment classifier, a multimodal assistant, an information-extraction pipeline, or an agent with tools.

AI-900-era foundations are still useful when they help you answer those questions, but AI-901 raises the practical standard. The strongest preparation therefore combines clear workload boundaries with responsible implementation judgment. If you can identify the right capability, explain why it fits, recognize its limitations, and connect it to fairness, reliability, privacy, inclusiveness, transparency, and accountability in a realistic scenario, you are studying the topic at the depth the current exam expects.

Add adversarial variations to every scenario

A scenario becomes much more educational when you deliberately change one assumption. If the original support assistant answers from public FAQs, make the content confidential. Privacy and security suddenly become more important. If the original visual assistant gives low-stakes product descriptions, change the setting to safety inspection. Reliability and human confirmation become more important. If an information-extraction workflow is reviewed by a person before use, change it so extracted fields automatically trigger payments. Validation and accountability become stricter.

This exercise teaches that responsible AI is contextual rather than decorative. The workload may remain the same while the risk profile changes because the consequence of error changes. It also prevents a common exam habit: matching one principle permanently to one workload. Privacy is not “the document principle,” and fairness is not “the hiring principle.” Each principle can become relevant across many systems depending on data, users, decisions, and actions.

For implementation study, adversarial variations also help you decide what controls belong outside the model. A prompt may ask the model to avoid unsupported conclusions, but an application handling financial or safety-critical actions may still require deterministic validation or human approval. A well-designed system combines model behavior with application controls rather than expecting the model to govern itself.

Practice explaining trade-offs, not just correct labels

Real scenarios rarely have one isolated concern. A company may want the most capable model, the lowest latency, the lowest cost, strong privacy, and perfect reliability at the same time. Preparation should therefore include trade-off explanations.

Suppose a team wants a multimodal assistant for field workers in areas with unreliable connectivity. Capability matters, but so do latency, availability, data handling, and what happens when the system cannot respond. Suppose a customer-support agent can draft replies faster with generative AI, but the organization requires consistent legal wording. The system may need templates or deterministic checks around generated content.

At AI-901 depth, you are not expected to design every enterprise control. You are expected to recognize that capability selection occurs inside constraints. Practice saying, “This workload fits because of X, but I would validate Y and restrict Z because of the scenario.” That sentence structure demonstrates more mature reasoning than naming a service alone.

Review through composition, not only isolation

Before final review, combine several workloads into one architecture sketch. A user speaks a question, includes a photo, receives an answer, and can ask the application to open a service request. Label speech recognition, multimodal understanding, generative response, speech synthesis, and agentic action separately. Then write the responsible-AI concern that is most important at each boundary.

The exercise exposes whether your knowledge survives composition. Many real AI solutions are pipelines, and a problem in one stage can be misdiagnosed as a problem in another. If speech recognition mishears an identifier, the model may generate a perfectly reasonable answer to the wrong text. If the image is ambiguous, a confident generative response may still be unsafe. If an agent has excessive tool permissions, a correct model response can still create security risk.

Being able to decompose a system is one of the most useful conceptual skills you can carry from fundamentals study into practical AI work.