How Can Technical Staff Upskill on AI?

Every technology function in a financial services firm now faces the same question: are our engineers, data specialists and infrastructure teams actually ready to build, integrate and support AI systems?

It is tempting to assume the answer is yes. These are, after all, the people who already work with technology every day.

But AI systems behave differently from the deterministic software technical teams are used to building. Outputs can vary between runs. Performance can drift as data changes. Behaviour can be difficult to explain, even to the people who built the integration.

General workforce AI literacy programmes do not close this gap. Technical staff need something more specific: a genuine understanding of how AI models behave, how to evaluate them, and how to build around them in a way that remains governable.

This article sets out what that upskilling should look like, and why hands-on experimentation — not courses alone — is what makes it stick.

Why Technical Staff Are Not Automatically AI-Literate

It is a reasonable-sounding assumption: someone who can build a reconciliation engine, maintain a data pipeline or write trading system code must already understand AI.

In practice, this assumption is frequently wrong, and operationally risky.

Traditional software is deterministic. Given the same input, it produces the same output, every time. Technical staff are trained, tested and promoted on their ability to reason about systems that behave this way.

AI models, particularly machine learning and generative models, do not always share this property. The same input can produce different outputs between runs. Performance can degrade as underlying data shifts — a phenomenon known as drift. Model reasoning is often opaque, making it hard to explain exactly why a particular output was produced.

None of this is covered by general software engineering skill, no matter how strong. It is also not fully addressed by general workforce AI literacy training, which is designed to build awareness and risk sensitivity across an entire organisation rather than the deeper technical fluency engineers and data teams need to build, test and support AI systems responsibly.

The result is a specific and often invisible skills gap. Technical staff who are highly capable in traditional system design can still be under-prepared to integrate AI safely, simply because no one has addressed the behavioural differences directly.

Traditional Approaches to Technical AI Training

Most firms start technical AI upskilling in familiar ways: vendor certifications, online courses and internal documentation.

These approaches have genuine value. Vendor certifications give structured, credentialed grounding in a specific platform or toolset. Online courses can efficiently cover foundational concepts — what a large language model is, how retrieval-augmented generation works, what fine-tuning does — at scale and low cost. Internal documentation captures firm-specific standards and expectations that generic courses cannot.

However, these methods share a common limitation when applied to AI specifically: they build knowledge, not capability.

A developer can complete a certification on a model provider's platform and still not know how their own firm's trade data will behave when it drifts, or how to design an evaluation framework for a model embedded in a live reconciliation process. Passive learning formats are well suited to explaining concepts, but AI's behavioural quirks — variability, drift, sensitivity to input framing — are best understood by encountering them directly.

Certifications and courses remain a useful foundation. They are rarely sufficient on their own, and firms that stop there often discover the gap only once an AI-enabled system is already in production.

Where Hands-On, Experimental Learning Helps

This is where AI genuinely changes what technical upskilling can achieve.

Sandboxed, hands-on experimentation allows technical staff to encounter the real behaviours of AI models directly, using data and use cases that resemble their actual working environment, without the risk of affecting live systems.

A well-designed sandbox exercise might ask an engineering team to run the same model against the same dataset multiple times and observe variability, deliberately introduce a shift in the input data to observe drift, or build a basic evaluation framework to score model outputs against known-good answers. These are experiences that no amount of reading or certification study reliably produces.

Peer review and mentoring add a further layer of value. When technical staff work through AI integration problems alongside colleagues who have already encountered similar issues, they develop pattern recognition faster and are more likely to raise concerns early rather than after deployment.

This does not remove the need for oversight. Sandbox exercises should be structured, reviewed and connected to the firm's actual governance expectations, not treated as unsupervised exploration. AI accelerates the learning curve; it does not replace the judgement of technical leads, model risk teams or governance functions who need to sign off on what gets built.

Making Technical Upskilling Stick

Even a well-designed hands-on programme fails if it cannot survive contact with delivery pressure.

Technical staff need protected time, explicitly carved out of delivery schedules, to experiment meaningfully. Without this, upskilling activity is the first thing dropped when deadlines tighten.

Sandboxes need careful design. They should use data that is representative of real firm use cases — trade volumes, data structures, seasonal patterns — without exposing sensitive or regulated information. Anonymised or synthetic datasets built from historical records often strike the right balance.

Mentoring structures matter as much as the technical content. Pairing less experienced engineers with those who have already worked through AI integration challenges spreads capability faster than any course can.

Finally, technical skill-building should be explicitly linked to governance responsibilities. Engineers who understand why evaluation checkpoints, drift monitoring and explainability matter — not just how to build them — are far more likely to design systems that remain auditable, and far better prepared to answer questions from model risk or compliance functions.

Skills also degrade without practice. A single upskilling sprint is a useful starting point, but ongoing exposure — new sandbox projects, periodic reassessment, refreshed exercises as tools evolve — is what keeps technical AI capability current.

Example

A London-based fixed income trading desk's technology team is asked to integrate an AI-based anomaly detection tool into their trade reconciliation process.

The engineering team initially treats it like any other software integration. During testing, they discover the model's outputs vary between runs and degrade when trade volumes spike around month-end settlement.

The team pauses deployment and undertakes a structured upskilling sprint covering model evaluation, drift monitoring and explainability, using a sandbox built from anonymised historical reconciliation data.

After the sprint, the engineering team redesigns the integration with built-in evaluation checkpoints and drift alerts, and can clearly explain the model's behaviour to the firm's model risk committee before go-live.

FAQs

• Is general AI literacy training enough for technical staff?

  No. General AI literacy training builds organisation-wide awareness of AI risks and opportunities, but technical staff need deeper, more specific skills in model behaviour, evaluation and integration that general training does not address.

• What is the fastest way to build real AI capability in an engineering team?

  Combine short conceptual grounding with hands-on sandbox projects using representative data, supported by mentoring and peer review, rather than relying solely on courses or certifications.

• How do we keep technical AI skills from becoming outdated?

  Treat upskilling as ongoing practice rather than a one-off event. Pair regular hands-on projects with periodic reassessment as tools and internal use cases evolve.