AI Governance And Program Management practice questions

Configuring model weight encryption in the secure vault.

Why it fails: Model weight security is a technical control, not the initial governance assessment step.

Setting up a model drift detection dashboard in Azure Machine Learning.

Why it fails: A drift dashboard monitors post-deployment model behaviour; it neither identifies PII processing risks nor satisfies the mandated impact assessment, which must precede training. It is tempting because drift detection is genuine AI governance tooling, and would be correct once the model runs in production and requires ongoing performance monitoring.

Performing a sensitivity analysis on model output latency.

Why it fails: Performance metrics are post-deployment or during tuning, not a pre-training governance requirement.

To specify hardware requirements for training.

Why it fails: Hardware specifications belong to AI system lifecycle and resource clauses, not the Context clause, which determines external and internal factors shaping the AIMS scope. It tempts because infrastructure planning does appear in ISO/IEC 42001, but under operational and technical controls, not organisational context.

To mandate the use of cloud-based AI services.

Why it fails: Cloud-service mandates sit outside ISO/IEC 42001 entirely; the Context clause establishes external and internal issues relevant to the AIMS, not deployment models. It tempts because cloud AI is common in practice, yet the standard is technology-neutral and never prescribes a hosting platform.

To identify all bugs in the production code.

Why it fails: The Context of the Organization clause requires determining internal and external issues relevant to the AI management system, not scanning production code for defects. It is tempting because it sounds like an audit activity, and it would be correct if the clause addressed software quality assurance.

Require HITL for every single AI inference.

Why it fails: Mandating HITL for every inference makes the policy unworkable for high-volume or real-time AI, so it will be ignored or bypassed. It is tempting because universal review appears maximally safe, but HITL belongs on decisions meeting defined risk thresholds, not on all inferences.

Delegate HITL requirements to the software development team.

Why it fails: Delegating HITL to developers places a governance control outside the policy's authority, leaving no organisation-level definition of when human review is triggered, who reviews, or how it is evidenced. It is tempting because developers implement the review interface, yet the requirement itself is a risk-management decision.

Exclude HITL to maximize system throughput.

Why it fails: Excluding HITL removes the human review control that the policy exists to mandate for consequential AI decisions, prioritising throughput over oversight. It is tempting where latency or volume genuinely precludes review, but that scenario calls for defining narrow low-risk exceptions, not a blanket exclusion.

Scanning all model weights using antivirus.

Why it fails: Antivirus signatures target known malware binaries, not adversarial weights, poisoned training data, unsafe serialisation formats or tampered model artefacts. It is tempting because endpoint scanning is a familiar supply chain control, and would be correct for detecting conventional malware in downloaded files or packages.

Reviewing the vendor's marketing brochure.

Why it fails: A marketing brochure is vendor-authored promotional material with no independent verification of model provenance, training data or weights. Model cards, SBOMs and third-party audits provide assurance. Brochures tempt because they are the quickest documentation a procurement team receives, and vendors do describe security features there, but they are not evidence.

Limiting model access via VPN.

Why it fails: A VPN only restricts network reachability to the model endpoint; it does not verify provenance, integrity or licensing of weights, training data or dependencies. It is tempting because VPNs genuinely secure remote access to internal services, and would be the right control when the requirement is limiting who can reach a deployed model.

A local Python script for model testing.

Why it fails: A Python test script can be valuable for checking a model's robustness, fairness or performance, but it runs on one machine, covers one model at a time, and has no workflow, inventory or audit trail visible to the organisation. Its results are best treated as evidence fed into a governance platform, rather than as the oversight tool itself.

A public open-source project management board.

Why it fails: A public project board offers no compliance telemetry, policy enforcement or audit trail for AI models, so it cannot provide centralised oversight. It is tempting because open-source boards genuinely track tasks and issues across teams, and would suit coordinating remediation work once a governance platform has already flagged the findings.

A standard spreadsheet file.

Why it fails: Spreadsheets are a common starting point for tracking AI risks, but they lack access control, reliable version history, workflow, integration with machine learning platforms and audit trails, and they quickly become inconsistent as models change. They cannot provide dependable, organisation-wide oversight of AI compliance, which needs a dedicated governance or GRC system.

Weekly technical incident logs.

