Microsoft AI-901: Responsible AI and Model Selection
Start with a decision the model is supposed to support
An AI fundamentals learner needs more than a list of services. A school scheduling assistant, an invoice classifier and a generative writing tool have different desired outputs, data inputs and consequences. Before picking a model, describe the task in one sentence, identify the authorized user and define which part of the result will be accepted, revised or refused. If the output must be a precise quantity, an expressive language model is not automatically the best tool.
The current Microsoft AI-901 guide divides skills into identifying concepts and capabilities (40–45%) and implementing Foundry solutions (55–60%). This guide addresses the conceptual decision preceding implementation: how to select appropriate model capabilities and settings while considering all six responsible AI principles. An implementation test appears in separate Foundry exercises, so this explanation does not claim a live model or tenant was deployed.
Write down success criteria before running a test. For a support reply, correctness, helpfulness and privacy may all matter. For an extraction task, field-by-field matching and provenance may be more important than a natural-sounding answer. For an image generator, prompt adherence, image safety and content rights should be considered. Different outputs require different test data, model capabilities and acceptance thresholds.
Know what a generative model can and cannot infer
Generative models learn patterns that help them predict or construct new text, images and other outputs from a request and context. They can summarize, draft, classify loosely or propose a response, but the resulting language is not proof of access to the current business database. When the exact latest price, policy or case status matters, the system needs a governed data source and a way to verify what was retrieved. Otherwise a persuasive answer can still be wrong.
Contrast prediction and generation. A classifier returns a category or score against a defined set of labels; a regression model estimates a quantity; a generative model creates an output whose interpretation may depend on prompting and context. Those families can be combined, but the combination increases validation work. Predictive versus generative AI is a useful conceptual reference for this choice.
A foundation model may support text, vision, audio or several modalities. Do not assume that all model deployments accept the same input size, generate images, provide tools or operate in the same region. Capability, throughput, rate limits, authentication and availability are concrete deployment considerations. Choose a supported task first, then investigate the eligible model subset and its actual parameters rather than relying on a product family name.
Apply fairness to the population actually served
Fairness begins with who receives a useful result and who might receive worse outcomes. For a fictional job-search assistant, compare performance for different writing styles, language backgrounds, assistive-input methods and job families where appropriate and lawful. An impressive average can hide a subgroup failure. Define the measurement before looking at results; otherwise a team can choose whichever metric gives the model the most flattering score.
Ask whether the reference dataset reflects the people who will use the product. If a speech recognizer was evaluated only with quiet, clear audio from one accent, deployment to a noisy call center is an untested expansion. If a document classifier has few minority-language records, its confidence may be misleading there. Improve data coverage, collect representative feedback and route uncertain cases to a person rather than claiming the same performance everywhere.
Fairness does not mean mechanically removing every difference from a model response. It means examining whether differences are justified by the legitimate task and whether the harm falls disproportionately on someone. A responsible evaluation report includes sampling limitations, uncertainty and a proposed mitigation. If protected personal characteristics are involved, data collection and use must also follow applicable privacy requirements.
Engineer reliability and safety around failure
Reliability asks whether the system behaves consistently enough for its intended use; safety asks what happens when it does not. A study helper that omits a reference may create confusion. A medical or financial assistant that invents instructions may cause significant harm. For an entry-level demonstration, select low-stakes content and show what the app does when the input is missing, malformed or outside its scope. A useful refusal is often better than fabricated certainty.
Test a representative series of cases rather than repeating a single prompt until it works. Include normal questions, ambiguous language, contradictory evidence and a case with no legitimate answer. Record the expected result separately from the model’s actual response. Any tool with external side effects needs authorization checks independent of the generated text. A user cannot gain access to another record simply by persuading the model with a long instruction.
Safety boundaries include content filtering, human escalation, input limits and the ability to shut down an unsafe workflow. They also include a correction plan after release. If the model quality drops when a deployment or prompt changes, revert the affected version and investigate before expansion. A polished demo that cannot recover from a rejected request is not a reliable application.
Minimize private information and secure access
Privacy begins before prompting. The best method to protect sensitive data is often not to send it at all. Replace real identifiers with synthetic examples, restrict retrieval to the user’s authorized records and avoid placing secrets in source code or prompt text. When an application uses Foundry resources, identity roles and endpoint configuration should be explicit. A deployment that answers correctly under an administrator account may still fail the user’s least-privilege requirement.
Security is not only a harmful-content classification. It includes authentication, key handling, audit evidence, permission scope, secure network paths, data retention and protection against untrusted instructions in retrieved material. A document that says ‘ignore previous rules’ is source content, not a legitimate operator request. The model may quote or summarize it, but it should not turn that text into new tool privileges.
Document which logs may contain prompts or responses and who is authorized to read them. A debugging practice that copies customer records into shared test files can violate the privacy goal even if the model response is harmless. Use synthetic examples for initial AI-901 exercises and consult Microsoft’s current Foundry and Azure governance documentation before a real production deployment.
Design for inclusion beyond an ideal browser user
Inclusiveness concerns the different ways people interact with a solution. A visually oriented agent that works well with high-resolution screenshots can fail for someone using screen readers, small screens or low-bandwidth connectivity. A speech-only interface may fail for a user in a noisy environment or someone who cannot speak clearly. Decide which accommodations and fallback channels are necessary for the actual user group.
An inclusive application should keep error messages intelligible, avoid using color alone to encode meaning, and provide an alternative to audio or visual-only evidence when feasible. A transcript may support review of a speech session, while keyboard navigation can make a chat client accessible to more users. These choices are product-level implementation decisions, not capabilities that can be guaranteed by selecting a newer generative model.
Test with realistic device, language and accessibility conditions. A benchmark may show excellent recognition accuracy while the surrounding application lacks a way to correct a transcript. A model may generate a clear caption but an inaccessible interface may prevent anyone from editing it. The complete user journey, not the isolated inference endpoint, determines whether the solution is inclusive.
Make transparency useful, not decorative
Transparency is about giving a user enough information to interpret a result appropriately. For a model-generated answer, tell the user when content may be uncertain, which data sources were consulted where applicable, and what the tool has actually done. A summary is not a verified transaction receipt. A search result and a model’s reasoning about that result are different types of evidence.
An explanation should match the user’s decision. A service representative needs the policy paragraph and timestamp, not a generic statement about machine learning. A student needs to know that an answer is a study aid and may require comparison with the official guide. An administrator needs an audit trail showing what was configured and which role authorized a change. Different levels of explanation serve different accountability needs.
Avoid promising access to hidden model reasoning or perfectly interpretable weights. A meaningful transparency mechanism can instead show the visible input, documented model/deployment version, cited knowledge source and tested output. These observable facts help users correct errors. They also make it harder to mistake fluent language for independent verification.
Assign accountability for decisions and incidents
Accountability exists when named people can approve the intended use, interpret failures and decide whether to suspend the system. Record the business owner, technical owner, data steward and incident escalation path before expanding an AI pilot. An application cannot accept responsibility for a harmful decision merely by displaying a model-generated disclaimer. Someone must own thresholds, access privileges, content changes and the user’s remedy.
In a small AI-901 prototype, the student can demonstrate this principle by adding a decision log: what the application is permitted to answer, what it refuses, which model deployment was selected and how a poor response would be reported. The purpose is not a bureaucracy checklist; it is to make a future bad result traceable to a component that can be corrected.
The responsible AI principles discussion deepens the connection between incomplete evidence and responsible human approval. Ownership should become more rigorous as consequences rise, but even an educational app benefits from a clear boundary between illustration and fact verified in a live environment.
Turn principles into an AI-901 model-selection exercise
Choose three fictional tasks: label an email’s topic, draft a customer reply and interpret a receipt photograph. For each, write a success criterion, the input modality, the required permissions, a plausible model capability and a failure or refusal case. Add one fairness, safety, privacy, inclusion, transparency and accountability question to the evaluation plan. The same model may not be the best choice for all three; explain the tradeoff rather than treating every question as a model popularity contest.
Before deploying in Microsoft Foundry, compare available models and configurations with the actual resource, deployment region and supported SDK. A strong first experiment uses synthetic data, the least privileged test identity and a small suite of expected outputs. If the model cannot support the chosen modality or safe response contract, change the task or select a different eligible deployment. Do not invent an execution log for an experiment that has not run.
This article is a learning and architecture framework, not a report of a real Foundry test. Microsoft AI-901 includes practical model and agent interactions, covered in the separate Foundry model-and-client walkthrough. Use the two pieces together: a model’s answer matters only when its intended use and evaluation are clear.
