This is going to be a long rambling post. So, here's a summary in case you want the highlights. 

TL;DR

Some AI tools can do more than answer questions. They can make plans, send messages, buy things, or use other computer tools. These systems are called AI agents.

I'm writing this post to ask an important question. 

Who is responsible if an AI agent makes a mistake or hurts someone? 

The AI itself is not a person. Responsibility may belong to the people or companies that built, changed, sold, or used it.

To decide who should be responsible, the article says we should ask:

1. Who controlled the AI?
2. Who gave it the power to act?
3. Who knew about the danger?
4. Who could have prevented the harm?

For example, a company may let an AI agent buy supplies. If the AI buys the wrong items, the company may still be responsible because it gave the AI permission to make purchases. Laws in the United States already recognize that computer programs can help form contracts Agency and Electronic Agents.

The article also explains open weights. Weights are important numbers that help an AI model work. A company may let people download these weights, but that does not always make the AI fully “open source.” True open-source AI gives people broader freedom and enough information to use, study, change, and share the system Open Source AI and Open Weights.

Licenses can set rules for using open weights. For example, a license might require people to:

• Test the AI before using it;
• Explain how they changed it;
• Protect private information;
• Watch for safety problems;
• Report serious incidents; and
• Keep records of what the AI did.

But a license cannot erase every legal duty. A company may still be responsible if it uses AI carelessly or places it in a dangerous situation Negligence and Enterprise Liability.

The article connects these ideas to the LinkedIn post I wrote called, 11 Pillars of a Scalable AI Governance Framework. The pillars encourage organizations to create clear leadership, use good data, protect security and privacy, treat people fairly, allow human review, make AI accessible, monitor it, follow the law, and train workers Introduction.

What I Hope You Takeaway

AI should help people, but people and companies must remain responsible. They should test AI, set clear limits, keep records, protect users, and make sure a human can step in when an important decision is being made.

Beyond Just Models - Thinking About Agentic Liability and Open-Weights Licensing

Abstract

Agentic AI does not fit neatly into familiar legal categories. It uses software systems that can plan, route work, negotiate, call tools, and carry out tasks with little real-time human review. At the same time, the market for “open” AI has split into three legally different groups. These are truly open-source AI, source-available model releases, and open-weights distributions. Open weights give users a model’s learned parameters, but not all the freedoms that come with open source. argue that the law should address these two changes together. We should not decide liability by treating the model like a person. Instead, the law should assign responsibility across the AI value chain based on control, capability, knowledge, and risk. A license cannot replace public law. But it can put governance into practice by setting duties for provenance, or where data and models came from; evaluations; notices to later users; incident reports; audits; security; and control over operations.

compare U.S. and EU law. I cover agency and attribution, which ask whose acts count under the law. I also cover contracts made by electronic agents, negligence, product liability, enterprise liability, causation, evidence burdens, copyright, license enforcement, warranties, disclaimers, indemnities, audit rights, and regulatory duties. I place those rules within the EU AI Act, Directive (EU) 2024/2853 on defective products, the U.S. E-SIGN Act and UETA, and recent U.S. Copyright Office guidance on AI. I then draw on my October 8, 2025 governance model, called the “11 Pillars of a Scalable AI Governance Framework.” The model offers a practical structure for assigning risk before harm occurs, or ex ante, and enforcing accountability afterward, or ex post.[^1] The result treats agentic liability and open-weights licensing as two sides of the same governance problem, not as separate debates.

Introduction

The key legal question about agentic AI is not whether a model is “autonomous.” The question is who should answer for what happens when it acts. An agentic system may find information, choose tools, write messages, make recommendations, place orders, or start the next step in a workflow. But people and organizations still stand behind every act. They may include the model developer, licensor, fine-tuner, deployer, infrastructure provider, principal, and user. The law already knows how to divide responsibility in systems with many actors. What it needs is a clear method for applying old legal rules to these new technical layers.[^2]

AI licensing raises a related problem. The label “open” no longer has one clear meaning. The Open Source Initiative’s Open Source AI Definition requires real freedom to use, study, change, and share a system. It also requires access to the preferred form for changing the system and its key parts.[^3] In contrast, many well-known “open” releases provide model weights under custom terms, limits on use, or limited documents. Model weights are the learned numerical parameters that shape the model’s output. These releases may be useful and easy to reuse. Still, they are not always open source in the legal sense. They are better called open-weights or source-available models.[^4]

These two debates meet because a license is often the first tool an AI provider uses to manage later risk. Licensors may ban certain uses, disclaim warranties, require credit, require notices to later users, and keep audit rights. But contract terms alone cannot decide liability when a model is used to sort healthcare cases, rank job applicants, or make purchases on its own. Courts and regulators will ask familiar questions. Who controlled the system? Who knew about the risk? Who could have reduced it at the lowest cost? Who gained from the deployment? And who was best able to save the evidence?[^5]

make three claims. First, the law should assign agentic liability by looking at what each actor did. It should not pretend that the “AI” itself is a legal person. Second, an open-weights license should serve as a layer of governance, not just as an intellectual property, or IP, tool. Third, my “11 Pillars of a Scalable AI Governance Framework” connect legal rules to daily practice. The pillars describe the controls that courts and regulators increasingly expect: governance structure, data controls, security, privacy, transparency, fairness, human oversight, accessibility, monitoring, legal alignment, and documentation.[^1]

