Select Two (Multi-Select) Questions

Using cloud-based storage

Why it fails: Cloud-based storage is a hosting location, not a leakage mechanism; leakage occurs when training data contains information about the target or test set, such as target-derived features or preprocessing fitted before splitting. Auditors examine pipeline stages for that contamination, whereas cloud storage is simply an infrastructure choice.

Documenting model parameters

Why it fails: Documenting model parameters is legitimate reproducibility practise, not leakage; leakage is train-test contamination or target information entering features. It is tempting because documentation touches training artefacts, and it would be correct if parameters were exposed to inference inputs rather than recorded for audit.

Using open-source libraries

Why it fails: Open-source libraries are a supply-chain and licensing concern, not leakage of training data into features. Leakage means target-derived information entering predictors, such as scaling before splitting or including post-outcome columns. Auditors review library provenance for vulnerability and licence risk, which is a separate control objective from leakage detection.

Selecting a font

Why it fails: Font selection is a presentation or branding decision made once during design, not an ongoing operational concern. AI operational challenges involve monitoring drift, data pipeline reliability, model retraining, cost control, and latency in production. Typography belongs to interface design, where it would be the relevant consideration.

Writing poetry

Why it fails: Poetry generation is a creative content task, not an operational concern such as model drift, latency, cost control or hallucination monitoring. It is tempting because generative AI demonstrably writes verse, but that capability belongs to use-case selection, not to running AI systems in production.

Buying new office chairs

Why it fails: Office furniture is a facilities and workplace procurement matter, unrelated to running models in production. AI operational challenges concern inference latency, drift detection, retraining cadence, data quality, and compute cost. Chairs would be the correct answer only in a workplace-planning or ergonomics question.

Updating the corporate logo

Why it fails: Changing the corporate logo has no bearing on model training or evaluation and cannot reveal bias. It is tempting only as a distractor resembling a governance action, but detecting bias requires techniques such as disaggregated metric analysis and re-sampling or re-weighting the imbalanced groups.

Changing the font size in the UI

Why it fails: Font size is a presentation setting with no connection to model inputs, predictions or group error rates, so it cannot reveal disparate impact across demographics. Bias detection requires statistical techniques such as disaggregated performance metrics or fairness indicators; UI styling belongs to accessibility and design review, not audit testing.

Increasing the number of project meetings

Why it fails: Project meetings generate no measurement of model outputs across demographic groups, so they cannot reveal disparate error rates or representation gaps. It is tempting because stakeholder discussion feels like oversight, but bias detection requires quantitative fairness metrics and subgroup testing.

Manual code refactoring

Why it fails: Model observability relies on runtime instrumentation — logging predictions, monitoring drift, latency and data quality — not on rewriting source code. Manual refactoring alters model or pipeline code before deployment and produces no telemetry about live behaviour. Refactoring would be the right activity when remediating technical debt or improving maintainability, not for observability.

Database backup frequency

Why it fails: Database backup frequency concerns durability and recovery of stored data, not the runtime behaviour of a deployed model. Observability requires capturing inference metrics, input drift and prediction distributions from the serving path. Backup scheduling would be the correct control when defining recovery point objectives for the feature store or training data.

Developer salary audits

Why it fails: Salary audits reveal nothing about a deployed model's runtime behaviour, so they cannot surface drift, latency or token-level metrics. They are tempting because workforce cost analysis belongs to HR budgeting, where auditing developer pay against market bands would indeed be the right exercise.

Office temperature

Why it fails: An automated deployment log documents release artefacts, timestamps, environments and results. Office temperature is environmental telemetry unrelated to what code was deployed, by whom, or whether it succeeded. It would belong in a facilities monitoring system, not a deployment audit trail.

Team member home address

Why it fails: A deployment log records automated release metadata such as build identifiers, timestamps, environments and approvers; a home address is personal data with no bearing on what was deployed or when. It would belong in an HR or personnel record, not an audit trail of deployment events.

Favorite programming language

Why it fails: Deployment logs capture machine-generated release facts: version numbers, commit hashes, target environments and outcomes. A favourite programming language is a personal preference that changes nothing about a deployment and cannot support rollback or audit. It would fit a skills inventory, not a deployment record.

Temperature drift

Why it fails: Temperature drift is not a recognised category of AI model drift; it describes environmental or hardware variation, not statistical change in data or concept relationships. It is tempting because 'drift' suggests gradual change over time, but the actual axes are data drift, concept drift, and label drift, which concern input distributions and target mappings.

CPU drift

Why it fails: CPU drift is not a recognised category of AI model drift; it refers to processor timing or frequency variation, not change in the statistical relationship between inputs and outputs. It is tempting because performance degradation sounds like drift, but the actual types are data drift, concept drift, and label drift.

