Most business leaders I talk to about AI agents eventually arrive at the same question. They have heard the pitch, they understand the opportunity, and they are ready to move. Then they ask: “Who is responsible for making sure it does the right thing?”
The question usually gets handed to IT. Or to whoever is configuring the tools. Or to the vendor. And then, quietly, it does not really get answered at all.
That is a problem. Not because the technology is dangerous in some abstract sense, but because an AI agent without clear rules will fill the gaps with its best judgment, and its judgment is shaped by whatever instructions it was given, however vague. If the instructions were vague, the judgment will be too.
Setting the rules for your AI agent is not a technical task. It is a leadership decision. And most leaders are not yet treating it like one.
What Happens When Rules Are Missing
Here is a scenario that plays out more often than it should.
A company deploys an AI agent for client-facing communication. The agent is capable. It produces polished, confident output. Nobody defined which data it was allowed to use, so it uses everything it can access. Nobody defined what it must refuse, so it answers everything it is asked. Nobody required it to flag uncertainty, so it presents incomplete information with the same confidence as verified information.
Three months in, a client receives a response that contains details from another client’s account. Or a pricing commitment the business never agreed to. Or advice that falls outside the company’s area of expertise. The agent did not break any rule. No one told it the rule existed.
The business does not have an AI problem. It has a governance problem. And the governance problem started the moment someone decided those decisions were a technical detail rather than a leadership call.
The Decisions That Belong in Your Spec
Every agent spec should contain a governance section. Not as an afterthought. As a core part of the definition, written and reviewed before any configuration begins.
That section forces decisions on nine specific questions. These are not technical specifications. They are policy decisions.
What data is the agent allowed to use?
Approved public sources, specific internal documents, CRM records, all of the above? The answer determines the agent’s capability and its risk profile.
What data is the agent not allowed to use?
This is as important as the first question. If you cannot answer it, the first question is not really answered either.
What topics require the agent to refuse or escalate?
Legal matters, pricing commitments, personnel decisions, medical advice. Depending on your industry and your client relationships, this list may be short or long. It must exist.
Are the agent’s outputs advisory only?
Or does the output carry implied authority? If a client acts on what the agent says, who is responsible? That question needs an answer before the agent goes live, not after something goes wrong.
Is human approval required before any output is acted on?
For some workflows, yes. For others, no. The answer belongs in the spec.
What logging or audit trail applies?
If something goes wrong, can you reconstruct what the agent said, to whom, and why? This is not a nice-to-have. In many industries, it is a requirement.
What are the privacy limitations?
Can the agent access employee data? Client data? Sensitive internal financials? Each of these is a decision, and each decision has implications.
Why Leaders Avoid These Conversations
I want to be honest about why these decisions are often skipped.
They feel technical. The questions about data access and logging and escalation paths sound like they belong in an IT specification document, not a leadership conversation. So leaders defer to the people configuring the tools, who are often not in a position to make policy decisions.
Teams are impatient to build. There is genuine excitement around AI deployment right now, and governance conversations slow things down. Nobody wants to be the person who adds three weeks of documentation to what feels like a simple configuration task.
Nobody has failed visibly yet. Governance conversations are often driven by incidents. Before the incident, the risks feel theoretical. After the incident, the business is scrambling to add rules that should have been there from the start.
All three of these are understandable. None of them are good reasons to skip the conversation.
Why IT Cannot Do This for You
The person configuring the agent can implement the rules you define. They cannot define them for you.
They do not know which clients are sensitive. They do not know which data sources carry legal risk in your context. They do not know your risk tolerance or your compliance obligations or the commitments you have made to your clients about how their data is handled.
You know those things. Or you can find out. That is the work, and it belongs at the leadership level, done before the build begins, not discovered during testing or after a client complaint.
The practical implication is that governance decisions need to be in writing, reviewed by the right people, and embedded in the spec before anyone opens the builder. Not because the process requires bureaucracy, but because an agent configured without those decisions will make them itself, and it will make them based on what it was asked to do, not what your business actually needs.
Governance as a Competitive Advantage
There is an upside to this that is worth naming.
Businesses that take governance seriously from the start build AI systems that are faster to deploy, easier to expand, and more trusted by the people using them. When the rules are clear, the agent behaves consistently. When the agent behaves consistently, teams trust it. When teams trust it, they use it properly. When they use it properly, the outcomes improve.
The businesses that skip governance often get there eventually, after an incident or after enough frustration that someone finally writes down the rules. But they lose months and sometimes client relationships getting there.
The AI Pulse Assessment, where every AI Momentum engagement begins, is designed to surface these decisions early. Not to slow down the build, but to make the build worth doing. The questions about data, access, boundaries, and accountability are part of the assessment because they are the foundation everything else is built on.
If you do not have answers to those questions yet, that is normal. That is where most businesses are. The important thing is to answer them before you build, not after.
