A management control, sales administration, supply chain or HR manager did not wait for the IT department. They opened a personal ChatGPT or Claude account one weekend, and built a tool that automates part of their team's work. Three months later, the team is using it every day. The tables fill up faster, chase-up emails go out automatically, and variances are detected before month-end closing.
The problem arises afterwards. The tool runs on a personal account, with company data in it, and only one person knows how it works. The IT department has just found out, or is going to find out in the next few weeks.
This scenario repeats itself across entire departments, in various forms. Corporate AI governance is rarely considered when choosing a tool: it arises when an unchosen tool already exists, works, and a decision has to be made about what to do with it. It is this decision that matters, not the rulebook one would have liked to write beforehand.
This is not an isolated case. According to the 2024 Work Trend Index from Microsoft and LinkedIn, 78 % of AI users at work bring their own AI tools without their company’s approval, a phenomenon known as Bring Your Own AI (« bring your own AI«), a proportion that rises to 80 % in small and medium-sized enterprises. The gap between what teams are required to achieve and what the IT department can deliver within the expected timeframe is driving the staff who are most comfortable with these tools to fill the void themselves.
These employees have an advantage that the IT department does not: they know the detail of the process. A sales administration manager knows which orders fall outside the standard workflow and why. A management controller knows what adjustments they make each month before publishing a figure. An HR manager knows which exceptions apply depending on the type of contract. This knowledge appears in no functional specification. It lives in the person's head, in their habits, in the corrections they make without even thinking about them.
When this person builds a tool with an AI assistant, they encode this tacit knowledge into code or prompts. The result works because it reproduces exactly what they were already doing. But none of this is documented, checked, or transferable. If the person changes roles, the tool becomes a black box. If sensitive data leaves via this channel, nobody can say precisely which data, nor to where.
This is not just an IT security issue. Customer or employee data that passes through a personal account escapes the guarantees that the company must provide regarding the retention, access or deletion of that data. The issue quickly makes its way from the manager's office to that of the compliance officer.
The IT department discovering this kind of tool finds itself facing a real dilemma unplugging it amounts to removing a measurable productivity gain, with no immediate replacement solution. Leaving it running amounts to endorsing a risk she does not control.
Dealing with this type of situation is not a matter of choosing between banning and allowing. Four obstacles crop up systematically and deserve to be examined before any decision is made: dependence on a single person, who built and modified the tool without ever documenting the rules they put into it; the lack of traceability regarding data passing through a personal account, outside the company's security perimeter; the ambiguity surrounding actual controls, since no one else can say what the tool validates, corrects or ignores; and the lack of a continuity plan if the person changes position, goes on extended leave, or leaves the company.
Before cutting off access, the first step involves understanding what the tool actually does, not what its creator thinks it does. A quick audit, conducted with the person rather than against them, makes it possible to list the business rules, the specific cases handled, and the data used.
Next comes the separation between business logic, which has value, and infrastructure, which poses the risk. The identified rules and exceptions can be incorporated into an environment controlled by the company, with data that remains within its perimeter. The personal account disappears, but the work done is not lost.
| Current situation | Target situation |
| Personal AI account | Enterprise-managed AI environment |
| Only one person knows the rules | Documented and shared rules |
| No data traceability | Data monitored and managed |
| Person-dependent continuity | Continuity ensured by the system |
The way people are treated matters just as much as the way tools are treated. Punishing such initiatives amounts to discouraging future ones, even though it is precisely these that most quickly reveal the real pain points on the ground. Involving this employee in the project’s resumption, whilst recognising their contribution, is far more crucial to the success of the transition than a technical migration plan alone.
The question we should be asking is not «should we ban uncontrolled AI?», but « how to take back control of what’s already working«, without losing the time that this employee has saved in their own way.
This sort of makeshift tool deserves to be viewed differently from the way we usually view shadow IT. An unmaintained codebase is a problem. But the knowledge it contains – the rules, exceptions and checks that an employee has formalised without being asked to do so – is a rare resource. It has already passed the toughest test for an AI project: it is used every day by a team that is under no obligation to use it.
At JEMS, we call this approach Cognitive Architecture. It is based on the assumption that a company’s processes are never fully described in a flowchart or in documentation. Part of it lives in people's heads, in habits, in the corrections everyone applies without writing them down. The role of a governed agent-based system is not to replace this tacit knowledge, but to capture it and make it explicit, controllable and transferable.
A vibe-coded tool that works is therefore not just a risk to be addressed. It is a signal to be heeded, before it becomes a problem that is more difficult to resolve. This interpretation shifts the initial question: it prompts us to ask what this tool reveals about the limitations of our official systems, before seeking to identify who authorised it.
The productivity gain that this type of tool has produced is real, measured, and experienced every day by a team. Removing it without putting anything in its place would mean losing this gain; keeping it as it is would run a risk that no one has chosen to take on. The right answer is neither one nor the other.
Taking back control of these initiatives, formalising what they have revealed, and integrating them into a framework that the IT department can follow and develop: this is a practical undertaking, carried out in collaboration with the teams that have taken the lead, rather than in opposition to them.
If you have identified this type of tool within your teams, or if you would like to assess where your organisation stands on these issues, the JEMS teams would be happy to discuss the next steps with you.
