Chapter 4 · Safety, Society and Governance
Stakeholder Impact and Open vs Closed Models: Arguments from Several Sides
- Page 15 of 22
- 18 min read
The previous page, Safety Controls and Synthetic Media: Layered Defences, Provenance and Response, asked how to stop a feature from being misused. This page widens the view from one feature to the people around it. Benefits and costs rarely land on the same people. A model choice, such as an open model you run yourself or a closed service you rent, moves some costs from one group to another. Creators, data workers and speakers of smaller languages sit in the supply chain even though they never use the product.
You need Python 3.12 and its standard library only: no packages, no network, no model calls. The one code block is short, and the text under it is its real output. Most of the page is tables and worksheets.
Honesty convention. Every company, person and number is invented unless a block is labelled Documented case or Legal note, and those come only from the course's checked sources. Open versus closed models, and copyright and training data, are contested. The tables give the strongest arguments on several sides, and the page does not choose a side. Nothing here is legal advice.
What you will learn
- How to map benefits and costs across stakeholder groups, and flag who gains, who pays and who has a say.
- How to compare open and closed models without a verdict: access, transparency, misuse, control, support and dependency.
- How to treat copyright and training-data disputes carefully, and keep legal permission apart from ethical attribution.
- How to record the interests of creators and dataset contributors, and ask about data workers and their working conditions.
- How to spot language and regional exclusion.
Map benefits and costs across stakeholder groups
Page 1 listed users, affected non-users and other stakeholders. Here we ask a sharper question of each group: do they gain, do they pay, and do they have a say in the decision? "Pay" means any cost: money, time, risk, lost opportunity, loss of control over data. The three flags are a chosen way to look, not a measurement. Two people can fill them in differently, and the disagreement is useful.
Toy data: a stakeholder-by-effect table for the hypothetical screening feature from the earlier pages.
ROWS = [ # Toy data: (group, effect, gains, pays, has_say) for the hypothetical ShortlistHelper rollout
("Recruiters", "less time spent reading CVs", True, False, True),
("Hiring managers", "shortlists arrive sooner", True, False, True),
("Agency owner", "lower cost per placement; licence fee; legal exposure", True, True, True),
("Vendor", "licence income; holds CV text", True, False, True),
("Applicants, standard CVs", "faster replies", True, False, False),
("Applicants, unusual CVs", "lower rank; may never be read", False, True, False),
("Current employees", "their CV data could be reused", False, True, False),
("Local job market", "shortlists may narrow over years", False, True, False),
]
print(f"{'group':<26}{'gains':<7}{'pays':<6}{'say':<5}effect")
for group, effect, gains, pays, say in ROWS:
mark = lambda flag: "yes" if flag else "-"
print(f"{group:<26}{mark(gains):<7}{mark(pays):<6}{mark(say):<5}{effect}")
pay_no_say = [g for g, _, gains, pays, say in ROWS if pays and not say]
mixed = [g for g, _, gains, pays, say in ROWS if gains and pays]
gain_free = [g for g, _, gains, pays, say in ROWS if gains and not pays]
print()
print("pay without a say :", pay_no_say)
print("gain and pay :", mixed)
print("gain, pay nothing :", len(gain_free), "of", len(ROWS), "groups")group gains pays say effect
Recruiters yes - yes less time spent reading CVs
Hiring managers yes - yes shortlists arrive sooner
Agency owner yes yes yes lower cost per placement; licence fee; legal exposure
Vendor yes - yes licence income; holds CV text
Applicants, standard CVs yes - - faster replies
Applicants, unusual CVs - yes - lower rank; may never be read
Current employees - yes - their CV data could be reused
Local job market - yes - shortlists may narrow over years
pay without a say : ['Applicants, unusual CVs', 'Current employees', 'Local job market']
gain and pay : ['Agency owner']
gain, pay nothing : 4 of 8 groupsThe result illustrates the calculation only; the rows are invented. Read the pattern, not the count. In this table every group that decides also gains, and every group that pays without a say is an affected non-user. That is not proof of unfairness. It is a prompt to ask whether the costs are acceptable, whether those groups can be heard (an appeal route, a consultation), and whether a control can move a cost back to the people who benefit. Note also that "Applicants, standard CVs" gain only if the feature really does answer faster; that is an assumption to test, not a fact.
Open and closed models: what the words mean
An open model, in this course, is one whose trained parameters (its "weights") can be downloaded and run by the user, under a licence. A closed model is reached only through a provider's service, so the provider keeps the weights. "Open" is a spectrum, not a switch: weights, training code, training data and licence terms can each be shared or withheld, and licences may restrict some uses. Always say which part is open.
Invented scenario:
Organisation: Greenfield Clinics, a network of eight small clinics (invented), based in Accra.
Feature: appointment reminders and simple questions, in English and three local languages.
Options: A rent a closed model through a provider's service
B download an open model and run it on a rented server
C no AI: staff send a fixed message list and answer the phone
Question: which option, under what conditions, and who is accountable?Note option C. The decision pattern always includes "do not use AI". A decision between A and B hides a first question: is a model needed at all?
Comparing open and closed models
Compare open and closed model trade-offs. The table gives the strongest argument on each side. The voices are invented and placed in different regions only to show that people with different positions and constraints see the issue differently. Nobody on the page speaks for a country.
| Topic | Arguments for open models | Arguments for closed models |
|---|---|---|
| Access and cost | Anyone with hardware can use, adapt and study it, with no per-request fee. A university lab in Nairobi can adapt it to a local language without asking permission (invented voice). | No hardware to buy or run. A small team in Bogotá can start in a day and pay only for what it uses (invented voice). |
| Transparency | Outsiders can inspect weights, test behaviour and repeat research. Independent audits become possible. | The provider can run its own large-scale tests and publish documentation. Some argue that fewer parties holding the weights makes accountability easier to assign. |
| Misuse | Defenders can study problems in the open, and many eyes find faults. Withholding does not stop determined actors who build their own models. | The provider can monitor use, block abuse, update safeguards and withdraw access. Once weights are released, safeguards can be removed and release cannot be undone. |
| Control and independence | You choose the version, when to update and where data goes. No provider can change terms on you. | The provider carries operational burden: security patches, scaling, uptime and safety updates. |
| Support and accountability | Community and commercial support exist but may be uneven; the deployer carries more of the responsibility. | A contract names who answers when something fails. The deployer carries less operational work, but depends on the provider. |
None of these arguments is settled by facts we can check from this page. Several depend on a specific model, a specific licence and a specific year. A learner should be able to state each side fairly, then say which arguments matter most for their case and why.
Open models: access, transparency and misuse
Evaluate access, transparency and misuse concerns in open models. For a specific open model ask three things. Access: what does the licence allow (commercial use, adaptation, redistribution), and what hardware and skills are needed to run it? A model that is free but needs a server and an engineer is not equally open to everyone. Transparency: what is published (weights only, or also training data description, evaluation results, known limits)? Open weights with no documentation allow inspection of behaviour but not of origins. Misuse: what can a bad actor do that they could not do with a service that watches use, and what can a defender do that they could not do with a closed service? Record both. Reasonable people weigh the two differently.
Closed models: control, support and dependency
Evaluate control, support and dependency concerns in closed models. Ask: control (can the provider change the model, price or terms without your agreement, and how much notice is promised?); support (who answers during an incident, in your language and time zone?); and dependency (if the service ends, rises in price or is not available in your country, how long would it take to switch, and what would be lost?). Write the answers as a short exit note. For Greenfield Clinics the exit note might say: "reminder templates are stored by us; switching to option C takes one day; switching to another provider takes about one month (estimate, untested)". An untested estimate is labelled as one.
Whichever option you choose, the decision pattern still applies: affected people (patients with low literacy or no smartphone), unknowns (how well the model handles each local language), conditions and a review date. Open or closed is one input to that decision, not the decision itself.
Copyright and training-data disputes
Assess copyright and training-data disputes. Models are trained on very large collections of text, images, code and audio, and some of that material was created by people who were not asked and not paid. Whether this is lawful depends on the country, the facts, the type of use and the date. Courts have not converged. For the basics of copyright, licences and attribution see the Beginner pages Copyright, Licences and Attribution: Using AI Output and Source Material and Creative Rights, Imitation and Freelance Practice: Fair Work with AI. This page does not repeat them; it teaches how to describe a dispute fairly.
Legal note (as of 2026-10-12; not legal advice): This area changes quickly, and decisions apply to their own facts and courts. (1) In the United States, the Copyright Office has released a "Part 3" report on training, as a pre-publication version on 2025-05-09, with a final version to follow; this page does not summarise its conclusions. (2) A US class action by authors against one AI company ended in a court-approved settlement, reported by the Authors Guild to have received final approval on 2026-07-20. A settlement is not a ruling on whether training is lawful. (3) On 2026-09-29 the US Court of Appeals for the Third Circuit held that one company's use of another's copyrighted legal-research headnotes to build a competing, non-generative AI tool was not fair use; the court itself distinguished generative AI cases, so its reach is limited. (4) The European Commission says providers of general-purpose AI models must have a copyright-compliance policy and publish a summary of training data; the EU also has a text-and-data-mining exception that rightholders can reserve. Positions in other countries differ and are changing. Source types: the Copyright Office website, a court opinion, an Authors Guild news report, and Commission pages; check the current official text for your country and sector.
| Argument | Made by | Question it raises |
|---|---|---|
| Creators should control and be paid for the use of their work in training | Many authors, artists and rightholder groups | How could consent and payment work for billions of items? |
| Learning from data resembles reading and should be allowed, or the benefits are lost | Many developers and researchers | Is a system that can reproduce a style or text equivalent to a person who learned it? |
| Access to large, diverse data is a condition for useful models in smaller languages | Researchers working on under-served languages | Can access be balanced with the rights of local creators? |
| Rules that favour only large licensed deals could shut out small developers | Small developers, open-model communities | Who can afford to comply? |
Legal permission and ethical attribution
Distinguish legal permission from ethical attribution. Three questions are different: May we use it? (law or licence), Should we credit the source? (a norm of honest work) and Is it fair to the people who made it? (a question of benefit). A use can be permitted but unfair, such as a lawful use that gives no credit to a community whose material made it possible. A use can be unlawful in one country and permitted in another. Attribution does not create permission, and permission does not remove the wish for credit. Keep the three answers on separate lines in your notes.
Document creator and dataset-contributor interests
Document creator and dataset-contributor interests. When your feature depends on training or reference data, write down whose material it is and what they might want. This is documentation, not a promise; it makes the interest visible to the person who decides.
Template:
Data source: (what, where it came from, under what licence or terms: UNKNOWN if not known)
Who made it: (authors, photographers, volunteers, annotators, communities)
Their interests: (credit, payment, control over reuse, removal on request, privacy, care)
How we learn about them: (provider documentation, licence text, contact route, community channel)
What we do about it: (credit, license check, opt-out route, refuse to use, ask the provider)
Open question: (what we could not find out, and who will keep asking)
Owner / review: (name, date)If the answer is "UNKNOWN" for the origin of the data, write that. It is itself the finding, and it is a reason to ask the provider or choose a source with clearer terms.
Human labour in data collection and annotation
Examine human labour in data collection and annotation. Behind many AI systems are people. They collect data, write example answers, label images and text, rank model outputs, review harmful content and test safety. This work is often done by contractors in many countries, through platforms or outsourcing companies. Describe the roles neutrally: they are skilled work that makes models usable, and the conditions vary widely.
Working conditions in data-labelling supply chains
Assess working conditions in data-labelling supply chains. Journalists have reported low pay and exposure to distressing material for some data workers. These are reports; this course does not give a figure or name a company. What a team can do is ask.
| Ask the provider or vendor | What a useful answer looks like | A weak answer |
|---|---|---|
| Who labelled or reviewed the data, and through whom? | Names the kind of workforce (own staff, contractors, platform) and the countries involved | "Our data is high quality." |
| How are workers paid, relative to local conditions? | A stated policy and how it is checked | Silence, or "market rate" with no detail |
| Is harmful content involved, and what support exists? | Limits on exposure, opt-out, counselling or breaks | No mention of the issue |
| Can workers raise concerns? | A channel that does not risk their work | A hotline nobody can reach |
A buyer cannot always verify the answers. Record what you asked, what you were told and what you could not check. That is the honest result; it is also better than a claim of "ethical AI" with nothing behind it.
Language and regional exclusion
Identify language and regional exclusion. A system can exclude people without a rule that does. Researchers (Ahia and colleagues, 2023, on a set of 22 languages) found that the number of tokens and the cost of the same content differ across languages, so speakers of many languages are "overcharged while obtaining poorer results", often in regions where the service is less affordable. Other forms are easy to imagine and must be checked case by case: weak accuracy for a dialect, a connection too slow for a hosted service, a payment method that is not available, a help page only in one language, training data that reflects some regions far more than others. Test the actual feature in the actual languages and conditions of the users it claims to serve, and write the results next to the claim. Greenfield Clinics should test reminders in all three local languages with patients before saying that it serves them.
Where this shows up at work
A product team keeps a stakeholder table next to its risk register. A procurement or engineering team writes a short "open or closed" note with an exit plan. A content or legal team keeps a list of data sources and licences. An operations team asks suppliers about worker conditions before renewing. In all four, the useful output is a record of what was asked, what was answered and what stayed unknown.
Common mistakes
- Treating "open" or "closed" as good or bad. Each solves some problems and moves others. The fix is to compare on the same questions for the same use.
- Mapping only the groups at the meeting. The groups that pay without a say are often absent. Add them first.
- Treating a settlement or one court decision as the law. A decision binds its parties and applies in its own place. The fix is to say what was decided, where and when, and to check your own country.
- Treating attribution as permission, or permission as fairness. Keep the three questions separate.
- Accepting a vague supply-chain answer as proof. Record that nothing was verified and decide whether that is acceptable for the stakes.
Try it yourself
Use ROWS from this page. The exercises revisit the risk register fields from Impact Assessment: Scope, Stakeholders and Harms for a Bounded AI Feature (page 1).
- Easy. For Greenfield Clinics, name two groups who "pay without a say" if the clinics choose option A or B. What would you ask them?
- Medium. Add a row to
ROWSfor a group missing from the screening table, and print the groups that pay without a say, sorted by name. - Hard. Write a fair two-sided summary (about 120 words) of the open versus closed choice for Greenfield Clinics, ending with the conditions under which you would revisit it, but without declaring a winner.
Answers
Easy. Examples: patients who speak a less-served local language (they may get poorer reminders); patients without a phone or smartphone (they may lose the phone service if staff time moves to AI); clinic staff whose workload changes; local creators whose language material may be in the training data. You would ask them how they currently get reminders and what a missed one costs.
Pass checklist: at least two groups outside the decision-makers; each paired with a concrete effect and a question. A weak answer lists only the clinic manager and the provider.
Medium.
ROWS.append(("Applicants with no reliable internet", "may be unable to upload a CV",
False, True, False))
for group in sorted(g for g, _, gains, pays, say in ROWS if pays and not say):
print(group)Applicants with no reliable internet
Applicants, unusual CVs
Current employees
Local job marketPass checklist: the new row has all five fields; the output is sorted by name; the new group is a real affected non-user.
Hard. A strong answer says: open can give control over data location and no per-use fee but needs skills and leaves safety work with the clinic; closed is faster to start and has a named support route but creates dependency and sends patient messages to a provider; no AI keeps human contact but needs staff time. It then lists conditions to revisit (if the languages are poorly handled, if the provider changes terms, if staff time falls). Pass checklist: both sides stated in the same terms; option C mentioned; no sentence of the form "obviously X is better"; review date or trigger. A weak answer sides with one option or lists only technical points.
Summary
- Map each group as gains, pays and has a say; the groups that pay without a say need special attention.
- Compare open and closed models on the same questions: access, transparency, misuse, control, support and dependency. State each side fairly and do not declare a winner.
- Describe copyright and training-data disputes with dates, courts and limits; separate legal permission, attribution and fairness.
- Document creator, contributor and data-worker interests, and ask suppliers about them; record what is unknown.
- Test language and regional access in the real conditions of your users.
Next: Labour, Environment and Trade-Offs: Weighing Evidence You Cannot Fully Measure continues with accessibility, resource use, how to read an environmental claim and how to write a balanced impact note.