If your AI agent's governance is a sentence, it is probably this one: "Someone reads everything before it goes out." That sentence is real and worth keeping. It is also one control out of five, and it only sees what the agent writes, not what it read or what it reached to get there. When an agent fails in production, the report we worked from argues, the cause is often something that happened while it was running: an instruction hidden in an email it read, a tool it should not have had, a file that went stale, a loop that kept spending. A policy written in advance does not stop any of those. Controls that act during the run can.
What AI governance means at your size.
AI governance, at the size of a small business, is the set of controls that keep an AI agent inside the limits you meant to give it while it is running. The report we worked from names five: trusted data (the agent reads from an approved, current source), access controls (it never holds more access than the person it acts for), guardrails (actions are checked before they happen, not only the text after), human escalation (sensitive or ambiguous cases leave the automatic path and go to a named person), and continuous monitoring (tests and alerts tied to a way to roll back). Policy still matters, because it says what the limits are. But the report calls the runtime layer, where those limits are enforced, "the least appreciated layer and one of the most important,"[1] and for a team of fifteen it is the part worth building first.
Five layers, one does the work.
The report draws governance as a stack of five layers, each with a different job.[1] Large organisations staff each layer with a team. A small business needs each layer to exist in its smallest working form, which usually means a page, a setting or a habit, not a product. The third line of each band below is our translation to that size.
Read the stack from the middle. Layer 1 says what is allowed. Layers 3 to 5 make sure the model, its inputs and the machinery underneath are what you think they are. Layer 2 is where an action is actually stopped, held for a person, or let through. A business can have a good policy and a locked-down server and still have an agent that sends a refund nobody approved, because nothing sat between the decision and the action.
Five controls, sized down.
The report then names five controls that cut across the layers.[1] Each comes with what it is meant to guarantee and the way it usually fails. We kept the failure modes, which are the most useful part, and wrote the smallest version of each that we would accept as present in a business of fifteen.
| control | the smallest version that counts | how it usually fails |
|---|---|---|
| 1 Trusted data | The agent reads from one named source with an owner, and its copy is refreshed on a schedule. When the source changes, the agent's copy follows. | A one-time export into a folder the agent searches, stale from the next day. The report's name for it: "shadow RAG" (RAG: an agent that searches your documents before it answers). |
| 2 Access controls | The agent runs under its own login, scoped to what the task needs and never wider than what the person it acts for can see. Every run is logged. | The agent runs on an admin or shared account, so it can read everything the owner can. |
| 3 Guardrails | A check before each action (is this tool allowed here, are its arguments in range) as well as a check on the text the agent writes. | One filter on the output and nothing on what the agent is about to do. |
| 4 Human escalation | A written list of what leaves the automatic path (money, complaints, anything legal, anything ambiguous), routed to a named person with enough context to decide. | Only disasters reach a person, or the case arrives without a record of what the agent saw. |
| 5 Monitoring | A handful of test cases rerun after every change, and an alert that reaches someone when a run fails or costs more than it should. | A dashboard nobody opens, no alert, and no link to rolling back. |
Two of these deserve a second look because small businesses get them wrong in opposite directions. Access control is the easiest to skip: the fastest way to connect an agent is to give it the owner's login, and the agent then inherits every folder, mailbox and bank export the owner can open. The report puts the rule plainly: one failure is "granting the agent more access than the human user it represents."[1] Guardrails, by contrast, are usually present but pointed at the wrong thing. A filter on what the agent writes catches rude replies. It does not catch a well-worded tool call that sends the wrong amount to the wrong supplier. The OWASP list of risks for AI applications names that second failure "Excessive Agency," and it ranks prompt injection first.[3]
One property manager, scored.
Picture a residential property manager in Sherbrooke with fifteen people and a few hundred units. It runs one agent. The agent reads tenant emails, drafts replies, opens maintenance work orders, and looks things up in the tenant files to answer questions about leases and payments. The owner describes the setup as governed, because every reply waits for the office manager before it goes out. Here is how its five controls score.
The owner is right that escalation is in place. The office manager reads every reply, and the written rule sends anything about money, complaints or the Tribunal administratif du logement to the owner. That is a real control. The trouble is what it cannot see. An approval step checks what the agent says. It does not check what the agent read or what it was able to reach. The agent answers lease questions from a copy of the tenant files exported in March, so a tenant who renewed in June gets a reply based on the old lease, and the office manager has no reason to doubt it. Former tenants' files are still in that folder, months after anyone needed them (Quebec's privacy act expects personal information to be destroyed or anonymized once its purpose is achieved, s. 23). And because the agent runs on the owner's admin account, a cleverly written email asking it to "summarise the payroll folder" meets no wall. Whether the office manager catches the reply depends on how busy the afternoon is.
None of the fixes is expensive. A separate login for the agent, limited to the tenant files and the work-order system. The export replaced by a direct read from the property management software, or by a nightly refresh that drops former tenants. A check on work orders before they open (a known unit, a known supplier, an amount under a set limit, anything else held for a person). A few test emails rerun after each change, a weekly look at the logs, and one alert when a run fails. None needs new software, and most are a setting rather than a project. Together they move this business from one control in place to five.
The order to build them in.
The report's advice on sequencing is the part we agree with most: "gateway first, then observability/evals, then metadata/access, then broader governance automation," and not "buying a giant platform before stabilizing your runtime surface."[1] A gateway, in a large company, is software that every call to an AI model passes through, so that routing, keys and spending sit in one place. At small scale, the same idea is simpler: one door per agent.
One door means each agent has its own account or key with the model provider, never a key shared across tools, and a spending cap where the provider offers one. That alone gives you three things: you can see what each agent costs, you can switch one agent off without touching the others, and a runaway loop hits a ceiling instead of your card. Seeing and testing comes next because every later control depends on knowing what the agent actually does; our six-line eval suite is the smallest version we know. Access and data come third, once you know what the agent needs, which is the only honest basis for scoping its login. Our note on splitting an agent's reads from its writes is one worked case of that step. Tooling comes last, if at all. Our build order for production agents applies the same logic to a single agent.
Does Law 25 apply to an AI agent?
Not by name. But once an agent touches personal information, the duties in Quebec's private-sector privacy act, as amended by Law 25, apply to the business that runs it, and several of them are these controls.[4] The statute does not mention AI agents, so how each section applies to one is a reading, ours, and a question for your own counsel. These sections line up with the layers and controls.
- Someone already owns it (s. 3.1). The person exercising the highest authority in the business is, by default, the person in charge of protecting personal information. That person's title and contact details must be published on the business's website. In a business of fifteen, the policy layer has an owner whether or not anyone has written the policy.
- Access is need-to-know (s. 20). Employees and agents (the statute means people acting for the business) may access personal information without consent "only if the information is needed for the performance of their duties." The rule was written for people. It is hard to argue that software doing an employee's task needs more than the employee does, which is the access control in figure 2.
- Data used for a decision must be current (s. 11). A business must ensure that personal information is "up to date and accurate when used to make a decision in relation to the person concerned." An agent answering lease questions from a March export is the trusted-data control failing in exactly that way.
- A new system gets an assessment (s. 3.3). A privacy impact assessment is required "for any project to acquire, develop or overhaul an information system or electronic service delivery system" involving personal information. An agent that reads and writes tenant files looks a lot like one. The act scales the assessment to the sensitivity of the information, what it is used for and how much of it there is.
- Leaving Quebec gets an assessment too (s. 17). Before personal information is communicated outside Quebec, including to a provider that processes it on your behalf, an assessment and a written agreement are required, and the information may go only if the assessment concludes it would be adequately protected. Where your model provider and your search index run is a governance question; our note on running AI on your own hardware covers it.
- Automated decisions come with a person (s. 12.1). A business that renders "a decision based exclusively on an automated processing" of personal information must tell the person, explain on request the information used, the reasons and the "principal factors and parameters" behind the decision, and their right to have that information corrected, and give them the opportunity to submit observations "to a member of the personnel of the enterprise who is in a position to review the decision." That applies after a decision, and only when no person took part, so it is not escalation before the agent acts. It is the nearest the statute comes to it, and a written escalation list is the simplest way to keep a decision from being exclusively automated.
- A leak is an incident with duties (s. 3.5). A business that has cause to believe a confidentiality incident has occurred must take reasonable measures to reduce the risk of injury and prevent another, and where there is a risk of serious injury, notify the Commission d'accès à l'information and the people concerned. Monitoring is how you find out in time.
The standards behind it.
The report anchors its stack on a handful of standards and says the layers map onto them. That mapping is the report's own, not a certification path, but the standards are real and two of them are worth an owner's time.
NIST AI Risk Management Framework 1.0. Released by the US National Institute of Standards and Technology on January 26, 2023, for voluntary use, and free to download.[2] Its four functions (Govern, Map, Measure, Manage) are a useful checklist for whether you have thought about a system before, during and after deploying it. NIST says it is being revised. If you read one standard, read this one. The OWASP Top 10 for LLM Applications (2025 edition) is the practical complement: ten named failure modes, from prompt injection to unbounded consumption, each with mitigations.[3] It is the closest thing to a test plan for guardrails.
ISO/IEC 42001 is the certifiable international standard for an AI management system; ISO/IEC 23894 is guidance on AI risk management. Both are paid documents written for larger organisations; we have not read them, and we name them only because the report maps to them. The EU AI Act sets duties that scale with risk, including human oversight for high-risk systems and transparency for some others, and it can reach a business outside the EU whose AI output is used there. For a business selling only in Quebec it is background, not the first thing to read.
Where we apply it ourselves.
Two examples from our own operations, both on the runtime layer, and one is weaker than we would like. The agents that draft our outbound email can stage a draft in the mailbox. The tools that would send it are set to ask a person for approval on every call, and that setting sits outside the agent, where no instruction can talk it past. The agents that draft these field notes write to a working branch of this site's code, and a person merges the result after reading it. That second gate still rests largely on the pipeline's instructions plus automated build checks, which is the kind of control an agent can be talked out of, so it is next on our own list. That is the distinction our note on auditing an automation by reading one file draws: what an agent may reach belongs in its access grants, not in its prompt.
What to do this week.
- List every agent and automation that uses AI.
One line each: what it does, whose login it runs on, what it reads, what it can change. If nobody can fill in the login column, start there.
target: one page, every agent - Give each agent its own door.
Its own account or key with the model provider, never shared, and a spending cap where one is offered. You can now see its cost and switch it off alone.
- Score each agent on the five controls.
Use the minimums in figure 2: 0 if missing, 1 if partial, 2 if someone could show it to you today. Be suspicious of any agent whose only 2 is "a person reads it."
target: five scores per agent, the zeros named - Fix access first if it is a zero.
Move the agent off any admin or shared account onto its own login, scoped to what the task needs. It is the gap no approval step can see.
- Write the escalation list down.
What always goes to a person, and which person. Money, complaints and anything legal are the usual start. If an agent makes decisions about people on its own, check the section 12.1 duties with counsel.
- Read NIST's framework before buying anything.
It is free. Software that promises to govern your AI comes after you know what your agents do and what they can reach.
What this does not claim.
The source is an AI-generated synthesis. The five layers, the five controls and the build order come from a research report produced with an AI tool. We have used its structure because it is coherent and matches how we run our own agents, not because it has been validated. Its in-text citations could not be traced to pages, so none of its figures, case studies or prices appear here, and the way it maps controls onto NIST, ISO and the EU AI Act is its own.
Not a compliance programme. Five controls in place do not make a business compliant with Law 25 or with any standard. They make an agent harder to misuse and easier to explain. The privacy duties described above are partly quoted from the statute and otherwise described in general terms; applying them is a matter for counsel.
Illustrative example. The property manager, its agent and its scores are ours, built to show how a business can hold its best control and miss the two it cannot see. They are not a measurement and not a client record. The two examples from our own operations describe how our pipeline works today, including the gate we have not yet moved out of the instructions.
If you would like a second pair of eyes on how your agents score, send us the list through the contact form. Finding the zeros, fixing access first, and deciding what can stay as it is, is what our automation audit is for.