Responsible Product Governance, Ethics and Risk

Introduction

Digital products increasingly make decisions about identity, access, eligibility, safety, communication, employment, finance, health and public services. Their effects extend beyond the person who downloads an application or pays a subscription. Data may concern employees, children, customers, non-users and communities; automated decisions may distribute opportunities and burdens; and software may operate across jurisdictions with different legal and cultural expectations.

Responsible product governance is therefore not a compliance activity added after launch. It is a product-management capability that connects strategy, design, engineering, operations, legal review and organisational accountability. Its purpose is to ensure that a product is useful, lawful, secure, inclusive, explainable where appropriate, and capable of being corrected when it causes harm.

This chapter presents an integrated approach to privacy, security, consent, intellectual property, accessibility, regulation and responsible artificial intelligence. It also introduces practical mechanisms including risk registers, data and model documentation, impact assessments, audits, incident response and responsible innovation controls.

Learning objectives

By the end of this chapter, the learner should be able to:

1. Distinguish privacy, security, consent, confidentiality, governance and accountability.
2. Apply privacy-by-design, security-by-design and accessibility-by-design principles.
3. Identify major intellectual-property and data-rights issues in digital products.
4. Analyse AI systems for bias, fairness, explainability, transparency and accountability.
5. Construct a product risk register and prioritise controls.
6. Explain the purpose of model cards, data sheets, audit trails and impact assessments.
7. Design governance processes for launch, monitoring, incident response and retirement.
8. Evaluate the strategic and ethical trade-offs involved in responsible innovation.

1. Governance as a product capability

Governance is the system of decision rights, policies, controls, evidence and escalation paths through which an organisation directs and supervises a product. It answers five practical questions:

• Who may make a decision?
• What standards and laws constrain that decision?
• What evidence is required before deployment?
• How will performance and harm be monitored?
• Who is accountable when the product fails?

Governance differs from management. Product management coordinates discovery, prioritisation and delivery; governance establishes the boundaries and conditions within which those activities are legitimate. Governance also differs from ethics in a narrow sense. Ethics concerns justified judgments about what ought to be done, while governance turns such judgments into repeatable organisational practices. Law is an essential constraint, but lawful conduct is not always sufficient for responsible conduct.

A useful governance principle is proportionality: the intensity of review should reflect the product's potential impact, scale, reversibility and uncertainty. A spell-checking feature generally requires less formal review than an AI system used to rank job applicants, determine insurance pricing or recommend medical treatment. Proportionality must not become an excuse for ignoring low-probability catastrophic risks; severe outcomes may justify strong controls even when probability is uncertain.

The accountability chain

Accountability should be allocated across the product life cycle rather than assigned only to a compliance officer. Typical roles include:

A product manager cannot transfer accountability simply by outsourcing development or using a third-party AI service. Vendors can perform processing or provide infrastructure, but the organisation remains responsible for choosing suppliers, defining permitted uses, monitoring performance and responding to failures.

2. Privacy, data protection and consent

Privacy is broader than secrecy. It includes appropriate control over personal information, observation, inference, identity, relationships and participation. Personal data generally includes information relating to an identified or identifiable person; the definition and applicable duties vary by jurisdiction. Sensitive categories may receive additional protection. Product teams should not assume that data becomes non-personal merely because names are removed: combinations of location, time, device attributes and behaviour may permit re-identification.

Data governance principles

A robust data practice commonly includes:

• Purpose limitation: collect and use data for specified, legitimate purposes rather than undefined future exploitation.
• Data minimisation: collect what is necessary for the purpose, not everything technically available.
• Accuracy: provide mechanisms to correct materially inaccurate data.
• Retention limitation: define how long data is needed and delete or anonymise it when the period ends.
• Integrity and confidentiality: protect data against unauthorised access, alteration, disclosure and loss.
• Accountability: retain evidence that the organisation has applied and can demonstrate these principles.