Relevant Doctrines

A. Agency, Attribution, and Electronic Agents

U.S. and EU law start with a basic rule. Software does not become a legal person just because it can act without live human review. In the United States, E-SIGN says a contract does not lose legal effect only because one or more electronic agents helped form it. But the agent’s act must be legally tied, or attributed, to the person who will be bound.[^6] UETA follows the same approach. It also says electronic agents may form a contract with each other even if no person reviewed the final terms at that moment.[^7]

This matters for agentic AI in two ways. First, attribution is still central. The legal question is not whether the machine “meant” to cause the result. It is whether the law ties the act to the principal because of authorization, programming, deployment rules, or the parties’ past dealings. Second, laws on electronic agents support automated contracts. But they do not erase common rules about mistake, authority, unconscionability, fraud, or acts within the scope of employment.[^7] For example, a purchasing bot may bind a company when it accepts a vendor’s quote within limits set by the company. A defense may still apply if the vendor knew the bot had failed, took advantage of a clear error, or manipulated the system.

EU law takes a different path to a similar result. It relies less on a special law for electronic agents. Instead, it uses ordinary rules on attribution, authority to act for another, consumer protection, and conduct in platforms and markets. In short, responsibility falls on the legal actor that runs the system, not on the model itself.

B. Negligence and Enterprise Liability

Negligence remains the most flexible legal rule for harms caused by agents. The questions are familiar: Was the harm foreseeable? Did the actor use reasonable care? Did the actor breach that duty? Did the breach cause harm and damages? AI changes what reasonable care may require. For agentic systems, it increasingly includes:

• capability testing before deployment;

• boundary setting on tool use and authority;

• prompt and policy controls;

• logging and record retention;

• monitoring for drift, jailbreaks, hallucination patterns, and unsafe escalation;

• human review thresholds for high-stakes decisions; and

• incident response processes.

Enterprise liability becomes especially important when an organization gives work to an AI agent to cut labor costs or operate at a larger scale. The principal gets the benefits of automation. It is also often the party that can prevent harm at the lowest cost. For both legal and practical reasons, the organization should not be able to shift all responsibility to end users through terms of service alone.

C. Product Liability in the EU and Its Spillover Significance

The EU’s revised Product Liability Directive, Directive (EU) 2024/2853, is especially important. It updates strict liability, which can apply without proof of negligence, for products that use digital tools and AI. The Directive clearly includes software in its product rules. It treats some parties that make major changes as manufacturers. It also says courts must judge defects in light of cybersecurity and learning that occurs after sale. When a claimant faces extreme technical difficulty, a court may order disclosure of evidence and use rebuttable presumptions, which are findings the other side may disprove.[^8]

Several parts of the Directive matter for agentic systems. A court may judge whether a product is defective by looking at how it was presented, its instructions, its reasonably foreseeable use, its ability to learn after sale, its links to other products, and cybersecurity rules tied to safety.[^8] So model cards, safety documents, limits on tool use, and warnings to later users can have legal weight. They are not just good ideas. The Directive also makes proof easier in some cases. If a defendant does not share key evidence, or if technical complexity makes proof far too hard, a court may presume a defect or causation. The defendant may rebut that presumption.[^8] In a hard-to-see AI stack, access to evidence may matter as much as the merits.

The Directive also takes a careful approach to free and open-source software. Software supplied outside commercial activity is generally outside the Directive. But when that software becomes part of a commercial product, the commercial maker may be liable for defects that result.[^9] This rule will likely shape disputes about later use of open weights. An open release by an upstream provider does not shield a downstream company that puts it into a commercial product.

D. Causation and Evidentiary Burdens

Causation is often the hardest legal issue in disputes about agentic AI. Causation asks whether the challenged conduct led to the harm. AI systems have many layers, can adapt, and often work by probability rather than certainty. Harm may come from prompt design, fine-tuning, a tool call, a collection of retrieved material, a business rule, user misuse, or workplace incentives. This complexity creates an evidence gap. Claimants often do not have the logs, model documents, internal tests, or failure reports held by the other side.

The EU addresses that evidence gap more directly than the United States. Its Product Liability Directive uses disclosure and presumptions to help claimants in some cases.[^8] U.S. law is more scattered. Still, ordinary evidence rules, discovery duties, the risk of spoliation, or loss of evidence, and adverse inferences still matter. An adverse inference lets a court draw a harmful conclusion when a party failed to preserve evidence. In practice, an organization should be able to rebuild what an AI agent saw, decided, and did. If it cannot, it may lose both trust and an advantage in court.

E. Copyright, IP Scope, and License Enforceability

Open-weights licenses sit on top of several uncertain and overlapping IP rights. U.S. copyright law clearly covers code, documents, and many datasets. It is less clear how far copyright covers model weights or learned parameters by themselves. The U.S. Copyright Office has made two useful points. First, an AI-assisted output needs enough human authorship to receive copyright. Second, the Office is still studying the use of copyrighted works in AI training. It released Part 3 of its AI report in pre-publication form on May 9, 2025.[^10] The practical lesson for deal lawyers is simple. A license may involve a mix of rights, so drafters should not claim more certainty than the law supports.

