The scopes climb in the same direction as ownership, so they also climb in the amount of work a team signs up for. Sorting a risk into the layer that owns it is the same instinct applied to one worry at a time; the matrix applies it to a whole workload before anybody has written a control down. The broader set of governance frameworks, review cadences and transparency standards sits in the governance programme this framework hangs inside, and the jump from scope 3 to scope 4 is the moment described in deciding how far to customise a model, seen from the security side rather than the cost and accuracy side.
Flash card
Generative AI Security Scoping Matrix: an AWS framework that sorts a generative AI use into one of five scopes by how much of the stack your organisation owns, so a team can tell which controls are theirs to run and which are somebody else's.
- Scope 1 is a consumer application: a public chatbot or image tool that staff use through its own interface, under whatever terms the provider publishes, with no contract negotiated for your purpose. You own almost nothing technically. Your controls are an acceptable-use policy, training on what may and may not be pasted in, and monitoring of what leaves the organisation.
- Scope 2 is an enterprise application: a business application you already pay for, from a vendor you already have a contract with, that has switched on generative AI features running on models the vendor picked and hosts. Your controls are contractual (what the vendor may do with your data, where it is processed, how long it is kept) plus whatever admin toggles the product exposes.
- Scope 3 is an application you build on a pre-trained model somebody else supplies, which is where an assistant calling Amazon Bedrock lands. The model belongs to the provider; the application layer, the prompts, the retrieval corpus, the logs and the AWS Identity and Access Management [IAM] permissions around all of it are yours, along with the guardrails and the output filtering.
- Scope 4 is that same pre-trained model fine-tuned on your own data, which adds ownership of the training data and of everything that data now carries into the weights: whether it should have been in there, who consented to it, and what a determined prompt could pull back out. Scope 5 is a model your organisation trains from scratch, where the whole stack is yours down to the provenance of the training corpus, including data you licensed, scraped or bought.
- Placement is decided by how much of the stack you built, not by how the service is billed and not by how managed it feels. A fully managed AWS service can still leave the application-layer controls entirely with you: Amazon Bedrock runs the model, and the prompt injection defence, the tenant isolation and the retention of conversation logs remain yours to design. The useful question is what you would have to rebuild if the supplier vanished tomorrow, and the answer names the scope.
Pick it when
Reach for it when a scenario asks which controls a team owns for a given AI workload, or when a governance programme needs a shared vocabulary for talking about several different AI uses at once. Naming the scope settles the argument about whether a control is a policy matter, a contract clause or a piece of engineering, and it is the framework a scenario means when it says governance frameworks in the context of generative AI on AWS.
It's the wrong answer when
It is the wrong answer for a certifiable management system, which is ISO/IEC 42001; for a risk process organised around govern, map, measure and manage, which is the NIST AI Risk Management Framework; and for any runtime enforcement, since a scope is a classification and blocks nothing. Placing a workload in scope 3 tells you the output filtering is yours, it does not filter anything, and Amazon Bedrock Guardrails still has to be configured.