Practical AI Use Cases and the AWS AI Service Catalog (AIF-C01)

AI and ML earn their keep in three broad situations that the exam names directly. The first is assisting human decision making: rather than replacing an expert, the model surfaces a prediction or ranking that a person then acts on, such as flagging the transactions most likely to be fraudulent so an analyst reviews those first. The second is scalability: a model can evaluate millions of items consistently and instantly in a way no human team could match, for example screening every product review or every login attempt as it happens. The third is automation: tasks that are repetitive and pattern-based, like sorting support tickets by topic or transcribing thousands of calls, can run without a person in the loop.

Underlying all three is a common signal: the problem involves recognizing patterns or predicting outcomes from data that is too large, too fast, or too nuanced for hand-written rules. If a task requires judgment based on many subtle examples, changes over time, or must operate at a volume beyond human capacity, it is a strong AI/ML candidate. On the exam, phrases like "analyze at scale," "detect patterns humans would miss," "personalize for each user," or "reduce manual effort" all point toward an AI/ML solution being appropriate.

Knowing when to say no is one of the most frequently tested points in this task. The headline rule: AI/ML produces probabilistic predictions, not guaranteed answers, so it is the wrong choice when a problem demands a specific, exact, deterministic outcome every time. If a task can be solved with a clear, fixed rule and must be exactly right, use conventional programming, not machine learning. Calculating sales tax, applying a documented refund policy, or summing a column of numbers all have one correct answer defined by a rule; wrapping them in an ML model would only add uncertainty. A model that is right ninety-nine percent of the time is unacceptable when the requirement is one hundred percent correctness.

The second reason to decline is a poor cost-benefit balance. Machine learning needs quality data, skilled effort, and ongoing operation (monitoring, retraining, and paying for inference), so if the problem is small, rarely occurs, or a simple rule already works well, the expense of building and maintaining a model is not justified. A related blocker is lack of sufficient, relevant data: a process that has produced only a handful of positive examples (for example, a defect type that has appeared only a few times across a decade of production records) gives a model almost nothing to learn from.

When ML is not justified, the cheaper alternative should support the existing control, not remove it. When an existing manual check is already working, the better move is usually to make that check easier, for example with simple rules or reports that surface the items most worth a closer look, rather than to remove the people doing it. Replacing a reliable human control with an unproven automated one trades a working safeguard for a brittle one.

Not every objection is a valid one. Some sound like reasons to avoid ML but are not:

Watch for wording like "needs a guaranteed exact answer," "outcome must be exactly correct," or "a simple deterministic rule already solves it" as signals that AI/ML is not appropriate.

When AI/ML does fit, the exam expects you to pick the technique that matches the problem type. The choice hinges on what you are trying to produce. Regression predicts a continuous numeric value, such as a price, a temperature, minutes until a delivery arrives, or expected demand. Classification predicts a category or class from a fixed set of options, such as spam versus not-spam, approve versus decline, or likely-to-cancel versus likely-to-renew; both regression and classification are supervised techniques that need labeled data (past examples with the known answer recorded). Clustering is an unsupervised technique that groups similar items together when you have no labels and want to discover natural segments, such as grouping customers by behavior.

Decide by the output, not by the algorithm's name. Logistic regression, despite its name, is a classifier: it outputs the probability of a class and is used for yes/no decisions. A classifier that outputs a probability ("82% likely to cancel") is still classification, because the target is a category.

Clustering versus anomaly detection. Both can work without labels, but they answer different questions. Clustering partitions the whole population into groups, so every customer lands in some segment. Anomaly detection models what normal looks like and flags only the unusual few that deviate from it, which is the core of most fraud detection. If the goal is "which groups exist," it is clustering; if the goal is "which items do not fit," it is anomaly detection.

The fastest heuristic: a number as the answer means regression, a labeled bucket means classification, grouping without predefined labels means clustering, and spotting outliers means anomaly detection.

The exam lists concrete application areas, and recognizing each by its description is enough. Computer vision interprets images and video, powering quality inspection, medical image analysis, and face or object detection. Natural language processing (NLP) works with written language for sentiment analysis, entity extraction, and document classification. Speech recognition converts spoken audio into text, enabling call transcription and voice interfaces. Recommendation systems suggest products, content, or connections based on a user's behavior and similar users, and are what drive "customers also bought" features.