U.S. courts have enforced open-source licenses. In Jacobsen v. Katzer, the Federal Circuit held that open-source license terms can act as enforceable copyright conditions.[^11] Courts have also allowed contract claims for breaking an open-source license when the complaint properly alleges agreement and exchange. The Ghostscript/Hancom dispute is one example.[^12] The lesson for AI licenses is clear. Rules about credit, notices to later users, or redistribution are not just good manners. When drafted correctly, they may have legal force.

Still, copyright cannot do all the work. Limits on a field of use, duties to test a model, or safety-reporting rules may be contract covenants even when copyright coverage is unclear. A covenant is a promise in a contract. AI licenses should therefore use both copyright conditions and contract covenants where appropriate.

Open Source AI, Source-Available Models, and Open Weights

These legal categories matter because policy debates often mix them together.

Category	Core Legal Character	Typical Access	Typical Restrictions	Best Description
Open-source AI	Released on terms that allow use, study, change, and sharing, with access to the preferred form for changing the system	Weights, code, and enough data, documents, or similar information	No limits based on the field of use, as understood in classic open source	True open-source release
Open weights	Model parameters are public, but other parts may be missing or under separate licenses	Weights and some documentation; code/data may be partial	May or may not include use restrictions	Weight-access release
Source-available model	Access is given under proprietary or custom terms	Varies widely	Often includes rules for acceptable use, competition, or scale	Publicly available, but not open source

The OSI’s Open Source AI Definition 1.0 centers on the classic freedoms to use, study, change, and share. For machine-learning systems, the needed materials include the architecture, parameters, inference code, and information needed to understand and change the system.[^3] As a result, many familiar releases are not legally open source, even if anyone can download them.

Meta’s Llama licenses show the difference. They make model materials widely available and allow many kinds of use and change. But they also use custom license terms and limits in their use policies. These releases are best described as source-available, open-weight models, not OSI-compliant open-source AI.[^4] RAIL-style licenses also support broad reuse while adding responsible-use limits. That approach may help governance, but it is not the same as an open-source software license.[^13] The PyTorch Foundation’s OpenMDW effort rests on a related point. AI models need licenses built for a mix of materials, including architecture, weights, code, documents, data, and related rights. Simply extending a software-only license is not enough.[^14]

A Proposed Framework: Control, Capability, Knowledge, and Risk

The law should divide agentic liability across the AI stack by using four factors.

1. Control

Who set the system’s operating rules, permissions, connections, limits, and use setting?

• High-control actors include deployers, organizational principals, and fine-tuners that can set guardrails for a field.

• Moderate-control actors include infrastructure and tool providers that control APIs, routing, permissions, rate limits, or safety layers.

• Lower-control actors include upstream weight licensors that cannot access a deployment and did not keep governance controls.

2. Capability

Who created or greatly changed the ability that caused the harm?

• base-model developers, for broad reasoning or tool-use abilities;

• fine-tuners, for patterns of action in a certain field;

• deployers, for workflow connections and business rules;

• tool providers, for ways to act, such as payment APIs or permission to write to a customer relationship management system, or CRM.

3. Knowledge

Who knew, or should have known, how the system could fail?

• actual knowledge from tests, incident reports, red-team findings, or user complaints;

• constructive knowledge, meaning what the actor should have known, from public benchmarks, common failures, or regulatory warnings;

• greater knowledge shown by sole access to logs, model cards, or internal tests.

4. Risk

Who created, increased, or made money from the risk? Who could reduce it at the lowest cost?

• organizations that give high-stakes decisions to agents should have greater duties;

• companies that put open weights into products should not push all risk onto upstream communities;

• keeping the financial benefit supports assigning liability to the enterprise.

Allocation Matrix

Actor	Primary Duties	Typical Liability Theories	Best Risk Controls
Model developer / licensor	explain abilities and limits; train and test responsibly; publish sources and warnings	negligence; product liability in some places; misrepresentation; breach of license	model cards, evals, usage limits, security controls
Fine-tuner / modifier	assess major changes; test task fitness again; record differences	negligence; substantial-modification liability; contract	change logs, benchmark differences, tests for the field
Deployer / integrator	set the scope of authority; review outputs; ensure the workflow is lawful	negligence; enterprise liability; sectoral compliance	human-in-the-loop, or HITL, review gates; escalation limits; logs; policy rules
Tool / infrastructure provider	secure ways to act; keep records; enforce permissions	negligence; aiding theories; contract	API controls, authentication, audit trails
Organizational principal	governance, training, oversight, incident response	agency and attribution; rules like respondeat superior, which can make an employer answer for a worker’s acts; negligence	board-level governance, approval matrices
User / operator	lawful use; follow instructions; avoid misuse	contributory fault; contract	training, notices, access controls

This framework avoids two bad extremes. It does not blame the model as if it were a person. It also does not excuse everyone just because the output came from a complex system.

Real-Life Applicability

A. Autonomous Purchasing Agent

Suppose a company uses a purchasing agent. The agent may find office equipment and buy it through a payment API up to a set dollar limit. The agent accepts a vendor listing that someone has manipulated and buys fake devices. Under U.S. law on electronic agents, the contract may still count as the company’s act if the system stayed within the authority the company gave it.[^6] The dispute then turns to negligence, mistake, the vendor’s knowledge, and the company’s controls. Did the deployer check signs about the vendor’s reputation? Did it limit product types, sellers, or payment methods? Did the tool provider keep logs? If the vendor knowingly used a weakness in the system, that fact affects both contract and tort claims. A tort is a civil wrong that causes harm. Still, the company receives the main benefit from automation and will likely bear most of the loss.

