An AI agent that answers a customer, approves a claim or files a document does those things for the company that runs it. Air Canada argued otherwise in 2024, after its chatbot gave a customer wrong information about a bereavement fare. A Canadian tribunal replied, in Moffatt v. Air Canada: "This is a remarkable submission." And: "It makes no difference whether the information comes from a static page or a chatbot."
Most of the law an agent meets is like this: written before agents existed, already in force, and indifferent to how the software works. That is why we pair engineering depth with technology law expertise. The rules an agent acts under decide parts of its architecture, and they are cheapest to build in before that architecture exists.
The rules exist before the agent does
They come from three places.
The law. The GDPR gives a person "the right not to be subject to a decision based solely on automated processing" when the decision has legal or similarly significant effects for them (Article 22), and it requires a company to "be able to demonstrate compliance" with the regulation's principles (Article 5). Sector rules add their own, such as DORA for financial entities. The EU AI Act adds duties that depend on what a system is used for, which we come back to below.
The company's contracts. What it has promised its customers and partners: the terms a customer bought under, confidentiality clauses, data processing agreements. And what it has accepted from its suppliers: a model provider's terms on where data is processed and how long it is kept, and the licence of every open-source component in the system.
The company's own policies. Who may approve a payment, what may be promised to a customer, how long a record is kept.
None of this is new to the company. What is new is software that acts under these rules with more freedom than earlier software had: an agent chooses its own steps.
A rule in a prompt is a request
The first idea in most projects is to write the rules into the agent's instructions. That turns each rule into a request to a language model, and a model does not behave the same way every time. Atil et al. configured five models for deterministic output, and their accuracy still varied by up to 15% between runs of the same tasks. An agent also reads text that nobody on the project wrote, such as an incoming email or a web page, and that text can carry instructions of its own.
Security practice has already drawn the conclusion. OWASP's guidance on excessive agency is to "implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not".
The same holds for every rule that matters. It has to become a control: something outside the model that checks, stops or hands over to a person, and that leaves a record.
Illustration of how rules become controls for an agent that handles customer claims. Three rules are written down. A clause of the customer terms, a line of the company's data policy and Article 22(1) of the GDPR. A first run refuses a claim and passes all three rules without being checked, stopped or recorded. Each rule then becomes a control on the run. Answers are checked against the clause they cite, the agent's tools can only reach approved hosts, and a refusal is decided by a person. The same run is repeated. Its answer is checked against the terms, one call to an unapproved host is blocked, and the refusal waits until a person confirms it. Each of the three controls leaves an entry in the record.
From a rule to a control
This translation is where legal expertise does its work in a build: reading a rule for what it requires of a system, and stating that so an engineer can implement it and a test can check it. The result is the three properties we build every agent to have.
Verified. A company answers for what its agent tells people. Moffatt is one tribunal's decision and binds no court in Europe, but its reasoning is ordinary: the tribunal found that the airline had not taken reasonable care to make sure its chatbot was accurate. In the system, that becomes an answer that cites the clause it relies on, a check that the clause says what the answer claims, and evals that measure how often this holds.
Constrained. A confidentiality clause or a data processing agreement says where data may go, and a policy says who may approve what. In the system, that becomes a list of the hosts the agent's tools can reach, enforced outside the model, a model provider and a processing region chosen to fit the contract, and permissions that leave out everything the task does not need. An agent that has no tool for making a payment cannot be talked into making one.
Governed. Where a decision about a person may not be left to software alone, a person has to make it, and the law is specific about what that means. The EU data protection authorities' guidelines on Article 22 say that human oversight has to be "meaningful, rather than just a token gesture", carried out by "someone who has the authority and competence to change the decision". The EU Court of Justice has been as strict about where a decision is made: in SCHUFA (2023), a credit score calculated automatically counted as an automated decision in itself, because the lender that received it "draws strongly" on it. In the system, that becomes a checkpoint that holds the decision, shows the reviewer the evidence the agent used, and lets them change the outcome. An approve button under a result nobody reads does not qualify.
Each control also leaves a record: which clause an answer cited, which call was blocked, who decided and when. That record is what being able to demonstrate compliance looks like in practice.
Knowing what does not apply
The other half of the work is scope. Reading a rule precisely includes reading where it stops.
The EU AI Act is the current example. Its heaviest duties are for high-risk systems, and a system is high-risk because of what it is used for: the uses listed in Annex III include recruitment, credit scoring and access to essential services. An agent that reviews supplier contracts or prepares invoice documentation is not among them. Most of those duties are on the provider of the system, not on every company that uses one, and since the amendment of July 2026 they apply from 2 December 2027. Nor is the Act part of Norwegian law yet: the government's stated aim is to put the Norwegian AI act before the Storting in spring 2027.
The same Act shows why scope cannot be read once and filed. A company that changes the intended purpose of an AI system so that it becomes high-risk is treated as its provider (Article 25(1)(c)). Pointing a general-purpose assistant at job applications can be such a change. And some duties do not depend on the risk class at all: a system meant to interact directly with people has to be built so that they "are informed that they are interacting with an AI system" (Article 50(1)).
A team that cannot tell where a rule stops can go wrong in two directions. It can build for duties that do not apply to its agent, or miss ones that do. The first is work that nobody required. The second is a system that has to be rebuilt when the gap is found.
Where it shows up in a build
- Scoping. Who the agent's results affect, which decisions it makes or prepares, what data it reads and under which contracts, and what its intended purpose is. Open questions go to the company's counsel while the answers can still change the design.
- Architecture. Permissions, data flows, the choice of model provider and region, and the points where a person decides.
- Evals. A rule that must always hold becomes a case in the eval suite and a condition of the release gate, so a change that breaks it does not ship. Our post on evals covers how such a suite is built.
- Operation. An audit trail that legal and compliance staff can read without the engineers who built the system.
The open-source tools we maintain reflect the same approach: tethered restricts which hosts a Python application can connect to, and licenseal checks the licences of a dependency tree before a release.
What it does not replace
We are an engineering company, not a law firm. We do not give legal advice, and this post is general information. Whether a rule applies to a particular system, and what it requires there, is for the company's own counsel to decide.
What legal expertise on the engineering side changes is the conversation with counsel. The questions arrive early and are specific to the system, and the answers end up in the system as checks, permissions and records, not in a memo written after it is built.
That combination has been in the agency from the start: our founder, Sergii Shcherbak, has worked as a technology lawyer (LL.M. in Law and IT, Stockholm University) as well as an AI engineer.
Questions to ask
Whether you build an agent yourselves or buy one, these questions show whether the rules were part of the design.
- Which rules are enforced by code, and which are only written in the prompt?
- Which of the agent's decisions affect a person, and who can change them?
- Where does the data go, and which contract covers each place?
- What record is there of what the agent did, and can your compliance team read it?
- What is the system's intended purpose, and is that use on the AI Act's high-risk list?
- When was your counsel asked, and what changed in the design afterwards?
We pair engineering depth with technology law expertise, so every agent is built to be verified, constrained, and governed.