Module 1: Why Ethics Matters in AI Engineering

8. Mini-project: Ethics Impact Analysis

You close the module by applying the framework to a real AI system. The deliverable is a complete 3-5 page Ethics Impact Analysis — the first tangible artifact of your ethical workflow.

This document is reusable: you'll refine and extend it throughout the guide as you learn specific techniques (bias testing in M2, privacy in M3, compliance in M4-6).

Deliverable spec

Minimum viable

✅ System defined: complete characterization (Phase 1).
✅ Stakeholders identified: a table with at least 4-5 stakeholders (Phase 2).
✅ Failure modes mapped: at least 6-8 concrete failure modes (Phase 3).
✅ Risks scored: a severity × probability matrix for each mode (Phase 4).
✅ Mitigations proposed: a specific technique + metric + ownership for each 🔴/🟡 risk (Phase 5).
✅ A structured document: 3-5 pages following the template.
✅ Decision log: dates and authors documented.

Stretch goals

⭐ Implement at least 1 mitigation in code (e.g., disparate impact testing as a CI test).
⭐ Stakeholder review: share the document with a PM/lead/legal and get feedback.
⭐ Compare against an existing system: apply the framework to a system already in production and identify the gaps.
⭐ A concrete post-deploy monitoring plan with dashboards and alerts.

Choosing the system to analyze

Three options:

Option A: your path Capstone

