A common AI fundamentals mistake is starting with a fashionable model instead of the problem. An organization may need a number predicted from historical data, a short message classified, a customer speaking converted into text, or a helpful answer composed from retrieved documents. Those tasks differ in output, evidence requirements and failure risks. Microsoft AI-901 includes choosing appropriate AI workloads and understanding model capabilities and deployment configurations, so the first skill is to translate a business question into a testable AI operation.<\/p>\n
Use a fictional bicycle-repair service as a running example. Customers submit appointment requests, photographs of damage and occasional voice messages. The team wants to estimate repair time, detect urgent requests and provide understandable guidance. Each part should be considered separately rather than handing all information to one general assistant and hoping that every answer will be right.<\/p>\n
A regression model predicts a numeric target, such as an estimated number of labor hours. It learns a relationship between inputs and a continuous value. A classification model selects among defined labels, such as routine, urgent or needs-human-review. A clustering task groups similar examples without preassigned classes; it may help analysts explore patterns but does not automatically provide valid business labels.<\/p>\n
Information extraction identifies values already present in source material, such as a product identifier, a date or an address. Text analysis can detect sentiment or entities. Generative AI creates new output from a prompt and available context: it may summarize a repair note or phrase a reply. A generative model can perform classification or extraction through prompting, but that does not automatically make it the cheapest, most consistent or most appropriate implementation of a strict deterministic requirement.<\/p>\n
Ask what counts as success. A numeric estimate can be measured against actual labor time. A classification can be checked against reviewed categories. Extracted identifiers should match the source, while a generated explanation needs checks for correctness, grounding, clarity and harmful unsupported advice. Selecting a model without defining the metric produces impressive demonstrations rather than reliable task outcomes.<\/p>\n
An AI model is trained using data and a learning objective. An inference request then uses the resulting model and a configuration to produce an output for new input. In generative applications, tokenized input, model context, inference parameters and output limits all influence the result. A model cannot necessarily access current private company policies unless the application deliberately supplies authorized information through a permitted mechanism.<\/p>\n
Context capacity matters when sending long repair manuals. The total request can include system instructions, user messages, examples, tool descriptions and retrieved evidence; using a large context does not guarantee the model pays equal attention to every detail. Output length limits can truncate an answer. Settings such as temperature can influence variation where supported, but do not confuse low variation with factual truth. An incorrect rule can be repeated consistently.<\/p>\n
A multimodal model can accept more than one modality, but supported combinations differ. Some models accept text and images; others may handle audio or return images. The label \u201cmultimodal\u201d is insufficient to establish that a model can transcribe a call, interpret a diagram and generate a video. Verify the selected model’s documented capabilities and deployment settings before treating an example as implementable.<\/p>\n
Microsoft Foundry offers a catalog and model deployment paths. Finding a candidate in a catalog is not necessarily the same as having a callable deployment in your project. Confirm the model’s licensing terms, supported region, capabilities, quota, required permissions, deployment type and endpoint. The Microsoft Foundry deployment overview<\/a> describes hosted\/serverless and other deployment choices. Some instant-access options are preview, so they should not be presented as a default production guarantee.<\/p>\n For the repair service, a model used in interactive chat should meet acceptable latency and input size. A batch process extracting fields from a backlog might prioritize throughput and cost per document. A generative image model is irrelevant to predicting repair hours. A model with excellent general reasoning may still be inappropriate if it lacks the input modality or permitted geography.<\/p>\n Do not assume that deploying a model supplies business authorization. The application must authenticate the caller where necessary, restrict data access, handle secrets and validate any state-changing operation. Similarly, an available endpoint does not mean every configuration or feature is compatible with the chosen model version.<\/p>\n Consider four repair-service requests. A customer asks \u201cIs the brake cable broken in this photo?\u201d This calls for image understanding or human inspection with explicit uncertainty. Another asks \u201cCan you draw a logo for the shop?\u201d That is image generation, not analysis. A caller leaves a recording: \u201cMy rear wheel rubs after braking.\u201d A speech recognizer or supported multimodal model can produce the spoken words, but the team should not treat the transcript as a perfect measurement. A clerk submits a scanned receipt. Extracting the amount and date is a document-processing task that should preserve the source fields and their units.<\/p>\n These tasks can be combined in a workflow, but label each transformation. A caption produced from an image is an inference, not the original photograph. A transcript generated from noise may omit a key word. An entity extracted from a form must be verified against the right field. If generated text is later used to classify a request, an initial error can be amplified. Explicit stages make the cause easier to locate.<\/p>\n A good answer often requires no<\/em> generated text. If an appointment system has a reliable database of available slots, a deterministic lookup is more accurate than asking a foundation model to imagine availability. Use AI where flexible understanding adds value, and conventional application code where the decision rule is known.<\/p>\n Task success is only one design dimension. For a spoken-request model, compare performance across accents and noisy environments. For visual tasks, test photographs under different lighting and camera quality. For ticket priority, determine whether a false negative could delay a safety-related repair. For customer data, minimize personal information sent to any inference endpoint and inspect what is written into logs.<\/p>\n Model selection should follow the observable task. A support agent asked to extract a serial number needs grounded fields and a validation rule; a service that creates marketing imagery needs a generative image capability; a customer who asks to escalate an unresolved order may need controlled agentic orchestration. Different workloads can share a foundation model without sharing the same acceptance test or permission boundary. Pair each model choice with its failure condition: unsupported media, unauthorized records, fabricated details or a missing approval. A model that extracts a serial number correctly but retrieves another customer’s repair record still fails its authorization test. Independent AI-901 workload-selection practice<\/a> cases should distinguish matching the requested AI capability from implementing it with permission-safe data access. Applying fairness, reliability and safety<\/a> also means measuring whether a faster or more accurate model exposes a new privacy risk or makes a product unusable for some people.<\/p>\n Evaluation should slice performance by meaningful use cases. One average accuracy score can conceal failures on unusual parts or minority languages. Include negative cases where the model must admit that a photo is too blurry or a request lacks enough information. A refusal or clarification is sometimes the correct outcome, not evidence that the model failed to please a user.<\/p>\n For every proposed feature, write five entries: input, desired output, candidate workload, failure consequence and acceptance test. Repair hours: structured measurements \u2192 number \u2192 regression \u2192 scheduling mistakes \u2192 compare predicted and actual hours. Complaint urgency: text \u2192 category \u2192 classification \u2192 missed urgent case \u2192 review a labeled test set. Voice request: recording \u2192 transcript \u2192 speech recognition \u2192 incorrect part name \u2192 evaluate terminology and speaker conditions. General repair explanation: question plus authorized reference \u2192 grounded response \u2192 generative AI \u2192 misleading instructions \u2192 validate sources and escalate uncertainty.<\/p>\n Add deployment constraints to the table: latency, data location, cost budget, language support and human oversight. This makes it clear where one model can serve several tasks and where specialized tools are preferable. It also gives beginners a reason to read documentation beyond the headline of a model card.<\/p>\n Selecting the right model does not configure its deployment, bind an application identity or authorize sensitive data access. Those Foundry deployment, identity and operations<\/a> decisions become important when the repair shop turns a useful demonstration into a controlled service. At the AI-901 level, keep the workload, model capability, deployment and application checks distinct.<\/p>\n One useful comparison is between a regression prediction and a rule-based threshold. If a repair shop simply needs to flag appointments longer than four hours, ordinary application logic can evaluate that condition. If it needs to estimate the likely duration before work begins from several historical signals, a predictive model may add value. The predicted value still needs a range of acceptable error and a way to detect when changes to equipment or staffing make historical data less representative. Do not interpret a highly precise-looking number as a guarantee. This distinction also applies to classification: a business label should be tested against reviewed examples, and unusual cases may require a human rather than the closest available class.<\/p>\nMatch workload input, output and evidence<\/h2>\n
Use responsible AI criteria when selecting a model<\/h2>\n
Build a lightweight decision table before coding<\/h2>\n
Prepare for scenario-based decisions, not just definitions<\/h2>\n