Stanford CS221 Autumn 2025 Lecture 18: AI & Society — Annotated Lecture Notes & Key Takeaways

Course Information

Institution: Stanford

Original Course: Stanford CS221 | Autumn 2025 | Lecture 18: AI & Society

Instructor Bio: This lecture is delivered by Percy Liang, Associate Professor of Computer Science at Stanford University and core faculty of the Stanford Institute for Human-Centered Artificial Intelligence (HAI). Percy Liang leads the Stanford Natural Language Processing Group and the Center for Research on Foundation Models (CRFM). His research spans the theoretical foundations and practical systems of artificial intelligence, including machine learning, natural language processing, AI alignment, and rigorous model evaluation. He received his PhD in Computer Science from the University of California, Berkeley and his BA in Mathematics from Harvard University. His work has been recognized with the NSF CAREER Award, Google Faculty Research Award, and multiple best paper awards at top-tier AI conferences. He has taught CS 221 at Stanford for over a decade, shaping foundational AI education for thousands of students.

Course Description: This lecture addresses the societal impacts, ethical challenges, and governance considerations of artificial intelligence technology. It covers key topics including algorithmic bias, fairness, privacy concerns, misinformation risks, and labor market impacts of AI automation. The lecture also discusses responsible AI development practices, emerging regulatory frameworks, and the role of technologists in ensuring AI systems benefit society broadly and equitably.

Lecture 18 of Stanford's CS221 is the day the course stops doing math. Up to that point the syllabus has been machine learning, search, MDPs and games, Bayesian networks, and logic; the lecturer rattles that list off in the first twenty seconds almost as a way of drawing a line, then steps over it into AI & Society. What follows is roughly eighty minutes of frameworks and case studies, with a lot of pointing at slides that a transcript can't show you. These are my notes on what he actually argued, in the order he argued it, plus the places where I think the argument is doing more work than it lets on.
 

Why an AI & Society lecture belongs in a CS class

 

He knows the objection is coming and voices it himself: this is a computer science course, there are entire other courses about technology and society, so why spend a lecture here?
 

Two reasons. The first is scale. Technology reshapes how people live — he gestures at the printing press and the steam engine, then at the internet, mobile phones and social networks — and AI is, on his telling, the fastest-growing technology in history. The number he offers at (1:43) is 800 million weekly active users for ChatGPT, with the point being that we're still early. Part of that growth is a distribution story: the internet and social media were already there to carry it.
 

The second reason is aimed straight at the room. Engineers, he says, hold an unusual concentration of power, in three forms. They understand what these systems can and cannot do better than anyone outside the field. They pick which problems get worked on at all. And once they decide to build something, they make a string of choices nobody else is going to make for them: which languages a model supports, whether the weights get released, which requests the service honors and which it refuses. None of these are technical questions, and nobody downstream can answer them for you.
 

Then he goes after the "let someone else worry about the consequences" posture, and this is where the lecture briefly gets theatrical. He tells the story of the rocket engineer who worked for the Nazi regime and then for the American space program, and quotes the Tom Lehrer song built around him — the line about not caring where the rockets land because that isn't your department. It's a deliberately extreme example, which he admits. I wrote "extreme — maybe too extreme" in the margin, because the distance between "I chose a training corpus" and "I built delivery systems for two different regimes" is enormous and he never builds the bridge. The narrower version of the point does land: the person writing the code is making judgment calls that nobody is auditing.
 

From there he moves to principles and immediately deflates them. "Develop AI to benefit and not harm society" is, in his own framing, close to a platitude by now. He walks through two documents instead. The Belmont Report, which grew out of a study in which Black men with syphilis were left untreated so researchers could watch the disease progress — he notes that every principle the report ended up endorsing, informed consent among them, was violated by that study. And the ACM code of ethics, with its obligations to contribute to human well-being, avoid harm, respect privacy. Both are, as he says, pretty much unobjectionable. Which is exactly the problem: the hard part is turning them into something you can act on. The rest of the lecture is his answer to that.
 

