AI-901 Define AI Concepts and Responsibilities

Define AI Concepts and Responsibilities Detailed Explanation

AI-901 scenario questions usually test the first correct match between requirement, Microsoft Foundry capability, model or service boundary, and observable validation evidence. Read the stem for input modality, required output, operational dependency, and the first proof point before choosing a tool, parameter, or code action.

Common distractors tune a later step before capability is proven, choose an adjacent AI workload, replace structured extraction with generic chat, or fix a symptom without satisfying responsible AI evidence. The correct answer is the option that resolves the actual scenario constraint and produces evidence the learner could verify in the Foundry portal, SDK response, tool output, or governance review.

Apply Responsible AI Requirements to an Azure AI Scenario

Exam Radar

• Microscopic Technical Focus: Fairness, reliability, privacy, inclusiveness, transparency, and accountability evidence in solution review
• Core Priority: Responsible AI is the policy lens behind design-choice questions: a technically working solution can still be wrong when it hides limitations, collects unnecessary data, excludes users, or lacks ownership for review.
• Confusion Alert: The common trap is to choose model accuracy or a larger deployment as the fix when the scenario asks for fairness, privacy, safety, transparency, or accountability controls.
• Scenario Logic: Look for who is affected, what decision or recommendation the AI output influences, and whether the missing control is fairness measurement, privacy minimization, disclosure, reliability review, or accountable ownership.
• Failure Trigger: The solution may be technically callable but still unsafe when users overtrust output, sensitive data is retained unnecessarily, or no review owner exists for harmful behavior.
• Operational Dependency: The blocking dependency is governance evidence attached to the actual user workflow, not a larger model, broader networking change, or more fluent prompt.
• Topic-Specific Exam Cue: Words such as fairness, transparency, privacy, responsible use, review, disclosure, sensitive data, or accountability usually mean the answer must name a responsible AI control.

Practice question: A team builds a Foundry-based support assistant for employees. The assistant gives confident policy answers, but users are not told that responses may be incomplete and no team owns review of harmful outputs. What should be addressed first?

A. Increase the model deployment capacity
B. Add more examples to improve tone
C. Add transparency wording and define an accountable review path
D. Move the assistant to a private virtual network

Correct Answer: C

Explanation: C is correct because the scenario contains transparency and accountability gaps. A may help throughput but not user overtrust. B may improve wording but not ownership. D may improve network isolation but does not address disclosure or review responsibility.

Atomic Deconstruction - Operational Level

Responsible AI questions begin with the affected user and the decision path. The operational object is the control evidence: what data is collected, what limitation is disclosed, who owns review, and which harm is being reduced. Without that evidence, a technically functional model can still be the wrong exam answer because it leaves the risk unmanaged.

The drill is to translate principles into inspection points. Fairness is checked against impacted groups, privacy against prompt and log fields, transparency against user-visible wording, reliability against fallback and validation behavior, and accountability against an owner. The correct option is the one that attaches the principle to a verifiable control.

For exam transformation, treat every option as a proposed dependency. The correct option is the one that unlocks the blocked workflow and can be verified. Wrong options are often useful in another situation, but they fail here because they tune a later step, address a different modality, or repair a symptom without satisfying the scenario requirement.

Component Specifications

For this table, read each row as a simple exam check: before improving the model, verify which responsible AI control is missing and what evidence would prove it exists.

Object	Attribute	Value Range	Default State	Dependency	Failure State
Impact assessment	Risk category	Fairness, safety, privacy, transparency	Not documented	Use case and affected user group	Review cannot prove which harm is being mitigated
Grounding disclosure	User-facing limitation statement	Visible, specific, scenario-bound	Absent unless designed	Application interface and model behavior	Users overtrust generated output or miss human review requirement
Data collection boundary	Input retention and minimization rule	Required fields only	Depends on app design	Privacy/security review	Unnecessary personal data enters prompts or logs
Accountability owner	Escalation path	Named role or support queue	Undefined	Operational process	Unsafe output has no remediation owner

Step-by-Step Execution Path

1. Map the user population, decision impact, and sensitive attributes before selecting technical controls. This establishes whether the first dependency is fairness measurement, privacy minimization, or safety review.
2. Inspect prompt, data, and output surfaces for hidden personal data, exclusion risk, unsupported language, and missing confidence or limitation wording.
3. Document the mitigation that directly matches the risk: privacy requires collection limits, transparency requires disclosure, reliability requires validation and fallback, and accountability requires an owner.
4. Verify the review outcome in the project or governance artifact before treating the solution as exam-ready evidence.

Suggested Lab Validation Ideas:

The following paths and commands are conceptual lab-style examples for practice. Adapt them to the current Microsoft documentation, SDK/API version, subscription permissions, and project environment before using them in a real implementation.

• Portal path: Microsoft Foundry project > Safety or evaluations view - portal evidence check for safety or quality review status.
• Local lab script: python review_ai_risk_register.py --scenario support-chat - local rehearsal for mapping scenario risk to responsible AI principle.

