IAPP AIGP: Complete Artificial Intelligence Governance Professional Syllabus Guide

Updated: July 27, 2026

This guide explains the entire Artificial Intelligence Governance Professional certification syllabus in practical, exam-focused and operational detail.

It follows the IAPP AIGP Body of Knowledge version 2.1, which became effective for examinations taken on or after 2 February 2026. The Body of Knowledge is reviewed periodically and identifies the knowledge, skills, competencies and performance indicators that may be assessed in the examination.

This is an explanatory study resource rather than an official IAPP course or legal opinion.

1. What the AIGP certification is testing​

The AIGP examination is not primarily testing whether you can:

• Train a neural network.
• Write Python code.
• Configure a cloud platform.
• Memorize every provision of every AI law.
• Perform advanced mathematical calculations.
• Work as a specialist data scientist.

It is testing whether you understand how an organization should govern AI responsibly across its complete lifecycle.

An AIGP-qualified professional should be able to answer questions such as:

• Should this AI use case be approved?
• What risks could the system create?
• Who is responsible for those risks?
• What laws and standards apply?
• What information should be collected before development?
• Is the training data lawful and appropriate?
• How should the system be tested?
• What human oversight is necessary?
• What should be documented?
• What should be monitored after deployment?
• What should happen when the system fails?
• When should the system be suspended or retired?

The certification therefore sits at the intersection of:

AI technology + ethics + law + risk management + organizational governance + operational controls

The four official syllabus domains are:

Domains III and IV have the greatest combined emphasis because the certification expects candidates to understand how governance works in practice, not merely how responsible-AI principles are described in theory.

2. Essential terminology before studying the domains​

2.1 What is an AI system?​

The OECD describes an AI system as a machine-based system that, for explicit or implicit objectives, infers from inputs how to generate outputs such as:

• Predictions.
• Content.
• Recommendations.
• Decisions.

Those outputs may influence physical or virtual environments. AI systems can also vary in how autonomous or adaptable they are after deployment.

A useful simplified definition is:

An AI system takes information, applies a model or reasoning process, and generates an output that influences a decision, activity or environment.

Examples​

An AI system could:

• Predict whether a customer will cancel a subscription.
• Recommend which job applicant should be interviewed.
• Generate an email response.
• Detect a potentially fraudulent payment.
• Diagnose an abnormality in a medical image.
• Decide which advertisement a person sees.
• Recommend whether a loan application should proceed.
• Operate an autonomous warehouse robot.
• Search internal documents and answer employee questions.
• Plan and execute tasks through an AI agent.

2.2 Model versus AI system​

A model is the mathematical or computational component that identifies patterns and produces outputs.

An AI system is the complete operational arrangement around that model.

An AI system may include:

• One or more models.
• User interfaces.
• Databases.
• Retrieval systems.
• Business rules.
• APIs.
• Human-review processes.
• Logging systems.
• Monitoring dashboards.
• Security controls.
• External tools.
• Approval workflows.
• Incident-management processes.

Example​

A large language model may generate text.

However, a customer-service AI system may include:

1. A large language model.
2. A retrieval system containing company policies.
3. A prompt-management layer.
4. A customer chat interface.
5. A content-filtering mechanism.
6. An escalation process to a human employee.
7. Logging and monitoring.
8. Identity and access management.
9. A CRM integration.
10. A feedback and complaint process.

Governance must cover the whole system, not only the model.

2.3 Deterministic versus probabilistic systems​

Deterministic system​

A deterministic system generally produces the same output when given the same input under the same conditions.

For example:

Input: 10 + 5
Output: 15

A conventional payroll rule may state:

If employee hours = 40 and hourly rate = $20,
gross pay = $800.

The output follows a predictable rule.

Probabilistic system​

A probabilistic system estimates what output is most likely or appropriate based on patterns learned from data.

For example, a generative-AI system may provide slightly different responses to the same question because its output is generated probabilistically.

A fraud-detection model may say:

Probability that this transaction is fraudulent: 78%

The model does not prove that fraud occurred. It estimates likelihood.

Governance significance​

Probabilistic outputs create governance challenges because:

• The output may be wrong.
• Similar inputs may receive different outputs.
• Confidence may be misunderstood.
• Users may treat a prediction as a fact.
• Performance may vary between population groups.
• The system may behave differently when real-world data changes.
• Exact reproduction of an output may be difficult.
• A model can appear convincing even when it is inaccurate.

Therefore, organizations need:

• Performance thresholds.
• Confidence thresholds.
• Human review.
• Testing across different conditions.
• Clear user instructions.
• Ongoing monitoring.
• Escalation mechanisms.

2.4 Classical AI​

Classical AI is a broad term generally used for earlier or more traditional forms of AI that perform a defined analytical or predictive task.

Examples include:

• Spam classification.
• Fraud detection.
• Demand forecasting.
• Recommendation engines.
• Customer churn prediction.
• Image classification.
• Credit-risk scoring.
• Route optimization.
• Rules-based expert systems.

Classical systems often have relatively narrow purposes.

A credit-risk model, for example, may generate only a probability of default. It is not expected to draft emails, create images and conduct open-ended conversations.

2.5 Machine learning​

Machine learning is an approach in which a model learns patterns from data rather than having every possible decision rule manually programmed.

Simple example​

Suppose an organization wants to predict whether a customer will leave.

The model may learn patterns from:

• Account age.
• Number of complaints.
• Product usage.
• Payment history.
• Customer-service interactions.
• Contract type.

The model identifies combinations associated with previous customer departures and then predicts the likelihood of future departures.

Governance questions​

A governance professional should ask:

• Was the historical data lawful to use?
• Is the data accurate?
• Does it represent the current population?
• Are some groups underrepresented?
• Are protected characteristics included?
• Are other variables acting as proxies for protected characteristics?
• Is the model accurate enough?
• What happens when the prediction is wrong?
• Who reviews the output?
• How often is the model reassessed?

2.6 Deep learning​

Deep learning is a form of machine learning that uses multilayered neural networks to learn complex patterns.

It is commonly associated with:

• Image recognition.
• Speech recognition.
• Natural-language processing.
• Generative AI.
• Autonomous systems.
• Multimodal systems.

Deep-learning models can be powerful but difficult to interpret. Their internal decision processes may involve very large numbers of parameters and mathematical relationships.

Governance implications​

The increased complexity may make it harder to:

• Explain individual outputs.
• Identify the source of an error.
• Detect hidden bias.
• Reproduce decisions.
• Determine which training data influenced an output.
• Identify why the system changed its behaviour.
• Establish responsibility for unexpected outcomes.

This does not mean deep learning should not be used. It means the degree of governance should match the system’s complexity and risk.

2.7 Generative AI​

Generative AI creates new content based on patterns learned from data.

It may generate:

• Text.
• Images.
• Audio.
• Video.
• Software code.
• Synthetic data.
• Designs.
• Summaries.
• Translations.

Generative systems usually produce plausible content rather than retrieving a guaranteed correct answer from a fixed database.

Major risks​

Generative AI may create:

• Hallucinated or fabricated information.
• Copyright concerns.
• Confidentiality breaches.
• Personal-data leakage.
• Harmful content.
• Discriminatory outputs.
• Insecure code.
• Misleading synthetic media.
• Impersonation.
• Overreliance by users.
• Incorrect professional advice.
• Prompt-injection vulnerabilities.

Example​

An employee asks a public generative-AI system:

“Summarize this confidential client contract.”

The employee may unintentionally expose:

• Client information.
• Commercial terms.
• Personal data.
• Legal advice.
• Trade secrets.

An acceptable-use policy should explain what information employees may and may not provide to external AI tools.

2.8 Large language models​

A large language model, or LLM, is trained on large quantities of language data to predict and generate sequences of text.

An LLM can perform tasks such as:

• Question answering.
• Summarization.
• Classification.
• Translation.
• Drafting.
• Information extraction.
• Code generation.
• Conversational assistance.

Important limitation​

An LLM does not necessarily “know” that its answer is true.

It produces text based on learned statistical patterns and the information made available in its context.

Therefore, fluent language is not evidence of:

• Accuracy.
• Legality.
• Fairness.
• Completeness.
• Currentness.
• Reliability.

Governance response​

Organizations may introduce:

• Retrieval-augmented generation.
• Trusted knowledge sources.
• Source citations.
• Output validation.
• Restricted use cases.
• Human review.
• Evaluation datasets.
• Hallucination testing.
• Refusal rules.
• Content filters.
• Logging and monitoring.

2.9 Multimodal AI​

A multimodal AI system can process or generate more than one type of information.

It may work with:

• Text.
• Images.
• Audio.
• Video.
• Sensor information.
• Structured data.

Example​

A multimodal insurance system might:

1. Read a customer’s written claim.
2. Examine photographs of the damage.
3. Review repair estimates.
4. Compare the claim with historical records.
5. Recommend whether further investigation is required.

Governance significance​

Multimodal systems increase the possible sources of harm.

For example:

• Images may reveal biometric information.
• Audio may identify an individual.
• Background objects may expose private information.
• Visual models may perform differently across skin tones.
• Generated images may be deceptive.
• The combined information may allow sensitive inferences.

2.10 General-purpose AI​

A general-purpose AI model can perform a broad range of tasks and can be integrated into many downstream systems.

It is not limited to one narrowly defined business function.

The EU AI Act distinguishes general-purpose AI models from individual downstream applications and establishes specific obligations for providers, with additional requirements for certain models presenting systemic risks.

Example​

A general-purpose model may be used for:

• Customer service.
• Legal drafting.
• Marketing.
• Coding.
• Recruitment support.
• Research.
• Document analysis.

Each downstream application may create different risks.

A model used for informal brainstorming is not governed in the same way as the same model used to recommend medical treatment.

2.11 Agentic AI​

Agentic AI refers to systems that can plan and perform a sequence of actions to pursue an objective.

An AI agent may:

1. Interpret a goal.
2. Break the goal into tasks.
3. Select tools.
4. Retrieve information.
5. Execute actions.
6. Observe results.
7. Adjust its plan.
8. Continue until it reaches a stopping condition.

Example​

A procurement agent might:

• Review an internal request.
• Search approved suppliers.
• Compare prices.
• Draft a purchase order.
• Request managerial approval.
• Submit the order after approval.
• Update the procurement system.

Additional governance risks​

Agentic systems may have access to:

• Email.
• Databases.
• Payment systems.
• Customer records.
• Internal APIs.
• File storage.
• Internet searches.
• Software-development tools.

This creates risks involving:

• Excessive autonomy.
• Unauthorized actions.
• Tool misuse.
• Cascading errors.
• Prompt injection.
• Privilege escalation.
• Unclear responsibility.
• Inadequate stopping conditions.
• Actions that cannot easily be reversed.

Suitable controls​

Agentic systems may require:

• Least-privilege access.
• Defined tool permissions.
• Human approval before material actions.
• Transaction limits.
• Segregation of duties.
• Action logs.
• Sandboxed environments.
• Rate limits.
• Emergency shutdown.
• Clear stopping conditions.
• Independent validation of high-impact actions.

The current AIGP Body of Knowledge expressly recognizes generative and agentic AI as part of the evolving governance environment.

DOMAIN I — FOUNDATIONS OF AI GOVERNANCE​

Domain I covers what AI governance is, why AI requires governance and how organizations establish governance expectations, responsibilities, policies and procedures. It accounts for approximately 16–20 examination questions.

3. Domain I.A — Understanding what AI is and why it needs governance​

3.1 What is AI governance?​

AI governance is the system through which an organization directs, controls and oversees its use of AI.

It includes:

• Decision-making authority.
• Policies.
• Roles and responsibilities.
• Risk-management processes.
• Technical controls.
• Legal compliance.
• Ethical requirements.
• Documentation.
• Monitoring.
• Assurance.
• Incident response.
• Reporting.

Governance answers four fundamental questions:

1. What AI may the organization use?
2. Who may approve, develop, deploy and operate it?
3. What controls must be satisfied?
4. Who remains accountable for the consequences?

AI governance should not be confused with AI management.

Governance​

Governance establishes:

