Its one of the things Sam Altman has flagged along with chip shortages thats blocking uptake in enterprise.
We saw the same story with Cloud. Central IT vs local business head fought over who had control of the cloud account. Local boss didnt want to wait for central IT, so they would swipe card and create shadow IT. Then we got sprawl where hundreds of teams had cloud accounts no one knew about and suddenly surprise bills would turn up. Too much sprawl triggers security and other issues and centralisation reasserts itself. Someone builds something good locally and leaves and local team has no clue where/how it runs. That type of stuff brings back centralisation.
In short term whoever has more political capital wins. Longer term, orgs that handle it well usually define what's safe to selfserve (low risk, non production) and develop fast path for review of anything else, rather than blocking it and pushing it underground.
The first is what you mentioned in this post. Tools that are widely used, built and maintained by a dedicated team, and carry highly sensitive data or act as critical infrastructure.
The second is small, simple tools built by an individual or team to address a very specific problem in a tailored way.
The first type doesn’t need to change. The same dedicated team can keep bringing their knowledge and abilities, and the use of AI can broaden that across the organization. The second type is something that is owned by a specific person, or a team. These should not be handed off to an IT or engineering team to maintain, and should be built, owned, and maintained by the user.
I work on an open-source project called Pando (https://github.com/trypando/pando) that helps give these sort of things a place, and makes it easy to track what users are building by enabling them to take ownership over their apps.