Something significant is happening inside large enterprises, and most technology leaders feel it before they can fully articulate it.
The marketing analyst is building a campaign attribution tool over a weekend. The FP&A manager has stitched together a forecasting workflow with AI and a few spreadsheet plugins. Your own engineers are shipping in days what used to take quarters. It’s possible the technology leader themselves are participating and even driving this energy.
The line between “software user” and “software builder” is blurring across every function.
This isn’t shadow IT in the old sense. It’s something more interesting, and potentially, more powerful.
The question isn’t whether to allow it. That ship has sailed. The question is how to channel it without compromising security, compliance, or the operational stability your business depends on.
In my experience, the CIOs who win this moment will be the ones who shift from gatekeeping to enabling, while quietly building the guardrails that keep the whole thing from going sideways.
The New Builder Landscape
Internal builders fall into two camps, and they need different things from the technology org to be successful.
The first is your engineering team, now using AI coding assistants and agents as part of their standard workflow. Tools like Kilo, Cursor, and Claude Code are increasingly common, and the results are tangible: faster shipping cycles, cleaner code, and shorter time-to-deploy.
The second is the business builder. The non-IT employee who has discovered that with a low-code platform, a sanctioned AI tool, and some Excel-grade logic, they can solve problems they used to file tickets for. These are your power users in finance, operations, marketing, and supply chain.
Both are net positives for the organization. Both introduce new risk surfaces. Treating them the same way is likely a mistake.
Step One: Define What “Sanctioned” Actually Means
The fastest way to lose control is to ban everything and pretend that solves it. The second fastest is to allow everything and hope for the best.
The middle path is a clear, published list or shared understanding of sanctioned tools, with the security review already completed, the data handling rules already documented, and the commercial licensing already negotiated.
For your engineering team, this likely means an approved AI coding assistant tied to your SSO, with enterprise-grade data handling that excludes your code from training data. It also means a clear position on what these tools can and cannot touch: production secrets, customer PII, regulated data.
For your business builders, this means a curated set of low-code and AI platforms with data connectors that respect your existing identity and access framework. Enforcement is still on the plate of the technology team and one should plan for the worst case scenario, while hoping for the best.
The goal is simple: make the sanctioned path the easiest path. When the approved tool is faster to access than the renegade alternative, shadow IT shrinks on its own.
Step Two: Tier the Guardrails by Risk
Not every internally built tool carries the same risk profile. A marketing dashboard pulling from a sanctioned data warehouse is not the same as a finance team building a workflow that touches the general ledger.
Approaching through a no-nonsense framework can be useful and weed out noise:
- Tier 1 – Personal Productivity: Individual workflows, summarization, drafting, internal analysis. Minimal review. Light governance. Let people build.
- Tier 2 – Team Workflows: Tools shared across a department, integrated with sanctioned data sources, but not touching customer-facing or regulated data. Requires registration in a central catalog, basic security review, and an owner of record.
- Tier 3 – Business-Critical: Anything that touches customer data, financial systems, regulated workflows, or external-facing processes. Full IT review, formal change management, and ongoing monitoring. No exceptions.
The trick is making Tier 1 and Tier 2 frictionless. If your builders have to wait six weeks for personal productivity approval, they’ll route around you. Reserve your security horsepower for the things that genuinely warrant it.
Step Three: Build the Catalog Before You Need It
Most organizations discover their internal building boom only when something breaks. Someone leaves the company and three departments suddenly can’t complete a critical task. A “small automation” turns out to be the load-bearing wall for a significant process.
A simple internal catalog solves more problems than it creates. This is how you potentially prevent the citizen-developer equivalent of SaaS sprawl. It’s also how you spot consolidation opportunities, when three departments have built nearly identical tools, that’s a signal for a centrally supported solution.
Step Four: Make Security Invisible, Not Absent
The fastest way to lose your builders is to drown them in security theater. The fastest way to lose your security posture and leadership is to wave it all through.
The answer is to embed security into the platforms themselves, not bolt it on through process.
When the guardrails are in the tool, the builder doesn’t have to think about them. They just build. Security becomes part of the path, not a stop along it.
For the engineering side, this means automated security scans built into the development process, checks that catch passwords or API keys before they get committed, and a combination of humans and tools reviewing AI-generated code before it goes live.
Step Five: Train for the New Skill Stack
Internal building is a skill, and most of your workforce hasn’t been formally taught it.
Prompt engineering, basic data literacy, when to use a workflow tool versus when to file a ticket, recognizing what should be escalated to IT, these are now baseline professional skills, not niche specialties.
I’ve had success with a tiered training approach, similar to AI rollouts:
- Builders get tool-specific training and best practices for the platforms they’re using. 1:1 sessions with folks exerting the most energy is where you will get the most return.
- Managers get training on how to evaluate what their teams are building and when to flag it for IT review.
- IT and security get training on supporting builders without becoming a bottleneck.
The cultural shift is the hardest part. Your IT team has to genuinely believe that empowered builders are a feature, not a threat to their relevance.
Spoiler: they make IT more relevant, not less, because someone has to architect the platform all of this runs on.
From Here
The rise of the internal builder isn’t a trend to manage. It’s a structural shift in how work gets done, and it’s accelerating with every new AI capability that ships.
The leaders who treat this as a threat will spend the next three years writing policies that nobody follows. The CIOs who treat it as an opportunity will build the platforms, guardrails, and culture that could turn every employee into a force multiplier for the business.
The goal isn’t to control every line of code that gets written inside your organization. That was never realistic, and it’s certainly not realistic now. The goal is to make the safe path the obvious path, and then get out of the way.
Sanction the right tools. Tier the risk. Catalog what gets built. Embed the security. Train the people.
Build something great.
Trusted insights for technology leaders
Our readers are CIOs, CTOs, and senior IT executives who rely on The National CIO Review for smart, curated takes on the trends shaping the enterprise, from GenAI to cybersecurity and beyond.
Subscribe to our 4x a week newsletter to keep up with the insights that matter.
