Introduction: The 6 parties in AI law

About this documentUpdated 2026-09-18ShowHide

Sean McDermott, Co-Founder and CEO, UnGovr

Written by Sean McDermott (with AI assistance) using the LexLint law library, which supplied every legal instrument, status and date on these pages.

Every law named here links to its summary page on lexlint.org, translated to English (if needed) and restructured to a standard format for human and code use. Every case links to the court's or the regulator's own record where one could be reached.

© 2026 UnGovr, publishing as LexLint. The text, the figures and the theme-register file are licensed under Creative Commons Attribution-NonCommercial 4.0: share and adapt them for noncommercial purposes with credit to LexLint (UnGovr). Please contact LexLint at hello@ungovr.org to discuss commercial use. Logos and wordmarks belong to their owners.

Corpus figures as of 2026-09-18.

In law, a party is a person or organisation that holds rights or owes duties in a situation, and so can be bound by a rule or held to account under it.

Every piece of user-facing software has a crowd of parties around it, and each one is the hook a different law reaches through. An AI agent sits in the middle of the same crowd and acts on most of them at once.

The six parties, and the agent

Each party has a name, boxed and in capitals, and the name means the same thing on every page of this section. Hover or focus a tag for its definition.

MAKER: makes it: the developer or publisher, the model provider, upstream suppliers, open-source projects.
DISTRIBUTOR: distributes it: the store or marketplace, the importer, the reseller, the integrator.
OPERATOR: runs it: the operator, a self-hosting customer, hosting and cloud, the services on the request path.
OVERSEER: oversees it: regulators and courts, auditors, standards bodies, platform rule-setters.
USER: uses it: the user as principal, the affected person, the data subject, a minor.
COUNTERPARTY: it talks to: the sites and interfaces it reads, the recipients it writes to, rightsholders, other users and devices.
AGENT: the software in the middle: software that pursues a goal by choosing and taking actions through tools, across more than one step, with limited human intervention between the steps. The Agentic AI Foundation publishes no definition of its own; its governance working group's charter speaks of "agentic AI systems", and this definition is meant to sit inside that phrase.

This document is the vocabulary the rest of the section uses. It is written for a technical reader and it names no statutes on purpose: the laws come in the documents that follow. What it fixes is the shape of the question. Before anyone can say which law applies to an AGENT, they have to be able to say which parties the AGENT's task touched, where each of them was, and what the law asks of each. That question is older than AGENTs, and it is easier to see on ordinary software first.

1Start wide: the parties around any software

Take any user-facing software: an application bought and installed, a web service open to the public, a mobile app from a store, the firmware in a device. Before a line of it runs, six kinds of party are attached to it, and a technical reader will recognise every one of them from an ordinary architecture diagram. The law does not see the architecture. It sees the parties, and each statute names one of them as the party it binds, and names another as the party it protects.

Figure 1. One piece of software and the six groups of parties around it. Somebody makes it, somebody distributes it, somebody runs it, somebody uses it, it talks to other people's systems, and somebody oversees the whole arrangement. Every group is a hook a different kind of law reaches through.

The table under the figure says what each group does and the kind of law that tends to key on it. The examples are deliberately everyday. None of them needs an AGENT to be true.