Why it fails: Weekly technical incident logs overwhelm the board with granular operational detail and omit aggregated residual risk positioning, so oversight becomes noise rather than assurance. It is tempting because frequent reporting appears rigorous, and would suit engineering or security operations reviews rather than board-level governance.

Annual compliance attestation only.

Why it fails: Annual attestation gives the board residual AI risk information too infrequently to exercise oversight between cycles, delaying response to material changes. It is tempting because annual compliance reporting satisfies statutory filing duties, and would suit a stable, low-change regulatory obligation rather than dynamic AI risk.

Real-time dashboard access for all directors.

Why it fails: Raw real-time dashboards give directors unfiltered operational telemetry without the interpretation, aggregation or context needed for governance decisions on residual risk. It is tempting because immediacy appears transparent, and would suit operational monitoring teams rather than a board exercising strategic oversight.

Hardware acceleration type.

Why it fails: Hardware acceleration describes the compute substrate and reveals nothing about legal or regulatory obligations. It is relevant for capacity planning and cost modelling. Regulatory assessment instead depends on metadata like intended use, training data provenance, and affected user populations.

Inference latency in milliseconds.

Why it fails: Inference latency is a performance metric, carrying no bearing on legal or regulatory exposure. It belongs in operational monitoring dashboards. Assessing regulatory risk requires attributes such as the system's purpose, data categories processed, and deployment jurisdiction.

Model training compute cost.

Why it fails: Training compute cost is a financial and sustainability metric, not a legal or regulatory risk attribute; it reveals nothing about data provenance, consent, or applicable jurisdictions. It is tempting because cost tracking supports budgeting and efficiency reporting, where it would be the correct metadata choice.

Configuring API rate limits in the AI gateway.

Why it fails: Rate limiting at the gateway enforces runtime availability and abuse controls, which sits in the Manage function's operational monitoring, not Govern. It tempts because gateway throttling is a common AI security control, and it would be the right answer if the question asked how to mitigate denial-of-service or cost-exhaustion attacks against a deployed model.

Conducting a red-teaming exercise for prompt injection.

Why it fails: Red-teaming for prompt injection produces empirical evidence about model robustness, which belongs to the Measure function's testing and evaluation. It tempts because red-teaming is a headline AI security activity, and it would be correct if the stem asked how to assess or validate a generative AI system's resistance to adversarial inputs.

Performing automated unit testing on model outputs.

Why it fails: Automated unit testing of model outputs verifies performance and correctness, placing it in Measure rather than Govern. It tempts because testing underpins trustworthy AI, and it would be the right choice if the question asked how to continuously evaluate a model's output quality or detect regression after retraining.

Number of GPU hours consumed.

Why it fails: GPU hours quantify compute consumption and cost, revealing nothing about AI security controls, threats or residual risk. It is tempting because GPU usage is a tangible AI programme metric boards already see in budget discussions, and it would be relevant for capacity planning or FinOps reporting rather than security posture.

Average model inference accuracy.

Why it fails: Inference accuracy is a model-quality or performance measure, not a security metric; it says nothing about adversarial robustness, data protection or access control. It is tempting because accuracy is the headline AI metric executives understand, and it would be the right choice when reporting model effectiveness or business value.

Total number of model versions created.

Why it fails: Counting model versions measures development throughput, not security posture; the board needs exposure, vulnerability and control-effectiveness indicators. It is tempting because model inventory and versioning underpin AI governance, and tracking versions is genuinely useful for auditability and change management rather than board-level risk reporting.

Directing daily stock market trades.

Why it fails: An AI Ethics Board provides oversight of AI development and use, advising on fairness, transparency and risk; it holds no trading mandate or execution authority. Directing trades belongs to trading desks under investment governance, so this option misassigns an operational function to an advisory body.

Conducting server hardware maintenance.

Why it fails: Hardware maintenance sits with infrastructure or facilities teams, not a governance body; an ethics board reviews model risk, fairness and compliance. It is tempting because boards are sometimes conflated with operational oversight, but the correct choice covers policy and ethical review, not physical server upkeep.

Writing all the Python code for the AI.

