CDEI common mistakes
CDEI · Understand the traps and how to avoid them.
Treating 'data ethics' as a synonym for legal compliance, so any scenario answer defaults to 'is it legal?' rather than also weighing harms, fairness, and stakeholder impact.
Candidates over-anchor on the regulatory domain they studied most and assume ethical duties are fully captured by law, missing that ethical analysis often goes beyond minimum legal requirements.
What to do instead
For each scenario, explicitly run two separate passes: a legal-compliance pass and an ethical-principles pass, then reconcile them. Practice flagging cases where conduct is lawful but still ethically questionable.
Applying a single ethical theory (usually consequentialism or deontology) to every scenario instead of selecting the framework the question is testing.
Candidates learn one framework well and use it as a hammer, ignoring cues in the stem that point to virtue ethics, justice/fairness, or care ethics.
What to do instead
Build a one-line trigger for each framework (e.g., 'maximizes overall welfare' = consequentialist, 'duty/rule regardless of outcome' = deontological, 'character of the actor' = virtue). Match the stem's language to the framework before answering.
Confusing anonymization, pseudonymization, and de-identification, and assuming any of them removes all re-identification risk.
Everyday usage treats these terms loosely, and candidates carry that looseness into items that hinge on the precise distinction and on residual re-identification risk from linkage attacks.
What to do instead
Memorize the definitions and the risk profile of each: pseudonymized data is still personal data because a key exists; anonymized data must be irreversibly non-identifiable; de-identified data can often be re-linked with auxiliary data. Treat 'zero risk' claims as a red flag.
Accepting a model's aggregate accuracy or a single fairness metric as proof the system is fair.
Candidates equate high overall performance with equitable performance and forget that aggregate metrics can mask subgroup harm and that fairness metrics can conflict.
What to do instead
Always ask for subgroup-level evaluation and check which fairness definition is appropriate to the context (e.g., equal opportunity vs. demographic parity). Recognize that satisfying one fairness metric can violate another, so the choice must be justified by the use case.
Treating data governance as purely an IT or tooling problem rather than a set of roles, policies, and accountability structures.
Candidates associate governance with software platforms and forget the human and organizational dimensions-ownership, stewardship, data quality accountability, and decision rights.
What to do instead
Map each governance scenario to the people-and-policy layer first: who owns the data, who is accountable for quality, what policy governs use. Then consider tooling as an enabler, not the solution.
Describing explainability as 'the model explains itself' without distinguishing interpretable models from post-hoc explanation techniques and their limits.
Candidates conflate transparency, interpretability, and explainability, and assume any explanation method gives faithful insight into model behavior.
What to do instead
Separate the concepts: transparency = visibility into process/data; interpretability = inherent human-understandable model structure; explainability = post-hoc approximations (e.g., feature attribution) that may be unfaithful. Match the level of explanation to the audience and stakes.
Citing a regulation by name but misstating its scope, obligations, or jurisdictional reach (e.g., assuming a privacy law applies only to companies headquartered in that region).
Candidates memorize acronyms and headlines rather than the operative requirements, and miss extraterritorial scope and role distinctions (controller vs. processor).
What to do instead
For each major regime, memorize three anchors: who it covers, what core obligations it imposes, and what the individual rights are. Pay attention to role definitions and cross-border applicability in scenario stems.
Answering AI-ethics scenarios with generic principles ('be fair,' 'be transparent') instead of concrete, actionable mitigations tied to the lifecycle stage.
Candidates know the vocabulary of ethical principles but have not practiced translating them into design, data, deployment, and monitoring actions.
What to do instead
Practice converting each principle into a lifecycle action: at data collection (representativeness, consent), at modeling (bias testing, documentation), at deployment (human oversight, monitoring), and post-deployment (feedback, redress). Choose the answer that names a specific mechanism.
Ignoring the distinction between the data subject's stated consent and the broader question of whether the use is ethically justified, treating consent as a complete ethical shield.
Candidates treat consent as a universal justification and overlook power asymmetries, group harms, and cases where consent is not freely given or does not cover downstream uses.
What to do instead
When consent appears in a scenario, test its validity (informed, specific, freely given) and whether it addresses collective or secondary harms. Recognize that lawful consent does not automatically make a use ethically sound.
Overlooking accountability gaps-failing to identify who is responsible when a system causes harm-and defaulting to 'the algorithm is at fault' or 'the developer is at fault.'
Candidates focus on technical causes of harm and skip the governance question of responsibility allocation across developers, deployers, and operators.
What to do instead
For any harm scenario, explicitly trace responsibility across the chain: who designed, who deployed, who monitors, and who has authority to intervene. Prefer answers that assign clear, documented accountability and human oversight rather than diffuse blame.