AI Governance, Risk & Compliance Interview Q&A — NIST AI RMF, EU AI Act, ISO 42001

The four functions are GOVERN, MAP, MEASURE and MANAGE. GOVERN is cross-cutting — it sets the culture, policies, roles and accountability that the other three run inside. MAP establishes context and identifies risks for a specific AI use case. MEASURE analyses, assesses and tracks those risks using quantitative and qualitative methods. MANAGE prioritises and acts on risks, allocating resources to treat, monitor and respond. Each function breaks into categories and subcategories. They are not strictly sequential — GOVERN wraps the lifecycle while MAP, MEASURE and MANAGE iterate.

It is published by NIST (US National Institute of Standards and Technology) and it is voluntary — there is no legal force on its own. But it has become the de-facto baseline: US federal guidance, enterprise procurement and many audit checklists reference it. The companion NIST AI 100-1 is the framework; the Playbook gives actionable suggestions; NIST AI 600-1 is the Generative AI Profile; and NIST AI 100-2 is the adversarial-ML taxonomy. So in interviews, frame it as "not law, but the language everyone speaks."

The seven characteristics of trustworthy AI are: valid and reliable (the foundation — accurate and consistent in use); safe; secure and resilient (withstands adversarial attack and recovers); accountable and transparent; explainable and interpretable; privacy-enhanced; and fair with harmful bias managed. NIST stresses these are interdependent and you trade them off — pushing explainability can cost accuracy, hardening security can cost usability. "Valid and reliable" is the base; the others build on it. Memorise the count as seven, because panels love to ask you to enumerate them.

That decision lives in MAP and MANAGE, governed by GOVERN. In MAP you establish context — intended use, affected people, benefits versus potential harms — and subcategory MAP 1.5 explicitly asks whether the AI system's risks exceed organisational tolerance, allowing a no-go. MANAGE 1.1 then determines whether the system achieves its purpose and whether to proceed, pause or decommission. The risk tolerance itself is set in GOVERN. So the answer is not one function: GOVERN sets the threshold, MAP surfaces the risk, MANAGE makes the deploy/halt call.

The Generative AI Profile (NIST AI 600-1, July 2024) is a cross-sectoral profile, not a new framework. It identifies twelve risks unique or amplified by GenAI — including CBRN information uplift, confabulation (hallucination), dangerous or violent content, data privacy leakage, harmful bias, and information integrity. For each it lists actions mapped back to GOVERN, MAP, MEASURE and MANAGE. In an interview, I'd use it to anchor a GenAI control set: red-team for prompt injection under MEASURE, set content filters and human review under MANAGE, and log provenance for information integrity. It is the bridge from generic RMF to LLM-specific controls.

I start with GOVERN, because everything else is unowned without it. Concretely: name an accountable owner, write a one-page AI policy and risk-tolerance statement, and create an AI use-case register so the chatbot is even visible. Then run MAP on the chatbot — intended use, who it serves, harms like prompt injection, data leakage and confabulation, tied to MAP 1.5 tolerance. Under MEASURE I'd red-team with garak and PyRIT and track refusal and jailbreak rates. MANAGE adds NeMo Guardrails or Llama Guard, human escalation, and an incident path. Governance before guardrails before tooling.

They are complementary, not interchangeable. The NIST AI RMF is a voluntary, outcome-based US framework; the EU AI Act is binding EU law with risk tiers, conformity assessments and fines. Doing the RMF well gives you most of the raw material — risk identification, measurement, oversight, documentation — that the Act's high-risk obligations demand, so it is a strong head start. But the RMF will not, by itself, make you compliant: you still need the Act's specific artefacts like the technical documentation, the EU declaration of conformity and registration. Frame it as "RMF builds the muscle; the Act dictates the exact reps."