The intent-and-impact map: benefits, misuse, and accidents

 

The first thing he wants to establish is that you don't get to choose how your system is used. If you personally do something harmful, that's your decision and someone can tell you not to. Building AI isn't like that, because AI is dual use — good for people or bad for people depending on who's holding it.
 

He runs through the historical parallels quickly, and I think this is the most useful thirty seconds in the lecture for getting oriented. Ammonia: fertilizer and chemical weapons. Rockets: missiles and space science. Nuclear: weapons and power. An agent that can break into a server is a penetration tester on your own infrastructure and an attacker on someone else's. Encryption protects everyone's privacy and conceals crime, and he notes that strong encryption was actually restricted for a period a few decades back — not a fact most people carry around.
 

His point is that naming something dual use isn't a license to shrug. There are things you can do to tilt the balance toward the good outcomes. It's hard, he says, but hard isn't impossible. That sentence is about as close to a thesis as the lecture gets.
 

The framework he uses to organize everything is a two-by-two: intent on one axis, impact on the other. Good intent with positive impact is the beneficial-applications quadrant — healthcare, education, science. Bad intent with negative impact is misuse: spam, fraud, disinformation. The interesting box is good intent with bad outcomes, which is what he means by accidents, and he says this is probably the most common case in practice. The fourth box, bad intent leading to good outcomes, stays empty; you'd have to be a supervillain to live there.
 

The beneficial list is long and he moves fast through it. Protein structure prediction and binding simulation cutting down wet-lab cycles in drug development. Clinical uses — answering questions against electronic health records, translating medical jargon for patients. Education, where his caveat is the useful part: a tutor that hands over the answer isn't tutoring, so the design target is pedagogy rather than task completion. Self-driving cars, which he calls genuinely good now, and household robotics, which he ties to aging populations. Weather and climate: forecasting, early warning, and checking whether policies are doing anything.
 

Misuse gets maybe two minutes. There's a recent Anthropic post, which he cites around (13:11), describing attackers using a coding agent to run a large-scale cyberattack; agents are now good enough for that to work. Generated text, images, audio and video at high fidelity can carry disinformation, whether the source is a state actor or a teenager going after a classmate. Each of these has the dual-use shadow attached — the same capabilities defend systems and find vulnerabilities.
 

Accidents get the most attention, and the list is worth writing down because it's the part you wouldn't guess from outside. Systems working worse for some groups than others — voice assistants and accented speech is his example. Sycophancy, where a model affirms a false belief the user already holds, which he singles out as most dangerous for users dealing with mental health problems. He's explicit about why this counts as an accident: nobody set out to build it, it's a side effect of tuning models to be pleasant. Overreliance, where the same drive to be helpful erodes people's willingness to think for themselves. Cultural homogenization. And job displacement, with entry-level software engineering named specifically — he says the work those roles do sits roughly at the level of current coding agents.
 

His summary of the three buckets is blunt. Do more of the first. You can't prevent misuse entirely, but you can build safeguards. Accidents are where there's the most room, because you can test before you ship.
 

Inequality and alignment: where things go quietly wrong

 

The rest of the lecture is four deep dives, and he's upfront that they're a representative sample rather than a survey.
 

Gender Shades and what an outside audit can do

 

The inequality section opens with a 2018 study at (20:51) that evaluated commercial gender classifiers from Microsoft, Face++ and IBM, then broke accuracy down by skin tone and by gender rather than reporting one figure. Averaged across everyone, the systems looked fine. Split by group, one intersectional group — darker-skinned women — was being served far worse.
 

Two things follow. The first is his real point: after the study came out, the companies fixed their systems. Third-party auditing works as an incentive, and the first step in fixing a problem is establishing that it exists, which sounds trivial until you notice how many teams never do it. The second is technical. You can collect more data for underrepresented groups, though that's expensive and is probably why the data was missing to begin with. You can upweight those groups during training. Or you can change the objective itself — he mentions distributionally robust optimization, which optimizes the worst group's accuracy rather than the average, so no subgroup gets left behind.
 

