We worked with a highly regulated financial trading organisation operating under strict data-security and compliance requirements.

The organisation relied heavily on internal systems such as Jira, Confluence, and operational runbooks. Over time, these systems accumulated a large amount of valuable knowledge, but accessing the right information quickly — especially in time-critical situations — had become increasingly difficult.

Public cloud AI tools were not an option. Any solution needed to operate entirely within the organisation’s own infrastructure, without sending sensitive data to external services.

The Real Problem

The challenge was not introducing AI for its own sake. The real issue was a lack of operational clarity.

Engineers and operations teams spent significant time piecing together context: searching through documentation, navigating multiple tools, and relying on institutional knowledge held by a small number of individuals. This slowed decision-making and increased cognitive load, particularly during incidents.

At the same time, there was little appetite for experimental or opaque systems. Any AI-based solution needed to behave predictably, respect existing access controls, and provide answers that could be trusted.

Constraints That Shaped the Design

From the outset, the system was shaped by a set of non-negotiable constraints.

All data and inference had to remain inside the organisation’s environment. Access to information needed to mirror existing permission models exactly, without introducing new security boundaries. Outputs had to be inspectable and grounded in internal sources, and the system had to support human decision-making rather than act autonomously.

Just as importantly, the solution needed to integrate with existing tools rather than disrupt established workflows.

What We Built

We designed and deployed a private AI assistant running entirely on-prem.

At its core, the system combined an on-prem language model with a retrieval layer connected to internal tools such as Jira and Confluence. Access to documents was permission-aware, aligned with the organisation’s existing identity and access controls.

The assistant was exposed through a conversational interface used by engineering and operations teams. Its role was deliberately narrow: to surface relevant internal knowledge, summarise existing documentation, and help users navigate complex systems more efficiently. It was not designed to generate speculative answers or take autonomous actions.

Design Considerations

Several considerations guided how the system was introduced and evaluated.

Trust was treated as a first-class concern. Rather than optimising for fluency or breadth, the focus was on consistent, grounded behaviour that allowed users to build confidence over time. Evaluation emphasised correctness and usefulness in real operational contexts, rather than generic AI benchmarks.

Particular care was taken to ensure that permission boundaries were respected at every step, and that responses could be traced back to internal sources when needed. The system was intentionally scoped to remain assistive, avoiding any functionality that could introduce operational risk.

Outcome

The assistant became a reliable internal reference point, particularly for incident response, onboarding, and navigating internal documentation.

The primary benefit was not raw speed, but confidence. Teams were able to access relevant information more quickly, with a clear understanding of where it came from and why it was appropriate to trust. Over time, this reduced friction, context-switching, and reliance on informal knowledge channels.

Why This Matters

This deployment reinforced a simple but important lesson.

In regulated environments, effective AI systems prioritise control, clarity, and trust over raw capability. Private AI succeeds when it makes existing knowledge usable, without increasing risk or undermining established safeguards.