AI governance frameworks (model cards, lineage, approval): AIP-C01 study notes and practice questions
What to know about AI governance frameworks (model cards, lineage, approval) for the AIP-C01 exam, from the AI Safety, Security, and Governance domain (20% of the exam guide), then 1 free question to test it. Part of the AIP-C01 study guide.
AIP-C01 asks how an organization keeps control of the models and prompts it uses, from selection through retirement. Questions describe a team that deploys without review, cannot say what data trained a model, or cannot tell which model serves which product, and ask for the governance mechanism that fixes it.
Model cards
A model card records the intended use, the training data at a summary level, evaluation results, known limitations and the risks the owner accepted. SageMaker AI supports model cards alongside its registry, and Bedrock publishes model information for foundation models. Your own cards should cover the fine-tuned or customized model, not only the base model, and be updated with each version.
Approval before production
The SageMaker AI Model Registry tracks model versions with an approval status. A deployment pipeline should deploy only versions marked Approved, so a model cannot reach production by skipping review. For Bedrock custom models, add a manual approval step in the pipeline before creating the on-demand deployment. See SageMaker AI Model Registry.
Lineage
Lineage links a model to its inputs: which dataset, which version of it and which preprocessing ran. Use SageMaker AI lineage tracking for the training pipeline and the Glue Data Catalog for dataset metadata and schemas, so an auditor can trace a fine-tuned model back to its source data.
Risk tiers and policy mapping
Classify each use case by risk, for example low, high and regulated. Each tier maps to required controls. A high-risk use, such as credit or hiring support, needs stricter guardrails, human review and full audit logs. Turn each written policy rule into a named control with an owner, so the policy can be checked.
Central register
Keep a central inventory of models, guardrails and prompt versions with owners and status. Bedrock Prompt management versions let you tie a production answer to the exact prompt that produced it.
How to choose
Scenario wording
Choose
“Document what a model may and may not be used for”
Model card for each model version
“Only approved models reach production”
Model Registry approval status enforced by the pipeline
“Show which data trained a fine-tuned model”
Lineage tracking plus Glue Data Catalog metadata
“Different controls for high-risk use cases”
Risk tiers mapped to required controls
“Know every model and prompt in use”
Central register with prompt and model versions
Common traps
Treating a model card as a one-time form instead of updating it with each version.
Deploying a registry version without checking its approval status.
Writing governance in a policy document only. Governance needs technical enforcement such as pipeline gates and IAM.
Assuming the base model’s documentation covers your fine-tuned model. Your customization changes behavior.
Recording lineage only for the final model, not the datasets and preprocessing steps.
An HR technology company sells a candidate screening assistant that ranks applicants with a model hosted on Amazon SageMaker AI. Customers in several countries use the same model version.
Auditors from two customers have asked for documentation of what the model is meant to do, which uses it should not support, and where its accuracy is weaker. The company's model registry already tracks each version and its approval status.
The documentation must stay with each model version, and no version should reach production unless that documentation is complete.
Which TWO actions meet these requirements? (Choose two.)
Choose two answers.
AA. Store the training notebook and hyperparameters in the team's Git repository, and point auditors to the commit history as the record of what the model is intended to do.
BB. Create a SageMaker Model Card for each model version that records intended use, prohibited uses, subgroup evaluation results and known limitations, linked to that version in the registry.
CC. Publish one company-wide responsible AI policy document that applies to all models, and ask each product team to read it before launch, without recording anything specific to each model version.
DD. Add a pipeline check that sets a version's status to Approved only after its model card lists intended use and limitations, and deploy only Approved versions.
EE. Add a tag with the model owner's name to each endpoint, and keep the design review's chat history as the record of decisions about the model and its limits.
Show the answer and explanation
Answers: B, D
A. Wrong: Commit history shows how the model was built, but it does not state the intended use, the prohibited uses or the known weak spots that auditors need. The requirement asks for documentation a reviewer can read, and commit logs do not provide that.
B. Right: A model card keeps the intended use, prohibited uses, evaluation results and limitations together, and attaching it to the registered version ties the record to the exact version in use. This answers the auditors' request for documentation that stays with each version. Learn more: Amazon SageMaker Model Cards (opens in a new tab)
C. Wrong: A general policy describes principles but does not say what a specific model version is for or where it is weak. Without a per-version record, auditors cannot match the documentation to the version that is running in production. Learn more: Responsible AI on AWS (opens in a new tab)
D. Right: Making the approval status depend on a complete card turns the documentation into a gate, so no version reaches production without it. It links the model card to the approval process that the company already uses for each version. Learn more: Update the approval status of a model (opens in a new tab)
E. Wrong: Tags show ownership but not the model's limits, and chat history is hard to audit and easy to lose. Neither gives auditors a maintained description of the model version they are reviewing.
Explanation
Model cards record intended use, prohibited uses, subgroup results and limitations for each version, and keeping the card with the registered version ties the record to what runs in production. Making the approved status depend on a complete card stops any version from reaching production without that documentation. Commit history, a general policy and tags do not give auditors a version-specific record.
Want more on AI governance frameworks (model cards, lineage, approval)? The 5 full-length practice sets have 5 more AI governance frameworks (model cards, lineage, approval) questions, 375 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →
Study AI governance frameworks (model cards, lineage, approval)