B. Customer-Service Agent Making Commitments

Now suppose a customer-service agent can offer refunds and service credits. It starts making promises outside company policy. This happens because its source documents are old and its conversation rules do not limit its authority. Customers rely on those promises. Ordinary attribution rules give a clear answer. The company built and branded the interface, then asked customers to rely on it. The more the agent appears to have authority, the harder it is for the company to argue later that “the bot was unauthorized.” Contract law, estoppel-like rules, consumer protection, and negligence all point in the same direction. Estoppel can stop a party from denying a claim when another person reasonably relied on its words or conduct. The answer is not to deny agency. It is to build limits, such as a fixed list of offers, approval for exceptions, and policy sources that the agent cannot change.

C. Healthcare or Employment Workflow

Liability has more layers in healthcare triage and job screening because special duties for those fields are stronger. A hospital may use an agent to summarize records and decide which cases need quick review. If the work is high stakes and important error rates are foreseeable, the hospital cannot rely on a broad disclaimer from an upstream provider. An employer that uses an agent to rank applicants or draft reasons for rejection also faces concerns about fairness, discrimination, and records. In both settings, human review must be real, not for show. The organization chose where to use the system, placed it in an important process, and controls how to correct harm. Under my framework, the deployer and principal carry the most responsibility. The upstream developer’s responsibility grows if it knew the model could fail in that field and did not clearly disclose the risk.

D. Downstream Deployment of Open Weights

Finally, consider a startup that downloads open weights. It fine-tunes them to screen legal clients and offers the result to consumers. The startup cannot fairly claim that an open upstream release removes its own duties. Under the EU Product Liability Directive, a party that makes a major change may count as a manufacturer. Under the AI Act, a downstream provider may have its own duties based on the system’s legal class and how it enters the market.[^8] An upstream licensor may avoid some AI Act transparency duties when it uses a qualifying free and open-source license. Even then, duties about copyright policy and summaries of training content may remain. And the exemption does not apply to general-purpose AI, or GPAI, models with systemic risk.[^15]

Governance Architecture Through My Eleven Pillars

My October 8, 2025, article is hopefully useful. It treats AI governance as part of how an organization runs, not as an extra compliance checklist.[^1] For agentic liability and open-weights licensing, my 11 pillars work as follows:

My Pillar	Liability Function	Licensing Function
Organizational structure	sets who may decide and who is accountable	identifies licensor, modifier, deployer roles
Data/input governance	reduces harm from bad inputs and disputes about sources	requires the source history of datasets and notices about use
Security	reduces prompt injection, model theft, and tool abuse	requires stronger security and incident reports
Privacy	limits misuse of sensitive inputs and outputs	assigns duties for following privacy law
Transparency / explainability / ability to challenge	supports attribution, evidence, appeals	requires model cards, downstream notices
Fairness / equity	reduces discrimination exposure	requires evaluation disclosures
Human oversight	stops too much delegation in high-stakes settings	defines reserved decisions and override rights
Accessibility / internationalization	reduces exclusion and misunderstanding	requires local language and accessible notices
Monitoring / audit	keeps evidence and catches drift, or change over time	creates audit rights and logging duties
Legal / ethical alignment	connects the system to the law in each place	ties use rights to compliance obligations
Documentation / training	proves reasonable care	supports duties passed to later users and promises to provide training

A generous commenter suggested adding Cultural Adoption. Adoption is incredibly important because without it, the organization has not implemented. For the purposes of this article, I've left it out of the analysis, but Ben's comment should be incorporated an overarching organizational framework. 

I hope this framework helps both in running organizations and legal disputes. Courts and regulators increasingly ask whether governance, testing, records, escalation, and audits matched the level of risk. My pillars can therefore serve as evidence that an organization acted with care, not just as a list of best practices.

Licensing Recommendations for Open Weights

An open-weights license should be a governance tool. It should clearly assign operating duties that can be enforced. The following terms matter most.

A. Permitted Scope and Controlled Use

Clearly say whether the allowed use is commercial, noncommercial, only for research, or limited to a certain field. If some uses are banned, say whether each limit is a license condition, a contract covenant, or both. Unclear terms are harder to enforce.

B. Attribution, Provenance, and Downstream Notices

Require retention of:

• attribution notices;

• model/version identifiers;

• modification and fine-tuning records;

• available information about the sources of training or test materials; and

• notices to later users about known limits.

C. Evaluations, Security, and Incident Reporting

For capable models, include obligations to:

• run basic safety tests and tests for the field before deployment;

• preserve records of those evaluations;

• use reasonable security against model extraction, abuse of jailbreaks, and unsafe tool calls; and

• report serious incidents within defined periods.

These terms match new AI Act expectations for records, tests of systemic risk, cybersecurity, and reports of serious incidents.[^15]

D. Allocation of Control

The license should specify which party controls:

• base weights;

• fine-tuned variants;

• deployment prompts and policies;

• tool integrations;

• safety layers;

• end-user interfaces; and

• post-deployment monitoring.

This makes it harder to shift blame and helps the parties design indemnities. An indemnity requires one party to cover certain losses of another.

E. Modification and Fine-Tuning Terms

Require material modifiers to:

