The New AI Gold Rush

Something is happening in your organization right now, and if you haven't heard about it yet, you will soon. Your employees are using AI tools — ChatGPT, GitHub Copilot, Claude, and dozens of others — to build things. Automations. Data dashboards. Customer-facing apps. Internal trackers. Some of these tools are genuinely impressive, and the people building them are proud of what they've created.

And then they come to IT with a request: "Can we just plug this into the system?"

This is the rise of the Citizen AI — a term modeled on the well-established concept of the Citizen Developer, but accelerated dramatically by the power of modern AI tools. Where a Citizen Developer might spend weeks building a Power App, a Citizen AI can prompt their way to a working application in an afternoon. The capability gap between technical and non-technical employees has collapsed. The governance gap has not.

Citizen AI is not malice, not sabotage — it is the collision between an employee's newly-expanded capability and an organization's need for governance, security, and compliance. It is one of the fastest-growing IT risk categories we see across our client base, and most organizations are completely unprepared for it.

The "Just Plug It In" Conversation

The scenario plays out in variations, but the pattern is consistent. A motivated employee — often in sales, operations, or finance — discovers that an AI tool can write code, generate reports, or automate a workflow that previously took hours. They build something. It works. They're excited. They want to take it further.

The ask usually sounds reasonable on the surface:

  • "Can I give it read access to the customer database so it can pull the right data automatically?"
  • "I need it to connect to our production API — just for reporting, nothing destructive."
  • "I set it up on my laptop but we need it somewhere the team can all access it."
  • "The AI wrote a Python script that processes the daily export — can IT just run it on the server?"

Each of these requests sounds like a small, contained ask. In reality, each one is a potential opening into your production environment by a system that has not been assessed, approved, tested, backed up, secured, or insured.

What Doesn't Disappear When AI Writes the Code

The single biggest misconception we encounter is this: because AI can write a working application quickly, the hard parts of IT must be easier too. They are not. Every obligation that existed before AI exists after it — and in some cases, the speed of Citizen AI development creates new risks precisely because it removes the natural friction that used to slow things down.

Production Data Access Controls

Your production database contains your most sensitive organizational data: customer records, financial transactions, employee information, intellectual property. Access controls to that data were designed and maintained by your IT team over years — with specific users, roles, and permissions granted for specific reasons, with audit trails, and with the assumption that every system touching that data was reviewed and approved.

A Citizen AI application that "just needs read access" is a new, unreviewed system making requests your access control framework was never designed to evaluate. If the app has a security flaw — a SQL injection vulnerability, an exposed API key, a misconfigured authentication layer — it becomes an attack surface in your most sensitive environment. Worse, because the application was written by an AI and may not be fully understood by the person who prompted it, the person requesting access may not know what data the app actually reads, stores, or transmits.

Regulatory Compliance

If your organization handles health information, financial records, personal data, or government-regulated data, you operate under compliance frameworks — HIPAA, NIST 800-171, ISO 27001, SOC 2, PCI-DSS, or others. These frameworks do not have an exception for "it was built with AI." Every system that touches regulated data must be reviewed, documented, and controlled according to the same standards as every other system.

The compliance implications run deep:

  • Data residency and processing agreements: If a Citizen AI application sends data to a third-party AI API for processing, that API provider becomes a data processor under HIPAA and GDPR. Do you have a Business Associate Agreement or Data Processing Agreement with that provider? Almost certainly not.
  • Audit trails: Compliance frameworks require documented change management. A Citizen AI application introduced outside of your change management process creates an undocumented system in your environment — a finding that can fail an audit.
  • Minimum necessary access: HIPAA's minimum necessary standard requires that data access be limited to what is strictly required. An AI-built app with broad database access typically fails this standard immediately.

A compliance violation triggered by a well-intentioned Citizen AI project carries the same regulatory weight as any other violation. The fact that it was built to help the organization is not a mitigating factor in an OCR investigation or a SOC 2 audit finding.

Cyber Insurance

