AI with an audit trail
Why we give models an identity and a permission set like any other user — and why a system that cannot explain what the AI did is not ready for a business to rely on.
Most AI features in business software are bolted to the side: a chat panel with broad access to a database, answering questions impressively in a demo. The trouble starts at the first serious question from a finance director — what can it see, and can you prove what it did last Tuesday?
Treat the model as a user
The approach we have settled on is unglamorous. The model authenticates. It holds a permission set. It is subject to the same access rules as a person doing the same job, and it cannot read what it is not entitled to read. Every action it takes is recorded with the record touched and the authority used.
This sounds obvious written down. It is not what most implementations do, because giving the model broad access makes the demo better and the retrieval simpler. The cost arrives later, when nobody can characterise the blast radius.
Propose, don't execute
Anything consequential should be proposed rather than performed — a draft invoice to approve, not an invoice already issued. This is not timidity about model quality. It is that a human approval step converts an unexplainable action into a decision with an owner, which is what the business actually needs.
If we can't log what it did and bound what it can reach, we don't ship it.
Keep the provider swappable
Model quality and pricing are both moving quickly, and some clients cannot send data outside their own infrastructure at all. Building against an abstraction rather than one vendor's API means switching providers — or running an open model on your own hardware — is a configuration change rather than a rebuild. That is worth the small amount of extra indirection it costs.
None of this makes AI less useful. It makes it usable by organisations that have to answer for what their systems do, which is most of them.