Shadow IT 2.0: Shadow AI Applications Built Without IT

Shadow IT 2.0: business teams now build software, not just buy it

Classic shadow IT was easy to picture: a department paying for a SaaS subscription nobody approved, or a critical process living in a spreadsheet on someone's desktop. IT found out late, but at least a vendor somewhere maintained the product.

Shadow IT 2.0 is different. With AI coding assistants, app builders and agents, employees no longer just buy tools. They build them. Sales, finance and operations now produce working applications, automations and integrations themselves.

A few illustrative scenarios (not real clients) of what this looks like in an SMB:

• Sales: an AI-built quoting tool that reads pricing from the CRM and updates deal stages.
• Finance: a reconciliation script that downloads bank exports every night and matches them against the accounting system.
• Operations: a customer intake form, generated in an afternoon, that writes straight to a database.

Why now? The barrier to building has collapsed. These apps look polished, solve real problems and ship faster than any IT backlog. Many employees were already choosing their own AI tools: the 2024 Microsoft and LinkedIn Work Trend Index found that 78% of AI users were bringing their own AI tools to work. In a 2025 Gartner survey reported by Infosecurity Magazine, 69% of cybersecurity leaders had evidence or suspected that employees were using public generative AI at work.

Those figures measure AI use in general, not apps built by business teams. But once people have the tools, building with them is the obvious next step.

The intent is usually good. People build these tools to do their jobs better.

The problem isn't behaviour. It's that nobody owns the result.

Why shadow AI applications carry more risk than a rogue spreadsheet

When a spreadsheet goes wrong, the damage usually stays in the spreadsheet. An AI-built app acts. It calls APIs, writes to databases, sends emails and handles customer data.

They connect to real systems and real data

To get an app working, the person building it often pastes an API key or database password straight into the code or a prompt. Customer or employee data may end up in an external AI service nobody has assessed.

In Quebec, this brings Law 25 into play. According to the Commission d'accès à l'information, businesses must designate a person responsible for protecting personal information, run a privacy impact assessment before acquiring or developing an information system involving personal information, report confidentiality incidents that present a risk of serious harm, and keep an incident register. Administrative monetary penalties can reach $10 million or 2% of worldwide turnover. An app built without telling anyone that handles personal information skips this assessment.

Across Canada, federal, provincial and territorial privacy regulators jointly issued principles for generative AI in December 2023. They apply to organizations that use generative AI, not only those that build it, and they stress accountability and keeping personal information out of prompts unless that use is authorized. This is general context, not legal advice. Your privacy officer or legal counsel should assess specific cases.

Nobody owns the code once it works

Most of these apps have no source control, code review, tests or documentation. Everything sits with one person and one account. When that person changes roles or leaves, or when a library or API changes, the app breaks and nobody knows how to fix it.

Unreviewed generated code also tends to share the same gaps: missing authentication, weak input validation and outdated dependencies. In Veracode's 2025 GenAI Code Security Report, which tested more than 100 language models on 80 coding tasks, generated code introduced OWASP Top 10 vulnerabilities in 45% of cases. Those were controlled benchmarks, not production apps, but the lesson holds: code that works isn't necessarily secure.

They fail silently

The biggest danger is that nobody can see these apps. A process that used to be manual now depends on an app IT has never heard of, with no monitoring, backup or alerts. When it stops, or keeps running while producing wrong results, the first sign may be an angry customer or a month-end close that doesn't reconcile.

What shadow AI apps really cost: hidden liabilities on the balance sheet

Shadow AI rarely appears as a line item. Its cost builds up in places a CFO only notices after something goes wrong.

The available research measures shadow AI broadly, meaning AI tools used without approval, not apps built by business teams specifically. It is still the best available indicator:

• In IBM's 2025 Cost of a Data Breach Report, one in five organizations reported a breach due to shadow AI. Organizations with high levels of shadow AI paid USD 670,000 more in breach costs than those with little or none.
• In the same report, shadow AI incidents compromised personally identifiable information more often (65% versus a 53% global average), and intellectual property too (40% versus 33%).
• IBM's 2026 report puts the average cost of a data breach for Canadian organizations at a record CA$7.11 million.
• Gartner, as reported by Infosecurity Magazine, predicts that by 2030 half of enterprises will face delayed AI upgrades or rising maintenance costs because of unmanaged technical debt from generative AI use.

These numbers mostly reflect large organizations; we found no SMB- or Quebec-specific data. But a smaller company has less room to absorb the same kind of incident.

Beyond breaches, these are the cost categories to track:

• Incident exposure: investigation, notification, remediation and possible penalties.
• Rework: rebuilding an app properly once it has become critical.
• Duplicated tools: several teams paying for overlapping AI subscriptions.
• Hidden maintenance time: staff quietly spending hours keeping fragile tools running.
• Audit and compliance effort: working out afterward which data went where.

What happens inside AI-generated code over time is covered in our article on the hidden cost of AI-generated software. Here the focus is organizational: liabilities nobody has recorded.

Ban, ignore or govern: comparing the three executive responses

When leadership discovers shadow AI applications, it usually picks one of three responses.

Many organizations have no governance at all. In IBM's 2025 report, 63% of breached organizations had no AI governance policy or were still developing one, and among those with a policy, only 34% audited regularly for unsanctioned AI. Gartner's recommendations, as reported by Infosecurity Magazine, point the same way: set company-wide AI tool policies, audit regularly for shadow AI, and include generative AI risk in SaaS assessments.

Governance is the only response that keeps both the speed and the control.

A practical governance framework for AI apps built outside IT