Fraud detection spots unusual or suspicious activity by learning what normal transactions look like and flagging the anomalies. Forecasting predicts future values from historical time-series data, such as future demand, staffing needs, or energy usage. Knowledge bases and intelligent search let users ask natural-language questions and get answers pulled from a body of documents, rather than scrolling through keyword results.

Agentic AI extends generative AI so a system can plan and carry out tasks by taking actions in other systems through tools, such as calling an ordering API to place a purchase order or booking a flight and sending the confirmation. The deciding feature is acting, not the number of steps. An assistant that searches a knowledge base, summarizes what it found, and cites its sources performs several steps, but it only reads and reports; it is retrieval (a knowledge base), not an agent. Once the assistant changes something outside itself, such as creating an order, updating a record, or sending a message on the user's behalf, it is agentic.

Tie each phrase to its capability: images to computer vision, audio to speech recognition, suggestions to recommendation systems, anomalies to fraud detection, answers from documents to knowledge bases, and actions taken on a user's behalf to agentic AI.

AWS offers pre-trained, managed AI services so you can add a capability with an API call instead of building and training a model yourself. Task 1.2 focuses on knowing each service by its purpose and what it accepts and returns.

• Amazon Transcribe converts speech (audio files or streams) to text. It can label who said what: speaker diarization separates multiple speakers in a single audio channel, and channel identification transcribes each channel separately when the agent and caller are recorded on different channels. Transcribe Call Analytics, its contact-center variant, works on two-channel call audio (agent on one channel, customer on the other) and also returns per-turn customer and agent sentiment, call categories, and issue detection directly.
• Amazon Polly does the reverse of Transcribe: it converts text to lifelike speech.
• Amazon Translate translates text (and text documents) between languages. It does not accept audio.
• Amazon Comprehend is the NLP service for text: it detects sentiment (positive, negative, neutral, or mixed), entities, key phrases, personally identifiable information, and the dominant language of a document. Its built-in features are pre-trained and work with no training data; custom classification and custom entity recognition train a model on labeled examples you provide.
• Amazon Lex builds conversational interfaces (chatbots and voice bots) and uses the same conversational AI technology that powers Amazon Alexa. A Lex bot recognizes the user's intent (what they want, such as "book an appointment"), prompts for any missing required details called slots (such as the date, time and location), and then fulfills the request, typically by invoking an AWS Lambda function that calls a backend system.

A note on forecasting. Amazon Forecast, the managed time-series forecasting service, has been closed to new customers since July 2024; existing customers can keep using it. AWS points new users to time-series forecasting in Amazon SageMaker Canvas (part of SageMaker AI), so for a new account forecasting is built with SageMaker AI rather than a dedicated service.

The six services the task names are Comprehend, Transcribe, Translate, Polly, Lex, and SageMaker AI; Rekognition, Textract, Kendra, and Personalize round out the common use cases.

Several managed AI services overlap at first glance, and the distinction is what each one actually understands. The table summarizes the pairs that are easiest to confuse.

A useful habit is to name the input and output of each service. Transcribe takes audio and returns text. Translate takes text and returns text in another language. Comprehend takes text and returns insights about it. Polly takes text and returns audio. Textract takes document images and returns text plus structure. Rekognition takes images or video and returns labels, faces, and detected text.

Managed AI services are often combined, and the order is decided by what each service accepts as input. Because Translate and Comprehend both work on text, any audio must go through Amazon Transcribe first.

• How customers felt on recorded calls: Transcribe the audio to text, then send the text to Amazon Comprehend for sentiment. Alternatively, Transcribe Call Analytics returns per-turn customer and agent sentiment itself, so one service can do both jobs for contact-center calls.
• Searchable English text from multilingual podcast episodes: Transcribe each episode in its source language, then translate the transcript with Amazon Translate; any text analysis, such as extracting key phrases, comes after. Translate cannot take audio directly, so whenever the input is speech, transcription is always the first step.
• Reply to a written message in a spoken voice: generate or select the reply text, then use Amazon Polly to speak it.

