D1 · AI Fundamentals and Literacy

This domain carries 24% of the blueprint — roughly 20 of 85 items on our mock. It is not a technical exam: it tests whether a business leader has enough literacy to hold a straight conversation with a technical team, choose the right kind of solution, and know what to ask for and what to worry about. You will not be asked to derive an algorithm; you will be asked which vocabulary applies, when AI is the wrong tool, what an agent’s autonomy costs you in oversight, and why a model that worked in January quietly degrades by June. The whole domain rewards one habit: understanding AI well enough to make a decision, without pretending to be an engineer.

What you need to know

AI is the umbrella; machine learning is AI that learns patterns from data; generative AI is ML that produces new content. A model is trained on historical data, then used for inference to make predictions — so it inherits whatever the training data encoded, including yesterday’s bias. Data type (structured versus unstructured) and data quality drive outcomes more than model choice does. Rule-based automation beats AI whenever the logic is deterministic and auditable; AI earns its place where patterns are too varied to enumerate. Agents add autonomy and tool use, which multiplies both value and governance exposure. Because the world moves and models do not, every AI solution needs ongoing monitoring for drift, and every organisation needs a transparent tool-classification list to keep shadow AI in check.

Learning objectives

By the end of this page you should be able to:

1. Use the core business vocabulary of AI correctly — algorithm, model, training, inference, prediction — and place AI, ML and GenAI in their nested relationship.
2. Distinguish structured from unstructured data and explain why data type and data quality drive AI outcomes.
3. Explain what training on historical data implies for a business: representativeness, recency, feedback loops and inherited bias.
4. Describe at a business level what ISO/IEC 23053 and ISO/IEC 42001 are for.
5. Decide when rule-based automation is the correct tool and when AI is the wrong one.
6. Distinguish AI agents from other AI solutions and reason about the governance consequences of autonomy.
7. Specify the ongoing monitoring a business owner must demand: model drift, data drift and performance decay.
8. Establish a transparent AI-tool classification (approved / blocked / under evaluation) to mitigate shadow-AI risk.
9. Apply basic prompt-engineering principles and explain token and context-window limits as business constraints.
10. Choose between prompting, RAG and fine-tuning on cost, effort, freshness and control.

Task statements covered

1.1 AI, ML, GenAI and the words that trip leaders up

The exam expects you to use five words precisely and to place three fields in their nested order. Getting the vocabulary wrong is the fastest way to lose a technical team’s confidence — and to pick a wrong answer.

The three fields are nested, not rival:

   ┌──────────────────────────────────────────────┐
   │ ARTIFICIAL INTELLIGENCE                        │
   │  systems that perform tasks needing            │
   │  human-like judgement                          │
   │   ┌──────────────────────────────────────┐     │
   │   │ MACHINE LEARNING                       │     │
   │   │  learns patterns from data instead     │     │
   │   │  of being explicitly programmed        │     │
   │   │   ┌──────────────────────────────┐     │     │
   │   │   │ GENERATIVE AI                  │     │     │
   │   │   │  ML that generates new content │     │     │
   │   │   │  (text, image, audio, code)    │     │     │
   │   │   └──────────────────────────────┘     │     │
   │   └──────────────────────────────────────┘     │
   └──────────────────────────────────────────────┘

A recommendation engine is ML but not generative. A rules engine that flags transactions over a threshold is neither ML nor GenAI — it is deterministic automation. GenAI is a subset of ML, which is a subset of AI; the exam punishes the reflex to call everything “AI”.

1.2 Structured vs unstructured data, and why quality drives outcomes

Data type shapes which solution is even possible, and data quality caps how good the outcome can be regardless of the model.

The leadership point is that GenAI made unstructured data commercially useful — the contracts, tickets and call transcripts that used to sit unread. But every kind of AI is bounded by data quality. A useful business checklist for quality is complete, correct, current, consistent, representative:

  DATA QUALITY  →  OUTCOME CEILING
  ─────────────────────────────────
  Incomplete   →  gaps the model fills with guesses
  Incorrect    →  confident wrong answers
  Stale        →  right answer to last year's question
  Inconsistent →  the same entity treated three ways
  Unrepresentative → works for the majority, fails a segment

