The LexLint Legal Handbook

Introduction: The 6 parties in AI law

In law, a party is a person or organization 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 jurisdictions' 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 a system built to the EU rule 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 law library 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, with a sample offered as a file.

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

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

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 LexLint law library 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 and the binding law that reaches each one.

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 LexLint law library 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 law library states.

What a tamper-proof log still cannot tell you

Agent action records are now built so that nobody can alter them. They are not yet built to 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 gateway 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 gateways 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 gateway 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 license 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.

Reporting clocks: the deadlines an incident starts, and how to read them

An incident involving an agent starts reporting clocks in the law of every jurisdiction where the affected systems and people are: the incident and vulnerability duties of cybersecurity law, the breach duties of privacy law and the serious-incident duties of the AI laws. This document says what a reporting clock is, which families of law set one, how a deadline is read from the sentence that carries it, and what the clocks ask of an agent. The clocks themselves, every one in the LexLint law library on one time axis with its sentence beside it, are the clocks page.

Read this if an incident has happened, or you are writing the runbook for one, and you want to understand the clocks before you read them.

You come away with what a clock is and where it starts, the four families of law that set one, seven notes on how a rung is read from its sentence, and the record an agent has to keep for every report.

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.