Shadow AI: why banning it doesn't work, and what does instead

In most organizations I come across, the question "should we allow AI?" has already been settled — just not by management. Teams are generating business code and automations with AI, sometimes all the way to production, with no validation and no automated tests. That flow exists, it's growing, and it shows up on no dashboard.

It's called shadow AI. Here's how I govern it — without banning it.

Why banning it fails, every time

A ban doesn't remove the practice: it pushes it into the shadows. And by pushing it into the shadows, it removes the one thing still protecting you — your ability to see it.

The reason has nothing to do with indiscipline. It's mechanical: as long as the unofficial route is faster than the official one, a ban isn't a wall, it's a speed bump. Teams don't bypass the framework out of defiance; they bypass it because it costs more than going around it.

Hence the rule I apply: if compliance costs more effort than non-compliance, the framework is decorative. You don't lose control by allowing AI. You lose it by banning something you can't detect.

The default-route principle

The reversal fits in one sentence: don't build a barrier, open a corridor that's faster than the workaround.

A barrier gets bypassed. A default route gets taken — not out of obedience, but because it takes less effort than the alternative. In practice, that means the sanctioned path has to be ready to run and faster from day one than the improvised one. If it takes three weeks of compliance work before the first useful line gets written, nobody will take it, and you're back where you started.

A corridor means checkpoints — not a committee

The corridor isn't a review board: a review committee is too slow, and becomes one more thing to work around.

It's automatic checks placed at every step, each with a binary result: it passes or it blocks. No eyeballing, no interpretation. A red check stops the flow — not as a recommendation, as a mechanical halt.

The point that matters most to management: quality and security are inherited from a pre-approved foundation, not from the skill level of whoever is driving the AI. That's exactly what makes it acceptable for a non-developer to produce something that reaches production: it isn't their personal rigor holding the risk, it's the corridor.

The kit: the default route, made concrete

This is the tangible part, and it's public. The Foyer framework currently ships three kits — one per major technical stack (Python, PHP, Rust). Each one is a runnable skeleton, not a document:

Clone it, run it, it's green. On a fresh clone, the build and then the full set of checks pass green before the first line of business code. The starting point isn't a blank page, it's a base that already complies.
The AI agent replaces the example with your business domain; the foundation itself doesn't move. That's what carries the guarantee.
Nothing is locked in. The web framework and the storage approach are interchangeable choices: each kit ships at least two proven options per slot, swappable without touching a line of business logic.
No AI vendor lock-in either. The agent's behavior is described in Markdown and a state registry — open formats any model can read, whether it's hosted by an American vendor, a European one, or on your own infrastructure.

One point of honesty, because this is the kind of nuance that matters when someone sells you a framework: these checks run on your machine or in your containers, on demand. It isn't a hosted dashboard that lights up on its own — it's a harness your team runs, whose result depends on no third-party service.

Who decides what — the part management wants in writing

This is where the framework becomes a governance guarantee, not just a tool.

The agent settles reversible technical choices on its own, and announces them in one sentence instead of putting them to a vote. A business owner never gets asked "ORM or SQL?".
The business side decides only business matters, in plain language: "do we delete permanently, or archive?" rather than the jargon version. The rule is explicit in the framework: if a question contains a word the decision-maker would have to look up, it isn't a question — it's a default the agent owns.
Irreversible decisions stop the machine. The agent doesn't execute: it assembles the evidence, logs a pending arbitration in the shared registry, and hands over. A human decides, and the decision is written down along with the alternatives that were ruled out.

That's the "answerability" principle: nobody — not the agent, not me — acts with a responsibility they couldn't answer for in front of you.

Where to start: a scoped pilot

Not a transformation program. A pilot:

One kit, one volunteer team, the checks wired in.
Measure over a single iteration: real velocity, security incidents avoided, team peace of mind.
Open the corridor before the shadow becomes the norm — the longer you wait, the bigger the untracked flow gets, and the more the catch-up costs.

What this means for your organization

Your teams are already using AI. So the real question isn't whether you allow it, but whether what they produce passes through checks you chose — or through none at all.

If you'd like to look at what this would mean in your organization, let's talk. The framework and the kits are public and verifiable: gilmry.github.io/foyer.

And if you'd rather have something other than text, it's all below: the video version (8 minutes), the audio version (12 minutes), the original architecture note as a download — all three in French — and the playlist following how KoproGo is steered: project management, product direction, team leadership, on a real product rather than a textbook case.