The situation
A retailer’s security team has been handed four generative-AI uses and asked to size the controls for each of them.
The first is staff using a public chatbot website to draft supplier emails and rewrite product copy. Nobody procured it. It arrived one browser tab at a time, and the first anyone in security heard of it was a marketing deck that mentioned it in passing.
The second is the helpdesk product the support team already pays for, which has switched on AI features: ticket summarisation, suggested replies, sentiment tagging. Same vendor, same contract, new capability, and an admin console with a page of toggles nobody has read.
The third is a support assistant the retailer built itself. It runs an Amazon Bedrock model over a knowledge base of the retailer’s own returns policies, delivery windows, and product data, behind an API the customer-facing site calls.
The fourth is a variant of that assistant, fine-tuned on two years of past ticket transcripts so it answers in the house voice and understands the shorthand the support team uses.
Review has been asked for one answer per use: what do we have to do about this? Every attempt so far has collapsed into the same argument, which is whether “it’s a managed service” means the provider has it covered.
What actually matters
Every control in a generative-AI system is one of two things. Either you implement it, or you satisfy yourself that somebody else implemented it. Those are different jobs with different evidence and different failure modes. Implementing a control means writing the policy, wiring the key, turning on the log, and being able to show the configuration. Assuring yourself of somebody else’s control means reading a contract, a certification, or an attestation, and accepting that your recourse is commercial rather than technical. The dangerous state is a control that everyone believes sits in the other category, because nobody writes down the assumption that it was handled elsewhere.
Which category a control falls into is decided by how much of the stack you built, and that has almost nothing to do with how the service is billed or badged. A fully managed AWS service can leave you owning the application-layer controls entirely, because the provider is running infrastructure and weights while you are choosing what goes into the prompt, what the retrieval layer may return, and who is permitted to call any of it. Managed is a statement about operations. Ownership is a statement about which decisions are yours.
The second thing that moves with the stack is data, and specifically which of your data crosses the boundary and what it leaves behind. A prompt sent to somebody else’s service is a disclosure, whatever the terms say afterwards. A document embedded into an index is a copy that now lives in a store you are responsible for. A ticket transcript used for tuning stops being a record and becomes part of an artefact that can repeat its contents back to a stranger. Each of those artefacts, the index, the prompt library, the invocation logs, the custom model, gets created, encrypted, versioned, audited, and eventually deleted, and each one is yours from the moment it exists. A use that generates none of them leaves you with policy and vendor management. A use that generates four leaves you with four lifecycles.
Scoping wrong is expensive in both directions. Scope too wide and a review burns weeks producing control evidence for things you do not run and cannot change. Scope too narrow and the gaps are silent, which is worse, because the assumption that the provider handles it never appears in a document anybody reviews. The classification also applies per use rather than per organisation. This retailer runs four uses that land in three different places, and one team is expected to hold all of them at once.
What we’ll filter on
- Weights: who chose, trained, and holds the model weights?
- Application: who owns the prompts, the retrieval corpus, the tool calls, and the interface the user talks to?
- Data crossing: does your data leave your boundary, and does any of it persist on the far side?
- Artefacts: does the use create something you have to govern for a whole lifecycle, such as an index, a log store, or a custom model?
- Mechanism: can you implement the control yourself, or can you only request assurance and evidence for it?
The landscape
AWS publishes a Generative AI Security Scoping MatrixAWS’s five-scope classification for generative-AI use, running from a consumer app you only use (Scope 1) to a model you trained from scratch (Scope 5), which decides how many of the security controls are yours to implement rather than assure. for exactly this classification. It sorts a use into one of five scopes by how much of the stack the user owns, and then asks the same five discipline questions at whichever scope the use landed in. The scopes run from owning almost nothing to owning everything.
Scope 1 is a consumer application. Somebody uses a public generative-AI service through its own interface, under its own terms of use, with no contract negotiated for the purpose. The retailer’s staff drafting supplier emails on a public chatbot site sit here. The provider owns the model, the application, the data handling, and the retention policy. What the retailer owns is who is allowed to use it and what they are allowed to put in it, and neither of those is a technical control inside the service.
Scope 2 is an enterprise application. A business application procured under a contract has generative-AI features built into it, and those features run on models the vendor selected and hosts. The helpdesk product with AI summarisation sits here. The vendor still owns the model and the application, but now there is a contract, a data processing agreement, an admin configuration surface, a tenancy model to ask about, and usually an audit log the retailer can export. The controls are mostly the vendor’s, but the assurance is contractual instead of a click-through, and some configuration genuinely belongs to the customer.
Scope 3 is a pre-trained model. You build an application against a foundation model somebody else trained, reached through an API. The Bedrock support assistant sits here, and it is the placement teams get wrong most often. The provider owns the weights and the hosting. Everything else belongs to the retailer: the prompts, the knowledge base and its contents, the retrieval layer and what it is permitted to return, the identity and access controls on the model call, the guardrails, the invocation logs, the encryption keys on all of it, and the application’s own behaviour when someone tries to talk it into misbehaving. Bedrock being an AWS-managed service moves none of that.
Scope 4 is a fine-tuned model. Everything in Scope 3, plus your data has now shaped the weights. The tuned variant trained on ticket transcripts sits here. The additions are specific: the training dataset is a governed asset with its own provenance, consent, and retention questions; the resulting custom model is an artefact that may have memorised what went into it; and both need encryption, versioning, access control, and a deletion story. The base weights are still the provider’s, which is why this is a step up from Scope 3 rather than a leap to owning the model outright.
Scope 5 is a self-trained model. You train from scratch on your own data and own the entire lifecycle, from corpus curation through training runs to serving and monitoring. Nothing the retailer runs is here, and for most organisations nothing ever will be, but the scope exists so the top of the range is named.
Across all five, the matrix asks the same five discipline questions. Governance and compliance: which policies, standards, and obligations does this use fall under, and who signs off. Legal and privacy: what do the terms actually say about your data, and what do your own privacy commitments require. Risk management: what are the threats specific to this use, and what is the impact if they land. Controls: which technical and procedural controls apply, and who runs each one. Resilience: what happens when the provider changes the model, degrades, or goes away. The scope does not change the questions. It changes who has to answer them and whether the answer is a configuration or a clause.
Evaluation
Side by side
| Scope | This retailer’s use | Owns the weights | Owns the app | Data leaves the boundary | Creates artefacts you govern | Controls you implement |
|---|---|---|---|---|---|---|
| 1. Consumer app | Public chatbot for drafting | ✗ | ✗ | ✓ | ✗ | ✗ (policy and monitoring only) |
| 2. Enterprise app | Helpdesk with AI features | ✗ | ✗ | ✓ | ✗ (vendor holds them) | ✓ (configuration and access) |
| 3. Pre-trained model | Bedrock support assistant | ✗ | ✓ | ✓ (to the model API) | ✓ (index, prompts, logs) | ✓ (everything but the weights) |
| 4. Fine-tuned model | Tuned variant on transcripts | ✗ (base) / ✓ (custom) | ✓ | ✓ | ✓ (plus training set and custom model) | ✓ (plus training-data governance) |
| 5. Self-trained model | None | ✓ | ✓ | ✗ | ✓ (everything) | ✓ (everything) |
Read down the last two columns and the gradient is monotone. Each scope adds artefacts you have to govern and controls you have to run, and takes away somebody you can ask instead. The first two columns are what people reach for when they classify by service tier, and they are the two that matter least: Scope 2 and Scope 3 have identical answers there, and completely different answers everywhere else. What separates them is who built the application, which is why “the vendor hosts it” settles nothing.
Where a workload lands
The gates are ordered so the cheapest question comes first. Whether you built the application is usually answerable in a sentence, and it splits the four workloads into the two where security’s job is largely policy and procurement, and the two where security’s job is the whole application. Only then is it worth asking what your data did to the weights, because that question only has consequences on the side where you own the application in the first place.
The solution
The public chatbot is Scope 1, and the honest position is that the retailer implements almost nothing inside it. What it owns is the perimeter around it: an acceptable-use policy that says which categories of information may never be pasted into an external service, awareness training that makes the rule land, and egress monitoring or a browser control that turns the policy into something observable. There is no contract to negotiate, no tenancy to isolate, no log to export, and no deletion request to serve. Legal and privacy is the discipline that carries the weight here, and the mitigating decision available is whether to sanction the tool at all or replace it with something inside a scope the retailer can actually control.
The helpdesk product is Scope 2, and the work is procurement-shaped with a technical tail. The contract and data processing agreement decide whether ticket contents may be used to improve the vendor’s models, how long they are retained, where they are processed, and what happens on termination. The admin console decides which AI features are on, for which agents, over which ticket queues. Tenancy is a question to ask rather than a control to configure, and the answer belongs in the risk register either way. What the retailer can implement is access control on the feature, an export of the vendor’s audit log into its own audit trail, and a review cadence for when the vendor changes the underlying model without asking.
The Bedrock assistant is Scope 3, and this is where the control list stops being short. The retailer owns identity and model access, the private network path, and the keys on every persistent store, which is the four-plane job on its own, with customer-managed keys on the knowledge base, the vector index, and the invocation logs. It owns what the retrieval layer is allowed to return, which is where permission-safe retrieval belongs rather than in the prompt. It owns the guardrail configuration, the defence against instructions that arrive inside retrieved documents, and the controls that stop the model becoming an exfiltration path. It owns keeping personal data out of prompts and logs, and it owns which teams may reach which models as more services start calling Bedrock. The provider owns the weights and the hosting, and that is the whole of what the retailer gets to assume rather than verify. Resilience is the discipline teams skip here, and the concrete version of it is having a plan for the day the model version behind the assistant is deprecated.
The tuned variant is Scope 4, which is the Scope 3 list unchanged plus a new set of obligations that arrive with the training data. Two years of ticket transcripts are customer records, so provenance, lawful basis, and retention all apply before a single tuning job runs, and the personal data in them has to come out during dataset preparation rather than being trusted to a guardrail afterwards. The dataset itself becomes a governed artefact with its own storage, encryption, and access list. The resulting custom model is another, and it needs a customer-managed key, a version history, and an owner, because a tuned model can surface fragments of what it was trained on and evaluation has to test for that specifically. Serving it also changes the operational shape, since a custom model needs provisioned throughput rather than the on-demand pool. None of the Scope 3 controls go away; the tuning adds a second lifecycle beside them.
One thing the scope does not tell you is how hard to press. Scope sizes ownership, not risk. Two Scope 3 applications, one summarising internal meeting notes and one reading invoices and account history back to customers, own exactly the same control list and deserve very different intensity on every item. Data classification and blast radius decide how strong each control has to be. The matrix decides which controls are on the list and whose name is against each one, and it is worth doing first, because sizing a control you do not own is wasted effort and skipping one you do own is the finding that shows up in an incident.
Worked example
A customer asks for their data to be deleted
The same request, four answers, and the differences are entirely a function of scope.
For the public chatbot, the retailer cannot serve the request inside the service, because it has no administrative relationship with it and no way to identify what staff pasted in. The answer is the reason a Scope 1 use is a poor place for customer data, and the remediation is the policy, not a deletion workflow.
For the helpdesk product, the request goes to the vendor under the data processing agreement, and the retailer’s job is to raise it, track it, and hold evidence that it was actioned. Whether the AI features left a derived copy anywhere, such as summaries attached to closed tickets, is a question the contract should already have answered.
For the Bedrock assistant, the retailer serves the request itself. The customer’s records are deleted from the source system, the knowledge base is re-synced so the embedded copies go with them, and the invocation logs are handled under whatever retention rule was set, since prompts and completions can quote the record even after the record is gone.
For the tuned variant, everything above applies and then the hard part starts. If the customer’s transcripts were in the tuning set, the tuning set has to be corrected and the model retrained or rolled back to a version that never saw them, because there is no delete operation on a set of weights. That obligation exists from the moment the tuning job runs, which is a reason to strip identifiers before tuning rather than after a request arrives.
The provider retires the model version
For Scope 1 and Scope 2, the retailer finds out when the output changes. The mitigation is a review cadence and a contractual notice period, and the risk register should say plainly that the model behind the feature can change without a change on the retailer’s side.
For Scope 3, the retailer gets a deprecation notice, a window, and a target version, and it owns the regression testing that says whether prompts and guardrails still behave. That is a scheduled piece of engineering work rather than a surprise.
For Scope 4, the base model moving means the tuning has to be redone against the new base, and the evaluation set that proved the old custom model was safe has to be run again against the new one. The custom model is an asset with a dependency on somebody else’s release calendar, which is a resilience question worth answering before the notice arrives rather than after.
What’s worth remembering
- The Generative AI Security Scoping Matrix sorts a use by how much of the stack you own: Scope 1 consumer app, Scope 2 enterprise app with AI features, Scope 3 an application you built on a pre-trained model, Scope 4 that model fine-tuned on your data, Scope 5 trained from scratch.
- Building on Bedrock is Scope 3, not Scope 2. The service being managed by AWS says nothing about who owns the prompts, the retrieval corpus, identity, guardrails, keys, and logs, and all of those are yours.
- Fine-tuning moves a use to Scope 4 and adds obligations rather than replacing them: training-data provenance and consent, the dataset as a governed artefact, and a custom model that can memorise what went into it.
- Every scope gets the same five discipline questions, covering governance and compliance, legal and privacy, risk management, controls, and resilience. What changes is whether the answer is a configuration you make or a clause you rely on.
- Scope the use before sizing its controls. Under-scoping leaves gaps nobody wrote down because everyone assumed the provider had them.
- Scope sizes ownership, not intensity. Two applications in the same scope with different data classifications own the same control list and deserve very different strength on each item.