Responsibility for employee-built software is shared, and it should be written down before anything breaks. The platform vendor is responsible for its own systems, but many vendors' terms put the data inside your apps on you. The company owns the data, the decisions and the people. Each tool should have a named business owner who decides on changes, a builder who maintains it, and an admin who controls access. Blame the process, not the builder, and choose a platform whose design makes the common failures hard to cause.
When the company's main software breaks, everyone knows who to call. When a tool built by the office manager on an AI platform breaks, nobody is quite sure. Is it the office manager's fault? The platform's? The owner's, for letting the team build in the first place? That uncertainty costs time exactly when time matters most, and it can damage trust inside a team that was doing something good.
Employee-built software is now common. Pax8's October 2026 survey of AI-engaged businesses with 5 to 499 employees found 67 percent have built one or more AI solutions now in regular use. This guide maps who is responsible for what when one of those tools fails, explains what vendor terms usually say, and gives you a plan to settle responsibility before anything breaks.
What "breaks" can mean
Different failures have different owners, so start by naming them.
| Failure | Example | Main question |
|---|---|---|
| Wrong results | The commission tracker miscalculates a rate | Who checks the numbers, and who fixes the rule? |
| Outage | The dispatch board will not open on Monday morning | Who restores it, and what does the crew do meanwhile? |
| Data exposure | Customer records are readable by outsiders | Who restricts access, investigates and decides on notification? |
| Data loss | A month of job notes disappears | Who restores, and who fills the gap? |
| Abandoned tool | The builder left and nobody can change the tool | Who owns it now? |
| Platform failure | The vendor ships a change that breaks or exposes something | What does the vendor owe you, and what do you still have to do? |
The four parties
Every employee-built tool involves four parties, whether or not anyone has said so.
The platform vendor
The vendor is responsible for its own systems: keeping the platform running, securing its infrastructure and fixing its own bugs. Platform failures happen. Lovable says a February 2026 regression exposed public projects' chat history and source code from February 3 to April 20, 2026, and that it fixed the problem within two hours of the public report. In July 2025, Fortune reported that an AI agent on Replit wiped SaaStr's live database during a code freeze, and Replit promised separation of development and live databases and a planning-only mode in response.
But vendor responsibility often stops at the platform. Many vendors' terms put responsibility for the data inside your apps on you. Lovable disputes CVE-2025-48757, a flaw in which apps built on its platform exposed data through missing access rules, saying each customer is responsible for protecting their app's data. Earlier, in August 2021, UpGuard found 38 million records exposed across 47 Microsoft Power Apps portals, and Microsoft first called the behavior "by design."
The lesson: read the terms, and assume the data in your apps is your responsibility unless the contract clearly says otherwise.
The company
The company owns the data, chooses the platform, decides who may build and is accountable to customers, employees and regulators. When a tool exposes customer data, it is the company that may have to notify people, answer to customers and deal with regulators. That accountability cannot be handed to an employee or a vendor.
The business owner of the tool
Every tool should have a business owner: the manager whose team relies on it. The business owner decides what the tool should do, approves changes, sets priorities when it breaks, and signs off that it was tested. This is usually not the person who built it.
The builder
The builder creates and maintains the tool. They fix problems, make approved changes and know how it works. They are responsible for doing that work carefully, not for every consequence of a tool the company chose to rely on.
A responsibility map you can copy
Fill this in for every important tool and keep it with your app register.
| Responsibility | Platform vendor | Company owner | Tool's business owner | Builder | Admin |
|---|---|---|---|---|---|
| Platform uptime and security | Responsible | Chooses the vendor | |||
| Deciding what the tool does | Responsible | Advises | |||
| Building and fixing | Depends on the platform | Approves | Responsible | ||
| Testing before launch | Signs off | Runs tests | |||
| Who can access it | Provides the controls | Sets policy | Says who needs it | Responsible | |
| Data inside the tool | Per contract | Accountable | Responsible for what goes in | ||
| Responding to an exposure | Per contract | Decides and notifies | Informs | Helps fix | Restricts access |
| Recovery from data loss | Per contract | Decides | Fills the gap | Helps restore | Coordinates |
| Continuity when people leave | Accountable | Names a successor | Hands over | Removes access |
Blank cells mean "not this party's job." The point of the map is that nobody has to work it out during an emergency.
Why blaming the builder backfires
When a tool breaks, it is natural to look at the person who built it. Resist that.
- People stop reporting problems. If reporting a bug means taking the blame, people hide bugs until they become incidents.
- People stop building. The people who build tools are the ones who noticed a problem and fixed it. Punishing them teaches everyone else not to bother.
- It misses the real cause. Most failures come from the process: no test step, no role rules, a tool living in a personal account, a platform that made the risky thing easy.
- AI output is hard to verify. Even developers are cautious. In the 2026 Stack Overflow Developer Survey, only 6.6 percent said they trust AI output for many tasks including important work decisions. Expecting a non-developer to catch every AI mistake alone is not reasonable. The platform and the process need to carry that load.
Instead, run a short blameless review after every meaningful failure:
- What happened? In order, with times, using the activity record.
- What was the impact? Who was affected and how.
- Why did it happen? Keep asking why until you reach a process cause.
- What will we change? One to three specific changes, each with an owner.
- Share it. A short summary with the team builds trust and spreads the lesson.
An example: the commission tracker that got it wrong
Here is an example, not a real customer, of how the map works in practice. A 25-person distributor's sales manager asks the operations coordinator to build a commission tracker to replace a spreadsheet. It runs for two months. Then a rep notices that orders split between two reps were counted in full for both.
- The business owner, the sales manager, decides what happens: pause payouts from the tracker, pay this month from the old spreadsheet, and correct the rule.
- The builder, the operations coordinator, uses the change record to find the rule that caused the problem and requests the fix.
- The admin confirms nobody else changed the tool in the meantime.
- The company owner decides how to handle the overpayments with the reps, with advice from the accountant.
- The blameless review finds the real cause: the test step never included a split order. The test checklist gets a new line. Nobody is blamed, and the coordinator keeps building.
Total time from discovery to fix: one afternoon, because everyone knew their part in advance.
What to tell customers when a tool affects them
If a failure touches customers, such as a missed appointment or an exposed record, the company speaks for itself, not the builder and not the vendor. Keep it simple: say what happened, what it means for them, what you have done, and who to contact. For anything involving personal data, talk to your legal or compliance advisor before you send it, because notification rules can apply.
Read the vendor's terms
Before you sign, find answers to these in the vendor's terms, or ask in writing:
- Who is responsible for protecting the data inside apps we build?
- What does the vendor commit to for uptime, and what happens if it misses?
- How and how fast will the vendor tell us about an incident affecting our data?
- What help does the vendor give with recovery after data loss?
- Does the vendor charge us for failed attempts by its AI?
- What happens to our tools and data if we leave?
Our AI platform due diligence checklist has the full list.
Talk to your insurance broker
Ask whether your cyber or business insurance covers data exposures and outages from software your own employees built, and whether the policy requires specific controls such as access restrictions, records or backups. It is far better to learn the answer now than after an incident.
Before any tool goes live: a responsibility checklist
- Name the business owner. One person, by name.
- Name the builder and a backup. At least two people should know how the tool works.
- Confirm the admin. The person who controls access.
- Confirm the tool belongs to the company, not a personal account.
- Record what data it holds, and whether any is sensitive.
- Run and sign off the test. See how to test an AI-built app before launch.
- Write the fallback. What the team does if the tool is down.
- Know the recovery path. See backups, rollback and recovery.
- Add it to the app register with the responsibility map filled in.
When the builder leaves
This is the most common way an employee-built tool becomes orphaned. If the tool lives on a company platform, the admin removes the person's access in one step and the tool stays. The business owner names a new builder, who reads the tool's change record to get up to speed. If the tool lived in a personal account, you may have days, not weeks, to move it. Our guide to what happens when the app builder leaves covers this in detail.
How FORGE handles it
FORGE is built so that responsibility is clear and the common failures are hard to cause in the first place.
- Safety does not depend on each builder. A panel of top AI models plans each tool, a dedicated AI crew builds it, every piece is checked for quality and security before it is ever saved, and the tool is checked at every step.
- Every app lives inside your company. Anyone outside gets nothing back, not even a hint the app exists.
- Clear roles. Owners, admins, builders and app users each see and do exactly what their role allows. Owners and admins decide who builds, and app users cannot change tools.
- Tools belong to the company. Removing someone ends their access immediately, and every tool they built stays with your company.
- A complete record. Every step of every build is recorded with who or what did it, so a blameless review starts from facts.
- You never pay for our misses. A build FORGE fails is free, and changes only count when something actually changes.
Onboarding is done by our team, starting with a workflow workshop where we help you name owners for your first tools on your real work. Talk to us.
Questions people ask
Is the employee who built the app responsible when it breaks?
The builder is responsible for maintaining the tool and fixing problems, but the company is accountable for the tools it chooses to rely on. Holding one employee solely responsible discourages people from building and from reporting problems. Assign roles in advance and review failures without blame.
Is the AI platform responsible if an app it built leaks data?
Read the vendor's terms. Many put responsibility for the data inside your apps on you. Lovable, for example, disputes CVE-2025-48757, saying each customer is responsible for protecting their app's data. Vendors are generally responsible for failures in their own platform, but the details depend on your contract.
Who should own an internal tool?
Each tool needs a business owner: the manager whose team relies on it, who decides on changes and priorities. That is usually not the person who built it. The builder maintains it, and the admin controls who can use it.
What happens when the person who built a tool leaves?
If the tool lives in their personal account, it may leave with them. If it lives on a company platform, an admin removes their access and the tool stays. Make sure at least one other person knows how each important tool works.
Does cyber insurance cover problems with employee-built apps?
It depends on the policy. Ask your broker whether data exposures and outages from internally built software are covered, and whether the policy has requirements such as access controls or records that you must meet.
What is a blameless review?
A blameless review is a short meeting after a failure that asks what happened and what to change in the process, rather than who to punish. It makes people more willing to report problems early, which is how small problems stay small.
How does FORGE reduce the burden on the company?
FORGE checks every piece of every tool for quality and security before it is saved and checks the tool at every step, so safety does not depend on each builder. Every app lives inside your company, every step is recorded, tools stay with the company when people leave, and a build FORGE fails is free.
See what FORGE builds for your team
We onboard every team ourselves, starting with the work that costs you the most time.
Talk to us