Worked example. A support team wants to auto-triage tickets. The model reaches 91% accuracy on the majority language but 62% on a customer segment that writes in a second language under-represented in the training data. Headline accuracy of 88% hides a segment failure that is also the highest-complaint segment. The fix is a data decision (represent the segment), not a model swap — quality and representativeness, not cleverness, set the ceiling.

1.3 Training on historical data — and what it implies

A model trained on historical data is, by construction, a compressed opinion about the past. Three consequences follow, and each is a business risk, not a technical footnote.

• Representativeness. The model is only as fair as the data was balanced. If a hiring dataset over-represents one profile, the model learns that profile as “good”.
• Recency. The world moves; the training snapshot does not. A demand model trained before a market shift keeps answering last year’s question.
• Feedback loops. When a model’s own outputs become tomorrow’s training data, small biases compound. Recommend the same products, gather clicks on those products, recommend them harder.

The most examined line: yesterday’s data encodes yesterday’s bias. A model does not invent discrimination; it faithfully reproduces whatever the historical data contained, then applies it at scale and at speed. That is why a business owner asks what period is this trained on, who is in the data, who is missing, and how will the model’s own outputs feed back in before trusting a prediction.

   HISTORICAL DATA ──train──► MODEL ──inference──► DECISIONS
        ▲                                              │
        └──────────  outputs become new data  ─────────┘
              (feedback loop: bias can compound)

1.4 Global frameworks and a unified vocabulary

The exam asks you to be aware of two ISO/IEC standards at a business level — what each is for, not their clause numbers.

Why a strategist cares: a common vocabulary lets legal, risk, engineering and the business argue about the same thing, and a recognised management-system standard turns “trust us, we’re responsible” into something a customer or regulator can audit. You will also meet the NIST AI Risk Management Framework (Govern, Map, Measure, Manage) and risk-tiered regulation such as the EU AI Act in Domain 3 — the fundamentals here are that standards exist, they give everyone the same words, and one of them (42001) is a certifiable management system.

1.5 Rule-based automation versus AI

The single most valuable literacy skill on this exam is knowing when not to reach for AI. Rule-based automation is deterministic, transparent, cheap to audit and correct every time the rule is correct. AI is probabilistic, powerful on messy patterns, and wrong some of the time by design.

Honest examples where AI is the wrong tool:

• Calculating tax or interest — a formula, deterministic, must be exact and auditable. Use a rule.
• Enforcing a compliance threshold (“block any transfer over the limit”) — a rule, not a model.
• Routing a form by a checkbox value — a rule.
• Any decision that must be identical and defensible every time — a rule, because “usually right” is not good enough.

AI earns its place where the input is unstructured or the patterns are too varied to write down: summarising a call, extracting fields from a messy invoice, flagging anomalies no one pre-listed, drafting a first version. When a stem describes a deterministic, well-specified, high-stakes-must-be-exact problem, the sophisticated answer is a rule.

1.6 AI agents versus other AI solutions

An agent is an AI solution that can take actions toward a goal, not just produce an answer. The defining capabilities are autonomy (it decides the next step), tool use (it calls systems, APIs or functions), agent-to-agent communication (agents coordinate) and orchestration (a controller sequences the steps). A plain GenAI assistant answers; an agent does.

  ASSISTANT                         AGENT
  ─────────                         ─────
  You → prompt → answer             Goal → plan → act (tool) → observe
  You act on the answer                    → decide next step → repeat
                                           → until goal met or stopped
  Human in every loop               Human sets the goal and the guardrails

The leadership point is that autonomy and governance move together. The more an agent decides and acts on its own — spending money, sending messages, changing records — the more it can accomplish and the more damage a single wrong step can do. So autonomy is a governance dial, not a free upgrade:

1.7 Why AI needs ongoing monitoring

A trained model is a snapshot; the world keeps moving. That gap is why the correct answer to “we deployed it, are we done?” is always “no”. Three related decays matter, and a business owner must be able to name what they are asking for.