These principles influence product design. A feature requiring continuous location should be challenged: Is continuous precision necessary? Could coarse location, temporary access or on-device processing achieve the same value? Can the user understand the consequence of refusing access? Such questions often produce both safer and more efficient products.

Consent is a design relationship

Consent is not merely a checkbox. For consent to be meaningful, it normally needs to be informed, specific, freely given and expressed through a clear affirmative action, subject to the relevant legal regime. A pre-ticked box, bundled acceptance of unrelated purposes, confusing language or a refusal that unfairly blocks an unnecessary feature undermines meaningful choice.

Consent is also not the universal legal basis for data processing. Depending on jurisdiction and context, processing may rely on contract, legal obligation, legitimate interests, protection of vital interests or another recognised basis. Product teams must not choose consent simply because it is familiar. Where consent is used, the system should record what was presented, when, how the user acted, what purpose was accepted and how withdrawal will work. Withdrawal should be practically available and should not require disproportionate effort.

Children and other vulnerable groups require enhanced safeguards. Age assurance, parental involvement, safer defaults, reduced profiling and plain-language explanations may be necessary. Age assurance itself creates privacy and fairness risks, so collecting identity documents should not be treated as the automatic solution.

Privacy engineering

Privacy engineering converts principles into technical and organisational controls. Examples include encryption in transit and at rest, role-based access, tokenisation, pseudonymisation, privacy-preserving analytics, separate data stores, retention automation, access logging and deletion workflows. Differential privacy can reduce disclosure risk in aggregate statistics by adding calibrated noise, but it introduces a privacy–utility trade-off and requires careful parameter selection. It is not a substitute for minimisation or access control.

A privacy impact assessment is appropriate when processing may create significant risks, such as large-scale monitoring, sensitive data, systematic profiling or innovative technologies. It should describe the processing, necessity, risks to individuals, mitigations, residual risks and consultation or approval decisions. The assessment is a living product artefact, not a document filed once before launch.

3. Security and resilience

Security protects confidentiality, integrity and availability. Confidentiality limits information access; integrity protects correctness and trustworthiness; availability ensures that authorised users can obtain the service when needed. Product risk may also include authenticity, non-repudiation, safety and resilience.

Security-by-design begins during discovery. Threat modelling asks what assets matter, who may attack them, what attack paths exist, and which controls reduce likelihood or impact. Common methods include abuse cases, attack trees, data-flow diagrams and structured approaches such as STRIDE. A product team should consider account takeover, insecure direct object references, injection, excessive privileges, secrets exposure, supply-chain compromise, model extraction, prompt injection and denial-of-service where relevant.

A practical control baseline includes:

1. Strong authentication and appropriate multi-factor authentication.
2. Least-privilege access and periodic access review.
3. Secure software development, code review and dependency management.
4. Secrets management rather than credentials embedded in code.
5. Encryption and key-management procedures.
6. Logging that supports detection without collecting unnecessary personal data.
7. Vulnerability management, penetration testing and patching.
8. Backup, recovery and tested business-continuity procedures.
9. Coordinated vulnerability disclosure and incident-response playbooks.
10. Supplier-security assessment and contractual incident obligations.

Security is not identical to privacy. A highly secure system may still collect excessive data or use it for unexpected purposes. Conversely, a privacy-friendly design can be insecure if an attacker can access the limited data it holds.

4. Intellectual property and data rights

Digital products combine code, interfaces, text, images, music, databases, trained models, trademarks, trade secrets and user contributions. Rights depend on jurisdiction, contract, licence terms and the nature of the material. Product teams should establish an asset register identifying ownership, licence, permitted use, attribution requirements, geographical limits and expiration or termination conditions.

Important questions include:

• Was code copied from an open-source project, and what obligations does its licence impose?
• Does a commercial licence permit modification, redistribution or use in a hosted service?
• Were training data, images, voices or user posts lawfully obtained and used for the intended purpose?
• Who owns generated outputs, and can the organisation warrant that outputs are non-infringing?
• Are trademarks, confidential information or personality rights implicated?
• Do employment and contractor agreements assign relevant rights to the organisation?

