Your Board Will Ask Which Decisions AI Made. Logs Will Not Answer.

Try this at your next leadership meeting. Ask for a list of the consequential decisions AI systems shaped or made in your company last quarter, and the role accountable for each one.

Not what you spent on AI. Not what your AI strategy is. Those have answers, and the answers are slides. This one does not have an answer in almost any organisation I have encountered, and the reason it does not is more interesting than the fact.

The question is becoming harder to defer. December 2027 sits roughly one board planning cycle away, and it is the point at which high-risk obligations bite and governance expectations around AI step up generally. No regulation mandates the artefact I am about to describe. But the questions arriving around that date are the ones this artefact answers, and organisations that cannot answer them will be assembling the answer under time pressure rather than by design.

Shaped, or Made

Before going further, a distinction that most coverage of this topic skips and that a board will not.

AI systems sit on a spectrum. Some recommend, presenting an option to a person who chooses. Some rank or filter, shaping what a person ever sees, which is a quieter and often more consequential form of influence. Some execute a decision a policy already made, within pre-set bounds. And a smaller number decide, in the sense that no human considers the individual case before the outcome takes effect.

Legal accountability sits with the organisation across all four. That does not change. But the governance question differs sharply between them, and lumping them together produces either paranoia or complacency depending on which end you anchor on.

The useful question is therefore not only "which decisions did AI make," but "where along that spectrum does each consequential decision sit, and did anyone choose that position deliberately?" In a great many cases the position was chosen by an engineering default rather than by a policy.

Logs Are Not the Same as Authority

The instinctive response is that this is a logging problem, and the data must be in there somewhere.

Most organisations can produce enormous quantities of AI logs. Prompts, completions, tool calls, latencies, retrieval traces, error rates. Modern observability tooling is very good and getting better.

But logs record what happened. They do not record who was entitled to make it happen.

Take an illustrative case. Imagine an agent that adjusts a customer's credit limit within a narrow band, at three in the morning, as part of a routine reconciliation. This is a hypothetical, and autonomous adjustment of that kind is not common today. A log will tell you the adjustment occurred. It will not tell you whether the system was permitted to adjust credit limits, under which policy, up to what threshold, with which exceptions, on whose delegated authority, and who would have had to approve it had a person done the same thing.

That second set of facts is what an auditor, a regulator, a customer's counsel or a non-executive director is actually asking for. In most enterprises it exists only in the heads of the people who built the workflow.

Observability tells you what your systems did. It does not tell you what they were allowed to do.

Why Nobody Recorded It

This is the part I find genuinely interesting, and it is not a story about negligence.

In human processes, authority is implicit in structure. A person's ability to approve a refund is a function of role, grade, reporting line and a delegation of authority matrix that exists somewhere in finance. Nobody records the authority for each individual decision, because the org chart records it once and every decision inherits from it.

An AI system has no position in that structure. It has credentials.

Credentials are an access control artefact. They express what a system can technically reach, which is almost never the same as what it is institutionally permitted to decide. The gap between those two things is where the entire problem lives. A system given a service account with broad scope, for perfectly good engineering reasons, now has technical capability that no delegation matrix has considered, and nothing connects the two.

So the honest description is not that organisations failed to log authority. Authority was inherited from a structure that these systems were never placed into, and nothing in the deployment process noticed.

What a Decision Register Contains

The artefact that answers the board's question does not exist in most companies. It is worth being concrete about what it would contain. Not a maturity model. A table, one row per class of consequential decision.

• The decision class. In business terms a director would recognise. "Hold a payment above threshold X," not "invoke the risk scoring endpoint."
• The position on the spectrum. Recommends, ranks, executes within bounds, or decides. And whether any human approval step is real or nominal.
• The deciding entity. Which system, model or agent, in which combination with which people.
• The authority basis. The policy, delegation or control that permits this decision to be made this way, with a reference. If none exists, that row is the finding.
• The bounds. Thresholds, exceptions, and what triggers escalation to a person.
• The accountable owner. A role, for continuity, plus the name of the person currently holding it. Roles survive reorganisation; names create follow-up. You need both, and accountability needs a named owner rather than an organisational abstraction.
• The evidence trail. Where the record lives that would let somebody reconstruct a specific instance twelve months later.

This is additive to work you have probably already done rather than a replacement for it. An AI system inventory lists what you are running. A decision register maps where consequential authority sits. The first is a prerequisite for the second, and neither substitutes for the other.

The difficulty is not the schema. It is that filling in the authority basis forces conversations most organisations have been comfortably avoiding.

Start With One Workflow

The failure mode is attempting completeness. An enterprise-wide decision register commissioned as a programme will produce a consultant's deliverable and no change in behaviour.

Take one workflow instead. Preferably one that touches customers and has already made somebody uncomfortable. Fill in the columns. Time how long it takes and note which column stalled.

Then do a second one and see whether the stall was specific or structural.

What you are building toward is not documentation. It is a gate: the point at which no consequential AI-shaped decision enters production without a row. That gate is cheap to install while you have a handful of systems and considerably harder once you have four hundred, which is the same lesson as every asset register in the history of enterprise IT and one that gets relearned each time.

What This Is Not

It is not an argument for slowing deployment, and the argument is easily conscripted into that.

A decision register does not require human approval of every action. It requires that somebody wrote down, in advance, which actions do not need one and why. Those are close to opposite postures. The organisations that move fastest in 2028 will be the ones that can say precisely where autonomy is authorised, because they will not have to litigate it every time a new use case appears.

The bottleneck is rarely permission. It is the absence of a prior decision about permission.

The Question

Look at the columns above and answer honestly.

Which one would your organisation struggle most to fill: the authority basis, the bounds, or the accountable owner?

I have a guess, and I would rather hear yours. If you have actually attempted this for one workflow, I would particularly like to know how long it took and where it stopped.

Originally published on LinkedIn on August 18, 2026.