Your teams build applications with AI without IT. Why this new shadow IT is beyond your security and what governance to adopt.
Shadow AI has long designated a simple thing, the employee who pastes into ChatGPT what he should not. That time is over. In 2026, your teams no longer just question an AI, they build complete applications with it, plug them into your production systems and publish them on the open web, without the IT department or security being in the loop. The artifact moved from prompt to product, and the risk surface followed the same path.
The magnitude is no longer theoretical. A survey by the company RedAccess, relayed and verified in May by Axios and WIRED, identified nearly 380,000 applications built with tools like Lovable, Replit or Base44, all publicly accessible. More than two thousand leaked corporate or personal data without any access control, sometimes granting default administrator access to anyone who came across the URL. Financial data from a bank, non-anonymized customer conversations, clinical trials from a healthcare player. All indexed by search engines, and discovered not by a sophisticated attack, but by simple mapping of the web.
This is not the shadow IT you knew
The reflex would be to put all of this in the shadow IT box. This would be an error of analysis. Classic shadow IT remained narrow-minded. When a team opened a SaaS account on a bank card without warning, the data lived with an unsanctioned publisher, but an identity, logs and a governance surface existed regardless. The citizen developer equipped with AI reverses this logic. The application is tailor-made, the data is loaded by hand, the integrations are direct connections to your reference systems, and the finished product often lands on the public web. There is no longer a publisher to audit, only a collaborator, a platform and a URL.
The real mechanism is the decision gap
These collaborators are not malicious. These are competent people who solve a real problem faster than the organization can do, by doing exactly what the platform invites them to do. The problem lies elsewhere, in the gap between the ability to build and the understanding of what has been built. The tool has removed the friction that once required learning before deploying. We put it online without ever having acquired the mental model that would ask the only question that matters, who can access this and with what rights.
This gap is made worse by the platforms themselves. A documented vulnerability, referenced CVE-2025-48757, revealed faulty access policies in projects generated by Lovable, exposing data on more than 170 applications in production. The AI had generated the data layer, not the rules deciding who had the right to read it. However, these tools, which are by design aimed at non-technical profiles, tend to transfer responsibility for security to users who are unaware of its existence. It is a problem of governance before being a problem of individual negligence.
And it is the organization that answers
On the compliance side, the company remains responsible for what its employees deploy. A DIY application that collects data related to your brand exposes you to the GDPR as if your IT department had delivered it itself. The trust your customers place in you is not divided depending on whether the code comes from the product team or from a spreadsheet that became an application on a Friday afternoon. You answer in full, and you must be able to prove it.
The answer is not a tool purchase
The temptation, when reading these figures, is to look for the technical line of defense that would be missing from the arsenal. This is a false lead, because the category resides precisely in the interstices that your architecture leaves between its layers. The answer lies in four movements, none of which is an additional license.
Start with discovery, in a non-punitive way. Ask your teams what they have built, asking the question as an inventory and not as an audit, otherwise no one will answer you honestly. Then map, for each application reported, to which systems it is connected, by what mechanism, and especially if it can be reached publicly, because this reachability is the most actionable signal in the short term. Trace marked routes, that is, a sanctioned path with approved platforms, acceptable data categories and a minimum authentication standard, all configured securely by default. And accept that it will never be a one-off inventory, because the photograph taken this month will already be incomplete the following month.
But visibility isn’t enough, and that’s where most devices stop too soon. The decision-making gap does not close by seeing better, it closes by raising the competence of those who build. Secure default models, templates, minimal literacy about access controls and personal data weigh more on your actual exposure than just another dashboard.
The direction to take is now understood even by the regulators. The head of the British cybersecurity center took advantage of the last RSA Conference to call on the industry to design these tools secure from the start, stating that a ban was not a credible option. We won’t stop your teams from building, and it would be counterproductive to try. The only question for you is whether you put the safeguards in place before the first leak imposes them on you. The decision gap never closes on its own. It closes the day the organization decides to install the rails instead of waiting for the accident.
