AIGP common mistakes
AIGP · Understand the traps and how to avoid them.
When a stem describes a use case (e.g., predicting loan default from structured tabular data, or ranking candidates from free-text CVs), the candidate selects a model family by buzzword association - picking a generative LLM or 'deep learning' because it appears in recent headlines - rather than by matching data type, label availability, need for calibrated uncertainty, latency, and explainability constraints.
Candidates memorise model names from news coverage and skip the requirements-to-technique mapping step; generative AI dominates attention, so it becomes the default answer even for problems where simpler supervised or even rule-based methods are the better governance choice.
What to do instead
Before answering, write down the four or five use-case constraints from the stem (data modality, labelled vs unlabelled, need for probability estimates, latency/compute budget, explainability demand) and eliminate options that fail a stated constraint; practise classifying use cases into supervised, unsupervised, reinforcement, generative, and symbolic/rule-based categories with one governance-relevant rationale per choice.
The candidate equates 'AI system' with machine learning or with large language models, so questions about autonomy, inference, adaptivity, or rule-based expert systems get answered as if only trained statistical models count; consequently they misjudge whether a described system falls in or out of scope of a definition or obligation.
Most public discourse and vendor marketing uses 'AI' as a synonym for generative ML, so candidates import that narrow usage into exam stems that deliberately describe a non-ML or hybrid system.
What to do instead
Memorise the widely used governance definition (a machine-based system that infers, from input it receives, how to generate outputs such as predictions, content, recommendations or decisions, with varying levels of autonomy and adaptivity) and test each stem scenario against each element - inference, autonomy, adaptivity, goal orientation - rather than against 'is it a neural network'.
The candidate places a described system in the wrong tier of the EU AI Act's risk pyramid, or treats general-purpose AI obligations as if they were an additional high-risk requirement, or assumes a prohibited practice becomes permissible with disclosure or consent.
The Act layers several distinct regimes (prohibited practices, high-risk under Annex III and product-safety routes, limited-risk transparency duties, minimal-risk, plus a separate GPAI chapter), and candidates collapse them into a single 'high-risk or not' question.
What to do instead
Build and rehearse a one-page decision tree: first ask 'is the practice prohibited?', then 'is it a product-safety or Annex III high-risk use?', then 'is there a transparency obligation (chatbot, synthetic content, emotion recognition, deepfake)?', and treat GPAI provider duties (technical documentation, copyright policy, systemic-risk evaluation) as a parallel track. Note that transparency and consent do not cure a prohibition.
The candidate assigns obligations to the wrong actor - describing a deployer's duties as a provider's, or assuming a user who substantially modifies or rebrands a system stays a deployer rather than becoming a provider.
Frameworks use role-based allocation (provider/developer, deployer/user, importer, distributor, authorised representative), and candidates learn 'the organisation must...' lists without attaching each duty to a specific role.
What to do instead
For every framework you study, make a three-column table: actor, trigger for that role, core obligations. Specifically rehearse the re-branding/substantial-modification rule that converts a deployer into a provider, and the deployer-specific duties (human oversight, input data relevance, monitoring, informing affected persons).
The candidate treats NIST AI RMF, ISO/IEC 42001, the OECD AI Principles, and UNESCO's Recommendation as interchangeable - for example, describing the NIST framework as certifiable, ISO/IEC 42001 as government-enforced law, or the OECD Principles as a technical control catalogue.
All are described in similar 'responsible AI' language, so candidates match on content keywords and ignore the structural differences in issuer, legal force, auditability, and intended audience.
What to do instead
Memorise a comparison grid with four columns: issuer and type (standards body, government agency, intergovernmental organisation), voluntary vs certifiable vs legally binding, what artefact it produces (management system, risk process, principles, control set), and who it is written for. Anchor each framework with one distinctive fact (e.g., ISO/IEC 42001 is a certifiable management-system standard; the NIST AI RMF is voluntary and process-oriented with govern/map/measure/manage functions).
The candidate answers lifecycle questions as if governance ends at the pre-deployment approval or procurement sign-off, so they omit post-deployment monitoring, performance drift detection, incident response, change management, re-validation after model updates, and decommissioning or retirement of the system.
Organisational narratives and exam-prep summaries foreground 'approve the model' gates, and candidates reproduce a stage-gate diagram while dropping the continuous-operations half of the lifecycle.
What to do instead
Draw the lifecycle as a loop, not a line, and for each phase name one governance artefact (use-case intake and triage, data provenance record, evaluation and red-team report, deployment decision record, monitoring dashboard with thresholds, incident log, retirement record). In any scenario question, ask 'what happens after go-live?' before selecting an answer.
The candidate uses risk vocabulary loosely - treating inherent risk and residual risk as the same number, answering an impact-assessment question with a risk-assessment answer (or vice versa), or claiming a risk is 'acceptable' without referencing the organisation's stated risk appetite or tolerance.
The terms appear in overlapping documents and candidates learn definitions in isolation without a model of how they relate arithmetically and procedurally.
What to do instead
Fix a mental formula: inherent risk = likelihood x severity before controls; residual risk = after controls, compared against a documented tolerance threshold set by risk appetite. Separately learn that an impact assessment examines effects on people, groups, and rights (who is affected, how severely, can they contest), while a risk assessment examines the organisation's objectives and likelihood of harm - then check which noun the stem actually uses.
The candidate treats a vendor's assurances, a third-party audit certificate, or a model card as transferring accountability, and writes answers that omit contractual controls, ongoing supplier monitoring, and the deploying organisation's own due diligence and validation before and during use.
Certificates and supplier documentation feel authoritative and reduce perceived workload, so candidates assume they close the risk rather than inform it - a classic outsourcing reflex carried over from other compliance domains.
What to do instead
Adopt the rule 'accountability does not transfer with the model'. For every supply-chain scenario, answer from the deploying organisation's duties: pre-contract due diligence and use-case fit, contractual terms (audit rights, incident notification, data-use limits, change notification), independent validation, and periodic reassessment including supplier model-version changes.
On emerging-issues questions the candidate picks the most absolute option available - 'AI output can never be copyrighted', 'an AI system can never bear legal responsibility', 'open-weight release is always irresponsible' - instead of the option that reflects the current state of the debate and the conditions under which positions shift.
Ambiguity feels unsafe in a multiple-choice format, and candidates convert a contested, fact-dependent question into a bright-line rule so they can answer decisively.
What to do instead
For each debated topic, write a two-sided card: what is settled, what is contested, and which facts move the answer (degree of human creative control; documented human oversight and attribution; capability level and available safeguards; jurisdiction). Practise choosing the conditional answer ('depends on whether X is documented') over the categorical one when the stem supplies unresolved facts.
The candidate collapses distinct transparency concepts - answering a question about disclosing that a person is interacting with an AI, or about the use of training data, with an answer about explaining an individual decision, or vice versa; similarly, they mix input-side IP questions (lawful use of protected works in training) with output-side questions (infringement or authorship in generated content).
All of these are tagged 'transparency' or 'IP' in preparatory material, and candidates pattern-match the keyword rather than the specific obligation and the direction of the data flow.
What to do instead
Build a disambiguation table with rows for disclosure of AI interaction, disclosure of synthetic or manipulated content, explanation of a specific automated decision, publication of training-data summaries or copyright policy, and model/system documentation - each with its own trigger and audience. For IP, always label the question 'input (training)' or 'output (generation)' before evaluating any option.