AI Citizen Development Governance: Why Blocking Builders Backfires

The risk of AI-enabled citizen development is usually framed one way: people will build things they shouldn't. I want to suggest the risk points in the opposite direction, and it's a mistake with real consequences for AI citizen development governance. It isn't that people will build. It's that you'll try to stop them.

The question organizations are getting wrong

AI has handed a remarkable capability to people who have never written a line of code. A financial analyst can generate a Python script. A marketing manager can wire up an automated workflow. A product owner can build a small tool that solves a problem their team has lived with for months.

Watch how organizations respond, and a pattern emerges. Clamp down. Restrict access. Require approvals. Some even disable the very mechanisms that would make the whole thing safer.

That instinct is worth a closer look. It isn't a strategy. It's a protection response. Our brains are prediction machines, built to conserve energy by anticipating what comes next. When something arrives that we can't predict or control, hundreds of people suddenly able to build software, it registers as a threat, and we shut the gates. Understandable. Also backwards.

The question was never whether to let people build. They are already building, with or without permission. The real question at the heart of AI citizen development governance is whether you create an environment where people build well, or leave them to build badly.

This has happened before

We have navigated this terrain before. Cast your mind back about ten years, to self-serve reporting.

Before self-serve BI, getting a report meant submitting a request to a data team, waiting weeks, receiving something already slightly wrong by the time it arrived, and then working around it with an Excel file someone maintained under their desk.

Then organizations started giving people platforms: structured, governed environments with curated data sets, where anyone could build their own view of the business. Not raw access to everything. Curated access to the right things.

The result was an explosion of useful work, and the bottleneck at the data team's door dissolved.

AI-enabled citizen development is the same evolution, one step further. Instead of building reports, people are building tools, automations, and scripts. The principle is identical: give people governed access to the right building blocks. Not blanket prohibition. Not unlimited access.

Even before that, savvy financial analysts were developing complex systems using Excel macros and Access databases. The world didn’t collapse, business problems were solved, though IT often ended up with an operational nightmare at some point.

The blast radius framework for AI governance

Not all citizen development carries the same risk, and treating it as if it does is where governance usually goes wrong. My colleague, Peter Maddison, uses these factors when considering what he calls the “blast radius” of potential problems:

• how far can this go wrong?
• how many people does it affect?
• how much and what type of data is exposed?
• who has access, and to what?

Consider three locations on that risk map.

1. A financial analyst builds a script for their own use, pulling data they already have access to. If something breaks, the blast radius is one person and one workflow. Low risk.
2. That same script becomes the source data for a team's monthly reporting. The blast radius expands. Medium risk.
3. An AI agent gets write access to production systems and starts modifying data that feeds regulatory reporting. Now the blast radius is potentially the entire organization and its legal obligations. High risk.

The appropriate level of control scales with the blast radius. Personal use doesn't need an enterprise governance committee. Enterprise-wide impact does. Design governance around that distinction, and you can welcome the first category while protecting against the third.

The mechanism that matters most

A practical principle from the team that are handling this well: control the data and actions the agents can access. The only way to prevent a real “shoot yourself in the foot” experience is to deny agents access where they don’t belong. If there is a way for an agent to access your sensitive data and expose it to the world, it’ll happily do so on a malformed prompt.

It's tempting to restrict agent access to file systems and command lines directly. “Lock everything down!” But this is the wrong lever. The more effective path is to provide controlled tools: curated interfaces that let agents accomplish what they need, within defined boundaries. The agent isn't denied capability. It's given capability through a governed pathway.

This is also why disabling hooks in AI development environments concerns me, a step we have seen large, risk-averse organizations take when AI agents make them nervous. Hooks are the mechanism that lets you build governance into AI behavior: run this check before a task starts, enforce this policy before a tool is called. Disabling them in the name of restricting AI is like removing the guardrails from a highway to reduce traffic. The guardrails are what let you travel at speed safely.

If hooks make you nervous, that nervousness is information. The answer is to design better hooks, not to remove them. Relying solely on non-deterministic “rules” to control your agents behaviour is about as effective as telling the hungry kid with a sweet tooth “don’t eat the candy”.

What "governed platform" actually means in practice

The work here is less about technology selection and more about mapping the terrain. What can people access? What boundaries trigger an escalation to someone with more technical context? Where does self-serve end and professional engineering begin?

You don't need to build the platform from scratch. Most organizations already run governed low-code environments (Microsoft's Power Platform is the common example) designed to give people capability within defined limits. The platform is the easy part. The design questions are not.

There's a meaningful difference between building a report on curated data and modifying a production system. The former, almost anyone can do safely on the right platform. The latter requires an understanding of the SDLC, of test environments, of what it means to check and ship. Those concepts are second nature to developers. For everyone else, they are foreign territory, and our brains resist starting work in territory we can't map. Ambiguity doesn't just slow people down. It stops them.

The transition across that line needs to be designed, not left for individuals to stumble upon.

What Xodiac sees

Organizations steering through this well share a common stance. They treat the question of who can build what as a design challenge, not a policy problem.

They ask: What are the right building blocks to expose? What data can be read freely, and what requires additional controls before it's touched? How do we make it easy to do the safe thing, and harder, not impossible, to do the risky thing?

We don’t have to implement the code ourselves, and that isn't our job anymore. As roles shift, AI can write the code, and our job becomes making the delivery system visible: to surface who is building what, where the risk actually sits, and where decisions are being made by default rather than by design. That visibility creates shared understanding between the people who build and the people who answer for what gets built. From there, the organization can make good calls as the scenarios evolve, instead of relying on a policy written before anyone knew what citizen development would look like.

The goal was never an AI policy that covers every scenario. It's a delivery system healthy enough to make good decisions as the scenarios change. So a question worth sitting with: who decides what gets built in your organization, and was that decided by design, or by default?

Xodiac helps organizations build AI governance models, define risk boundaries, and create the structures that let people go fast safely. If your teams are building with AI tools and you're not certain the guardrails are in the right places, let's talk.