There's an aside here I wanted more of. He asks, in one sentence, whether gender classification is a well-defined task at all, given that it reads superficial features off an image rather than anything resembling self-identification. That's a much larger question than the framing implies, and he drops it immediately.
 

Two more kinds of inequality

 

The second example is geographic. Take a reward model fine-tuned from Llama — the kind that scores how good an assistant's reply is, and the kind used to post-train models with reinforcement learning, which he links back to the previous lecture — and score replies to prompts built from "I am from [country]." The US and Canada come out high, Saudi Arabia comes out low, and he says there's no good reason for it. If you then fine-tune against that reward model, you bake the bias straight in.
 

The third is the one I'd remember. The task is detecting a collapsed lung from a chest X-ray, and the system reports accuracy around 0.87, which sounds respectable. Looking closer, at (25:25) he describes researchers noticing the model had locked onto a chest drain — the tube that shows up in X-rays of patients who are already being treated for a collapsed lung. So it's excellent on patients who have been treated and much worse on patients who haven't, which means it fails exactly on the people who still need diagnosing. That's a spurious correlation: a pattern that holds in the training data, doesn't reflect the causal structure, and therefore collapses under a different condition. He ties it back to minority populations being hit hardest, and then to a rule — stop watching a single aggregate number.
 

Alignment, and the three ways a reward function lets you down

 

Set up as a reinforcement learning problem, alignment looks easy: write down a reward capturing what you want, train an agent to maximize it. He then spends fifteen minutes on why it isn't.
 

The first failure is reward hacking. The demo is an older OpenAI result from around (29:14), in a boat-racing game where points come from hitting targets; the trained agent never finishes the race, it just circles and rams the same targets forever. His gloss on why this is maddening is that you wanted the system to grasp your intent, while all it can do is follow the specification you actually wrote. The contemporary version is coding agents rewarded for passing unit tests. Tests never cover everything, so passing them doesn't mean correct, and correct doesn't mean secure, robust, or readable. His practical rule: a slightly wrong reward, optimized a little, probably still moves you in a roughly right direction — optimized hard, and the system starts finding devious ways to squeeze out more reward.
 

The second failure is pluralism, and it's the one with no fix. Whose values does the reward encode? His example is whether governments should moderate content on social media, on which reasonable people split hard. Picking one answer and fine-tuning it into a model served to everyone means projecting that answer onto the world. Ideally a model would represent a range of thought within some reasonable window while also being personalized to individual users — and he names the tension rather than resolving it: represent diversity or personalize, and if you personalize, how do you keep everyone out of an echo chamber, especially when models already trend sycophantic? He says outright there's no recipe.
 

The third is scalable oversight. Models now produce answers that experts struggle to check; his example is a project that had models answer unanswered Stack Exchange questions. The proposed responses: break problems into pieces small enough for a human to verify; use one AI to supervise another, through debate or constitutional approaches, which he notes has an obvious recursion problem; supervise the process rather than the outcome, having the model show its work so the steps can be checked; and formal verification where the problem can be stated as a theorem, which he's realistic about — most real problems can't.
 

Copyright, memorization, and what "open" really means

 

Copyright from first principles

 

The hook is a settlement: Anthropic agreeing to pay authors $1.5 billion to settle a copyright suit, mentioned around (36:08) as evidence that this isn't hypothetical. Then he backs up and teaches the basics, on the argument that you can't work out where models sit in this space without them.
 