• rename materially altered variants;

• document significant parameter, dataset record major changes to parameters, datasets, or policies;

• re-run stated evaluations for sensitive uses; and

• take responsibility for new ways the model may fail because of fine-tuning.

F. Warranties, Disclaimers, Indemnities, and Insurance

Disclaimers remain useful, but they are not talismans. Upstream licensors should disclaim merchantability, fitness, and uninterrupted performance to the maximum extent permitted, while recognizing that mandatory law may override such terms. Deployers in regulated or high-stakes settings should not expect an upstream disclaimer to protect them from claims by users or regulators. Indemnities should match each party’s risk:

• licensor indemnity for knowing IP misrepresentation or intentional malware/backdoor insertion;

• modifier indemnity for harms arising from material changes;

• deployer indemnity for workflow misuse, unlawful sectoral deployment, or failure to implement required oversight.

Insurance requirements may be appropriate for high-risk enterprise deployments.

G. Audit Rights

Audit rights should be targeted, not punitive. A mature structure includes:

• records-access rights tied to suspected serious breach;

• confidentiality protections and trade-secret handling;

• third-party assessor options;

• remediation periods; and

• termination rights for uncured critical violations.

Recommendations

1. Adopt a role-based liability map before deployment. Every agentic system should have a written matrix assigning responsibility across developer, modifier, deployer, infrastructure provider, and principal.

2. Treat logging and evidence preservation as core safety functions. In both litigation and regulation, inability to reconstruct system behavior is itself a governance failure.

3. Use the term “open source” precisely. If a release does not satisfy OSI-style openness, call it open weights or source-available, not open source.

4. Draft AI licenses as dual-track instruments. Separate copyright conditions from contractual operational covenants.

5. Reserve human authority for consequential acts. Commitments involving payment, employment, healthcare, legal rights, or safety should have explicit escalation thresholds.

6. Bind substantial modifiers. Fine-tuners and downstream integrators should inherit baseline duties and assume liability for material alterations.

7. Align governance with my eleven pillars. The framework offers a practical checklist for proving reasonable care, organizational ownership, and continuous compliance.[^1]  

Conclusion

Agentic AI does not require law to invent a robotic personhood doctrine. It requires law to see clearly where authority, capability, knowledge, and risk actually sit. Once that is done, familiar doctrines, like agency, negligence, product liability, enterprise responsibility, causation, and evidentiary allocation, remain surprisingly adaptable. The harder challenge lies in implementation: documenting who controlled what, who changed what, and who knew what when the system acted.

Open-weights licensing sits at the center of that implementation challenge. It cannot displace public law, but it can distribute governance obligations through the AI supply chain. The most defensible path forward therefore combines doctrinal realism with operational specificity: precise categorization of openness, carefully segmented contractual duties, and institutional controls consistent with my eleven-pillar architecture. Beyond the model, accountability belongs to the humans and entities who build, release, modify, deploy, and profit from agentic systems.

Footnotes

[^1]: Daphné Pierre, 11 Pillars of a Scalable AI Governance Framework (LinkedIn, Oct. 8, 2025). I identify eleven governance pillars: organizational structure; data/input governance; security; privacy; transparency, explainability, and contestability; fairness; human oversight; accessibility and internationalization; monitoring and audit; legal and ethical alignment; and documentation and training.

[^2]: See Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024, art. 1, art. 2, 2024 O.J. (L 1689) 1 (establishing a Union-wide framework governing providers and deployers of AI systems and GPAI models); European Commission, AI Act (application timeline noting entry into force on Aug. 1, 2024 and general applicability from Aug. 2, 2026, with exceptions). (eur-lex.europa.eu)

[^3]: Open Source Initiative, The Open Source AI Definition 1.0 (defining Open Source AI around the freedoms to use, study, modify, and share, together with access to the preferred form for modifications and the means to use the system). (opensource.org)

[^4]: See Meta, Llama 2 Community License Agreement (granting broad rights but under bespoke terms and an incorporated acceptable-use policy); Meta, Introducing Llama 3.1 (describing an openly available model release while also discussing license changes and ecosystem controls). These features make Llama-style releases better understood as source-available open-weight models than OSI-compliant open-source AI. See also Hugging Face, OpenRAIL: Towards Open and Responsible AI Licensing Frameworks (explaining licenses that combine broad access with use restrictions). (ai.meta.com)

[^5]: See NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0); NIST AI RMF Playbook, Govern function (emphasizing governance, documentation, legal/regulatory understanding, and continuous risk management across the AI lifecycle). (nvlpubs.nist.gov)

[^6]: Electronic Signatures in Global and National Commerce Act, 15 U.S.C. §§ 7001(h), 7006(3) (providing that contracts involving electronic agents may not be denied legal effect solely for that reason, if the action is legally attributable to the person to be bound, and defining “electronic agent”). (law.cornell.edu)

[^7]: Unif. Elec. Transactions Act §§ 9, 14 (Unif. L. Comm’n 1999) (addressing attribution and automated transactions); id. prefatory note and comments (stating that the Act validates electronic transactions without displacing underlying substantive law and that electronic agents bind the user of the machine). (uniformlaws.org)

[^8]: Directive (EU) 2024/2853 of the European Parliament and of the Council of 23 October 2024 on liability for defective products, arts. 7–10, 2024 O.J. (L 2853) 1 (defectiveness, liable economic operators, disclosure of evidence, burden of proof, and presumptions); id. art. 8(2) (treating certain substantial modifiers as manufacturers). (eur-lex.europa.eu)

