Security, compliance and governance for AI solutions on AWS

An AI system is an ordinary cloud application with three unusual assets inside it: a training dataset that may contain the most sensitive records the company holds, a model that encodes them and can be stolen or coaxed into revealing them, and a prompt channel that lets untrusted text drive privileged actions. Securing it means the usual AWS discipline (identity, encryption, network isolation, detection) plus controls for those three assets, and governing it means being able to show an auditor where the data came from, who could touch it, and which standard the whole thing was measured against. This article is Domain 5 of the exam, fourteen percent of the questions, and it is the domain with the most service names per page; the tables are the point. It leans on the responsible AI article for bias and transparency, on the Bedrock article for Guardrails, and on the prompt engineering article for the mechanics of prompt injection.

The map

Read this first when short on time. Every branch is a section below.

Shared responsibility: what AWS secures and what you secure, for Bedrock, SageMaker and EC2

The AWS shared responsibility model says AWS is responsible for security of the cloud (the facilities, hardware, network and the managed service software) and the customer is responsible for security in the cloud (data, identities, configuration, and whatever software the customer runs), and for AI the line moves depending on how much of the stack is managed.

Three ways to run a model on AWS put the line in three different places:

flowchart TD
  A["Always AWS<br/>regions, hardware, network, hypervisor"]
  B["Bedrock adds to AWS's side<br/>OS, model server, model weights, scaling, patching"]
  S["SageMaker adds to AWS's side<br/>OS and instance lifecycle only"]
  E["EC2 adds nothing<br/>customer owns OS, drivers, model server, weights"]
  C["Always the customer<br/>IAM, data, prompts, keys, guardrails, logging, compliance evidence"]
  A --> B --> C
  A --> S --> C
  A --> E --> C

Two Bedrock facts sit at the heart of many questions. First, Bedrock does not use customer prompts, completions or fine-tuning data to train the base models, and does not share them with the model providers; a customised model is a private copy in the customer's account. Second, Bedrock does not store prompts and completions unless the customer turns on model invocation logging, so the customer decides where (S3, CloudWatch Logs) and for how long that record exists. The responsibility for what the model is asked and what it says is entirely the customer's, which is why Guardrails and human review appear on the customer side of every column.

security of the cloud

What AWS protects: physical sites, hardware, the network, virtualisation, and the software of managed services.

security in the cloud

What the customer protects: data, identities and permissions, configuration, guest operating systems where they own them, and application code.

customised model

In Bedrock, a fine-tuned or continued-pre-training copy of a foundation model, stored encrypted in the customer's account and never visible to other customers or the provider.

Identity and access: IAM roles, policies and least privilege for AI workloads

AWS Identity and Access Management (IAM) decides which principal may call which API on which resource, and for AI systems the practical questions are which role a training job or an endpoint runs as, who may invoke which model, and how to make both as narrow as possible.

The pieces

A principal is an identity making a request: an IAM user, a federated person, or a role assumed temporarily by a person or a service. A policy is a JSON document of allow and deny statements on actions, resources and conditions. Everything is denied unless a policy allows it, and an explicit deny beats any allow. Least privilege is the rule that a principal gets only the actions and resources it needs, for only as long as it needs them, and it is the phrase the exam uses to mark the correct answer.

The roles an AI application actually uses

1. SageMaker execution role. Every notebook, training job, processing job, pipeline and endpoint runs as a role you hand to SageMaker. It needs read on the training data, write on the output location, pull on the container image, and use of the KMS key; it does not need AmazonSageMakerFullAccess, which is the managed policy people attach in a hurry and auditors find later.
2. Bedrock invocation. The application's role gets bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream on specific foundation-model ARNs (and on an inference profile if cross-region inference is used). Model access is enabled per account and per region, and IAM condition keys can require that a named guardrail be applied to every call, so the policy itself enforces the safety layer.
3. Agent and knowledge base roles. A Bedrock agent runs as a role that may invoke its model and its action-group Lambda functions and nothing else; a knowledge base's role may read its S3 source and write to its vector store. Excessive agency, one of the LLM threats below, is prevented mostly by keeping these roles small.
4. People. Humans should come through AWS IAM Identity Center (the successor to AWS SSO): workforce identities from the corporate directory, permission sets mapped to roles, and short-lived sessions. SageMaker Studio domains and Amazon Q Business both authenticate users through it, so a leaver disabled in the directory loses the notebook and the assistant at once.