What a business owner must ask for, in plain terms: a baseline captured at launch; ongoing monitoring against it; alert thresholds that page a human; a defined cadence for review and retraining; and an owner accountable for acting on the alert. On AWS, tooling such as SageMaker Model Monitor exists to detect and alert on inaccurate predictions from deployed models — but the exam only needs you to know that monitoring is not optional and someone must own it. “Set it and forget it” is always the wrong answer.

1.8 Shadow AI and transparent tool classification

Shadow AI is employees using AI tools that the organisation has not vetted — pasting confidential data into a personal chatbot to get work done faster. It is rarely malicious; it is usually a symptom of a governed path that is too slow or does not exist. The mitigation the exam wants is transparent classification: a living, published list of tools in three states.

Two things make classification work rather than perform caution: it is transparent (people can see the list and why a tool is where it is) and it comes with a fast approved default, so the governed path is easier than the ungoverned one. A blanket ban with no approved alternative does not stop shadow AI; it guarantees it. This is the fundamentals-level version of a theme Domain 3 develops into a full governance operating model.

1.9 Prompt-engineering principles at a business level

You will not be tested on clever prompt tricks, but on the principle that a model’s output quality is largely a function of the instruction it was given. The business-level checklist:

• Role — tell the model who to be (“you are a claims analyst”).
• Task — state the single job precisely.
• Context — supply the facts the model needs instead of hoping it guesses.
• Constraints — length, tone, what to avoid, what must be included.
• Format — the exact shape of the output (table, bullets, one page).
• Examples — one or two worked examples steer format and quality more than a paragraph of description.
• Success criterion — how you will judge the answer.

The leadership takeaway: vague in, vague out. When a team complains that “the AI gives generic answers”, the first question is what it was asked, not whether to buy a bigger model. Prompt clarity is the cheapest quality lever there is.

1.10 Tokens and context windows as business constraints

A token is a chunk of text (roughly a short word or word-piece) that the model reads and writes; you are typically billed per token and the model can only “see” a bounded amount of text at once — its context window.

  CONTEXT WINDOW  =  how much the model can hold in view at once
  ┌───────────────────────────────────────────────────────┐
  │ system + instructions │ your documents │ conversation  │  ← output
  └───────────────────────────────────────────────────────┘
     if the total exceeds the window, the oldest text falls out

Two business constraints follow. First, cost scales with tokens: a workflow that stuffs a whole 200-page manual into every request is expensive and often slower, and RAG (1.11) exists partly to avoid it. Second, the window is finite: past a limit the model forgets earlier context, truncates the document, or loses the thread of a long conversation — which shows up as a quality problem that is really a context-limit problem. When a stem says the model “forgets earlier instructions” or “misses details in a very long document”, the discriminator is the context window, not the model’s intelligence.

1.11 Model adaptation: prompt → RAG → fine-tuning

There is a ladder of ways to make a general model fit a specific business need. Climb it only as far as you must, because each rung costs more effort and control.

Retrieval-Augmented Generation (RAG) is the workhorse for business knowledge: it keeps the facts in a source you control, so updating a policy document updates the answers with no retraining. On AWS this is what managed Knowledge Bases provide at a strategic level — RAG without the infrastructure. Fine-tuning changes the model itself; it is powerful for consistent tone or specialised behaviour but expensive, slow to refresh, and the wrong tool when the underlying facts change weekly.

  Need better answers from a general model?
  │
  ├─ Better instructions / context enough?  → PROMPT ENGINEERING (start here)
  │
  ├─ Answers must reflect changing, proprietary facts?  → RAG
  │
  └─ Need consistent specialised behaviour, stable data,
     and prompting/RAG are not enough?  → FINE-TUNING (last, most costly)

The exam’s preferred instinct: start at the cheapest rung and climb only when forced. Reaching straight for fine-tuning when a prompt or RAG would do is the classic over-engineering distractor.

Decision framework

The capability-to-solution selector

When a business problem lands on your desk, this selector routes it to the kind of solution before anyone talks about a specific product. Score the problem on four axes, then read the recommendation.

How to read it:

Worked application. A lender wants to (a) decide loan eligibility against a fixed regulatory rule, (b) predict default risk, and (c) draft the customer decision letter.

