The person who prompted the tool is not accountable for what it does. The company is, from the day the tool touches customer or finance data. Accountability for AI-generated code needs four things written down before the code runs: who owns it, what it is allowed to do, what counts as done, and what evidence shows it still does that.
You should not judge an AI-built tool by whether it works. It does; that stopped being the interesting question about two years ago. Judge it by whether anyone in the company can say what it is allowed to do, and prove it.
Working code is the wrong test
AI writes working code in an hour. In Veracode's October 2025 update to its GenAI Code Security Report, code generated by more than 100 large language models introduced security flaws in 45 percent of tests, while the code itself ran. Working and safe are two different tests, and the second one is the company's, not the model's.
The tools already exist inside your company. Operations has automated the invoice reminders, sales wired a lead scorer to the CRM, and someone in finance runs a script every Friday that reconciles two exports. All three work. Ask who is allowed to change them, what data each one reads, and what happened the last time an exception hit, and in most companies nobody has an answer.
Four things nobody wrote down when the tool was prompted
An owner
The tool inherits its author, not its process. When the person who prompted it changes roles or leaves, the tool keeps running and nobody will touch it, because it works and nobody knows why. The owner of a tool has to be the owner of the process it automates.
Authority
What the tool is allowed to do lives in the prompt, not in a role. An agent with access to everything, because that was easier on a Tuesday afternoon, has no boundary a security review can read. Permissions belong in identity and roles, the same place they live for people.
The data it touches
An automation that reads customer records or writes to the ledger leaves no trail unless someone built one. "What did the script do with the invoices in March" is a question with no answer in most companies today.
What counts as done, and what happens on the exception
The tool encodes one person's version of the process. The first order that does not fit that version is handled by hand, next to the automation, and the workaround becomes the real process.
Why a PDF policy is not evidence
A policy says what is allowed. Evidence says what happened, who authorised it, and whether the two match. Most companies have the first and mistake it for the second.
In AvePoint's State of AI 2026 report, 88.4 percent of the 750 IT, security and AI leaders surveyed said their organisation had an AI agent-related breach in the past year. Google's 2024 DORA report found that AI adoption improved individual productivity while it negatively affected software delivery stability and throughput. Both findings describe the same thing: more gets built, and less of it is governed.
An auditor does not ask whether you have an AI policy. They ask what this system did last quarter and who approved it, and a PDF has no answer to that. The running system does, if it was built to keep one.
What accountability looks like in a running system
Governance is not a department. It is a property of the runtime: the answers to the accountability questions come from the system itself, not from a meeting.
| Question | Answer from a document | Answer from the runtime |
|---|---|---|
| Who is allowed to do this? | A role described in a policy | An identity with roles, the same for people and agents, checked on every call |
| What did it do last month? | Nobody knows | A trace from the request to the database query, for every action |
| Is it still doing what was agreed? | The last review said yes | The declared behaviour compared with the observed behaviour, on a page you can open now |
| How do we undo it? | Find the person who built it | A reviewed path to stop or reverse the change |
This is how EmpoweredHouse builds it. EHOS, the EmpoweredHouse Operating System, is a governed runtime that keeps authority, traceability and evidence for the software a company owns. It is the runtime EmpoweredHouse builds client software on, and today it does three of the four rows above:
- Identity and roles through a self-hosted identity provider, with agents acting through an MCP server on the same tokens as people.
- A trace of every request from the web layer through the application to the database query.
- A contract-conformance dashboard that compares what the business contract declares with what the running system did.
Conformance checking, the process-mining technique, verifies that a process ran according to its model; EHOS verifies that the software is still what someone authorised.
The fourth row, a reviewed undo path a technical owner can approve in hours, is a direction we are building toward, not a feature you can open today. We say so because a claim without evidence is exactly what the previous section describes.
The owner is in the room
Accountability has a name attached, and it is not the name of the person who typed the prompt. Two people own an AI-built tool, and both have to be in the room before it reaches production.
The process owner decides what the tool is for, what it is allowed to do, and what counts as done. The technical owner accepts the architecture, the access boundary and the way change is reviewed and reversed. If the company has neither, the tool is not ready for production, however well it works. If it has both, the person who built it stops being its single point of failure and gets a reason to stay.
What to check this week, with the tools you already have
You do not need a new system to start. You need four answers, per tool, written down:
- Which tools built with AI run on production today, and who maintains each one?
- What happens to each of them if the person who built it leaves next month?
- Who can say what each tool did last week, and where would they look?
- Which process was automated without being mapped first, and what broke when the first exception hit?
Every question without an answer is a tool without an owner, and that list is where accountability starts, not the AI policy.
Frequently asked questions
Is the developer who used the AI tool responsible for its output?
Inside the company, the owner of the process is responsible for what the tool does to that process, and the technical owner is responsible for how it is built and changed. The author of the prompt is neither by default. Write the two names down before the tool touches real data.
Does an AI policy make the company compliant?
A policy states intent. Compliance is shown by evidence of what systems did and who authorised it. Without a trace and a way to compare declared behaviour with observed behaviour, the policy is a promise the company cannot check.
Do AI agents need their own identity?
Yes. An agent acting under a shared key or a person's credentials cannot be audited, limited or revoked on its own. Give agents identities and roles in the same system people use, and the same access review covers both.
Can we make an existing AI-built tool accountable without rewriting it?
The first three steps need no code: name the owner, move its permissions into a role, and route its actions through a traced path. The rewrite comes only if the tool cannot be made to run inside a boundary the technical owner will accept.
Do not put a tool on production if nobody owns the process it automates; write the owner down first. If you already have one AI-built workflow and a technical owner who will approve its boundary, send us the four answers above and we will tell you what governing it would take. Send us the four answers
