Business owner at a crossroads signpost - deciding where humans stay in the loop when AI tools have real authority

What happens when the tool has real authority and nobody’s had the governance conversation.

October 12, 2026•11 min read

"The tool you checked out on in June already left you behind" (last week's newsletter) made the case for a real, documented capability jump AI tools made this year: from something you prompt one line at a time to something you can hand a real, multi-step piece of work and walk away from. That newsletter flagged, without developing it fully, that the governance question sitting behind that shift deserved its own newsletter, not a paragraph tacked onto the end of one about product launches. This is that newsletter, and I want to be precise about why the timing matters, because the governance conversation most businesses think they've already had was built for a tool that no longer exists.

The permission conversation a lot of businesses had earlier this year, if they had one at all, was designed around a specific shape of interaction. You ask the tool for something. It gives you an answer. A person reads that answer before anything happens because of it. That human moment, the pause between the tool producing something and a person acting on it, was never written down as a rule anywhere. It didn't need to be. It was simply built into how the tool worked, because a single-response tool cannot do anything with its own output except hand it to you.

That built-in pause is exactly what disappeared with the shift I described last week. A tool that can be handed a task and left to run for an hour doesn't wait for a human to read its first move before making its second one. It pulls the data, drafts the response, checks it against whatever rule you gave it, and sends it, or files it, or updates the record, all without a person necessarily looking at any single step along the way. The checkpoint that used to exist for free, simply because of how these tools worked, now has to be built on purpose, or it doesn't exist at all.

Why is this a different kind of problem, not a bigger version of the old one?

Because the question a business now has to answer sits inside the task rather than in front of it. Once a tool can run five or ten steps unsupervised, someone has to have decided, specifically, which of those steps still gets a human eye on it and which ones don't.

"The line your business needs to draw before anything else" set out the one-page boundary document every business needs, the plain-English page that says what's fine to do without asking, what needs a check-in, and what's off limits entirely. That page still matters, and if your business hasn't written one, this newsletter is not a reason to skip it and jump to what follows. But that page was built to answer a question about permission at the start of a task: is this person, or this tool, allowed to begin this kind of work at all.

The question a business now has to answer is a different one, and it sits inside the task rather than in front of it. Once you've said yes, this tool can handle client correspondence, or yes, this tool can reconcile the accounts, the next question isn't whether it's allowed to start. It's where, inside that now-longer sequence of steps, a human actually needs to look before the sequence continues. A tool that only produced one output at a time never needed this question answered, because the human was always going to look, by necessity, at the only thing the tool made. A tool that can run five or ten steps unsupervised needs someone to have decided, specifically, which of those steps still gets a human eye on it and which ones don't.

Most businesses that have written a governance page at all have written the first kind, the start-of-task permission page, because that's the kind of governance question these tools raised until quite recently. Almost none have written the second kind, the mid-task checkpoint, because until this year there usually wasn't a mid-task to put a checkpoint inside. That's not a criticism of anyone who stopped at the first page. It's an accurate description of a job that got bigger while nobody was looking, in exactly the way capability jumps tend to make jobs bigger.

What are even the most AI-forward businesses still figuring out?

Even the most AI-forward organisations are still making these calls case by case rather than working from a settled rulebook, and nobody has fully met the standard yet. The answer isn't to wait for a finished framework to copy, because one doesn't exist; it's to start making the calls in real time and get more precise about them as you go.

I want to be honest about how unfinished this problem is everywhere, not just in businesses with five or fifteen people, because there's a comfort in that honesty that's worth having before this gets practical. Paul Roetzer runs one of the more AI-forward organisations operating today, tracking exactly this kind of shift for a living. He's said plainly that there are moments, at least once a day, where a team member wants to run an experiment and his own reaction is that he isn't sure about that one. Even someone who understands the risks at that depth still finds himself pausing, case by case, rather than working from a settled rulebook that answers every situation in advance.

He's also said something more striking, and more useful to a business owner reading this than the pausing itself. The current bottleneck at his own company is him. He hasn't hired a CIO or a CTO to own this properly, so the decisions about what's safe to hand over and what still needs a human default, for now, to whichever call he happens to make in the moment. He's not describing that as a solved problem he's generously sharing. He's describing it as the honest state of things at an organisation that's about as far ahead on this as any business is likely to be right now.

That matters for two reasons. It means a business owner who hasn't fully worked out where the mid-task checkpoints go isn't behind some standard that more sophisticated businesses have already met. Nobody's fully met it yet, including the people whose job is to think about this constantly. And it means the answer isn't to wait for a finished framework to copy, because one doesn't exist to copy. The businesses making real progress on this aren't the ones with the most complete policy. They're the ones who've started making the calls in real time, the way Roetzer describes making his, and getting more precise about them as they go rather than waiting for certainty that isn't coming.

What actually goes on the governance page now?

One new column. For each thing your business now lets a tool do end to end, name the specific point inside that sequence where a human still looks before it goes further, not just whether the sequence is allowed to start.

The practical version of this doesn't require throwing out that earlier document and starting again. It requires adding one new column to it. For each thing your business now lets a tool do end to end, name the specific point inside that sequence where a human still looks before it goes further, not just whether the sequence is allowed to start.

Take the reconciliation example from that earlier issue. "You can use AI to reconcile invoices and flag discrepancies" was the old-shape answer, a permission granted at the front door. The new-shape version names the checkpoint inside the sequence: the tool can pull the data and produce the reconciliation and the flagged list, but nothing gets marked resolved and nothing gets written back to the ledger until a person has looked at the flagged items specifically, not the whole output, just the part that actually carries risk. That's a five-minute addition to a document that already exists, and it's the difference between a tool that's merely allowed to run and a tool that's actually being watched while it does.

The same logic applies anywhere a task now runs longer than it used to. Client correspondence drafted and queued is fine to let run unsupervised. Client correspondence drafted and sent without a specific person reading the specific message first is a different decision, and it deserves to be made on purpose rather than defaulted into because nobody thought to separate "draft" from "send" once the tool became capable of doing both without stopping.

The same question applies to scheduling and triggered tasks, which is one of the more concrete new capabilities behind the shift "The tool you checked out on in June already left you behind" described. A tool that can be told to run something every morning at seven, pulling fresh data and acting on whatever it finds, is a materially different proposition from a tool that runs once when you ask it to and then waits. The trigger itself is not the risk. The risk is a business setting up a recurring, unattended task and never once revisiting what it's actually doing three months in, once the person who set it up has moved on to other things and the task is just quietly running in the background, trusted by default rather than by decision. A checkpoint doesn't only need a place inside a single task's sequence of steps. A recurring task needs a review date as well, a point someone has actually put on a calendar to look back over what it's been doing and confirm it's still doing what it was meant to.

Who actually owns the checkpoint?

Whoever is closest to the work the tool is now doing, and that person needs to know, explicitly, that watching this is part of their job. Naming the checkpoint and naming who owns it are the same decision, made at the same time, or the checkpoint isn't real yet.

There's a question underneath all of this that's worth naming directly, because it's the one most businesses skip past on their way to the practical part. Deciding where the checkpoints go is not, by itself, enough. Someone has to actually be the person who looks, and in a business of five or fifteen people, that's rarely going to be a dedicated role the way it might be at a larger organisation with a CIO to hand it to. It's going to be whoever's closest to the work the tool is now doing, and that person needs to know, explicitly, that watching this is now part of their job, not an assumption everyone quietly makes and nobody actually owns.

This is worth saying plainly because the alternative, an unowned checkpoint, is worse in a specific way than no checkpoint at all. A business that knows it has no oversight at least knows where it stands. A business that believes a checkpoint exists, because someone once said "someone should probably keep an eye on that," but never assigned the watching to an actual person, is operating with the comfort of governance and the reality of none. Naming the checkpoint and naming who owns it are the same decision, made at the same time, or the checkpoint isn't real yet.

Which businesses will be ahead of this by next year?

Not the ones with the longest governance document. The ones ahead of this are the businesses where someone has actually sat with the specific tasks now running longer than they used to and asked, plainly, where in that sequence a human still needs to be looking.

The businesses that handle this well over the next twelve months won't be the ones with the longest governance document. Length was never the point, and a business that produces forty pages nobody reads has arguably built a worse system than the business with one honest page that names three real checkpoints and means them. What separates the businesses ahead of this from the ones behind it is whether anyone has actually sat with the specific tasks now running longer than they used to and asked, plainly, where in that sequence a human still needs to be looking.

That's an afternoon's work for most businesses, not a project. It's also, I'd guess, still undone in the great majority of businesses that read this newsletter, for the same reason the original permission page so often went unwritten: nobody has been asked the question directly enough for an answer to form. Consider this that question, asked directly, about the tasks in your business that changed shape this year without anyone officially deciding they had. Nobody signed off on the change. It happened anyway, task by task, the moment each tool quietly became capable of more than it was originally trusted to do.

How do you find out where your business stands?

Knowing whether your business has actually kept its governance current with what these tools can now do, or is still working from a page written for tools that only produced one output at a time, is exactly what the AI Readiness Assessment is built to surface. It takes about ten minutes and the result is specific to your business. Click here now to take it.

My book, The Human Edge is launching early Q4 2026. To be first to know when it's available, connect with me on LinkedIn and comment or DM me there.

Back to Blog