AI Governance Interview Questions: The One That Filters Everyone Out

What this is testing

Whether you know the risk-tier hierarchy and can apply it systematically rather than guessing. Interviewers look for the methodical approach: check prohibited uses first, then high-risk categories, then limited risk transparency obligations, then minimal risk.

Strong answer structure

Start by checking whether the system falls into a prohibited use category under Article 5 — social scoring, real-time biometric surveillance in public spaces, subliminal manipulation. If not, check Annex III: does the system fall into one of the eight high-risk use cases (biometric identification, critical infrastructure, education, employment, essential services, law enforcement, migration, administration of justice)? If yes, the full high-risk compliance stack applies — conformity assessment, technical documentation, human oversight, registration in the EU database. If Annex III doesn’t apply, check whether limited-risk transparency obligations apply (chatbots, deepfakes). Everything else is minimal risk with general obligations only.

What this is testing

Whether you can distinguish these three assessments precisely. Many candidates conflate them. Interviewers specifically listen for who owns each, when it triggers, and what it covers.

Strong answer structure

A DPIA (Data Protection Impact Assessment) is a GDPR requirement triggered by high-risk personal data processing — it’s owned by the data controller and assesses privacy risk. An AIA (AI Impact Assessment) is a broader governance tool assessing an AI system’s potential harms across stakeholders — not legally mandated under the EU AI Act, but referenced in standards like ISO 42005. A FRIA (Fundamental Rights Impact Assessment) is an EU AI Act Article 27 requirement — but only for deployers who are public bodies or organisations acting on their behalf. It assesses impacts on fundamental rights specifically. The three can overlap but are not interchangeable, and each has a different owner, trigger condition, and scope. See DPIA vs AIA vs FRIA for the full breakdown.

What this is testing

Practical application of the Provider/Deployer distinction. Many candidates know what providers must do; fewer can articulate the deployer-specific obligation stack.

Strong answer structure

As a deployer of a high-risk AI system in an employment context (Annex III, category 4), we must: verify the provider has completed the conformity assessment and provided the required technical documentation; implement the system consistent with the provider’s instructions for use; maintain human oversight and ensure affected employees are informed of AI-assisted decisions that significantly affect them; conduct a FRIA if we are a public body or acting on behalf of one; keep logs of system operation; and have a process for handling system suspension when safety or compliance concerns arise. We do not redo the conformity assessment — that sits with the provider — but we are responsible for appropriate use on our side of the obligation boundary.

What this is testing

Cross-functional communication at the technical-executive interface — one of the most consistently flagged capability gaps in AI governance hiring.

Strong answer structure

Model drift is when an AI system’s performance degrades over time because the real-world data it encounters in deployment no longer matches the data it was trained on. For a board audience: “The AI system we approved in Q3 was tested against a specific set of conditions. If the market, our customers, or our processes change significantly, the system may start making worse decisions without any technical failure occurring — it simply hasn’t been updated to reflect the new reality. Our governance framework includes scheduled model performance reviews and automated drift monitoring alerts that trigger a human review before the degradation reaches a threshold that creates compliance or reputational risk.”

What this is testing

Third-party AI risk management competency and EU AI Act vendor due diligence knowledge.

Strong answer structure

For a high-risk system under the EU AI Act, I’d look for: the EU Declaration of Conformity and evidence of the completed conformity assessment; the technical documentation package (training data description, model architecture overview, accuracy and robustness testing results); the instructions for use that define our deployer obligations; the human oversight mechanisms the system is designed to support; the logging and monitoring specifications; and their incident notification process. Beyond regulatory compliance, I’d also want the model card, their bias evaluation methodology and results on demographic subgroups relevant to our use case, and their post-deployment monitoring commitments, including how and when they notify deployers of material model updates or drift events.

What this is testing

Cross-functional conflict resolution and risk-proportionate decision-making. Interviewers look for candidates who can navigate between business pressure and governance obligations without defaulting to either blocking everything or approving everything.

Strong answer structure

First, classify the system: does it fall into a risk category that creates a hard compliance obligation that cannot be bypassed on timeline grounds? If it’s high-risk under the EU AI Act, the conformity assessment is not optional and the three-week deadline is the problem, not the review. If it’s lower-risk, the question is whether the pending legal review covers risks that are time-sensitive or stable enough to manage post-launch. My approach is to have that conversation with legal explicitly: what specifically is outstanding, what is the risk if we deploy before it’s resolved, and is there a staged rollout (limited user group, enhanced monitoring) that manages the residual risk while the review completes? The answer I’m trying to avoid is either a blanket block that ignores the business reality or a blanket approval that ignores the legal gap.

What this is testing

Programme design and prioritisation under resource constraints. A strong answer is structured, sequenced, and honest about what can’t be done in phase one.

Strong answer structure

Phase one is inventory and triage: identify all AI systems currently in use, classify them by risk level using the EU AI Act framework or NIST AI RMF as the scoring rubric, and establish which ones create immediate compliance obligations. Most organisations discover systems they didn’t know existed in this phase — shadow AI adoption is almost universally underestimated. Phase two is policy and accountability: designate AI governance ownership (who approves new systems, who monitors existing ones, who handles incidents), build a lightweight intake process for new AI proposals, and write the foundational policy documents. Phase three is programme operationalisation: vendor due diligence standards, ongoing monitoring cadence, training for non-governance stakeholders, and board reporting. Starting with a comprehensive framework and perfect documentation is the wrong instinct — starting with inventory and triage is always correct because you can’t govern what you haven’t found. See how to build an AI governance programme from scratch for the full implementation guide.

What this is testing

Portfolio evidence. If you don’t have a real example, this question exposes it. Candidates who have actually worked with AI systems talk about specific metrics, specific stakeholders, and specific resolution steps. Candidates who haven’t tend to speak in generalities.

Strong answer structure

If you have a real example, use it. If you’re early in your AI governance career, the honest answer acknowledges that and pivots to what you would do: “I haven’t identified a live bias issue in a production system yet, but I’ve worked through the methodology on a hypothetical use case as part of my AIGP preparation. I would start by defining the relevant fairness metric for the use case — demographic parity if the baseline population should have equal outcomes, equal opportunity if we’re trying to ensure equal true positive rates across groups. Then I’d look at performance disaggregated by affected subgroups rather than aggregate accuracy, flag gaps above our agreed threshold to the system owner, and document the finding, the proposed mitigation, and the residual risk in the governance log. Building that portfolio of documented cases — even on hypothetical systems — is something I’m actively doing.”