This is the risk that surprises organizations the most. Your cyber insurance policy contains a section on authorized systems and approved software. When you purchased that policy, your insurer made underwriting decisions based on your disclosed IT environment — the systems you run, the controls you have in place, and the governance processes you follow.

Most cyber policies contain language excluding coverage for losses arising from unauthorized access, unapproved systems, or circumvention of security controls. A Citizen AI application that was never approved by IT, never assessed for security, and never added to your system inventory is precisely the kind of system that can trigger an exclusion when things go wrong.

Consider the scenario: a Citizen AI application running on an employee's laptop or on an unmanaged cloud account is compromised. Customer data is exfiltrated through the application. You file a claim. Your insurer asks for documentation of the compromised system and its approval status. There is none. The claim is denied — or significantly reduced — on the grounds that the system was outside your approved IT environment.

This is not a hypothetical. We are already seeing insurers ask detailed questions about Citizen AI governance policies and shadow AI controls as part of the renewal process. Organizations without documented AI governance frameworks are facing higher premiums and reduced coverage.

Architecture and Backup

Your IT team maintains your infrastructure with a specific architecture in mind: defined systems, documented integrations, backup schedules, disaster recovery plans, and lifecycle management processes. Citizen AI applications exist outside this architecture by definition.

When a Citizen AI app becomes operationally critical — and they do, faster than anyone expects — you have a system with no backup strategy, no documented recovery process, no owner who understands the codebase, and no upgrade path when the underlying AI tool changes its API or pricing. The employee who built it may leave the organization, and with them goes whatever tribal knowledge existed about how it works.

The long-term architectural debt from Citizen AI proliferation is significant. Every one-off integration that bypasses your standard processes creates technical debt that compounds. Three months from now, your IT team will be asked to support, debug, and maintain systems they were never involved in building — while also managing the security and compliance exposure those systems created.

The Real Cost Equation

The business case for Citizen AI governance is not just about risk avoidance. It is about understanding the true total cost of ungoverned AI adoption versus the cost of doing it right.

IT Remediation Hours

When a Citizen AI project surfaces — whether through an incident, an audit, or a support request — your IT team must triage and remediate it. This means auditing what the application does, what data it accesses, how it was built, whether it has security vulnerabilities, and what compliance obligations it triggers. This is skilled, expensive work that displaces planned projects.

Based on what we see in our managed IT practice, a single Citizen AI remediation engagement — from discovery through risk assessment, remediation, documentation, and compliance review — routinely runs 20 to 60 hours of IT labor. At blended IT rates, that is $3,000 to $10,000 per incident. Organizations with active AI adoption and no governance framework face multiple incidents per quarter.

Employee Productivity Drain

There is a counterintuitive cost that organizations often miss: the employee who built the Citizen AI application. Once the application becomes operationally important, that employee becomes informally responsible for its maintenance, troubleshooting, and feature requests — work that has nothing to do with their actual job. A salesperson debugging a Python script is not selling. A finance analyst triaging an API error is not analyzing. The productivity gain that motivated the original project gets consumed by the ongoing maintenance burden of a system that was never built to be maintained.

Governance does not prevent employees from using AI productively. It channels that productivity into systems that IT can support properly — so the employee gets the benefit without inheriting the operational burden.

Liability Exposure

The liability exposure from ungoverned Citizen AI is the hardest cost to quantify and the most important to prevent. A single data exposure event involving a Citizen AI application can trigger regulatory penalties, customer notification obligations, litigation, and reputational damage that dwarfs the cost of any governance program.

Under HIPAA, a breach of unsecured protected health information carries civil penalties up to $1.9 million per violation category per year. Under GDPR, fines can reach 4% of global annual revenue. Under various state privacy laws, per-record penalties add up quickly when multiplied across a customer database. These numbers are not theoretical — they are the outcomes that regulators impose when organizations cannot demonstrate that adequate controls were in place.

The question is not whether your organization can afford to implement Citizen AI governance. The question is whether it can afford not to.

What Good Citizen AI Governance Looks Like

Effective Citizen AI governance is not about preventing employees from using AI. The organizations that try to ban AI tools entirely lose the productivity benefits and simply drive the activity underground. Effective governance is about creating a structured path for AI adoption that captures the business value while managing the risk.

