The LexLint Legal Handbook

Introduction: The 6 parties in AI law

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.

Read this if you are about to ask which law reaches your agent and want the question stated properly first.

You come away with a vocabulary: six parties, where each one is, and the questions an agent's task raises about each.

Where the parties are, and whose law that makes applicable

The server's location is the one fact almost no law turns on. Each body of law reaches an agent through where one of its parties is: the market a system was placed on, where its output is used, where a person lives or is sitting, where the operator is established, where the machine it read belongs. Which party, what counts as evidence of where they are, and what to do when nothing says.

Read this if you have to decide which places' law a run is under, and want the rule per body of law rather than a guess from an IP address.

You come away with the hook each body of law reaches through, the party it turns on, how far each source of location can be trusted, and the widening and unknown rules.

Global AI law: 8 common threads

What the AI laws in force around the world have in common, the unusual provisions that trip an agent, the older privacy, security and scraping law that already binds one, where the new law restates the old, and why an EU-compliant system still has twenty-seven national layers to read.

Read this if you build or run agentic software and need the law itself, in one place, with the statutes named.

You come away with what the AI laws in force share, the provisions that trip an agent, and the older law that already binds one.

The requirement register

Every requirement line the LexLint software-law corpus carries for AI, privacy, scraping and cybersecurity law, typed and dated, with the class of duty it belongs to, the party it binds, the territory it reaches through and what a runtime control can do about it. Tabulated by obligation class, and offered whole as a file.

Read this if you need the requirement lines behind a duty, by class, party or runtime tier, or the whole register as a file.

You come away with a reference: twenty classes of duty, each with what statutes require, whom they bind and where they reach, and the file behind it.

Does legal action really happen?

Enforcement actions, judgments and settlements, each starting from an ordinary product feature, with the primary source beside every figure: the evidence that these laws constrain software today, at every size of company.

Read this if you need evidence that these laws are enforced against software, with the figures and the sources.

You come away with cases, fines and settlements by product feature, the pace of enforcement, and what an agent should take from each.

What the law makes you constrain

Eight places a duty can land on a running agent: the model itself, the instructions it runs on, the safeguards around it, the tools it can reach, the environment it runs in, what watches it, the people accountable, and what it is built from. Each with the law that already asks for something there, and how much of it the corpus holds.

Read this if you are deciding what an agent may do at run time, and want the law behind each limit rather than a framework's list of them.

You come away with eight layers, the binding law that reaches each one, and where the corpus is thin enough that a framework is your only source.

What the law makes you able to show

Nine things an operator can be made to produce after an agent has acted: the traces, who acted, what it could reach, where a person was, what it made, what was done about it, when, what was fixed, and how long all of it has to last. The last is the one the law states in periods, and the corpus carries them.

Read this if you are designing the record an agent leaves behind, or have to produce one to a regulator, a customer or a court.

You come away with nine evidence classes, what binding law actually asks for in each, and the retention periods the corpus states.

What a tamper-proof log still cannot tell you

Agent traceability work has produced records that cannot be altered. It has not produced records that can say which law was in play, because the signal that would answer that is the one every privacy instinct says not to keep. The instinct is right about the raw signal and wrong about the field.

Read this if you are designing an agent audit record, or reviewing one, and need to know what it has to carry about where the people in it were.

You come away with why a record needs a jurisdiction field, what belongs in it, and the deployment step that silently fills it with the wrong answer.

How a runtime engine takes in legal constraint data

Agent deployments are converging on a proxy between the agent and its models, tools and other agents, evaluating a policy per call. Every one of those engines can decide a request, and none of them knows what the law asks. What a legal constraint looks like as data, how much of the law a request path can do anything about, measured, how the engine learns whose law is in play, the four shapes an integration can take, and the ceiling on what any of it may claim.

Read this if you build or operate the gateway, proxy or policy engine that agents run through, and want to load legal constraints into it.

You come away with a constraint as a record with a party, a hook and a tier; the measured share a gateway can enforce, detect or evidence; four integration shapes with their failure stories; and what a gateway must never claim.

What an open-source project owes the people who run it

Every open-source licence disclaims liability and the law binds the operator, so an open-source project carries little legal risk. The exposure it creates for the people who deploy it is another matter, and three questions follow for a project that already knows where that exposure is.

Read this if you maintain or govern an open-source project that agents are built from.

You come away with where a project's legal exposure really sits, and three questions with concrete things a project can ship.

The clocks an incident starts

Every reporting clock in the corpus that an incident involving an agent can start: the incident and vulnerability duties of cybersecurity law and the breach duties of privacy law, by jurisdiction, each with the sentence that carries the clock, and the Open Secure AI Alliance's proposed SAFE timeline drawn on the same scale.

Read this if an incident has happened, or you are writing the runbook for one, and need to know which reports are due, to whom and by when.

You come away with a reference: the statutory clocks by jurisdiction, the sentence each is read from, and where a voluntary timeline sits among them.

Incident command: from the facts of an incident to the notices that are due

The clocks document lists every reporting deadline an incident can start. Which of them your incident actually starts turns on a small set of facts: what kind of event it was, where the affected people live, and when you became aware. This document is the method: the facts, the three states a clock can be in, how to read the conditions inside a clock sentence, and what to record so the answer can be defended later.

Read this if an incident has happened, or you are writing the runbook, and you have the clocks in front of you and need to know which ones run for this event.

You come away with a fact pattern of eight questions, three states with no clock ever hidden, the rule for a sentence that names a judgment standard, and a record that is a fact rather than a conclusion.

When the operator is a public body, the report is a public record

A water utility, a transit agency, a public hospital or a ministry that runs an agent holds its incident report, the notices it sent and the notices it received as public records. Under most public-records acts a record is released on request unless an exemption covers it, on a deadline counted in days. Which grounds the acts carry, whether the body must or may withhold, how fast it has to answer, and what that means for the body, for its vendor and for anyone who sends it an alert.

Read this if you build or run an agent inside or for a public body, you are the vendor whose report lands in one, or you send incident alerts to one.

You come away with which of five withholding grounds the world's records acts carry and how often, the response deadlines beside them, and the one rule: write the report assuming it will be read.