Open-source software is not “free of obligations.” Permissive licences may require attribution and preservation of notices; reciprocal licences may impose conditions when covered code is distributed or combined in specified ways. Automated code generation does not remove the need for licence scanning, human review, testing or provenance records.

Generative AI creates additional uncertainty around training data, output similarity, confidential prompts and ownership. Organisations should avoid sending trade secrets or personal data to a model provider without understanding retention, training-use, access and deletion terms. A defensible policy distinguishes approved, restricted and prohibited uses and requires human review for high-impact outputs.

5. Accessibility and inclusive product design

Accessibility means that people with disabilities can perceive, understand, navigate and interact with a product. It is both a matter of equal participation and a product-quality discipline. Relevant standards may include the Web Content Accessibility Guidelines and jurisdiction-specific disability-discrimination or procurement laws; standards are important, but compliance with a checklist does not guarantee an accessible experience.

Accessibility-by-design includes semantic structure, keyboard operation, sufficient colour contrast, resizable text, captions and transcripts, descriptive labels, focus management, error recovery and compatibility with assistive technologies. Accessibility testing should combine automated checks, manual testing and participation by users with different disabilities.

AI can assist accessibility through captions, image descriptions, translation or speech interfaces, but can also fail disproportionately for accents, speech impairments, low vision or atypical language. Therefore, accessibility features require accuracy monitoring, user correction, fallback paths and an option to complete essential tasks without the automated feature.

Inclusive design extends beyond disability. Language, literacy, age, connectivity, culture, income and device constraints affect whether a product is genuinely usable. A product that technically works but excludes a group from meaningful participation has a governance problem, not merely a user-experience problem.

6. Responsible AI: from principles to evidence

Responsible AI concerns the social and organisational conditions under which AI is designed, deployed and governed. Common principles include human agency, fairness, transparency, explainability, privacy, safety, security, contestability and accountability. Principles become operational only when linked to requirements, tests, owners, thresholds and escalation mechanisms.

Bias and fairness

Bias can enter through problem formulation, sampling, labels, measurement, historical decisions, proxy variables, optimisation objectives, deployment context and human interpretation. It is therefore insufficient to test only the final model. Teams should examine the full pipeline, including who is represented, who is missing, what the target means and whether the product changes behaviour after deployment.

Fairness is not a single universal metric. Potential criteria include:

• Demographic parity: selection rates are similar across groups.
• Equal opportunity: true-positive rates are similar across groups.
• Equalised odds: true-positive and false-positive rates are similar across groups.
• Calibration: among people assigned the same predicted risk, observed outcome frequencies are comparable across groups.

These criteria can conflict, particularly when groups have different base rates or when predictions are imperfect. Product teams must therefore justify the fairness objective in relation to the decision, harms, legal context and affected communities rather than reporting one number as proof of fairness.

For a binary classifier, a confusion matrix separates actual and predicted outcomes. For group g:

Here TP, FN, FP and TN denote true positives, false negatives, false positives and true negatives. TPR is the true-positive rate and FPR is the false-positive rate. These rates are meaningful only when the outcome labels are sufficiently valid, the groups and decision thresholds are defined, and sample sizes support reliable estimation. They do not by themselves establish that a decision is ethically justified.

Explainability and transparency

Explainability concerns whether people can understand relevant aspects of a system's operation or decision. Transparency concerns disclosure about the system, its purpose, data, limitations, governance and use. Neither requires revealing security-sensitive information or proprietary source code in every case.

Different audiences need different explanations. A user may need to know why content was recommended and how to change preferences. An affected person may need the principal factors behind an eligibility decision and a route to appeal. An auditor may require data lineage, test results, version history and access logs. A regulator may require evidence of risk management and compliance.

Explanations should be accurate, stable enough to be useful, actionable and appropriate to the decision. A post-hoc explanation that sounds plausible but does not reflect the model's behaviour is misleading. For high-impact decisions, a human review and meaningful contestability mechanism may be more important than a technically elegant explanation.

Accountability and human oversight