[^9]: Id. recitals concerning software and free/open-source software supplied outside commercial activity, while preserving liability for downstream commercial manufacturers integrating such software into products. (eur-lex.europa.eu)

[^10]: U.S. Copyright Office, Copyright and Artificial Intelligence (noting Part 2 on copyrightability issued Jan. 29, 2025, and Part 3 on generative AI training released in pre-publication form on May 9, 2025); U.S. Copyright Office, Copyright Registration Guidance: Works Containing Material Generated by Artificial Intelligence (Mar. 16, 2023); U.S. Copyright Office, Copyright and Artificial Intelligence, Part 2: Copyrightability (concluding that copyrightability turns on sufficient human authorship, not prompts alone). (copyright.gov)

[^11]: Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008) (recognizing that open-source license terms may operate as enforceable copyright conditions). (cafc.uscourts.gov)

[^12]: Artifex Software, Inc. v. Hancom, Inc., No. 3:16-cv-06982 (N.D. Cal.) (allowing contract theories tied to alleged open-source license noncompliance to proceed past the pleading stage, and later settling). See also Artifex, Artifex and Hancom Reach Settlement Over Ghostscript Open Source Dispute. (app.midpage.ai)

[^13]: Hugging Face, OpenRAIL: Towards Open and Responsible AI Licensing Frameworks (describing RAIL licenses as combining open access with identified responsible-use restrictions). (huggingface.co)

[^14]: PyTorch Foundation, The Open Source Legacy and AI’s Licensing Challenge (describing OpenMDW as a purpose-built license for model architecture, parameters, code, documentation, data, and related rights, developed to operationalize the Model Openness Framework). (pytorch.org)

[^15]: AI Act art. 53(1)–(2), art. 54(6), art. 55, art. 56 (GPAI obligations, open-source exceptions, systemic-risk obligations, and codes of practice); European Commission, Guidelines on Obligations for General-Purpose AI Providers (published July 18, 2025) (clarifying that open-source GPAI providers may be exempt from certain technical-documentation, downstream-documentation, and EU-representative obligations if conditions are met, but still owe copyright-policy and training-summary duties, and that systemic-risk models remain fully covered). (eur-lex.europa.eu)

The Future Can't Leave People Behind 

Let's Bring Back Technology for the People

There was once a time when the internet felt like a promise.

Not a product. Not a marketplace. Not a surveillance machine. Not a battlefield of algorithms competing for attention. A promise.

In its early cultural imagination, the internet represented possibility. It was supposed to connect people across geography, class, language, and circumstance. It was supposed to democratize knowledge. It was supposed to make information easier to access, communities easier to build, voices easier to hear, and opportunity easier to distribute. For many people, the internet was not just a technological breakthrough, it was a social one. It suggested that humanity had created a tool powerful enough to help us become more informed, more connected, more creative, and perhaps even more compassionate.

That older vision of the internet was not perfect, and it was mostly not free from inequality, exclusion, or commercial interest. But it carried a certain optimism. People believed in the good that technology could do. They believed that if information could move freely, if people could communicate across borders, if knowledge could be shared at scale, then society might become better. The internet seemed to offer a new kind of public square, messy, imperfect, but alive with human possibility.

Somewhere along the way, that promise changed.

The internet became less like a commons and more like a shopping mall. Less like a public library and more like a casino. Less like a tool for collective uplift and more like an engine for monetization. The digital world, once imagined as a place made by and for people, became increasingly shaped by the priorities of capitalism: growth, scale, extraction, optimization, advertising, engagement, profit.

This shift did not happen overnight. It happened gradually, through platforms, business models, investment incentives, data collection, and the normalization of a simple but devastating idea: if something can be monetized, it should be. Human attention could be monetized. Human relationships could be monetized. Human insecurity could be monetized. Human creativity could be monetized. Human loneliness could be monetized. Even outrage could be monetized.

The result is the world we live in now, a world where extraordinary technological advancement coexists with extraordinary social frustration. We have more tools than ever, yet many people feel less supported. We have more platforms for expression than ever, yet many people feel unheard. We have more information than ever, yet many people feel confused, manipulated, and exhausted. We have more innovation than ever, yet large portions of society are struggling to meet basic needs.

That contradiction should trouble us. It should force us to ask whether we are using the right definition of progress.

Too often, progress is measured by what we can build rather than whom we help. A new device is treated as progress. A faster platform is treated as progress. A more powerful algorithm is treated as progress. A company reaching a higher valuation is treated as progress. A technology becoming more efficient, more scalable, or more profitable is treated as progress.

But utility is progress. Usefulness is progress. Human benefit is progress.

A tool might be impressive. A platform may be clever. An artificial intelligence system may be breathtaking in its technical sophistication. But if it does not meaningfully improve all human life, if it does not reduce suffering, expand opportunity, protect dignity, or support those most in need, then we should be careful about calling it progress. It may be advancement. It may be innovation. It may be profitable. But progress requires a moral dimension. Progress is not merely movement forward in technical capacity. Progress is movement toward a better society.

And by that measure, we should worry.