Comprehend supports sentiment in a number of languages besides English, so translation is needed for the humans who must read the text, not always for Comprehend itself. Check what the requirement actually asks for: a readable English version needs Translate; a sentiment score alone may not.

The pre-trained services above solve common, well-defined problems out of the box, but sometimes your problem is specific to your business, such as predicting churn from your own customer data or detecting defects unique to your product. That is where Amazon SageMaker AI fits. SageMaker AI is the fully managed service for the whole custom machine-learning workflow: you use it to build, train, and deploy your own models, with the infrastructure managed for you.

The distinction the exam draws is level of control versus effort. Managed AI services like Comprehend or Rekognition require no ML expertise and no training data of your own; you send a request and get a result, but you cannot change what the model does. SageMaker AI gives you full control to create a model tailored to your data and problem, at the cost of needing data and more skill. A simple decision rule: if a ready-made service already does the task, such as transcription or translation, use it; if you need a custom model trained on your own data, use SageMaker AI. Note that building the model pipeline in detail, along with MLOps and monitoring, belongs to Task 1.3, so here you only need to know what SageMaker AI is for.

Task 1.2 asks when a traditional ML model is a better fit than a foundation model (FM), and the reverse. Foundation models are large, general-purpose models (the basis of generative AI) that are powerful and flexible but also large, costly to run, nondeterministic, and hard to fully explain. Traditional ML models, such as a regression or decision-tree model trained on your tabular data, are smaller, cheaper, and often far easier to interpret, but each one learns a single task from labeled examples. The right choice depends on constraints, not on which is more advanced.

Regulation does not automatically mean traditional ML. What matters is what the model does. A retailer under strict consumer-protection rules that wants first drafts of product descriptions for thousands of new items, with no labeled training data and a copy editor reviewing every draft before it is published, is a good fit for a foundation model: the task is open-ended generation, and the human review is the control. The same retailer automatically approving or refusing refunds, where each decision must be justified to a regulator, points to traditional ML.

Generation versus retrieval of past answers. Retrieval, such as a similarity search over content you already have, needs no labels either, and it works well when the same requests recur. But it can only return text that already exists, so it cannot handle a request that nothing in the archive covers. A foundation model generates new text, which is what an open-ended drafting task needs.

A plausible rationale is not an explanation. When regulators require you to show which factors drove each individual decision, asking an LLM to write a justification does not meet the requirement. The text is generated after the fact, may not reflect how the decision was actually reached (it is not faithful), and can differ each time it is generated (it is nondeterministic). Citing the policy documents an FM retrieved through retrieval-augmented generation (RAG) has the same limit: it shows what the model read, not how this applicant's factors were weighed. Interpretable traditional models, together with feature-attribution tools such as Amazon SageMaker Clarify (covered in Task 4.2), give a per-decision explanation.

The common trap is assuming the biggest, newest model is always best; the opposite trap is assuming any regulated industry rules out foundation models. Decide from the task: per-decision explanation, consistency, and cheap high-volume scoring favor traditional ML; open-ended generation, scarce labels, and broad language tasks favor a foundation model.

Consider an insurer modernizing its operations, where each need maps to a different Task 1.2 answer. To decide which claims to pay automatically and which to route to a human, it must be able to explain and defend every decision to regulators, so it chooses a traditional ML classification model over a foundation model, and it keeps a person in the loop for borderline cases, an example of AI assisting human decision making. To estimate a fair premium, a continuous dollar amount, it uses regression. To predict next quarter's claim volume from years of history, it uses forecasting on time-series data, built in SageMaker AI. To turn long policy wording into plain-language summaries for customers, it uses a foundation model to draft them, with a staff member reviewing each summary before it is published.

For its contact center, the insurer converts recorded calls to text with Amazon Transcribe, with agent and caller labeled separately, gauges customer sentiment and pulls out key details with Amazon Comprehend, and answers common questions through a chatbot built on Amazon Lex that asks for a policy number before looking anything up. It reads fields and tables from scanned claim forms with Amazon Textract. When it wants to segment customers into groups with no predefined labels, it uses clustering. Finally, it decides not to use AI to calculate policy renewal dates, because that is a fixed, exact rule with one correct answer and needs no prediction. One company, and every core Task 1.2 judgment: value, non-value, technique choice, service choice, and model choice.