Clients increasingly ask us a direct question: do you use AI to produce your work? The honest answer is yes. AI helps us summarise sources, draft sections, generate diagrams, check documents for gaps and format deliverables. It would be strange for a firm that advises on AI not to use it.
The more useful question, and the one we would ask in a client's position, is different: who is accountable for what you hand over? A deliverable can be drafted with heavy AI assistance and still be fully owned by a named person who framed it, verified it and signed it off. It can also be drafted with little AI and owned by nobody in particular. The amount of AI involved matters less than whether the accountability chain is intact.
This part describes how we keep that chain intact. It is not a claim that our process is perfect. It is a description of the controls we use and the reasons for them, so that clients can test them.
This article describes CloudNala's working practice. No client work, names or results are referenced.
Accountability has to live somewhere specific
When AI is involved in producing a deliverable, there is a temptation to let accountability diffuse. The AI drafted it, a consultant edited it, a reviewer skimmed it, and the client received it. If a claim turns out to be wrong, nobody quite owns the mistake.
We avoid this by being explicit about which steps the AI may perform and which steps always belong to a person. In every deliverable, five steps matter.
Frame. A person sets the scope, the question the deliverable must answer, and the context the AI may use. The AI does not decide what the work is about.
Draft. The AI may draft sections, summarise sources and propose structure. A person chooses the argument and decides what to keep.
Check. The AI can run checks: flagging missing sections, unsupported claims, inconsistencies between a figure in one place and a figure in another. A person verifies material claims against the evidence, especially anything about a client's environment, a product's behaviour, a regulation or a cost.
Approve. A named person signs off. This step has no AI involvement by design, because it is the step that carries accountability.
Issue. The AI may help format and package the output. A person versions it and sends it, so there is a record of exactly what the client received.
The AI lane can grow as tools improve. The human lane never empties. That is the rule, and it holds regardless of which tool is used.
Context control comes before any prompt
The second discipline concerns what the AI is allowed to see. Most of the serious risks in AI-assisted consulting are not about the quality of the output. They are about information going somewhere it should not: client material sent to a tool the client has not approved, one client's context bleeding into another client's work, or confidential detail ending up in public content.
We sort material into tiers before any tool sees it.
- Public material: published sources, regulations, vendor documentation and our own published articles. This can be used with approved AI tools freely.
- CloudNala working material: our methods, templates and checklists. This can be used with approved tools inside our own environment.
- Engagement material: information a client has approved for use on their engagement. This stays inside that engagement's workspace and is never mixed with another client's.
- Client confidential material: anything the client has not approved for AI processing, or that their policy requires to stay in their own environment. This stays in the client's tools, and our AI tools do not touch it.
Nothing moves outward from an inner tier without a person deciding that it may. When we write public articles, including this series, we use fictional organisations and rebuild examples from public sources rather than redacting real ones. A relabelled client diagram is still a client diagram.
Specialist roles, not one general assistant
A single general-purpose AI conversation that does research, writes architecture, estimates cost and drafts a proposal tends to produce plausible text that is weak in each area. We get better results, and clearer accountability, by splitting work into specialist roles with defined inputs and outputs: a research step that produces a source register, an architecture step that produces decision records and diagrams from a typed source, an estimation step that produces assumptions and ranges, and a writing step that turns verified material into prose.
Each role has its own instructions, its own boundaries and its own checks. The person responsible for the deliverable reviews the outputs of each role, not just the final document. This is the same principle we describe for software in AI changes responsibilities, not accountability.
Evidence review is the expensive step, and the important one
Drafting is now cheap. Verification is not, and it should not be. For every material claim in a deliverable, we want to know where it came from, when it was checked and whether it is a fact, an inference or a recommendation. Volatile claims, such as prices, regional availability, product versions and regulations, are rechecked on the day the deliverable is finalised, because a claim that was true last month may not be true today.
This is the step most at risk of being skipped when AI makes everything else fast. A polished document creates a feeling of completeness that the evidence may not support. Our rule is simple: if a claim cannot be traced to a source or to a named person's confirmed judgement, it is either removed, softened to what can be supported, or labelled clearly as an assumption.
Versioned deliverables
Every deliverable we issue is versioned, and the version a client receives is the version that was approved. If a client comments on version 2 and we produce version 3, the comments are resolved against version 3 explicitly rather than assumed to carry over. This sounds administrative. It matters most when a deliverable feeds a decision: a client should always be able to say which version of the analysis they relied on.
What clients should ask any adviser
These controls are not unique to us, and clients should expect something like them from any firm using AI. Five questions test whether an adviser's accountability chain is real.
- Who framed this deliverable, and what context was the AI given?
- Was any of our confidential material processed by an AI tool, and which one?
- How were material claims verified, and when?
- Who signed it off, by name?
- Which version did we receive, and what changed from the last one?
An adviser who cannot answer these clearly is not necessarily careless. But the answers should exist.
The point of view
Using AI to produce client work is not the risk. Losing track of who is accountable for it is. The controls that matter are explicit roles for AI and people, context sorted before any tool sees it, evidence verified by a person, a named approver and versioned deliverables. With those in place, AI makes good work faster. Without them, it makes unaccountable work faster.
Next: Part 3, Claude, Codex and Copilot are tools inside a delivery system. All parts are on the series page.
How CloudNala can help
We help professional services teams and internal advisory functions design their own AI-assisted working practice: context tiers, specialist roles, evidence review, approval and versioning. The result is a short operating standard that lets people use AI tools confidently while keeping accountability with named individuals.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Talk to CloudNala or write to us at consult@cloudnala.co.za