• Direction.
• Authority.
• Accountability.
• Risk tolerance.
• Oversight.
• Escalation.

Management​

Management carries out:

• Development.
• Testing.
• Deployment.
• Monitoring.
• Maintenance.
• Reporting.

The board or executive committee may govern the organization’s AI strategy, while product managers, developers and operational teams manage individual systems.

3.2 Why AI needs governance​

AI introduces risks that may not be adequately controlled through ordinary software-development processes.

The AIGP syllabus identifies characteristics including:

• Complexity.
• Opacity.
• Autonomy.
• Speed and scale.
• Data dependency.
• Potential for harm or misuse.
• Probabilistic outputs.

Complexity​

An AI system may combine:

• Multiple models.
• External APIs.
• Data pipelines.
• Human decisions.
• Business rules.
• Cloud services.
• Third-party components.
• Retrieval systems.
• Monitoring tools.

When something goes wrong, the root cause may not be immediately clear.

Opacity​

Some AI models are difficult to interpret.

A system may make an accurate prediction without providing a human-understandable explanation of how it reached that result.

Opacity can make it harder to:

• Challenge an outcome.
• Detect discrimination.
• Investigate an incident.
• Satisfy legal requirements.
• Identify an incorrect assumption.
• Establish accountability.

Autonomy​

A system may act without waiting for a human instruction at every step.

The greater the autonomy, the more important it becomes to define:

• Permission boundaries.
• Approval requirements.
• Stopping conditions.
• Escalation routes.
• Human override.
• Audit logging.

Speed​

AI can make thousands or millions of decisions quickly.

Speed creates efficiency, but it can also distribute an error before humans notice it.

Scale​

A biased individual decision may harm one person.

A biased automated system used across an organization may harm thousands of people consistently.

Data dependency​

AI performance depends heavily on:

• Training data.
• Validation data.
• Testing data.
• Production inputs.
• Data quality.
• Data representativeness.
• Labelling processes.
• Data permissions.

A technically advanced model cannot compensate for fundamentally unsuitable data.

Potential for misuse​

A system designed for one legitimate purpose may be adapted for:

• Surveillance.
• Manipulation.
• Impersonation.
• Fraud.
• Discrimination.
• Cyberattacks.
• Unauthorized profiling.

Probabilistic outputs​

The system may produce:

• False positives.
• False negatives.
• Hallucinations.
• Inconsistent outputs.
• Inappropriate recommendations.
• Overconfident responses.

The NIST AI Risk Management Framework recognizes that trustworthy AI requires attention to validity and reliability, safety, security and resilience, accountability and transparency, explainability and interpretability, privacy and fairness.

4. Types of AI risk and harm​

The syllabus expects candidates to identify harms affecting:

• Individuals.
• Groups.
• Organizations.
• Society.

4.1 Harm to individuals​

Examples include:

• Being incorrectly denied a loan.
• Being unfairly rejected for employment.
• Receiving an incorrect medical recommendation.
• Exposure of personal information.
• Reputational harm from false generated content.
• Manipulation through personalized messages.
• Loss of an opportunity without meaningful explanation.
• Physical harm from an autonomous system.
• Psychological harm from harmful or deceptive interaction.

4.2 Harm to groups​

An AI system may perform differently across groups.

Examples include:

• A recruitment model disadvantaging women.
• A facial-recognition system having different error rates across demographic groups.
• A lending model disadvantaging residents of particular areas.
• A healthcare model being less accurate for underrepresented populations.
• A language system performing poorly for regional accents or minority languages.

Group harm does not always require the system to use a protected characteristic directly.

Other attributes may act as proxies.

For example:

• Postal code may act as a proxy for ethnicity or socioeconomic status.
• Employment gaps may correlate with pregnancy, caring responsibilities or disability.
• University attended may correlate with social background.
• Shopping behaviour may reveal health or religious information.

4.3 Harm to organizations​

Organizational harms include:

• Regulatory penalties.
• Litigation.
• Reputational damage.
• Customer loss.
• Intellectual-property infringement.
• Trade-secret exposure.
• Security incidents.
• Operational disruption.
• Incorrect business decisions.
• Vendor lock-in.
• Financial losses.
• Loss of employee trust.
• Inability to demonstrate compliance.

4.4 Harm to society​

Societal harms may involve:

• Disinformation.
• Political manipulation.
• Reduced trust in institutions.
• Widespread surveillance.
• Labour-market displacement.
• Environmental impact.
• Concentration of technological power.
• Systemic discrimination.
• Reduced human autonomy.
• Normalization of unreliable automated decisions.
• Undermining access to public services.

4.5 Misalignment risk​

Misalignment occurs when an AI system’s behaviour does not match the organization’s actual goals, values or intended outcomes.

Example​

An organization asks an AI customer-service system to minimize call-handling time.

The system may learn to:

• End conversations quickly.
• Avoid complex complaints.
• Discourage escalation.
• Give incomplete answers.

The system optimizes the specified metric but undermines:

• Customer satisfaction.
• Fair treatment.
• Regulatory obligations.
• Long-term customer trust.

The problem is not necessarily that the model malfunctioned.

The problem may be that the organization selected an incomplete objective.

Governance response​

Define balanced objectives such as:

• Resolution quality.
• Customer satisfaction.
• Accuracy.
• Compliance.
• Appropriate escalation.
• Handling time.

4.6 Ethical risk​

Ethical risk arises when an AI use may be legally possible but inconsistent with organizational or societal values.

Example​

A retailer may be technically capable of analyzing customers’ emotional states through cameras.

Governance questions include:

• Is the use necessary?
• Do customers reasonably expect it?
• Is meaningful consent possible?
• Could the system manipulate vulnerable customers?
• Is the business benefit proportionate to the intrusion?
• Could a less invasive method achieve the same objective?

Legal compliance is a minimum requirement. It is not always sufficient to establish that a use is appropriate.

4.7 Bias risk​

Bias refers to systematic patterns that may create unfair or distorted outcomes.

Bias can enter through:

• Problem definition.
• Data collection.
• Sampling.
• Measurement.
• Labelling.
• Model design.
• Feature selection.
• Threshold selection.
• Human interpretation.
• Deployment context.
• Feedback loops.

Historical bias​

Historical data may reflect previous discrimination.

A recruitment model trained on past hiring decisions may learn the organization’s historic preferences rather than an objective definition of ability.

Sampling bias​

The dataset may not represent the intended population.

Measurement bias​

The organization may measure the wrong concept.

For example, using previous salary as a measure of professional ability may reproduce historic pay inequality.

Label bias​

Human reviewers may label data inconsistently or based on subjective assumptions.

Deployment bias​

A model may be used in a context different from the one for which it was tested.

Automation bias​

Users may trust an automated recommendation more than they should, even when contradictory evidence exists.

4.8 Complexity and scalability risk​

A small defect can become a large problem when an AI system is:

• Used across multiple countries.
• Integrated into many products.
• Reused for unapproved purposes.
• Available to millions of users.
• Connected to automated decision processes.

Governance must therefore examine both:

• The seriousness of an individual failure.
• The number of people or processes that could be affected.

5. Responsible-AI principles​

The AIGP Body of Knowledge identifies the following common principles:

• Fairness.
• Safety and reliability.
• Privacy and security.
• Transparency and explainability.
• Accountability.
• Human-centricity.

These principles overlap, but they are not interchangeable.

5.1 Fairness​

Fairness means that the AI system should not create unjustified or systematically harmful differences between individuals or groups.

Fairness does not always mean treating everyone identically.

Equality versus equity​

Equality provides the same treatment.

Equity considers whether different support or treatment is necessary to produce a fair opportunity.

Example​

A voice-recognition system may be offered to all employees equally.

However, if it performs poorly for certain accents or speech impairments, equal availability does not produce equitable access.

Types of fairness questions​

• Are similar people treated similarly?
• Are relevant differences considered appropriately?
• Are protected groups disadvantaged?
• Are error rates comparable across groups?
• Is the decision criterion itself legitimate?
• Can affected people challenge the outcome?
• Has accessibility been considered?

Fairness metrics​

Technical teams may examine:

• Demographic parity.
• Equal opportunity.
• Equalized odds.
• False-positive rates.
• False-negative rates.
• Selection rates.
• Calibration.

No single fairness metric is universally correct.

Different fairness objectives may conflict. Governance therefore requires a contextual decision involving:

• Legal requirements.
• Nature of the decision.
• Type of harm.
• Affected stakeholders.
• Acceptable trade-offs.

Example​

In medical screening, false negatives may be more harmful than false positives.

In criminal-risk prediction, false positives may create particularly serious consequences.

The appropriate fairness assessment depends on the use case.

5.2 Safety​

Safety concerns preventing unacceptable physical, psychological, financial or societal harm.

A safe AI system should:

• Operate within defined limits.
• Fail in a controlled way.
• Avoid creating unreasonable danger.
• Support human intervention.
• Be tested under foreseeable conditions.
• Have emergency shutdown procedures.

Example​

An autonomous industrial robot should stop when a person enters a restricted area.

A medical AI should not silently generate a high-confidence recommendation when the input image is unusable.

5.3 Reliability​

Reliability concerns whether the system performs consistently and as intended.

A reliable system should:

• Produce sufficiently accurate outputs.
• Maintain performance over time.
• Behave predictably within its intended environment.
• Tolerate reasonable variations in input.
• Meet service and availability expectations.

Safety versus reliability​

A system can be reliable but unsafe.

For example, a model may consistently recommend an inappropriate action.

A system can also be safe but temporarily unreliable because safety controls prevent it from acting when confidence is low.

5.4 Privacy​

Privacy concerns appropriate handling of personal information and respect for individual autonomy.

Privacy governance includes:

• Lawful data collection.
• Purpose limitation.
• Data minimization.
• Transparency.
• Retention limits.
• Data-subject rights.
• Access controls.
• Privacy-enhancing techniques.
• Protection against inappropriate inference.

AI-specific privacy risks​

AI can create privacy risks through:

• Training on personal data.
• Memorization of training information.
• Reidentification.
• Inference of sensitive attributes.
• Prompt logging.
• Model inversion.
• Membership inference.
• Combining datasets.
• Automated profiling.

5.5 Security​

Security protects:

• Confidentiality.
• Integrity.
• Availability.

Confidentiality​

Information is accessible only to authorized people and systems.

Integrity​

Information and system behaviour are not altered improperly.

Availability​

The system remains accessible when needed.

AI-specific security threats​

• Prompt injection.
• Adversarial examples.
• Data poisoning.
• Model theft.
• Training-data extraction.
• Insecure plugins.
• Malicious tool calls.
• Supply-chain compromise.
• Unauthorized fine-tuning.
• Model denial-of-service.
• Privilege escalation through agents.

Privacy versus security​

Security supports privacy, but the concepts are not identical.

A system may be secure against hackers while still collecting excessive personal data.

A privacy-compliant design must ask whether the data should be collected at all, not merely whether it is protected.

5.6 Transparency​

Transparency concerns providing relevant information about the AI system and its use.

Transparency may include explaining:

• That AI is being used.
• The system’s purpose.
• The responsible organization.
• What information is processed.
• The role AI plays in the decision.
• Known limitations.
• Human-review options.
• How to complain or challenge an outcome.

Transparency does not mean publicly disclosing every line of source code.

The appropriate level depends on the audience.

Different audiences need different transparency​

Customers may need:

• Notice that they are interacting with AI.
• Explanation of how a decision affects them.
• Complaint and review routes.

Developers may need:

• Technical architecture.
• Data sources.
• Model limitations.
• Evaluation results.

Executives may need:

• Material risks.
• Business benefits.
• Residual risk.
• Regulatory exposure.

Regulators may need:

• Technical documentation.
• Risk assessments.
• Logs.
• Testing evidence.
• Governance approvals.

5.7 Explainability​

Explainability concerns whether humans can understand how or why the system produced an output.

Global explanation​

A global explanation describes how the system generally operates.

For example:

“The model assesses income stability, payment history, outstanding debt and account history.”

Local explanation​

A local explanation describes why a particular output was produced.

For example:

“The application was referred for additional review because the reported income could not be verified and the debt-to-income ratio exceeded the review threshold.”

Explainability versus transparency​

Transparency means disclosing relevant information about the system.

Explainability means making the system’s operation or a particular result understandable.

A company might transparently disclose that it uses AI while still being unable to explain a specific decision.

5.8 Accountability​

Accountability means that identifiable people or organizational functions remain answerable for the AI system.

“AI made the decision” is not an adequate accountability model.

Accountability requires:

• Named owners.
• Defined decision rights.
• Approval records.
• Escalation routes.
• Documentation.
• Monitoring.
• Consequences for noncompliance.
• Ability to investigate decisions.
• Board or executive oversight.

Responsibility versus accountability​

A person may be responsible for performing a task.

Another person may be accountable for ensuring the task is completed correctly.

For example:

• A data scientist may be responsible for bias testing.
• The AI product owner may be accountable for ensuring the system meets the approved fairness requirements.

5.9 Human-centricity​

Human-centric AI places human rights, dignity, autonomy, well-being and meaningful control at the centre of the system.

Questions include:

• Does the system support people or merely reduce costs?
• Can individuals understand its role?
• Can people challenge important outcomes?
• Is human oversight meaningful?
• Are vulnerable people protected?
• Does the system reduce human autonomy?
• Is the system accessible?
• Are workers being monitored disproportionately?

The OECD AI Principles emphasize human rights, democratic values, fairness, privacy, transparency, robustness, safety and accountability.

6. Domain I.B — Establishing organizational expectations​

6.1 Defining roles and responsibilities​

A strong AI governance programme must identify who:

• Proposes an AI use case.
• Owns the business outcome.
• Approves development.
• Assesses legal requirements.
• Reviews privacy.
• Reviews security.
• Governs data.
• Builds the system.
• Tests performance.
• Approves release.
• Operates the system.
• Monitors the system.
• Investigates incidents.
• Communicates with regulators.
• Decides whether to suspend the system.

The syllabus expects candidates to understand both governance stakeholders and the differences between developers, providers, deployers and users.

6.2 Board and executive leadership​

The board or senior executive body should normally oversee:

• AI strategy.
• Risk appetite.
• Material AI risks.
• High-impact use cases.
• Organizational accountability.
• Investment in governance capabilities.
• Significant incidents.
• Regulatory exposure.

The board does not need to approve every low-risk AI tool.

It should establish a governance structure ensuring that material matters receive appropriate attention.

6.3 AI governance committee​

An AI governance committee may:

• Approve or reject higher-risk use cases.
• Review impact assessments.
• Resolve cross-functional disagreements.
• Define prohibited uses.
• Review exceptions.
• Oversee the AI inventory.
• Review incidents.
• Monitor regulatory changes.
• Report to senior leadership.

The committee should have sufficient authority and should not operate merely as an advisory group whose recommendations can be ignored without explanation.

6.4 Business owner​

The business owner defines:

• The problem.
• Expected benefits.
• Intended users.
• Success measures.
• Operational process.
• Acceptable risk.

The business owner should remain accountable for the use case rather than transferring responsibility entirely to the technical team.

6.5 Product or system owner​

The system owner coordinates:

• Requirements.
• Development.
• Risk assessments.
• Testing.
• Documentation.
• Release.
• Monitoring.
• Change management.

The system owner should know whether the AI system remains within its approved purpose and risk boundaries.

6.6 Data owner and data steward​

The data owner is accountable for the appropriate use of a dataset.

The data steward may perform operational data-management activities.

Responsibilities may include:

• Data quality.
• Access authorization.
• Retention.
• Metadata.
• Lineage.
• Lawful use.
• Data classification.
• Correction.
• Deletion.

6.7 Technical teams​

Technical stakeholders may include:

• Data scientists.
• Machine-learning engineers.
• Software engineers.
• Data engineers.
• AI architects.
• Security engineers.
• Model validators.
• Site-reliability engineers.

They are responsible for implementing technical requirements, but they should not independently decide the organization’s ethical or legal position.

6.8 Legal and compliance​

Legal and compliance teams may assess:

• Applicable law.
• Contractual obligations.
• Regulatory classification.
• Intellectual property.
• Consumer protection.
• Discrimination risk.
• Required disclosures.
• Documentation requirements.
• Enforcement exposure.

They require sufficient technical information to perform their role effectively.

6.9 Privacy and data protection​

Privacy stakeholders may assess:

• Lawful basis.
• Purpose limitation.
• Data minimization.
• Sensitive data.
• Data-subject rights.
• Automated decision-making.
• Privacy impact assessments.
• Cross-border transfers.
• Retention.
• Third-party processors.

6.10 Information security​

Security teams assess:

• Threat models.
• Access controls.
• Encryption.
• Supply-chain security.
• Prompt injection.
• Model extraction.
• Data leakage.
• Incident detection.
• Infrastructure security.
• Business continuity.

6.11 Procurement and third-party risk​

Procurement should not evaluate only:

• Price.
• Features.
• Delivery dates.

AI procurement should also evaluate:

• Data use.
• Model training practices.
• Security.
• Intellectual-property rights.
• Performance evidence.
• Audit rights.
• Regulatory support.
• Model updates.
• Incident notification.
• Exit arrangements.

6.12 Human resources​

HR may be involved when AI affects:

• Recruitment.
• Performance monitoring.
• Promotion.
• Scheduling.
• Employee surveillance.
• Termination.
• Training.
• Workplace accessibility.

6.13 Internal audit​

Internal audit independently assesses whether governance controls:

• Exist.
• Are appropriately designed.
• Operate effectively.
• Produce reliable evidence.
• Address identified risks.

Internal audit should maintain sufficient independence from those who build and operate the system.

7. Cross-functional collaboration​

AI governance is inherently cross-functional because no single team has all the information required.

The technical team understands:​

• Architecture.
• Model behaviour.
• Data pipelines.
• Performance.
• Security implementation.

The business team understands:​

• Objectives.
• Customers.
• Operational context.
• Commercial value.
• Process consequences.

Legal and compliance understand:​

• Obligations.
• Restrictions.
• Regulatory exposure.
• Contractual requirements.

Privacy understands:​

• Personal-data risks.
• Data-subject rights.
• Data-protection controls.

Risk and audit understand:​

• Control design.
• Risk acceptance.
• Assurance.
• Governance evidence.

Affected stakeholders understand:​

• Real-world consequences.
• Accessibility.
• User expectations.
• Potential harms not visible to designers.

Cross-functional governance is not simply inviting many people to a meeting.

It requires:

• Defined decision rights.
• Timely access to information.
• Clear escalation.
• Documented disagreements.
• Sufficient authority.
• Accountability for actions.

8. Training and awareness​

The syllabus expects organizations to provide training on:

• AI terminology.
• AI strategy.
• Governance.
• Stakeholder responsibilities.

Training should be role-based.

8.1 General employee training​

Employees should understand:

• Approved AI tools.
• Prohibited information.
• Acceptable use.
• Verification requirements.
• Copyright considerations.
• Incident reporting.
• AI-generated content labelling.
• Human responsibility for outputs.

8.2 Developer training​

Developers may need training on:

• Secure AI development.
• Bias testing.
• Data governance.
• Model documentation.
• Evaluation.
• Privacy-enhancing methods.
• Threat modelling.
• Responsible model selection.

8.3 Executive training​

Executives should understand:

• Strategic opportunities.
• Material risks.
• Accountability.
• Regulatory exposure.
• Risk appetite.
• Required governance investment.
• Incident responsibilities.

8.4 Procurement training​

Procurement teams should understand:

• AI vendor due diligence.
• Data-use clauses.
• Model-update risks.
• Audit rights.
• Intellectual-property warranties.
• Incident notification.
• Subprocessor risks.

8.5 Training effectiveness​

Completion rates alone do not prove training is effective.

Organizations may evaluate:

• Knowledge tests.
• Scenario exercises.
• Reduction in policy violations.
• Incident-reporting quality.
• Employee behaviour.
• Audit findings.
• Phishing or prompt-injection simulations.

9. Proportional governance​

AI governance should be proportionate to:

• Organizational size.
• AI maturity.
• Industry.
• Use case.
• Scale.
• Autonomy.
• Data sensitivity.
• Potential harm.
• Regulatory requirements.
• Risk tolerance.

Low-risk example​

An internal tool summarizes publicly available articles and does not make decisions about individuals.

Possible controls:

• Approved tool.
• Employee training.
• Basic accuracy review.
• Security restrictions.
• Acceptable-use policy.

High-risk example​

An AI system recommends whether a person should receive a mortgage.

Possible controls:

• Formal impact assessment.
• Legal review.
• Fairness testing.
• Explainability.
• Human review.
• Detailed documentation.
• Audit.
• Regulatory classification.
• Complaint mechanism.
• Continuous monitoring.
• Incident reporting.
• Board-level risk visibility.

Proportionality does not mean small organizations can ignore governance.

It means governance should be designed according to the risk and the organization’s context.

10. AI ecosystem roles​

10.1 Developer​

A developer designs or builds an AI model or system.

Responsibilities may include:

• Model architecture.
• Data preparation.
• Training.
• Testing.
• Documentation.
• Security.
• Performance evaluation.

10.2 Provider​

A provider makes an AI model or system available under its name or control.

A provider may have responsibilities involving:

• Product compliance.
• Technical documentation.
• Instructions.
• Monitoring.
• Incident reporting.
• Downstream information.

10.3 Deployer​

A deployer uses an AI system within an operational environment.

The deployer decides:

• The business context.
• Who uses it.
• What data it receives.
• How outputs affect people.
• What human oversight exists.
• How the system is monitored.

10.4 User​

A user directly interacts with or operates the AI system.

Users may require:

• Training.
• Usage restrictions.
• Access controls.
• Instructions.
• Escalation procedures.

10.5 Importer and distributor​

An importer or distributor may make an AI system available within a jurisdiction or supply chain.

Their responsibilities may include confirming that required compliance information and documentation exist.

10.6 Multiple roles​

An organization can hold several roles.

For example, a bank may:

• Develop an internal credit model.
• Provide the system to a subsidiary.
• Deploy the system in its lending operation.
• Employ users who operate it.

Governance must assess each role separately because responsibilities may overlap.

11. Domain I.C — Policies across the AI lifecycle​

The AIGP syllabus expects organizations to create policies covering:

• Use-case assessment.
• Risk management.
• Ethics by design.
• Data acquisition and use.
• Development.
• Training and testing.
• Deployment.
• Monitoring.
• Documentation.
• Reporting.
• Incident management.

11.1 AI use-case intake policy​

Before development begins, the organization should record:

• Name of the proposed system.
• Business owner.
• Purpose.
• Intended users.
• Affected people.
• Data required.
• Expected outputs.
• Decision influence.
• Level of autonomy.
• Third-party involvement.
• Countries of operation.
• Potential benefits.
• Potential harms.

The intake process determines whether the use case needs:

• Simple approval.
• Legal review.
• Privacy assessment.
• Security review.
• Full AI impact assessment.
• Executive or committee approval.
• Rejection.

11.2 AI inventory​

An AI inventory is a structured register of AI systems used or developed by the organization.

It may contain:

• System name.
• Owner.
• Purpose.
• Provider.
• Model version.
• Data categories.
• Risk classification.
• Geographic use.
• Impact-assessment status.
• Approval status.
• Monitoring status.
• Incident history.
• Retirement date.

Without an inventory, an organization may not know:

• What AI it uses.
• Who owns each system.
• Which systems are high risk.
• Which systems use personal data.
• Which vendors require reassessment.
• Which systems should be retired.

11.3 Risk-classification policy​

A risk-classification process may assess:

• Impact on fundamental rights.
• Physical safety.
• Financial impact.
• Legal significance.
• Number of affected people.
• Vulnerability of affected groups.
• Data sensitivity.
• Autonomy.
• Reversibility.
• Explainability.
• Human oversight.
• Public exposure.

Systems may be classified internally as:

• Low.
• Moderate.
• High.
• Prohibited.

This internal classification may differ from a legal classification but should account for applicable legal requirements.