Accountability requires a named owner, documented authority, auditability and remedies. “Human-in-the-loop” is not automatically meaningful: a reviewer who handles thousands of recommendations under time pressure may merely rubber-stamp the model. Effective oversight specifies when humans must intervene, what information they receive, whether they can override the system, how overrides are recorded and whether the organisation learns from them.

A model should not be deployed merely because it performs well in a test environment. Deployment approval should consider intended use, foreseeable misuse, affected groups, reversibility, monitoring capability and the availability of remedy. High-impact uses may require pre-deployment impact assessment, independent review, staged release and explicit executive acceptance of residual risk.

7. Risk management for digital and AI products

Risk is the possibility that an uncertain event produces an undesirable consequence. A product risk register makes uncertainty visible and assigns action. Typical fields are:

For a simple qualitative prioritisation, teams may use:

If each factor is rated on a 1–5 ordinal scale, scores range from 1 to 25. The values are ranking aids, not probabilities or monetary estimates. They should not be multiplied as if a score of 4 were twice as likely as a score of 2. Organisations should define scales, thresholds and escalation rules before using them, and should separately consider uncertainty, velocity, duration, concentration and irreversibility.

A more rigorous expected-loss model may be used when probabilities and consequences can be estimated:

Here p_i is the probability of scenario i and C_i is its consequence, expressed in a consistent unit such as monetary loss. This model assumes scenarios are sufficiently defined and that expected value is an appropriate decision criterion. It can conceal catastrophic low-probability outcomes, distributional injustice and uncertainty in the estimates; it should therefore supplement, not replace, qualitative judgment and legal or ethical constraints.

Risk treatment follows a hierarchy. Avoiding a harmful feature is often stronger than attempting to control it after launch. Reduction may involve minimisation, guardrails, testing or human review. Transfer through insurance or contract does not eliminate responsibility. Acceptance should be explicit, informed and authorised at the appropriate level.

8. Documentation, audits and lifecycle controls

Documentation is a control because it preserves institutional memory, enables review and makes claims testable. Useful artefacts include:

• Data sheet: purpose, sources, collection conditions, representation, quality issues, licensing and recommended uses.
• Model card: intended use, prohibited use, architecture or method at an appropriate level, evaluation data, performance by relevant groups, limitations and monitoring plan.
• System card: broader description of the integrated product, dependencies, user experience, safeguards, misuse scenarios and governance.
• Algorithmic or privacy impact assessment: affected parties, risks, alternatives, mitigations, consultation and residual risk.
• Decision log: significant product choices, evidence, dissenting views, approvals and rationale.
• Audit trail: access, model versions, input or feature changes, decisions, overrides and relevant events, subject to minimisation and retention rules.

Audits may be internal, independent, regulatory, technical or participatory. An audit should have a defined scope, criteria, evidence standard, independence level and remediation process. Metrics alone are inadequate: an audit should test whether controls operate in practice, not merely whether policies exist.

Monitoring should cover technical performance, security, privacy, fairness, user complaints, accessibility, drift, misuse and unexpected effects. A model can degrade because the data distribution changes, user behaviour adapts, labels arrive late or the business process changes. Product teams should define thresholds that trigger investigation, rollback, retraining, restriction or retirement.

9. Regulatory and organisational landscape

Digital products may be affected by multiple overlapping regimes: data-protection and privacy law, consumer-protection rules, anti-discrimination law, employment law, sectoral regulation, cybersecurity obligations, accessibility requirements, intellectual-property law and emerging AI legislation. The exact duties depend on jurisdiction, sector, role, scale, data and use case. A product team should obtain qualified legal advice rather than treating a general framework as a universal legal checklist.

Regulatory readiness involves:

1. Mapping jurisdictions, users, suppliers and data flows.
2. Classifying the product's risk and regulated activities.
3. Assigning accountable officers and decision rights.
4. Translating obligations into product and engineering requirements.
5. Maintaining evidence of testing, consent, notices, access control and incident response.
6. Providing rights-request, complaint, appeal and correction processes where required.
7. Reviewing material changes and new use cases before deployment.