Why it fails: An AI Ethics Board sets policy and reviews ethical implications of AI systems; it does not author production code. Writing Python belongs to engineering teams, so this option confuses governance oversight with implementation work that the board is constituted to review independently.

Self-assessment is prohibited for all high-risk systems.

Why it fails: The EU AI Act permits providers to self-assess most high-risk systems against Annex VI, with notified-body involvement reserved for specific cases such as biometric identification. A blanket prohibition tempts because third-party assessment does exist under Annex VII, but it applies only to those listed systems.

Providing a written promise of security.

Why it fails: Conformity assessment under the EU AI Act requires documented technical evaluation against Annex III requirements, not a written promise. A security pledge carries no evidential weight for market placement. It tempts because contractual assurances are common in procurement, but they belong in commercial agreements, not regulatory conformity procedures.

Delegating all compliance to the system deployer.

Why it fails: The EU AI Act places conformity assessment obligations on the provider itself, and deployers cannot absorb that legal duty. Delegation tempts because deployers do carry separate obligations, such as human oversight and monitoring, so it would be correct when describing deployer responsibilities rather than the provider's conformity assessment.

The employee breakroom notice.

Why it fails: A breakroom notice conveys operational or safety reminders to staff and holds no authority to define AI governance positions. It would be appropriate for announcing office logistics, but transparency and explainability commitments require a formal policy document approved through governance channels.

The server configuration log.

Why it fails: Server configuration logs record infrastructure settings and runtime parameters, not governance positions on model transparency or explainability. Such logs would be the correct artefact when auditing deployed server settings, but they cannot express an organisational stance on AI disclosure.

The marketing brochure.

Why it fails: A marketing brochure communicates product benefits to prospective customers and carries no governance authority over AI transparency or explainability. It would be the right vehicle for publicising approved AI features, but the stance itself belongs in a formal policy or governance document.

By the programming language used.

Why it fails: Programming language says nothing about an AI system's risk, purpose or data handling, so it cannot drive governance controls. It is tempting because language choice affects maintainability and tooling, and would matter for engineering standards or skills planning — but classification for governance must reflect impact and autonomy.

By the number of developers assigned.

Why it fails: Developer headcount says nothing about an AI system's risk, autonomy or data sensitivity, so it cannot drive governance controls or oversight tiers. Classification should follow risk and impact, such as EU AI Act categories. Counting developers would only be relevant for capacity planning or team resourcing, not governance.

By the date of deployment.

Why it fails: Deployment date is a lifecycle timestamp, not a risk attribute, so it cannot determine oversight, documentation or approval requirements. It tempts because newer systems may lack maturity and older ones may be unmaintained, which matters for patch and review scheduling — but governance classification must reflect purpose, impact and data.

Disabling all network access to the internet.

Why it fails: Cutting all internet access blocks sanctioned SaaS and cloud services alongside shadow AI, so business operations fail while unsanctioned tools simply move to mobile networks. Full egress denial suits isolated environments, not enterprises needing visibility and control over AI usage.

Ignoring the usage until a breach occurs.

Why it fails: Waiting for a breach forfeits any chance of detection or containment, leaving data exfiltration and model leakage unaddressed until damage is done. It would only be defensible where usage is genuinely sanctioned and monitored, which is the opposite of shadow AI.

Sending disciplinary emails to all employees.

Why it fails: Disciplinary emails punish discovered use without discovering it, since shadow AI is by definition invisible to the security team; they also drive usage further underground. Sanctions belong within a governance programme after detection, not as the primary enterprise-level control.

To market the model to external customers.

Why it fails: A validation report is an internal governance artefact for risk committees and auditors, evidencing independent challenge of the model. Marketing material is produced by product or sales functions. It is tempting because validation results can support external claims, but customer-facing promotion is not the report's objective.

To reduce the model development time.

Why it fails: Validation occurs after development, independently challenging assumptions, data and outputs to surface model risk; it does not shorten build time. It is tempting because validation findings can feed back into iterative development, but accelerating delivery is a project-management outcome, not the report's objective.

To guarantee 100% accuracy in all scenarios.

Why it fails: A validation report documents independent assessment of a model's conceptual soundness, data quality and performance against defined risk tolerances; no methodology can guarantee 100% accuracy across all scenarios. It is tempting because validation does test accuracy, but only within stated assumptions and datasets — an unattainable guarantee is not its objective.