Memory drift

Why it fails: Memory drift is not a recognised category of AI model drift; it describes resource consumption or state accumulation in software, not statistical divergence between training and production data. It is tempting because models can degrade as memory grows, but genuine drift types are data drift, concept drift, and label drift.

The lobby receptionist

Why it fails: A lobby receptionist holds no ownership of the processes, systems or data within the audit scope, so cannot define boundaries, risks or controls. Reception staff are the right interviewees when the audit covers physical site access, visitor logging or building entry procedures.

The company's external marketing agency

Why it fails: An external marketing agency operates outside the organisation's control environment and cannot describe internal processes, assets or risk appetite within scope. External agencies are the right interviewees when the audit covers outsourced marketing data processing or third-party contractual obligations.

Office cleaning staff

Why it fails: Cleaning staff hold no audit-relevant accountability for AI governance, risk treatment or control operation, so their testimony cannot evidence scoping decisions. They are tempting because facilities personnel do interact with physical access controls and asset registers, which matters when auditing data-centre or on-premises infrastructure scope rather than AI system stakeholders.

Company CEO name

Why it fails: A CEO's name has no bearing on pipeline execution time; latency is governed by model inference, data transfer and compute provisioning. It tempts because leadership decisions shape AI strategy, but strategy does not determine per-request pipeline latency.

Office building height

Why it fails: Office building height does not affect AI pipeline latency, which depends on compute, network and storage performance. It tempts because physical premises appear in some infrastructure discussions, yet building geometry has no bearing on request processing time.

Increased electricity consumption of servers

Why it fails: Drift degrades model accuracy and reliability, not server power draw; electricity is an infrastructure cost unrelated to distributional shift. It is tempting because retraining drifted models does consume compute, which is relevant when auditing operational cost rather than model risk.

Inability to access the source code of the model

Why it fails: Model drift concerns degradation of predictive accuracy as data distributions shift, not source-code availability, which is an explainability and IP concern. Auditors address drift through monitoring performance metrics, retraining triggers and data-distribution checks. Source-code access would matter for auditing proprietary or opaque third-party models.

Ask developer for coffee

Why it fails: Decommissioning covers technical and governance tasks such as archiving model artefacts, revoking endpoint access, and notifying stakeholders; fetching coffee is unrelated to any AI governance lifecycle. It is tempting as a joke answer, but it satisfies no decommissioning requirement and addresses no model, data, or access concern.

Delete all company records

Why it fails: Decommissioning retires a model from production by archiving artefacts, revoking access, and updating documentation; deleting all company records destroys unrelated business data and violates retention obligations. It is tempting as a clean-up step, but record deletion is a data-governance decision, not part of the model retirement workflow.

Increasing the size of the marketing team

Why it fails: Marketing headcount does not establish accountability, oversight, or risk controls, so it cannot satisfy governance requirements such as defined roles, policies, and audit mechanisms. It is tempting because AI governance needs organisational buy-in and communication, but those are outcomes of governance structures, not a critical framework component.

Choosing the most expensive cloud platform

Why it fails: Cost does not deliver the policies, risk assessments, or oversight bodies that AI governance requires; an expensive platform can still lack the necessary controls. It is tempting because procurement decisions feel consequential and budget signals commitment, but governance frameworks are defined by accountability and process, not by the price of the underlying cloud service.

Unprotected endpoints

Why it fails: Unprotected endpoints accept requests without authentication or authorisation, so any caller can invoke the model and exfiltrate data. It is tempting when rapid prototyping demands zero-friction access, and would be acceptable only for an isolated, non-production sandbox holding no sensitive data or credentials.

Storing logs on public S3

Why it fails: Public S3 buckets expose inference logs containing prompts and outputs to anyone, breaching confidentiality requirements. It is tempting because public buckets remove access-management overhead for quick debugging, and would be valid only for intentionally published, non-sensitive artefacts such as open sample datasets.

Public internet access

Why it fails: Public internet access exposes the endpoint to unauthenticated traffic, defeating the private networking and authentication controls the scenario requires. It is tempting because public endpoints simplify external client connectivity, and would be valid for a deliberately open, non-sensitive demo API where no data protection is needed.

Developer age demographics

Why it fails: Developer age demographics describe the build team, not the model's behaviour, so they cannot evidence suitability for production. They are tempting because workforce diversity metrics matter in governance reviews, and would be relevant when auditing team composition or bias in development processes rather than the deployed model itself.

Operating system color schemes

