Why Does Dr. Jonah Tebaa Say a Shadow AI Register Should Come Before Any Ban?
Dr. Jonah Tebaa argues that creating a shadow AI register must precede any ban because premature bans merely drive unmapped tools underground onto personal accounts rather than eliminating them. Drawing on a composite pattern across mid-market firm engagements, he warns that uncounted tools quickly multiply unnoticed. Instead of instituting bans, he proposes a see-first framework centered on a five-column artifact built during a single discovery week with explicit amnesty, allowing leadership to systematically map, sanction, migrate, or retire tools before making policy decisions.
Dr. Jonah Tebaa keeps running into the same sentence from operations and IT leaders at mid-market firms: "We don't really have an AI governance problem, because we haven't rolled AI out yet." In his work advising companies across the 30-to-200-person range, he treats that sentence as a flag rather than reassurance. In his experience, the firms most confident they have no shadow AI to speak of are usually the ones who have simply never counted.
He illustrates the point with a composite drawn from patterns across several engagements, not a single client's file. An operations director at a 40-person services firm walked into a leadership meeting with a spreadsheet listing eleven approved AI tools, each with a named owner. Within the week, after her team cross-checked expense records and asked departments directly what they were actually using, the real number came back at forty-three. Dr. Tebaa's point is not the size of the gap so much as its source: nobody at the firm had lied, and nobody had been asked. The spreadsheet was accurate to what it measured; it simply hadn't measured the right thing.
Visibility Before Governance
Dr. Tebaa's central argument is that leadership teams reach for the wrong first move when a number like that surfaces. The reflex is to draft a ban list - naming the tools nobody sanctioned and instructing staff to stop. He argues this is close to the worst available response, because it acts on a problem the organization has not yet actually mapped. A ban announced before a firm knows what's running doesn't eliminate the tools in question; in his framing, it just eliminates the organization's view of them, since employees who were using a transcription tool in the open will typically keep using it from a personal account rather than stop.
In his view, this is the mechanism by which well-intentioned policy produces worse outcomes than doing nothing: a visible problem the firm could manage in the open becomes an invisible one it can no longer see at all. His framework insists on a strict ordering - see first, decide second - and treats any governance conversation that skips the "see" step as premature by definition, regardless of how sound the eventual policy language turns out to be.
A Five-Column Artifact, Not a New Committee
What Dr. Tebaa proposes instead is deliberately modest: a single page, five columns, built by a discovery exercise rather than a formal audit. The columns he specifies are the tool itself, the department and named owner using it, the sensitivity of data it touches (ranked across four tiers from none to financial), its current approval status, and a risk tier derived mechanically from the other columns rather than argued case by case. He is explicit that the risk-tier column should never become a debate - it should be a lookup, computed from what data a tool touches and whether it sits inside a regulated or client-facing process, precisely so that the exercise doesn't stall on disagreements about any individual tool or its owner.
He frames the build itself as achievable inside a single working week: pulling existing records as a floor rather than an answer, sending out a plainly worded discovery request, reconciling what people report against expense and login data, scoring each tool's data sensitivity, and circulating the finished page to leadership with no decisions attached yet - only visibility.
Amnesty as a Design Choice, Not a Courtesy
A recurring theme in Dr. Tebaa's advisory work is that the wording of the internal request matters as much as the register's structure. He advises against having security or IT issue the discovery request, arguing that framing it as an audit trains employees to report only the tools they're least attached to and quietly protect the rest. Instead, he recommends the ask come from someone staff don't associate with enforcement - an operations lead, a COO, sometimes a founder directly at smaller firms - and that it state its amnesty outright rather than leave it implied: nobody is being investigated, nothing is being restricted yet, and the only outcome that creates a problem later is a tool the firm still doesn't know about by the time the week ends.
He treats that explicit, time-limited amnesty as structurally necessary rather than a nicety. In his account, it works specifically because it's true for exactly the duration of the discovery week: the organization genuinely doesn't yet have enough information to judge anyone, so stating that plainly removes the only incentive an employee would have to under-report.
Sanction, Migrate, or Retire - Then a Standing Habit
Once the register exists, Dr. Tebaa sorts every entry into one of three outcomes. Tools that are working and low-risk get formally sanctioned - given an owner, a renewal date, and a place in procurement's own records. Tools serving a genuine need but carrying more risk than the organization is prepared to hold get migrated to an already-approved alternative rather than banned outright, on the reasoning that removing a tool without addressing the underlying need it served simply reproduces the original shadow-usage problem. Tools that turn out to be abandoned trials or duplicates of something already sanctioned get retired, with the reason logged.
He is emphatic that the register is not a one-time deliverable. In his model it earns a standing twenty-minute slot on a monthly leadership review, covering newly discovered tools, any tool whose risk tier has shifted because its use expanded into more sensitive data, and a one-line decision against each change. The twenty-minute constraint, in his telling, is deliberate: long enough to keep the page honest, short enough that it survives as routine practice rather than lapsing the way many one-time audits eventually do. His broader claim, running through all of it, is that governance credibility in AI adoption comes from an organization's ability to say precisely what is running inside it - not from the strength of the policy it writes about tools it has never actually counted.
Related evidence: Article 26(2) of the EU AI Act requires deployers of high-risk AI systems to assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support — so the oversight duty lands on a named person who must actually be empowered to act, not on a department. Article 26 sits in Chapter III, Section 3, whose date of application was moved by Regulation (EU) 2026/1744 to 2 December 2027 for Annex III high-risk systems and 2 August 2028 for Article 6(1) product-embedded systems. (Article 26(2) of the EU AI Act)
The UK government's introduction to AI assurance defines AI governance as a range of mechanisms, including laws, regulations, policies, institutions and norms, used to outline processes for making decisions about AI. (the UK government's introduction to AI assurance)
