This tests the core skill of the role. Can you connect regulatory obligation to product feature? Do you know the actual requirements, or just that the regulation exists?

Start with risk classification — determine if the product falls under prohibited practices, high-risk, limited-risk, or minimal-risk classification under the EU AI Act. For high-risk systems, mandatory requirements include: 1. Risk management system (Article 9) — product feature: documented risk assessment workflow integrated into model review process. 2. Data governance (Article 10) — product feature: data quality controls and training data documentation. 3. Technical documentation (Article 11) — product feature: automated model card generation. 4. Human oversight (Article 14) — product feature: human-in-the-loop escalation UI with audit trail. 5. Accuracy/robustness (Article 15) — product feature: performance monitoring dashboard with drift alerts. Map each requirement to a specific sprint, assign ownership, and integrate with EU enforcement milestones (GPAI: Aug 2, 2025; high-risk: Aug 2, 2026).

Tests whether you can write governance requirements, not just describe them. Senior interviewers want to see that you understand what fairness means in product terms.

A governance PRD for bias detection goes beyond standard product requirements: 1. Regulatory context — which obligations does this feature satisfy (NYC LL 144 four-fifths rule, EU AI Act Article 10, NIST AI RMF MEASURE 2.5). 2. Fairness metric definitions — specify which metrics the dashboard must compute: demographic parity, equalized odds, selection rate by protected class. Define who defines “protected class” (legal, not engineering). 3. User stories per persona — compliance officer (audit evidence export), data scientist (metric drill-down), product manager (pre-launch gate check). 4. Data requirements — what demographic data is needed, consent requirements, anonymization approach. 5. Acceptance criteria — quantified fairness thresholds, human review trigger conditions, audit trail completeness. 6. Non-functional requirements — data retention for audit, access controls by role, immutability of logged decisions.

This is the fundamental tension of the role. Governance PMs must satisfy three constituencies with different definitions of success. Interviewers want to see your prioritization framework, not just that you acknowledge the tension.

Three-axis prioritization: 1. Mandatory vs. optional — regulatory deadlines are non-negotiable. EU AI Act enforcement dates are fixed. Distinguish mandatory compliance features from “nice-to-have” governance enhancements; mandatory features take absolute priority. 2. Risk-tiered sequencing — use the NIST AI RMF risk-tiering to prioritize which AI systems need governance features first. High-risk systems under EU AI Act get resources before limited-risk. 3. UX as enabler, not blocker — governance features that are unusable get worked around. Good UX for compliance features increases actual compliance. Frame UX investment as risk reduction, not polish. Tools: maintain a compliance matrix that maps every sprint item to a regulatory requirement. This makes prioritization transparent to leadership and legal simultaneously.

Tests regulatory knowledge (EU AI Act Article 14, NYC LL 144), UX design thinking, and governance implementation capability. A hiring tool is a high-risk system under EU AI Act.

EU AI Act Article 14 requires human oversight mechanisms that allow human intervention. For an automated employment decision tool: 1. Scope definition — identify which decisions are fully automated vs. AI-assisted. NYC LL 144 covers “automated employment decision tools” that substantially assist in employment decisions. 2. Escalation triggers — define conditions under which the AI must defer to human review: low confidence score, demographic parity threshold breach, appeal by candidate, novel profile outside training distribution. 3. Human review interface — design the reviewer experience: show AI recommendation, confidence score, key factors, demographic context. Do not show protected attributes directly. 4. Override audit trail — every human override logged with reviewer ID, timestamp, rationale, and final decision. Immutable. 5. Feedback loop — reviewer decisions feed back to model monitoring; systematic overrides signal model drift or bias.

This is a strategic question. Can you build a plan that satisfies legal, engineering, and business leadership simultaneously? Do you know what “high-risk” means in the Act and what the actual requirements are?

Phase the roadmap against enforcement milestones: Phase 1 (Immediate — GPAI obligations active Aug 2, 2025): Confirm risk classification with legal; document the system under Article 11; begin technical documentation. Phase 2 (6 months before Aug 2, 2026): Implement risk management system (Article 9); establish data governance controls (Article 10); design human oversight interface (Article 14); build accuracy and robustness monitoring (Article 15). Phase 3 (Pre-launch gate): Conformity assessment per Annex VI; notified body review if required; CE marking if applicable. Governance artifacts each phase produces: compliance matrix, model card, data governance documentation, human oversight design spec, conformity assessment evidence package. Stakeholder alignment: legal owns regulatory interpretation; engineering owns implementation; PM owns the roadmap that connects both to business launch dates.