In 2019, I attended a government seminar and delivered a presentation with a Cheeky title, “Digitising public sector bureaucracy”. My central argument was simple, and at the time it unsettled a few people in the room: most technology projects, in most organisations, were not eliminating bureaucracy at all. They were digitising it. And government, more than almost any other sector I had seen, was remarkably effective at exactly that — taking a slow, paper-bound, multi-signature process and turning it into a slow, screen-bound, multi-click process. Same friction, same delay, same lack of accountability—just faster typing.I coined a term for it that day, somewhat off the cuff: “digitising the bureaucracy.” It landed harder than I expected. The Permanent Secretary presiding over the session picked it up and repeated it back to the room in his closing remarks, using it as shorthand for exactly the trap I was warning against.That moment has stayed with me, because the pattern I described in 2019 hasn’t gone away — it has simply migrated. It is no longer confined to government digitisation programmes. It is now the defining risk of enterprise AI transformation. There is a quiet assumption sitting underneath most transformation programmes today: that technology is the fix. Buy the platform, deploy the model, automate the workflow, and the organisation will somehow become more disciplined, more efficient, more “digital.” It rarely works that way. What actually happens, far more often than boards like to admit, is that badly governed processes get automated at speed — and the chaos that used to move at the pace of a human simply starts moving at the pace of a machine.Every transformation slide deck tells roughly the same story: legacy process on the left, sleek digital future-state on the right, an arrow labelled “AI” or “automation” pointing from one to the other. What the arrow conveniently skips over is the actual condition of the process being transformed. Is it well controlled? Is ownership clear? Does anyone actually know why the process works the way it does, or has it simply calcified into “the way we’ve always done it”?Organisations that skip this question don’t get transformation. They get a faster, better-branded version of their existing problems. A reconciliation process with unclear accountability doesn’t become accountable because it’s now run through an RPA bot. A lending decision shaped by inconsistent judgement doesn’t become consistent because a model now makes it — it becomes consistently opaque, and considerably harder to interrogate after the fact.This is the trap: technology projects are approved and funded as efficiency and growth initiatives, sitting under profit and transformation mandates, while the governance question — should we even be automating this, and is it safe to do so — gets treated as a downstream implementation detail rather than a precondition.Culture rarely appears on a transformation roadmap, and that omission is itself revealing. Culture is what determines whether risk gets raised or buried, whether a control failure is escalated or quietly worked around, whether “the system told me to” becomes an acceptable answer to an auditor. No amount of technology sophistication compensates for a culture where people don’t feel safe naming a problem.This matters more, not less, as organisations adopt AI. Automated systems don’t just execute a process — they encode an organisation’s tolerances. A culture that tolerates ambiguous ownership will produce an AI deployment with ambiguous ownership. A culture that treats controls as a compliance checkbox rather than a genuine safeguard will deploy AI the same way: as a checkbox exercise, rushed to production because a deadline is louder than a risk register.Technology inherits the culture of the organisation that builds it. If the culture is chaotic, the technology will digitise that chaos with impressive fidelity.There’s a persistent framing, especially in fast-moving technology functions, that controls and risk exist to slow things down — the department that says no while everyone else tries to ship. This framing is not just unhelpful, it inverts the actual value controls provide. A control is what allows an organisation to move quickly with confidence, because it defines the boundaries within which speed is safe.Controls that are designed after a system is already in production are not controls. They are documentation of what already happened, useful mainly for the post-incident review. Real control design has to happen before the technology decision is made — as part of the technology decision — not layered on afterward as a governance patch.This is precisely why AI Operations as a discipline matters: it is not simply “operations, but with AI in it.” It is the deliberate practice of building operating models where control design, risk appetite, and human accountability are established before the automation goes live, not reconstructed after something goes wrong. Enterprise AI transformation done properly is a controls-first exercise wearing a technology coat.
This page contains an attributed headline and the preview text supplied through the publisher’s RSS feed. Copyright in the original reporting belongs to CIO Africa.