Technology is advancing so quickly, but more and more people are being disadvantaged. Economic inequality continues to shape access to housing, healthcare, education, safety, and opportunity. Social alienation is widespread. Political anger is intensifying. Protests, unrest, and public frustration are not random disruptions, they are signals. They are evidence that many people do not feel served by the systems governing their lives. They are evidence that large portions of the population believe leadership, whether political or economic, is not operating on their behalf.

This is one of the defining problems of our time. The people with the most power to shape society are often not incentivized to serve society.

Political leaders are frequently incentivized to win elections, satisfy donors, dominate news cycles, and preserve power. Economic leaders are incentivized to increase shareholder value, capture markets, reduce costs, automate labor, monetize users, and generate returns. These incentives do not always align with the common good. In fact, sometimes they conflict with it.

That conflict matters because systems produce what they are designed to reward. We get what we reward. If we reward attention capture, we will get addiction by design. If we reward profit above care, we will get profitable systems that neglect human beings. If we reward scale without responsibility, we will get massive technologies deployed faster than society can understand, regulate them, or equitably distribute across nations of all sizes.

This is especially urgent in the age of artificial intelligence.

AI is often discussed as inevitable, as though society has no choice but to accept whatever version of the future the most powerful technology companies decide to build. We are being told that AI will transform everything, like work, education, healthcare, law, art, communication, government, and daily life. Some of that is probably be true. AI will produce real benefits. It may help solve complex problems, improve access to services, assist workers, accelerate research, and expand human creativity.

But the question is not if AI can do powerful things. We know that, obviously. The question is, who is benefiting from this power?

If AI is developed primarily to reduce labor costs, concentrate wealth, increase surveillance, manipulate behavior, or replace human judgment in contexts where empathy and accountability are essential, then society may become more technologically advanced while becoming less humane. If AI systems are built by a narrow class of people, trained on biased histories, deployed by profit-driven corporations, and governed by weak public oversight, then the harms will not be evenly distributed. They will fall hardest on the people, and countries, who are already most vulnerable.

That is the pattern we should be afraid of. Not technology itself, but technology absorbed into unjust systems.

When society rushes forward with new tools while failing to protect single mothers, people experiencing homelessness, people with disabilities, the elderly, low-wage workers, children, caregivers, Least-Developed Nations, and other vulnerable populations, we reveal something about our priorities. We reveal that innovation has become more important than care. We reveal that speed has become more important than justice. We reveal that the future is being imagined without enough attention to the people most likely to be harmed by it.

What kind of society are we building if we cannot prioritize those who need support the most?

That question should be at the center of every conversation about technology. Not as an afterthought. Not as a public relations statement. Not as a diversity paragraph buried in a corporate report. At the center.

A society is not measured by how well it serves its most powerful members. The powerful usually find ways to be served. A society is measured by how it treats those with the least power, including the poor, the disabled, the elderly, the unhoused, the sick, the marginalized, the overworked, the underpaid, people from countries you've never visited, the people whose lives are often discussed in policy but ignored in practice.

If technological progress leaves those people behind, then it is not progress in the fullest sense. It is selective advancement. It is luxury futurism. It is the creation of tools that make life more convenient for some while making life more precarious for others.

We should be honest about the world such a path creates. It is not a great world. It is not even a stable one. A society that excludes or disregards large portions of its population eventually weakens itself. When people feel abandoned, they do not simply disappear. Their suffering becomes social tension. Their anger becomes political volatility. Their exclusion becomes a moral failure that eventually becomes a structural crisis.

Here's another concern that's been swirling in my head recently, intellectual stagnation.

A healthy society needs contradiction. It needs different experiences, different perspectives, different ways of understanding the world. Progress depends on ideas being challenged. If everyone left at the table thinks the same way, believes the same things, shares the same assumptions, and benefits from the same systems, then society does not become more intelligent. It becomes more fragile.

The most vulnerable populations often see truths that the powerful miss. People living at the edge of systems understand those systems differently. A person navigating disability understands access in a way an able-bodied designer may not. A single mother understands time, labor, childcare, and bureaucracy in ways that policymakers often fail to grasp. A person experiencing homelessness understands the failures of housing policy, mental healthcare, labor markets, and social services not as abstractions but as daily realities. Elderly people understand dependence, dignity, healthcare, loneliness, and social neglect in ways younger innovators may overlook.

If those perspectives are excluded from the design of the future, the future will be poorly designed.

This is why the obsession with sameness is so dangerous. When technology is built by narrow groups for narrow interests, it reflects narrow assumptions. It may become efficient, but not wise. It may become profitable, but not just. It may become seamless for the privileged and hostile to everyone else.

Without contradiction, we cannot move forward as a society. Without challenge, ideas become stale. Without difference, innovation becomes repetition disguised as novelty. A room full of people who agree with each other may move quickly, but speed is not wisdom. Sometimes disagreement is the very thing that prevents a society from making catastrophic mistakes.

This is where the current moment feels so unsettling on one side, and exciting on the other. For probably the first time in modern history, some people might look around and wonder whether humanity is moving backward even as technology moves forward. And another group of people see society moving into a utopian future that will solve everything.

That sounds paradoxical, but it's not.

A society can have advanced machines and declining empathy. It can have artificial intelligence and inadequate healthcare. It can have billion-dollar platforms and rising homelessness. It can have smart devices and social media, yet lonely people. It can have automation and exhausted workers. It can have endless content and little wisdom. It can have innovation conferences, product launches, and soaring valuations while ordinary people feel more anxious, less secure, and less hopeful about the future.

