From shadow AI to governed vibe-coded apps: The CIO’s guide

How to let business teams build and maintain internal tools without making IT the default support team.

AI has made it easier for business teams to build their own internal tools and agentic workflows. It hasn’t removed the inheritance tax for IT: securing and maintaining those applications.

As a CIO or senior IT leader, you have to decide who will own what employees create. Teams that can’t get an app request prioritized can now build it themselves. But if your engineers still need to secure the result, make it reliable, and handle future changes, faster building can increase demand on the same constrained team.

In conversations with IT leaders, I hear that tension repeatedly. They want employees to solve more of their own problems. They also need to know which applications exist, what data they access, and who remains responsible when something breaks or the builder leaves.

Ownership is becoming a defining constraint on business-led development. If every application requires an engineering handoff, we’ve made prototyping more accessible, without resolving the capacity problem.

How IT leaders are approaching this

In conversations with IT and engineering leaders, I hear two common responses, each with a different division of responsibility:

Let business teams build with vibe-coding tools

Vibe-coding tools let business teams turn an idea into a working prototype without waiting for engineering. They can test a workflow and demonstrate what they need.

But the result is a generated codebase. Someone still needs to review it, verify security and permissions, establish how it will be hosted, and maintain it when integrations fail or requirements change. For business teams, that someone doesn’t exist.

Without a clear support owner, the application either comes back to IT or starts being used without anyone responsible for keeping it secure and reliable. Faster prototyping doesn’t resolve who can own the application beyond the initial build.

Build with an AI coding agent and a DIY stack

An AI coding agent, a database, and a hosting provider give your engineers flexibility in what they build and where it runs. If you have the technical capacity, this can be the right approach.

But your organization still has to connect and operate the stack. Authentication, permissions, integrations, logging, and deployment must be implemented or configured and maintained. Shared services can reduce duplication, but each application still needs support for its access rules, business logic, and dependencies.

For routine departmental tools, a small workflow improvement can become an ongoing engineering commitment. Your engineers take on another application to maintain, while business teams return to the queue whenever they need changes.

The CIO’s question is no longer “Can we build this?” It’s “Does this deserve a permanent place in our engineering workload?”

The new operating model: an IT-approved path to secure business-led app development

The question I think IT leaders need to answer is: how do we give business teams a sanctioned, governed way to build without inheriting ownership of their vibe coded apps?

That path needs to work beyond the prototype. Teams should be able to build and update applications within boundaries your team defines, without returning to engineering for every change.

Let business teams build within boundaries IT controls

Your team defines who can build, which systems applications can connect to, and how they can be shared. The environment needs to enforce those boundaries and give IT visibility into what’s running, who owns it, and what data it accesses.

Avoid another codebase for engineering to maintain

Business teams need tools they can maintain through understandable configuration, supported by infrastructure they don’t operate themselves. Everyday changes should stay with the business. IT handles agreed technical escalations and reviews changes that increase risk or complexity.

Enforce security independently of the generated interface

Permissions, data visibility, and edit rules need to operate independently of AI-generated screens. Business teams should be able to configure access within approved controls without implementing their own authorization logic. Changing an interface should not change what a user is allowed to access.

Reduce the infrastructure each team must manage

Keeping application ownership with the business also means limiting the underlying infrastructure it must operate. The platform should provide the agreed hosting, monitoring, and recovery capabilities, with clear responsibilities for the provider, IT, and the business team.

How Softr puts this operating model into practice

Softr is the secure platform for building and running business applications, with IT governance and infrastructure built in.

We built Softr around a clear division of responsibility: business teams own their applications, IT governs access and use, and the platform provides the technical foundation. Making that division work requires more than faster app generation. It requires security enforcement, maintainability, and infrastructure to be part of the platform itself.

• ‍IT stays in control: IT defines and who can build, manage, and publish applications, and establishes which company data sources they’re approved to use. Workspace roles, identity controls, and app permissions support those boundaries. Connection credentials stay server-side, while audit logs provide visibility into application and database changes.‍
• Business teams own more than the prototype. Teams build and update applications using AI, including through Claude or Codex via MCP. Visual controls make the app’s structure, workflows, data connections, and permissions understandable and editable without reading code or relying on an LLM to explain how it works. Core capabilities run on platform-managed components, so engineering doesn’t inherit a separate codebase to maintain.‍
• Security is by design. Access permissions, data visibility, and edit rules are enforced by Softr’s backend, outside AI-generated interface code. Connection credentials stay server-side. Encryption, SOC 2 Type II reporting, and GDPR documentation support your security assessment.‍
• Infrastructure comes built in. Managed hosting, databases, workflows, monitoring, and backups reduce the stack your team must assemble and operate for each application.

Evaluate ownership beyond the prototype

When you evaluate an AI app-building platform, ask what happens after launch.

Can business teams keep improving their applications while your team retains visibility and control over access, data connections, and use? Or does every tool become another codebase and support commitment for engineering?

That’s the standard I believe this next phase of business-led development needs to meet: broader ownership, enforceable controls, and less infrastructure to assemble and maintain. Faster prototyping only addresses part of the capacity problem if engineering still inherits every application.

Bring your use case and IT requirements to our team. We’ll show how Softr supports building, access controls, and ongoing changes, so you can assess what business teams could own and where IT would remain involved.

Talk to our team →