flowchart TD
  P["Person via IAM Identity Center<br/>permission set, short-lived session"]
  S["SageMaker Studio and jobs<br/>run as the execution role"]
  D["Training data bucket<br/>bucket policy allows only that role"]
  K["KMS customer managed key<br/>key policy allows only that role"]
  A["Application role<br/>InvokeModel on two model ARNs, guardrail required"]
  B["Amazon Bedrock<br/>model access enabled in this region"]
  P --> S
  S --> D
  S --> K
  A --> B
  P -. "deploys" .-> A

role

An IAM identity with permissions but no long-term credentials; a person or a service assumes it and receives short-lived keys.

execution role

The role SageMaker assumes on your behalf to run a job or an endpoint. Its permissions are the job's permissions.

SCP

Service control policy: an AWS Organizations policy that caps what any principal in an account may do. It grants nothing by itself; it only limits.

Encryption: KMS, customer managed keys, at rest and in transit

Encryption at rest protects stored data (buckets, volumes, model artefacts, vector stores) with keys managed in AWS Key Management Service (KMS), and encryption in transit protects data moving between components with TLS; on AWS the first is a configuration choice per resource and the second is the default on every service API.

Keys and who holds them

KMS offers three tiers of key. AWS owned keys belong to the service and are invisible to you; many services use them by default. AWS managed keys (aws/s3, aws/sagemaker) live in your account, are used automatically by the service, and show up in CloudTrail, but you cannot change their policy. Customer managed keys (CMKs) are created by you: you write the key policy, control grants, enable rotation, can disable or schedule deletion, and every use is a CloudTrail event naming the caller. Regulated workloads use CMKs because "we can revoke access to the data by disabling the key" is a control an auditor understands, and because the key policy is a second lock, independent of IAM, on the data it protects.

CMK

Customer managed key in KMS: created, governed and audited by the customer, usable by services only through its key policy and grants.

envelope encryption

Data is encrypted with a data key, and the data key is encrypted with the KMS key. KMS never sees the data; the service never stores the plaintext data key.

SSE

Server-side encryption: S3 encrypts the object when it is written and decrypts it when it is read, using S3 keys (SSE-S3), KMS keys (SSE-KMS) or a key you supply (SSE-C).

Network isolation: VPC, PrivateLink and the front door

Network isolation keeps the model, the data and the application on private addresses, reached only over paths you allow: a VPC with private subnets and security groups for what you host, interface VPC endpoints (AWS PrivateLink) for the managed services you call, and a hardened public entry point for the users.

Private paths to managed services

By default, a call to Bedrock or SageMaker goes to a public AWS endpoint over the internet (encrypted, but public). An interface VPC endpoint puts a private IP for the service inside your subnet, so the call stays on the AWS network; the endpoint's own policy can restrict which APIs and which resources may be reached through it, and the security group on it limits who in the VPC may use it. Bedrock has endpoints for the control plane (bedrock), the runtime (bedrock-runtime) and the agent runtime; SageMaker has them for the API, the runtime (invoking endpoints), Studio and the feature store. S3 gets a gateway endpoint. With those in place a workload in a subnet with no internet route can train, invoke models and read data.

SageMaker adds isolation of its own: a Studio domain or notebook can be created in VPC-only mode with direct internet access disabled, so all traffic flows through the endpoints; training and inference containers can run with network isolation, meaning no outbound network calls at all, which also guarantees an untrusted third-party container cannot exfiltrate data.

The front door

Users reach a generative AI application through an ordinary web front, and it is protected in the ordinary way: Amazon CloudFront or an Application Load Balancer, AWS WAF for request filtering and rate limiting (which is also the first line against prompt-flooding and unbounded consumption), AWS Shield for DDoS protection (Standard is automatic, Advanced is paid and adds response support), and Amazon API Gateway with authorisation (Cognito, IAM or a Lambda authoriser) in front of the Lambda or container that builds the prompt. Secrets the application needs come from Secrets Manager at run time.

flowchart TD
  U["Users"]
  W["CloudFront with WAF and Shield<br/>rules, rate limits, DDoS protection"]
  G["API Gateway<br/>authorisation, throttling"]
  L["Lambda in a private subnet<br/>application role, builds the prompt"]
  E["Interface VPC endpoint<br/>bedrock-runtime over PrivateLink"]
  B["Amazon Bedrock<br/>guardrail applied on every call"]
  K["KMS customer managed key<br/>knowledge base and logs"]
  T["CloudTrail and invocation logging<br/>who called, what was asked and answered"]
  S["Secrets Manager<br/>third-party keys at run time"]
  U --> W --> G --> L --> E --> B
  L --> S
  B --> K
  B --> T