Voluntary frameworks such as the NIST AI Risk Management Framework, OECD AI principles and ISO management standards can structure practice, but they do not replace applicable law. Regulatory compliance should be treated as a floor; responsible product governance also asks whether a legally permitted design is socially acceptable, understandable and proportionate.

10. Responsible innovation operating model

A practical operating model uses stage gates without turning governance into a delivery bottleneck.

Discovery: identify affected parties, intended and foreseeable uses, alternatives, rights, harm scenarios and success criteria beyond revenue or engagement.

Design: minimise data, define consent and notices, specify accessibility, threat-model the system, select fairness and performance measures, and design appeal and human-override pathways.

Build and validate: implement security controls, test representative cases and edge cases, document provenance, conduct red-team and misuse testing, and obtain required approvals.

Launch: use staged release, feature flags, rate limits and rollback plans. Communicate limitations and support channels in language users can understand.

Operate: monitor outcomes, complaints, incidents, drift, access, fairness and accessibility. Review vendors and retrain or recalibrate only through controlled change management.

Retire: stop collection, preserve only justified records, delete or return data, disable integrations, communicate the change and document lessons learned.

A governance council can coordinate difficult decisions, but it should not become a substitute for accountable product ownership. Effective councils include product, engineering, security, privacy, legal, design, operations and—where appropriate—representatives of affected communities. They need authority to delay or reject a launch, access to evidence and a defined escalation route.

Applied case: an AI recruitment-screening product

This is an illustrative case, not a description of a particular organisation.

Background

A software company develops a tool that ranks job applications and recommends candidates to recruiters. It learns from historical hiring data and extracts features from résumés. The commercial proposition is faster screening and more consistent shortlisting.

Problem

Early testing shows high overall predictive performance, but applicants from one demographic group receive fewer recommendations. Historical hiring decisions reflect a workforce that was not representative of the available labour market. Some résumés contain names, schools and employment gaps that act as proxies for demographic characteristics. The vendor proposes removing explicit demographic fields, claiming that this will solve bias.

Analysis

Removing explicit fields does not remove proxy effects. The team must define the legitimate decision objective, examine label quality, assess representation, compare error rates and investigate whether the historical target encodes past discrimination. It must also consider privacy, accessibility, employment regulation, transparency and the applicant's ability to challenge an adverse result.

The initial risk register identifies: discriminatory ranking; inaccurate or incomplete résumé parsing; privacy risks from collecting unnecessary information; security risks involving applicant data; lack of explanation; automation bias among recruiters; and vendor opacity. High impact and limited reversibility justify enhanced review before deployment.

Approach and solution

The team changes the product from automatic rejection to decision support. It removes unnecessary sensitive information from the ranking process, limits retention, encrypts applicant data and establishes role-based access. It evaluates equal-opportunity and false-positive differences by relevant groups, while recognising that no single metric resolves the fairness question. It conducts job-relatedness review with employment specialists and consults affected stakeholders.

Recruiters receive explanations framed as job-related evidence, warnings about limitations and mandatory training against automation bias. Applicants receive a clear notice that automated assistance is used, information about the role of the system and a route for correction or human review, subject to applicable law. The vendor supplies a model card, data-provenance statement, change-notification process and audit access. The launch is staged, with monitoring and a stop rule if material disparities or accuracy failures emerge.

Outcome

The revised product processes fewer applications automatically but produces a more defensible workflow. The organisation accepts a slower screening process in exchange for improved contestability, reduced privacy exposure and better evidence about job-related performance. It also discovers that the greatest problem was not merely the model: it was the historical label and the assumption that efficiency justified automated exclusion.

Learning points

1. Fairness must be analysed across the decision process, not just the algorithm.
2. Removing sensitive variables can leave discriminatory proxies intact.
3. Human oversight must include authority, information and time to challenge the system.
4. Documentation and supplier contracts are operational controls.
5. Responsible innovation may reduce short-term efficiency while improving legitimacy and long-term value.