The Act is risk-based with four tiers. Unacceptable risk — banned outright (Article 5): social scoring, untargeted facial-image scraping, most real-time remote biometric ID in public, manipulative or exploitative systems. High risk — permitted but heavily regulated (Annex III plus safety-component cases): credit scoring, recruitment, biometrics, critical infrastructure, education and law-enforcement uses. Limited risk — transparency obligations only: chatbots must disclose they are AI, and AI-generated content must be labelled. Minimal risk — the vast majority, like spam filters and game AI: no mandatory obligations. Most compliance effort concentrates on the high-risk tier.

The Act entered into force on 1 August 2024. 2 February 2025 — the prohibited practices (Article 5) and AI-literacy obligations applied. 2 August 2025 — the GPAI (general-purpose AI model) obligations, governance bodies and the penalty regime started applying. The high-risk dates then moved: the May-2026 Digital Omnibus (provisional agreement 7 May 2026) deferred the bulk of stand-alone Annex III high-risk obligations from the original 2 Aug 2026 deadline to 2 December 2027, and high-risk AI embedded in regulated products (Annex I) to 2 August 2028. Transparency duties for chatbots and AI-generated content still land on 2 August 2026. The current headline a candidate must give is: bans Feb 2025, GPAI Aug 2025, Annex III high-risk now Dec 2027.

The top tier is for the prohibited practices in Article 5: up to EUR 35 million or 7% of total worldwide annual turnover, whichever is higher. That is steeper than GDPR's 4%/EUR 20m ceiling. The next band — breaching most other obligations, including high-risk and GPAI duties — is up to EUR 15 million or 3%. Supplying incorrect, incomplete or misleading information to authorities is up to EUR 7.5 million or 1%. For SMEs and start-ups, the lower of the fixed amount or the percentage applies. Memorise "7% global turnover" — it is the headline number panels expect.

All GPAI (general-purpose AI) model providers must keep technical documentation, give downstream deployers the information they need, comply with EU copyright law, and publish a summary of training data. On top of that, a model is presumed to carry systemic risk when the cumulative compute used for training exceeds 10^25 floating-point operations (FLOPs), or when the Commission designates it. Systemic-risk models face extra duties: model evaluation and adversarial testing, systemic-risk assessment and mitigation, serious-incident reporting, and cybersecurity protection. The Commission's GPAI Code of Practice is the route to demonstrate compliance.

Yes — the Act is extraterritorial, like GDPR. It applies to providers placing AI systems on the EU market regardless of where they are established, and to providers and deployers located outside the EU when the output of the system is used in the EU. So a Hyderabad ITES firm whose recruitment model screens candidates for an EU client is in scope as a provider, and likely high-risk under Annex III. Practically, you appoint an EU authorised representative, complete the conformity assessment, and register in the EU database. "No EU office" is not a shield if EU people feel the output.

For an Annex III high-risk system the provider must build a continuous risk-management system, apply data governance for training and test data, prepare technical documentation, enable automatic logging, ensure transparency and instructions for use, design human oversight, and meet accuracy, resilience and cybersecurity targets. They then run a conformity assessment (often self-assessment, third-party for some biometrics), draw up the EU declaration of conformity, affix the CE marking, and register the system in the EU database. Post-market monitoring and serious-incident reporting continue after launch. It is product-safety law applied to models.

Limited-risk means transparency obligations rather than the full high-risk regime. For a chatbot, users must be told they are interacting with an AI system unless it is obvious. For deepfakes and other generated or manipulated content, the output must be disclosed as artificially generated or manipulated and, for GPAI, marked in a machine-readable way so it is detectable. AI-generated text published to inform the public on matters of public interest must also be labelled. These transparency duties apply from 2 August 2026. So the requirement is disclosure and labelling — not conformity assessment.

ISO/IEC 42001:2023 is the world's first international AI Management System (AIMS) standard, published December 2023. It specifies requirements to establish, implement, maintain and continually improve an AIMS so an organisation develops and uses AI responsibly. Yes — it is certifiable: an accredited body runs a two-stage audit, then annual surveillance, with recertification roughly every three years. It uses the Annex SL high-level structure shared with ISO 27001 and ISO 9001, and runs on the PDCA (Plan-Do-Check-Act) cycle. Certification is how you show external assurance of governed AI.