interface VPC endpoint

An elastic network interface in your subnet with a private IP that fronts an AWS service through PrivateLink. Has its own security group and endpoint policy.

gateway endpoint

A route-table entry that sends S3 or DynamoDB traffic over the AWS network; no ENI, no charge.

security group

A stateful, instance-level firewall: allow rules only, applied to ENIs including endpoint ENIs.

Sensitive data: finding it, protecting it and engineering it securely

Secure data engineering for AI means knowing what sensitive data you hold before it reaches a model, reducing it with privacy-enhancing techniques, controlling who may read what at column and row level, checking its quality, and guaranteeing its integrity from source to training set.

Finding sensitive data

Amazon Macie is the discovery service for Amazon S3: it uses machine learning and pattern matching to find personally identifiable information (names, addresses, national IDs, card numbers), financial data, credentials and secrets in objects, runs one-off or scheduled discovery jobs or continuous automated sensitive data discovery across the account, and publishes findings to Security Hub and EventBridge. It is the answer for "which buckets contain PII" before a training set is assembled. Amazon Comprehend finds PII inside a piece of text (an API call on a document or a batch job over many), and can redact it; it is the answer for a text pipeline or a prompt. Guardrails for Amazon Bedrock handles PII in model traffic at inference. The three are often confused; the table under threat detection below settles the split.

Privacy-enhancing techniques

Anonymisation and pseudonymisation are the two the exam most often contrasts: anonymised data is no longer personal data under GDPR and falls outside it; pseudonymised data is still personal data, because the mapping exists, and stays regulated.

Access control on data

Three layers stack. IAM and S3 bucket policies decide who may read a bucket or prefix. AWS Lake Formation adds fine-grained permissions on catalogued tables: column-level (hide the salary column), row-level (a region's analysts see only their rows) and cell-level, granted to principals or through LF-tags on tables and columns, and enforced across Athena, Redshift Spectrum, EMR and Glue. Amazon DataZone sits above as a business catalogue where data owners publish data products and consumers subscribe with an approval step, so access is granted by a workflow rather than a ticket to an administrator.

Quality and integrity

Data quality assessment is a security practice as much as a modelling one, because poisoned or corrupted data is a security failure: AWS Glue Data Quality evaluates rules (completeness, uniqueness, ranges, freshness, custom SQL) on tables and pipelines and can stop a job that fails them; Glue DataBrew profiles a dataset visually; SageMaker Data Wrangler reports on a data flow. Data integrity is the guarantee that what was trained on is what was collected: S3 checksums (SHA-256, CRC and others computed on upload and verifiable on download), S3 versioning so an overwrite never destroys the original, S3 Object Lock for write-once-read-many immutability with governance or compliance mode and legal holds, and dataset versioning (a manifest, a hash, or a SageMaker Feature Store version) recorded in the model card.

PII

Personally identifiable information: anything that identifies a person alone or in combination. Health data (PHI) and card data (PCI) are regulated subsets.

WORM

Write once, read many: storage that refuses modification or deletion for a retention period. S3 Object Lock implements it.

LF-tag

A Lake Formation tag attached to databases, tables or columns; permissions granted on the tag apply to everything carrying it.

Threat detection and vulnerability management around the AI stack

The detection services do for an AI application what they do for any other workload: GuardDuty watches for malicious activity, Inspector finds vulnerabilities in the software you run, Security Hub aggregates findings against standards, and WAF and Shield defend the edge; the AI-specific part is knowing which one covers which layer of the model pipeline.

Two of these tend to be mixed up: Inspector finds weaknesses in software you deploy (a vulnerable library in the container), GuardDuty finds someone exploiting your account (an API call pattern that looks like an attacker). Config, which appears in the governance section, is a third thing again: it finds mis-configuration (an unencrypted endpoint). The three together are vulnerability, threat and configuration.

CVE

Common Vulnerabilities and Exposures: the public identifier for a known software vulnerability. Inspector reports them with a severity score.

finding

A single detected issue with a severity, a resource and a recommendation, in the common format Security Hub aggregates.

Threats specific to AI systems, and the OWASP Top 10 for LLM applications

Beyond ordinary application security, an AI system has attacks aimed at the training data, the model itself and the prompt channel, and the OWASP Top 10 for LLM Applications and MITRE ATLAS are the two catalogues that give them names.

Against the model and its data

Against the application: the OWASP Top 10 for LLM applications

The OWASP Top 10 for Large Language Model Applications (2025 edition) lists the risks builders most often ship. Each pairs naturally with an AWS control:

1. LLM01 Prompt injection. Untrusted text (a user message, or a document the model reads) alters the model's behaviour. Guardrails' prompt-attack filter, separating instructions from data, least-privilege tools. Detail in the prompt engineering article.
2. LLM02 Sensitive information disclosure. The model reveals PII, secrets or proprietary data from its training set or context. Redact before training and retrieval; Guardrails sensitive-information filters; document-level access control in RAG.
3. LLM03 Supply chain. Compromised models, datasets, plugins or libraries. Trusted sources, Inspector, provenance.
4. LLM04 Data and model poisoning. As above.
5. LLM05 Improper output handling. Model output is passed unchecked into a browser, a shell or a database (cross-site scripting or injection via the model). Treat output as untrusted input; encode, validate, parameterise.
6. LLM06 Excessive agency. An agent has more tools, permissions or autonomy than the task needs and is talked into misusing them. Narrow action groups, narrow roles, confirmation for consequential actions, human approval steps.
7. LLM07 System prompt leakage. The system prompt, and any secret in it, is extracted. Keep secrets out of prompts; assume the prompt is public; enforce rules in code, not only in the prompt.
8. LLM08 Vector and embedding weaknesses. Poisoned or over-shared vector stores; embeddings inverted back to text. Access control on the store, per-document permissions, ingestion validation.
9. LLM09 Misinformation. Hallucinated or wrong output relied on. Grounding, citations, contextual grounding checks, human review.
10. LLM10 Unbounded consumption. Denial of service or denial of wallet through unlimited requests or tokens. WAF rate limits, API Gateway throttling, Bedrock quotas, per-caller token budgets, CloudWatch spend alarms.

MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) is the companion catalogue in the style of MITRE ATT&CK: a matrix of tactics and techniques used against machine learning systems, with real case studies, used by security teams to threat-model a model the way they already threat-model a network.