If you completed the AI-Powered Knowledge Assistant (#25, capstone), apply the Impact Analysis to that system.

Upside: you know the system in detail, and you can act on the findings (implement mitigations).

Downside: if you built it without thinking about ethics, you're going to find issues — which is exactly the point.

Option B: a system from your job

If you work at a company that deploys AI, pick a real system (with management's permission if that applies).

Upside: directly useful professionally.

Downside: confidentiality. Don't publish sensitive findings.

Option C: a provided case study

If you have no Capstone of your own and no system at work, use one of the following case studies:

C1: Healthcare Triage System

An AI system that takes patient symptoms via web chat and classifies urgency (immediate / 24h / week / non-urgent). Outputs: a classification + a recommended action. LLM-based with prompt engineering. Training data: 10,000 anonymized historical triage conversations. Deploy: a clinic with 50K visits/year in the US. Replaces traditional phone triage.

C2: Content Moderation System

An AI system that classifies user posts on a social platform (1M users) into categories: safe / borderline / unsafe. Outputs: a classification + confidence. LLM-based with few-shot prompting. Posts in multiple languages (English, Spanish, Portuguese, Hindi). Automatic decision: "unsafe" posts get hidden automatically, "borderline" ones go to human review. Deploy: global.

C3: Loan Approval System

An AI system that predicts the probability of default for applicants for personal loans ($1K-$50K). Output: a 0-1 score + an approve/deny/manual review decision. An ML model (gradient boosting) trained on 5 years of internal data. Features: income, credit score, employment, location, age. Deploy: a US fintech, scale 10K applications/month.

C4: Educational Recommendation System

An AI system that recommends courses to students on an online platform (500K users). Output: a ranked list of courses. A collaborative filtering + content-based hybrid. Data: course completions, ratings, time spent. Decision: shown automatically on the student's home page. Personalization via inferred demographics (age, location, declared interests). Deploy: globally.

How to proceed

Step 1: choose the system

Decide which of the options (A, B, or C). If C, choose which case study (C1-C4).

Step 2: apply the 5 phases

Work the 5 phases in order. Don't skip Phase 1 — if the characterization is vague, everything else becomes vague.

Phase 1: Characterization

Answer the 14 characterization questions (from capsule 07):

What does it do? (1 sentence)
What type of model?
Who provides it?
What's the formal output?
How is the output used?
Where does the training data come from?
What kinds of personal data?
Is there consent?
What's the demographic composition of the data?
What jurisdictions?
Who are the users?
What scale?
How reversible is the output?

Phase 2: Stakeholders

Identify at least 4-5 stakeholders. For each one: how they interact, which decisions affect them, possible outcomes, vulnerabilities.

Phase 3: Failure modes

Identify at least 6-8 failure modes. Cover these categories at minimum:

Bias / discrimination.
Privacy.
Accuracy / hallucination.
Misuse.
Transparency.
Accountability.

Phase 4: Severity × probability

For each failure mode, assign a severity (LOW/MEDIUM/HIGH/CRITICAL) and a probability (LOW/MEDIUM/HIGH/VERY HIGH). Justify it. Determine the zone (🟢/🟡/🔴).

Phase 5: Mitigations

For each risk in the 🔴 or 🟡 zone, propose:

A specific technique.
A metric.
An acceptance criterion.
An owner.
An estimated time.

Step 3: write the document

Use the template structure (from capsule 07):

# Ethics Impact Analysis: [System]

## 1. Executive summary
## 2. System characterization
## 3. Identified stakeholders
## 4. Failure modes
## 5. Risk assessment
## 6. Mitigation plan
## 7. Post-deploy monitoring plan
## 8. Decision log
## 9. Next review

3-5 pages. No fewer (you're cutting analysis), no more (you lose precision).

Step 4: review

Share it with at least one person (a mentor, a peer, a PM) and get feedback. Typical feedback runs in these directions:

"This stakeholder is missing": revisit Phase 2.
"The severity looks underestimated": revisit Phase 4 with more conservatism.
"The mitigation is too abstract": revisit Phase 5 with more technical detail.
"Jurisdiction X is missing": revisit Phase 1.

Iterate until the feedback is "the doc is complete, ready for formal stakeholder review."

A worked example: case C3 (Loan Approval System)

We show the first 3 phases so you have a model. The details go in your own deliverable.

Phase 1: Characterization

System: Loan Approval System — predicts the probability of default for personal loan applicants, outputs an approve/deny/manual review decision.

Type: Binary classifier + threshold. Gradient boosting (XGBoost). Trained from scratch.

Provider: the in-house ML team.

Output: a 0-1 probability score + a decision (approve if > 0.7, deny if < 0.3, manual review between 0.3-0.7).

Use: an automatic decision for approve/deny. Manual review only for the ambiguous zone.

Training data: 5 years of internal loan history. ~500K applications, ~100K loans issued. Labels: defaulted vs. paid.

PII in the data: name, address, SSN (hashed), employment, income, credit history. Sensitive data: yes (financial).

Consent: a clause in the application form, blanket consent for "credit decisions."

Demographic composition: historical applicants, US. Racial distribution: 65% white, 15% Hispanic, 12% Black, 8% Asian (per ZIP code inference). Gender distribution: 55% M, 45% F.

Jurisdictions: US (FCRA, ECOA, CRA). State-specific: NY, IL, and CA have extra requirements.

Users: individual applicants, loan officers (manual review zone).

Scale: 10K applications/month. ~$200M loan volume/year.

Reversibility: hard to reverse. Denied applicants rarely re-apply; approved ones have a contractual commitment.

Phase 2: Stakeholders

Stakeholder	How they interact	Decisions that affect them	Possible outcomes	Vulnerabilities
Applicants (all)	Submit an application	Approve/deny + interest rate	Access to credit, economic opportunity	Low-income, minorities, young/old
Loan officers	Review the manual zone	Time invested, automation bias	Efficiency (positive); blindness to edge cases (negative)	Automation bias
The company	Builds/operates it	Default rate, regulatory exposure	Profit; lawsuits	FCRA, ECOA enforcement
Historically under-served communities	Under-represented in approvals	Access to credit	Economic mobility vs. exclusion	Historic redlining
Regulators (CFPB, state)	Audit	Legal compliance	Fines, cease-and-desist	—
Society at large	Aggregate credit patterns	The distribution of credit	Equity vs. systemic exclusion	—

Phase 3: Failure modes

Failure mode	Mechanism	Stakeholders	Harm outcome
Racial bias via ZIP proxy	ZIP code correlates with race because of segregation; the model learns the correlation	Minority applicants	Unfair denial of credit
Indirect gender bias	Income and employment patterns correlate with gender	Female applicants	Denial or a higher rate
Age bias	Length of credit history penalizes the young + the old	Young (< 25) and old (> 65)	Denial
Disparate interest rates	Risk-based pricing escalates on proxies	Low-income, minorities	Predatory rates
Hallucination in feature engineering	(Less applicable to gradient boosting, but data quality issues apply)	Applicants	Decisions based on corrupt data
Privacy leak in logging	SSN, income in logs	Applicants	PII exposure
No appeal mechanism	Denied applicants don't know why	Applicants	No possibility of feedback/improvement
Post-deploy data drift	The model becomes outdated	All stakeholders	Silent performance deterioration

(Phases 4 and 5 continue in your own deliverable)

Step-by-step exercise

Step 1: block the time (4-8 hours)

Set aside 4-8 hours to do the analysis seriously. If you do it in 30 minutes, the doc will be superficial.

Step 2: Phase 1 (1 hour)

Answer the 14 questions. If you can't answer them, stop and get the information (talk to the PM, read the code, ask the data science team) before moving on.

Step 3: Phase 2 (1 hour)

Brainstorm stakeholders. Start with the obvious ones (users, subjects), expand to the indirect ones (families, communities), finish with the systemic ones (regulators, society).

Step 4: Phase 3 (2 hours)

The most laborious step. For each category (bias, privacy, accuracy, misuse, transparency, accountability), generate at least 1-2 concrete failure modes. Use the case studies (Amazon, facial recognition, Apple Card) as inspiration.

Step 5: Phase 4 (1 hour)

Assign severity + probability + zone. Be conservative (raise it when in doubt).

Step 6: Phase 5 (1-2 hours)

For each 🔴/🟡 risk, propose a concrete technical mitigation. If you don't know which one, search "mitigate [risk] in [system type]" — the literature is extensive.

Step 7: write it up (1 hour)

Compile the 5 phases into the template. The executive summary goes last (it's what stakeholders read first, so write it last, once you understand everything).

Step 8: review (variable)

Share it. Iterate. Refine.

Expected output

A 3-5 page document

With a clear structure:

[ Executive summary  — 1/3 page ]
[ Characterization   — 1/2 page ]
[ Stakeholders       — 1/2 page ]
[ Failure modes      — 1 page   ]
[ Risk assessment    — 1 page   ]
[ Mitigations        — 1 page   ]
[ Monitoring + log   — 1/2 page ]

Total: ~4 pages

Demonstrating competence

After this mini-project, you should be able to answer with confidence:

✅ "Who are the system's stakeholders?" ✅ "What are the priority ethical risks?" ✅ "Why is [risk X] high severity and medium probability?" ✅ "What mitigation do you propose for [risk X]?" ✅ "How will you verify the mitigation works after implementation?"

If you can, you passed the module.

Common traps during the exercise

1. Starting with mitigations, not with the analysis

The temptation: you already know "bias testing is a mitigation," so you jump straight there. Result: a superficial analysis.

Better: Phases 1-4 first, mitigations at the end. If you don't understand the risk concretely, the mitigation is going to be generic.

2. Using "could" as a hedge

"Bias could exist" isn't analysis. Identify the concrete mechanism: "Bias will exist via the ZIP code proxy because...".

If you can't identify a mechanism, the risk is under-investigated, not low.

3. Ignoring the regulatory dimension

If the system has exposure to EU users, the EU AI Act applies. Document it. If it has applicants in hiring, EEOC + state laws apply.

4. Defending the system

The temptation: justifying the current design decisions. "It's like this because it's already built like this."

Resist. The framework exists to identify issues, not to defend the status quo. If the analysis reveals the system has problems, that's the desired output.

5. Pretending your own system is the exception

"Other systems have bias, but mine doesn't." False by default. Assume there's bias until you prove otherwise with testing.

Closing the module

8 capsules

Introduction.
Case study #1: Amazon Hiring.
Case study #2: Facial Recognition Bias.
Case study #3: Apple Card Credit Scoring.
The 4 dimensions of cost.
The engineer's responsibility.
Ethics Impact Analysis: the framework.
Mini-project: your own Impact Analysis (this capsule).

What changed in you

Before the module:

You thought "AI ethics = abstract philosophy."
"If we pass compliance, we're fine."
"It's the PM's/legal's responsibility."

After the module:

You know AI ethics = quantifiable risk management, with specific dollar figures.
You know compliance is the floor, not the ceiling.
You know the engineer's technical responsibility is direct, based on regulation + asymmetric information + technical causality.
You have a concrete tool (Impact Analysis) that you applied to a real system.

The document you produced

It isn't an academic exercise. It's a reusable artifact that:

Gets updated when the system changes.
Gets referenced in future design reviews.
Gets included in compliance documentation.
Gets shared with regulators if an audit shows up.

You take a professional document with you into M2.

We start in the next module

Module 2: Bias and Fairness. We take one of the risks identified in your Impact Analysis — bias — and go deep with concrete techniques:

How to measure bias mathematically (fairness metrics).
How to test for bias in CI/CD.
How to mitigate detected bias (re-weighting, adversarial debiasing, post-processing).
How to choose a definition of "fair" for your context (an unavoidable decision, because the definitions are incompatible).

The transition is natural: you identified the risk in M1; M2 gives you the tools to measure it, test it, and mitigate it.

Resources for the exercise

Microsoft Responsible AI Impact Assessment Template — a commercial template.
Algorithmic Impact Assessment (Canada) — a government framework with a questionnaire.
AI Now Institute — Algorithmic Accountability — research and reports.
Partnership on AI — Resources — frameworks and case studies.
NIST AI RMF Playbook — step-by-step guidelines.

Capsule 08 of 08 — Module 1 — AI Ethics & Compliance Guide

End of module 1. Continue with module 2 (Bias and Fairness Deep Dive).

← Previous7. Ethics Impact Analysis: the framework Next →1. Module introduction: Bias and Fairness