Everyone is talking about the AI Act. We're talking about governance.
The last article was about the maturity required before signing with your first agent. It ended with a question that sounds more innocent than it actually is: Who actually reviews what the agent produces?
That’s exactly where readiness ends. And that’s where governance begins.
Governance sounds like a set of rules
When people hear that word, most think of guidelines, approval matrices, and a PDF that no one ever opens. In practice, it all comes down to three questions:
Who assigns which agent to which task? Who reviews the results before they leave the office? And where do they go if something goes wrong?
If the team’s answers are the same, governance already exists—even without a single document. If they differ, even the best set of rules won’t change that.
At the AIC Group, we gradually realized this. First, a second subject area was added, then more tasks, more knowledge bases, and more people working with the agent. Each expansion on its own was small.
But with an agent, nothing stands on its own. A new knowledge file doesn’t just answer the new question—it interferes with the old ones. An additional rule can override an existing one without anyone noticing, until the first result turns out to be wrong. And the more people work with it, the less you realize that they understand it differently.
The real work involved in expanding, therefore, isn’t the act of adding. It lies in determining whether the new elements interact with what already exists and whether the guidelines from back then are still sufficient. That was the moment when a way of working had to become a mutual agreement.
Governance takes shape during construction, not afterward
We see two patterns time and time again. Some people want to have everything figured out first and therefore never get started. Others just dive right in—and there are far more of them. They do give some thought to who will be overseeing things and what the agent should avoid doing. But those thoughts stay in their heads. Six months later, no one remembers exactly what was agreed upon.
That's why we write it down during construction and not afterward. We have it recorded in three places.
During cutting. Anyone who clearly describes an agent’s role, task, and context has, in effect, already classified it. After all, it is not the system that determines the risk, but the intended use. The same language model is uncontroversial as an internal research tool but poses a high risk in the job application process. This can only be deduced from the question of what the agent is intended to do. Every sensible agent project begins with that question anyway. The AI Regulation thus formalizes here what governance means anyway.
At the guardrails. The System Prompt is where boundaries actually take effect. What the agent shouldn’t do, where to ask for clarification, when to hand things off: That’s all laid out there, not in an appendix to the project manual.
During optimization. An agent that has been running for a year rarely does the same thing it did on the first day. Tasks expand, new data sources are added, and someone comes up with an idea. The question is not just whether the output improves, but whether the purpose of the agent has shifted.
If there's more than one agent
What we experienced then is something that happens sooner or later in every project. It never gave any warning beforehand, and at some point, it’s no longer enough for just two people to know what was intended.
That's why we're putting three things in writing.
The Agent Map. It shows what’s happening where: which agents are involved, what sources they draw on, which teams they’re assigned to, and in what direction the whole thing is growing. We create it early on and keep updating it. For governance, it’s the most important tool because it helps answer questions that would otherwise remain unresolved. Who else besides this one agent accesses this source? What are the implications of a change that currently seems harmless? And if an agent is to be granted more access or more leeway: Is the purpose still the same as it was at the beginning? You can see this immediately in an overview. Spread across many individual documents, no one notices it.
The Agent Concept. One clear set of instructions per agent. It specifies the agent’s role, the tasks it supports, its limitations, who reviews and approves, and at what point you take responsibility for it yourself. Include the version number and date. It’s the only document that even someone who never works with the agent can understand: management, the data protection officer, the works council, or your successor on the team. Anything that’s only in the Prompt system is invisible to these people.
The overarching concept. As soon as multiple agents are required to work together, the individual plan is no longer sufficient. Who is authorized to do what, where does the handoff occur, and where does a human step in? We derive this from the individual plans. What was written down earlier pays off here.
As for the third point, we’re still in the early stages ourselves and are currently exploring what that might look like. One thing has been clear to us from the start: When agents work together that aren’t yet functioning properly on their own, their errors multiply. The maturity of the individual agents isn’t a preliminary step that can be skipped; it’s a prerequisite.
The Point That Remains
There’s one order of priority we don’t negotiate: governance before autonomy. First the guidelines, then the freedoms. If you do it the other way around, it works for a while, but then it doesn’t anymore.
In our day-to-day work, this means: The agent makes a suggestion, we confirm it, and then it’s carried out. This isn’t a rule set in stone, but rather the natural result of the sequence of steps. How much an agent handles on their own depends on their level of experience and the nature of the task. What must not change, however, is the order: First, we discuss and document what they’re allowed to do; then they’re given the leeway to act. Not the other way around, and not as an afterthought.
That sounds like a hindrance, but it’s actually the opposite. If you know someone is watching, you can deploy the agent sooner and more boldly. And once you’ve deliberately set the guardrails, you can consciously extend them later. Without them, any expansion becomes a nerve-wracking ordeal.
And then what?
Readiness determines whether the team can handle it. Governance determines who is responsible for what. That leaves the third question, and it’s the most uncomfortable one: Does this actually accomplish anything?
That’s what the next episode is about.
Write to us. We’d be happy to share our approach.