That part might not be progress.  

Some people confuse technological capability with social advancement. Technology can help produce progress, but it is not progress by itself. A tool has no moral value independent of how it is used, who controls it, who benefits from it, and who is harmed by it.

A hammer can build a shelter or destroy one. A network can connect communities or manipulate them. An algorithm can expand access or reinforce discrimination. AI can assist human flourishing or intensify inequality. The tool matters, but the system around the tool matters more.

So what would it mean to bring back technology for the people?

First, it would we need to change the questions we're asking. Instead of asking only “Can we build this?” we should ask “Should we build this?” Instead of asking “Can this scale?” we should ask “Who does this serve?” Instead of asking “How much value can this capture?” we should ask “How much suffering can this reduce?” Instead of asking “How can this increase engagement?” we should ask “How can this improve human life?”

Second, we need to challenge the assumption that market success equals social value. A product can make money while making society worse. A platform can dominate a market while damaging public discourse. A technology can be widely used because people are dependent on it, not because it is good for them. Profit is not proof of benefit. Growth is not proof of wisdom. Popularity is not proof of justice.

Third, we would need leadership with different incentives. If political and economic leaders are rewarded for serving capital more than people, then we should not be surprised when people are treated as secondary. Public policy, corporate governance, and social expectations all need to shift toward accountability, care, and long-term human outcomes. Leaders should be judged not only by what they build or how much wealth they generate, but by whether their decisions make society more livable, fair, and humane, not only be centralized institutions, but also by us, everyday people. We can do this by choosing where our dollars and attention go.

Fourth, vulnerable populations must be treated as central stakeholders in the future, not peripheral concerns. This means designing technology, policy, infrastructure, and public services with direct input from those most affected. It means asking how AI impacts disabled people, caregivers, the elderly, low-income families, workers, tenants, students, and people without stable housing. It means recognizing that those groups are not obstacles to innovation. They are necessary guides for building systems that actually work. One of the most memorable moments for me witnessing this early into my career, was when I saw UN NGO Representatives bring homeless people to the United Nations to explain their experiences before the representatives drafted advocacy arguments. Let's see more of this.

Fifth, let's bring back the idea of the internet as a public good. The internet does not have to be only an advertising machine or a shopping infrastructure. It can still be a place of education, mutual aid, creativity, civic participation, and community. But that requires intentional design. It requires spaces that are not entirely governed by engagement metrics. It requires protecting privacy, supporting independent creators, investing in digital literacy, and resisting the total commercialization of human interaction.

Finally, we need a more humane definition of progress.

Progress is not just faster. Progress is not just newer. Progress is not just more automated. Progress is not just more profitable. Progress is not a world where a handful of people build extraordinary tools while millions of others become more disposable.

Progress is a society where technology helps people live with more dignity. Progress is a society where single mothers have support, not judgment. Where disabled people have access, not barriers. Where elderly people have care, not abandonment. Where people experiencing homelessness have housing and careers, not marginalization. Where workers have security, not constant replacement. Where children inherit possibility, not collapse. Where disagreement is valued because it sharpens our collective thinking. Where the future is not something imposed by the powerful, but something shaped by all of us.

The younger generation is inheriting a difficult world. They are being handed powerful tools, but also fragile institutions, anxiety, economic instability, political polarization, and a digital environment designed to capture their attention from childhood. It is unfair to tell them that technology alone will save them. Technology will not save society if society does not decide to save itself.

That decision begins with values.

We must decide that people matter more than markets. That usefulness matters more than novelty. That care matters more than speed. That inclusion matters more than efficiency. That the future should be judged by how it treats the vulnerable, not by how impressed the powerful are with their own inventions.

This weekend someone told me I was naive to believe the old internet promise could make its way back in its original form. He said too much has changed. Maybe he's right. 

But the spirit of that promise, the belief that technology can serve human beings, expand knowledge, connect communities, and improve society, is still worth fighting for.

We do not have to accept a future where every human need becomes a business opportunity and every social space becomes a site of extraction. We do not have to accept a future where artificial intelligence advances while human compassion declines. We do not have to accept a future where the most vulnerable are treated as irrelevant to progress.

We can choose differently.

But choosing differently requires us to be clear. Technology is not the destination. Capital is not the destination. Efficiency is not the destination. The destination is human flourishing.

If a tool helps us get there, it is progress. If it does not, then no matter how advanced it appears, we should have the courage to question it.

Because a society that builds remarkable things while abandoning its people is not moving forward. It's just moving fast.

So, Here's A Challenge for my Builders

I challenge every builder, founder, policymaker, investor, and technologist to ask a harder question before moving forward. 

How does this benefit society?

And just as importantly, is the economic model equitable and fair to the most vulnerable people in society?

If every solution is designed only for people who already have money, access, stability, and power, then what happens to the people who do not? Are we intentionally choosing to leave them behind?

Because if innovation only serves those who can afford it, that's not progress. It is exclusion dressed up as advancement. True progress must be useful, accessible, and humane, especially for the people society too often forgets.

To the unhoused, people with disabilities, people living in countries with extreme poverty, caretakers, elderly, military spouses, people who are lonely, students, low-income families, and people on the fringes, we won't let you get left behind. 

Daphné