When machine learning is the wrong tool

At the November 3 AI hour, Lorraine Beaudry arrived with a list from the board: twelve ideas, each beginning "Could AI...". Noor read it aloud and, to Lorraine's surprise, crossed out four. "Saying no to the wrong ideas," she said, "is the most valuable thing an AI assessment does. It saves the money for the right ones."

The exam guide asks candidates to recognize when AI and ML are not appropriate and when a traditional ML model is a better choice than a foundation model. This lesson covers both: the situations where ML adds cost and risk without benefit, and the factors, such as regulation, explainability and operating limits, that decide between kinds of AI.

When a rule already exists

If the correct answer can be written down as a fixed rule, a rule is cheaper, faster, fully explainable and always right. Vaccine due dates at Cascade Ridge follow manufacturer and professional guidelines; a reminder that fires 12 months after a rabies vaccination is a few lines of ordinary code. Training a model to predict the due date would only add the chance of being wrong. The same applies to tax calculations, eligibility rules set by policy and anything else defined by regulation or contract.

When a specific outcome is needed instead of a prediction

Machine learning produces probabilistic outputs: likely answers with some chance of error. Some decisions need a deterministic answer, the same correct result every time. Calculating an invoice, checking that a controlled drug count balances, or applying a refund policy should never be "probably right". If a wrong answer would be unacceptable and a definite answer can be computed, use conventional software. ML can still help around the edges, for example by flagging unusual invoices for a person to check, but it should not produce the invoice.

When there is not enough good data

ML learns from examples. If there are too few, if they do not represent the situations the model will face, or if nobody can label them reliably, a model will be unreliable. Andre suggested predicting which new clinics the company should open. Cascade Ridge has opened four clinics in ten years, which is four examples: far too few to learn from. That question belongs to market research and judgment, perhaps supported by data analysis, not a predictive model.

When the cost outweighs the benefit

Every ML system has costs beyond training: data preparation, integration, monitoring, retraining, security review and staff time. A cost-benefit analysis compares those with the value the model creates. The board's idea of predicting which clients will buy premium pet food scored poorly: the potential extra revenue was small, the data was thin, and a simple promotion to clients with large-breed dogs would capture most of the value. Lesson 5's business metrics, cost per prediction and return on investment, make these comparisons concrete.

When the risk of harm is too high

Some uses carry risks that outweigh any benefit, at least without strong safeguards. The board's idea of an "AI diagnosis" chatbot that tells clients whether their pet needs to come in was rejected by Dr. Kaur. A wrong answer could delay care for a sick animal, liability would fall on the practice, and veterinary regulators expect a professional to make clinical judgments. The agreed principle for all AI work at Cascade Ridge is that AI may assist, but every clinical decision stays with a veterinarian or a credentialed veterinary technician. AWS-114 covers human oversight in depth.

Traditional ML or a foundation model?

When AI does fit, there is still a choice between a traditional ML model, such as a gradient-boosted tree trained on your own tabular data, and a foundation model, such as a large language model used through Amazon Bedrock. The exam guide names three factors that often decide it.

• Regulatory concerns. Regulated decisions may require documented data sources, consistent behavior and the ability to show how an outcome was reached. A traditional model trained on known data is easier to document and audit than a very large model trained by someone else on data you cannot inspect.
• Explainability requirements. If people must understand why the system produced an answer, simpler models are easier to explain. A decision tree or a model with clear feature importances, checked with SageMaker Clarify, can show that past misses and days booked ahead drove a score. A large language model's reasoning is much harder to trace.
• Operational constraints. Foundation models can be slower, more expensive per request and less predictable in their output. A nightly score for 2,600 bookings needs speed, low cost and identical results for identical inputs, which suits a small traditional model. Tasks involving open-ended language, such as summarizing a call or drafting a letter, suit foundation models, because no small model trained on Cascade Ridge's data could do them.

The rough rule: structured data with a clear target and a need for explanation points to traditional ML; unstructured language or images, open-ended generation and tasks where no labeled data exists point to foundation models or managed AI services.

# A tiny screening function for AI ideas, following the decision path.
def screen(idea):
    if idea["fixed_rule"]:
        return "use rules or ordinary software"
    if idea["must_be_exact"]:
        return "do not use ML for the decision"
    if idea["examples"] < 1000 and not idea["pretrained_service"]:
        return "collect data first, or use a pre-trained service"
    if idea["value"] <= idea["cost"]:
        return "not worth it yet"
    return "try the simplest model first, with human review where stakes are high"

ideas = {
    "vaccine due dates": dict(fixed_rule=True, must_be_exact=True, examples=0, pretrained_service=False, value=0, cost=0),
    "new clinic sites": dict(fixed_rule=False, must_be_exact=False, examples=4, pretrained_service=False, value=50, cost=40),
    "no-show prediction": dict(fixed_rule=False, must_be_exact=False, examples=410000, pretrained_service=False, value=90, cost=25),
}
for name, idea in ideas.items():
    print(name, "->", screen(idea))

vaccine due dates -> use rules or ordinary software
new clinic sites -> collect data first, or use a pre-trained service
no-show prediction -> try the simplest model first, with human review where stakes are high

The screen is deliberately crude, and the thresholds are made up for illustration, but it captures the order of the questions Noor asks: is there a rule, must the answer be exact, is there data, is it worth it? Only ideas that pass every question reach the modeling stage.

Hidden costs and the simplest thing that works

Noor kept a list of costs that ideas often forget. People must label data, review flagged cases and handle complaints when a model is wrong. Integration means changing the software and screens staff already use, and training staff to trust or question a new signal. Security and privacy review takes time, and some data cannot be used at all. Monitoring and retraining continue for as long as the model is in use. Finally there is opportunity cost: the team's time spent on one idea is time not spent on another.

Her counter to these costs is to try the simplest approach first and measure it. Before the no-show model, Andre's old rule, an extra reminder for anyone booked more than three weeks ahead, already caught about 1 in 3 misses. The model had to beat that rule by enough to pay for itself, and it did, reaching about 6 in 10. If it had only matched the rule, the right decision would have been to keep the rule. A baseline is not just a statistical check; it is a business question about whether the extra complexity buys anything.

Using AI to assist rather than decide

Many ideas that fail as automated decisions succeed as assistance. The rejected diagnosis chatbot became a different, much safer idea: an assistant that helps clients describe their pet's symptoms in a structured way before a call, so the triage technician starts with better information and still makes every decision. The rejected premium-food prediction became a plain report of which clients have large-breed dogs. Reframing an idea so that a person stays in charge, and the AI saves them time or surfaces information, often keeps most of the value while removing most of the risk. Noor recorded each rejected idea with its reframed version, so the board could see that saying no to one design was not saying no to the underlying need.

Questions to ask before any AI project

Noor gave the leadership team a one-page list of questions to ask of every future idea, whether it comes from staff, a vendor or the board. What decision or task will this change, and who does it today? What happens when the AI is wrong, and who notices? Is there a rule or a simpler tool that would do? What data does it need, and are we allowed to use it that way? Who will own it once it is running, and what will it cost each year, not just to build? How will we know, within three months, whether it is working? An idea that cannot answer these questions is not ready for a pilot. Lorraine said the list would also help her evaluate the AI features vendors were starting to add to the practice-management software, where the same questions apply even if no model is built in-house.

Lorraine left the session with the board's list reduced from twelve ideas to five worth pursuing, three that would be handled without AI at all, and four reframed so that a person stays in charge. She said that was the most useful hour of the assessment so far, because it turned a vague wish to "use AI" into a short list of decisions she could fund and measure.