Technical Chain

A scenario starts with an affected user and an AI output path. The selected responsible AI control must attach to that path: privacy limits prompt data before the request is sent, reliability checks validate output before action, transparency changes what the user sees, and accountability defines who responds when the workflow fails. A model-only answer breaks the chain because it changes generation capacity without satisfying the governance dependency.

Operational Skills Matrix

Task	Precise Command or Path	Verification Standard
Validate privacy minimization	Review prompt fields and application telemetry schema	Only fields required for the task are sent to the model or stored in logs
Validate transparency evidence	Inspect UI copy, response metadata, and user disclosure text	The user can see limitations, human review cues, or generated-content notices where required
Validate accountability path	Review project risk register or support workflow	Each high-impact failure mode has a named review owner and escalation path

Select AI Model Capabilities and Deployment Parameters

Exam Radar

• Microscopic Technical Focus: Capability matching, model deployment choice, context limits, temperature behavior, and endpoint consumption readiness
• Core Priority: AI-901 expects candidates to match workload needs to model capabilities and deployment settings rather than treating every task as a generic chat call.
• Confusion Alert: Distractors often pick a famous model name, a high temperature, or a larger context window without proving that the capability matches text, vision, speech, agent, or extraction requirements.
• Scenario Logic: Start by identifying whether the app needs text reasoning, image input, embeddings, speech, image generation, or structured extraction; only then evaluate deployment and parameter choices.
• Failure Trigger: A request fails or returns unusable output when the selected deployment cannot consume the input modality or when the client targets the wrong deployment name or endpoint.
• Operational Dependency: The first dependency is a deployed model with the required capability and a client configuration that can successfully invoke it.
• Topic-Specific Exam Cue: Mentions of uploaded images, context size, temperature, deployment name, endpoint, or unsupported input usually point to model capability and deployment-parameter reasoning.

Practice question: A developer needs an app to answer questions about an uploaded product image and a text prompt. Which selection criterion matters first?

A. Choose the deployment with the lowest temperature
B. Choose a deployed multimodal model that accepts image and text input
C. Choose an embedding model because it can compare vectors
D. Choose any chat model and add a longer system prompt

Correct Answer: B

Explanation: B is correct because the input includes visual content. A tunes randomness after capability is satisfied. C supports similarity search, not image interpretation by itself. D fails when the chat model cannot process images.

Atomic Deconstruction - Operational Level

Model-selection questions start with capability fit. A deployment is not just a model name; it is the callable endpoint, supported input types, parameter surface, quota context, and authentication path that the app must use.

The drill is to reject parameter tuning until capability is proven. Temperature, token budget, and prompt wording matter only after the model can accept the required modality and the client can route to the right deployment.

For exam transformation, treat every option as a proposed dependency. The correct option is the one that unlocks the blocked workflow and can be verified. Wrong options are often useful in another situation, but they fail here because they tune a later step, address a different modality, or repair a symptom without satisfying the scenario requirement.

Component Specifications

In fundamentals terms, this table says: check whether the model can produce the required output before choosing temperature, context settings, or code structure.

Object	Attribute	Value Range	Default State	Dependency	Failure State
Model deployment	Capability family	Chat, multimodal, embedding, image generation, speech	None until deployed	Foundry model catalog and quota	Client cannot call the required capability
Context window	Token budget	Model-specific limit	Model dependent	Prompt and retrieved content length	Requests truncate or fail before required evidence is included
Temperature	Sampling variability	0.0 to model-supported maximum	Often 1.0 or service default	Task determinism requirement	Answers become inconsistent for classification or extraction tasks
Endpoint credential	Authentication material	Key or identity-supported token	Unavailable until configured	Client application	401/403 response or missing deployment target

Step-by-Step Execution Path

1. Classify the task by input and output: text reasoning, image interpretation, speech interaction, visual generation, or structured extraction. This prevents choosing a model that cannot consume the input.
2. Deploy or select a model with the required capability in Microsoft Foundry, then record deployment name, endpoint, and supported parameters.
3. Set deterministic parameters for classification or extraction and more creative parameters only when the scenario asks for varied generation.
4. Run a minimal SDK or REST invocation to prove the endpoint, deployment name, and authentication path are all aligned.

Suggested Lab Validation Ideas:

The following paths and commands are conceptual lab-style examples for practice. Adapt them to the current Microsoft documentation, SDK/API version, subscription permissions, and project environment before using them in a real implementation.

• Portal path: Microsoft Foundry > Models + endpoints > Deployment details - portal verification of deployment name, model capability, and endpoint.
• Python SDK rehearsal: client.responses.create(model=deployment_name, input='Classify this request') - local code-pattern validation; adapt to the current Foundry SDK version.

Technical Chain

The client request names a deployment, sends input shaped for a model family, and includes parameters that influence generation. The service resolves the deployment to a hosted model and rejects or degrades the request when capability, authentication, or parameter assumptions do not match. The exam answer must preserve that dependency chain: capability first, deployment identity second, parameter tuning third.

