When a large organisation presents its AI programme on a conference stage, the audience usually sees the finished layer: an assistant that helps service agents, a scam warning that appears at the right moment, a feature that feels personal without feeling creepy. What the audience rarely sees is the part of the story that came first, and in many cases the part that made the rest possible.
In South African financial services that earlier part often has a familiar shape. A core system falls over for a day or more. Customers cannot pay, the call centre is overwhelmed, the story reaches the news, and the board asks a question nobody can answer comfortably: how do we make sure this never happens again? The answer takes years. It involves re-platforming, breaking a monolith into domains that teams can own, rebuilding monitoring and recovery, and changing how releases are made. None of it is called AI. All of it is what an AI programme later stands on.
This series looks at South African enterprise AI in practice, using composite organisations rather than named companies. The point is not to tell one institution's story. It is to draw out the patterns that keep appearing when AI work actually reaches customers, and the decisions that leaders can take from them.
Strelitzia Bank is fictional, a composite drawn from patterns that recur across the industry, and its systems and figures are illustrative.
The outage that changed the agenda
Strelitzia Bank had grown quickly on a core platform that was never designed for its eventual volume. Releases were large and infrequent because every change touched shared code. Monitoring told the operations team that something was wrong, but rarely what or where. Recovery depended on a small number of people who understood how the pieces fitted together.
Then came the long outage. A routine change interacted badly with a database maintenance job, and restoring service took well over a day. Afterwards, the post-incident review found the usual list: no clear ownership of the failing component, no tested rollback, alerts that fired in the hundreds without pointing to a cause, and recovery steps that existed only in people's heads.
The bank's leadership did something that sounds obvious in hindsight and is hard in practice. It treated the outage as a strategy problem rather than an operations problem. The decision was not "fix this incident". It was "stop running the bank on a platform that produces incidents like this".
Why reliability work is AI work
At the time, nobody at Strelitzia described the re-platforming programme as preparation for AI. It was about keeping the bank open. Looking back, it did four things that every later AI feature depended on.
It created owned domains. Payments, cards, lending, customer profile and fraud became separately owned services with their own teams, interfaces and release cycles. An AI feature that needs to read recent transactions, check a fraud signal and open a service case now calls three owned interfaces rather than reaching into a shared database nobody wants to touch.
It produced trustworthy data in motion. Domain events, such as a debit order failing or a card being declined, became first-class records with consistent definitions. Those events are exactly what a service assistant needs to explain to a customer why their payment bounced. Before the re-platforming, the same information lived in batch extracts that arrived the next morning.
It made failure visible. Tracing, structured logs and service-level objectives meant the bank could see a problem as it developed and isolate it. AI features add new ways to fail, such as a slow model provider, a retrieval index that has gone stale, or a tool call that times out. A bank that can already see and contain failure in its core services can do the same for its AI services. One that cannot will discover its AI failures on social media.
It returned engineering time. This is the least visible effect and the most important.
The capacity argument
Every engineering organisation has a fixed amount of attention. Before the re-platforming, a large share of Strelitzia's engineering time went to firefighting: incident calls, emergency fixes, manual reconciliations after failed batches, and long release weekends. Another large share went to keeping the lights on. What remained for building new things was small and constantly interrupted.
Reliability work did not hire more engineers. It changed where their time went. As incidents became rarer and shorter, the time that used to disappear into firefighting became available for product work. That released capacity is where the AI programme came from: the teams who built the service assistant, the scam-warning feature and the internal knowledge tools were the same teams who, a few years earlier, would have spent that quarter recovering from the latest outage.
This is the argument executives most often miss when they compare their AI progress with a competitor's. They see the competitor's features and assume the gap is a data science gap or a vendor gap. More often it is a capacity gap. The competitor has teams with time to build. The organisation asking the question has teams still fighting the last fire.
What reliability looked like in practice
Reliability is easy to praise and hard to define. At Strelitzia it came down to a handful of measurable changes, each with an owner.
| Change | What it replaced | What it made possible later |
|---|---|---|
| Domain-owned services with versioned interfaces | One shared codebase and database | AI features calling owned APIs with clear contracts |
| Small, frequent releases with tested rollback | Quarterly release weekends | Shipping and withdrawing AI features safely |
| Service-level objectives per domain | "The system is up" or "the system is down" | Agreed latency and availability budgets for AI calls |
| Tracing across services | Logs searched by hand after the event | Following one customer request through model, tools and core systems |
| Rehearsed recovery runbooks | Recovery held in a few people's heads | Clear fallbacks when an AI dependency fails |
| Event streams with shared definitions | Overnight batch extracts | Real-time context for service and fraud AI |
None of these is novel. That is the point. The organisations that look advanced in AI are frequently the ones that did the unglamorous engineering earlier and more thoroughly.
The trap: AI as a substitute for foundations
The opposite pattern is common too. An organisation with an unstable core, overnight data and a backlog of incidents commissions an AI programme because the board wants one. A vendor builds a proof of concept on a copy of last month's data, the demonstration goes well, and then the programme stalls when it meets the production estate.
The assistant cannot see today's transactions because the data arrives tomorrow. It cannot open a case because the case system has no usable API. When the core platform slows down at month-end, the assistant slows down with it, and nobody can tell whether the problem is the model or the bank. The programme is reported as an AI failure. It is a foundations failure that happened to be discovered by an AI project.
We have written about this pattern from the data side in Data foundations before AI and about the leap from demo to production in Production begins after deployment. The reliability lens adds one more question that leaders should ask before approving the next AI investment: if this feature were live today, could our core systems keep it honest at month-end?
A readiness check for leaders
Before a material AI investment reaches customers, five reliability questions are worth answering in writing. They are not technical trivia; each one changes the risk the business is taking.
- Ownership. Which team owns each system the AI feature depends on, and do those teams know the feature exists?
- Interfaces. Does the feature reach those systems through versioned, documented interfaces, or through shared databases and screen scraping?
- Freshness. How old is the data the feature uses at the moment a customer asks a question?
- Visibility. If the feature gives a wrong or slow answer, can we trace that single request through every system it touched?
- Fallback. When the model provider, the retrieval index or a core system fails, what does the customer experience, and has anyone rehearsed it?
If most answers are uncertain, the most valuable AI investment this year may not be an AI feature at all. It may be the reliability work that makes the next three AI features cheap, safe and fast to build.
What South African conditions add
Two local factors sharpen the argument. The first is infrastructure volatility. Power interruptions, connectivity incidents and cross-border latency to model providers mean an AI feature has more external failure points here than in markets where those dependencies are taken for granted. A design that assumes the model is always reachable is a design that will fail in front of customers.
The second is trust. South African consumers have learnt, through scams and data breaches, to be wary of digital channels. An AI feature that fails visibly during an outage, or gives a confident wrong answer about a customer's money, does more damage here than a delayed feature would have. Reliability is not only an engineering virtue. It is part of the brand promise that makes customers willing to accept AI help at all.
The point of view
AI value in an enterprise is downstream of operational reliability. The organisations that seem to move fastest with AI are usually the ones that invested earlier in owned domains, observable systems, rehearsed recovery and the engineering capacity those things return. For leaders comparing themselves with those organisations, the uncomfortable conclusion is that the gap is often not in AI at all.
Start by asking where your engineering time goes. If the answer is "mostly firefighting", the first AI investment is reliability.
Next: Part 2, Helpful or intrusive? Temporary customer context in service AI. All parts are on the series page.
Background reading: CIO South Africa, "2026 IT Indaba: Capitec CIO Andrew Baker showcases the practical and delightful side of AI", 21 October 2026.
How CloudNala can help
We help leadership teams test whether their foundations can carry the AI programme they are planning. That means mapping the systems a proposed AI feature depends on, checking ownership, interfaces, data freshness, observability and fallback, and producing a short, prioritised list of the reliability work that should come first. Where the foundations are ready, we help design the AI feature so that it inherits that reliability rather than undermining it.
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