When Accountability Becomes Design

Most organisations now have policies describing who is responsible for the appropriate use of technology and data. The language of accountability is familiar, particularly as artificial intelligence becomes part of more operational processes. What I’m less certain about is whether those responsibilities are always reflected in the way systems are actually built.

A policy can say that someone is accountable for an outcome, but that doesn’t necessarily mean they can see how the outcome was produced, change the rules that influenced it or arrange for a mistake to be corrected. There can be a considerable distance between responsibility as an organisational statement and responsibility as something a person can exercise.

Where responsibility becomes difficult to see

Modern systems often distribute decisions across several components. Data is captured in one application, transformed elsewhere, interpreted by a model and presented through another interface. Each component may behave as intended, while the combined result is confusing or inappropriate.

When that happens, the question of ownership can become surprisingly difficult. A technical team may be responsible for the pipeline but not the definition of the metric. An operational team may own the process but not have access to the logic used to automate it. A governance function may have approved a policy without knowing exactly how it has been implemented.

None of this requires anyone to have acted irresponsibly. The difficulty arises because responsibility has been divided without enough thought about how those divisions affect the ability to respond when something goes wrong.

Making accountability practical

For me, this is where architecture and organisational design meet. Access controls determine who can change a system. Logs and lineage determine what can be investigated. Approval processes determine how changes are introduced. Escalation arrangements determine whether concerns reach someone with the authority to act.

These choices are sometimes treated as supporting features, but they shape whether accountability is meaningful. Being able to explain why an output occurred is valuable, yet explanation alone doesn’t tell us who can correct the underlying problem or how quickly that correction can be made.

A useful design should make it possible to trace important decisions, challenge assumptions and introduce changes without relying on informal knowledge held by one or two people. It should also recognise that responsibility for business meaning and responsibility for technical implementation may sit in different places, and that both need to be involved when a decision is reviewed.

At MycoFlow Systems, I’m interested in treating these questions as part of the design from the beginning rather than as documentation produced at the end. Reliable systems won’t prevent every mistake. They should, however, make it possible for people to recognise mistakes, understand their causes and take responsibility for putting them right.