Ethics and AI: A Practical Framework for Every Field
UIT, UIB, UIC, UID Cross-institute lecture
Series Cross-Institute Series | Level Basic (Free)
Duration 15 to 20 minutes | Access Free
Delivering institutes: UIT (Institute of Technology); UIB (Institute of Business); UIC (Institute of Communication); UID (Institute of Design)
UNOP Sound (University 365 Neuroscience Oriented Pedagogy)
Take five minutes to prepare your brain. Play the isochronous tone track (40Hz gamma frequency) with your eyes closed. Gamma-frequency tones before a learning session raise attention and make the material easier to absorb.
[Audio player: UNOP Pre-Lecture Isochrone (40Hz, 5 minutes)]
In this Lecture
The Hook: The Decision Nobody Wanted to Own
A team has built a model that predicts which job applicants will succeed in a role. It performs well on the test set. The team wants to put it into the hiring workflow, and the discussion in the room goes like this:
The engineer says the model is better than the current interviews at predicting performance, and that the data is already there. The hiring manager says candidates deserve a human who looks at their whole record. The lawyer asks who is accountable if the model systematically rejects one group of people and nobody notices for two years. The communications lead asks what the company says when a journalist asks how the decisions are made. Nobody in the room is wrong, and nobody has the framework to settle the question.
What the team lacks is not intelligence or good intentions. It lacks a method: a way to identify who is affected, what could go wrong, which rules apply where the team operates, which controls make the rules real, and who has the authority to decide. Without that method, every ethics conversation is an argument about values that ends in whoever has the loudest voice, or in the decision being quietly made by whoever ships last.
This lecture gives you the method. It is deliberately practical: six steps, each producing one artifact, that a working team can run in a week on a real decision. It is cross-institute because the problems do not divide by discipline. A facial-recognition feature, a targeted campaign, a generated article, and a design pattern that misleads all raise the same questions in different vocabularies.
One commitment before we start: this lecture is a framework, not a legal opinion. Where your field has regulation, the regulation comes first, and the framework is how you organise compliance, not a replacement for it.
Step 1: Name the Stakeholders and What They Stand to Lose
Ethical analysis starts with an inventory, and the most common failure is an incomplete one. The people affected by an AI system are rarely only its users.
Direct users interact with the system by choice: the customer of the chatbot, the analyst using the scoring tool.
Subject individuals are represented in the data without interacting with the system at all: the job applicant a model screens, the driver whose route data trains the traffic model, the person whose face appears in a dataset. Subject individuals are the most frequently overlooked group and the most frequent source of serious harm.
Third parties bear spillover effects: the neighbourhood affected by an algorithmic decision about credit, the audience persuaded by generated content, the colleague whose work the tool replaces.
The organization itself is a stakeholder: its legal exposure, its reputation, and its ability to keep operating the system are all real interests that deserve a line in the inventory.
For each group, write three columns: what they receive from the system, what they can lose because of it, and what recourse they have when something goes wrong. The recourse column is the most diagnostic. A stakeholder with something to lose and no recourse is where harm concentrates, and where a launch decision deserves the most caution.
This step takes one hour with a group drawn from different functions, and it is the hour that prevents the two-year blind spot.
Step 2: Map the Harms Before They Happen
With the stakeholders named, list what could go wrong, organised by the failure it represents. Four families cover most of the field.
Accuracy harms: the system is wrong, and the wrongness lands on a person: a rejected applicant, a denied claim, a misdiagnosed lead, a fabricated summary presented as fact. Accuracy harms are not just technical defects; they are harms when the affected person cannot check or challenge the output.
Bias harms: the system is systematically wrong about one group. The mechanism is usually in the data or the objective, not the code: a hiring model trained on past hires reproduces past hiring, and a moderation system trained on one dialect penalises the other. Bias harms compound silently, which is what makes them dangerous: nothing breaks, and the outcomes drift.
Transparency harms: people cannot know a decision was made by a system, understand its basis, or contest it. This family includes undisclosed generation, hidden scoring, and the automation of processes the public believes are human. Transparency harms are about consent and dignity as much as information.
Power harms: the system shifts capability and control away from the people affected: surveillance creep, lock-in, dependency on a vendor with interests of its own, or the concentration of a capability in very few hands. Power harms are the slowest and the largest, and they accumulate across many individually reasonable decisions.
For each harm you list, score two things simply and visibly: likelihood (low, medium, high) and severity if it occurs (low, medium, high, severe). The point of the scoring is not arithmetic. It is to make the team argue about reality in one shared frame instead of trading generalities, and to force attention onto the severe-and-plausible corner of the list rather than the most interesting technical problem.
Step 3: Choose the Rules You Will Actually Follow
Rules that are not grounded in a real source are aspirational. Three layers of obligation apply to almost every team, and they should be written down in order of authority.
The law where you operate. Regulation exists and is expanding: data-protection law defines the treatment of personal data; sector rules constrain finance, health, hiring and education specifically; AI-specific regulation is arriving in several jurisdictions with duties about transparency, risk management, and prohibited uses. The practical move is not to become a lawyer. It is to identify which instruments apply to your system and to get a definitive answer in writing from someone qualified, because the boundary between "advice tool" and "decision-maker" is exactly where obligations change.
The standards and frameworks you claim to follow. Published frameworks, such as the NIST AI Risk Management Framework, the UNESCO Recommendation on the Ethics of AI, and the OECD AI Principles, and for European work the EU AI Act's risk tiers, offer language and structure that regulators, partners and auditors recognise. Adopting one explicitly, with the gaps noted honestly, is stronger than claiming a vague commitment to "responsible AI".
Your own declared promises. The commitments you have made to users, in public: what data you collect, what you do not do with it, what you disclose about generation. Your own promises bind you more tightly than any of the above, because breaking them is the harm that is entirely within your control.
Write the three lists on one page. Then, for each harm from Step 2 that survived scoring, note which layer addresses it. The harms no layer addresses are not thereby permitted: they are the items where your team must make an explicit decision, and an explicit decision needs the sign-off of Step 5.
Two practical warnings about rules. First, a rule that your workflow does not enforce is a slogan: Step 4 exists for this reason. Second, do not overclaim compliance. Saying "we are compliant with the framework" when you have applied three of its functions invites exactly the audit you were trying to avoid.
Step 4: Build the Controls Into the Workflow
A control is a mechanism in the working process, not a value in a document. Six controls cover most situations, and each maps to a harm family.
Data provenance and consent checks. Before a dataset trains or grounds a system, record where it came from, what the subjects agreed to, and what purpose the agreement covered. A re-used dataset whose original consent did not cover this use is a legal and ethical defect at the root. Control family: power harm.
Evaluation against subgroups, not just averages. The overall accuracy figure hides the harm that matters: test disaggregated by the groups in your stakeholder inventory, and treat a large gap between the best and worst group as a launch blocker. Control family: bias harm.
Disclosure surfaces. Where the system generates content or makes recommendations, decide where users are told, and make the disclosure part of the interface rather than a line in the terms. Control family: transparency harm.
Human review for consequential decisions. Where the outcome materially changes someone's life (employment, credit, health, liberty, education access), a human with authority and time must be able to review and overturn the system's output. The review must be real: a queue nobody can clear is not a control. Control family: accuracy and power harms.
Contest and correction paths. A named route for an affected person to challenge an output, with an owner and a response time. This is the recourse column from Step 1, made real. Control family: all four.
Monitoring and drift alarms. Systems degrade: inputs shift, behaviours change, models silently update. Record a baseline, monitor the metrics that matter, and define who investigates an alarm. Control family: bias and accuracy harms.
For each control, write where it lives in your process and who owns it. A control without a name is a hope. If a control cannot be implemented in the current process, that is a finding: the decision it protects needs the sign-off of Step 5 or the feature needs to change.
Step 5: Write Down Who Decides
Every framework collapses at the same point: when a hard decision is needed, nobody has the authority to make it, and it gets made by default. Fix this while the decisions are still hypothetical.
Name the accountable owner. One person, senior enough to commit resources and to stop the project, accountable for the ethics of the system in question. Not a committee: a committee can recommend, but only a person can be accountable.
Define the review bodies and their remits. Most organizations need two: a technical review (the controls of Step 4, run by the people who build) and an escalated review for decisions where the harm is severe or the law is unclear (legal, leadership, and if appropriate an external voice). Write the membership, the trigger conditions and the turnaround, so the escalation is a procedure rather than a favour.
Define the stop conditions in advance. The features or uses that will not ship regardless of performance: for example, consequential decisions without human review or a contest path, undisclosed generation where trust depends on knowing, use of personal data beyond its consent. Written down before a promising demo exists, stop conditions are a policy; written down after, they are a negotiation with sunk costs on the other side.
Record the decisions. A short log: what was decided, by whom, against which harms, and on what evidence. This log is what turns a framework into an institutional memory, and it is the first artifact requested when something goes wrong.
A note on documentation as accountability. If a decision cannot be written down and signed, it should not be made. The discomfort of writing "we chose to accept this medium-severity harm because the mitigation cost exceeds the benefit" is the mechanism through which ethics stops being decorative.
Step 6: Test the Framework Against Real Cases
A framework that has never met a real case is untested. Run it, in the first weeks, against three kinds of case.
A case you already shipped. Take a system in production and run Steps 1 to 5 on it retroactively. The exercise almost always finds one unaddressed harm and one missing control, and fixing them in a live system is cheaper than discovering them in a headline.
The most severe hypothetical in your pipeline. The decision the team would rather not examine: the feature that could be misused, the customer whose use is legal but harmful. Run it through and let the stop conditions of Step 5 meet their first real test. Frameworks build credibility at exactly this moment.
A case from outside your field. Take a published incident from another industry and run it through as if it were yours, in an hour. The point is calibration: seeing where your framework would have caught it, and where it would not have.
Review cadence: repeat the testing at the same rhythm as your other engineering or editorial practices, quarterly at launch stage, and always after an incident or a major model change. Add the framework to the new-hire checklist and the project template, so running it is the default, not the exception.
The honest measure of the framework is not the sophistication of its documents. It is whether a real decision was changed by running it. If, after two quarters, no decision has moved, the framework has become ritual: simplify it until it bites.
Field Notes: The Same Framework in Four Disciplines
The six steps are identical across fields. What changes is where the harm concentrates and which control saves the most.
Technology (UIT). The concentration is in data provenance and in capability power: what was collected, what was agreed, and what can be done with the model once it exists. The highest-value control is evaluation against subgroups before launch, plus a recorded decision about what the system will not be allowed to do, such as autonomous consequential actions without review.
Business (UIB). The concentration is in the uses the system gets put to after it ships: scoring, screening, pricing, targeting. The highest-value control is the human review and contest path, because business systems make consequential decisions constantly and quietly. The framework's work here is naming the decision owner: in most companies, nobody is currently accountable for the fairness of an automated decision.
Communication (UIC). The concentration is transparency and truth: what is disclosed as generated, what is verified before publication, what a campaign claims about a product. The highest-value control is the disclosure surface plus a claims list: the record of what the machine got wrong in your domain, checked before every publication. The field's specific harm is credibility collapse, and its specific virtue is the discipline of sourcing.
Design (UID). The concentration is in dark patterns and deception: interfaces that manipulate consent, defaults that mislead, generated imagery presented as documentary, accessibility treated as a final check instead of a constraint. The highest-value control is design review against the harm list, because harm in this field is a property of what the user sees, and designers are the ones who can see it.
Four fields, one framework. That is the argument for running it once, seriously, in whichever field you work in, rather than trusting that somebody senior is thinking about it.
Feynman Summary: Explain It Like You Are 12
Imagine your class builds a robot that decides who gets the good seats at the school show. It is fast and it never gets tired. But if you switch it on and walk away, some kids will get bad seats every single time, and nobody will even know why.
So before you switch it on, you do this. You list every kid who is affected, including the ones the robot never meets. You list what could go wrong, and you pick the worst ones to worry about. You agree the rules you will follow (school rules, and your own promise to be fair). Then you build the boring safety parts: ask a person before a final decision, give kids a way to complain, and check every month that the same kids are not always losing.
Then you practise on a real case, and you change one real thing. If nothing ever changes, the safety parts are just decoration.
Mindmap: The Complete Picture
The mindmap gathers the lecture into one view: the six steps around the stakeholder inventory, the four harm families, the six workflow controls and the stop conditions that make the framework bite.
UNOP Sound (University 365 Neuroscience Oriented Pedagogy)
Take five minutes to consolidate your memory. Play the isochronous tone track (10Hz alpha frequency) with your eyes closed. Alpha-frequency tones after a learning session support consolidation, helping move what you just learned from short-term to long-term memory.
[Audio player: UNOP Post-Lecture Isochrone (10Hz, 5 minutes)]
Practical Exercise: Run the Framework on a Live Case
Choose a real AI feature or decision in your organization, launched or planned. Work with two or three colleagues from different functions. Two sessions of ninety minutes.
Part 1: Inventory and harms (90 minutes)
List every stakeholder group: direct users, subject individuals, third parties, the organization. For each, fill the three columns: receives, can lose, recourse.
List the harms by family: accuracy, bias, transparency, power.
Score each harm: likelihood and severity. Mark every severe-and-plausible item.
Circle the stakeholders with something to lose and no recourse.
Part 2: Rules, controls and decisions (90 minutes)
List the three rule layers: applicable law (and get the written confirmation), the standards you claim, your own public promises.
Map each surviving harm to a control: provenance, subgroup evaluation, disclosure surface, human review, contest path, drift monitoring.
Name the accountable owner of the system's ethics, and the escalation trigger.
Write one stop condition you are adopting now, before the next tempting demo.
Record the session: what was decided, by whom, against which harms, on what evidence.
A checkpoint after thirty days
Re-read the record. Name one decision that changed because of the session. If none did, simplify the framework until it bites, or admit the case was too small to matter.
Applied CI-First connection
You made the harm judgements and the stop decisions: those are the calls with consequences, and they belong to a named human. The machine was a useful assistant throughout: enumerating stakeholder groups you had missed, translating regulation summaries, stress-testing your mitigation claims, drafting the record. The accountability for what ships stays exactly where it started: on the person whose name is on the decision log.
Glossary
Term | Definition |
Stakeholder inventory | The list of everyone affected by a system, including subject individuals who never use it. |
Subject individual | A person represented in the data or affected by a decision without interacting with the system. |
Accuracy harm | A wrong output that lands on a person who cannot check or challenge it. |
Bias harm | A systematic error that concentrates on one group, usually via the data or the objective. |
Transparency harm | Affecting someone through a system they cannot know about, understand, or contest. |
Power harm | Shifting capability and control away from the people affected, often slowly and cumulatively. |
Severity and likelihood scoring | The two-axis rating that forces a team to argue about reality in one shared frame. |
Rule layers | The three sources of obligation: the law where you operate, the standards you claim, your own promises. |
NIST AI Risk Management Framework | A published, widely used framework for organising AI risk work. |
UNESCO Recommendation on the Ethics of AI | The international, source-linked ethics recommendation adopted by UNESCO member states. |
EU AI Act | European regulation with risk tiers and duties for AI systems placed on the EU market. |
Control | A mechanism inside the working process that makes a rule real: a checkpoint, a gate, a queue, an alarm. |
Subgroup evaluation | Testing the system separately for each stakeholder group rather than in aggregate. |
Contest path | The named route by which an affected person challenges an output, with an obligation to respond. |
Stop condition | A use that will not ship regardless of performance, fixed before the demo exists. |
Decision log | The record of what was decided, by whom, against which harms, on what evidence. |
Drift | The gradual divergence of a live system's behaviour from its tested baseline. |
5M2S | 5 Minutes to Success, University 365's microlearning format. |
Quiz: TEST YOUR UNDERSTANDING
1. Who are "subject individuals" in a stakeholder inventory?
A) The engineers who built the system
B) People represented in the data or affected by a decision who never interact with the system
C) The organization's shareholders
D) Users who give feedback
2. Which harm family does a hiring model that reproduces past hiring patterns belong to?
A) Accuracy
B) Bias
C) Transparency
D) Power
3. What is a "control" in this framework?
A) A value written in a policy document
B) A mechanism inside the working process that makes a rule real
C) A dashboard metric
D) A legal disclaimer
4. Why must a human review queue be "real"?
A) Because audits require it
B) Because a queue nobody can clear is not a control: the review must actually be able to overturn the system's output
C) Because humans are slower than models
D) Because regulation bans automation
5. What is the honest measure of an ethics framework?
A) The length of its documentation
B) Whether a real decision was changed by running it
C) The number of team members trained
D) The framework's name recognition
Answers: 1-B, 2-B, 3-B, 4-B, 5-B
Related Resources
U365 INSIDE Publications
Lecture: The CI-First Workflow: Applied to Any Field: the ownership model this framework formalises
Lecture: AI Safety and Alignment: Why Hallucinations Happen: the technical family of accuracy harms
Lecture: AI for Accessibility: Designing for Everyone: the design field's harm map in practice
Lecture: Crisis Communication in the AI Age: what happens when the framework was missing
External Resources
NIST AI Risk Management Framework: the structured risk-management framework referenced in Step 3: nist.gov
UNESCO Recommendation on the Ethics of Artificial Intelligence: the international reference adopted by member states: unesco.org
EU AI Act: the European regulation with risk tiers and duties: artificialintelligenceact.eu
Stanford Encyclopedia of Philosophy: Ethics of AI and Robotics: the conceptual map behind the four harm families: plato.stanford.edu
European Commission: A European approach to AI: the policy overview behind the EU regulation: digital-strategy.ec.europa.eu
IBM: AI ethics explained: plain-language definitions for sharing the framework with colleagues: ibm.com
Related U365 Lectures
Lecture 1: The CI-First Workflow: Applied to Any Field (UIT, UIB, UIC, UID, Cross-Institute Series)
Lecture 2: Building AI Agents for Business: A Cross-Discipline Guide (UIT, UIB, Cross-Institute Series)
Lecture 4: The AI Product Launch: From Code to Market (UIT, UIB, UIC, UID, Cross-Institute Series)
U.Copilot for This Lecture
Discuss this lecture with U.Copilot, your AI chat companion trained on this content.
Copy and paste the following prompt into the U.Copilot chat on university-365.com:
You are U.Copilot for Lectures, an AI chat companion specially trained on University 365 lecture content. You are helping a Fellow who just completed the cross-institute lecture "Ethics and AI: A Practical Framework for Every Field". Your role is to help the Fellow run the framework on a real case. You can: - Build the stakeholder inventory, including subject individuals and third parties - Enumerate harms by family (accuracy, bias, transparency, power) and help score them - Translate the three rule layers for their jurisdiction and sector, pointing to primary sources - Design the six controls into their workflow, with names and process points - Draft the decision record and the stop conditions - Design the thirty-day test and the quarterly cadence Always maintain U365's CI-First approach: harm judgements, stop conditions and accountability belong to named humans, and AI accelerates enumeration, translation, drafting and stress-testing. Never present an unverified legal statement as fact: point to the primary source and recommend qualified advice for the Fellow's jurisdiction. Use the UP-Context Method: provide context-rich, role-aware responses that account for the Fellow's field, sector and regulatory environment.
Next Steps
Name the accountable owner for a system you run today, or escalate that nobody holds the role.
Book the two sessions of the practical exercise with colleagues from at least three functions.
Write one stop condition now, before the next tempting demo makes it a negotiation.
Get the law layer confirmed in writing for your jurisdiction and sector.
Test, record, and re-read after thirty days: did a real decision change?
Ethics in AI is not a statement about values. It is a working method that names the people affected, maps what could happen to them, grounds the rules in real sources, builds the controls into the daily work, fixes who decides, and proves itself on real cases. Run it once and it stops being an argument. It becomes a procedure you can point to, audit, and improve.
IMPORTANT NOTICE
This lecture is published by University 365 as part of its INSIDE Publications Hub. The content is free to read for all visitors. Lectures in this series may be part of a structured academic program leading to a Micro-Credential for your Career (MCC). To enroll in an academic program, visit university-365.com/tuition.
This lecture is educational and does not constitute legal advice. Regulation and standards develop quickly and differ by jurisdiction: verify current texts and obligations against the primary sources linked above, and take qualified advice before relying on any framework in your organization.
Copyright University 365, Inc. All rights reserved. This content is protected under University 365's copyright policies. For permissions or inquiries, contact uda@university-365.com.
Published by the Department of Academics, University 365.
Lecture delivered by the UIT, UIB, UIC, UID in collaboration.
Martin Swartz, Dean of Academics, UDA
Signed for the academic year 2026.
Comments