Excel, macros, scripts, AI agents: how to regain control of a population of tools that grows faster than your inventory campaigns, without destroying the value it produces.
For twenty years, the answer to shadow IT has fit in one word: census. An annual campaign, a form, a frozen inventory. That answer was already fragile, and AI has just made it absurd. The question is no longer how many we have, but how to make sure no new critical tool is born out of control.
Recently, on an engagement at a large banking group, I watched internal control ask the IT department a simple question: how many Excel files, macros and scripts feed your critical reporting today?
Nobody had the answer.
The last census was two years old, a form never refreshed, and since then the population had moved, grown, mutated. We were steering a regulatory risk with an outdated snapshot. But beyond this specific example, I have yet to visit a large organization where this problem is truly solved.
What do we really mean by an EUC?
The technical term is EUC, for End User Computing, and it is often reduced to the financial controller’s Excel spreadsheet. That view is too narrow; in reality, EUCs cover a wide variety of tools.
An EUC is any tool, spreadsheet, macro, script, Access database, dashboard, RPA bot, automation, created or maintained by a user outside the IT governance cycle. We then tell them apart by usage rather than by technology: what data the tool handles, how critical it is, what level of control it is subject to, how integrated it is into governance.
And you all know the signals that give away their presence; you hear them in every organization. “The latest version is on So-and-so’s computer.” “The file comes in by email.” “If it breaks, we fix it by hand.” “There’s no documentation, but the team knows how to do it.” “We don’t know exactly where the data comes from.”
No inventory. No backup. No version control. No reproducibility.
A tool that a real process depends on, and that the organization does not see.
Where operational becomes regulatory
As long as an EUC calculates a department’s budget, the risk stays internal: it costs a few lost hours and a bit of hair-pulling to rebuild the trade-offs on data nobody checked. But in the end, the risk remains limited. At what point does it become a compliance problem? The day it enters the risk data aggregation chain, the one that feeds the reports sent to the regulator.
BCBS 239, the Basel Committee standard on risk data aggregation, requires this data to be accurate, complete, traceable, auditable, and produced by “highly automated processes, minimizing manual intervention”. A spreadsheet with no audit trail, no versioning and no data lineage methodically ticks the opposite box.
DORA, the European regulation on digital operational resilience (EU 2022/2554), applicable since January 2025, pushes in the same direction on continuity and control of assets, and GDPR adds the personal data layer on top. The result converges: a tool that touches critical data must be demonstrable, not just functional.
On audit day, saying it has worked for ten years is worth nothing. Only what you can prove counts.
AI industrializes the production of the old
The temptation today is to treat AI as a separate category, a third type of tool alongside the old Excel files and the solutions cobbled together by power users. But it is a false good idea: it pushes you to build a separate AI governance when it would be enough to extend the one that already exists.
What AI changes is the volume. Yesterday, writing a script required a specific, and often rare, skill. Today, a copilot generates an automation or an agent in a few minutes, at the request of someone who cannot code.
So the EUC population is no longer growing linearly; it is exploding.
And that is where the historical reflex collapses. Taking a census of a population through an annual campaign made sense when it moved slowly; trying to do it today is like counting a running crowd, and by the time you finish the inventory, it is already wrong.
If the declarative inventory is dead, it is not because we were doing it badly. It is because the pace of creation has changed scale.
Why doesn’t a ban ever last?
The most common answer is often the worst: lock down, ban, force everyone to go back through IT.
But the business has a real need, and whoever creates that script is often closer to the need than the IT department is. With AI, they can produce in three days what the IT cycle would deliver in three months. That value is real, and denying it guarantees workarounds rather than preventing them.
So the goal is not to eliminate and ban EUCs, but to keep what they create while removing the uncontrolled risk.
Four levers to regain control
The first lever is blocking at the source: technically preventing critical data from being exported to a tool that is not an official application. It is the only control that stops an ungoverned EUC from being created before it even exists. And incidentally, it acts as a detector, since you can then identify who is trying to take which data out, and therefore step outside the framework.
But this lever has a heavy limitation. Blocking assumes you know what you are blocking, and therefore that you have mapped every data input and output. In a small organization, the exercise takes a few days; we put it in place for our own use of AI and vibe coding at Alenia. In a large group, this complete mapping is nearly impossible, even when limited to critical data: the flows number in the thousands, they cross each other, they change every month. Blocking at the source is a target you work toward, not a switch you flip overnight.
So how do you find what nobody ever declared? That is the purpose of the second lever, automatic detection. Specialized tools, such as Mitratech’s ClusterSeven or CIMCON EUC Insight, scan file servers, network shares and cloud storage, SharePoint and OneDrive included, to spot the spreadsheets, databases and scripts running under the radar. The mechanism is a funnel: first a light scan of the metadata, then detection of version chains, because a file saved over and over is probably embedded in a real process, then in-depth content analysis, formulas, macros, links between files, access rights, reserved for the subset that survived the sorting.
It is effective, with two caveats. Technical scoring is automatic, but business criticality scoring is not: it assumes the organization has defined beforehand what is critical for it, and the real work lies there far more than in the scanning technology. As for the file that lives only on a user’s computer, never synced, it remains out of reach. Detection shrinks the blind spot without closing it.
The third lever comes down to a simple principle: one regime, one exception. A general regime, driven by the criticality of the usage and backed by AI-specific guardrails: approved tools, no sensitive data sent to external models, an explainability requirement. And a single supervised exemption, power users: competent, named, certified profiles, allowed to relax certain constraints on how they build. The latitude covers tools, access and deployment to production, never the fundamentals, since backup, documentation, version control and confidentiality remain non-negotiable. The exception has to be earned, and it can be taken away.
The fourth lever replaces the binary ban with a matrix, where authorization follows the use case rather than the tool. The same spreadsheet can be perfectly acceptable for local use and forbidden as soon as it touches regulatory data. So we cross two axes: the criticality of the usage and the origin of the tool. A critical usage with a continuity requirement remains a candidate for migration to a governed application, whatever its origin, never a permanent state. At the other end, a non-critical usage built on an approved platform is not only tolerated, but encouraged.
None of these levers is enough on its own, and large organizations combine them to build a framework that holds.
The most effective lever: open a fast lane
If I had to keep only one, it would be none of the four.
The control that has the most effect is not a control. It is an offer.
Give business teams tools to build fast, in an environment that has already been approved: self-service platforms, a catalog of advanced tools for power users, a managed workspace where you can script, version and deploy without ever stepping outside the framework.
Why do people work around the rules? The logic is human before it is technical. An uncontrolled EUC is almost always born from a legitimate need that did not find an official answer fast enough, and as long as the compliant path stays slower than the workaround, people work around it. If the finance manager, frustrated with their IT team, can build their own tool on top of the building blocks shared by IT, they won’t bother setting up a new infrastructure or unsecured connectors.
Let’s make the IT build cycle simpler and faster, and business users will no longer have a reason to leave it.
This lever has a downside, which can become serious. Opening fast platforms to the business mechanically triggers an explosion of application creation on the user side, and without guardrails you replace one problem with another: hundreds of fragile, poorly maintained applications that do the same thing three times over, and no enterprise architecture vision left at all. Ease of creation then becomes a resilience and maintainability debt, which takes nothing away from the need to catalog, rationalize and maintain overall consistency.
Where do you draw the line between opening enough and opening too much? I don’t know how to draw it in advance, and I don’t think it exists in the absolute. It depends on the organization’s maturity, on its risk tolerance relative to the velocity it wants.
IT moves up a level, whether it likes it or not
The center of gravity is shifting. Software development is being democratized, and the value of IT is sliding toward consistency, architecture and control, while the ability to produce code stops being what sets it apart.
The business will not wait. If it thinks it is faster to build without IT, it will build without IT, and the organizations that manage to channel this energy will move faster than those that spend their time banning it.
Going from gatekeeper to provider of fast lanes, from after-the-fact controller to architect of the framework: that is the condition for not being overtaken, by your own business as much as by your competitors.
One line does not move, though. In a regulated sector, this ramp-up is only possible if it respects regulation and security. Speed that ignores compliance creates no advantage: it increases the risk, and the bill comes later.
And where you work, is IT still chasing after its shadow IT, or has it started using it to move up a notch?