Long live the citizen developer -- just don't confuse empowerment with anarchy.
Citizen development is not new. Low-code and no-code tools have long enabled employees outside IT to contribute to the cause by building small apps, dashboards and workflow automations.
But those tools still required some level of technical comfort. A business user needed to understand the platform, the workflow, the components and the limits of what the tool could reasonably do.
Business users in HR, ERP, CX, finance, operations and other areas can now use natural language prompts to help create applications, tools, automations, agents and workflows. They use their words, and AI helps handle more of the underlying logic or code structure.
Simple, right?
Yes and no.
GenAI changes the citizen developer equation
The barrier has shifted from "Who can code?" or "Who knows how to use the low-code tool?" to "Who understands the problem well enough to describe what should be built?"
That is a real change. It gives business users of all kinds and technical abilities more room to take ideas and put them into action.
On one hand, that strengthens one of the chief promises of citizen development: moving problem-solving closer to the work.
A team can automate a local bottleneck, build a simple tool, test an idea or support a routine decision without forcing every request through a central IT backlog. That matters because business users often know the annoying handoff, spreadsheet workaround, reporting gap or approval delay better than anyone else.
But the same shift also raises the stakes.
AI-powered citizen development is not just about shortcuts. The tools and outputs citizen developers create can touch important organizational information, including customer data, employee data, financial workflows, operational decisions and business-critical systems.
That makes it essential for the enterprise to know what a tool can access, what it can change, who owns it and when it needs review. Otherwise, business-user innovation can turn into a new layer of shadow AI.
The goal should not be to shut citizen developers down. It should be to give them room to build without letting useful local tools drift outside the governance, security and compliance boundaries of the enterprise itself.
Generative AI expands what citizen developers can build, but it also raises the stakes around governance, security, data access and ownership.
Shadow AI is the reason for a real program
That is why shadow AI matters here.
Business users are not going to stop experimenting just because IT has not built a formal program around citizen AI. If the tools are easy enough to use, the business pressure is strong enough and the backlog is long enough, people will find ways to solve their own problems.
Sometimes that is exactly where useful innovation starts.
But it can also create a mess.
A team might build an AI tool that solves a local problem but connects to sensitive data. Another team might build something similar in a different platform. A workflow might start as a personal productivity shortcut and quietly become part of how a department does real work. No one may know who owns it, what data it uses, whether it is secure or what happens if it breaks.
That is the shadow IT problem in a new form. Only now, it is shadow AI.
An official citizen development program is one way to bring that work into the open. The point is not to smother business-user creativity. It is to make sure useful local experimentation happens inside a model the enterprise can see, govern and support.
In that sense, a citizen AI program is not just an innovation program. It is also a visibility program.
Citizen AI needs a program, not a free-for-all
In practical terms, citizen development programs should borrow from what enterprises have learned -- often the hard way -- about AI adoption over the last few years.
That means a common data foundation, appropriate governance, security and compliance practices, narrow use cases, interoperability and, increasingly, orchestration. Otherwise, AI tools, agents, workflows and automations can start to conflict with one another or drift outside the boundaries of the business.
Human oversight matters too.
That does not make citizen development any less useful. In many organizations, data science, AI and IT teams are already overwhelmed with requests. They cannot build every useful AI application, agent or workflow that a business team wants. Citizen development programs can help relieve that pressure, as long as the company is clear about what business users can build, what data they can touch and when IT needs to step in.
Critical functions -- even those first identified or prototyped by business users -- should still fall under IT's domain. That is how a useful local tool becomes an asset for the company instead of a liability.
Ducker Carlisle offers a useful example. The consulting firm started a citizen developer program after its data science and AI specialists were overwhelmed with requests for AI applications. About 80 of its 200 employees volunteered to take part, with participants spread across research, sales, HR, finance and other departments. The resulting AI apps automated dozens of tasks, cut operating costs by 3% and freed IT staff for other projects, according to the company.
That shows the benefit of a citizen development program when it is implemented with forethought and guardrails. Business users are not enterprise software engineers, and they should not be asked to act like they are.
The goal is more modest and more realistic: Let business users build useful AI agents and workflows that automate specific tasks and support the human workforce.
This is not a free-for-all. Business users are not being asked to create full enterprise software with service-level agreements, production infrastructure and all the engineering discipline that comes with that.
Citizen AI should not turn employees into software vendors. It should give business users room to solve problems close to the work, while IT keeps a path for successful or critical tools to become real enterprise assets.
Citizen AI works best as a pressure-release valve
That staged model matters.
Business users can build useful local AI tools. Then the company can decide which ones should stay local, which ones need review and which ones are important enough for IT to adopt, rebuild or support as company assets.
A local AI tool might address a narrow workflow, a repeated task or a small automation need. Enterprise software has a much larger purview. It needs stronger ownership, support, security, infrastructure, integration, documentation and accountability.
That is where IT should step in: when a tool gets popular, touches sensitive data, changes a workflow, affects customers, performs a critical function or starts to look like something the business now depends on.
Citizen AI works best as a pressure-release valve for business demand, not as a substitute for enterprise software discipline.
Citizen AI works best as a pressure-release valve for business demand, not as a substitute for enterprise software discipline.
That is the practical middle ground.
The enterprise should not pretend citizen developers are not going to use AI. It also should not pretend every business-built tool belongs in production. The point is to give business users a sanctioned way to solve real problems, while making sure useful local tools can be seen, reviewed and supported when they become important.
That is a healthier model than waiting for shadow AI to spread and then trying to clean it up later.
The promise of citizen AI is not that every employee becomes a developer. The promise is that more of the people closest to the work can help improve it.
That is worth encouraging. Just not as a free-for-all.
James Alan Miller is a veteran technology editor and writer who leads Informa TechTarget's Enterprise Software group. He oversees coverage of ERP & Supply Chain, HR Software, Customer Experience, Communications & Collaboration and End-User Computing topics.