Copyright exists to incentivize the creation of intellectual goods by protecting creators. It reaches back to eighteenth-century England and, in the US, to the Copyright Act of 1976, which covers original works of authorship fixed in a tangible medium. A few consequences matter. Collections as such aren't protected — a telephone directory is just a list, unless there's creativity in how it's selected or arranged. Protection covers expression, not ideas: quicksort is free, your particular implementation isn't. Since 1976 you don't need to register or publish, so the threshold is very low — your website is copyrighted, and so is the essay you turned in last week. But you do need to register before you can sue, which costs about $65, and protection ends eventually, after which the work falls into the public domain: Shakespeare, Beethoven, most of Project Gutenberg.
 

There are two ways to use protected work. Get a license, or claim fair use. Creative Commons licenses, created in 2001, are the interesting middle case — a creator saying in advance that anyone can use the work, which is how Wikipedia and Khan Academy operate. Companies also buy data directly; he lists Google paying Reddit and OpenAI paying Stack Exchange and Shutterstock. But most of the internet is none of those things — not licensed, not CC, not old enough to be public domain — and that's the bulk of training data, so fair use is carrying the weight.
 

The fair use test has four factors, and he walks them: purpose and character of the use, where educational and transformative uses fare better than commercial copying; the nature of the work, factual being more defensible than fictional; how much of it you took, a snippet versus the whole book; and the effect on the market, where competing with the original counts against you. Writing a movie summary is fine. Reimplementing an algorithm rather than copying its code is fine. Google Books indexing and showing snippets is fair use now, though it took a very long lawsuit to establish. And copyright isn't only about verbatim text — plots and characters are protected, which is why a story reusing Harry Potter's characters can infringe without copying a sentence, while parody gets more latitude. It's a semantics-and-economics question, not a string-matching one.
 

Applied to models, the picture is genuinely mixed. Copying data in order to train on it may itself be a violation unless fair use applies. The defense is that training is transformative — the model can do things the book can't — and that machine learning is after ideas rather than expression; a stop-sign classifier, he points out, doesn't care about your artistic choices, it wants the general concept. Against that, the market factor cuts the other way, and he's candid that writers and artists have real complaints. The sharpest thing he says is that those complaints wouldn't vanish if the models had never seen the work: a system that competes with artists is a problem for artists whether or not copyright is involved. Terms of service are a separate wall again — YouTube hosts plenty of Creative Commons material and still prohibits downloading it at scale.
 

When a model memorizes a book

 

Then he complicates his own argument. Yes, a model is different from its training data. But there's a measurable sense in which the data ends up inside the weights: take a book, compute the probability the model assigns to each token given the preceding ones, and high probability means the book has, in effect, been memorized. On Llama 3 70B, one Harry Potter book comes out heavily memorized.
 

Memorization on its own may be harmless, though. What matters is extraction — whether an ordinary user can get the text back out. Around (51:34) he describes prompting that model with the opening words of the first Harry Potter book and getting several hundred thousand tokens back, close to verbatim. That's a much stronger infringement story, because anyone who can download the weights can now hand the book to anyone. He then undercuts it slightly: this is the exception. Feed the same model a different well-known book and nothing comes out. So you can't claim models memorize everything, and you can't claim they memorize nothing; it depends on the model and on the work.
 

Transparency, and four flavors of open

 

The last movement is the one he says he personally cares about, and it starts with centralization: very few companies can afford to train frontier models, and very little is disclosed about how they're built.
 

Transparency comes first, as a precondition. Borrowing the logic that you can't improve what you can't measure, he argues you can't make systems safer if you don't know how they were made. His group's Foundation Model Transparency Index scores developers against a hundred indicators spanning upstream — data, labor, compute — the model itself, meaning capabilities, risks and mitigations, and downstream, meaning distribution, who can use it, and how feedback gets back to the builder. Scores come out uneven, with closed models doing especially badly on upstream items, which matters because you can't reason about labor conditions or copyright exposure without knowing what data and compute went in. The theory of change is simply that public scoring creates pressure: he reports scores rising between late 2023 and mid-2024, the same mechanism as the Gender Shades fix.
 

