Before AI Can Run the Business, We Need to Be Clear About How the Business Runs

The idea of an AI that understands your business is appealing.

You could ask why margins are falling, which customers need attention, or what is holding up delivery. Instead of calling several departments and comparing spreadsheets, you would have a system that brings the relevant information together and helps you decide what to do.

I can see why business leaders want this. It is also part of what motivates us to build SenangAI.

But there is a difficult assumption underneath that promise: that the business has already made its own rules, responsibilities and exceptions clear enough for AI to work with.

That deserves more attention.

The information may be there. The meaning may still be unclear.

Imagine asking an AI whether the company can accept a large customer order.

The inventory system shows enough stock. Sales sees an opportunity to meet its monthly target. Finance has concerns about the customer’s overdue balance. Operations knows that some of the stock has already been promised elsewhere, although the reservation has not yet reached the system.

An answer based on inventory alone could be accurate and still lead to a bad commitment.

Connecting more systems would help. The AI would then need to understand which records are current, what “available” means, which commitments take priority, and who can approve an exception.

These are business decisions that someone has to own.

This is where I think some conversations about enterprise AI become too optimistic. We talk about connecting data as though understanding will follow automatically. In practice, connecting data can expose disagreements that were previously hidden inside separate departments.

That can be valuable. The next step is to resolve those disagreements properly, rather than letting the AI quietly choose a version.

McKinsey’s proposal recognises this

McKinsey’s October 2026 article describes an AI operating system as an enterprise “second brain”. Its proposal includes shared business definitions, institutional knowledge, decision rights and human judgment. It also asks leaders to decide which actions can be delegated and when escalation is necessary. Read McKinsey’s article

I agree with that direction.

My concern is what happens during implementation. It is relatively easy to demonstrate an AI finding information across documents. It takes more work to establish whose interpretation should apply when those documents disagree.

Consider two versions of a pricing policy. One is formally approved. The other is newer and has been circulated by email, but is still under discussion.

Which should the AI use?

The newest document is not necessarily the authoritative one. The most frequently used document may not be correct either. Someone needs to establish its status, effective date, scope and owner.

A better model may help interpret the documents. The organisation still has to decide which policy it stands behind.

Knowing what to do does not give AI permission to do it

We already understand this when we work with people.

An employee may recognise that a refund is justified without having authority to approve it. A sales manager may see a good opportunity without being able to change a customer’s credit limit.

AI needs similarly clear boundaries.

If an agent identifies a promising customer opportunity, it might prepare an account summary, suggest an offer and draft a message. Sending that offer, changing the price or committing delivery capacity creates a different responsibility.

The company should decide where that boundary sits before the agent reaches it.

This does not mean putting an approval box in front of every small action. Some work can reasonably run within agreed limits. But those limits need to be specific enough to enforce.

For example, a company might allow an agent to create internal follow-up tasks while requiring approval before it changes customer terms. It might permit analysis across approved records while restricting which information can appear in an external message.

The useful question is: what has this agent actually been authorised to do, for whom, and under which conditions?

A person clicking “approve” is only part of oversight

I am cautious about treating “human in the loop” as a complete answer.

If someone receives a polished recommendation without the relevant evidence, they may have little basis for challenging it. If they receive hundreds of requests, careful review becomes difficult.

A 2026 position paper hosted by Microsoft Research argues that AI agents need to be designed around the practical demands of human oversight. The authors also discuss how reliance on automation can weaken the skills people need to supervise it. This is a research argument, not a measured failure rate across businesses. Read the Microsoft Research paper

For me, the practical lesson is straightforward. The reviewer should be able to understand what will change, why the change is proposed, what remains uncertain and what could go wrong.

They also need the authority to stop it.

In the customer-order example, an approval request should make the stock reservation and credit concern visible. Otherwise, the person may be approving a decision they would have rejected if they had seen the full situation.

Good oversight depends on the quality of that handover.

“Learning from experience” needs an owner too

The promise that enterprise AI improves over time sounds sensible. But what exactly is it learning?

Suppose a manager approves a special discount to resolve a service failure. The customer accepts it and renews.

Should the AI recommend the same discount next time? Should it apply to similar customers? Was it a commercial strategy or a one-off concession?

The outcome alone cannot answer those questions.

This is why I think companies need a clear process for turning experience into shared knowledge. A correction, an exception and a policy change should be recorded differently.

Meta’s engineering team provides a useful example. In its account of an organisational second-brain system, expert feedback is diagnosed, converted into proposed changes, tested and reviewed by domain experts. Corrected cases are then added to regression tests. It is a company-reported implementation, rather than independent proof that the approach will work everywhere. Read Meta’s engineering account

What matters to me is that an update has to earn its place.

An AI should not turn one person’s preference into company policy simply because that person corrected it. Nor should a successful outcome automatically justify giving the agent more freedom.

Someone needs to decide what changed, where it applies and whether the change caused problems elsewhere.

Governance has to fit the daily work

There is a temptation to leave these questions until after the pilot. First demonstrate the capability, then work out the controls.

That creates a difficult handover. The business sees something useful and wants to expand it. The teams responsible for security, operations and risk are then asked to make it dependable.

I would bring those responsibilities into the first workflow.

Choose a useful business problem. Agree on the information it needs, the decisions involved, the person responsible and the actions the system may take. Test what happens when information is missing, contradictory or out of date.

This need not become a large governance exercise before anything useful happens. It can begin with one task and a small set of clear rules.

NIST’s Generative AI Profile takes a continuing approach to risk management, covering monitoring, override, recovery and change management after deployment. It is voluntary guidance, but it offers a useful reminder that the work continues once a system goes live. NIST AI 600-1

How this shapes my thinking about SenangAI

These questions are directly relevant to what we are building at Kognosys.

I want SenangAI to help businesses see more of what is happening across their operations: emerging risks, missed opportunities, causes of poor performance and possible next steps.

For that to be useful, the system needs to make the basis of its recommendations understandable. People should be able to inspect the evidence, see conflicting records and recognise when an answer depends on an assumption.

The organisation should also retain control over access, deployment and authorised actions.

Those are responsibilities for us to demonstrate in real deployments. Describing them on a product page is only a starting point.

I also do not believe a business needs perfect data before it can begin. A focused implementation can reveal which definitions, records and processes need attention. The important thing is to make those gaps visible and give someone responsibility for resolving them.

AI can help organise the work. It cannot decide, on the company’s behalf, who should be accountable.

The enterprise second brain is a worthwhile ambition. To make it dependable, we have to be equally serious about the organisation around it.

Before asking AI to take on more responsibility, I would want the team to be able to answer three ordinary questions: which information applies, who can authorise the action, and who decides when the process changes?

The answers will tell us a great deal about whether the business is ready to put that intelligence to work.