AI Risk Governance And Framework Integration practice questions

Step 2: Select controls

Why it fails: Selecting controls occurs after the governance framework is defined.

Step 1: Categorize system

Why it fails: Categorization focuses on impact levels, not lineage.

Continuous Monitoring phase

Why it fails: Monitoring occurs after the system is deployed.

Enable Audit (Premium)

Why it fails: While necessary for broader auditing, the specific AI hub logging is the granular requirement here.

Set up Data Loss Prevention (DLP) policies

Why it fails: DLP restricts data flow but is not the primary mechanism for prompt logging.

Enable sensitivity labels

Why it fails: Sensitivity labels classify data but do not capture prompt logs.

Automatically disable the model.

Why it fails: Automatic disabling applies when a model breaches the High or Critical threshold, where immediate containment is required. Exceeding Moderate triggers a defined review or escalation step, not shutdown, so disabling halts legitimate pricing operations unnecessarily and skips the mandated governance process for that band.

Continue operation while monitoring for additional errors.

Why it fails: Continued monitoring suits a model still within its approved risk band, where periodic observation suffices. Once the score exceeds Moderate, the framework requires a mandatory escalation — reassessment, review or approval — rather than passive observation, so monitoring alone leaves the breach unaddressed and non-compliant.

Update the training data set to improve the score.

Why it fails: Retraining addresses the model's underlying behaviour, but the governance framework mandates a defined escalation action once the Moderate threshold is crossed, such as review or approval, before any remediation. Updating training data is the right response to a performance or drift finding, not to a threshold breach requiring governance sign-off.

To decommission the model permanently.

Why it fails: A post-implementation review evaluates whether the deployed model meets its objectives, risks and controls; it does not retire the system. Decommissioning is tempting because reviews can recommend retirement, but that decision belongs to a separate lifecycle stage, not the review's primary objective.

To ensure the developers received their bonuses.

Why it fails: Human resources management is outside the scope of AI risk governance.

To increase the model's complexity for better performance.

Why it fails: Increasing complexity is a technical goal, not a governance goal.

To ensure the developers received their bonuses.

Why it fails: Human resources management is outside the scope of AI risk governance.

To decommission the model permanently.

Why it fails: Decommissioning is one potential outcome, but the review's goal is assessment.

It is the only requirement for model governance.

Why it fails: Governance involves many more processes than just Red Teaming.

It is a marketing exercise to show off model robustness.

Why it fails: Red Teaming is a risk-identification activity, not a sales activity.

It should be performed by the same team that developed the model.

Why it fails: Red Teaming requires independence to be effective.

It is the only requirement for model governance.

Why it fails: Governance involves many more processes than just Red Teaming.

Performing a red-teaming exercise on the model inputs.

Why it fails: This is part of the 'Measure' or 'Test' functions, not 'Govern'.

Configuring automated PII scrubbing in the data pipeline.

Why it fails: This is a technical implementation of the 'Manage' function.

Reviewing the training dataset for bias using statistical sampling.

Why it fails: This is a 'Measure' activity focused on data quality.

Scanning the source code for hardcoded credentials.

Why it fails: This is a security best practice, not an ethical governance mechanism.

multi_select

Why it fails: ...

Requiring a legal sign-off on the final model deployment.

Why it fails: This is too late in the lifecycle to address design-level ethical risks.

multi_select

Why it fails: ...

Reviewing the production logs for anomalies.

Why it fails: This is a reactive monitoring step.

The marketing budget for upcoming AI product launches.

Why it fails: This is business financial information, irrelevant to AI risk policy.

A list of all employees who have access to the source code repository.

Why it fails: This is an access control list, not a policy component.

The speed of the network bandwidth between training sites.

Why it fails: This is an infrastructure performance metric.

The capability of the internal audit team to audit AI models.

Why it fails: While important, this is an assessment function, not a structural readiness component.

The total number of GPUs available in the data center.

Why it fails: This is a capacity/hardware issue.

Updating the SOC2 Type II report

Why it fails: A SOC 2 Type II report evidences controls over time for assurance purposes, not the contextual risk identification Map requires. Map demands documenting purpose, deployment context, and affected stakeholders. SOC 2 is tempting because it demonstrates governance maturity, but it reports on existing controls rather than framing the autonomous system's risk landscape.

