Who answers when AI gets it wrong
That question always shows up after the first error someone outside noticed, and by then it is too late to organise the answer. Accountability is defined beforehand, task by task, not tool by tool.
Build a list of everything already running with AI in your company, saying who answers for it, what each thing may do on its own and how much it may spend. And find out what currently has nobody responsible.
Sign up once to unlock this course
Course 01 is open. For courses 02 to 05 we ask for six fields. It is a single signup: done once, valid for the whole track. It is not a free diagnosis and it does not trigger automatic sales contact.
A tool has no owner. A task does
Companies try to control AI through the tool: which model is allowed, which subscription was approved, which team may use it. That helps, but it is not enough. The risk does not sit in the tool: it sits in what the tool does when nobody is watching.
What needs an owner is the task: work that repeats, with an expected outcome, that today is already done with AI support. Qualifying a prospective customer. Checking a document. Answering the first line of support. Each of those can have a named owner, a budget and a limit.
What is not on a list cannot be controlled
The first step is uncomfortable: most companies do not know how many things already run on AI inside them. Departments bought tools on their own, teams built automations, someone connected a system to a database. None of it was written down anywhere.
The minimal list has five columns: which task, from which area, what it decides or produces, who answers for it, and how much it spent last month. Building that list usually reveals two things at once: tasks with no owner, and spend nobody had added up.
Define what it may do, not which system it can reach
Saying the system “has access to the CRM” says nothing about permission. Permission is described action by action: it may read the history; it may draft the reply; it may send without review up to a certain value; it may not grant a discount; it may not close the case.
May act alone — what can be undone and has little impact. Needs approval — what affects a client, a contract or money. May not act — what carries accountability that cannot be handed over.
Defining those three bands before going live avoids the hardest conversation of all: removing permission after something went wrong.
A system without a budget is spend without an owner
The cost of a person is in the budget. The cost of AI systems, in most companies, is not. The spend shows up on a corporate card statement, with no cost centre, no limit and nobody watching whether it is rising.
Each task needs a monthly limit and a warning before it hits that limit. This is not bureaucracy: it is what lets you grow predictably and defend the investment when finance asks.
Without a record, the answer will always be “we do not know”
When an error happens, there are three questions: what information the system based itself on, what it did, and who approved it. If that is not recorded at the moment it happened, there is no way to recover it later.
The minimum record has four items: which information was consulted, what was produced, who approved when approval applied, and what a person changed afterwards.
None of this eliminates error
No organisation avoids every error, and promising that destroys trust at the first failure. What this work delivers is something else: error within a known limit, spotted quickly, with a defined owner and a record that lets you explain what happened.
Basis
This course treats the subject as organising the work, not as an internal policy document. Policy sets principle. The work needs an owner, a permission band, a spend limit and a record.
When the inventory becomes an investment decision
If your list shows several tasks with no owner and no spend limit, the next step is AI Operations Governance — and deployment on Arden.AS when the volume justifies it.