Overview
Understanding how to govern AI development is written from the viewpoint of an organization that builds AI, whether as a provider selling it or for its own use. It has three competencies and 16 performance indicators. III.A governs design and build: define the business context and use case, perform or review an impact assessment, apply policies and ethical considerations, manage internal and external risks, and document the process. III.B governs data for training and testing: data governance and lawful rights to use data, lineage and provenance, test planning across unit, integration, validation, performance and security testing, managing issues found, and documenting results. III.C governs release and operation: release readiness including model cards and conformity requirements, continuous monitoring and retraining schedules, periodic audits and red teaming, incident management, root cause work with stakeholders, and public disclosures.
IAPP allocates 21 to 25 scored items here, about 27% of the exam, tied with Domain IV as the largest.
How it's tested
Domain III questions describe an AI system at a point in its development and ask for the next governance action. Look for the life cycle stage, the risk level and what has or has not been documented yet. The best answer is the control that belongs at that stage, recorded so it can be shown to regulators later.
-
What comes next
A project has reached design, data collection, testing or release, and you choose the governance step that should happen at that point before moving on.
-
Data rights and quality
Training data comes from customers, scraping or a vendor, and you decide what must be confirmed about rights, provenance, representativeness or bias.
-
Post-release response
A deployed model drifts, fails an audit or causes an incident, and you choose the monitoring, documentation or disclosure response.
A team has trained a resume ranking model and wants to release it next week. Tests show strong overall accuracy but lower precision for applicants over 50. Releasing with a monitoring plan sounds pragmatic, yet a known disparity in an employment use is a release blocker. The governance answer is to investigate the cause, mitigate and retest, document the results, and only then approve release.
Performance indicators 16
Official performance indicators from the IAPP outline, in outline order.
III.A.1 Define the business context and use case of the AI systemPurpose, users, affected people and success criteria.
- What it means
- This indicator is the first gate in development. The team states the business problem, the intended purpose and users, the people affected by outputs, the decision the AI supports, success measures and whether AI is needed at all. A clear intended purpose also sets the system's regulatory classification.
- What to understand
- A vague use case makes every later control weaker, because risk, data needs and test criteria all derive from it. Ask whether a simpler non-AI solution would work. Record foreseeable misuse alongside intended use. Under the EU AI Act, intended purpose decides whether a system is high risk, so changing it later can change obligations.
- How it shows up
- A project begins with a model choice rather than a problem statement, and you choose the governance correction.
- Common confusion
- Starting with available data or a model and looking for a use afterward.
III.A.2 Perform or review an impact assessment on the AI systemAI impact, privacy and fundamental rights assessments.
- What it means
- This indicator covers assessing a system's likely effects on individuals, groups, the organization and society before building it. Formats include algorithmic or AI impact assessments, DPIAs where personal data is involved, and fundamental rights impact assessments. ISO/IEC 42005 gives guidance on structure, and NIST's Map function supports the same analysis.
- What to understand
- Impact assessments are done early and updated when the system changes, not filed once. They identify affected stakeholders, potential harms, likelihood and severity, mitigations and residual risk, and record who approved accepting it. The governance professional may perform the assessment or review one prepared by the project team. Combine overlapping assessments to avoid duplication while meeting each legal requirement.
- How it shows up
- A team asks when and how to assess impact, and you choose the timing and scope.
- Common confusion
- Doing the impact assessment after the model is built, when design choices can no longer change.
III.A.3 Apply the policies, procedures, best practices and ethical considerations to designing and building the AI systemEthics by design, policy gates and design choices.
- What it means
- This indicator turns policy into design decisions. Teams apply the organization's AI policies, secure development practices, privacy by design, fairness requirements, explainability needs and human oversight features while choosing model architecture, features and interfaces.
- What to understand
- Design choices carry ethical weight: a more interpretable model may suit a lending decision even if a complex model is slightly more accurate. Build in override and stop functions where oversight is required. Use checklists or gate reviews so policy is applied consistently. Involve diverse stakeholders and, for high-impact systems, consult affected communities.
- How it shows up
- A design trade-off is described and you pick the choice that best reflects policy and ethics.
- Common confusion
- Treating ethics as a review at the end rather than a set of design requirements.
III.A.4 Identify and manage the internal and external risks and contributing factors related to designing and building the AI model and systemTechnical, organizational, supply chain and external risks.
- What it means
- This indicator covers risk management during build. Internal risks include skill gaps, poor data, weak documentation and pressure to ship. External risks include third-party models and data, open-source components, regulatory change, adversarial attacks and shifts in the environment where the model will operate.
- What to understand
- Maintain a risk register tied to the impact assessment, with owners and treatments. Pretrained and open-source components need provenance and license review and a bill of materials. Threat modeling should include AI-specific attacks such as data poisoning, model inversion and prompt injection. Contributing factors such as unrealistic deadlines are risks in their own right.
- How it shows up
- A build depends on a third-party model or faces deadline pressure, and you identify the risk and treatment.
- Common confusion
- Limiting risk management to model accuracy while ignoring supply chain and organizational factors.
III.A.5 Document the designing and building processDesign records for compliance and risk management.
- What it means
- This indicator requires keeping records of design decisions, assumptions, alternatives considered, risk assessments and approvals. Documentation establishes compliance and helps manage risk. For high-risk systems under the EU AI Act, much of it feeds the Annex IV technical documentation.
- What to understand
- Good documentation lets an auditor or regulator reconstruct why the system looks the way it does. It records intended purpose, architecture, design trade-offs and who approved them. Version it alongside the code. Documentation written after the fact is weaker evidence and often incomplete.
- How it shows up
- A regulator or auditor asks how design decisions were made, and you identify the record that answers it.
- Common confusion
- Assuming code comments or a repository history are sufficient design documentation.
III.B.1 Establish and follow the requirements for data governanceLawful rights, quality, representativeness, access.
- What it means
- This indicator covers rules for data used in training and testing. IAPP's example is assessing and documenting lawful rights to collect and use data. Requirements also cover quality, relevance, representativeness, completeness, labeling standards, access control, retention and handling of personal and sensitive data.
- What to understand
- Confirm rights before collection: privacy lawful basis, consent scope, copyright licenses, contractual limits and website terms for scraped data. Check that data represents the population the model will serve, since gaps cause biased performance. The AI Act's Article 10 requires high-risk training, validation and test data to be relevant, sufficiently representative and examined for bias.
- How it shows up
- A team proposes a new training data source, and you identify what must be confirmed first.
- Common confusion
- Treating data quality as an engineering issue only, without checking legal rights to use the data.
III.B.2 Establish and document data lineage and provenanceWhere data came from and how it changed.
- What it means
- This indicator covers tracing data. Provenance records the origin of data: source, collection method, date, rights and consent. Lineage records how data moved and changed: cleaning, labeling, transformation, sampling and which model versions it trained.
- What to understand
- Lineage and provenance let you answer deletion requests, investigate bias, prove lawful use and reproduce results. Datasheets for datasets and data cards are common formats. Without them, a rights holder's claim or a data subject request may force retraining from scratch because no one can isolate the affected data.
- How it shows up
- A data subject asks for deletion or a rights holder disputes training use, and you identify the record needed.
- Common confusion
- Using provenance and lineage as the same thing; origin is not the same as transformation history.
III.B.3 Plan and perform training and testing of the AI model and systemUnit, integration, validation, performance, security and bias testing.
- What it means
- This indicator covers the test plan. IAPP's examples include unit, integration, validation, performance and security testing. Testing also covers fairness and bias, robustness to unusual inputs, explainability and, for generative systems, harmful output and hallucination rates. Training, validation and test sets must be kept separate.
- What to understand
- Plan tests before training, with acceptance criteria tied to the use case and impact assessment. Test the whole system, not just the model, since interfaces and human workflows create failures. Use holdout data that reflects real conditions and subgroups. Security testing should cover adversarial inputs and data leakage.
- How it shows up
- A test plan is reviewed and you identify the missing test type or acceptance criterion.
- Common confusion
- Relying on aggregate accuracy, which can hide poor performance on subgroups.
III.B.4 Identify and manage issues and risks during training and testing of the AI model and systemBias, overfitting, leakage, drift and poisoning.
- What it means
- This indicator covers problems found during training and testing: bias against groups, overfitting, underfitting, data leakage between training and test sets, poisoned or mislabeled data, memorization of personal data and unexplained behavior.
- What to understand
- Each issue needs triage, an owner and a decision: fix, mitigate, accept with documented rationale or stop. Mitigation options include rebalancing data, changing features, adjusting thresholds and adding human review. Escalate issues that affect the impact assessment conclusions. Never move a known high-severity issue to production on the promise of later monitoring.
- How it shows up
- Testing reveals a problem and you choose the governance response.
- Common confusion
- Treating a detected bias as acceptable because overall accuracy meets the target.
III.B.5 Document the training and testing processRecords that validate results and show compliance.
- What it means
- This indicator requires documenting data sets used, training parameters, test plans, results by subgroup, issues found and how they were resolved. Documentation validates results, establishes compliance and helps manage risk.
- What to understand
- Records should let someone else reproduce the results. Include model version, data version, metrics and thresholds, known limitations and sign-offs. These records support conformity assessment, audits and incident investigations. Test documentation also feeds the model card and instructions for use given to deployers.
- How it shows up
- An audit asks how a model was validated, and you identify the documentation needed.
- Common confusion
- Recording only final metrics and losing the issues and decisions made along the way.
III.C.1 Assess readiness, and prepare for release into productionModel cards, conformity and go/no-go decisions.
- What it means
- This indicator covers the release gate. IAPP's examples include creating the model card and satisfying conformity requirements. Readiness checks confirm that tests passed, risks are within tolerance, documentation is complete, monitoring and incident processes exist, users are trained and legal obligations such as conformity assessment, CE marking and registration are met.
- What to understand
- Release is a formal decision by an accountable owner, not an automatic step after testing. A model card summarizes intended use, performance, limitations and evaluation data. A staged rollout, such as a pilot or shadow mode, reduces risk. Rollback plans should exist before launch.
- How it shows up
- A team wants to launch and you identify the missing readiness item.
- Common confusion
- Thinking passing technical tests is the same as being ready for release.
III.C.2 Conduct continuous monitoring of the AI system, and establish a regular schedule for maintenance, updates and retrainingDrift, performance tracking and retraining cadence.
- What it means
- This indicator covers ongoing monitoring by the developer after release. It tracks performance, data drift, concept drift, fairness metrics, security events and user feedback, and it sets a maintenance and retraining schedule. For high-risk systems, the AI Act requires providers to run post-market monitoring.
- What to understand
- Set thresholds that trigger review or rollback. Retraining is a change that can introduce new risks, so it goes through testing and documentation again. Monitoring should feed back into the risk register and impact assessment. Continuous learning systems need extra controls because behavior changes without a formal release.
- How it shows up
- Model performance changes after release, and you choose the monitoring or maintenance action.
- Common confusion
- Treating retraining as routine maintenance that skips testing and approval.
III.C.3 Conduct periodic activities to assess the AI system's performance, reliability and safetyAudits, red teaming and threat modeling.
- What it means
- This indicator covers scheduled assessments beyond daily monitoring. IAPP's examples include audits, red teaming and threat modeling. Others include bias audits, conformity reviews, penetration tests and model validation by an independent team.
- What to understand
- Periodic assessments catch what monitoring dashboards miss, such as new attack techniques or gradual unfairness. Red teaming uses adversarial testers to make the system fail. Independent audits give assurance to leadership and regulators. Schedule them by risk level and after significant changes.
- How it shows up
- A schedule of assessments is being set, and you choose the right activity and frequency.
- Common confusion
- Assuming continuous monitoring removes the need for periodic independent assessment.
III.C.4 Manage and document incidents, issues and risksIncident response, logging and reporting.
- What it means
- This indicator covers what happens when an AI system fails or causes harm. Incident management includes detection, triage, containment, investigation, remediation, communication and documentation. Under the AI Act, providers of high-risk systems must report serious incidents to market surveillance authorities.
- What to understand
- AI incidents include harmful outputs, discriminatory decisions, security breaches, safety failures and misuse. Define what counts as an incident and the severity levels in advance. Keep an incident log and link it to the risk register. Containment may mean disabling a feature or reverting a model version. Data breaches may also trigger privacy notification duties.
- How it shows up
- An AI failure is reported and you choose the incident management step.
- Common confusion
- Handling AI incidents only through IT ticketing without legal, privacy or affected-user input.
III.C.5 Collaborate with cross-functional stakeholders to understand why incidents arise from AI systemsRoot cause analysis across teams.
- What it means
- This indicator covers root cause analysis. IAPP's examples of causes include brittleness and lack of robustness, among other factors such as data drift, poor training data, misuse, flawed assumptions and integration errors. Understanding why an incident happened needs engineers, product owners, legal, privacy, security and front-line staff.
- What to understand
- Technical teams see the model; business teams see the context; affected users see the harm. Blameless reviews encourage honest reporting. Root causes often sit outside the model, such as an interface that encouraged overreliance. Findings should update policies, training and design standards, not just the model.
- How it shows up
- An incident has recurred and you choose how to find and fix the root cause.
- Common confusion
- Assuming every AI incident is caused by the model rather than process, data or human factors.
III.C.6 Make public disclosures to meet transparency obligationsDocumentation, instructions for use and notices.
- What it means
- This indicator covers what a developer or provider tells others. IAPP's examples include technical documentation and instructions for use to deployers. Disclosures also include model cards, transparency reports, AI Act Article 50 notices, GPAI training content summaries and registration in the EU database for high-risk systems.
- What to understand
- Disclosures must be accurate and match actual capability, since overstated claims create consumer protection risk. Instructions for use tell deployers the intended purpose, performance limits, oversight needs and log requirements. Balance transparency with protecting trade secrets and security, but do not use secrecy to avoid legal duties.
- How it shows up
- A provider must decide what to publish or give deployers, and you identify the required disclosure.
- Common confusion
- Treating a marketing page as meeting the duty to give deployers instructions for use.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Intended purpose
The use the provider specifies for the system.
- Remember
- Drives risk classification and testing.
- Tested as
- Use case questions.
- Trap
- Ignoring foreseeable misuse.
-
AI impact assessment
Structured analysis of effects on people and society.
- Remember
- Early and updated over time.
- Tested as
- Assessment questions.
- Trap
- Doing it after build.
-
Data provenance
Origin, rights and collection method of data.
- Remember
- Proves lawful use.
- Tested as
- Data questions.
- Trap
- Confusing with lineage.
-
Data lineage
How data moved and changed through the pipeline.
- Remember
- Enables deletion and reproduction.
- Tested as
- Data questions.
- Trap
- Tracking only the source.
-
Representativeness
Data reflects the population the model will serve.
- Remember
- Gaps cause subgroup failures.
- Tested as
- Bias questions.
- Trap
- Relying on data volume.
-
Train/validation/test split
Separate data for fitting, tuning and final evaluation.
- Remember
- Leakage inflates results.
- Tested as
- Testing questions.
- Trap
- Testing on training data.
-
Model card
Summary of intended use, performance and limitations.
- Remember
- Part of release readiness.
- Tested as
- Release questions.
- Trap
- Treating it as marketing.
-
Data drift vs. concept drift
Input distribution changes versus relationship to outcome changes.
- Remember
- Both degrade performance over time.
- Tested as
- Monitoring questions.
- Trap
- Treating them as the same.
-
Red teaming
Adversarial testing to find failures.
- Remember
- Periodic, not one-off.
- Tested as
- Assessment questions.
- Trap
- Equating it with unit testing.
-
Post-market monitoring
Provider duty to track a high-risk system after release.
- Remember
- Feeds incident reporting.
- Tested as
- Monitoring questions.
- Trap
- Leaving it to deployers.
-
Serious incident reporting
Provider notification of serious incidents to authorities.
- Remember
- Required for high-risk systems.
- Tested as
- Incident questions.
- Trap
- Handling only internally.
-
Instructions for use
Provider information that tells deployers how to use the system safely.
- Remember
- Required for high-risk systems.
- Tested as
- Disclosure questions.
- Trap
- Substituting marketing material.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Continuous monitoring vs. periodic assessment
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Continuous monitoring | Automated tracking of metrics and drift | Ongoing, threshold-driven | Assuming it replaces audits |
| Periodic audit | Scheduled independent review | Assurance against criteria | Running it only after incidents |
| Red teaming | Adversarial attempt to break the system | Finds unknown failure modes | Treating it as standard QA |
Provenance vs. lineage vs. documentation
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Provenance | Where data came from and under what rights | Origin | Recording only transformations |
| Lineage | How data was transformed and used | History through the pipeline | Recording only the source |
| Technical documentation | Record of design, data, tests and decisions | Whole-system evidence | Writing it after release |
Development gates
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Use case gate | Purpose, users, affected people defined | Before data or model choice | Skipping to model selection |
| Data gate | Rights, quality and representativeness confirmed | Before training | Checking rights after training |
| Release gate | Tests, documentation, conformity complete | Before production | Shipping with known high-severity issues |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Monitor it later
- What candidates pick
- Release a model with a known subgroup disparity and promise post-launch monitoring.
- Why it looks right
- Monitoring sounds like a responsible control.
- Why it's wrong
- A known high-severity issue in a high-impact use must be mitigated and retested before release; monitoring detects new issues.
Clue to watch for The problem was found during testing, before launch.
-
Public data is free
- What candidates pick
- Train on scraped web data because it is publicly available.
- Why it looks right
- Anyone can view the content.
- Why it's wrong
- Public availability does not grant privacy lawful basis, copyright permission or compliance with website terms.
Clue to watch for Data was scraped or collected from third-party sites.
-
Aggregate accuracy
- What candidates pick
- Approve a model because overall accuracy meets the target.
- Why it looks right
- The headline metric looks good.
- Why it's wrong
- Aggregate metrics can hide poor performance for subgroups, which is a fairness and legal risk.
Clue to watch for Results by group are missing or uneven.
-
Model is the root cause
- What candidates pick
- Retrain the model after every incident.
- Why it looks right
- The model produced the harmful output.
- Why it's wrong
- Root causes often lie in data, interface design, misuse or process, which retraining does not fix.
Clue to watch for The incident recurs after retraining.
-
Documentation at the end
- What candidates pick
- Write technical documentation just before the conformity assessment.
- Why it looks right
- It saves effort during build.
- Why it's wrong
- Retrospective documentation is incomplete and weak evidence; records should be created as decisions are made.
Clue to watch for An auditor asks why a design choice was made.
-
Testing equals readiness
- What candidates pick
- Release once all technical tests pass.
- Why it looks right
- Tests are the visible gate.
- Why it's wrong
- Readiness also needs documentation, model card, monitoring plans, trained users, conformity steps and an accountable sign-off.
Clue to watch for The question asks if the system is ready for production.
Answer framework
For a Domain III scenario, locate the development stage and apply the control that belongs there.
- Identify the stage: use case definition, design and build, data collection, training and testing, release, or operation after release.
- Confirm the earlier gates were met: a defined purpose, an impact assessment, lawful rights to data and documented provenance before any training began.
- Check testing covers subgroups, robustness and security against acceptance criteria, and that issues found were mitigated, accepted with rationale or escalated.
- At release, require the model card, conformity steps, monitoring and incident plans, rollback option and an accountable owner's sign-off.
- After release, monitor drift and harms, run periodic audits and red teaming, investigate incidents across functions and keep public disclosures accurate.
Practice question
Want more like this? The AIGP practice test has questions for every domain.
Checklist
0 of 14
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Learn this domain as a timeline. Draw the development life cycle from use case to retirement and mark each of the 16 performance indicators at the point where it applies. Most questions test whether you know which control belongs at which moment, so the drawing is worth more than memorized definitions.
For III.A, practice writing a short use case statement and an impact assessment outline for a hiring tool and a medical triage tool, and compare how ISO/IEC 42005 and NIST's Map function frame the same work. For III.B, create a data checklist covering rights, provenance, lineage, quality, representativeness and test separation, then apply it to a scraped data set and a customer data set.
For III.C, read a published model card and a sample transparency report, and list what a release gate should require. Study the difference between monitoring, audits and red teaming, and walk through an incident from detection to root cause. Link each step back to the AI Act provider obligations from Domain II. Finish with case-study practice, where several questions follow one project through its stages.
FAQ
How much of the AIGP exam is Understanding how to govern AI development?
IAPP allocates 21 to 25 of the 85 scored items to Domain III, about 27%, tied with Domain IV as the largest domain.
Does this domain apply only to companies that sell AI?
No. It applies to any organization that builds or significantly customizes AI, whether for sale as a provider or for its own internal use.
What is the difference between data provenance and data lineage?
Provenance records where data came from and the rights attached to it. Lineage records how the data was transformed and which model versions used it.
What is a model card?
A short document describing a model's intended use, performance, evaluation data, limitations and ethical considerations, used at release and shared with deployers.
How often should an AI system be audited?
Frequency depends on risk and change. High-impact systems need regular independent assessment and a review after any significant change or incident.
What counts as an AI incident?
Any event where the system causes or nearly causes harm, such as discriminatory decisions, unsafe outputs, security breaches or misuse. Organizations define severity levels in advance.
Is red teaming only for generative AI?
No. It is common for generative models, but adversarial testing applies to any AI system whose failure could cause harm.
Other Artificial Intelligence & Machine Learning certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 3 knowledge
You have covered use case definition, impact assessment, data governance, testing, release and monitoring. Check whether you can pick the right control for each development stage.