A public press release.

Why it fails: A press release is marketing material, offering no audited evidence of controls, data handling or model governance. It is tempting because it is public and easy to obtain, and would suffice for initial market awareness, not for formal third-party risk due diligence.

A standard company invoice.

Why it fails: An invoice confirms billing details only, providing no assurance over security, privacy or model risk controls. It is tempting because it is a standard procurement artefact, and would be correct for verifying commercial terms, not for due diligence on an AI provider's governance.

The employee directory.

Why it fails: An employee directory reveals nothing about security controls, data protection or AI model governance, so it cannot evidence due diligence. It is tempting because it identifies personnel contacts, and would be useful for operational escalation, not for assessing a provider's risk posture.

Re-training the model without a review.

Why it fails: Retraining alters model weights but leaves the governance failure that let security requirements lapse unaddressed, so the same defect recurs. Retraining is correct after a documented root-cause and change-control review identifies data or drift as the cause, not as a substitute for that review.

Immediate deletion of all data.

Why it fails: Deleting all data destroys the evidence and artefacts needed for root-cause analysis and remediation, and may breach retention duties. Data destruction is correct at end-of-life or when data is unlawfully held, following approved disposal procedures, not as a response to unmet security requirements.

Ignoring the policy until the end of the year.

Why it fails: Deferring to year-end leaves the project operating outside its security requirements, extending exposure and breaching policy obligations. Scheduled annual review is appropriate for stable, low-risk systems, not for an active failure requiring immediate governance escalation and remediation.

Deleting logs after 24 hours.

Why it fails: Purging logs after 24 hours destroys the evidence trail auditors need to reconstruct how a decision was reached, directly defeating auditability. Short retention is tempting for privacy or storage-cost reasons, but it belongs in data-minimisation contexts, not where traceability of model inputs, weights and outputs must be preserved.

Using proprietary black-box models only.

Why it fails: Proprietary black-box models hide internal weights and logic, so auditors cannot trace how an output was produced. Closed models are tempting for vendor support and performance, and are acceptable where only outcomes matter, but auditability demands explainable, inspectable decision paths that black boxes cannot expose.

Hardcoding all decisions.

Why it fails: Hardcoding every decision removes the model's ability to record reasoning, inputs or confidence, leaving nothing to inspect after the fact. Deterministic rule engines are tempting where repeatability and safety matter, but auditability requires logged, reconstructable decision provenance — not fixed outputs that bypass logging entirely.

The Cloud Service Provider.

Why it fails: A Cloud Service Provider supplies infrastructure and platform components under shared responsibility, but the deploying business unit retains accountability for the AI system's outcomes and risks. It is tempting because the CSP hosts the model and data, so failures appear to originate there, yet contractual responsibility for use and impact stays with the organisation.

The external auditor.

Why it fails: An external auditor provides independent assurance over controls and reports findings; they do not own the AI system's business outcomes or bear accountability for its decisions. It is tempting because auditors assess AI governance and risk, but accountability rests with the business unit's leadership, who own the system and its results.

The junior data scientist.

Why it fails: A junior data scientist implements models but holds no accountability for deployment outcomes; governance responsibility sits with executive leadership, not technical staff. It is tempting because data scientists build and tune the system, so their hands-on role can appear decisive, yet accountability for business impact and risk remains with the owning business unit's leadership.

Improving model prediction speed.

Why it fails: Watermarking adds provenance and ownership evidence; it does not alter inference computation, so prediction speed is unaffected. It is tempting because governance and performance are both model concerns, but the benefit here is traceability and misuse detection, not latency reduction.

Preventing unauthorized hardware usage.

Why it fails: Watermarking embeds a detectable signal in model outputs or weights to prove provenance and detect misuse; it has no bearing on hardware authorisation or licensing. It is tempting because governance covers asset control, but hardware usage is enforced by licensing or attestation mechanisms, not watermarking.

Reducing model memory footprint.

Why it fails: Watermarking embeds identifying signals for provenance verification; it does not compress weights or activations, so memory footprint is unchanged. It is tempting because model optimisation and governance are often discussed together, but the actual benefit is proving model origin and detecting unauthorised use.