11.4 Ethics-by-design policy​

Ethics by design means considering responsible-AI principles during design rather than attempting to correct ethical problems after deployment.

It may require teams to ask:

• Is the purpose legitimate?
• Is AI necessary?
• Are less intrusive alternatives available?
• Who benefits?
• Who carries the risk?
• Could the system reduce human autonomy?
• Could it disadvantage vulnerable groups?
• What values should guide trade-offs?
• What uses should be prohibited?

11.5 Development policy​

An AI development policy may require:

• Approved development environments.
• Version control.
• Code review.
• Data approval.
• Model documentation.
• Testing standards.
• Reproducibility.
• Security review.
• Change management.
• Release approval.

11.6 Monitoring policy​

A monitoring policy should define:

• Metrics.
• Thresholds.
• Review frequency.
• Responsible owners.
• Escalation triggers.
• Reporting requirements.
• Retraining triggers.
• Suspension triggers.

11.7 Documentation and record-keeping policy​

Records may include:

• Use-case proposal.
• Impact assessment.
• Data documentation.
• Model card.
• Test evidence.
• Approval decision.
• Risk acceptance.
• Monitoring results.
• Incidents.
• Model changes.
• Vendor assessments.
• User instructions.
• Complaints.

Documentation allows the organization to demonstrate what it knew, what it decided and what controls it implemented.

11.8 Incident-management policy​

An AI incident may involve:

• Discriminatory outcomes.
• Data leakage.
• Dangerous recommendations.
• Security compromise.
• Systematic hallucination.
• Regulatory noncompliance.
• Unauthorized use.
• Failure of human oversight.
• Material performance degradation.

The policy should define:

1. Detection.
2. Reporting.
3. Severity classification.
4. Containment.
5. Investigation.
6. Root-cause analysis.
7. Corrective action.
8. Notification.
9. Recovery.
10. Lessons learned.

11.9 Retirement policy​

Retirement should address:

• Disabling system access.
• Terminating integrations.
• Preserving required records.
• Deleting data where appropriate.
• Ending vendor access.
• Communicating changes.
• Migrating users.
• Managing archived outputs.
• Confirming that the system is no longer operating.

12. Updating existing policies for AI​

The syllabus specifically identifies:

• Data privacy.
• Security.
• Data governance.
• Intellectual property.

12.1 Privacy policy update​

The policy may need AI-specific rules for:

• Training data.
• Prompt data.
• Model memorization.
• Inferred data.
• Automated decisions.
• Synthetic data.
• Model logging.
• Data-subject requests.

12.2 Security policy update​

AI-specific additions may include:

• Prompt-injection controls.
• Adversarial testing.
• Model access.
• AI supply-chain review.
• Tool permissions.
• Agentic-system controls.
• Model extraction prevention.

12.3 Data-governance policy update​

The policy may need to cover:

• Data provenance.
• Training suitability.
• Representativeness.
• Labelling quality.
• Dataset versioning.
• Generated data.
• Model feedback data.

12.4 Intellectual-property policy update​

The policy may address:

• Use of copyrighted training materials.
• Generated-content ownership.
• Open-source model licences.
• Employee use of generated content.
• Confidential information in prompts.
• Vendor indemnities.
• Code-generation risks.

13. Third-party AI governance​

Third-party AI may enter an organization through:

• Formal procurement.
• Cloud services.
• HR tools.
• Marketing platforms.
• Embedded software features.
• Employee use of public tools.
• Contractors.
• Open-source models.
• Supply-chain integrations.

13.1 Vendor due diligence​

Questions should include:

• What model is used?
• Where is the service hosted?
• What data does the vendor collect?
• Does the vendor use customer data for training?
• How long are prompts and outputs retained?
• What subprocessors are involved?
• What security certifications exist?
• How is bias tested?
• How are model changes communicated?
• What audit evidence is available?
• How are incidents reported?
• Can the organization export its data?
• What happens at termination?

13.2 Contractual controls​

AI contracts may address:

• Permitted data use.
• Confidentiality.
• Security requirements.
• Data location.
• Subprocessors.
• Intellectual-property rights.
• Warranties.
• Performance commitments.
• Audit rights.
• Regulatory cooperation.
• Incident notification.
• Liability.
• Indemnification.
• Change notification.
• Termination.
• Data deletion.
• Transition support.

DOMAIN II — LAWS, STANDARDS AND FRAMEWORKS​

Domain II accounts for approximately 19–23 questions. It covers privacy laws, other existing laws, AI-specific legislation and major governance standards and frameworks. The current Body of Knowledge refers to the EU AI Act, South Korea’s AI Basic Law and relevant U.S. federal and state AI laws affecting private-sector organizations.

14. Difference between laws, regulations, standards and frameworks​

Law​

A law creates legally enforceable obligations.

Noncompliance may result in:

• Penalties.
• Regulatory orders.
• Litigation.
• Compensation.
• Product restrictions.
• Criminal consequences in some circumstances.

Regulation​

A regulation is a legally binding rule issued through an authorized legislative or regulatory process.

Standard​

A standard defines agreed requirements, specifications or practices.

Standards may be:

• Voluntary.
• Contractually required.
• Used for certification.
• Referenced by regulators.
• Used as evidence of good practice.

Framework​

A framework organizes principles and activities to help an organization manage a subject.

A framework may offer flexibility rather than mandatory requirements.

Policy​

An internal policy states the organization’s rules and expectations.

Procedure​

A procedure explains how to comply with the policy.

Control​

A control is a measure that reduces risk or supports compliance.

Example​

• Law: Requires organizations to protect personal data.
• Standard: Describes how a management system should operate.
• Framework: Organizes AI risk activities into Govern, Map, Measure and Manage.
• Policy: Prohibits employees from entering confidential data into public AI systems.
• Procedure: Explains how to request approval for an AI tool.
• Control: Blocks uploads to unapproved AI websites.

15. Domain II.A — Privacy laws and AI​

The AIGP syllabus expects understanding of:

• Transparency.
• Choice.
• Lawful basis.
• Purpose limitation.
• Data minimization.
• Privacy by design.
• Controller obligations.
• Impact assessments.
• Processors.
• Cross-border transfers.
• Data-subject rights.
• Automated decision-making.
• Incidents.
• Breach notification.
• Records.
• Sensitive data.

Exact requirements vary by jurisdiction. The GDPR provides a useful model because it expressly addresses principles including purpose limitation, data minimization, transparency and automated decision-making.

15.1 Personal data​

Personal data is information relating to an identified or identifiable individual.

AI systems may process personal data through:

• Training datasets.
• Prompts.
• User profiles.
• Transaction histories.
• Images.
• Voice recordings.
• Device information.
• Behavioural data.
• Location information.
• Generated inferences.

Even when direct identifiers are removed, information may remain personal if an individual can reasonably be reidentified.

15.2 Transparency and notice​

People should receive appropriate information about how their data is used.

An AI privacy notice may explain:

• What data is collected.
• Why the data is used.
• Whether AI is involved.
• Whether profiling occurs.
• Whether decisions are automated.
• Who receives the information.
• How long it is retained.
• What rights individuals have.
• How to request human review.

A notice should be:

• Clear.
• Accessible.
• Accurate.
• Timely.
• Appropriate for the audience.

A vague statement that “data may be used to improve services” may be insufficient where the organization actually uses the data to train a model that makes significant decisions.

15.3 Choice and consent​

Choice allows individuals to exercise control over certain uses of their information.

Consent, where relied upon, should generally be:

• Informed.
• Specific.
• Freely given.
• Unambiguous.
• Capable of withdrawal.

Consent is not always the appropriate legal basis.

Example​

An employer may have difficulty relying on employee consent where the power relationship means the employee cannot freely refuse.

The governance professional should ask:

• Is consent legally required?
• Is another lawful basis available?
• Is the choice genuine?
• What happens if the individual refuses?
• Can the organization stop processing after withdrawal?
• Has downstream model use been considered?

15.4 Lawful basis​

Organizations need a valid legal justification for processing personal data.

Depending on jurisdiction and context, this may involve:

• Consent.
• Contractual necessity.
• Legal obligation.
• Vital interests.
• Public task.
• Legitimate interests.

An AI project should not collect data first and identify a legal basis later.

The lawful basis should be assessed before processing begins and documented.

15.5 Purpose limitation​

Purpose limitation means personal data should be collected for specified and legitimate purposes and not reused incompatibly.

Example​

A company collects customer-service calls to resolve complaints.

It later wants to use the recordings to train an emotion-recognition system for employee-performance monitoring.

Governance questions include:

• Is this compatible with the original purpose?
• Were customers and employees informed?
• Is the use necessary?
• Does it create new risks?
• Is additional consent or another lawful basis required?
• Could a less intrusive dataset be used?

The GDPR expressly requires personal data to be collected for specified purposes and restricts incompatible further processing.

15.6 Data minimization​

Data minimization means using only information that is:

• Adequate.
• Relevant.
• Necessary.

Example​

A recruitment system may not need:

• Full home address.
• Photograph.
• Date of birth.
• Marital status.
• Social-media history.

Collecting additional information “because it might improve the model” is not automatically justified.

Minimization techniques​

• Remove unnecessary fields.
• Aggregate information.
• Pseudonymize data.
• Use shorter retention.
• Restrict prompts.
• Use synthetic data where appropriate.
• Process data locally.
• Avoid storing raw inputs.
• Limit model access to required records.

15.7 Privacy by design​

Privacy by design means building privacy into the system from the beginning.

It is not a final compliance review added immediately before release.

Privacy-by-design decisions may include:

• Selecting a less intrusive use case.
• Avoiding sensitive data.
• Using local processing.
• Applying access controls.
• Separating datasets.
• Minimizing logs.
• Encrypting data.
• Creating deletion capabilities.
• Designing user rights into the workflow.
• Preventing vendor reuse of data.

South Korea’s privacy regulator has similarly emphasized incorporating privacy-by-design into AI development and coordination between privacy professionals and developers.

15.8 Controller and processor​

A controller generally determines the purposes and means of personal-data processing.

A processor processes data on the controller’s behalf.

AI example​

A company decides to use an AI recruitment platform to rank candidates.

The company may be the controller because it decides:

• Why candidates are assessed.
• Which candidates are included.
• How scores affect recruitment.

The platform provider may act as a processor for certain activities.

However, role classification depends on the actual arrangement. A vendor may be a separate controller for data it uses for its own purposes.

15.9 Privacy impact assessment​

A privacy impact assessment evaluates how a project affects privacy and how risks will be mitigated.

It may examine:

• Nature of the processing.
• Scope.
• Context.
• Purpose.
• Necessity.
• Proportionality.
• Risks to individuals.
• Safeguards.
• Residual risk.
• Consultation requirements.

A privacy impact assessment focuses on personal-data risks.

An AI impact assessment may be broader and include:

• Fairness.
• Safety.
• Human rights.
• Social impact.
• Explainability.
• Environmental impact.

The two assessments can be integrated but should not be treated as automatically identical.

15.10 Cross-border transfers​

AI services may involve data moving between countries through:

• Cloud hosting.
• Vendor support.
• Model APIs.
• Subprocessors.
• Global development teams.
• Monitoring systems.

Governance should identify:

• Where data is stored.
• Where it is accessed.
• Which legal transfer mechanisms apply.
• What contractual safeguards exist.
• Whether local laws create additional risks.

15.11 Data-subject rights​

Depending on the applicable law, individuals may have rights involving:

• Access.
• Correction.
• Deletion.
• Restriction.
• Objection.
• Portability.
• Information about automated decisions.
• Human review.

AI systems can make these rights technically difficult.

For example:

• Can the organization locate an individual’s training data?
• Can the information be deleted?
• Can an inaccurate profile be corrected?
• Can the organization explain a decision?
• Can the individual opt out of profiling?
• Does deletion require retraining the model?

These questions should be considered during system design.

15.12 Automated decision-making​

Automated decision-making occurs when a decision is made through automated processing with limited or no meaningful human involvement.

A person clicking “approve” without genuinely reviewing the evidence may not constitute meaningful human oversight.

Meaningful human review requires:​