The foundational elements of a practical Citizen AI governance framework include:

  • A Citizen AI Acceptable Use Policy that clearly defines what AI tools employees may use for what purposes, what data classifications are permitted as AI inputs, and what the approval process is for new AI-assisted workflows.
  • A Shadow AI Discovery Process that proactively identifies AI tools and applications already in use across the organization — before they become incidents.
  • A Citizen AI Integration Request Workflow that gives employees a clear, fast path to get their AI projects evaluated and approved rather than forcing them to choose between abandoning a useful tool and going around IT.
  • Data Classification Controls that define which data may be used as AI inputs, under what conditions, and with what contractual protections from AI providers.
  • Vendor Vetting Standards for AI tools — covering data retention policies, model training practices, security certifications, and DPA/BAA availability.
  • Incident Response Procedures specific to AI-related data exposure, including notification chains and evidence preservation for regulatory reporting.

The governance framework does not need to be elaborate to be effective. In most organizations, a clear policy, a simple request workflow, and consistent enforcement are sufficient to close the largest risk gaps. The goal is not to create bureaucracy — it is to create accountability.

Starting the Conversation

The most important first step is to acknowledge that Citizen AI is almost certainly already present in your organization. According to recent workforce surveys, more than 70% of employees report using AI tools for work — and the majority do so without explicit IT knowledge or approval. The question is not whether your organization has Citizen AI. It is how much exposure that activity has already created.

At Axiom IT Group, our Citizen AI Governance assessment starts with a shadow AI discovery scan across your environment — identifying tools in use, integrations in place, and data exposure already present. From there, we work with your leadership to build a governance framework that fits your organization's risk tolerance, compliance obligations, and culture. We help you say yes to AI adoption in a way that protects the organization.

Your employees' good intentions are an asset. With the right governance in place, they remain one.

The Offboarding Time Bomb: When the Builder Leaves

Every risk described above intensifies the moment the employee who built the Citizen AI application leaves the organization. This is the scenario IT teams dread most — and it is playing out at organizations of every size as the first wave of Citizen AI builders begins to change jobs, retire, or be reorganized out of their roles.

Silent App Failures: The Connection Drop

Most Citizen AI apps and Power Automate flows run on the personal credentials and API connections of the person who built them. This is a structural problem baked into how these tools are most commonly deployed by non-technical users — the easiest path to "make it work" is to connect it under your own account.

What happens when IT deactivates the former employee's account in Microsoft Entra ID is this: their underlying OAuth tokens and API connections invalidate immediately. The app does not display an error. It does not send an alert. It simply stops functioning. Scheduled data flows stop running. Approval notifications are never sent. Database writes silently fail. The team using the application often does not realize anything is wrong until a business process that was quietly depending on the app grinds to a halt — sometimes days or weeks later.

The discovery conversation is always the same: "The tool stopped working. We don't know who built it or how it works. Can IT fix it?" IT then inherits a system they have never seen, connected to credentials that no longer exist, with no documentation and no contact person to ask.

Orphaned State and Locked Admin Controls

If the departing employee was the sole owner of a Power App, a custom script, or a Dataverse solution, that asset becomes an orphan the moment they leave. The end users who rely on it daily — typically with User or Run-Only permissions — cannot edit formulas, add new team members, adjust database structures, or repair broken connections. They can only use the application, and once it breaks, they can do nothing to fix it.

IT administrators must then intervene using PowerShell or administrative portals to manually force-reassign primary ownership to another user before any remediation work can even begin. In a Power Platform environment without centralized governance, IT may not even know the application exists until the support ticket arrives — at which point the business impact is already underway.

Microsoft has added tooling to address orphaned app discovery in recent versions of the Power Platform Admin Center, but these tools only help organizations that already have IT oversight of their Power Platform environment. If the governance structure was not in place before the employee left, the discovery process is manual and time-consuming.

The Black Box Spaghetti Code Dilemma

