AIGP Sample Questions: What the Real Exam Format Looks Like

In the 2026 BoK v2.1, the distinction between Provider (the developer who places an AI system on the market) and Deployer (the organization that uses it in a professional context) is one of the most exam-critical concepts across all four domains. Under the EU AI Act, Providers of high-risk AI systems are legally obligated to supply technical documentation and instructions for use that enable Deployers to fulfill their own downstream compliance obligations. The Deployer must conduct an impact assessment — but they cannot do so if the Provider has failed their upstream transparency requirements. The governance failure originates squarely with the Provider.

Option A is a role-reversal trap. Human oversight is indeed a Deployer obligation under the EU AI Act — but the question asks what caused the current compliance failure. The Deployer cannot implement oversight for an assessment they were unable to conduct. Choosing A mistakes the downstream symptom for the upstream cause. Option C inverts the regulatory architecture entirely. It is factually false: Providers hold primary responsibility for technical documentation under Annex IV of the EU AI Act. Deployers may need to supplement documentation for their specific use case, but they are never "solely responsible" for generating it from scratch. This answer exploits the test-taker's possible uncertainty about the boundary between Provider and Deployer duties. Option D is the most dangerous distractor in the set because it contains a grain of real-world commercial reasoning — vendors frequently attempt to shield proprietary architectures behind confidentiality claims. However, the EU AI Act explicitly rejects this argument for high-risk systems. No proprietary exemption exists that allows a Provider to withhold the documentation necessary for a Deployer's compliance.

The question contains a critical qualifier: "bias that may emerge due to real-world data drift." Data drift occurs when the statistical distribution of real-world inputs diverges from the distribution of the original training data — a post-deployment phenomenon. Disparity testing (also called disparate impact analysis or fairness auditing) is the technical mechanism used to continuously measure whether a deployed system's outputs differ in rate or quality across legally protected demographic groups. Because drift-induced bias only manifests in production, this testing must be ongoing against live output data — not conducted once at deployment and then discontinued.

Option A is an organizational mitigation measure, not a technical detection mechanism. Awareness training for underwriters addresses human behavior in the review process but provides zero data-driven signal about whether the AI model itself is producing disparate outcomes across groups. It is a governance control, not a measurement tool. Option B addresses audit trail completeness and is a valid governance practice — but documentation of decisions describes what happened after the model scored an application, not whether the scoring itself was fair. Auditability enables a future investigation; disparity testing triggers that investigation in the first place. These are related but categorically distinct activities. Option D is the canonical "lifecycle phase" trap. Re-analyzing training data quality is a critically important pre-deployment activity — and many candidates who have studied thoroughly will recognize it as a best practice. The trap is that it belongs to Domain III (Governing AI Development), not Domain IV. Historical training data analysis cannot detect bias patterns introduced by new real-world inputs that the model has never encountered. Choosing D is an error of context, not an error of knowledge.

Retrieval-Augmented Generation (RAG) is a hybrid architecture that enhances a large language model by fetching relevant, up-to-date facts from a trusted internal knowledge source at the time of query execution. In this scenario, the "trusted source" is the firm's daily pricing rules database. Because the retrieval step occurs at inference time — not at the point of training — the chatbot's responses are anchored to current institutional data, not static parametric knowledge. This "contextual grounding" is the primary architectural defense against hallucinations in regulated environments where factual precision is a legal and consumer protection requirement. The BoK v2.1 explicitly tests RAG as the governance-preferred solution for grounding generative outputs in dynamic, domain-specific facts.

Option A — Agentic Architecture is a high-frequency distractor in 2026 because it is explicitly covered as a new addition to BoK v2.1. Agentic systems are designed to take autonomous, multi-step actions — browsing, executing code, submitting forms. This architecture introduces its own governance risks (auditability, human oversight, reversibility) and does not inherently solve the hallucination problem. A well-read candidate may select A because they know it is "new and important," which is precisely why the examiner included it. Option C — Expert System targets candidates who conflate "being grounded in rules" with rule-based AI architectures. Expert systems encode domain knowledge as explicit logical rules and were the dominant AI paradigm before machine learning. While they are deterministic and rule-bound, they cannot process natural language queries and are architecturally incompatible with the conversational chatbot described in the stem. The distractor exploits the semantic overlap between "pricing rules" and "rule-based systems." Option D — Classic Machine Learning is the elimination option. A classical ML model — such as a gradient-boosted classifier — can score a loan application against historical data, but it cannot generate natural language responses or retrieve dynamic external content. It does not qualify as the architecture for a generative chatbot and fails the basic requirement of the stem. Candidates who choose D have likely misread the question as asking about the underlying scoring engine rather than the customer-facing chatbot layer.