Sort transparency artefacts by who holds the pen and most of this domain sorts itself. A worked scenario runs the same three artefacts past an auditor; this card stays on the AWS-authored one. Alongside the two cards, the guide counts open source models, data, licensing among the tools to identify transparent and explainable models, and it is the one that gives answers without anyone writing a document at all. Explainability sits next door and is a different job: telling a person why a decision came out the way it did needs the reasoning behind one output, where a card describes the service in general.
Flash card
AWS AI Service Card: the transparency document AWS publishes for one of its own managed AI services or models, covering what the service is for, how it was built, and where its behaviour has limits.
- AWS writes it and AWS publishes it. You do not author a service card, you cannot edit one, and there is no console where you fill one in. They sit on the AWS site as public documents, free to read without an account, so a customer, an auditor or a regulator can read the same text you read.
- Each card covers one specific AWS AI service or model, or one use case within a service, rather than a whole product family. Face matching in Amazon Rekognition has its own card; so do Amazon Titan and Amazon Nova models on Amazon Bedrock. A service with several distinct capabilities can have several cards, because the fairness and accuracy story differs between them.
- The contents follow a set shape: the intended use cases and the ones AWS says the service is not built for, the design choices AWS made, fairness and performance considerations including how accuracy was measured and across which groups, and deployment guidance for using the service responsibly. That covers what you would otherwise have to ask an AWS engineer over a call.
- A service card documents behaviour, it does not change it. Reading one does not filter a response, gate a deployment or block a request; Amazon Bedrock Guardrails and IAM policies do that. Treat the card as evidence you cite in a risk assessment or a procurement review, and expect a scenario asking for a runtime control to name something else.
- The counterpart for a model or feature your own team builds is Amazon SageMaker Model Cards, which you author and version yourself: intended use, the data behind the model, evaluation results, and the risks and limitations you already know about. Hold the three-way distinction in one line. An AI Service Card is AWS documenting AWS. Amazon SageMaker Model Cards are you documenting your model. AWS Artifact is neither, being the console where AWS’s downloadable compliance certifications live, SOC and ISO reports among them.
Pick it when
Pick it when the scenario asks what AWS has published about a managed service you call: what it is meant for, how its accuracy varies across groups, or what AWS recommends when deploying it. It is also the honest answer when somebody outside your organisation wants transparency about a component you did not build, because a document you wrote yourself proves nothing about a service somebody else runs.
It's the wrong answer when
It is the wrong answer for your own trained or fine-tuned model, which wants Amazon SageMaker Model Cards; for a compliance certification such as SOC 2 or ISO 27001, which wants AWS Artifact; for measured scores over your prompts and your data, which wants Amazon Bedrock Model Evaluations; and for any control that has to act at request time, which wants Amazon Bedrock Guardrails or an IAM policy.