flowchart TD
  D["Training data and documents<br/>poisoning, supply chain"]
  M["Model and vector store<br/>theft, inversion, membership inference, embedding leaks"]
  P["Prompt channel<br/>injection, jailbreaks, system prompt leakage"]
  O["Output<br/>improper handling, sensitive disclosure, misinformation"]
  T["Tools and agents<br/>excessive agency"]
  R["Resources<br/>unbounded consumption"]
  D --> M --> P --> O --> T
  P --> R

jailbreak

A prompt designed to make the model drop its safety behaviour; a prompt injection aimed at the safety rules rather than the task.

excessive agency

An LLM-driven component with more permissions, tools or autonomy than its task requires, so that a manipulated model can do real damage.

denial of wallet

An attack that runs up the victim's bill (tokens, invocations) rather than taking the service down.

Knowing where data came from: lineage, catalogues and citations

Data lineage is the recorded path from a source system through every transformation to a training set, a model and a prediction, and it is what lets you answer "where did this come from" for a regulator, "what is affected" after a breach, and "which documents support this answer" for a user.

AWS splits the job across several services, each holding one kind of record:

• AWS Glue Data Catalog holds technical metadata: databases, tables, schemas, partitions and locations, populated by crawlers or by Glue jobs, and used by Athena, Redshift Spectrum, EMR and SageMaker. It is the inventory of what data exists and what shape it is in.
• Amazon DataZone is the business catalogue on top: data products with owners, descriptions, glossary terms and quality indicators, published into a domain, and subscribed to through an approval workflow. It records who asked for what data and who approved it.
• AWS Lake Formation governs permissions on the catalogued data and records grants; with the catalog it answers "who could read this table on this date".
• Amazon SageMaker ML Lineage Tracking records the graph of artefacts (datasets, images, models), actions (processing, training, deployment) and contexts (experiments, endpoints) as pipelines run, so a model version can be traced back to the exact dataset version and code that made it. SageMaker Feature Store versions features by time, so a training set can be reconstructed as of a date.
• SageMaker Model Cards summarise the lineage for people: training data sources, evaluation datasets, intended use, as the responsible AI article describes.
• Amazon Bedrock Knowledge Bases return citations, the retrieved passages and their source locations, with each answer, which is lineage at the level of a single generated response, and the reason a user can verify it.

