# AWS Frameworks for AI Decisions AWS CAF at business level, the responsible AI dimensions and Well-Architected Responsible AI Lens, the shared responsibility model for AI, AI Service Cards, and the external standards (ISO/IEC 42001 and 23053, NIST AI RMF, EU AI Act) an AIB-C01 strategist must recognise. import { Tabs, TabItem } from '@prosefly/astro-components'; This is the single reference for the frameworks the [AWS Certified AI Business Strategist (AIB-C01)](/aws/aib-c01/) exam leans on. It carries them at the **business level the exam tests** — no console flows, no APIs, no architecture. Everything here is verified against AWS's published material as of **15 September 2026**; the exam asks you to *apply* these frameworks to decisions, not to cite article numbers or capability counts. Where the exam guide's wording differs from AWS's canonical wording, both are shown. ## AWS Cloud Adoption Framework (AWS CAF) The AWS CAF is the framework AIB-C01 uses to structure a transformation: who owns what, in what order, and how you know a phase is done. Three moving parts: **six perspectives** (the lenses), **four transformation domains** (the value chain), and **four phases** (the sequence). ### The six perspectives Each perspective is a set of capabilities owned by a group of stakeholders. Business, People and Governance are **business-capability** perspectives; Platform, Security and Operations are **technical-capability** perspectives. CAF 3.0 details 47 capabilities in total; the strategist needs the perspectives and the questions they answer, not the capability list. | Perspective | What it owns | The question it answers | | --- | --- | --- | | **Business** | Business outcomes, value realisation, portfolio and investment decisions | Does this AI initiative move a business outcome we care about, and can we prove it? | | **People** | Culture, org structure, roles, skills, change management | Do we have the leadership, skills and culture to adopt this, and who champions it? | | **Governance** | Portfolio management, risk, compliance, benefits realisation | Who is accountable, what are the risks, and how do we manage the portfolio? | | **Platform** | Architecture, engineering, the technology estate | Can our technology foundation support this, and how do we build or buy it? | | **Security** | Identity, controls, threat detection, compliance assurance | Is the data protected, are controls in place, and are we compliant? | | **Operations** | Running, observing and supporting workloads in production | Can we run this reliably in production and detect when it degrades? | :::tip[Exam signal] Stems that say "who should be accountable", "which stakeholders", "what capability gap" or "assess readiness across" are CAF-perspective questions. A strategist answer names the perspective and its owner, not a technical fix. ::: ### The four transformation domains — a value chain CAF frames transformation as value flowing along a chain. Each stage feeds the next; a broken link upstream caps the value you can realise downstream. ```text TECHNOLOGY ──▶ PROCESS ──▶ ORGANIZATION ──▶ PRODUCT migrate & digitise & reshape teams, new / improved modernise automate roles, incentives offerings & models the estate workflows around the work for customers value cannot skip a stage: modern tech with unchanged processes and org structure produces a pilot, not a product ``` The strategist reading: buying the platform (Technology) without redesigning the workflow (Process) or the roles around it (Organization) is the single most common reason a pilot never becomes a Product-level outcome. ### The four phases — entry and exit criteria | Phase | Purpose | Entry criteria | Exit criteria | | --- | --- | --- | --- | | **Envision** | Identify and prioritise transformation opportunities against business objectives | Leadership wants to move; business objectives are stated | A prioritised set of opportunities tied to specific business outcomes | | **Align** | Identify capability gaps across the six perspectives, cross-organisational dependencies and stakeholder concerns | Prioritised opportunities exist | A gap and dependency map, named stakeholders, an action plan to close gaps | | **Launch** | Deliver pilots *in production* and demonstrate incremental value | Gaps understood, pilot scope agreed, baseline measured | Pilots running in production with measured incremental value against baseline | | **Scale** | Expand production pilots and business value to the desired scale | A pilot has demonstrated value and is operationally sound | Value realised at the intended scale, with governance and operations that hold | :::note[Envision → Align, not Envision → Experiment] AWS CAF's own second phase is **Align**. The AIB-C01 exam guide (task 4.4.1) gives an *example* wording of "envision, experiment, launch, scale". Treat that as loose phrasing of the same iterative idea, **not** a different framework. If a stem quotes the guide's four words, it is still testing the CAF sequence: envision the opportunity, close the gaps, prove value in a production pilot, then scale. ::: ### AWS CAF for AI, ML and Generative AI AWS publishes a dedicated **CAF for AI, ML and Generative AI** whitepaper. It uses the *same* six perspectives and the *same* four phases; it does not invent a parallel framework. Its contribution is to name the AI-specific capability gaps you look for in each perspective — for example data readiness and model governance under Governance, and AI literacy and champion identification under People. For the exam, the takeaway is: the AI variant is CAF applied to AI, so a question about "the AWS framework for adopting AI" is answered with CAF's perspectives and phases. ### Worked CAF gap assessment — *Meridian Logistics* *Meridian Logistics* wants to deploy a document-extraction assistant that reads freight invoices. Leadership is enthusiastic (Envision done). Running Align across the six perspectives surfaces the real state: | Perspective | Finding | Gap severity | | --- | --- | --- | | Business | Outcome named (cut invoice-processing cost 40%) and baseline exists | Low | | People | No AI champion; finance team fears role loss; no literacy programme | **High** | | Governance | No accountability owner; no risk classification; no monitoring plan | **High** | | Platform | Would use a managed platform; no build needed | Low | | Security | Invoice data includes supplier bank details; no access-control review done | Medium | | Operations | No plan to detect extraction-accuracy drift in production | Medium | The strategist's conclusion: the technology is the *easy* part. Meridian is **not ready to Launch** — the two High gaps (People and Governance) must close first. The recommendation is to appoint an accountable owner and an AI champion, run a literacy session with the finance team framing the assistant as a shift to *oversight* work, and define an accuracy-monitoring threshold — *then* pilot. Buying the platform now would produce a stalled pilot and a frightened team. This is the exam's favourite pattern: the correct answer fixes the People/Governance gaps before it touches Technology. ## AWS responsible AI — the eight dimensions AWS publishes **eight core dimensions** of responsible AI. Each carries a business question you should be able to ask, and a failure example that shows what goes wrong when it is neglected. | Dimension | Business question | Failure example | | --- | --- | --- | | **Fairness** | Does the system treat comparable people and groups equitably? | A hiring screen down-ranks a demographic because the training data reflected past bias | | **Explainability** | Can we explain *why* the system produced an output, to the people affected? | A loan denial that no one — including staff — can account for to the customer | | **Privacy and security** | Is personal and sensitive data protected across its lifecycle? | Customer records leak into prompts and surface in another user's output | | **Safety** | Does the system avoid harmful behaviour and outputs? | A support bot recommends an action that damages the customer's account | | **Controllability** | Can humans monitor, steer and intervene in the system? | An automated pricing agent runs unchecked and cannot be paused during an incident | | **Veracity and robustness** | Are outputs accurate, and does the system hold up under real-world and adversarial conditions? | A confident hallucination is published as fact; the model breaks on inputs it never saw | | **Governance** | Are policies, accountability and oversight in place across the lifecycle? | No one owns the model; issues have no escalation path | | **Transparency** | Are stakeholders told how and where AI is used, and its limitations? | Customers are not told they are talking to AI, or what it cannot do | :::note[The exam guide names a six-item subset] The AIB-C01 exam guide's own list is **fairness, explainability, privacy, safety, transparency, robustness** — a subset of AWS's eight. Learn all eight (the exam can reference *controllability*, *veracity* and *governance* by concept), and recognise the guide's six as the ones most likely to be named explicitly. The principle they share: responsible AI is a *design input*, not a review at the end — task 3.1.3 calls this **governance by design**. ::: ## AWS Well-Architected Responsible AI Lens The **Well-Architected Framework Responsible AI Lens** is AWS's collection of best practices for building and operating AI responsibly, organised across **design, development and operation**. Its role in the strategist's toolkit is to be the *how* that sits under the *what* of the eight dimensions: the dimensions tell you fairness and transparency matter; the Lens is where the concrete practices live. In an exam scenario, reaching for the Responsible AI Lens is the right move when the question is "how do we operationalise responsible AI across the lifecycle" rather than "which principle applies here". You do not need to recite its practices — you need to know it exists and where it fits. ```text WHAT (dimensions) HOW (Well-Architected Responsible AI Lens) fairness, safety, ──▶ best practices across transparency, ... design → development → operation the principles the lifecycle practices that realise them ``` ## AWS shared responsibility model for AI workloads The classic split is **security *of* the cloud** (AWS) versus **security *in* the cloud** (customer). For AI workloads the line moves depending on how managed the service is, but one column never moves: customer accountability for **what the system is used for and whether its output is fit for purpose**. | AWS is responsible for… | The customer is responsible for… | What stays yours no matter what | | --- | --- | --- | | Security *of* the cloud: physical infrastructure, hardware, the managed-service operation | Security *in* the cloud: their data, access control, configuration of the service | **Use-case appropriateness** — deciding AI should be used here at all | | Operating and patching the managed AI platform | Which data goes in, and its quality and classification | **Human oversight** of consequential decisions | | Availability of the underlying models and infrastructure | Whether the business process using the output is compliant | **Fitness for purpose** — whether the output is good enough to act on | :::tip[Exam signal] Stems like "the vendor manages the model, so who is accountable for a biased output?" test this model. The answer is almost always the **customer** — a managed service moves the *operational* line but never removes accountability for the use case, the data you feed it, and whether you should have used AI at all. ::: Worked reading: a bank uses a fully managed foundation-model service to draft credit-decision explanations. AWS operates the platform and secures the infrastructure. The bank is still accountable for the data it supplies, for keeping a human in the loop on the actual credit decision, and for whether an AI-drafted explanation is fit to send to a regulator. "It's a managed service" is not a defence for an unfair or unexplained decision. ## AI Service Cards **AI Service Cards** are AWS's transparency artefact for its AI services and models. Each card documents three things: - **Intended use cases and limitations** — what the service is for and what it should not be used for. - **Responsible AI design choices** — the decisions AWS made to address the responsible AI dimensions. - **Performance and optimisation best practices** — how to get good, responsible results. For the strategist, the Service Card is the document you point a governance or procurement conversation at when someone asks "is this service appropriate and safe for our use case?" It supports the **transparency** dimension and feeds the build-buy-partner and use-case-appropriateness decisions. ## External standards worth knowing at a business level The exam expects you to *recognise* these and know what each obliges you to do — not to quote clauses. **ISO/IEC 42001 — AI management system.** The certifiable *management-system* standard for AI, in the same family as ISO 9001 (quality) or ISO 27001 (information security). It defines how an organisation governs AI across its lifecycle: policies, roles, risk treatment, continual improvement. AWS has stated support for it. *What it obliges you to do:* stand up and maintain an auditable management system for AI — documented policies, accountable owners, risk processes — that a certification body could assess. It is about *how you run the AI programme*, not about any single model. **ISO/IEC 23053 — framework for AI systems using machine learning.** A framework standard that gives a common vocabulary and description of AI systems built with ML — components, lifecycle, terminology. It underpins the "unified AI vocabulary" that task 1.1.6 asks you to be aware of. *What it obliges you to do:* nothing certifiable on its own — it is a shared reference model. Use it so that business, legal and technical stakeholders describe the same ML system the same way, which is the point of task 1.1.6. **NIST AI Risk Management Framework.** A voluntary, widely referenced framework for managing AI risk, organised into four functions: **Govern, Map, Measure, Manage.** *Govern* sets the culture and accountability; *Map* establishes context and identifies risks; *Measure* assesses and tracks them; *Manage* acts on them and monitors. *What it obliges you to do:* nothing legally, but it gives you a defensible structure for an AI risk programme. When a stem asks how to organise risk management across the lifecycle, Govern-Map-Measure-Manage is the answer to reach for. **EU AI Act — risk-tiered regulation.** Sorts AI uses into tiers — **unacceptable, high, limited, minimal** — and attaches obligations to the tier, not to the technology. Unacceptable uses are banned; high-risk uses carry heavy obligations (documentation, oversight, quality); limited-risk uses carry transparency duties; minimal-risk uses are largely unregulated. *What it obliges you to do:* classify each AI use by its risk tier and apply the obligations that tier demands. Task 3.2.4 tests exactly this — *applying a risk classification framework to prioritise governance*, not memorising article numbers. ### Risk classification as a mental model ```text EU AI Act tiers obligation intensity ─────────────────────────────────────────────▶ minimal limited high unacceptable (little) (tell (document, (banned) users) oversee, QA) strategist's job: place each use case on this line, then govern to the tier — not to the hype ``` ## When to reach for which framework | The decision in front of you | Reach for | Why | | --- | --- | --- | | Structuring an end-to-end AI adoption programme | **AWS CAF** (perspectives, domains, phases) | It sequences the work and assigns ownership | | Assessing readiness and capability gaps | **CAF Align phase** across the six perspectives | Gaps are found per perspective | | Deciding *how* to build responsibly across the lifecycle | **Well-Architected Responsible AI Lens** | It holds the operational best practices | | Deciding *whether* a use is responsible | The **eight responsible AI dimensions** | They are the principles to apply | | Classifying and prioritising AI risk | **EU AI Act tiers** or **NIST AI RMF** | Tier-based obligations; lifecycle risk functions | | Standing up an auditable governance programme | **ISO/IEC 42001** | The certifiable management-system standard | | Establishing shared AI terminology | **ISO/IEC 23053** | The framework and vocabulary for ML systems | | Judging who is accountable for a managed AI service | **Shared responsibility model** | It draws the accountability line | | Deciding if a service fits a use case | **AI Service Cards** | Intended use, limitations, design choices | ## Key takeaways - **AWS CAF** = six perspectives (Business, People, Governance, Platform, Security, Operations) × four transformation domains (Technology → Process → Organization → Product) × four phases (Envision → Align → Launch → Scale). Value cannot skip a transformation stage, and each phase has entry and exit criteria. - The guide's "envision, experiment, launch, scale" is loose wording for the CAF phases, whose true second phase is **Align**. - AWS publishes **eight** responsible AI dimensions; the exam guide names a **six-item subset** — learn all eight and treat responsible AI as **governance by design**. - The **Well-Architected Responsible AI Lens** is the *how* (lifecycle best practices) under the *what* (the dimensions). - The **shared responsibility model** moves the operational line for managed services but never removes customer accountability for **use-case appropriateness, human oversight and fitness for purpose**. - **AI Service Cards** document intended use, limitations and responsible-AI design choices — your transparency and procurement reference. - Recognise **ISO/IEC 42001** (certifiable AI management system), **ISO/IEC 23053** (ML framework and vocabulary), **NIST AI RMF** (Govern-Map-Measure-Manage) and the **EU AI Act** risk tiers, and know what each obliges you to do.