Even if IT successfully reassigns ownership of an orphaned Citizen AI application, the knowledge problem remains unsolved. Non-technical builders rarely document their AI prompts, variable structures, database schemas, conditional logic, or the reasoning behind their design decisions. The application exists, but the understanding of why it was built the way it was left with the person who built it.

When the application inevitably breaks — and it will, because AI-generated code accumulates brittle assumptions about the environment it was built in — the new owner cannot fix it. IT is called in to debug a system of AI-generated logic they did not write, in a language and framework they may not specialize in, with no documentation and no way to ask the original developer questions. The result is a reverse-engineering project that costs more in billable hours than it would have cost to build a professionally architected application from scratch, with the added pressure of a broken business process waiting to be restored.

This is not a hypothetical scenario. It is the most common way Citizen AI projects end.

Security and Compliance Backdoors

Leaving Citizen AI applications unmanaged when an employee exits creates security exposure that can persist long after the individual is gone.

If the employee embedded personal API keys, third-party webhooks, or hardcoded credentials into the application — a common shortcut in AI-generated code — those connections may continue making external data calls out of the network even after the employee's corporate account is deactivated. The connection is not to the company's managed service accounts. It is to the former employee's personal OpenAI account, their personal Zapier subscription, or their individual GitHub token. Revoking corporate credentials does not revoke those.

If the employee built a Citizen AI application outside the governed environment — on a personal GitHub repository, deployed to a personal Vercel account, or running on a local Python environment on their work laptop — proprietary company data, source code, and business logic may be stranded on personal assets entirely outside IT's reach. In regulated industries, this is not a nuisance. It is a reportable data governance incident.

The full cost of an unmanaged Citizen AI offboarding — covering the IT remediation hours, the business disruption, the security audit, the potential compliance review, and the rebuild of whatever was lost — can easily exceed $15,000 to $40,000 for a single application that a single employee spent an afternoon building.

The Quiet Rollback: What Is Actually Happening at Scale

Here is the reality that vendor marketing will not tell you: across industries, the organizations that moved fastest on ungoverned Citizen AI are now quietly reversing course.

The most publicized examples came from the enterprise AI adoption wave of 2023. Samsung banned internal use of generative AI tools in April 2023 after engineers accidentally uploaded proprietary source code and internal meeting notes to ChatGPT — data that Samsung had no contractual mechanism to have removed from OpenAI's training pipeline. The ban was implemented within weeks of the incident becoming public. Apple followed in May 2023, restricting employee use of ChatGPT and GitHub Copilot over concerns about confidential data exposure, as reported by the Wall Street Journal. Goldman Sachs, JPMorgan Chase, Citigroup, and Verizon all implemented restrictions on employee use of external AI tools during the same period — not because they were opposed to AI, but because their legal, compliance, and risk teams had evaluated the data exposure implications and found them unacceptable without proper controls.

These are not small or technologically unsophisticated organizations. They are institutions with thousands of engineers and billions of dollars in technology budgets. Their conclusion was not that AI is bad. Their conclusion was that AI without governance is a liability.

The pattern extends beyond consumer AI tools. Organizations that rushed to enable Power Platform Citizen Development — Microsoft's own framework for empowering non-technical builders — are discovering that the sprawl of ungoverned apps and flows has created environments that no one fully understands, that IT cannot efficiently support, and that carry data exposure and compliance risk they did not anticipate. Gartner research published in 2024 identified uncontrolled SaaS and citizen development sprawl as a top contributor to unplanned IT spend, with organizations reporting that remediating ungoverned Citizen AI environments was consuming budget that had been allocated to planned digital transformation projects.

The rollback is quiet because organizations do not issue press releases when they reverse course on an internal initiative. The pattern is visible, however, to any IT team that is paying attention: the pilot programs that were going to "empower every employee to be a developer" are being scoped back to governed, IT-partnered programs with proper oversight. The tools are the same. The governance structure is different.

This is not a failure of AI. It is a calibration — the market working out the difference between what AI can do and what an organization can responsibly deploy without the governance infrastructure to support it. The organizations emerging strongest from this calibration are the ones that built governance frameworks early enough to capture the productivity benefits without absorbing the remediation costs.