There's a quiet failure happening across South African enterprises right now, and most executives haven't named it yet. They've signed contracts with AI agencies. They've watched impressive demos. They've paid the invoices. And six months later, the "AI solution" is either gathering dust in a forgotten corner of the tech stack, or it's producing outputs that nobody on the team actually trusts enough to act on.

The problem isn't the technology. Large language models, computer vision, anomaly detection — the underlying capability is genuinely powerful. The problem is the delivery model. The traditional AI agency approach — build it offsite, hand it over, invoice, leave — was borrowed from the era of building websites and mobile apps. It doesn't survive contact with the messy reality of a live enterprise, and nowhere is that more obvious than in cybersecurity.

Why the ordinary AI agency model fails

The classic agency relationship is transactional by design. You write a brief, they build to spec, they deliver, you sign off. This works fine when the requirements are stable and well understood — a marketing site, a booking system, a reporting dashboard. But AI systems, particularly in security, are none of those things.

Here's what actually goes wrong:

  • The context evaporates. An external team builds a threat-detection model based on a snapshot of your environment. But your environment isn't a snapshot — it's a living thing. New applications get deployed, network topology shifts, staff join and leave, and the threat landscape mutates weekly. The model was tuned for a world that no longer exists by the time it goes live.
  • Nobody owns the feedback loop. When your SOC analysts flag a false positive at 2am during a load-shedding-induced infrastructure hiccup, who fixes it? The agency finished the engagement in March. Getting them back requires a change request, a scoping call, and a quote. By the time that's approved, the analysts have stopped using the tool.
  • Generic models meet specific threats. An off-the-shelf model trained on international datasets doesn't understand that a spike in traffic from a particular ISP at month-end is normal for your payroll run, not an exfiltration attempt. Local context — the kind that separates a real incident from noise — is exactly what generic solutions lack.
  • Alignment is assumed, never verified. The agency's goal is to deliver against the contract and move on. The CISO's goal is to reduce real risk continuously. Those two objectives overlap on paper and diverge in practice almost immediately.
The uncomfortable truth: most AI agency engagements optimise for shipping a deliverable, not for changing a security outcome. Those are very different things.

What Forward Deployed AI Engineering actually means

Forward Deployed AI Engineering (FDAIE) inverts the model. Instead of building AI at arm's length and throwing it over the wall, you embed specialised AI engineers directly inside the team that will live with the system. They sit with your SOC analysts. They watch how alerts are actually triaged. They see which dashboards get ignored and which ones drive decisions.

The term "forward deployed" comes from a military and expeditionary logistics idea — you position your capability at the front line, close to where the action happens, rather than keeping it safe and distant at headquarters. Applied to AI engineering, it means the people building the models are in the room where the models are used.

Concretely, an FDAIE engineer working with a South African bank's security team might spend their first two weeks doing nothing but observing. Learning that the fraud team distrusts model output because a previous vendor's tool cried wolf too often. Discovering that half the "anomalies" flagged by the existing system are just the quarterly reconciliation batch. Understanding that POPIA constraints mean certain customer data can never leave a specific data residency zone — so the model has to be architected around that from day one, not retrofitted after an audit finding.

That embedded knowledge is impossible to capture in a requirements document. It only transfers through proximity.

The three advantages that compound over time

1. Deep integration with internal teams

When an AI engineer is part of the security team's daily standup, alignment stops being a hopeful assumption and becomes a lived reality. The engineer hears the CISO's priorities directly. They understand the difference between what the board is asking for and what the analysts actually need at the coalface. Models get built to serve the real workflow, not an idealised version of it drawn on a whiteboard during a kickoff meeting.

2. Rapid iteration from frontline feedback

This is where FDAIE pulls decisively ahead. In the agency model, feedback travels through a formal, slow channel: ticket, triage, quote, approval, sprint, delivery. In the embedded model, an analyst can turn to the engineer and say "this alert type is useless" — and by the end of the week the model has been retuned. That tightness of loop is the entire game in security, where threats evolve faster than any quarterly release cycle can accommodate.

3. Customisation that adapts to a moving target

A threat landscape is never static, and in South Africa it has its own texture. We see phishing campaigns tailored to local banks, business email compromise attacks that exploit our specific payment rails, and social engineering that plays on load-shedding disruptions ("your account was suspended during the outage, click here to restore"). A model that adapts continuously, guided by an engineer who understands both the AI and the local context, stays relevant. A frozen, delivered-and-forgotten model degrades from the moment it ships.

The South African case for embedding, not outsourcing

There are reasons the FDAIE model is especially well-suited to the local enterprise landscape.

POPIA changes the economics. When personal information is involved — and in a bank, insurer, or telco it almost always is — you cannot casually ship data to an external team for model training and iteration. Data residency, consent, and processing constraints are legal requirements, not preferences. An embedded engineer working inside your environment, on your infrastructure, under your governance, sidesteps an entire category of compliance risk that the traditional agency handoff creates.

Rand economics reward durability over flash. Buying a glossy international AI platform priced in dollars, then paying dollar-denominated support fees to keep it running, is an expensive way to end up with a tool that doesn't understand your environment. Investing in engineers who build capability that stays inside your organisation — and who upskill your own people as a side effect — is a fundamentally better return in a weak-currency economy.

Local context is the whole point. Threat detection is pattern recognition, and patterns are meaningful only in context. An engineer who knows that Eskom stage 6 correlates with a spike in failed VPN reconnections, or that a particular traffic pattern is your medical aid claims batch and not a data breach, builds models that don't waste your analysts' scarce attention on false alarms.

What this means for CISOs

If you're a security leader weighing an AI investment, the question isn't really "which AI vendor?" It's "which delivery model actually changes my security posture six months from now?"

Here are the takeaways worth holding onto:

  • Judge vendors on the feedback loop, not the demo. A polished demo tells you what the technology can do on a good day. Ask instead: when this fails at 2am, how fast does it improve? If the honest answer involves a change request and a quote, you have a problem.
  • Prioritise capability transfer. The best engagements leave your team stronger, not just handed a black box. If nobody internal understands how the model works, you've bought a dependency, not a solution.
  • Treat AI in security as a continuous practice, not a project. Threats iterate; your defences must too. Any model that's "done" is already decaying.
  • Build compliance in from the start. Under POPIA, retrofitting governance onto a delivered system is painful and risky. Embedding engineers inside your controlled environment makes compliance the default rather than the exception.

The traditional agency model wasn't wrong for its era. It's simply the wrong tool for a problem that never stops moving. Forward Deployed AI Engineering isn't a rebrand of consulting — it's a recognition that in cybersecurity, the value of an AI system is created not at delivery, but in the thousand small adaptations that follow. And those only happen when the people who build the models are close enough to the fight to see what's actually happening.

The real question for security leaders isn't whether to adopt AI. It's whether to keep it at arm's length, or bring it inside where it can actually earn its keep.