• Sufficient knowledge.
• Authority to change the outcome.
• Time to review.
• Access to relevant information.
• Freedom from pressure to accept the model.
• Understanding of system limitations.
• Documentation of the review.

15.13 Incident and breach management​

Not every AI incident is a personal-data breach.

Personal-data breach​

A breach affects the confidentiality, integrity or availability of personal data.

AI incident​

An AI incident may involve:

• Harmful bias.
• Dangerous recommendations.
• Significant performance failure.
• Unauthorized use.
• Transparency failure.
• Security failure.
• Personal-data breach.

One event may be both.

15.14 Sensitive data​

Sensitive or special-category data may include:

• Health information.
• Biometrics.
• Race or ethnicity.
• Religious beliefs.
• Political opinions.
• Sexual orientation.
• Genetic data.

Other high-risk information may include:

• Children’s data.
• Precise location.
• Financial information.
• Criminal-history data.

AI systems may infer sensitive information even when it was not directly collected.

For example, purchasing patterns may reveal:

• Health conditions.
• Pregnancy.
• Religious practice.
• Financial distress.

Governance should consider both explicit data and inferred data.

16. Domain II.B — Other existing laws​

16.1 Intellectual-property law​

AI raises IP questions concerning:

• Training data.
• Model weights.
• Source code.
• Generated outputs.
• Prompts.
• Fine-tuned models.
• Databases.
• Open-source components.

Training-data rights​

An organization should ask:

• Is the data copyrighted?
• Does a licence permit AI training?
• Are database rights involved?
• Are contractual restrictions present?
• Does the dataset contain trade secrets?
• Is scraping legally permitted?
• Can the organization demonstrate provenance?

Generated outputs​

Questions include:

• Who owns the output?
• Does copyright attach?
• Could the output reproduce protected material?
• Does the vendor claim rights?
• Can the output be commercially reused?
• Is attribution required?

Trade secrets​

Entering confidential information into an external AI tool may undermine trade-secret protection if appropriate controls are absent.

Open-source models​

Open-source does not mean “without legal obligations.”

Licences may impose:

• Attribution.
• Use restrictions.
• Distribution requirements.
• Notice requirements.
• Restrictions on downstream licensing.

16.2 Nondiscrimination law​

AI systems used in employment, credit, lending, housing and insurance can create discrimination risks, all of which are expressly included in the AIGP syllabus.

Direct discrimination​

The system intentionally treats someone differently because of a protected characteristic.

Indirect discrimination or disparate impact​

A neutral-looking criterion disproportionately disadvantages a protected group without sufficient justification.

Proxy discrimination​

The model uses a variable that strongly correlates with a protected characteristic.

Example​

A model does not use race.

However, it uses:

• Postal code.
• School attended.
• Purchasing patterns.
• Language preference.

Those variables may reproduce racial or socioeconomic patterns.

Governance controls​

• Protected-group analysis.
• Feature review.
• Fairness metrics.
• Representative data.
• Independent validation.
• Human review.
• Complaint mechanism.
• Periodic monitoring.
• Documented justification.

16.3 Consumer-protection law​

Consumer-protection laws commonly prohibit unfair or deceptive practices.

AI-related risks include:

• Exaggerated claims.
• False accuracy statements.
• Undisclosed chatbot interaction.
• Fake reviews.
• Deceptive synthetic content.
• Manipulative personalization.
• Dark patterns.
• Unsupported claims that a system is unbiased.
• Misrepresentation of human oversight.

Example​

A company advertises:

“Our AI recruitment tool eliminates human bias.”

Unless this claim is supported by strong evidence, it may be misleading.

A more defensible statement may explain:

• What fairness testing was performed.
• What limitations remain.
• What human oversight exists.

16.4 Product liability​

Product-liability principles may apply where an AI-enabled product causes harm.

Potential defects include:

Design defect​

The system was designed in an unreasonably dangerous way.

Manufacturing or implementation defect​

The product did not operate as designed because of an implementation problem.

Failure to warn​

The provider did not adequately disclose limitations, risks or required precautions.

Maintenance failure​

The organization knew performance had degraded but failed to update or withdraw the system.

AI-specific complexity​

Liability may be complicated by:

• Model updates.
• Third-party components.
• User modifications.
• Fine-tuning.
• Dynamic behaviour.
• Multiple actors in the value chain.
• Unforeseen downstream uses.

17. Domain II.C — AI-specific laws​

17.1 Risk-based regulation​

Risk-based regulation imposes different requirements depending on the seriousness of the AI use.

The EU AI Act uses categories including:

• Prohibited or unacceptable risk.
• High risk.
• Specific transparency risk.
• Minimal risk.

It also establishes obligations for general-purpose AI models.

17.2 Prohibited or unacceptable-risk AI​

Certain uses may be prohibited because their risks are considered incompatible with fundamental rights or public values.

Examples under the EU AI Act include certain forms of:

• Manipulation.
• Exploitation of vulnerability.
• Social scoring.
• Certain biometric practices.
• Certain criminal-risk predictions.

The exact legal criteria matter. Candidates should avoid assuming that every biometric or profiling system is automatically prohibited.

The exam may describe a system and ask whether it is:

• Prohibited.
• High risk.
• Subject to transparency requirements.
• Minimal risk.

17.3 High-risk AI​

High-risk systems may include certain uses affecting:

• Employment.
• Education.
• Access to essential services.
• Law enforcement.
• Migration.
• Justice.
• Critical infrastructure.
• Regulated products.

High-risk status usually creates obligations involving:

• Risk management.
• Data governance.
• Documentation.
• Logging.
• Human oversight.
• Accuracy.
• Robustness.
• Cybersecurity.
• Monitoring.

17.4 Transparency-risk systems​

Some systems require specific disclosures.

Examples may include:

• Chatbots.
• Emotion-recognition systems.
• Biometric categorization.
• Deepfakes.
• Certain AI-generated content.

The central governance question is:

What information must the person receive so they are not misled about the nature or origin of the interaction or content?

17.5 Minimal-risk systems​

Many AI systems may not face specific mandatory obligations under a risk-based AI law.

Examples might include:

• Spam filters.
• AI-enabled games.
• Low-impact productivity tools.

However, minimal legal risk does not mean zero organizational risk.

Privacy, security, consumer, IP and contractual laws may still apply.

17.6 Risk-management system​

A formal AI risk-management process should:

1. Identify risks.
2. Estimate probability.
3. Estimate severity.
4. Identify affected stakeholders.
5. Select controls.
6. Test control effectiveness.
7. Assess residual risk.
8. Approve or reject the risk.
9. Monitor changes.
10. Update the assessment.

Risk management is continuous rather than a one-time document.

17.7 Data governance requirements​

AI-specific laws may require data to meet standards involving:

• Relevance.
• Representativeness.
• Accuracy.
• Completeness.
• Appropriate statistical properties.
• Bias management.
• Provenance.

Governance should document both strengths and known limitations.

17.8 Technical documentation​

Technical documentation may include:

• Purpose.
• Architecture.
• Model type.
• Data sources.
• Development process.
• Performance metrics.
• Testing.
• Limitations.
• Human oversight.
• Monitoring.
• Version history.
• Risk controls.

The purpose is to allow:

• Internal review.
• Regulatory assessment.
• Downstream implementation.
• Incident investigation.
• Reproducibility.

17.9 Record keeping and logging​

Logs may capture:

• Inputs.
• Outputs.
• User identity.
• Model version.
• Time.
• Tool actions.
• Human override.
• Errors.
• Escalations.
• Security events.

Logging must be balanced against privacy and data-minimization requirements.

Organizations should not collect unlimited logs merely because storage is available.

17.10 Conformity assessment​

A conformity assessment evaluates whether a regulated AI system satisfies applicable requirements before it is placed on the market or put into service.

It may involve:

• Internal assessment.
• Independent assessment.
• Technical documentation.
• Quality-management evidence.
• Testing.
• Registration.
• Declarations.

Conformity is not identical to general performance testing.

It is an assessment against defined legal or technical requirements.

17.11 AI impact assessment​

An AI impact assessment identifies:

• Intended benefits.
• Affected stakeholders.
• Potential harms.
• Severity.
• Probability.
• Mitigations.
• Residual risk.
• Accountability.
• Monitoring.

It should be specific to the use case.

The same model may require different assessments when used for:

• Marketing content.
• Recruitment.
• Medical advice.
• Legal research.

17.12 Human oversight​

Human oversight must be designed according to the risk.

Possible models include:

Human in the loop​

The human approves the output before action occurs.

Human on the loop​

The system operates, but a human monitors it and can intervene.

Human in command​

Humans control the system’s purpose, boundaries and continuation.

Meaningful oversight requires:

• Competence.
• Authority.
• Time.
• Information.
• Independence.
• Ability to override.
• Protection against automation bias.

17.13 Quality-management system​

A quality-management system establishes repeatable processes for:

• Development.
• Testing.
• Documentation.
• Approval.
• Change control.
• Vendor management.
• Monitoring.
• Corrective action.
• Continual improvement.

Quality management ensures governance is part of normal operations rather than dependent on individual effort.

17.14 General-purpose AI obligations​

General-purpose model providers may have responsibilities involving:

• Technical documentation.
• Information for downstream providers.
• Copyright-related compliance.
• Training-data information.
• Evaluation.
• Risk management.
• Cybersecurity.

More capable models presenting systemic risk may face additional obligations under the EU AI Act.

17.15 Enforcement​

Enforcement frameworks may include:

• Supervisory authorities.
• Market-surveillance authorities.
• AI offices.
• Investigations.
• Information requests.
• Audits.
• Corrective orders.
• Withdrawal.
• Restrictions.
• Penalties.

Governance professionals should understand that enforcement is not limited to fines.

A regulator may require an organization to:

• Stop processing.
• Correct documentation.
• Notify affected users.
• Withdraw a system.
• Restrict a feature.
• Improve controls.

18. Domain II.D — Standards and frameworks​

18.1 OECD AI Principles​

The OECD principles support innovative and trustworthy AI that respects human rights and democratic values.

The five values-based principles are:

1. Inclusive growth, sustainable development and well-being.
2. Human rights, democratic values and fairness.
3. Transparency and explainability.
4. Robustness, security and safety.
5. Accountability.

The OECD also provides recommendations for policymakers involving research, inclusive ecosystems, interoperable governance, human capacity and international cooperation.

Governance application​

An organization can translate the principles into:

• Policy commitments.
• Impact-assessment questions.
• Design requirements.
• Testing criteria.
• Reporting metrics.
• Supplier requirements.
• Audit controls.

18.2 NIST AI Risk Management Framework​

The NIST AI RMF is a voluntary, non-sector-specific and use-case-agnostic framework designed to help organizations manage AI risk and support trustworthy AI.

Its four core functions are:

• Govern.
• Map.
• Measure.
• Manage.

GOVERN​

Govern establishes the organization-wide environment for AI risk management.

It includes:

• Policies.
• Accountability.
• Risk culture.
• Roles.
• Training.
• Documentation.
• Third-party management.
• Executive oversight.

Govern applies across the other functions and throughout the lifecycle.

Example​

An organization defines:

• An AI governance committee.
• A risk-classification policy.
• An AI inventory.
• Impact-assessment requirements.
• Incident escalation.
• Model approval authority.

MAP​

Map establishes the context in which the AI system operates.

It includes:

• Intended purpose.
• Users.
• Affected stakeholders.
• Benefits.
• Harms.
• Data.
• Legal environment.
• System boundaries.
• Dependencies.
• Misuse scenarios.

Example​

For an AI recruitment system, Map would identify:

• Candidates.
• Recruiters.
• Hiring managers.
• Protected groups.
• Input data.
• Decision influence.
• Employment laws.
• Potential exclusion.
• Human-review process.

MEASURE​

Measure evaluates the identified risks and system characteristics.

It may include:

• Accuracy testing.
• Fairness testing.
• Security testing.
• Explainability testing.
• Robustness testing.
• Privacy assessment.
• Human-factors evaluation.
• Monitoring metrics.

Example​

The recruitment system may be tested for:

• Selection-rate differences.
• False-negative rates.
• Performance across job categories.
• Stability over time.
• Explanation quality.
• Recruiter override behaviour.

MANAGE​

Manage prioritizes and responds to risks.

Responses may include:

• Avoid.
• Mitigate.
• Transfer.
• Accept.
• Monitor.

Example​

The organization may decide to:

• Remove a biased feature.
• Require human review.
• Restrict the system to candidate prioritization.
• Set a lower automation level.
• Reject the use case.
• Accept a minor residual risk with monitoring.

NIST explains that Govern operates throughout the process, while Map, Measure and Manage can be applied to specific AI systems and lifecycle stages.

18.3 ISO/IEC 22989​

ISO/IEC 22989 establishes AI terminology and describes AI concepts.

Its governance value is consistency.

Without standard terminology, different teams may use words such as:

• Model.
• System.
• Autonomy.
• Learning.
• Agent.
• Provider.
• User.

in inconsistent ways.

Common terminology supports:

• Contracts.
• Policies.
• Regulatory analysis.
• Technical documentation.
• Cross-functional communication.
• Audit.

ISO states that the standard is applicable to different types of organizations and can support communication among diverse stakeholders.

18.4 ISO/IEC 42001​

ISO/IEC 42001 specifies requirements for an AI management system.

It follows a management-system approach covering areas such as:

• Organizational context.
• Leadership.
• AI policy.
• Roles.
• Planning.
• Risks and opportunities.
• Objectives.
• Operational controls.
• Performance evaluation.
• Continual improvement.

What an AI management system means​

It is the coordinated system of:

• Policies.
• Processes.
• Responsibilities.
• Resources.
• Controls.
• Reviews.
• Audits.
• Improvements.

used to manage AI consistently.

ISO 42001 is organizational in scope.

It is not simply a test of one individual model.

18.5 ISO/IEC 42005​

ISO/IEC 42005 provides guidance for AI system impact assessments.

It supports structured examination of how an AI system and its foreseeable uses may affect:

• Individuals.
• Groups.
• Society.

It also supports documentation, accountability and alignment with fairness, safety and human-centric values.

Typical impact-assessment questions​

• What is the intended purpose?
• Who is affected?
• What benefits are expected?
• What harms are possible?
• Are vulnerable groups affected?
• How serious could the harm be?
• How likely is it?
• What controls are available?
• What residual risk remains?
• Who approves the decision?
• How will impacts be monitored?

DOMAIN III — GOVERNING AI DEVELOPMENT​

Domain III covers designing, building, training, testing, releasing, monitoring and maintaining AI systems. It accounts for approximately 21–25 questions.

19. Domain III.A — Governing design and build​

19.1 Define the business context​

A project should begin with a clear business problem.

A useful use-case statement includes:

• Problem.
• Purpose.
• Intended users.
• Affected people.
• Expected benefit.
• Required performance.
• Decision influence.
• Scope.
• Exclusions.
• Alternatives.

Weak statement​

“We want to use generative AI in HR.”

Strong statement​

“We want to use an AI assistant to draft standardized answers to internal employee policy questions. Answers will be grounded in approved HR policies, displayed as drafts and reviewed by HR staff before being sent.”

The second statement defines:

• Purpose.
• Users.
• Data source.
• Human oversight.
• Decision limitation.

19.2 Determine whether AI is necessary​

Before approving AI, ask:

• Can a conventional rules-based system solve the problem?
• Can the process be improved without automation?
• Is sufficient data available?
• Does AI create a meaningful benefit?
• Is the benefit proportionate to the risk?
• Is the system likely to be maintained?
• Is the organization operationally ready?

Using AI because it is fashionable is not a sufficient business justification.

19.3 Requirements gathering​

Requirements should include more than functional features.

Functional requirements​

What the system must do.

Example:

• Classify incoming customer requests.
• Retrieve relevant policy documents.
• Draft an answer.

Performance requirements​

How well it must perform.

Example:

• Minimum classification accuracy.
• Maximum response latency.
• Maximum hallucination rate.
• Required availability.

Governance requirements​

How it must behave responsibly.

Example:

• Must not make binding decisions.
• Must not expose personal data.
• Must cite approved sources.
• Must escalate certain complaints.
• Must log outputs.
• Must allow human override.

19.4 Architecture selection​

Architecture affects:

• Data exposure.
• Control.
• Cost.
• Performance.
• Explainability.
• Vendor dependency.
• Security.
• Scalability.

Possible architectures include:

• Vendor-hosted API.
• Private cloud.
• On-premises model.
• Edge model.
• Retrieval-augmented system.
• Fine-tuned model.
• Agentic system.

Architecture should be selected according to the use case rather than solely according to model capability.

19.5 Model selection​

Model selection may consider:

• Accuracy.
• Latency.
• Cost.
• Explainability.
• Size.
• Security.
• Hosting.
• Language support.
• Multimodal capability.
• Vendor terms.
• Environmental impact.
• Regulatory obligations.
• Fine-tuning requirements.

The largest model is not always the most appropriate model.

A smaller model may provide:

• Lower cost.
• Lower latency.
• Easier local deployment.
• Reduced data exposure.
• Better control.

19.6 Human-oversight design​

Human oversight should be defined during design.

Questions include:

• Which outputs require review?
• Who performs the review?
• What information is available?
• Can the reviewer override the output?
• How is disagreement recorded?
• What happens when confidence is low?
• What happens outside business hours?
• Is the reviewer sufficiently trained?
• Could workload make review superficial?

19.7 Metrics and thresholds​

A metric measures an aspect of performance.

A threshold defines the level required for action or approval.

Example metrics​

• Accuracy.
• Precision.
• Recall.
• False-positive rate.
• False-negative rate.
• Hallucination rate.
• Toxicity rate.
• Latency.
• Availability.
• Human override rate.
• Escalation rate.
• Complaint rate.

Example threshold​

“The system may automatically classify a request only where confidence exceeds 90%. All lower-confidence cases must be sent to a human reviewer.”

Thresholds should reflect the harm associated with different errors.

19.8 Stakeholder engagement​

Relevant stakeholders may include:

• Users.
• Customers.
• Employees.
• Vulnerable groups.
• Subject-matter experts.
• Regulators.
• Civil-society organizations.
• Accessibility experts.

Stakeholder engagement can identify risks that technical testing may not reveal.

19.9 Probability-severity matrix​

Risk may be evaluated by combining:

• Probability of occurrence.
• Severity of harm.

A rare but catastrophic harm may require strong controls despite low probability.

19.10 Risk-mitigation hierarchy​

A useful hierarchy is:

1. Avoid the risk.
2. Eliminate the harmful feature.
3. Reduce the probability.
4. Reduce the severity.
5. Add detection and response.
6. Transfer part of the risk.
7. Accept residual risk.

Example​

For an AI medical system:

• Avoid: Do not allow autonomous diagnosis.
• Reduce: Limit the system to clinical decision support.
• Detect: Flag low-confidence results.
• Respond: Require specialist review.
• Accept: Document remaining limitations.

19.11 Benchmarking​

Benchmarking compares the system against:

• Baseline human performance.
• Existing software.
• Previous model versions.
• Industry datasets.
• Required standards.
• Competitor or vendor claims.

Benchmarking should use data relevant to the intended environment.

Excellent performance on a public benchmark does not guarantee acceptable performance in the organization’s actual use case.

19.12 Pilot testing​

A pilot limits the system to:

• A small group.
• A short period.
• A controlled environment.
• Nonbinding recommendations.
• Restricted data.

A pilot allows the organization to observe:

• User behaviour.
• Unexpected outputs.
• Operational impact.
• Oversight quality.
• Real-world performance.

Pilots should still have clear controls. “Pilot” should not mean “uncontrolled experiment.”

19.13 Design documentation​

Development documentation may include:

• Business case.
• Requirements.
• Architecture.
• Model-selection rationale.
• Impact assessment.
• Data decisions.
• Metrics.
• Thresholds.
• Test plans.
• Stakeholder feedback.
• Risk acceptances.
• Approvals.

The AIGP syllabus emphasizes documentation as evidence of compliance and risk management.

20. Domain III.B — Data, training and testing​

20.1 Lawful rights to data​

Before using data, confirm:

• Ownership.
• Licence.
• Consent.
• Contractual rights.
• Privacy-law basis.
• Restrictions.
• Retention.
• Geographic limitations.
• Intellectual-property conditions.

Public availability does not automatically mean unrestricted permission for AI training.

20.2 Data quality​

Data quality may include:

• Accuracy.
• Completeness.
• Consistency.
• Timeliness.
• Validity.
• Relevance.
• Uniqueness.

Example​

A customer dataset may contain:

• Duplicate records.
• Incorrect ages.
• Missing income information.
• Outdated addresses.
• Inconsistent categories.

The model may learn unreliable patterns from these errors.

20.3 Data quantity​

More data is not automatically better.

The organization needs enough relevant data to:

• Represent important cases.
• Train the model.
• Validate performance.
• Test edge cases.
• Assess groups.

A very large biased dataset remains biased.

20.4 Data integrity​

Integrity means data has not been altered improperly and remains trustworthy throughout processing.

Controls include:

• Hashing.
• Access control.
• Versioning.
• Change logs.
• Approval workflows.
• Secure pipelines.
• Validation checks.

20.5 Fit for purpose​

Data may be accurate but unsuitable for the use case.

Example​

Historical customer-service data may accurately record past complaints.

However, it may be unsuitable for training a system to detect current fraud because:

• The objective is different.
• Fraud patterns changed.
• Labels are incomplete.
• Relevant attributes are absent.

20.6 Data lineage​

Data lineage traces how data moves and changes.

It records:

• Source.
• Transfer.
• Transformation.
• Combination.
• Storage.
• Use.
• Output.

Example​

Customer application
→ identity verification
→ data-cleaning pipeline
→ feature calculation
→ model input
→ risk score
→ lending decision system

20.7 Data provenance​

Provenance concerns the origin and history of data.

Questions include:

• Who collected it?
• When?
• For what purpose?
• Under what permission?
• How was it labelled?
• Was it modified?
• Is the source trustworthy?
• Which model version used it?

Lineage is about the data’s movement.

Provenance is about its origin and history.

20.8 Training data​

Training data is used to adjust model parameters and teach the model patterns.

20.9 Validation data​

Validation data supports:

• Model selection.
• Hyperparameter tuning.
• Threshold setting.

20.10 Test data​

Test data provides an independent assessment of performance after development choices have been made.

Using the same data for training and final testing may produce an unrealistically positive result.

20.11 Unit testing​

Unit testing examines individual components.

Examples:

• Input validation.
• Feature calculation.
• Retrieval function.
• Content filter.
• API response handling.

20.12 Integration testing​

Integration testing examines whether components work together.

Examples:

• Model and database.
• Retrieval system and LLM.
• AI output and workflow.
• Human-review interface and logging.

20.13 Validation testing​

Validation determines whether the system meets its intended purpose and requirements.

It asks:

Did we build the right system for the business and risk context?

20.14 Performance testing​

Performance testing may assess:

• Accuracy.
• Precision.
• Recall.
• F1 score.
• False-positive rate.
• False-negative rate.
• Latency.
• Throughput.
• Availability.
• Cost.

Precision​

Of the items predicted positive, how many were actually positive?

Recall​

Of all actual positive items, how many did the system detect?

Example​

In fraud detection:

• High precision means most flagged transactions are genuinely suspicious.
• High recall means the system detects most suspicious transactions.

Increasing one may reduce the other.

The appropriate balance depends on:

• Cost of blocking legitimate payments.
• Cost of missing fraud.
• Availability of human review.

20.15 Security testing​

Security testing may examine:

• Unauthorized access.
• Prompt injection.
• Adversarial input.
• Data leakage.
• Model extraction.
• Tool misuse.
• Supply-chain vulnerabilities.
• Denial of service.
• Privilege escalation.

20.16 Bias testing​

Bias testing should examine:

• Performance by group.
• Selection rates.
• Error rates.
• Data representation.
• Proxy variables.
• Threshold effects.
• Intersectional groups.