The framework has four steps: discover what exists, classify it by risk, put guardrails in place, and promote critical apps into a proper engineering process. None of it requires a large IT department.

1. Discover: inventory what already exists

Start with a no-blame amnesty. Ask teams to declare the AI tools, scripts, automations and apps they use or have built, and make clear the goal is to support them, not punish them. Then cross-check single sign-on logs and expense reports for AI tool subscriptions. Expect to find more than you thought.

2. Classify: tier apps by data sensitivity and business criticality

Three tiers are enough for most SMBs:

• Personal productivity: helps one person, no sensitive data. Rule: approved tools only, no production data.
• Team tool: shared within a team, uses internal data. Rules: a named owner, credentials in a vault, documented data flows and a backup.
• Business-critical or customer-facing: a process or customer depends on it, or it handles personal information. Rules: source control, code review, automated tests, a CI/CD pipeline and a security review, plus a privacy impact assessment when personal information is involved.

3. Guardrail: approved tools, secrets management, data rules

• Publish a short list of approved AI tools and a simple way to request a new one.
• Keep production and personal data out of unapproved tools.
• Store credentials in a secrets vault, never in code or prompts.
• Give app accounts only the access they need (least privilege).
• Provide a sandbox with test data so people can experiment safely.

4. Promote: a clear path from prototype to production

Once an app reaches the business-critical tier, it moves into source control, CI/CD pipelines, code review and testing, for example in Azure DevOps, with a named owner. The engineering steps are covered in our article on going from prototype to production. What matters here is that the trigger is clear and agreed in advance.

Then comes a decision: harden or rebuild? Hardening makes sense when the scope is stable, the code is understandable and the data-handling issues can be fixed. Rebuilding as custom software makes sense when the security review finds structural problems (no real authentication model, for instance), when the app must integrate with several core systems or scale, or when nobody can explain how it works. AI speeds up development, but experienced developers still need to make this call. It is the kind of decision where Groupe Conseil CG's custom software development and DevOps consulting fit in.

What good looks like: IT as an enabler, not a gatekeeper

The goal is not to stop people from building. It is to make building safely the easiest option. Business teams prototype freely in a sandbox. IT provides templates, shared repositories and ready-made pipelines. Critical apps get real engineering support.

Every app that matters has three clear roles:

• Business owner: decides what the app should do and is accountable for its use.
• Technical owner: maintains the code, dependencies and deployments.
• Security and privacy review: approves data flows and access before production.

Hypothetical walkthrough. Take the quoting tool from the opening. During the amnesty, the sales manager declares it. It is classified business-critical because clients receive its output. Its API key moves from the code to a vault. The code goes into a shared repository, a developer reviews it, and authentication and input validation are added. A pipeline now deploys each change after automated tests. The sales manager stays business owner; IT becomes technical owner. The team keeps its tool, and the company knows where its data goes.

What leaders should measure

A few indicators tell you whether AI use is under control:

• Number of known AI-built apps, and the share with a named owner.
• Share of business-critical apps under source control and CI/CD.
• Number of AI tools in use versus approved.
• Time from a prototype request to a supported production release.
• Incidents or data-handling exceptions linked to unmanaged apps.

Review them quarterly. If the path from prototype to production is too slow, teams will go back to building in the shadows.

The next wave: AI agents will make shadow IT 2.0 harder to see

Agents that act on systems, sending emails, updating records, triggering payments, are already here. Anything ungoverned then has a bigger impact.

OWASP's Gen AI Security Project calls this risk "excessive agency": AI systems with too much functionality, permission or autonomy can take damaging actions. Its recommended mitigations match the framework above: least privilege, minimal extensions, human approval for high-impact actions, and monitoring. Gartner, as reported by Infosecurity Magazine, predicts that by 2030 more than 40% of organizations will suffer security and compliance incidents due to unauthorized AI tools.

Companies that set guardrails now will adopt AI faster, not slower, because they will know what is running, who owns it and what it can touch.

FAQ

What is shadow AI, and how is it different from traditional shadow IT?

Traditional shadow IT means buying or using unapproved tools, like a SaaS subscription or a critical spreadsheet. Shadow AI covers AI tools used without approval and, increasingly, apps, automations and agents employees build themselves with AI, often connected to real systems and data.

Should we ban ChatGPT and AI coding tools?

A ban usually pushes use onto personal devices and accounts, where IT sees nothing. An approved tool list, data rules and a clear path to production keep the productivity gains and make the risk visible.

How do we create an approved AI tool list without slowing teams down?

Keep the list short, publish a simple request process for new tools, and offer a sandbox with test data. Gartner, as reported by Infosecurity Magazine, also recommends including generative AI risk in SaaS assessments.

What minimum controls should an app built by a non-developer meet before it touches production data?

At minimum: a named owner, approved tools only, credentials in a vault, and least-privilege access. If it is business-critical or handles personal information, add source control, code review, tests and a security review.

Who is liable under Quebec's Law 25 if an AI-built app leaks customer data?

Law 25's obligations fall on the business, not only on the employee who built the app. Treat this as general information and consult your privacy officer or legal counsel for a specific case.

When should a business-built AI app be rebuilt instead of hardened?

Rebuild when the security review finds structural problems, when the app must integrate with several core systems or scale, or when nobody can explain how it works. Otherwise, hardening is often enough.

Shadow AI applications are a sign your teams want to move faster. Banning them doesn't work, and ignoring them builds risk nobody sees. A simple framework does: discover, classify, guardrail, promote. It turns scattered experiments into assets the company can rely on.

If you need help taking the apps your teams have built to production, whether by rebuilding them as custom software or moving them into DevOps, let's talk about your project.