Tools only work when people use them consistently, so AI governance also needs processes: written policies, people responsible for decisions, regular reviews, clear documentation and training. AWS's guidance adds a framework for deciding how much security work a generative AI use case needs, the Generative AI Security Scoping Matrix. The exam tests whether you can pick the right process for a scenario and place a use case in the right scope.
Policies
A governance policy turns principles into rules people can follow. AWS's guidance for generative AI recommends clear policies and procedures for model access and usage, covering things like which models may be used, what data may go into them and how outputs are checked. A common example is a data-usage rule that bans pasting personal, confidential or proprietary data into public generative AI apps. Policies only help if staff know them, which is why training sits alongside them.
A Governance Committee and Review Cadence
AWS recommends a dedicated model governance committee with clear roles. It develops evaluation criteria for foundation models, reviews requests to use them, and checks that use follows the organization's ethical AI principles, working with legal and compliance teams. A committee gives one consistent decision point instead of each team approving its own projects.
Governance also needs a review cadence: a regular schedule for revisiting decisions. Threats, models and regulations change, so AWS's guidance calls for regular security assessments and compliance audits, and for reviewing and updating security controls as threats evolve. Regular performance reviews check that models still meet business needs. Approving a system once at launch is not enough.
The Generative AI Security Scoping Matrix
The matrix sorts generative AI use cases into five scopes, from least to most ownership:
| Scope | What you're doing | Example |
|---|---|---|
| 1. Consumer app | Using a public third-party generative AI service | Staff using a public chatbot |
| 2. Enterprise app | Using a business app with built-in generative AI | A scheduling tool that drafts agendas |
| 3. Pre-trained models | Building your app on an existing model through an API | A support chatbot on an Amazon Bedrock model |
| 4. Fine-tuned models | Refining an existing model with your own data | A model tuned on your product documents |
| 5. Self-trained models | Training a model from scratch | An industry model built in-house |
Scopes 1 and 2 are mainly about governing what you buy: terms of service, licensing, data use and what staff may share. From scope 3 onward you're building, so you also own more of the controls, and at scopes 4 and 5 you're responsible for the training data itself. The matrix pairs each scope with security disciplines: governance and compliance, legal and privacy, risk management, controls and resilience.
Transparency Standards and Training
Transparency means documenting what an AI system is for, how it was built and where it falls short. AWS publishes AI Service Cards describing the intended uses and limitations of its own AI services, and Amazon SageMaker Model Cards let teams document their own models. AWS's guidance also recommends keeping detailed documentation of security measures and controls.
Training makes the rest work. AWS recommends security awareness training for teams that work with generative AI, and training programs that cover both technical skills and responsible AI practices.
On the Exam
Match the process to the problem. Ad hoc model launches point to a governance committee with clear criteria. Staff leaking data into public chatbots points to a usage policy plus training. Controls approved long ago point to a regular review cadence. For the scoping matrix, ask who built the model and whose data shaped it.