Agent governance: owner, scope, permission, audit trail

A network of veterinary clinics in Brazil, 190 people, 14 locations — a mid-size Brazilian company (figures in Brazilian reais). Someone on the sales team set up, on their own, an AI agent that read the new-clients inbox and replied with a proposal. It worked for six weeks. In the seventh, the agent replied to an email that contained an animal's lab report — identified client data — and quoted parts of it in the reply sent to another recipient on the same thread.

Nobody acted in bad faith. What was missing was not ethics or technology: it was four fields filled in before turning the agent on. This piece is about those four fields. It is not legal advice — for how the law applies to your case, talk to whoever handles legal matters for your company.

01Governance without a committee #

NIST published version 1.0 of the AI Risk Management Framework (NIST AI 100-1) in January 2023. The document organizes the work into four functions: govern, map, measure and manage. It's voluntary, was written for organizations of any size, and has a virtue for a mid-size company: the 'govern' function is described as defining roles, responsibilities and documentation — not building new structure.

Whoever wants to formalize further has ISO/IEC 42001, published in 2023, which defines a certifiable AI management system, in the same spirit as quality and information security standards. For a 190-person company, getting certified is rarely the next step; using the control list as checklist inspiration almost always is.

02The four fields #

1. Owner. One named person, not a department. They answer for what the agent does, approve scope changes, and are the one called when it errs. If the name doesn't fit on one line, the agent doesn't go into production.
2. Declared scope. In one sentence: what the agent does, on which cases, and what it explicitly does not do. Include the stop condition — what it does when it hits a case outside its scope.
3. Minimum permission. Read access only to what the task requires; write access even narrower, and never to the final system of record without a check. The agent's account is its own, never a human administrator's.
4. Audit trail. A log per action: what triggered it, what was read, what was decided, what was changed, when, and whether there was human review. Without this there's no way to investigate an incident or prove compliance.

In the veterinary network's case, three of the four fields were empty, and the fourth — permission — was the personal account of whoever set up the agent, with access to the whole inbox. None of the four requires special software to exist. They require a decision before turning the agent on.

03Personal data, legal basis and residency #

The LGPD (Law 13,709/2018) governs operations with personal data in Brazil, and an agent that reads, classifies or replies using that data is processing it just like any other system. Three practical consequences, in operational language.

• Purpose and legal basis. Processing needs a specific purpose and a legal basis — contract performance and legitimate interest are the most common in a business context, and each has its own conditions. Using data collected for service in a different purpose is the most frequent mistake.
• Sensitive data has stricter rules. The law defines specific categories, including health data and biometrics, with their own processing conditions. In a clinic, this isn't a detail: it's most of what flows through. The safe route is usually to keep that data out of the agent's scope.
• Where the data is processed matters. International transfer has its own requirements under the law. It's worth knowing, and putting in writing, which country the provider processes the submitted content in, whether it retains it and for how long, and whether it's used to train models.

Want to see how this looks inside a real operation? Explore the platform.

The ANPD is the authority responsible for enforcing and providing guidance on the LGPD in Brazil, and it publishes guidance materials. Following them is cheaper than discovering the interpretation in the middle of an incident.

04Checklist for whoever has no compliance team #

Eight lines. A one-hour meeting settles it for the first agent and becomes the template for the next ones. The cost of that hour is known; the cost of skipping it, in the veterinary network's case, was a disclosure to a client, an emergency access review and three weeks of stopped operations.

05What keeps this alive #

Governance written once and never revisited is a dead document. Two practices sustain it: a quarterly review of the agent inventory — which ones exist, who owns them, what changed in scope — and the rule that any permission change goes through the owner, always. Both fit into the routine of whoever already reviews access.

It's also worth logging scope decisions along with the reason. Knowing why an agent doesn't do a certain thing prevents the restriction from being removed six months later by someone who only saw the inconvenience, not the reason — the same decision-without-memory problem described in how to roll out AI across your company's processes.

At Relevanti, owner, scope, permission and per-action logging are part of how an agent is built, not a control bolted on afterward — see the platform, the breakdown by area in solutions, or bring your agent inventory to a conversation.

Agent governance is not a brake: it's what lets you expand scope without a scare. Whoever has the four fields filled in can say yes faster, because they know exactly what they're saying yes to.