Who is accountable when an AI makes a decision in your business
You are. That is the short answer and it does not change no matter whose software you bought. The useful question is whether you can show what happened, and most systems in the market cannot.
A client asked me once who had approved something. I did not have an answer. Not because the system had done anything wrong, but because nothing had been recorded that could tell either of us. That gap is the reason everything below exists.
The three questions you will eventually be asked
They come from a customer, an insurer, a regulator, or your own team after something went sideways. They are always the same three:
- What did the system do?
- Why did it do that?
- Who signed off?
Most AI deployments can answer the first one, sometimes. Almost none can answer all three. And the gap is rarely deliberate: nobody decided not to keep records, they just never built the place records go.
What an audit trail actually is
Not a log file. A log tells you a request happened. An audit trail tells you a decision happened and carries enough context to reconstruct it later:
- What the system saw, meaning the actual inputs it was working from
- What it decided, and where in the process that decision sat
- What information it used to get there, so an answer can be traced to a source
- Whether a human was in the loop, and which human
- When, precisely
That last one sounds trivial and turns out to matter most. Disputes are almost always about sequence. Who knew what, and when.
The AI writes the summary. It never makes the decision that carries consequence. On one system, urgency triage runs through deterministic logic with no model in the decision path at all, resolving in under two seconds, covered by tests. The model describes what happened. A function you can read decides what to do.
Grounding, and why "the AI said so" is not an answer
A model that answers from general knowledge is guessing about your business with great confidence. A model that answers only from your prices, your availability, your documents can be checked, because every answer has a source you can point at.
This is also the practical answer to a question we get asked constantly: does our data train someone else's system? It should not, and the boundary should be explicit. Reuse the architecture, the prompting patterns, the evaluation harness. Never another client's content.
Where the line sits, by industry
The approval boundary is not a fixed setting. It moves with the cost of being wrong.
- Low consequence. Answering opening hours or a published price. The system can act alone.
- Medium. Booking an appointment, quoting from a price list. Act, but record it and make it reversible.
- High. Anything clinical, legal, financial, or contractual. Draft only, human approves, everything logged.
A vendor who applies the same setting to all three has not thought about your business.
Why this is worth building before you need it
Nobody asks for an audit trail on a good day. They ask on the day something has already gone wrong, and on that day you cannot build one retrospectively. It is one of the very few parts of an AI deployment that has to exist before the thing it protects against happens.
Seeing this in your own operation?
We build AI workers that run inside small service businesses, then stay and operate them. If any of the above sounds like your week, the conversation is short and there is nothing to install.
Related: What happens when it gets something wrong · How you know it is actually working
Want this running on your phones?
Tell us how many calls you miss in a week and what an average job is worth. If an answering service will not pay for itself on those numbers, we will say so.