Annex A is the reference list of AI-specific controls, and Annex B gives implementation guidance for them — mirroring how ISO 27001 Annex A and 27002 relate. The controls span areas such as the AI policy, internal organisation and roles, resources for AI systems, impact assessment on individuals and society, the AI system lifecycle, data for AI systems (quality, provenance, preparation), information provided to interested parties, AI use, and management of third-party and supplier relationships. Like 27001, you select applicable controls and justify exclusions in a Statement of Applicability. It is the practical control catalogue under the management-system clauses.

They share the same Annex SL management-system backbone — context, leadership, planning, support, operation, performance evaluation, improvement — so if you already run an ISO 27001 ISMS you can bolt the AIMS on rather than start fresh. The difference is scope: 27001 protects information security (confidentiality, integrity, availability); 42001 governs responsible AI across the model lifecycle, adding controls for fairness, transparency, impact assessment and data provenance that 27001 never had. In an integrated programme you reuse 27001's risk process, internal audit and management review, and extend the risk scope to AI-specific harms. One auditor, two certificates.

They are companion standards, not management systems. ISO/IEC 22989 is the vocabulary standard — it defines AI terminology and concepts so everyone in your programme means the same thing by "model," "training data" or "AI system." ISO/IEC 23894 is AI risk-management guidance; it adapts the generic ISO 31000 risk process to AI-specific sources of risk and is the natural way to operationalise the risk clauses of 42001. So in a stack: 22989 gives you the words, 23894 gives you the risk method, and 42001 is the certifiable management system that ties them together.

AI TRiSM — Gartner's AI Trust, Risk and Security Management — is a market framework, not a standard. It groups capabilities into pillars: AI governance, runtime inspection and enforcement (guardrails, prompt and output filtering), information governance (data and privacy), and infrastructure and stack (model and supply-chain security). The contrast: ISO 42001 is a certifiable governance management system — process and accountability; TRiSM leans operational and runtime — what tooling actually inspects model inputs and outputs in production. I'd use TRiSM to choose controls like Llama Guard, NeMo Guardrails or Protect AI scanning, and 42001 to certify the programme around them.

I'd run it as a PDCA project. Plan: define scope and context, get leadership to sign an AI policy, build the AI use-case inventory, and run AI risk and impact assessments using ISO/IEC 23894. Pick Annex A controls and write the Statement of Applicability with justified exclusions. Do: implement the controls — data governance, lifecycle gates, human oversight, third-party AI due diligence. Check: internal audit, then a management review, fixing nonconformities. Act: the accredited body's two-stage certification audit. Reusing the client's existing ISO 27001 ISMS for audit, document control and risk process is the single biggest time-saver.

You need one of the Article 6 bases. For training, legitimate interests (Art. 6(1)(f)) is the common route, but it demands a documented legitimate interests assessment balancing your interest against the data subjects' rights, and it can be objected to. Consent is cleaner legally but hard to gather at scale and must be freely given and specific. Special-category data (health, biometrics, ethnicity) needs an extra Article 9 condition. Two principles bite hard for AI: purpose limitation — data collected for one purpose cannot be silently repurposed for training — and data minimisation — train on the least data needed.

Under GDPR Article 35 a DPIA (Data Protection Impact Assessment) is mandatory when processing is likely to result in a high risk to individuals — which covers most serious AI: large-scale profiling, automated decisions with legal or significant effects, systematic monitoring, and special-category data at scale. The DPIA must describe the processing and purpose, assess necessity and proportionality, evaluate risks to data subjects, and set mitigations. For AI specifically you document the training-data sources and lineage, bias testing, and human-oversight design. It is the privacy twin of the EU AI Act risk assessment, and you do it before processing starts.

Article 22 gives a person the right not to be subject to a decision based solely on automated processing — including profiling — that produces legal or similarly significant effects. A fully automated loan rejection at a Mumbai bank serving EU customers is exactly that. It is permitted only if it is necessary for a contract, authorised by law, or based on explicit consent, and even then you must provide safeguards: the right to obtain human intervention, to express a view, and to contest the decision. Practically you build a human-review path and meaningful explanation. "Solely" is the key word — token rubber-stamping does not make it human-in-the-loop.

