AWS Frameworks for AI Decisions

This is the single reference for the frameworks the AWS Certified AI Business Strategist (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?

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.

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

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

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.

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

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.

Risk classification as a mental model

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.