Challenges and limitations

Responsible governance involves unavoidable tensions. More data may improve personalisation but increase privacy exposure. Stronger fraud detection may create false positives. Explanations may improve contestability but reveal gaming opportunities. Fairness metrics may conflict. Accessibility adaptations may be expensive when systems were not designed for them. Documentation can become performative if no one uses it to make decisions.

There are also epistemic limits. Some harms are difficult to quantify, future effects are uncertain and affected people may not have equal power to participate in consultation. Independent audits can miss emergent behaviour; user consent cannot legitimise every harmful design; and a model that is accurate on average may still be unacceptable for a particular high-stakes use. Governance should therefore combine measurement with precaution, participation, professional judgment and mechanisms for correction.

Best-practice checklist

Before launch, a product team should be able to answer yes—or document why not—to the following questions:

• Is the intended purpose specific and justified?
• Are data collection, retention, access and deletion defined?
• Can users understand choices, consequences and available remedies?
• Has the team assessed security threats, accessibility barriers and misuse?
• Are intellectual-property rights and supplier terms documented?
• Have relevant performance and fairness tests been selected and interpreted appropriately?
• Are model, data and system limitations documented?
• Is there a named accountable owner with authority to intervene?
• Are monitoring, incident response, rollback and retirement plans tested?
• Has residual risk been explicitly accepted at the right level?

Chapter Summary

Responsible product governance integrates law, ethics, risk management and product delivery. Privacy requires purpose limitation, minimisation, appropriate choice, retention control and accountability; security protects confidentiality, integrity and availability through preventive and detective controls. Intellectual-property governance requires provenance, licence review and careful treatment of generated content. Accessibility and inclusion must be designed and tested with affected users.

Responsible AI cannot be reduced to accuracy or a single fairness metric. Bias may arise throughout the data, modelling and deployment pipeline. Fairness criteria can conflict, explanations must be truthful and actionable, and accountability requires named owners, evidence, meaningful human oversight and remedies. Risk registers, impact assessments, model cards, system documentation, audits and monitoring convert broad principles into operational controls. A mature product organisation treats responsible innovation as a strategic capability that protects people, supports trust and improves the durability of product value.

Key Terms

Accountability: The obligation to explain decisions, accept responsibility and provide remedies.

Accessibility: The ability of people with diverse abilities to use a product effectively.

Audit trail: A chronological record of relevant system actions and decisions.

Consent: A meaningful, informed and affirmative expression of agreement to specified processing or use.

Data minimisation: Limiting data collection to what is necessary for a defined purpose.

Explainability: The capacity to provide understandable and relevant accounts of system behaviour or decisions.

Fairness: The normative and measurable treatment of people or groups without unjustified disadvantage.

Governance: Decision rights, policies, controls, evidence and escalation mechanisms for directing a product.

Impact assessment: A structured analysis of affected parties, risks, mitigations and residual risk.

Intellectual property: Legally recognised rights in creations, inventions, brands, confidential information and related assets.

Model card: Documentation describing a model’s purpose, performance, limitations and appropriate use.

Privacy by design: Incorporating privacy protections into product architecture and lifecycle decisions.

Proportionality: Matching governance effort and controls to potential impact, uncertainty and reversibility.

Risk register: A maintained record of risks, causes, impacts, controls, owners and responses.

Security by design: Integrating threat analysis and security controls from product discovery onward.

System card: Documentation of an AI-enabled product, including dependencies, safeguards, limitations and misuse risks.

Transparency: Disclosure that enables relevant stakeholders to understand a system’s purpose, operation and governance.

Vulnerability disclosure: A process for receiving, assessing and communicating information about security weaknesses.

Review Questions

Short Answer Questions

1. How does product governance differ from product management?
2. Why is consent not equivalent to a privacy policy acceptance checkbox?
3. Distinguish privacy from security using one product example.
4. What information should a model card contain?
5. Why can removing protected attributes fail to eliminate AI bias?

Long Answer Questions

