AI agent governance:
permissions, approvals, records and evals.

A chat assistant answers a person, and the person decides what to do next. An agent reads your systems, takes steps and writes back. A policy document can’t reach that layer. The controls that hold are set in the platform the agents run on, per agent and per workflow, before anything goes live.

Company-wide AI governance still matters: which tools are allowed, which model providers you trust, how people are trained. This page covers the part that is specific to agents, where software takes actions on the company’s behalf.

This is least privilege, applied to agents. Set permissions per agent and per job, not per user account. Separate reading from writing, and scope both: one territory, one entity, one set of fields. An agent that prepares meetings needs to read the CRM. It doesn’t need to edit deal stages.

Avoid giving an agent a person’s login or open access to a computer or browser. Once you do, you can no longer say what it is able to do. Instructions in a prompt can be misread. A tool the agent doesn’t have can’t be misused.

A useful test: if this agent gets it wrong in the worst way its tools allow, what happens? If the answer isn’t acceptable, narrow the tools rather than adding another rule to the prompt.

Human in the loop works when it is placed by consequence, not spread everywhere. Ask three things of each step. Can it be undone? Does it leave the company? Does it decide something about a person? A step that can be undone, stays inside the company and decides nothing about a person can usually run on its own.

Too many approvals train people to click yes. Put them where a person adds judgement, and show the evidence with the request so the reviewer can check it in a minute.

For every run, keep the inputs, the sources the agent used, each tool call, the output, the version of the agent or workflow and who approved what. That is what lets you answer the question that always comes up after something goes wrong: what was the agent doing when it did that?

Records also make fixes safe. When a result falls short, you can see which source or rule caused it, change it and check the change against the same cases. On the EU side, deployers of high-risk systems must keep the logs those systems generate for at least six months (Article 26 of the AI Act).

Agents drift because the company changes under them: sources move, products change, models get updated. Evaluations are how you notice. Build them from real examples of the work with agreed answers, including the messy cases and the ones where the right outcome is to stop and ask a person.

Measure four things on every piece of work an agent takes over: quality, cost, time and human effort. Run the evaluations before every change and keep them running on the work in use. More in agree the standard before you build, and on putting numbers to it in how to measure the ROI of AI agents.

Treat a change to an agent’s instructions, tools or workflow like a change to code. Show it in full, run the evaluations and only then put it live. Each run should record which version it used, so a result can always be traced to the setup that produced it.

Agree data handling before you start: where the platform is hosted, which model providers are used, what they retain and whether anything is used for training. On Ortelian, the platform is hosted in the EU, agents use models with zero data retention only, and you own your data and world model and can export both.

This is not legal advice. For most B2B agent work, such as research, CRM upkeep, meeting prep and planning support, the AI Act asks little. Two duties already apply to everyone. Since 2 August 2026, AI that talks directly to people has to say it is AI unless that is obvious, and generated content has to be marked (Article 50). Companies also have to take measures for the AI literacy of the people who use AI at work (Article 4, softened but not removed by the Omnibus).

The heavy duties are for high-risk uses, and in business work the main one is AI that decides about people at work: recruitment, promotion, task allocation, monitoring. The Digital Omnibus moved the start of those rules for Annex III systems to 2 December 2027, as the European Commission sets out. Deployers of a high-risk system then need, among other things, human oversight by a competent person, logs kept for at least six months and workers informed before rollout.

The controls on this page give you the records, the oversight and the evidence that this work depends on. They don’t make a system compliant by themselves, and they don’t replace a conformity assessment or a lawyer. Our note on what the EU AI Act asks of B2B companies covers the tiers, the dates and what we would do now.

Ortelian is a platform plus a forward-deployed team. We work on site not because our product needs it, but because your company does. Where an approval belongs, and which tools an agent should have, depends on how your work actually runs, and that only shows up when you sit with the people who do it. We set the controls with your team during the audit and the build, before anything goes live.

After launch, your team runs it or we keep running it for you. Either way, we host and operate the platform, and the evaluations keep running on the work in use. Your own agents can use the platform headless through the same scoped tools, and it plugs into ChatGPT Enterprise and Microsoft Copilot over MCP. We set that connection up for your workspace inside the engagement, so the same permissions and records apply.

To see the controls on real work, look at AI agents for sales, where meeting prep runs on its own and anything sent to a customer waits for approval, or AI agents for operations, where matched documents move on and exceptions go to a person with the evidence attached. For how this fits a full engagement, see what an AI-native deployment partner does. For what agents take on in each team, see AI agent examples by function.