Why it fails: Colour schemes affect neither model accuracy, fairness, robustness nor data governance, so they cannot inform suitability. Auditors assess training data provenance, evaluation metrics and bias testing. Interface theming belongs to user-experience review, where accessibility contrast standards would be the relevant criterion.

Marketing campaigns for AI product launches

Why it fails: Marketing campaigns promote AI products; they play no part in detecting, containing or recovering from an AI incident. It is tempting because launch governance and customer communication can matter after a public AI failure, and campaign planning would be correct when the objective is commercial go-to-market rather than response readiness.

Software license management for all developers

Why it fails: License management tracks software entitlements, not AI incidents; it neither detects model drift nor triggers containment or rollback. It is tempting because governance and compliance tooling genuinely supports AI programmes, and licence audits would be the right control when the requirement is cost or legal compliance rather than incident response.

Automated email server maintenance

Why it fails: Email server maintenance is routine IT operations and plays no part in detecting, containing, or recovering from AI incidents. An incident response strategy covers AI-specific harms such as model drift, data leakage, and adversarial input. Maintenance is tempting as general hygiene, but it addresses availability, not AI incident handling.

Network bandwidth optimization plans

Why it fails: Network bandwidth optimisation concerns infrastructure performance, not AI governance, risk or compliance controls. It is tempting because operational capacity planning supports AI systems, and bandwidth plans would be correct when scoping the infrastructure readiness assessment that underpins deployment of a governed AI workload.

Automated model training hyperparameter tuning

Why it fails: Hyperparameter tuning is a model development activity, not a governance or risk assessment component. It is tempting because tuning affects model performance and reproducibility, and automated tuning would be correct when the requirement is optimising model accuracy within an MLOps pipeline rather than establishing oversight controls.

The programming language used to build the model

Why it fails: The programming language is an implementation detail that does not influence whether outcomes are equitable across groups; fairness depends on data representation, label quality and error-rate parity. It is tempting because language choice affects library availability and performance tuning, and would matter when selecting a stack for reproducibility or deployment constraints, not for assessing bias.

The number of CPU cores allocated for training

Why it fails: CPU core allocation affects training throughput and cost, not the distribution of outcomes across groups, so it cannot measure Fairness. It is tempting because compute provisioning genuinely matters when sizing training infrastructure or diagnosing slow convergence. Fairness instead requires evaluating disparities in model performance across protected groups, which hardware allocation never captures.

Company stock price

Why it fails: Company stock price has no bearing on AI pipeline operational availability. Critical components are data ingestion, model serving endpoints, and infrastructure health such as latency, throughput and error rates. Stock price is tempting because dashboards often display business metrics, but it is unrelated to pipeline uptime or availability monitoring.

Developer social media activity

Why it fails: Social media activity has no operational relationship to pipeline availability; monitoring should cover model inference latency, data ingestion and compute resource health. It is tempting because developer sentiment can signal project risk, but that belongs to team or reputational analysis, not AI pipeline availability monitoring.

The number of lines of code in the pipeline

Why it fails: Line count measures code volume, not pipeline security controls such as encryption, access logging or input validation, so it evidences nothing about data protection. It is tempting because code metrics can flag maintainability or review coverage, and would be relevant when assessing software quality or change-management rigour rather than pipeline security.

Office access badge logs

Why it fails: Badge logs record physical entry to offices, not logical access to pipeline components, so they cannot evidence encryption, IAM permissions or audit logging across the data flow. They are tempting because physical access controls are a genuine audit domain, and would be correct when the scope covers data-centre or facility security.

Cloud provider logo

Why it fails: A cloud provider's logo is decorative branding, carrying no information about model provenance, training data, hyperparameters, or approval status, so it cannot support an audit trail. Registries record model versions, artefacts, and evaluation metrics. It is tempting because vendor attribution appears on documentation, but that belongs in marketing material, not the registry.

Employee birthday

Why it fails: An employee's birthday is personal data irrelevant to model lineage, versioning, or reproducibility, and recording it in a registry creates privacy exposure without audit value. Registries track model versions, training datasets, metrics, and approvals. It is tempting because HR records are audited elsewhere, but that is a separate compliance domain.

The office address of the IT department

Why it fails: An office address is administrative contact data and evidences nothing about model training. It is tempting because audit scoping often begins with organisational and site details, so location records surface early. Verifying training requires datasets, training scripts or pipeline configurations, hyperparameters, and run logs showing the process executed.

Employee performance reviews

Why it fails: Employee performance reviews are HR records describing staff appraisal, not evidence of how a model was trained. They are tempting because training data often involves human labelling, so reviewer output can feel related. Auditors instead need datasets, training code or pipeline definitions, hyperparameters, and training logs or metrics.