The Digital Personal Data Protection Act 2023 (assented August 2023) is India's first comprehensive data-protection law; the DPDP Rules 2025 were notified in November 2025 with phased enforcement and a full-compliance deadline in 2027. Core duties: a clear notice and consent for processing, purpose limitation, breach notification, and honouring data-principal rights. The government can name a Significant Data Fiduciary with extra duties — periodic DPIAs, audits and a Data Protection Officer. Penalties run up to INR 250 crore per instance. There is a children's-data consent regime too. For AI teams it means consent-tracked training data and a lawful purpose, not scraped-and-forgotten datasets.

The risk is that prompts and completions routinely contain PII — PAN, Aadhaar, account numbers, health details — and logging them in plaintext creates an unlawful secondary copy with no lawful basis, breaching data minimisation and DPDP/GDPR purpose limitation. It also widens the breach blast radius. The fix: redact PII before logging using Microsoft Presidio or a similar detector, log only what debugging needs, set short retention with auto-deletion, encrypt and access-control the log store, and document the basis. Better still, separate a sanitised debug stream from the raw request path. Treat prompt logs as production personal data, not throwaway debug text.

Lineage — knowing exactly where each dataset came from, on what basis, and how it was transformed — is what lets you answer the questions regulators and customers actually ask. Under GDPR you must honour erasure and demonstrate lawful basis and purpose limitation, which is impossible if you cannot trace a record's origin. The EU AI Act requires high-risk data governance and a GPAI training-data summary. Lineage also underpins bias analysis, copyright defensibility, and incident response when a poisoned or unlicensed source surfaces. So it is an evidence requirement: no lineage means no provable compliance, regardless of how clean the data looks.

An AI inventory or use-case register is a single source of truth listing every AI/ML system in the organisation — what it does, who owns it, the data it uses, its risk classification, and its lifecycle stage. It is first because you cannot govern what you cannot see; shadow AI in a spreadsheet or a SaaS feature is the biggest gap. The register feeds everything downstream: NIST MAP, EU AI Act tiering, ISO 42001 scope and DPIA triggers. Each entry should link to its model card, risk assessment and approval. In an audit it is the index from which every other piece of evidence hangs.

A model card is structured documentation of a model so reviewers and auditors understand it without reading the code. For governance it should cover: intended use and out-of-scope uses; training data sources and lineage; performance metrics broken down by relevant subgroups; fairness and bias evaluation; limitations and known failure modes; security and adversarial testing results; the responsible owner; and the version and approval date. It is the artefact that satisfies NIST transparency, ISO 42001 documentation and the EU AI Act's instruction-for-use duty in one place. Treat it as a living document, versioned with the model.

An AI-BOM (or ML-BOM) extends the software bill of materials to the AI supply chain. A standard SBOM lists code libraries and versions for vulnerability tracking. An AI-BOM adds the model-specific layer: base/foundation models and their versions and licences, datasets used for training and fine-tuning, model weights and their provenance, and the inference framework. It matters because supply-chain attacks now hit models — a poisoned weight or a malicious serialized model. You generate it with tools like CycloneDX ML extensions, scan artefacts with ModelScan or Protect AI, and sign them with Sigstore cosign. It is how you prove model provenance under the EU AI Act and NIST supply-chain controls.

I'd build a gated intake. Step 1: any new AI use case is logged in the use-case register with a short questionnaire — purpose, data sensitivity, affected people, autonomy of the decision. Step 2: an automated rules layer maps answers to a tier using EU AI Act Annex III and the firm's own scale, plus a GDPR/DPDP DPIA trigger check. Step 3: by tier, attach controls — minimal gets baseline logging; high-risk routes to a full review board, conformity assessment, model card, human oversight and red-teaming. Step 4: an accountable owner signs off and the register records the decision and date. The output is a defensible, repeatable paper trail.

