A founder starts reading things more closely than they used to. A client proposal, a board paper, a market summary from someone in the team. Nothing is clearly wrong with any of them. But a sentence sounds right and can’t be traced to anything, or a figure is close to the real one without being it. So the next document gets the same careful read, and the one after that.
Nobody decided this. It builds up gradually and sits in the founder’s week next to everything else, usually without a name.
It can be the first visible sign that a team is using AI unevenly. There is no incident to point to and no project that failed. What changes is how much of the team’s work needs checking before it can be trusted, and who ends up doing the checking.
The obvious reading
The usual response is to treat it as a skills gap. Some people use the tools well, some barely use them, and a few use them with more confidence than care. So the company runs a workshop, shares a few prompts, and expects the spread to narrow.
That helps, but it treats the issue as individual, and the cost doesn’t stay with the individual. Work passes through several hands before it leaves the building: someone drafts, a manager edits, a head of function approves, the founder signs off. If one person in that chain accepts AI output without testing it, everyone after them inherits the error, usually without knowing where it came from.
The people downstream compensate. A careful manager rewrites a section; a senior colleague double-checks a number. That work is real, yet it appears in no plan or budget, and it falls hardest on the strongest people. The reliability of the team’s output ends up set by its least careful step, which is what the title means.
Why it lands on leadership
Three things tend to sit underneath this, and an individual getting better at prompting solves none of them.
There is no shared standard. Most teams adopted AI one person at a time, each finding their own way. Ask what “good enough to send” means when AI has touched the work, and the answers in one room will differ. Without a common answer, everyone applies their own.
Review depends on understanding. A manager who doesn’t use these tools well has trouble judging what was made with them. They usually do one of two things: approve too much, or check everything. Both cost the company something, and neither shows up until later.
The founder is often somewhere else. Founders tend to try new tools early and with real enthusiasm, while their leadership team may be ahead in some areas and behind in others. Decisions made at different levels of understanding pull in different directions, and the founder is left to reconcile them. It is the pattern described in Why Scale-Ups Slow Down: Leadership Becomes the Bottleneck, arriving by a different route.
Questions worth asking
These are not an audit. They are three questions a leadership team can work through in one conversation.
- Who decides how AI is used in each function, and do they understand it well enough to judge the output?
- When AI has helped produce a piece of work, what happens to it before it reaches a customer or the board? Who checks it, and against what?
- Is the leadership team itself at roughly the same level? If not, which decisions are being made by people who can’t fully evaluate the tools involved?
If the answers differ from one executive to the next, that difference is the finding.
The hiring question
When a gap like this becomes clear, the first instinct is often to hire for it: a Head of AI, a new COO, a senior person who will “own” the topic. Sometimes that is right. More often it is early.
If the real issue is that nobody has been given ownership of the standard, a new executive arrives into the same ambiguity. The role may be unclear, the authority may overlap with existing leaders, and the founder remains the person everyone checks with. Settling the mandate first decides whether a hire is needed at all, and what kind of person the role requires. It is how we approach any leadership decision: validate the decision before looking for the person.
If you do hire, assess for judgement rather than familiarity with tools. Tools change quickly. What lasts is knowing when output can be trusted, when it can’t, and how to build that habit in other people.
A more useful way to look at it
A team’s AI capability is usually described by its best users. Day to day, it is set by the distance between them and everyone else, and by whether anyone is responsible for that distance. That makes it a question about ownership and standards, which sit with leadership, more than a question about software.
If you recognise the founder who has quietly started checking everything, the useful first step is usually small: decide who owns the standard, and say so. Whether anyone needs to be hired comes after that. It is the kind of decision we help founders work through before any search begins.
