HIRAF common mistakes
HIRAF · Understand the traps and how to avoid them.
When asked to classify a control or obligation, the candidate labels it by the technology involved (e.g., 'this is a model-training rule') instead of by the governance function it performs, so the answer lands in the wrong domain.
The exam spans six domains that overlap heavily; candidates anchor on familiar technical vocabulary and map every item back to the domain they know best rather than reading what the question is actually testing.
What to do instead
Before answering, restate the stem in one sentence naming the actor (developer, deployer, regulator, data steward) and the decision being made; assign the domain from that sentence, not from the keywords.
The candidate treats 'high-risk' as a property of the algorithm's accuracy or complexity, calling a highly accurate model low-risk and a weak model high-risk.
Engineers habitually equate model quality with risk, but risk classification turns on use context, affected persons, and severity of harm, not on benchmark performance.
What to do instead
For any risk-tier question, write down the use case, the population affected, and the consequence of error before judging the tier; explicitly separate performance metrics from risk tier in the reasoning.
The candidate proposes 'collect more data' or 'retrain the model' as the fix for a governance problem such as missing consent records, undocumented provenance, or absent retention schedules.
Technical training biases candidates toward modeling solutions, and data-quality problems superficially resemble data-volume problems.
What to do instead
Ask whether the defect is in the data itself or in the documentation, lawful basis, and accountability around it; if the latter, answer with process controls (data catalog, lineage, consent register, retention policy), not model changes.
The candidate answers monitoring and incident-response questions by describing pre-deployment validation only, omitting post-deployment drift detection, logging, and rollback.
Coursework and project experience center on the training/validation split, so the lifecycle is mentally truncated at deployment.
What to do instead
Memorize the operational loop (deploy, monitor inputs and outputs, detect drift, escalate, retrain or roll back, document) and check every ops answer against all five stages.
The candidate conflates explainability with interpretability and picks 'provide feature importance' as the answer whenever transparency is mentioned, even when the question concerns disclosure to an affected individual or a regulator.
The terms are used loosely in practice, and SHAP-style outputs are the most familiar transparency artifact.
What to do instead
Distinguish three audiences: developers (debugging), affected persons (meaningful explanation of a decision), and regulators (documentation and audit trails); select the artifact that matches the named audience.
The candidate applies a single jurisdiction's rule set (usually the EU AI Act) to every regulatory question, including ones framed around sectoral supervision, procurement, or standards conformity.
The EU AI Act dominates headlines and study material, so it becomes the default lens even when the stem describes a different regime or a voluntary standard.
What to do instead
Read the stem for the regulator, instrument, or obligation type named; if it references conformity assessment, standards bodies, or sector regulators, answer within that framework and note the jurisdiction explicitly.
The candidate describes a fairness mitigation as 'remove the protected attribute from the features' and treats that as a complete remedy.
Dropping a column feels like an obvious fix and is easy to recall, but proxies and disparate impact survive feature removal.
What to do instead
State that removing the attribute is insufficient, then name the actual approach (proxy auditing, reweighting or resampling, threshold adjustment, post-processing) and the metric being targeted.
The candidate mixes up training, validation, and test roles, or claims hyperparameters are learned from the test set, when answering model-development questions.
Terminology is learned informally in practice, and leakage is common in real projects, so flawed workflows feel normal.
What to do instead
Anchor on data roles: training fits parameters, validation selects hyperparameters and early stopping, test estimates generalization once; flag any answer that lets test data influence a design choice.
The candidate answers a data-governance question with a storage or tooling recommendation (use a lakehouse, use a feature store) instead of naming the accountable role, ownership model, or quality-control process requested.
Tooling is concrete and easy to name, while governance structures are abstract, so candidates substitute the tangible answer.
What to do instead
When the stem mentions ownership, stewardship, quality, or lineage, answer with roles, RACI assignments, data contracts, and quality gates; mention tools only as supporting mechanisms.
The candidate defines AI by capability alone (e.g., 'systems that learn from data') and then misclassifies rule-based or classical optimization systems in fundamentals questions.
Everyday usage equates AI with machine learning, so the broader scope of the field is lost.
What to do instead
Use a scope-based definition covering perception, reasoning, learning, and action, and check whether the described system involves learning, symbolic reasoning, or search before labeling it.