1. Explain how privacy-by-design and security-by-design should influence product discovery, development and operation.
2. Compare demographic parity, equal opportunity, equalised odds and calibration. Why can fairness criteria conflict?
3. Discuss the role of accessibility testing, inclusive research and fallback mechanisms in AI-enabled products.
4. Describe how a risk register, impact assessment and audit trail work together across the product lifecycle.
5. Evaluate the claim that legal compliance is sufficient for responsible product innovation.

Analytical / Application Questions

1. A financial product uses an AI model to flag accounts for fraud review. Design a governance plan covering data minimisation, security, fairness, explainability, human review, monitoring and appeals.
2. Construct a five-entry risk register for a generative-AI customer-support assistant that may process confidential customer information. Justify likelihood, impact, controls and escalation decisions.
3. An accessibility audit finds that an automated speech interface performs poorly for users with certain accents and speech impairments. Analyse the ethical and product risks and propose a remediation and launch decision.

Multiple Choice Questions with Answers

Question 1

Which statement best describes product governance?

A. A system of decision rights, controls, evidence and accountability

B. A marketing process for increasing product adoption

C. A technical method for improving model accuracy

D. A method for replacing product managers with legal teams

Correct Answer: A. A system of decision rights, controls, evidence and accountability

Question 2

Which practice most directly reflects data minimisation?

A. Collecting all available user data for possible future use

B. Collecting only data necessary for a specified purpose

C. Retaining data indefinitely after account closure

D. Sharing raw data with every internal team

Correct Answer: B. Collecting only data necessary for a specified purpose

Question 3

For a binary classifier, which expression defines the true-positive rate?

A. TP ÷ (TP + FN)

B. FP ÷ (FP + TN)

C. TN ÷ (TN + FP)

D. FN ÷ (FN + TP)

Correct Answer: A. TP ÷ (TP + FN)

Question 4

Why is removing explicit demographic variables insufficient to guarantee fairness?

A. Models cannot operate without demographic variables

B. Proxy variables and historical labels may still reproduce disadvantage

C. Fairness requires deleting all training data

D. Demographic variables always improve accuracy

Correct Answer: B. Proxy variables and historical labels may still reproduce disadvantage

Question 5

What is the primary purpose of a model card?

A. To document a model’s intended use, performance, limitations and risks

B. To provide a sales forecast for the product

C. To replace all security testing

D. To record only the model’s source code

Correct Answer: A. To document a model’s intended use, performance, limitations and risks

Question 6

Which control most directly supports meaningful human oversight?

A. Automatically accepting every model recommendation

B. Giving reviewers authority, relevant information and time to override decisions

C. Removing all explanations from the user interface

D. Allowing only the model vendor to investigate complaints

Correct Answer: B. Giving reviewers authority, relevant information and time to override decisions

Question 7

A risk register uses a 1–5 likelihood scale and a 1–5 impact scale. What is the score for likelihood 4 and impact 3?

A. 7

B. 12

C. 16

D. 25

Correct Answer: B. 12

Question 8

Which statement about open-source software is most accurate?

A. It is always free of attribution and redistribution obligations

B. Licence terms may impose attribution, notice or reciprocal obligations

C. It cannot be used in commercial products

D. AI-generated code is automatically outside licence considerations

Correct Answer: B. Licence terms may impose attribution, notice or reciprocal obligations

Question 9

Which practice is most consistent with accessibility-by-design?

A. Relying exclusively on automated accessibility scanners

B. Providing keyboard operation, captions, semantic structure and user testing

C. Adding accessibility only after legal complaints

D. Using colour alone to communicate system status

Correct Answer: B. Providing keyboard operation, captions, semantic structure and user testing

Question 10

Why should expected-loss calculations not be the only basis for responsible product decisions?

A. They cannot use probabilities

B. They may conceal catastrophic low-probability harms and distributional injustice

C. They are valid only for marketing decisions

D. They always produce negative values

Correct Answer: B. They may conceal catastrophic low-probability harms and distributional injustice