Cases from the MBA and the Vanguard · MBA module — when the best tool in the division is the one nobody approved
Subtitle: A junior assistant built with AI what corporate BI could not and now someone has to decide what to do with it.
It is the last week of the month, and Alex is doing what he has done every month since he joined: preparing the billing reconciliations for the corporate print fleets his manager is responsible for. He is a junior billing assistant in the managed print division of a large IT group. The clients span financial services, property, transport and telecommunications. Together they run thousands of printers and copiers, each one generating meter readings, each billed at a cost-per-page rate that changes with contracts, volume bands and annual price adjustments.
The work is unforgiving. A meter that runs backwards, a device that moved sites, a rate increase applied in one workbook but missed in the next: each is a small error that becomes a large one on an invoice to a corporate client. The company has a central Business Intelligence platform, and it produces standard reports. They show what was billed. They do not show why it changed, whether the formulas held, or what the trend says about next year.
Then one month the process broke. His manager, who normally approves every invoice, was on leave, and Alex had to stand in and sign off the billing for the first time. While checking one client's account, he found that the client had received the wrong invoice and that the following month's billing had charged it twice. He calculated the credit note and helped repair the relationship. It cost time, goodwill and an escalation to senior management. It also taught him an uncomfortable truth: the error was caught only because a different pair of eyes, and a junior pair at that, happened to be looking. The integrity of the division's enterprise contracts rested on whoever was at their desk at the end of a long month.
So he built something. Alex is not a software developer. Working with an AI assistant, largely in his own time over several weeks, he built a reconciliation system that checks meter continuity, flags rate changes, tests formula integrity and surfaces device anomalies before an invoice goes out. On top of it he built client-facing reporting: interactive billing dashboards and monthly and annual presentations, including a multi-year trend analysis for the division's largest client.
The reports are better than what the company's BI produces, and not only in his own opinion: clients and senior colleagues have said they have never had this clarity from the group before. Alex now uses the system every month on every account. It has made the team faster, more accurate and more visible. It also exists entirely outside formal IT channels. No one in central IT has reviewed it, and no one but Alex fully understands how it works. The group has been slow on AI: there is no approved AI tool and no AI policy. Alex did not ask permission, because there was no one whose job it was to give it, and because a junior assistant does not usually ask the IT department for anything.
He can see three paths, and none of them is clean.
The first is the quiet shadow. He keeps using the system as a personal productivity tool and says nothing. Clients stay happy, and his manager's accounts look excellent. But the firm now depends on something it does not know exists. If Alex is ill, it stops. If he leaves, it leaves with him. If the logic misreads a rate rule, there is no one to catch it and no record of how the number was produced.
The second is to hand it to corporate BI. He presents it formally and lets IT absorb it into the enterprise stack. The firm gains security, backups and continuity. But Alex has heard how central projects go. The risk is that the tool joins a reporting queue, is rebuilt to fit the standard platform, and comes back months later as the same generic summary the clients already ignore. The BI team, meanwhile, is being asked to adopt something a junior assistant built that outperformed their own work.
The third is to become the owner without the title. He keeps control of the business logic and runs it as an extra responsibility. The tool stays sharp because the person closest to the work keeps shaping it. But Alex would carry responsibility for the accuracy of client billing through an AI-built system, with no seniority, no mandate, no budget and no authority to say no when others start depending on it.
Alex has sketched a fourth path that tries to combine all three. Ninety days as a declared sandbox, logging every anomaly and every check against the invoices actually sent. IT providing the secure connections, access controls and backups, but not rewriting the client reporting. And a formal role for Alex as the named owner of the reconciliation rules and dashboards, accountable for billing accuracy.
On paper it looks like the answer. In practice it depends on things he cannot control. Will his manager back him, or feel exposed by what the stand-in found? Will IT accept a system it did not build? Will leadership reward initiative, or ask why client billing data was processed in tools no one approved? The tool belongs to the company; that part is not in doubt. What is in doubt is whether the company will see it as an asset or as a breach, and whether it will punish the one employee who solved a problem the organisation had not yet admitted it had.
Month-end is coming again. The system will run. Before it does, Alex has to decide what he tells his manager, and what he asks for.
I would open with a silent vote: every leader writes down shadow, BI, owner or hybrid before anyone speaks. I would ask first the leader at the table who runs an IT or BI function, because they will speak for the enterprise, and then a founder, who will speak for the edge. The fact that would change the room's answer: whether client billing data was processed in tools outside the company's approved systems. If it was, the conversation moves from how to reward the initiative to how to contain the risk, and the hybrid path becomes much harder to argue for.
Today the dashboard only surfaces anomalies; a person decides. The NEO question begins when it is connected to an agent that can act. Picture it: the agent sees a meter running backwards on a client account and, inside its configured limits, issues a credit note and sends a corrected invoice. It also misreads an unwritten clause about volume-band resets and issues an unauthorised 15% credit across four corporate accounts, at machine speed, before anyone has looked.
An agent can find problems faster than any human. It cannot carry the responsibility for fixing them. That still sits with a named person, and if no one can be named, the agent should not act. The question for leadership is not whether edge-built AI is allowed, but who is named when it acts, and what record proves that they were in control.
Shadow AI is not proof that people are breaking the rules — it is proof that the rules have lost touch with the work.
A live case: every round can be improved, and the author's feedback is the next one.
The same two questions, answered twice: first without the mentor's corpus, then from it — his decision doctrine, VIS, the second volume, his papers on Latin America, shadow AI and edge flow, and the agent charter.
Without the mentor's corpus
1. Come forward before the month-end run, to his manager first, in writing, and open with the fact everyone will ask about: where the client data went. If it stayed inside company systems and the AI only helped write the checks, this is a gap in governance. If client data went into a public AI service, it is also a data incident, better named by him than found by someone else. Next come the double billing he caught, what the tool has caught since, what only he understands, and one request: a declared 90-day run beside the current process, taken to leadership with his manager. Leadership should legitimise the tool and not sanction him. David Marx's just culture model separates three behaviours: it accepts the error, coaches the at-risk behaviour, and sanctions reckless conduct, the conscious disregard of a substantial and unjustifiable risk. Building a check where there was no rule and no one to ask is at-risk behaviour at most. The Institute for Safe Medication Practices spells out the remedy: remove the barriers to safe choices and coach the person. If data did leave, stopping that flow is containment, not punishment. Legitimising is not trusting. US bank supervisors warned in 2011 that user-built applications such as spreadsheets are particularly prone to model risk, and that users underrate it when results look favourable. Their answer is effective challenge: review by an informed person who did not build the model. Ask yourself: who, other than Alex, could explain tomorrow why this month's invoice says what it says?
2. Not a policy. A door with a name on it, a clock and an amnesty, all on one page:
Aviation learned why the amnesty matters. When TWA Flight 514 flew into a Virginia mountain in December 1974, a United crew had nearly hit the same mountain six weeks earlier, and there was no way to share that warning beyond United. Since 1976 NASA has run a reporting system that holds reports in strict confidence, and the FAA waives penalties, within limits, for unintentional violations reported within ten days. The size of what hides is known. In Microsoft and LinkedIn's 2024 survey of 31,000 people, 78% of AI users brought their own tools to work, and 52% were reluctant to admit using AI for their most important tasks. People ask first when asking is quicker and safer than hiding. Every declared tool then gets one line in a register: owner, data, deputy, date of the next check. Ask yourself: if someone wanted to ask permission tomorrow, whose name would they write on the email?
Sources: D. Marx, "Patient Safety and the Just Culture", Obstetrics and Gynecology Clinics of North America, 2019; ISMP, "The differences between human error, at-risk behavior, and reckless behavior are key to a just culture", ISMP Medication Safety Alert!, June 2020; Board of Governors of the Federal Reserve System and OCC, Supervisory Guidance on Model Risk Management (SR 11-7), April 2011; NASA ASRS, CALLBACK 435, April 2016, and the ASRS confidentiality and immunity provisions; Microsoft and LinkedIn, 2024 Work Trend Index.
From the mentor's corpus
1. The mentor's decision doctrine gives Alex his first sentence, and it is not a confession. Its first rule treats human failure as a design axiom: a system that depends on one permanently trustworthy guardian is badly designed. The month his manager was away exposed that flaw, because billing integrity rested on whoever happened to be looking. The quiet shadow would rebuild it with Alex as the guardian. So he brings the flaw, not the dashboards. The second rule tells leadership what to do: human and AI power must be limited by scope, time, evidence, independent review and revocation. That is legitimisation, and it is almost exactly his fourth path, with one change. The mentor's VIS separates the Decision Owner, accountable for the outcome, from the Recommender, accountable for the integrity of the process, so that the Recommender can reach uncomfortable conclusions without carrying the outcome. Alex should ask to own the rules and the checks, not billing accuracy. His manager keeps the signature, and with it a reason to back him rather than feel exposed. Stopping the tool would be what the second volume calls over-centralisation under pressure: it feels responsible, and afterwards people at the edge stop exercising disciplined initiative. On sanction, the mentor's paper on Latin American business describes AI that flags payment anomalies for dialogue rather than punishment, and names the order: learning before sanction. Ask yourself: am I asking to own the outcome, or the integrity of the check?
2. The mentor's article on shadow AI puts the stake in one line: an organisation is only as secure as the decision-making of its most curious employee. So the smallest thing informs that decision instead of forbidding it. The second volume names the gap that produced Alex: intent without boundary conditions. The edge guesses its permission, more liberally or more conservatively than leaders meant, and they find out when results arrive. The correction is to declare the boundaries explicitly, tighter than a leader would naturally want. In ninety days that is one page and one rhythm, built from the mentor's paper "From Idea Flow to Edge Flow":
The decision doctrine lets that person answer fast: roughly 80% confidence can be enough for a reversible decision. The paper's own example shows what comes next: a spike in reported concerns, then a settling. Shame no one for the spike, and record what was learned, so that the next team can spend less courage buying the same lesson. Ask yourself: if the next Alex looked for the rules today, what would he find?
On the NEO Turn. The mentor's task-to-agent protocol draws the line where the case does: the machine observes and orients at scale, and the human keeps the Decide and Act phases. A credit note is an act. His Command Layer names who answers: the agent for the action, and whoever issued its intent for the intent, the boundaries and the authorisation, both on the record. So credit notes stay at the HAI5 level "Human decides after AI recommends" until the evidence earns more. Each boundary is a constraint the agent cannot cross without a receipt that flags it for human review, and a kill indicator, such as credits on more than one account in a day, pauses it. VIS keeps the record, from raw evidence through the AI's analysis to the human decision. The deeper lesson is the unwritten clause: an agent keeps only the rules someone wrote down, which is why the charter writes its logic as If/Then rules with their exceptions. Write them first; where they are silent, the agent stops.
Sources: the mentor's decision doctrine of 22 August 2026 (§1, §2, §6); the VIS framework (the Decision Owner and the Recommender; provenance); Vanguard Leadership, vol. 2 (the failure modes of Mission Command; the Command Layer); the mentor's paper on Vanguard lessons from Latin America; the mentor's article on shadow AI; the mentor's paper "From Idea Flow to Edge Flow"; the Vanguard Task-to-Agent Mapping Protocol (the Agent Charter, the kill indicator).
The mentor had written this company's way out before the case arrived. In his own case in this book, "The AI Office That Began with One Brave Team", a company that had discussed AI for months let one volunteer team trial AI on one process, and gave the experiment an address. Alex's system is the same experiment started in the wrong order: the work came first, and the sponsor never came. So what he brings to his manager is neither a confession nor a request for a title. It is a proposal for an AI office, built the way the mentor's team built theirs.
What the mentor's team asked for. Before they started, the team asked for five things:
The founder agreed and became the sponsor. Alex needs the same five things, and one person willing to sponsor him: his manager, or the head of the division.
The starting package, for month-end billing. The mentor's team ended its first month with a repeatable package: choose one workflow, define the outcome, assign an owner, prepare the sources, set approval boundaries and run a measured trial. For Alex:
The mistake they could discuss. On the fourth day of the mentor's trial, a draft treated an old customer exception as a standard condition. The reviewer caught it, and the team fixed the way the source was handled. The team leader then showed the mistake to the founder at the weekly review, alongside the successes. That habit is what turns a shadow into an asset. Alex's first month should produce one list: what the system caught and what it got wrong, both with dates.
When everyone wants one. The mentor's case warns about the next step. Once a trial works, every team wants the same setup, and a capable pilot team risks becoming the support desk for every new experiment. What gets shared is the package, not Alex's evenings. Ask yourself: who in my company would sponsor the next Alex, and have I told them it is their job?
Sources: the mentor's case "The AI Office That Began with One Brave Team" (chapter 14 of this book).
It is fine that he did something good for the company, but he works for that company. So my advice is: ask for a meeting with the boss, prepare well and present what he has done. If the boss says no, that is the boss's right, and there is no need to fight on: kill switch.
The tool belongs to the company, so he presents it to his boss, and that is it. Never work against the company.
A question for the table, a disagreement, what you would have done. The case lead reads every comment; the ones the table takes up enter the chapter as questions from the room, with your name.