9.1 SageMaker Model Cards & AI Governance Frameworks
Key Takeaways
- The customer governance resource is SageMaker Model Cards, not an invented Bedrock Model Cards resource.
- Substantive card edits create new versions, preserving prior governance evidence.
- Model cards document controls; they do not enforce runtime authorization, safety, or deployment policy.
9.1 SageMaker Model Cards & AI Governance Frameworks
Model cards document what a model is, how it was evaluated, where it should be used, and which limitations and controls apply. The customer-managed AWS resource is Amazon SageMaker Model Cards; Amazon Bedrock does not expose a similarly named model-card resource. Bedrock publishes provider information for available models, while a development team that needs its own governed artifact can create a SageMaker Model Card, including for a model that was not trained in SageMaker AI.
What a useful model card records
A card should identify the exact model or deployment target, owner, business purpose, intended users, approved uses, prohibited uses, risk rating, data provenance, evaluation evidence, safety controls, monitoring plan, and review status. For a Bedrock application, custom fields can reference the foundation model ID or inference profile, Prompt Management version, Guardrail version, Knowledge Base, retrieval dataset, tool set, and deployment configuration.
| Governance question | Evidence to record |
|---|---|
| What is being approved? | Model ID and version, customization artifact, prompt version, retrieval and tool dependencies |
| What may it do? | Intended users, business process, permitted actions, human-review boundaries |
| What must it not do? | Unsupported languages, prohibited decisions, autonomous actions, regulated-data restrictions |
| How was it tested? | Dataset version, metrics, judge or human-review method, safety and adversarial results |
| How is it controlled? | IAM role, Guardrail, network boundary, encryption, logging and retention choices |
| When is review required? | Expiration date, drift trigger, incident trigger, model or data change trigger |
Do not claim that a model card itself enforces policy. It is documentation and an approval record. IAM, network policies, Guardrails, workflow gates, and application validation implement controls. The card helps reviewers verify that those controls exist and that their limitations are understood.
SageMaker Model Cards behavior
SageMaker Model Cards integrate with SageMaker Model Registry. When the associated model was created in SageMaker AI, supported details can be populated from the model. A card can also describe a model created elsewhere, but the team supplies the information manually. That makes the resource useful for governing a Bedrock-based solution even though the Bedrock foundation model is not a SageMaker training job.
Model-card versions support auditability. Current SageMaker documentation explains that changing card content other than approval status creates another version, preserving the earlier record. Cards can be exported to PDF for review. The organization should still retain machine-readable evidence and source artifacts; a PDF alone is not a deployment control or a reproducible evaluation.
Approval status should correspond to a defined workflow such as Draft, Pending Review, Approved for Staging, Approved for Production, or Rejected. Separate model quality approval from application approval when retrieval, prompts, and tools materially change behavior. An approved base model does not automatically approve every application that invokes it.
Minimum viable governance record
For a customer-support assistant, the card might identify the selected Bedrock target, approved languages, internal users, prohibited autonomous refunds, retrieval corpus owner, Guardrail version, evaluation dataset, safety thresholds, and requirement for human approval above a refund amount. Attach an evaluation report by controlled S3 URI and record the release owner and next review date.
Avoid vague fields. 'Use responsibly' is not an operational boundary. 'May draft refund recommendations; may not invoke the payment tool; a service agent approves every refund' is testable. Likewise, 'high accuracy' should become a named dataset, metric, threshold, failed-slice review, and date.
When the model target changes, create a new evaluated release and update the card version. When only approval status changes, follow the model-card status workflow. Keep the application deployment record separate enough to show which approved card version was actually active at a given time.
A card for a third-party or Bedrock-hosted model will not auto-populate all details. Supply the provider information, application-specific evaluation, and controls manually, and distinguish provider claims from results the organization verified.
Relationship to Model Registry
Model Registry catalogs deployable model versions and their artifacts, metadata, and approval status. A model card adds structured documentation about purpose, risk, training, evaluation, and limitations. Link them when SageMaker resources are involved, but do not treat them as interchangeable. A Bedrock application can reference its external model target in a card even when no SageMaker model package is deployed.
Model cards should also state who may change approval status and which evidence is mandatory for that transition. Restrict the API accordingly and audit status changes through the organization's change process.
Which AWS resource can a team use to maintain its own versioned governance record for a Bedrock-based model application?