Operational Skills Matrix

Task	Precise Command or Path	Verification Standard
Validate model capability	Microsoft Foundry portal > deployment details	The deployed model supports the required text, image, speech, agent, or generation input
Validate endpoint readiness	Run a minimal SDK or REST test call against the deployment	The response returns expected content without 401, 403, 404, or unsupported-parameter errors
Validate parameter fit	Inspect request payload for temperature, max output, and input type	Parameter choices match deterministic or creative task requirements

Identify Azure AI Workload Patterns

Exam Radar

• Microscopic Technical Focus: Scenario-to-workload mapping for generative AI, agents, text analytics, speech, vision, image generation, and information extraction
• Core Priority: The fundamentals exam asks candidates to recognize which Azure AI workload fits the user goal before choosing a tool or writing code.
• Confusion Alert: Wrong options usually choose an adjacent workload: speech synthesis for speech recognition, image generation for computer vision analysis, or chat completion for structured document extraction.
• Scenario Logic: Match the source input and required result: transcript, spoken response, generated image, visual interpretation, text insight, generated answer, or structured field extraction.
• Failure Trigger: The app uses an AI service that works on related data but produces the wrong output shape, such as a summary where fields are required or synthesized speech where transcription is needed.
• Operational Dependency: The blocking dependency is the correct workload pattern, because later configuration cannot repair a service chosen for the wrong transformation.
• Topic-Specific Exam Cue: Verbs such as transcribe, synthesize, detect, generate, summarize, classify, or extract usually reveal the workload family.

Practice question: A claims-processing app must read uploaded repair invoices and return vendor name, invoice date, line items, and totals. Which workload pattern is the best match?

A. Information extraction with Content Understanding
B. Text-to-speech using Azure Speech
C. Image generation using a generative model
D. Sentiment analysis of customer comments

Correct Answer: A

Explanation: A is correct because the required output is structured fields from documents. B creates audio from text. C creates new images. D classifies tone and does not extract invoice fields.

Atomic Deconstruction - Operational Level

Workload-recognition questions are output-contract questions. The learner should name the data entering the workflow and the exact result the application needs before looking at services.

The drill is to compare adjacent workloads by transformation direction. Speech-to-text, text-to-speech, image interpretation, image generation, text analysis, and information extraction each produce different evidence, so an answer that works on the same input can still be wrong when it returns the wrong output.

For exam transformation, treat every option as a proposed dependency. The correct option is the one that unlocks the blocked workflow and can be verified. Wrong options are often useful in another situation, but they fail here because they tune a later step, address a different modality, or repair a symptom without satisfying the scenario requirement.

Component Specifications

Use this table as a workload decision aid: first ask what the app must return, then choose the service family that naturally returns that result.

Object	Attribute	Value Range	Default State	Dependency	Failure State
Text analytics workload	Primary output	Entities, sentiment, key phrases, summaries	No output until input text is processed	Language model or text analysis API	App receives prose when it needed labels or extracted values
Speech workload	Direction	Speech-to-text or text-to-speech	Not selected	Audio input/output format	The app transcribes when it needed spoken response, or the reverse
Vision workload	Input interpretation	Image or video understanding	Not selected	Visual input and model capability	Image is generated or ignored instead of analyzed
Information extraction workload	Structure target	Fields, tables, entities from documents/media	Schema absent	Content Understanding configuration	Output cannot be mapped into business fields

Step-by-Step Execution Path

1. Identify the source input type: plain text, spoken audio, image, video, document, or form. Input type narrows the service family.
2. Identify the required output: generated answer, action plan, transcript, synthetic speech, visual description, generated image, or structured fields.
3. Match the workload to the output evidence, then reject adjacent services that operate on the same input but produce the wrong result.
4. Validate the choice by describing one observable result the app must produce, such as extracted invoice fields or a spoken answer.

Suggested Lab Validation Ideas:

The following paths and commands are conceptual lab-style examples for practice. Adapt them to the current Microsoft documentation, SDK/API version, subscription permissions, and project environment before using them in a real implementation.

• Local lab script: python classify_workload.py --input invoice.pdf --goal extract-fields - local rehearsal for scenario mapping.
• Portal path: Microsoft Foundry > Tools - portal verification of available Foundry Tools for speech, vision, or Content Understanding workflows.

Technical Chain

A workload decision begins with data modality and ends with an observable output contract. If a question asks for key phrases, the chain goes through text analysis; if it asks for a spoken answer, it requires speech synthesis or a multimodal path; if it asks for fields from documents, it requires extraction. Adjacent services fail because they transform the data into a different output shape.

Operational Skills Matrix

Task	Precise Command or Path	Verification Standard
Validate input modality	Review scenario input and sample payload	Input is categorized as text, audio, image, video, document, or mixed media
Validate output contract	Review required application result	The selected workload produces labels, transcript, speech, generated content, visual interpretation, or extracted fields as required
Validate distractor rejection	Compare adjacent workload outputs	Rejected options operate on wrong modality or return wrong output shape