The quickest way to make an AI rollout awkward is to launch the chatbot and only then ask who is responsible for its answers.
The quickest way to make an AI rollout awkward is to launch the chatbot and only then ask who is responsible for its answers.
A team may ask which model to buy or which workflow to automate before deciding who owns the risks. Privacy, security and quality questions then arrive late.
Australia’s Guidance for AI Adoption points in the opposite direction.
Its first essential practice is simple: decide who is accountable.
That sounds administrative, but it exposes one of the biggest weaknesses in modern AI adoption. Imagine five departments using six AI products through three vendors. If nobody can answer who is responsible when an output causes a problem, the arithmetic is the least worrying part.
Accountability should exist at both organisational and system level.
A senior owner should understand the company’s overall AI posture. Individual systems should also have people who understand their purpose, limitations, data, risks and escalation path.
From there, responsible AI becomes a repeatable operating discipline.
Risk needs to be assessed according to use. A model helping draft internal notes is not equivalent to a model ranking job applicants. A customer-support summariser is not equivalent to automated eligibility assessment.
Data needs to be understood. Where does it come from? Does it include personal or sensitive information? Does a third-party provider retain prompts? Can the organisation explain what information is moving outside its environment?
Systems need testing. “The demo looked good” is not a test strategy. AI systems can fail inconsistently, so teams need acceptance criteria, edge cases and ongoing monitoring.
Human oversight also needs to be real rather than ceremonial. A person clicking “approve” without enough information, authority or time to challenge an output is not meaningful oversight.
Transparency needs to be designed for the audience. Customers do not need a research paper about a model architecture, but they may need to know when AI is interacting with them or materially influencing an outcome.
Finally, organisations need records.
In a poorly managed workflow, prompts can disappear into chat histories and decisions can scatter across email and browser tabs. An inventory of deployed systems gives someone a place to start asking what is actually running.
That is not scalable.
One reason I increasingly favour connecting AI activity to systems such as ERPNext, Payload or Trilium is not because every company needs those exact products. It is because AI needs a place to live operationally.
A useful AI workflow should have state.
It should know whether something is a draft, needs review, has been approved, has been rejected, has been published or requires investigation.
This makes governance less abstract.
Instead of writing an AI policy that sits in a PDF, the rules become part of the workflow itself.
For agencies, this is a major opportunity. Clients do not just need somebody who can generate content or add an AI chatbot to a website. They need people who can help them integrate AI into a coherent operating environment.
The next generation of digital work will be judged less by whether AI was used and more by whether it was used deliberately.
References used for this article
If you can relate, feel free to reach out.