Automating the model deployment pipeline

Why it fails: Automating deployment addresses operational efficiency, sitting outside the Map function's remit of establishing context and identifying risks. Map requires documenting intended purpose, affected populations, and risk tolerances. Pipeline automation is tempting as governance tooling, but it neither characterises the system nor enumerates its risks, which Map specifically requires.

Conducting a quarterly penetration test

Why it fails: Penetration testing validates security controls, aligning with the Measure or Manage functions, not Map. Mapping requires documenting context, purpose, and risk identification for the autonomous system. Penetration testing is tempting because it surfaces vulnerabilities, but it produces evidence after deployment rather than the contextual risk framing Map demands.

Public relations

Why it fails: Public relations manages reputation and messaging, not the risk, legal or data-protection controls an AI governance committee must oversee. It is tempting because PR is consulted on AI incidents and disclosure, but that is crisis communication, not the ongoing oversight representation the committee needs.

Hardware vendors

Why it fails: Hardware vendors supply infrastructure and are commercial counterparties, so they cannot provide independent oversight of AI risk decisions. They are tempting because compute underpins AI systems, but vendor representation belongs in procurement or architecture reviews, not a governance committee that must avoid conflicts of interest.

External marketing agencies

Why it fails: Marketing agencies supply campaign execution, not governance oversight of AI risk, compliance or model accountability. They are tempting because external partners often sit on AI steering groups for customer-facing use cases, but that is stakeholder consultation, not the internal control representation a governance committee requires.

Purchasing cybersecurity insurance for AI systems

Why it fails: Insurance transfers residual financial loss after an AI incident; it neither sets nor aligns risk appetite, which is expressed through limits, tolerances and governance. Cover is the right control when the objective is financial protection against defined AI-related losses rather than appetite alignment.

Assigning AI risk ownership to the IT department

Why it fails: Assigning ownership to IT places AI risk in a technology silo, separating it from enterprise risk governance and appetite-setting. Alignment requires AI risk owned and reported within the ERM structure. IT ownership is appropriate for technical controls such as model deployment and monitoring, not appetite alignment.

Implementing a standalone AI audit program

Why it fails: A standalone AI audit programme provides independent assurance after the fact; it does not connect AI tolerances to enterprise limits. Alignment requires AI risk appetite statements and metrics integrated into the ERM framework. Standalone auditing suits verifying controls once appetite and boundaries are already established.

Data scientists' training hours per quarter

Why it fails: Training hours count staff activity, revealing nothing about whether deployed models still perform accurately or fairly. It is tempting because it is easy to collect and shows governance investment, but board-level model performance reporting requires outcome metrics such as accuracy, drift and bias, not input effort measures.

Computational resource utilization percentage

Why it fails: Resource utilisation measures infrastructure cost and capacity, not whether models remain accurate, fair or compliant. Boards need model performance and risk indicators such as drift, accuracy and bias. Utilisation belongs in operational capacity reporting, not governance-level oversight of AI model trends.

Model latency in milliseconds

Why it fails: Latency measures serving responsiveness, not whether predictions remain accurate, unbiased or stable as data drifts. It is tempting because milliseconds are simple to monitor and affect user experience, but the CRO's performance-trend reporting needs accuracy, drift and fairness metrics that evidence model risk over time.

Personnel physical security badges

Why it fails: Physical badge controls sit outside the AI model lifecycle and address facility access, not model risk. Auditing should cover data provenance and quality, model development and validation, and deployment monitoring for drift and bias. Badge records would be relevant to a physical security audit, not AI compliance.

Office climate control settings

Why it fails: Office climate control settings are a facilities concern with no bearing on AI model lifecycle auditing, which covers data provenance, training, validation, deployment and monitoring controls. It is tempting because physical environment controls appear in broader IT audit checklists, where they would be the correct focus for data-centre or hardware assurance.

Assign AI risk ownership to individual data scientists

Why it fails: COSO ERM assigns risk ownership at the enterprise or business-process level, with oversight independent of the people building the model. Naming individual data scientists creates self-assessment, removing the segregation between risk-taking and risk-owning. It is tempting because data scientists understand model behaviour, and in a small team they may legitimately act as control operators.

Disable all open-source AI libraries