Intersectional analysis considers combinations, such as:

• Age and gender.
• Disability and language.
• Ethnicity and location.

A system may appear fair across broad groups while disadvantaging a smaller intersectional group.

20.17 Interpretability testing​

Interpretability testing considers whether stakeholders can understand:

• Relevant features.
• Model behaviour.
• Output rationale.
• Limitations.
• Confidence.

The required level depends on the audience and decision.

20.18 Overfitting​

Overfitting occurs when a model learns the training data too closely and performs poorly on new data.

It may memorize:

• Noise.
• Accidental patterns.
• Dataset-specific features.

Warning signs​

• Very high training performance.
• Significantly lower test performance.
• Unstable real-world results.

20.19 Underfitting​

Underfitting occurs when a model is too simple or insufficiently trained to capture relevant patterns.

It performs poorly on both training and test data.

20.20 Data leakage​

Data leakage occurs when information unavailable at the time of a real decision improperly influences model training or evaluation.

Example​

A model predicting loan default includes information recorded after the customer already defaulted.

The model may appear highly accurate during testing but fail in production.

20.21 Data poisoning​

Data poisoning occurs when an attacker or unreliable process introduces harmful data into training or feedback data.

The objective may be to:

• Reduce performance.
• Create a backdoor.
• Manipulate specific outputs.
• Introduce bias.

20.22 Testing documentation​

Records should identify:

• Dataset version.
• Model version.
• Test environment.
• Metrics.
• Thresholds.
• Results.
• Failures.
• Exceptions.
• Reviewers.
• Approval.
• Known limitations.

The syllabus explicitly requires documentation of training and testing to validate results, establish compliance and manage risk.

21. Domain III.C — Release, monitoring and maintenance​

21.1 Production readiness​

Before release, verify:

• Approved purpose.
• Risk classification.
• Completed impact assessment.
• Data approval.
• Test completion.
• Security approval.
• Privacy approval.
• Human oversight.
• Monitoring.
• Incident process.
• User training.
• Documentation.
• Rollback capability.

A useful release decision is:

• Approve.
• Approve with conditions.
• Delay.
• Reject.

21.2 Model card​

A model card summarizes important information about a model.

It may include:

• Model name.
• Version.
• Developer.
• Purpose.
• Intended use.
• Prohibited use.
• Training information.
• Performance.
• Group-level results.
• Limitations.
• Ethical considerations.
• Security considerations.
• Contact point.

A model card supports transparency but does not replace:

• Full technical documentation.
• Impact assessment.
• Testing evidence.
• User instructions.

The AIGP syllabus specifically identifies model-card creation as a production-readiness activity.

21.3 Continuous monitoring​

Monitoring should assess whether the system remains:

• Accurate.
• Reliable.
• Safe.
• Fair.
• Secure.
• Compliant.
• Fit for purpose.

Monitoring metrics​

• Performance.
• Data quality.
• Data drift.
• Model drift.
• Latency.
• Availability.
• Error rate.
• Override rate.
• Complaints.
• Security incidents.
• Harm reports.
• Usage outside approved scope.

21.4 Data drift​

Data drift occurs when production input data changes compared with the data used for development.

Example​

A fraud model was trained before a new digital-payment method became common.

Transaction patterns change, reducing model effectiveness.

21.5 Model drift​

Model drift generally refers to deterioration in the relationship between inputs and intended outcomes.

Patterns that were previously predictive may no longer be valid.

Example​

A customer-churn model relies heavily on office attendance.

After widespread remote working, the relationship between attendance and resignation changes.

21.6 Concept drift​

Concept drift occurs when the meaning or relationship the model is trying to predict changes.

It is closely related to model drift and is often used to describe changes in the underlying real-world concept.

21.7 Maintenance​

Maintenance may include:

• Data updates.
• Model retraining.
• Software patches.
• Security fixes.
• Threshold changes.
• Prompt updates.
• Retrieval-index updates.
• Policy updates.
• Vendor-version assessment.

Every material change should undergo an appropriate level of review and regression testing.

21.8 Audit​

An audit examines whether the system and governance programme conform to defined criteria.

Audits may evaluate:

• Policies.
• Documentation.
• Control operation.
• Legal compliance.
• Technical performance.
• Monitoring.
• Accountability.
• Incident handling.

21.9 Red teaming​

Red teaming involves deliberately attempting to make the system fail or behave harmfully.

Tests may attempt to produce:

• Unsafe content.
• Confidential-data leakage.
• Discriminatory outputs.
• Prompt-injection success.
• Unauthorized tool actions.
• Policy bypass.
• Hallucinations.

Red teaming complements ordinary testing because it adopts an adversarial mindset.

21.10 Threat modelling​

Threat modelling identifies:

• Assets.
• Threat actors.
• Attack surfaces.
• Vulnerabilities.
• Attack paths.
• Consequences.
• Mitigations.

For an AI agent, assets might include:

• Email.
• Customer records.
• Payment permissions.
• API credentials.
• Internal documents.

21.11 Incident management​

When an incident occurs, the organization should determine:

• What happened?
• Who was affected?
• Is the issue continuing?
• What model and data versions were involved?
• Was a control absent or ineffective?
• Is notification required?
• Should the system be suspended?
• How can recurrence be prevented?

The syllabus identifies causes such as:

• Brittleness.
• Lack of robustness.
• Poor-quality data.
• Insufficient testing.
• Model drift.
• Data drift.

21.12 Brittleness​

A brittle system performs well under expected conditions but fails sharply under small or unfamiliar changes.

Example​

An image system accurately identifies clean product photographs but fails when:

• Lighting changes.
• The image is rotated.
• The background changes.
• The camera quality is lower.

21.13 Robustness​

Robustness is the ability to maintain acceptable performance under:

• Noise.
• Variation.
• Adversarial input.
• Unexpected conditions.
• Component failure.

21.14 Public disclosures​

Disclosures may include:

• Technical documentation.
• Instructions for use.
• Known limitations.
• Transparency notices.
• Post-market monitoring information.
• Incident reports.

The amount of disclosure depends on:

• Audience.
• Law.
• Risk.
• Confidentiality.
• Security.
• Contract.

DOMAIN IV — GOVERNING DEPLOYMENT AND USE​

Domain IV accounts for approximately 21–25 questions and covers model selection, deployment options, vendor assessment, continuous monitoring, downstream risk and system deactivation.

22. Domain IV.A — Deciding whether and how to deploy AI​

22.1 Business objective​

The organization should define:

• Desired outcome.
• Performance requirement.
• Cost.
• Timeframe.
• Users.
• Affected stakeholders.
• Decision significance.
• Success criteria.

A valid objective should not be:

“Use AI because competitors are using it.”

22.2 Data availability​

Questions include:

• Is sufficient data available?
• Is the data lawful?
• Is it representative?
• Is it current?
• Can it be accessed securely?
• Does it contain protected information?
• Can it support testing?
• Will production data match development data?

22.3 Ethical considerations​

Ethical deployment questions include:

• Is the purpose appropriate?
• Is the use proportionate?
• Are vulnerable people affected?
• Does the system manipulate behaviour?
• Can individuals challenge outcomes?
• Is the process accessible?
• Is the system replacing essential human contact?

22.4 Workforce readiness​

Workforce readiness includes:

• Skills.
• Training.
• Process redesign.
• User acceptance.
• Human oversight.
• Support.
• Escalation.
• Change management.

A technically successful system may fail if:

• Users do not trust it.
• Users overtrust it.
• Employees lack time to review outputs.
• Responsibilities are unclear.
• The workflow does not support escalation.

23. Comparing model types​

23.1 Classical versus generative​

Classical​

Best suited to:

• Prediction.
• Classification.
• Ranking.
• Optimization.

Generative​

Best suited to:

• Drafting.
• Summarization.
• Conversation.
• Content creation.
• Flexible knowledge work.

Governance distinction​

Generative AI usually introduces greater risks involving:

• Hallucination.
• Open-ended output.
• Copyright.
• Harmful content.
• Prompt injection.

23.2 Proprietary versus open source​

Proprietary model​

Potential advantages:

• Vendor support.
• Managed infrastructure.
• Service commitments.
• Regular updates.

Potential risks:

• Limited transparency.
• Vendor dependence.
• Data-use concerns.
• Unannounced changes.
• Limited audit rights.

Open-source model​

Potential advantages:

• Greater control.
• Local deployment.
• Inspection.
• Customization.
• Reduced vendor dependency.

Potential risks:

• Internal maintenance burden.
• Security responsibility.
• Licence obligations.
• Limited support.
• Unknown training data.
• Misconfiguration.

23.3 Small versus large models​

Large model​

Potential advantages:

• Broad capability.
• Strong general performance.
• Flexible tasks.

Potential disadvantages:

• Cost.
• Latency.
• Energy use.
• Complexity.
• Harder local deployment.
• Greater attack surface.

Small model​

Potential advantages:

• Lower cost.
• Faster response.
• Easier edge deployment.
• Greater control.
• Task specialization.

Potential disadvantages:

• Narrower capability.
• Lower general reasoning performance.
• More task-specific training.

23.4 Language versus multimodal​

Language models process text.

Multimodal systems may process combinations of:

• Text.
• Image.
• Audio.
• Video.
• Sensor data.

Multimodal systems may create additional risks involving:

• Biometrics.
• Sensitive visual information.
• Synthetic media.
• Cross-modal inference.
• Accessibility.
• Differential performance.

24. Deployment options​

24.1 Cloud​

Advantages:

• Scalability.
• Managed infrastructure.
• Rapid implementation.
• Access to powerful models.

Risks:

• Data transfer.
• Vendor lock-in.
• Subprocessors.
• Shared responsibility.
• Availability dependency.
• Geographic hosting.

24.2 On-premises​

Advantages:

• Greater infrastructure control.
• Local data.
• Custom security.
• Reduced external transfer.

Risks:

• Cost.
• Maintenance.
• Skills.
• Hardware.
• Patching.
• Scalability.

24.3 Edge​

Edge deployment runs the model near the user or device.

Advantages:

• Low latency.
• Offline operation.
• Reduced data transfer.
• Greater local privacy.

Risks:

• Device security.
• Limited computing power.
• Difficult updates.
• Physical compromise.
• Distributed monitoring.

24.4 Using the model as-is​

Advantages:

• Faster deployment.
• Lower development cost.
• Vendor-supported behaviour.

Risks:

• Limited customization.
• Generic performance.
• Lack of domain grounding.
• Reduced control.

24.5 Fine-tuning​

Fine-tuning further trains a model on task-specific data.

Potential benefits:

• Better domain language.
• More consistent style.
• Improved task performance.

Risks:

• Training-data rights.
• Privacy.
• Bias.
• Overfitting.
• Cost.
• Version management.
• Need for retesting.

24.6 Retrieval-augmented generation​

RAG retrieves relevant information from an external knowledge source and supplies it to the generative model.

Basic flow​

User question
→ search approved documents
→ retrieve relevant passages
→ provide passages to model
→ generate grounded response

Benefits​

• Improved grounding.
• Current information.
• Source control.
• Potential citations.
• Reduced need for model retraining.

Risks​

• Incorrect retrieval.
• Outdated documents.
• Excessive access.
• Permission leakage.
• Malicious documents.
• Prompt injection through retrieved content.
• Incomplete sources.

Governance controls​

• Approved knowledge sources.
• Document ownership.
• Access filtering.
• Freshness review.
• Retrieval evaluation.
• Source citations.
• Document sanitization.
• Logging.

24.7 Agentic architecture​

An agentic architecture gives the model access to tools and allows it to perform multistep tasks.

Controls should consider:

• Tool permissions.
• Action limits.
• Approval checkpoints.
• Memory.
• Identity.
• Logging.
• Reversibility.
• Stopping conditions.
• External communication.
• Financial transactions.

The AIGP Body of Knowledge explicitly includes fine-tuning, RAG and agentic architectures among deployment options candidates should understand.

25. Domain IV.B — Assessing a selected AI system​

25.1 Deployment impact assessment​

The assessment should evaluate the actual configuration.

For example, it should not assess only “use of an LLM.”

It should assess:

• The specific model.
• Version.
• Prompt.
• Data.
• Retrieval sources.
• Users.
• Decisions.
• Integrations.
• Geography.
• Human oversight.
• Monitoring.

25.2 Vendor agreement assessment​

Important clauses include:

Data use​

• Can the vendor use prompts for training?
• Can the vendor retain outputs?
• Who owns uploaded data?

Security​

• What controls are required?
• How quickly must incidents be reported?
• Are penetration-test results available?

Intellectual property​

• Who owns outputs?
• Does the vendor provide indemnification?
• What happens if generated content infringes rights?

Model changes​

• Can the vendor replace the model?
• Must it provide notice?
• Can the customer reject a material change?

Audit​

• Can the organization inspect controls?
• Are third-party assurance reports available?
• Will the vendor support regulatory inquiries?

Exit​

• Can data be exported?
• Will data be deleted?
• Is transition assistance available?
• Can the model configuration be preserved?

25.3 Proprietary AI model​

Building a proprietary model offers:

• Greater customization.
• Control.
• Potential competitive advantage.
• Direct access to technical information.
• Reduced external dependency.

It also creates:

• Higher development cost.
• Greater maintenance burden.
• Data responsibility.
• Security responsibility.
• Compliance obligations.
• Potential liability.
• Need for internal expertise.

The organization cannot transfer responsibility merely because the system is technically sophisticated.

26. Domain IV.C — Governing deployment and use​

26.1 Operational controls​

Deployment controls may include:

• Role-based access.
• Authentication.
• Input validation.
• Human approval.
• Output filtering.
• Logging.
• Data-loss prevention.
• Usage limits.
• Escalation.
• User training.
• Monitoring.
• Version control.

26.2 User training​

Users should understand:

• Intended purpose.
• Prohibited uses.
• Limitations.
• Verification requirements.
• Human responsibility.
• Data restrictions.
• Escalation.
• Incident reporting.

A warning displayed once during system launch is not necessarily sufficient training.

26.3 Continuous monitoring​

Monitoring in deployment should compare:

• Current performance.
• Approved thresholds.
• Baseline performance.
• Group-level performance.
• Previous versions.
• Complaint patterns.
• Human overrides.
• Emerging risks.

26.4 Periodic assurance​

Periodic activities may include:

• Audit.
• Red teaming.
• Threat modelling.
• Security testing.
• Bias reassessment.
• Impact-assessment refresh.
• Vendor reassessment.
• Legal review.

The syllabus requires both continuous monitoring and periodic assessment. They are related but different.

Continuous monitoring​

Occurs routinely or automatically.

Periodic assessment​

Occurs at defined intervals or trigger events and provides a deeper review.

26.5 Secondary use​

Secondary use occurs when a system or its outputs are used for another purpose.

Example​

A customer-service sentiment score is later used for:

• Fraud detection.
• Credit decisions.
• Employee-performance evaluation.

The new use may require:

• New lawful basis.
• New impact assessment.
• New testing.
• New approval.
• Updated notice.

26.6 Unintended use​

Unintended use occurs when people use the system outside its designed purpose.

Example​

A summarization assistant is used to provide legal advice.

Controls may include:

• Technical restrictions.
• User training.
• Warning messages.
• Usage monitoring.
• Access limits.
• Policy enforcement.

26.7 Downstream harm​

Downstream harm occurs when an output causes consequences beyond the immediate system.

Example​

An AI system incorrectly labels a person as high risk.

That label is shared with:

• Insurers.
• Employers.
• Banks.
• Public agencies.

Even if the original system only produced a recommendation, downstream reliance multiplies the harm.

26.8 External communication plan​

An organization should plan communication for:

• Customers.
• Employees.
• Regulators.
• Vendors.
• Partners.
• Media.
• The public.

The plan should define:

• Who communicates.
• What information is disclosed.
• When disclosure occurs.
• Legal review.
• Technical validation.
• Consistency.
• Contact channels.

26.9 Deactivation​

A deactivation policy should define triggers such as:

• Serious incident.
• Regulatory prohibition.
• Security vulnerability.
• Unacceptable bias.
• Performance degradation.
• Vendor failure.
• Missing documentation.
• Change in business purpose.

Deactivation capabilities may include:

• Emergency stop.
• Feature disablement.
• User-access removal.
• Model rollback.
• API revocation.
• Manual fallback.

26.10 Localization​

Localization may involve adapting or restricting the system according to:

• Local laws.
• Language.
• Cultural context.
• Data-location requirements.
• Performance differences.
• Regional risk.

A system performing well in one country may not perform appropriately in another because of:

• Language.
• Demographics.
• Legal rules.
• Social expectations.
• Available data.
• User behaviour.

27. Complete worked example: AI recruitment system​

Consider a company proposing an AI system to rank job applicants.

Stage 1: Define the purpose​

The company documents:

• Roles covered.
• Applicant population.
• Data used.
• Ranking method.
• Human-review process.
• Expected benefits.
• Success metrics.

It prohibits the system from making final hiring decisions.

Stage 2: Identify stakeholders​

Stakeholders include:

• Applicants.
• Recruiters.
• Hiring managers.
• HR.
• Diversity and inclusion.
• Legal.
• Privacy.
• Security.
• Vendor.
• Regulators.

Stage 3: Assess risks​

Risks include:

• Discrimination.
• Proxy variables.
• Incorrect rejection.
• Lack of explanation.
• Excessive personal data.
• Accessibility barriers.
• Vendor data reuse.
• Automation bias.

Stage 4: Evaluate legal requirements​

The company assesses:

• Employment law.
• Nondiscrimination law.
• Privacy law.
• Automated decision-making.
• AI-specific regulation.
• Required notices.

Stage 5: Assess data​

The company checks:

• Historical hiring bias.
• Representation.
• Label quality.
• Missing groups.
• Data rights.
• Sensitive attributes.
• Proxy variables.

Stage 6: Select architecture​

The company chooses a vendor-hosted model but prohibits the vendor from using candidate data for general model training.

Stage 7: Define metrics​

Metrics include:

• Job-relevance accuracy.
• Selection rates.
• False-negative rates.
• Group-level performance.
• Human override.
• Applicant complaints.

Stage 8: Establish oversight​

Recruiters must review:

• All rejections.
• Low-confidence rankings.
• Accommodation requests.
• Unusual candidate histories.

Stage 9: Test​

Testing includes:

• Validation.
• Bias analysis.
• Security.
• Accessibility.
• Explanation quality.
• Workflow testing.

Stage 10: Pilot​

The company pilots the system for one job family.

No candidate is automatically rejected.

Stage 11: Release​

Release requires:

• AI committee approval.
• Legal approval.
• Privacy approval.
• Security approval.
• Completed documentation.
• User training.
• Monitoring dashboard.

Stage 12: Monitor​

The company reviews:

• Group selection rates.
• False negatives.
• Recruiter overrides.
• Complaints.
• Data drift.
• Model changes.

Stage 13: Incident​

Monitoring reveals that applicants with career breaks are ranked lower.

The company:

1. Suspends automatic ranking.
2. Investigates the feature.
3. Assesses whether caring responsibilities or disability are indirectly affected.
4. Removes or redesigns the feature.
5. Retests the model.
6. Reviews affected applicants.
7. Documents corrective action.

This example connects all four AIGP domains.

28. How AIGP questions are likely to test these concepts​

IAPP states that the examination primarily uses the remember, understand, apply and analyze levels of Bloom’s Taxonomy.

Remember​

Which principle concerns unjustified differences between groups?

Answer: Fairness.

Understand​

Why does a probabilistic AI system require ongoing monitoring?

Because its outputs may vary and its performance can change as data and operating conditions change.

Apply​

A company wants to use customer-support recordings to train an employee emotion-recognition system. What should it do first?

The strongest answer will likely involve assessing the new purpose, lawful data use and impact before training begins.

Analyze​

A recruitment model is accurate overall but has a significantly higher false-negative rate for one group. What is the most important concern?

The answer is likely the differential harm and fairness risk, not only overall accuracy.

29. Common exam traps​

29.1 Choosing a technical control when governance is missing​

If no owner or use-case approval exists, additional model testing may not solve the fundamental problem.

29.2 Treating transparency and explainability as identical​

Disclosure that AI is used is transparency.

Understanding why an output occurred is explainability.

29.3 Assuming human involvement automatically equals oversight​

Human review must be meaningful.

29.4 Selecting the most advanced technology​

The most capable model is not always the most appropriate.

29.5 Focusing only on accuracy​

A system can be accurate overall but unfair, insecure, unsafe or unlawful.

29.6 Treating compliance as a one-time assessment​

AI governance continues through monitoring, maintenance, incidents and retirement.

29.7 Assuming the vendor carries all responsibility​

Deployers remain responsible for their own context, data, configuration, users and decisions.

29.8 Choosing consent automatically​

Consent is not always required or appropriate. The correct lawful basis depends on jurisdiction and context.

29.9 Collecting more data by default​

More data can increase privacy, security, bias and quality risks.

29.10 Retraining immediately after every performance problem​

The correct response may first require:

• Investigation.
• Data correction.
• Threshold adjustment.
• Process change.
• Human oversight.
• System suspension.

30. Current exam and preparation information​

The IAPP exam store states that the AIGP examination:

• Contains 100 questions.
• Has an allotted time of 2.75 hours.
• Includes a 15-minute break.
• May be taken through Pearson VUE at a testing centre or remotely.
• Must be completed within one year of purchase.

The current Body of Knowledge indicates the minimum and maximum number of questions expected from each domain. IAPP recommends using the Body of Knowledge to allocate study time according to the blueprint and generally recommends at least 30 hours of preparation, while recognizing that individual needs vary.

A realistic preparation plan for someone seeking strong practical understanding would be closer to 50–70 hours, especially when privacy law, AI regulation and formal governance are new subjects.

31. Recommended study order​

Stage 1 — Learn the foundations​

Study:

• AI system terminology.
• Model versus system.
• AI risks.
• Responsible-AI principles.
• Governance roles.

Stage 2 — Study law and standards​

Focus on:

• Privacy principles.
• Discrimination.
• Intellectual property.
• Consumer protection.
• AI risk classifications.
• NIST AI RMF.
• OECD principles.
• ISO 22989, 42001 and 42005.

Stage 3 — Learn lifecycle governance​

Follow a system through:

1. Use-case proposal.
2. Impact assessment.
3. Data.
4. Development.
5. Testing.
6. Release.
7. Monitoring.
8. Incident.
9. Retirement.

Stage 4 — Practise scenario questions​

For every scenario, ask:

1. What is the use case?
2. Who could be harmed?
3. What lifecycle stage is this?
4. Who is accountable?
5. What law or principle applies?
6. What is the most fundamental missing control?
7. What should happen before the organization proceeds?

Stage 5 — Final revision​

Prioritize:

• Domain III.
• Domain IV.
• Domain II.C.
• Differences between similar concepts.
• Scenario-based application.

32. Final memory framework​

Use the following sequence whenever analysing an AI governance problem:

PURPOSE​

Why is the AI system being used?

PEOPLE​

Who uses it, and who could be affected?

PERMISSION​

Is the data and activity legally permitted?

PRINCIPLES​

Are fairness, safety, privacy, transparency, accountability and human-centricity addressed?

PROCESS​

What lifecycle policies and approvals apply?

PERFORMANCE​

How will accuracy, fairness, reliability and security be tested?

PROTECTION​

What technical, organizational and human controls reduce risk?

PROOF​

What documentation demonstrates the decision and control operation?

PRODUCTION​

How will the system be deployed and monitored?

PROBLEMS​

How will incidents, drift, complaints and failures be managed?

PAUSE​

When must the organization restrict, suspend or deactivate the system?

That framework captures the central logic of the AIGP syllabus:

Govern the organization, understand the context, assess the impact, control the lifecycle, monitor the outcome and remain accountable.

Related reading​

• AI Governance: NIST AI RMF and the EU AI Act
• EU AI Act Application Playbook
• AI Governance: ISO/IEC 42001
• OWASP LLM Top 10 governance
• Responsible AI and Governance