IAAA VantageAIGP PrepEverything the exam loves to conflate.
Every side-by-side comparison table across the curriculum, gathered in one place — 22 tables total. Each links back to its source concept for full context.
The three classic ML paradigms
| Supervised | Unsupervised | Reinforcement | |
|---|---|---|---|
| Learns from | Labeled examples — an answer key attached to each one | Unlabeled data — no answer key at all | Trial-and-error, guided by a reward signal |
| Governance-relevant picture | Studying with a marked answer key | Sorting objects into piles nobody named | Training a dog with treats |
| Primary risk | Inherits whatever bias is baked into the historical labels | Creates categories nobody defined and can encode proxy discrimination invisibly | Reward-hacking — achieves the metric while defeating the actual intent |
| Where you'll see it | Credit scoring, hiring screens, medical triage | Customer segmentation, anomaly detection | Recommender systems, robotics, RLHF alignment of LLMs |
⚠ Two hybrids build on this table and are worth knowing by name: self-supervised learning (a model generates its own labels from raw data — the pretraining recipe behind large language models) and RLHF (humans supply the reward signal, importing their own values and blind spots into the model).
Provider, deployer, and user — the three-party split
| Provider | Deployer | User | |
|---|---|---|---|
| Who they are | Builds/trains the foundation model — the engine | Puts the model to work for a specific purpose — builds the car | The person actually typing the prompt or reading the output — drives the car |
| Formal AI Act obligations? | Yes — training-data, evaluation, disclosure duties | Yes — use-context duties, human oversight | None formally |
| Practical risk they carry | Can't foresee every downstream use | Owns the harm specific to their use case | Over-trusting fluent-sounding output |
| Governance lever | Model cards, red-teaming, evaluation transparency | Contracts, use-policy, monitoring | Training and awareness on AI's limitations |
⚠ The user is the party with zero formal AI Act obligations but real exposure to a badly-behaving model — the one riding in a car whose engine and dashboard they had no say in. A governance program that only staffs for provider and deployer duties has a gap exactly here.
Who is harmed: individual vs. group vs. societal
| Individual harm | Group harm | Societal harm | |
|---|---|---|---|
| What it is | One identifiable person suffers a wrongful denial, economic loss, injury, dignitary harm, or privacy loss | A protected or vulnerable class is systematically disadvantaged, even if each individual decision looks defensible on its own | Diffuse damage to the public — no single identifiable victim, just a degraded shared environment |
| Example | One applicant is wrongly denied a loan | Résumés from women are systematically scored lower across many applicants | Cheap synthetic media erodes shared trust in what's real during an election |
| How you'd notice | A complaint or appeal from the affected person | Disaggregated outcome analysis across a demographic slice | No complainant to point to — only visible at a population level, often only in hindsight |
⚠ A model can look fine on individual-level review and still be causing group or societal harm — that's why harm analysis has to check all three levels, not just the level a complaint happens to surface.
Allocative vs. representational harm
| Allocative harm | Representational harm | |
|---|---|---|
| What happens | A resource or opportunity — a loan, a job, a benefit — is distributed unfairly | A system demeans, stereotypes, erases, or misrepresents a group |
| Does a decision have to occur? | Yes — it's always tied to something being allocated or denied | No — it can occur with zero decisions in sight, e.g. purely generated content |
| Example | A biased credit model denies a qualified applicant | An image generator depicts every CEO it draws as a man |
⚠ Decision-focused controls (audit the denials, check the approval rate) never catch representational harm, because nothing was ever 'decided' — it needs its own review lens.
Measurement bias vs. representation bias
| Measurement bias | Representation bias | |
|---|---|---|
| Where it enters | The label or proxy itself is a flawed stand-in for what you actually want to predict | Some groups are under-sampled or missing from the training data |
| Classic example | Obermeyer healthcare algorithm: “healthcare cost” used as a proxy for “need” — unequal access made cost a racially skewed measure | A face-recognition set trained mostly on lighter-skinned faces performs worse on darker skin |
| The fix | Choose a better label or proxy; validate it against ground truth | Re-sample, re-weight, or actively collect the underrepresented group |
⚠ “Not enough Black patients in the data” is the wrong diagnosis for Obermeyer — they were present, just measured with a bad label. Save “not enough data” for representation bias.
The four fairness definitions, side by side
| Demographic parity | Equalized odds | Predictive parity | Calibration | |
|---|---|---|---|---|
| What it requires | Equal positive-prediction rates across groups | Equal true-positive and false-positive rates across groups | Equal precision across groups — of those predicted positive, the same share actually are | A given score means the same thing for every group: the actual outcome rate matches the predicted score regardless of group |
| Where it breaks down | Can force unequal error rates if groups have different true qualification rates | Cannot hold at the same time as calibration when base rates differ across groups | Can coexist with very different absolute numbers of opportunities going to each group | Can coexist with unequal error rates across groups |
⚠ When groups have different base rates, no model can satisfy calibration and equalized odds simultaneously — that's a mathematical fact, not an engineering shortfall, so 'just collect more data' never resolves it.
Transparency vs. explainability
| Transparency | Explainability | |
|---|---|---|
| What it's about | Disclosure about the system itself: that AI is in use, its purpose, capabilities, and limitations | The reason behind one specific output the system produced |
| The picture | The sign on the door: “an AI is deciding this” | The reason given once you're inside, for why it decided what it decided |
| Legal example | EU AI Act Article 50 — chatbots and deepfakes must identify themselves as AI | GDPR Articles 13–15 and EU AI Act Article 13 — meaningful information about the logic behind a decision |
⚠ A system can be fully transparent (everyone knows AI is deciding) and still not explainable (no one can say why it decided what it decided) — the two are independent, and the exam likes to test whether you'll assume satisfying one satisfies the other.
Global vs. local explanations
| Global explanation | Local explanation | |
|---|---|---|
| Question answered | How does the model behave overall — which factors dominate its decisions in general? | Why did the model produce this particular output, for this one person's case? |
| Best audience | Validators and regulators auditing the model's overall logic | The affected individual seeking an actionable reason or grounds to contest |
| Example | “Debt-to-income ratio is the most influential factor across all applicants” | “Your application was declined principally due to your debt-to-income ratio and short credit history” |
⚠ A validator satisfied by strong global explanations hasn't thereby given the declined applicant anything they can act on — the two serve different audiences and neither substitutes for the other.
In-the-loop vs. on-the-loop vs. in-command
| In-the-loop | On-the-loop | In-command | |
|---|---|---|---|
| What the human does | Approves each individual decision before it takes effect | Monitors the system in operation and can intervene | Sets the operating bounds and can decommission the system entirely |
| Best fit | High-stakes, low-volume decisions — parole, medical diagnosis | High-volume decisions where per-item review isn't feasible — fraud screening at scale | Every AI system, regardless of which of the other two also applies |
| Failure mode | Rubber-stamping — approving without genuine review | Alert fatigue — so many cases flagged that overrides stop happening | No one actually holds the authority or knowledge to pull the plug |
⚠ These aren't a menu of alternatives — in-command is always required, and picking on-the-loop for a fraud tool doesn't retire the need for someone in-command of the whole system.
GDPR Article 22 vs. AI Act Article 14
| GDPR Article 22 | AI Act Article 14 | |
|---|---|---|
| Applies to | Solely automated decisions with legal or similarly significant effects | High-risk AI systems (Annex III / Article 6) |
| What it requires | A right not to be subject to the decision unless an exception applies, plus safeguards: meaningful human involvement, the right to contest, and an explanation of the logic | A design duty: overseers must understand the system's capabilities/limitations, stay aware of automation bias, correctly interpret output, and be able to intervene or halt |
| Who it's really about | The data subject's rights over their own case | The system's design, so a human overseer can meaningfully intervene at all |
| Common failure | A ten-second rubber-stamp reviewer isn't “meaningful involvement” — Article 22 isn't satisfied | A system built without a real intervene/halt capability fails Article 14 even with a human sitting in front of it |
⚠ “We added a human, so we're compliant” fails both articles for the same underlying reason: a token human presence isn't oversight.
AI-specific attack classes, side by side
| Adversarial examples | Data poisoning | Model inversion / membership inference | Prompt injection | |
|---|---|---|---|---|
| What's attacked | The model at inference time, via a crafted input | The training pipeline, via corrupted training data | The model's confidentiality, via its outputs | The LLM's instruction-following, via untrusted input content |
| Goal | Force a misclassification or wrong output | Implant a hidden behavior or quietly degrade the model | Extract or confirm whether specific data was in the training set | Hijack the system's behavior using content it was only supposed to read |
| Primary defense | Adversarial robustness testing, red-teaming | Training-data provenance and integrity checks | Rate limiting, query monitoring, differential privacy | Privilege separation — never give the model more authority than its least-trusted input source warrants |
⚠ These target four different points in the system — input, training data, output, and instructions — so a control built for one (e.g. input validation against adversarial examples) does nothing against the others.
The three lines model, applied to AI
| First line | Second line | Third line | |
|---|---|---|---|
| Who | Business and technical teams building and operating the AI system | The AI governance function — legal, privacy, security, data science, ethics | Internal audit |
| Role | Owns the system's risk day to day and executes controls: intake, documentation, testing, monitoring | Sets policy, runs the review process, maintains the inventory, advises and challenges the first line | Independently assures that the whole apparatus — lines one and two — actually functions as designed |
| Example action | A named accountable owner runs pre-deployment testing on their own system | The governance function reviews a high-risk use case and can send it back for more work | Audit samples the inventory annually to confirm the review process is real, not theater |
⚠ Risk ownership always stays with the first line — the second line advises and challenges but doesn't own the risk, and the third line never does either line's job, it only checks that both are actually working.
Role-differentiated training: what each audience actually needs
| Executives & board | Engineers & data scientists | Frontline staff | Legal, procurement & compliance | |
|---|---|---|---|---|
| What they need | Enough terminology and risk literacy to ask good questions and approve or reject AI initiatives responsibly | Operational specifics: which policies gate which lifecycle stage, what documentation is required, when to escalate | Practical, scenario-based training on what the tool can and can't be trusted to do, and when to override it | Enough depth to evaluate vendor contracts and conduct assessments |
| What they don't need | Model-architecture detail | Board-level risk framing | Policy-document literacy on its own | Hands-on model-building knowledge |
| Failure if skipped | Rubber-stamp approvals of initiatives no one really understands | Policy violated unintentionally through not knowing which gate applies when | Blind trust in a fabricating tool — e.g. publishing hallucinated claims unverified | Vendor contracts signed with no AI-specific protections |
⚠ A single generic training module satisfies none of these rows well — the same 40-page policy handed to all four audiences is the design failure this competency exists to catch.
Under-scaling vs. over-scaling
| Under-scaling | Over-scaling | |
|---|---|---|
| What it looks like | A regulated, large, or high-risk organization treats AI governance as an informal side project with no real structure | A small or early-stage organization adopts a heavyweight, multi-committee framework built for a much bigger organization |
| What breaks | Genuine risk goes unmanaged because no one has real ownership, review, or escalation authority | The organization can't staff or run the process, so it gets quietly bypassed the first time it slows down a launch |
| Example | A 3,000-person regulated bank running AI governance as two engineers' side project | A 5-person startup adopting a 60-page bank framework with four committees |
⚠ Both failures leave the organization equally unprotected — one because no structure exists, the other because the structure exists on paper only.
Where each pre-AI policy category quietly breaks
| Data privacy | Security | Data governance | Intellectual property | |
|---|---|---|---|---|
| What the old policy assumed | Personal data is only handled when directly collected | Attacks target traditional network/application surfaces | Deleting the source record deletes the data | Only humans create content, and company data stays inside company tools |
| What AI adds | A model can infer new personal data it was never directly given | Model-specific attack surfaces: prompt injection, model extraction, training-data poisoning | A model can retain the “shape” of data in its weights even after the source record is deleted | Who owns AI-generated output, and employees pasting confidential data into third-party AI tools |
| Real-world trigger | Profiling that derives special-category data from mundane behavior | An LLM assistant manipulated via prompt injection | A customer's erasure request the retention policy has no answer for | Employees pasting client contract text into a public chatbot |
⚠ None of these old policies was wrong when written — AI simply raises a question each one never had to answer, which is why the review is a systematic re-read, not a rewrite from scratch.
Four more mechanical GDPR duties an AI program routinely forgets
| Third-party processors | Cross-border transfers | Breach notification | Record keeping | |
|---|---|---|---|---|
| The rule | Art. 28 — a vendor training/hosting your model on your behalf is a processor | Sending EU data to a non-EU-hosted model needs a real transfer mechanism | Art. 33/34 — 72 hours to notify the regulator once a breach is known; individuals too, if risk is high | Art. 30 — the training run itself is a processing activity that must be documented |
| What satisfies it | A data-processing agreement spelling out exactly what the vendor may do — not a vague terms-of-service line | An adequacy decision for that country, or Standard Contractual Clauses with a documented risk assessment | A clock that starts the moment you become aware — not once you've fully understood what happened | Purpose, data categories, retention, recipients — logged for the training run, not just the model's day-to-day use |
| Where teams miss it | A vague 'we handle your data responsibly' clause standing in for a real DPA | An API call to a US-based foundation model doesn't feel like an international transfer — but it is one | Waiting until the situation is fully understood before the clock is treated as running | Documenting how the finished model is used, while never documenting the training run that built it |
Three easily-confused categories: special-category, biometric, and inferred data
| Special-category data (Art. 9) | Biometric data (Art. 4(14)) | Inferred special-category data | |
|---|---|---|---|
| What it is | The enumerated list itself — health, race/ethnicity, political opinions, religion, trade union membership, genetic data, sex life/orientation, plus biometric data used for identification | A subset of special-category data: data from specific technical processing of physical/physiological/behavioral traits, used to uniquely identify someone | Not a separate legal category — an ordinary output that reveals a special category, generated by a model rather than collected as an input |
| How you'd know it's present | It's a labeled field or direct input — health records, a religion question on a form | It requires a specific technical purpose: a photo alone doesn't count, but a photo processed into a facial template for identification does | It requires an inference audit — the data doesn't look sensitive, the model's prediction is what makes it sensitive |
| Governance trap | Assuming a narrow exception (like consent) automatically applies without checking its specific conditions | Assuming any photo or voice sample is automatically 'biometric data' under GDPR — it isn't unless used for identification | Assuming 'we never collected that' is a defense — an accurate inference is regulated exactly like direct collection |
⚠ The exam likes to test the middle two: a plain photo is not biometric data, but a model that infers a special category from ordinary features has still triggered Article 9 — 'we never asked for it' protects nothing.
The key AI copyright cases, and what each one actually decided
| Bartz v. Anthropic | Thomson Reuters v. Ross Intelligence | Pending: NYT v. OpenAI, Getty v. Stability, Kadrey v. Meta | |
|---|---|---|---|
| Was training itself fair use? | Yes, for the lawfully-acquired books | No — Ross's tool competed directly in the same market (legal research) as the training material | Undecided — rulings expected through 2026 |
| Did acquisition method matter? | Yes — assembling a library from pirated copies was not fair use, separate from the training-use question | Not the deciding factor — market competition was | A live issue in each case |
| Outcome | Settled for roughly $1.5 billion over the pirated-copies claim | First final ruling against an AI company on fair use | Active litigation, no final rulings yet |
⚠ The exam's trap: Bartz shows a company can win the fair-use question and still face massive liability on the acquisition question — the two questions from simple don't rise or fall together.
Two different impact-assessment moments: III.A design review vs. IV.B formal assessment
| III.A — design-stage review (this competency) | IV.B — formal deployer assessment (DPIA/FRIA) | |
|---|---|---|
| Who owns it | The design-and-build team, closest to whatever just changed | Compliance, privacy, or legal functions |
| When it happens | Continuously — at each significant design decision | At the deployment decision point, typically once |
| What it produces | A lightweight delta review: what changed, does it affect the harm analysis, is a full reassessment triggered | A full formal instrument (a DPIA under GDPR Art. 35, or a FRIA under AI Act Art. 27) |
| What triggers it | A changed data source, architecture, or scope, or a new risk-matrix finding | The system moving toward deployment, or a formally defined reassessment trigger |
⚠ These aren't competing paperwork — the design-stage review is what keeps the formal deployer assessment from going stale before it's even filed.
The four load-bearing readiness questions
| Business objectives | Performance requirements | Data availability | Workforce readiness | |
|---|---|---|---|---|
| Core question | Does the metric it optimizes match what the business actually wants? | What accuracy, latency, and reliability does this specific use case demand? | Does the deployer actually have representative, current data for this population? | Do the people operating or overseeing it have the training, authority, and time to do so? |
| Failure if skipped | A chatbot 'resolves' tickets by ending them prematurely — hitting the metric, missing the goal | A model tuned for one risk level gets deployed where the cost of error is much higher | The vendor's benchmark data doesn't resemble the population actually being served | Human oversight becomes theater — nobody trained to actually intervene |
⚠ A brilliant model can fail on any one of these four axes alone — readiness isn't a single yes/no, it's four separate checks that all have to pass.
Classic (predictive) vs. generative AI
| Classic / predictive | Generative | |
|---|---|---|
| What it produces | A score, class, or ranking on something that already exists | New content: text, images, code, audio |
| How it fails | Wrong in a measurable way — a computable false-positive rate | Hallucinates — fluent, confident content with no ground truth to check against |
| How you catch the failure | Compare against ground truth / labeled test data | Grounding, retrieval, and human verification — there's no single ground truth to check against |
| Governance need this creates | Standard TEVV — accuracy, precision/recall, calibration | Hallucination controls, provenance/IP diligence, content moderation |
Cloud vs. on-premise vs. edge
| Cloud | On-premise | Edge | |
|---|---|---|---|
| Where data goes | Leaves the organization to a vendor's servers | Stays in-house, under the organization's own governance | Stays on the device itself — the most private option |
| Cost and maintenance | Lowest upfront cost, ongoing vendor dependency | Higher upfront and maintenance burden, fully owned in-house | Cheap per unit, but hard to maintain at scale across many devices |
| Monitoring and patching | Vendor-managed, centrally observable | Centrally managed by the organization itself | Hardest — every instance is separate, so you can't centrally observe or update them all |
| Primary risk this creates | Data-residency, cross-border-transfer, and vendor-dependency risk | Cost and maintenance burden | Degraded monitoring, patching, and incident response |
⚠ The trap is treating this as a pure infrastructure choice — each option reallocates risk, it doesn't eliminate it.
9 more topics locked
Beta access previews one topic per domain. The rest unlock for everyone once Vantage opens full access.