Openness is different from transparency, and he lays out a spectrum. Closed models, reachable only through an API or a product. Open-weight models — Llama, DeepSeek, Qwen — where you get the weights but not the data or the code. Open-source models, where you also get the code and the data recipe, though development still happens behind closed doors. And open development, where the community can see everything and contribute.
 

Two points here are worth keeping. The first is that "open model" in ordinary usage almost always means open weights, and open weights alone is not transparency: you can ship weights and say nothing about your data. He gives Mistral 7B a score in the mid-fifties out of a hundred as an example. The analogy he offers is good — releasing weights is closer to shipping a compiled binary than to open source. The second is why openness is worth wanting at all: it lets researchers fine-tune, quantize and otherwise experiment in ways an API never permits; it spreads power rather than concentrating it, with a Linux-versus-Windows counterfactual he poses about the 1990s; and it makes independent inspection possible. He's also honest about the limit — weights or no weights, training a foundation model from scratch still takes capital most people don't have.
 

On the risk side he makes two arguments I found the most genuinely persuasive part of the whole lecture. The first is marginal risk: the right question isn't whether an open model can be misused, it's how much worse things get than in the world where it wasn't released. In that world, closed models still exist, and so does the internet — including most of what you'd need to know about making bioweapons, some of it taught in advanced biology courses. The second is that harm usually requires a chain, not a model. An open-weight model might help someone design something dangerous, but then it has to be manufactured and deployed, and those are separate gates that can be reinforced independently. He even suggests that gating at the physical layer is sometimes easier than gating at the model layer.
 

He dates the paper behind this to 2023, the year after ChatGPT put AI in front of everyone, when policy discussion was loud and confused and the fate of Meta's open-weight releases was an open question. The framework, in his telling, is a way to make that argument legible.
 

Where the lecture left me unconvinced, and where it goes next

 

The individual pieces are strong and the connective tissue is thinner. My notes have three recurring complaints.
 

The dual-use framing is doing more work than it should. Everything on his list — ammonia, nuclear, encryption — has a regulator, a licensing regime, or a physical chokepoint attached. Putting AI next in that line is rhetorically clean and analytically blurry, and he never says what the equivalent chokepoint would be.
 

The reward-hacking and pluralism sections both end in the same place: be careful, don't over-optimize, there's no recipe. That's honest, and I'd rather have honesty than a fake answer, but after two sections built on the same move I wanted at least one worked example of a team making the tradeoff badly and what it cost them. This part of the lecture would benefit from an example.
 

And the dates are worth checking. He dates the syphilis study behind the Belmont Report to 1974, and gives copyright protection a flat 75-year term; both struck me as things to verify before repeating.
 

None of that undoes the main argument, which I thought held together well. He closes on three moves: aim at beneficial applications, build safeguards against misuse, and put the most effort into preventing accidents. The recurring instruction is to think about the ecosystem rather than the model — follow the chain upstream to the data, the labor and the energy, and downstream to how people actually use the thing. He pairs that with a metrics point: inequality pushes you to track several numbers, and reward hacking pushes you to distrust any single one, so what you want is a broad suite of measurements rather than one score. Openness and transparency he frames as foundational, with an analogy to political freedom — not sufficient on their own, but very little else improves without them. And auditing gets promoted from a technical activity to a social one. On the surface it's just evaluation: prompt a model, look at what comes back. He wants you to see it as raising awareness in a way that manufactures the will to fix things.
 

Eighty minutes is a short time to spend on AI & Society, and the lecture says as much — the deep dives are explicitly a sample. What it does well is hand you vocabulary: dual use, accidents, spurious correlation, reward hacking, pluralism, scalable oversight, marginal risk, the transparency index. If you're the person who ends up making those design calls nobody else will make, that vocabulary is the part that transfers.
 

Content Disclaimer:

This article is for general reference only and does not constitute professional R&D guidance, production process advice or quality certification. All material performance data has specific test premises; readers should verify parameters against actual equipment and working conditions.