flowchart TD
  S["Source systems<br/>databases, logs, documents, third-party data with licences"]
  I["Ingestion and transformation<br/>Glue jobs, DataBrew, quality rules, PII redaction"]
  C["Glue Data Catalog and DataZone<br/>schema, owner, terms, approvals, Lake Formation grants"]
  F["Feature Store or versioned S3 dataset<br/>checksums, Object Lock, point-in-time"]
  T["Training and evaluation<br/>ML Lineage Tracking records dataset, code, image"]
  R["Model Registry and Model Card<br/>version, approval, data sources, metrics"]
  E["Endpoint or Bedrock application<br/>invocation logs, citations back to sources"]
  S --> I --> C --> F --> T --> R --> E

Provenance also has a legal edge. Datasets and models come with licences (Creative Commons variants, research-only terms, model licences with acceptable-use clauses) and consent conditions; recording them in the catalogue at ingestion is what makes "may we fine-tune on this" answerable later. The same record is the mitigation for the intellectual-property risk in the previous article.

lineage

The recorded chain of sources, transformations and consumers for a piece of data or a model.

provenance

Where data originally came from and under what terms: the source, the licence, the consent, the date.

data product

In DataZone, a published, owned, documented dataset that consumers subscribe to rather than copy.

Standards and laws: ISO, SOC, the EU AI Act, NIST and the sector rules

Compliance standards are the external yardsticks an AI system is measured against: management-system standards that certify how an organisation runs, audit reports that attest to controls, and laws that decide what an AI system may do and how it must be explained.

The exam does not test the clauses. It tests which named standard fits which sentence: an AI management system is ISO 42001, a security management system is ISO 27001, an auditor's report on controls is SOC 2, a law that tiers AI systems by risk is the EU AI Act, a voluntary framework for managing AI risk is the NIST AI RMF, and healthcare, payment and personal data have their own acronyms.

Two ideas tie the list together. First, AWS's compliance covers the cloud: its ISO, SOC and PCI attestations say the infrastructure and the managed services meet the standard, and the customer still has to make what they build on top compliant, which is the shared responsibility model from the top of this article again. Second, "algorithm accountability laws" is the exam guide's umbrella term for laws such as the EU AI Act and municipal rules that require organisations to assess, document and explain automated decisions, and in a question that phrase points at documentation tools: Model Cards, impact assessments, audit trails.

management-system standard

A standard, such as ISO 27001 or 42001, that certifies how an organisation governs a subject rather than a single product.

attestation report

An independent auditor's report, such as SOC 2, that controls were designed and operated as described.

business associate agreement

The HIPAA contract under which a cloud provider may handle protected health information for a covered entity.

Governance services: Config, Inspector, Audit Manager, Artifact, CloudTrail and Trusted Advisor told apart

Six AWS services carry the governance and compliance load on the exam, and every question about them comes down to matching a verb (record, scan, collect, hand over, log, advise) to the right name.

flowchart TD
  Q([What does the scenario need?]) --> A{Records?}
  A -- "API calls, who did what" --> CT["AWS CloudTrail"]
  A -- "resource settings over time" --> CF["AWS Config"]
  A -- "neither" --> B{Findings?}
  B -- "software vulnerabilities" --> IN["Amazon Inspector"]
  B -- "best-practice gaps, quotas" --> TA["AWS Trusted Advisor"]
  B -- "neither" --> C{Audit?}
  C -- "collect our evidence" --> AM["AWS Audit Manager"]
  C -- "AWS's own reports" --> AR["AWS Artifact"]

A second ring of services sets the guard rails around accounts rather than inside them. AWS Organizations groups accounts and applies service control policies that cap what any principal can do, which is how a company forbids Bedrock outside approved regions or blocks model providers it has not reviewed. AWS Control Tower sets up a multi-account landing zone with preventive and detective controls already wired to Config. Amazon CloudWatch holds the metrics, logs and alarms that monitoring and observation rely on. The AWS Well-Architected Framework adds a Machine Learning Lens and a Generative AI Lens: question sets for reviewing a workload against best practice, which the exam may name as "a framework for reviewing the architecture".

conformance pack

A packaged set of AWS Config rules and remediation actions that together represent a standard or an internal policy.

service control policy

An AWS Organizations policy that sets the maximum permissions for every account it is attached to; it never grants, it only limits.

Well-Architected lens

