Two things are true about AI workloads that are not true about most software your organisation runs.
The first is that they charge by consumption, at a rate that varies with how the system behaves rather than how many users it has. A retry loop, a longer document, or a change in how verbose the model is feeling all move the bill. The second is that the same input can produce different output on different days, which means "it worked when we tested it" carries less weight than usual.
Both properties point at the same requirement. You need to be able to see what the system did.
What to capture
For every run: the input, what was retrieved and from where, the model and version used, the prompt, the tool calls with their arguments and results, the final output, the tokens consumed, the latency, the cost, whether it escalated, and what a human changed if they changed anything.
That is more than most teams capture and less than it sounds, because it is one structured record written once per run. The discipline is capturing it at the source rather than reconstructing it later from application logs, which does not work.
Two fields are consistently under-appreciated. What was retrieved is the first thing you need when an answer is wrong, because it immediately separates a retrieval failure from a reasoning failure — two entirely different fixes. What the human changed is a free, continuously-generated quality signal: if reviewers rewrite the same section of every draft, the system has a specific, fixable weakness, and nobody had to file a ticket for you to learn it.
Three audiences, one trace
The same record answers three different questions, which is why it is worth capturing properly once.
The business wants to know whether the thing is working: how many cases were handled, how much time was saved, how often a human had to intervene, whether quality held. This is the view that determines next year's budget, and it is the one most commonly missing.
The engineers want errors, latency, retry rates, tool failure rates and which step is slow.
Finance wants cost per workflow, per team, per month, and a forecast. This is where AI differs sharply from the rest of the estate, because cost is a function of behaviour rather than provisioning.
Cost as a design constraint
A worked example of why this matters. An agent handles a request in four model calls at a manageable cost each. On a difficult case it retries, calls a tool that returns something unexpected, reasons about it, and takes eleven calls. If ten percent of your volume behaves like the second case, your average cost is nearly half again what your pilot suggested — and the pilot ran on clean cases, because pilots always do.
This is not an argument against agents. It is an argument for four controls that belong in the design from the start.
A hard ceiling on steps per task, enforced in code. A cost budget per task, checked as the task runs, that stops the work and escalates rather than continuing. Alerting on cost per unit of work rather than on the monthly total — a doubling of per-case cost is visible weeks before it shows up on an invoice. And routing by difficulty, so that the straightforward eighty percent of cases go to a smaller, cheaper model and only the hard ones reach the expensive one.
That last one is where most of the savings sit, and it requires knowing which cases are hard, which requires the trace data. The controls compound.
Rand-denominated realities
For South African organisations there are two specifics worth planning for.
AI services are almost universally priced in United States dollars while budgets are approved in rand, so the exchange rate is a live variable in your run cost. A workload budgeted at one exchange rate can be materially over at another without a single line of code changing. Track cost in both currencies and set the alert thresholds in rand, because that is what the finance committee will ask about.
Data residency also interacts with cost. Processing in a South African region, where it is required for POPIA or contractual reasons, sometimes carries different pricing and different model availability than the cheapest global option. That is a legitimate constraint — but it should be a decision made explicitly, with the cost difference quantified, rather than discovered when someone reviews the invoice.
The governance argument
Beyond cost, there is a question every organisation deploying AI into a real process will eventually be asked, by a client, a regulator, an auditor or an unhappy customer: what did the system do, and why?
Without a trace, the answer is a description of how the system generally works. With one, the answer is the specific record: this is the request, these are the documents it read, this is what it produced, this is who approved it, at this time.
The gap between those two answers is the gap between a manageable incident and an unmanageable one. It is also, increasingly, the gap between passing a client due-diligence questionnaire and not.
What can go wrong
Logging prompts and outputs means logging whatever the user put in them, which for many workflows includes personal information. The trace store therefore inherits the same POPIA obligations as any other system holding that data — retention limits, access control, deletion on request. Teams routinely build excellent observability and accidentally create an ungoverned copy of sensitive data in the process. Decide what is redacted before you turn it on, not after.
The other common failure is capturing everything and looking at none of it. A trace store nobody queries is storage cost with no benefit. One dashboard that a named person reviews weekly is worth more than a complete telemetry pipeline nobody has opened since it was built.
How to start small
Log one structured record per run into a table. Input, retrieved sources, output, tokens, cost, latency, escalated, human-edited. That is a single table and an afternoon of work, and it will answer most questions you have in the first six months.
Add a weekly view showing volume, cost per case, escalation rate and human-edit rate. Watch the trend rather than the absolute numbers. Set an alert on cost per case rather than total spend.
Then, when the system matures, adopt proper tracing tooling. Doing it in that order means you will know what you actually need from the tooling — which is a much better position than choosing a platform first and discovering that it captures everything except the two fields you keep wanting.
How CloudNala can help
We instrument AI workloads so that the business, engineering and finance questions are all answerable from the same trace — with per-case cost alerting, model routing by difficulty, budget ceilings enforced in code, and redaction decided before the first record is written. It is the same cost governance discipline we bring to cloud environments generally, applied to a workload whose spend moves with behaviour rather than provisioning.
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.
Book an AI Readiness Workshop or write to us at consult@cloudnala.co.za