• (a) Eligibility is deterministic, high-stakes, must be identical and auditable → rule-based automation. Using a model here would be both riskier and harder to defend.
• (b) Default risk is a pattern in structured historical data with error tolerance managed by policy → classical ML, with explainability (e.g. SageMaker Clarify at the strategic level) and human review of edge cases because the domain is regulated.
• (c) The letter is unstructured generation from a template and the facts → GenAI, with a human review gate before anything goes to the customer.

One business problem, three different solution classes. The framework’s value is refusing the reflex to make all three “an AI project”.

Common mistakes

Scenario walkthrough

Scenario. A retailer’s operations director asks you to “add AI” to three problems at once. First, a returns-eligibility check: the policy is a fixed set of rules (within 30 days, unworn, receipt present). Second, demand forecasting for seasonal stock, where two years of clean sales history exist. Third, an auto-responder that will read a customer’s free-text complaint and send a resolution email — refund, replacement or apology — on its own to cut response time. A vendor has pitched a single “AI platform” for all three, and a fine-tuned model “trained on your data” for the responder. The director wants a recommendation by Friday and is impressed by the fine-tuning pitch.

Expert reasoning trace.

1. Refuse the one-size framing. These are three different problems on the capability-to-solution selector, and bundling them into one “AI project” is the first error. I score each separately.

2. Returns eligibility is deterministic and auditable — the answer is fixed by policy and must be identical every time and defensible to a customer or regulator. That is rule-based automation, not AI. Using a probabilistic model here would introduce variability into a rule that has no reason to vary, and make disputes harder to defend. The sophisticated answer says “this one is not an AI problem”.

3. Demand forecasting is a pattern in structured historical data with error tolerance managed by safety stock. That is classical ML. But I immediately flag recency and representativeness: two years of history that predate a market shift will forecast last year’s demand, so I ask what period the data covers and require drift monitoring, because a forecast that was accurate at launch decays as conditions move.

4. The auto-responder is the dangerous one. It is GenAI (unstructured input, generated output) plus autonomy (it sends, and refunds are money leaving the business). Autonomy and governance move together: an agent that spends money on its own has a large blast radius. So the recommendation is GenAI to draft, with a human approval gate before anything is sent or refunded — at least until monitored performance justifies raising autonomy on low-value, reversible cases.

5. Challenge the fine-tuning pitch. The responder’s facts — this customer, this order, current policy — change constantly, and fine-tuning freezes knowledge at training time. The right adaptation is RAG over current order and policy data, not fine-tuning, because updating a policy document must update the answers without a retrain. Fine-tuning here would be the most expensive rung of the ladder solving a problem the cheaper rung solves better.

6. Name the monitoring and ownership. Each AI component gets a baseline, drift monitoring and a named owner; the deterministic returns check does not need drift monitoring because it does not learn.

Exam-correct recommendation: rule-based automation for returns eligibility; classical ML with drift monitoring for forecasting; GenAI with RAG and a human approval gate for the responder, raising autonomy only for low-value reversible cases once monitored. Reject the single-platform bundle, reject fine-tuning for the responder, and reject any full autonomy that lets the system refund money unsupervised on day one.

Exam traps in this domain

Practice questions

Each item states how many responses to select. Attempt before revealing.

Key takeaways

• AI ⊃ ML ⊃ GenAI; use algorithm, model, training, inference, prediction precisely, and do not call deterministic automation “AI”.
• Data type and data quality set the outcome ceiling; representativeness and recency matter more than model cleverness.
• Training on historical data means the model reproduces yesterday’s patterns and biases at scale — interrogate who is in the data and how fresh it is.
• Rule-based automation beats AI whenever the logic is deterministic, exact and must be auditable; knowing when not to use AI is a core exam skill.
• Agents add autonomy and tool use; oversight must scale with autonomy because action power is blast radius.
• Every learned model drifts — demand baselines, monitoring, thresholds, a review cadence and an owner; “set and forget” is always wrong.
• Beat shadow AI with a transparent approved/blocked/under-evaluation list plus a fast approved default, not a blanket ban.
• Climb the adaptation ladder only as far as forced: prompt first, then RAG for changing facts, and fine-tune last for stable, specialised behaviour.