Party	Who is in it	What the law tends to ask of, or about, them	An everyday example
1MAKER	The developer or publisher whose name is on the product; the provider of a model behind a feature; the suppliers of libraries, kits and tool interfaces; open-source projects whose code was taken in without a contract.	Product safety and product liability; the duty to document what was built and to fix what is found; copyright and licence terms on what was taken in; export rules on some components.	A vulnerability in a library the product ships has to be patched and, in some places, reported on a clock.
2DISTRIBUTOR	The app store or marketplace that lists it and takes a cut; the importer that brings it into a market; the reseller or channel partner; the integrator that installs and configures it for a client.	Market-access rules (who may place a product on a market, and what mark it carries); store policies with the force of contract; the duty to pass warnings and notices along the chain.	An app is pulled from a store for a privacy-label mismatch, and the publisher learns of it from the store, not from a regulator.
3OPERATOR	The OPERATOR that runs it for its customers; a customer that runs a bought copy on its own servers; the hosting and cloud provider that holds the data and the compute; the payment, advertising and analytics services on the request path.	Data protection, with the OPERATOR usually the party that decides why data is processed and the hosting provider the party that processes it under contract; security duties; consumer protection for what the service promises.	A support ticket contains a customer's medical detail, and three companies now hold a copy: the OPERATOR, its cloud, and its ticketing vendor.
4OVERSEER	Regulators and courts, which enforce, fine and enjoin; auditors and certifiers, which attest to a standard; standards bodies, which write what an audit checks; platform rule-setters such as device makers and store operators, whose rules bind by contract.	The duty to keep records that an OVERSEER can read; the duty to report incidents; registration, audit and certification where a sector requires it.	After an outage, the question a regulator asks first is not what failed but what the log shows.
5USER	The USER, who is the principal the software acts for; the affected person, who is reached by the software's output without being its USER; the data subject, whose personal data flows through it; a minor, who is a USER the law treats differently.	Consent, notice and the right to object; the right to a human decision in some cases; age rules; unfair-practice rules on how the interface behaves toward the person in front of it.	A USER uploads a group photo. The USER consented to the upload; the four other people in the photo did not consent to anything.
6COUNTERPARTY	The sites and interfaces it reads, which are other people's servers; the recipients it writes to by email, text, post or form; the rightsholders whose content it uses; other USERs and devices it exchanges data with.	Computer-misuse and access law on the COUNTERPARTY's machine; the COUNTERPARTY's terms; copyright and database rights on what is read; outreach rules on what is sent, and to whom.	A price-comparison feature fetches a retailer's page a thousand times an hour, and the retailer's terms said it could not.

2Same code, three shapes, three sets of roles

The parties in Figure 1 are not fixed to the code. They move with the way the code is shipped. The same product, sold as an installed package, run as a public web service, or published as a mobile app, puts different organisations and people into the same six parties, and the duties follow the party rather than the code.

Party	Installed or purchased product	Public web service	Mobile app from a store
MAKER	The vendor, plus its component suppliers	The OPERATOR's own team; often the same company that runs it	The publisher, plus the platform's own kits it must build on
DISTRIBUTOR	A reseller, a channel partner, an integrator; an importer if it crosses a border	Nobody in between: the web is the channel	The store, which reviews it, lists it, and can remove it
OPERATOR	The customer, on its own servers or its own cloud account	The OPERATOR, on rented cloud, with payment and analytics vendors on the path	The publisher's backend, plus the USER's own device, which runs half the product
USER	The customer's staff, under an employment relationship	The public, including people the OPERATOR has never identified	The public, including minors, with the device reporting who and where they are
COUNTERPARTY	The customer's other systems, inside its own perimeter	Third-party interfaces, other people's sites, a payment processor	Device sensors, other apps, the platform's own services, and the same web
OVERSEER	The customer's auditors and its sector regulator	Consumer and privacy regulators, and courts	The store's review process first, then the same regulators

Read down any column and the legal picture changes without a line of code changing. In the first column the party that runs the software is the customer, so the customer holds the data and answers for it, and the vendor's duties are about what it built. In the second the MAKER and the OPERATOR are one company, and every duty lands there. In the third a store sits between the MAKER and the USER with rules of its own, and the USER's device is itself part of the product. A team that knows which column it is in already knows which of the six parties it is, and which it is not.

3Where a party is matters as much as who it is

The rule in one line

A USER's location at the moment of use matters as much as their residence, and both matter as much as their identity. The same is true of every other party in the figure.

Each party in Figure 1 also has a location, and the law reaches a party through where it is. The same USER is a different legal situation in two cities: the rules on what they must be told, what they can consent to, and what may be inferred about them differ by where they are sitting when they use the software, and again by where they live. The same is true of the site the software reads, which is somebody's machine in some country; of the company that made the model behind a feature, which sold it into some market; and of the OPERATOR, which is incorporated somewhere and serves customers somewhere else.

Ordinary software mostly resolved this once. The company and its servers were in one place, the customers were in a known set of places, and the answer was worked out at launch and written into a policy. The later documents give the statutes that hang on each hook. Here the point is only that every party in the figure carries a location, and location is an input to the question, not a detail of the answer.

4Now put an AGENT in the middle

An AGENT is not a new kind of party. It is software that acts: it plans, calls tools, reads and writes, and takes steps toward a goal it was given. It acts in the OPERATOR's name, for the person who asked, against other people's systems, and it has no legal role of its own. Every statute that reached one of the parties in Figure 1 still reaches that party in Figure 2. What is new is reach: a single task touches parties that ordinary software touched one at a time, if it touched them at all.

Figure 2. The same six groups, with an AGENT in the middle. Under each group's name is what the AGENT does to the parties in it. Every line out of the centre is an interaction, and every interaction is a fact the law turns on.

