Exam-style
An auditor meets a team that trained its own support-ticket triage model and also calls a managed AWS service for document extraction. She asks what the triage model is for and where its output should not be trusted, what fairness considerations and limitations AWS documented for the managed service, and for evidence that AWS holds a current SOC 2 report. Which set answers all three?
Reveal the answer
C. Amazon SageMaker Model Cards for the triage model, an AWS AI Service Card for the managed service, and AWS Artifact for the SOC 2 report
Match the artefact to whoever wrote it. The team authors and versions an Amazon SageMaker Model Card alongside the triage model: intended uses and non-uses, a risk rating, training details, evaluation results and observations, and a named model owner. An AWS AI Service Card is the mirror image, published by AWS for its own AI services, covering intended use cases and limitations, responsible AI design choices such as fairness and bias, and deployment best practices. It says nothing about the triage model. AWS Artifact provides on-demand downloads of AWS security and compliance documents, SOC 1, 2 and 3 among them. Amazon Bedrock Evaluations scores responses against a prompt dataset, which is measurement, not a statement of intended use. AWS Config records how resources are configured and flags the ones that break rules you define, and AWS CloudTrail records who called which API and when. Neither is a certification. The single-card answer fails on authorship: a card the team wrote is not evidence about AWS.
Q. An auditor asks what your own triage model is for, what fairness considerations AWS documented for the managed service you call, and whether AWS holds SOC 2. Which three artefacts?
A. Amazon SageMaker Model Cards for your model, an AWS AI Service Card for the AWS service, and AWS Artifact for the SOC 2 report.
Why? Sort by author. You write the card for the model you trained, AWS writes the card for the service it sells, and AWS Artifact is where AWS’s own audit reports are downloaded on demand. A model card carries intended uses, a risk rating, training details, evaluation results and the limitations you already know about, and a named owner. A service card carries that same shape of information for a service you did not build, which is why it stands up as evidence to somebody assessing you. The near misses are worth naming. Amazon Bedrock Evaluations scores responses against a prompt dataset, AWS Config tracks resource configuration against rules, and AWS CloudTrail records account activity as events. All three are useful, and none of them documents what a model is for.
There is a fourth route to the same transparency, and it is not a document. Where a model’s weights, training data and licence terms are published, they can be read directly, so the answer comes from provenance rather than somebody’s write-up of it.