An employee-built AI tool needs formal ownership when other people depend on its output, its access expands or its decisions begin affecting work beyond the maker’s own task. Reassess it when the reliance changes, before the team treats an informal favor as a supported service. Formal ownership means an accepted operating responsibility, with authority, time and backup. It does not always mean transferring the tool to IT.
For a department manager, the useful starting question is what would happen if the maker stopped helping tomorrow. Could colleagues still complete the work, find the original information and recognize a bad result? The tools and workflows guide covers the broader operating choices. Here the decision concerns a personal helper that has quietly acquired dependents.
Notice when personal use becomes shared reliance
A tool can remain small while its consequences grow. One colleague may use an output to make a commitment; a whole department may use another tool only for optional brainstorming. Headcount alone does not tell you which needs stronger support.
Ask the maker and the people receiving the output what has changed:
- Reliance. Has anyone stopped doing an earlier check or maintaining the original work record because the helper now supplies it?
- Access. Does the tool now read a shared mailbox, restricted documents or information belonging to another team?
- Authority. Does it still suggest a draft, or can it send messages, change records or trigger actions?
- Continuity. Who notices a missing run, answers questions and handles a problem when the maker is unavailable?
Microsoft’s guidance for managing the Power Platform default environment recognizes that personal productivity tools can become widely used or business critical. Its environment recommendations consider sharing, data and business impact. Those platform-specific recommendations are useful prompts for a review, not a universal number of users at which every AI tool must change owner.
The maker may not know how much colleagues rely on an emailed spreadsheet or shared output. Speak to those colleagues as well as inspecting the tool. A list of people with access shows who could use it; it does not show which work would stop without it.
Keep the request separate from the commitment
Suppose Sam Taylor, an order-desk employee at a wholesale bakery, builds an AI helper that extracts requested delivery windows from retailer emails into a draft list. At first, Sam uses it to organize personal notes and checks each item against the original message. Later, colleagues start using the shared list to prepare the day’s customer replies.
The important change is that other people now expect the list to represent incoming requests. If the helper misses an email or turns an ambiguous request into a definite time, colleagues may not know what needs checking. Sam’s convenience has become part of the team’s work.
A requested slot is not a confirmed booking
The requested window
Keep the actual request available, including uncertainty or alternatives.
An extraction to check
An omitted or ambiguous request remains unresolved. The list cannot confirm a booking.
The confirmed commitment
Authorized staff check the request and confirm through the existing booking procedure.
The team should preserve the original emails and authoritative order register, with the order desk still confirming bookings through its established procedure. A requested delivery window is not a confirmed delivery promise. The helper’s list cannot acquire that authority simply because colleagues find it useful.
A bounded departmental arrangement might allow the helper to prepare the list while a named order-desk employee checks requests before sending confirmations. Missing or unclear information stays unresolved. When the helper is unavailable, the team processes the original messages using the existing register. That fallback is only credible while people can still reach and use those records.
If colleagues want the tool to amend confirmed orders or send customer promises, they are proposing different work. Review that change before enabling it, including the permissions, checking and support it requires. The prototype-to-production guide explains how to define a supported release when that becomes the next decision.
Choose an arrangement the receiving team can sustain
Do not make IT takeover the only route to legitimacy. A department may have the skills and authority to operate a limited helper. Equally, naming its manager as owner does not give the department the ability to repair it.
Use the actual work to choose an arrangement:
| Arrangement | When it may fit | What must be explicit |
|---|---|---|
Keep it personal | The employee uses permitted information for their own work, retains the required checks and creates no shared service expectation | The permitted use and a way to stop using it without leaving colleagues dependent |
Support it within the department | A team relies on a bounded task and can provide the required checking, maintenance and backup | Accepted responsibilities, allocated time, approved access and a usable fallback |
Establish a wider service | The dependence, complexity or required coverage exceeds what the department can support | A receiving service owner, technical capacity, operating conditions and an agreed transition |
Restrict or retire it | The use is not permitted, the risk is unresolved or nobody can sustain the required support | Who changes use safely, informs dependents and preserves necessary work records |
These are choices to make from the evidence, not stages every tool must pass through. A personal helper need not become an enterprise application. A useful shared tool may also be better replaced by an existing supported service than rebuilt or absorbed.
ServiceNow’s application-lifecycle guidance separates helping users from maintaining the application and calls for reassessing ownership when an application changes significantly. That distinction matters here: somebody answering questions does not establish who can fix the implementation or approve its next use.
Agree support before it becomes an unlimited favor
The support experience can differ sharply even within the same platform. In a February 2026 PowerApps discussion, a Reddit user described repeated interruptions and pressure from business teams after an app’s maker left. The account illustrates an unresolved operating burden; it does not establish how often this happens.
In the same discussion, another Reddit user who described themselves as the citizen developer reported a more bounded arrangement. IT help had agreed hours, the maker handled simpler work, and IT controlled publication. The maker said a second version was tested and signed off. These are self-reported low-code experiences, rather than measured AI results, but the contrast makes the agreement tangible.
For Sam’s helper, write down the commitments that the team has actually accepted:
- Define the supported task. Extract requested delivery windows into a draft list. Keep customer confirmation and changes to confirmed orders outside that authority.
- Assign the work of operating it. Identify who checks completeness, responds to users, investigates failures and can pause the helper. Allocate time and name cover for absences.
- Set the change boundary. Identify who reviews a new data source, permission or action before it is added. Keep the current version and relevant instructions findable by the maintainer.
- Try the fallback. Have someone other than Sam handle a missing request from the original email and register. Resolve missing access or unclear responsibility before calling the arrangement supported.
Microsoft’s maker-support guidance describes informal and formal support routes and making responsibilities explicit when informal help is insufficient. Choose commitments from available capacity. A weekly advice session is not an agreement to repair a failed ordering workflow at any hour.
Use the ongoing AI support guide to define request handling and escalation. Include maintenance and cover in the cost of operating internal AI software, even when the initial build was quick.
Make the decision visible to the people who rely on it
Keep the accepted operating agreement with links to the current implementation and instructions, where the authorized maintainer can find them. The next colleague should be able to understand the arrangement without reconstructing Sam’s intentions.
Add the decision and the change that would require another review. For the bakery, the decision might be departmental support for drafting requested slots, with another review before customer messaging or order changes are introduced. Record unresolved conditions honestly, including any restriction while support is being arranged.
Tell the people receiving the list what it represents, who checks it and where to report a missing request. Ask them to confirm that the agreed alternative still lets them finish the work. Ownership becomes useful when it changes expectations and makes action possible. A name in an inventory, without an accepted duty or the ability to carry it out, leaves the original dependence in place.
Questions and answers
Does formal ownership always mean IT takes over?
No. A department can own an employee-built AI helper if it accepts the work, has the necessary skills and approved access, and can provide checking, maintenance and backup. IT or another service team may need to take responsibility when those requirements exceed departmental capacity. Choose from the operating arrangements using the tool’s actual dependence and consequences.
Is there a number of users that makes ownership mandatory?
There is no universal user count for employee-built AI tools. One person can use a tool to make a consequential commitment, while many people can use another for optional ideas. Review reliance, access, authority and continuity. Apply any specific rules for your platform and organization as well; a general ownership discussion does not replace them.
What if the employee who built the tool is leaving?
Identify the people relying on the tool, preserve access through approved arrangements and have the receiving owner demonstrate that they can operate it or use the fallback. Do not solve the problem by sharing the departing employee’s credentials. If the tool is an agent, the internal-agent ownership guide explains the business, technical and control responsibilities to hand over.
What if nobody will accept responsibility for a useful tool?
Do not present the tool as supported. The department manager should establish whether use can be restricted safely while support is arranged, whether an existing service can replace it or whether it needs retirement. First identify dependents and the work records they need, then communicate the alternative. Usefulness does not create maintenance capacity or permission to keep expanding access.
How much documentation does a small helper need?
Enough for an authorized person other than its maker to understand the permitted task, recognize a failed or uncertain result, find the relevant implementation and finish the work through the agreed alternative. Test that with a realistic absence or missing-input case. If the person cannot complete it, improve the instructions, access or operating arrangement rather than treating a longer document as proof of readiness.