You treat a vendor model like any high-risk dependency, with AI-specific due diligence. Before onboarding, demand evidence: their model card, security and red-team results, data-handling and training-data position, sub-processor list, and any ISO 42001 or SOC 2 attestation. Pin obligations in the contract — data-use limits (no training on your data without consent), breach notification, audit rights, and EU AI Act role clarity (are they provider or are you?). At runtime, wrap the API in your own guardrails rather than trusting theirs blindly, and log usage. Add each vendor model to your AI-BOM and re-assess on version changes. Shared responsibility, written down.

Auditors want operational proof, not a policy PDF. I'd show: logs of human interventions — cases where a reviewer overrode or confirmed a model decision, with timestamps and reviewer identity; an escalation runbook and tickets showing it was followed; override and reversal rates trended over time, proving reviewers can and do act; training records for the humans in the loop; and the UI design showing the reviewer sees explanation and can decline. For Article 22 and EU AI Act oversight, the killer evidence is a real case where a human changed the outcome. If override rate is zero, that is a red flag for rubber-stamping, not success.

There is no single federal AI law, so a global firm tracks a patchwork of US state laws plus sector regulators. The headline is the Colorado AI Act (SB 205) — the first comprehensive US state AI law, which puts a duty of reasonable care on developers and deployers of high-risk AI making consequential decisions (employment, lending, housing, insurance, education) to prevent algorithmic discrimination, run impact assessments, give consumers notice and a right to appeal, and report discrimination to the Attorney General. Its effective date was pushed to 30 June 2026. NYC Local Law 144 requires an independent annual bias audit of any automated employment decision tool (AEDT), public posting of the results, and candidate notice. Add the Utah AI Policy Act (generative-AI disclosure), Illinois amendments to its Human Rights Act on AI in hiring, the California rules on automated decision-making, and sector regulators like the EEOC (employment discrimination), CFPB (adverse-action notices for AI credit decisions) and FTC (unfair/deceptive AI). The interview point: in the US you map by state and use-case, not one statute.

First define the protected attributes and the fairness notion that fits the use case — they conflict, so you choose, you cannot satisfy all at once. The core metrics: demographic (statistical) parity — selection rates equal across groups; equal opportunity — equal true-positive rates; equalized odds — equal TPR and FPR; predictive parity — equal precision; and disparate-impact ratio, the test US enforcers use, where the four-fifths (80%) rule flags a selection rate for any group below 80% of the top group's rate as adverse impact. You compute these per subgroup on a representative test set and also intersectionally (e.g. gender × ethnicity), because a model can look fair marginally and fail on an intersection. Tooling to name: IBM AIF360, Microsoft Fairlearn, Google What-If Tool, or Aequitas. If you find disparity: re-balance or re-weight data, apply in-processing constraints (Fairlearn's reductions), or post-process thresholds per group — then re-test and record it in the model card. The auditor wants the metric chosen, the threshold, the result by subgroup, and the remediation, not a single accuracy number.

Under Article 73, the provider (and the deployer who tells the provider) of a high-risk AI system must report any serious incident to the market surveillance authority of the member state where it occurred. A serious incident is one that directly or indirectly leads to a death or serious harm to health, a serious and irreversible disruption to critical infrastructure, a breach of fundamental-rights obligations, or serious harm to property or the environment. The clock: report immediately after establishing a causal link (or reasonable likelihood of one), and in any case no later than 15 days after becoming aware. The window tightens for the worst cases — death is reportable within 10 days, and a widespread infringement or critical-infrastructure incident within 2 days; you may file an incomplete initial report to meet the deadline and complete it later. Then you investigate, run a risk assessment, and take corrective action without destroying evidence. This sits alongside GDPR's 72-hour breach notice (different trigger — personal-data breach) and, separately, GPAI systemic-risk models owe serious-incident reporting to the AI Office. Interview tip: name Article 73, the 15-day default, and the 10-day/2-day tighter windows.