The table below takes seven ordinary AGENT tasks and says which of the six parties each one touches. The right-hand column is written as questions, because at this stage they are questions: the next documents say which statutes ask them and where.

AGENT Task	Parties it touches	The legal questions that follow
Answer a customer's support question from the company's documents and send the reply by email	USER (the customer as principal) · COUNTERPARTY (the mail recipient, the documents read) · MAKER (the model provider sees the customer's message) · OPERATOR (the OPERATOR's mail and ticketing systems)	Does the customer have to be told the answer came from a machine? Where is the customer? Did the customer's message, with whatever it contained, go to a third party's model, and where is that provider? What does the sent email have to say about who sent it?
Compare prices across five retail sites and buy the cheapest one with a stored card	COUNTERPARTY (five COUNTERPARTYs' sites and their terms; a payment processor) · USER (the principal's money and consent) · OVERSEER (who made the contract, and whether it binds)	Did any of the five sites forbid automated access in its terms, and does that matter where the site is? Who is the buyer in the contract the AGENT formed? What can the USER undo, and by when?
Screen four hundred job applications and shortlist twenty	USER (the applicants are affected persons, not USERs) · OPERATOR (the employer as OPERATOR) · MAKER (what the model was trained on) · OVERSEER (employment regulators)	Is this a decision about a person made by a machine, and where does each applicant live? Do the applicants have to be told, or given a way to contest it? Does anyone have to test the tool for bias before it is used, and publish the result?
Book travel for an employee with a corporate card, passport details included	COUNTERPARTY (airline and hotel interfaces) · USER (the employee as principal and as data subject) · OPERATOR (the employer as OPERATOR) · DISTRIBUTOR (the booking platform's terms)	Whose passport data just crossed which border, and under what arrangement? Is the employee a USER or a subject here, or both? Which party is responsible if the booking is wrong?
Draft and post a reply on a social network in the user's name	USER (the principal whose name is on the post; every reader is an affected person) · COUNTERPARTY (the platform and its rules) · OVERSEER (platform rule-setters)	Must the post say it was machine-written, and to whom? Does the platform's own policy on automated posting bind the USER, the OPERATOR, or both? Who is speaking, in law, when the post is defamatory?
Fill in a government form on a public portal for a USER	COUNTERPARTY (the portal is a COUNTERPARTY, with its own terms and its own access rules) · USER (the USER as principal and data subject) · OVERSEER (the agency, which may have rules on who may submit)	Does the portal permit submissions by software at all? Who signed the form? What record has to be kept of what was submitted on the USER's behalf?
Read a USER's inbox and calendar to plan their week	USER (the principal, and every correspondent in the inbox as a data subject, some of them minors) · MAKER (the model provider, again) · OPERATOR (where the plan and the copies are stored)	The USER consented; did the people who wrote to them? What was retained, for how long, and where? What did the AGENT infer about the USER that the USER never said?

The AGENT did not remove any party from the picture. It added arrows. So "which law applies to this AGENT" is really "which parties does this task touch, where are they, and what does the law ask of each", and that has to be traceable through the AGENT's interactions.

5What traceable means, in practice

A law that binds the OPERATOR because of where a USER is cannot be applied unless something recorded where the USER was. A duty that attaches to what the AGENT said to a person cannot be discharged unless the fact that a machine produced the words survived the trip from the model to the screen. A rule about the COUNTERPARTY's terms cannot be honoured unless the AGENT knew which site it was reading. In each case the law asks a question about one arrow in Figure 2, and a system that cannot say which arrows a task drew cannot say which law applied to it.

For an engineer, that turns into three habits, none of which needs a lawyer to start:

Name the parties per task, not per product. A product touches all six groups over its life; a task touches a few. The unit the law reasons about is the task.
Record where each party was. The USER's declared location, the COUNTERPARTY's domain, the destination of every call, the provider behind every model. These are the facts every later document keys on, and they are either on the wire at the time or gone.
Keep the arrow. An interaction that seemed harmless when it happened may be the one a duty attaches to later. The record of what the AGENT did, for whom, and with what authority is the evidence layer every OVERSEER in Figure 1 will ask for.

6What this document is not

It is a vocabulary, not a legal analysis. It names no statute and makes no claim about which law binds any particular system. The document that follows, Global AI law: 8 common threads, supplies the statutes and the jurisdictions, and the theme register lists what the law says under each of a governance working group's themes, with the party each duty binds and the hook it reaches through.