Why it fails: A blanket ban removes legitimate open-source components rather than governing them, so it cannot map to COSO's risk identification, assessment and response components. It tempts because open-source supply-chain risk is real, and in highly regulated or air-gapped environments an approved-libraries-only policy is a defensible control.

Mandate daily model training cycles

Why it fails: Daily retraining is an operational cadence, not a governance control, and it increases model drift, compute cost and change-management exposure without addressing COSO's risk appetite, tolerance or reporting components. It tempts because frequent retraining genuinely helps fast-moving fraud or demand models where data distributions shift hourly.

Hardware procurement schedules

Why it fails: Procurement is an operational function unrelated to risk register requirements.

Technical documentation of model architecture

Why it fails: This is model documentation, not specifically a risk register requirement.

Mean Squared Error (MSE)

Why it fails: MSE is a granular regression error metric that gives directors no business-risk framing such as drift magnitude, affected segments or retraining triggers. It is tempting because it quantifies prediction error precisely, and it would suit a data science team monitoring model performance rather than a board report.

GPU utilization percentage

Why it fails: GPU utilization percentage measures hardware consumption, not model drift, so it cannot evidence whether predictions still match reality for the board. It is tempting because it genuinely supports capacity planning and infrastructure cost reporting, where it would be the right metric. Drift requires statistical comparison of input distributions or prediction accuracy over time.

Latency per inference request

Why it fails: Latency per inference request measures serving responsiveness, not model drift, so it cannot evidence the board's requested risk view. It is tempting because latency monitoring genuinely belongs in operational dashboards, where it would be the right metric for detecting performance degradation or capacity shortfalls in production inference endpoints.

Replace the COSO risk taxonomy with the NIST AI RMF taxonomy entirely.

Why it fails: Discarding COSO's taxonomy destroys the existing ERM structure the mapping must connect to, leaving no common reference points. It is tempting because harmonising taxonomies reduces duplication, and would be correct where no established ERM framework exists and one is being built from scratch.

Automate all AI model monitoring using only the NIST RMF 'Measure' function.

Why it fails: The Measure function covers AI risk metrics and monitoring, not the crosswalk linking NIST RMF functions to COSO components. It is tempting because continuous monitoring underpins AI risk management, and would be correct where the requirement is operational telemetry on deployed models rather than framework alignment.

Assign AI model owners to report directly to the NIST oversight board.

Why it fails: Reporting lines to a NIST oversight board do not exist; NIST publishes the framework and holds no governance authority over firms. It is tempting because clear AI accountability is valuable, and would be correct where an internal AI governance committee needs defined model ownership and escalation paths.

The Chief Technology Officer (CTO).

Why it fails: A CTO chairs technology strategy and delivery, not enterprise risk appetite, so cannot arbitrate risk tolerance across functions. It is tempting because the CTO owns AI platforms and technical controls, but a governance committee needs the Chief Risk Officer's enterprise-wide risk mandate.

The Lead AI Data Scientist.

Why it fails: A lead data scientist chairs model development and experimentation, not enterprise risk appetite, so lacks authority to set risk tolerance. It is tempting because this role understands AI failure modes technically, but a governance committee needs the Chief Risk Officer's enterprise-wide risk mandate.

The Head of Marketing.

Why it fails: A Head of Marketing chairs customer and brand strategy, not enterprise risk appetite, so cannot arbitrate risk tolerance across functions. It is tempting because marketing owns AI use cases and reputational exposure, but a governance committee needs the Chief Risk Officer's enterprise-wide risk mandate.

The total computational cost of running the models.

Why it fails: Computational cost is a resource-efficiency measure, not an accountability control, so it cannot evidence assigned ownership or oversight of AI risk. It is tempting because finance and boards track spend closely, and it would be correct when reporting infrastructure budget or model running costs rather than AI RMF accountability.

The number of lines of code written for the AI model.

Why it fails: Lines of code measure development effort, not governance accountability, so they evidence nothing about oversight, ownership or risk decisions. It is tempting because code volume is easy to count and sounds technical, and it would suit a software-estimation or maintainability discussion rather than an AI RMF board metric.

The frequency of model retraining cycles.

Why it fails: Retraining frequency describes operational cadence, not accountability, so it shows nothing about who owns AI risk decisions or how they are reviewed. It is tempting because regular retraining looks like active governance, and it would be correct when demonstrating model maintenance or drift-management practise instead.