A domain-specific extension of the Well-Architected Framework's review questions; the ML and Generative AI lenses cover model workloads.

Data governance: lifecycle, logging, residency, monitoring and retention

Data governance is the set of rules about where data may live, how long it stays, who may touch it and how every touch is recorded, applied to the training data, the prompts, the outputs and the logs of an AI system alike.

flowchart TD
  C["Collect<br/>consent, classification, catalogue entry"] --> S["Store<br/>region chosen, encrypted, access controlled"]
  S --> U["Use<br/>training, retrieval, prompts, all logged"]
  U --> A["Archive<br/>lifecycle rule to cheaper storage, still governed"]
  A --> D["Delete<br/>retention expiry, legal hold lifted, evidence kept"]

1. Lifecycle. Data is collected under a stated purpose, stored with a classification, used within that purpose, archived when cold and deleted when its retention period ends. On AWS the mechanics are S3 lifecycle rules (transition to Glacier classes, expire after N days), S3 Object Lock for records that must not be altered, and Backup plans with retention.
2. Logging. Every access and every model call is recorded: CloudTrail for API activity, Bedrock model invocation logging for prompts and completions, SageMaker endpoint data capture for inference inputs and outputs, CloudWatch Logs for the application. Logs are themselves data with a retention setting.
3. Residency. Data stays in the geography the law or the contract names. AWS Regions are the unit: an S3 bucket, a SageMaker job or a Bedrock invocation lives in one Region and does not leave it unless configured to. Bedrock model availability differs by Region, and cross-region inference routes requests only within a defined geography (for example within the EU or within the US).
4. Monitoring and observation. CloudWatch alarms on error rates and latency, Model Monitor on drift, GuardDuty on threats, Config on configuration, Macie on new sensitive data appearing; observation is the human review of what those tools report, on a cadence.
5. Retention. Each class of data has a period: prompts and outputs perhaps 30 days for debugging, training datasets for as long as the model that used them is in service, audit logs for the years a regulator requires. The period is enforced by lifecycle rules, not by memory.

data residency

The requirement that data be stored and processed within a named geography.

retention period

How long a class of data is kept before deletion, set by law, contract or policy and enforced by a lifecycle rule.

cross-region inference

A Bedrock feature that routes requests across a set of Regions within one geography for capacity, without leaving that geography.

Governance processes: policies, reviews, the Scoping Matrix and the people

Governance processes are the human side of compliance: written policies that say what is allowed, reviews on a cadence that check it is still true, a framework for deciding how much scrutiny a given AI use deserves, and training so that the people building it know the rules.

Policies and review cadence

A governance policy states who may use which AI services for what, which data classes may reach a model, which models are approved, what must be logged and who signs off. A review cadence checks it: quarterly for the policy itself, at every release for a high-risk system, continuously through the automated services above. A review strategy is risk-based: a marketing copy assistant gets a light check; a model that influences credit or medical decisions gets an impact assessment, a bias audit and human oversight.

The Generative AI Security Scoping Matrix

AWS's Scoping Matrix is a way to classify a generative AI use by how much of the model is yours, because responsibility for security and governance grows with ownership. It has five scopes.

The matrix is used with five lenses at each scope: governance and compliance, legal and privacy, risk management, controls, and resilience. The point the exam wants is the direction: moving from scope 1 to scope 5, the customer's share of the shared responsibility model grows, the controls become more technical, and the documentation duties (Model Cards, lineage, evaluation records) become mandatory rather than optional.

Transparency standards and team training

Transparency standards say what a system must disclose: that a user is talking to an AI, what data it uses, how confident it is, where an answer came from, and how to reach a human. On AWS the artefacts are SageMaker Model Cards, AWS AI Service Cards for the managed services, Knowledge Base citations and Guardrails' block messages. Team training closes the loop: developers learn the policy and the OWASP list, data engineers learn classification and the privacy techniques, reviewers learn the bias metrics, and everyone learns which data may not leave the account. The AWS Cloud Adoption Framework for AI adds the organisational view, with perspectives on business, people, governance, platform, security and operations.

Generative AI Security Scoping Matrix

AWS's five-scope classification of generative AI uses, from consuming a public app to training your own model, used to decide which security and governance controls apply.

review cadence

The fixed schedule on which policies, risk assessments and controls are re-examined.

AWS CAF for AI

The Cloud Adoption Framework's AI-specific guidance on the organisational capabilities needed to adopt AI responsibly.

Recap