Chloe Maraina has spent her career turning raw, complex data into clear operational insight for mission owners. As a Business Intelligence expert with a strong data science bent, she sits at the nexus of sovereign cloud, AI, and defense-grade integration. In this conversation, Chloe unpacks why Defence Technologies partnered with Oracle Cloud Infrastructure, how sovereign AI gets engineered and accredited across the UK, NATO, and allied nations, and what it takes to move from a whiteboard sketch to fielded capability without compromising security or speed. Themes range from platform selection and distributed cloud patterns to accreditation, procurement, scaling bottlenecks, and the day-to-day realities of making sovereignty tangible.
Summary of key themes: The interview explores mission-driven priorities that shaped the collaboration, the criteria and trade-offs behind choosing a hyperscale platform, and the practical lifecycle from day-one setup to production handoff. It examines cost and efficiency outcomes, fit-for-mission choices across Oracle’s distributed cloud options, and how sovereignty requirements shape data, identity, telemetry, and model governance. The discussion covers the role of Whitespace and the Oracle Defense Ecosystem in accelerating productization, the primary scaling bottlenecks for sovereign AI on OCI, and how security and performance are balanced through rigorous threat modeling and testing. It closes with roadmap translation into engineering backlogs, where adoption is moving fastest, and a practical playbook for replicating success.
This collaboration frames Defence Technologies and Oracle working together on sovereign cloud and AI. What specific mission challenges drove this move, and how did you prioritize them? Walk us through one real scenario, the metrics you tracked, and what “good” looked like in the field.
We were seeing missions struggle with three intertwined challenges: constrained connectivity at the edge, fragmented data governance across jurisdictions, and a widening gap between AI experimentation and accredited, sovereign deployment. We prioritized those by impact on decision timelines and risk to operational security, with a bias toward anything that could shorten the time from data capture to trusted action. In one scenario, we had sensors delivering bursts of unstructured data from a contested environment; we needed to triage, enrich, and serve actionable insights even when bandwidth dipped and latency spiked. The metrics were simple but unforgiving: time-to-first-insight, continuity of service under degraded links, and fidelity of audit trails for post-mission review. “Good” felt like the team in the field not noticing the turbulence—data arrived, models adapted, and the system quietly kept receipts for every decision without getting in the way.
You said the goal is to build sovereign AI products on “the world’s most trusted hyperscale platforms.” How did you evaluate platforms, and why did OCI win? Share the step-by-step selection process, key trade-offs, and any anecdotes from bake-offs or pilot tests.
We ran a staged evaluation: requirements capture with mission owners, architecture alignment with sovereign controls, hands-on pilots under degraded conditions, and an accreditation-readiness review. OCI distinguished itself on distributed cloud patterns we could place at the edge, inside customer facilities, and in dedicated regions with strong data and identity boundaries. The trade-offs were about balancing portability of our applications with deep integration into native services for observability, key management, and data pipelines. In a bake-off simulating low-bandwidth backhaul, OCI’s edge posture let us keep inference close to the source while syncing only what mattered upstream—no drama, just steady behavior when the link wobbled.
Customers can deploy Defence Technologies’ apps across OCI. How does that deployment actually unfold from day one to production? Detail the timeline, integration steps, security checks, and the handoff to operations, including the top three pitfalls you’ve learned to avoid.
Day one is about establishing a clean landing zone: compartments, network segmentation, keys, secrets, and identity mapped to roles that mirror the customer’s org chart. Next, we integrate data sources and baseline models, set up CI/CD with policy checks, and run red-team style validation against our threat model. Security checks are continuous—controls mapping, logging and telemetry verification, and resilience drills that force failovers. Handoff to operations includes runbooks, dashboards aligned to mission metrics, and a rehearsal under realistic load. The pitfalls: skipping early data classification, underestimating edge-to-core sync patterns, and treating accreditation as a checkbox instead of a living process.
You promise to help customers stay ahead of adversaries while cutting costs and boosting efficiency. What concrete cost baselines did you start with, and what savings have early adopters seen? Share measurable efficiency gains, with before-and-after workflows or staffing impacts.
We start by mapping costs to mission flows—data ingress and egress, storage tiers, training versus inference, and operations time spent chasing compliance artifacts. Early adopters saw meaningful reductions by pushing compute to the right place—edge for time-sensitive inference, core for heavy analytics—and by automating lineage and policy enforcement so teams weren’t hand-curating logs. Workflows that once required manual triage now trigger automated enrichment and routing, freeing specialists to focus on anomalies instead of routine. The qualitative result is fewer midnight calls and more daylight for analysis, with a spend curve that mirrors mission tempo rather than fixed, underutilized capacity.
The partnership taps Oracle’s distributed cloud: Roving Edge Infrastructure, Compute Cloud@Customer Isolated, and Exadata Cloud@Customer. How do you choose among these for a mission? Give a decision tree, example configurations, performance metrics, and a story where the “wrong” choice taught you something.
The decision tree starts with where data is born and who must control it: if it’s generated in the field with intermittent links, Roving Edge is first pick; if data must never leave a facility, Cloud@Customer Isolated wins; if the mission hinges on high-performance relational workloads, we bring Exadata Cloud@Customer to bear. We combine them—edge for inference and filtering, Cloud@Customer for model lifecycle and secure data processing, and Exadata for mission databases and analytics. Performance is gauged by latency to insight, durability of telemetry, and predictable throughput under bursty conditions. We once leaned too heavily on core services for an edge-heavy mission; moving inference to Roving Edge and tightening sync windows immediately smoothed operations and made the whole system feel calm.
Sovereign AI is central here. What does “sovereign” mean in practice across the UK, NATO, and allied nations? Break down data residency, identity, telemetry, model governance, and procurement constraints, and share a case where sovereignty requirements changed your architecture midstream.
Sovereign means data residency and processing boundaries that align with national rules, identity that federates without leaking control, telemetry that is complete but scoped, and model governance that traces lineage, training data, and policy adherence. Procurement adds constraints on where services can run, what external dependencies are allowed, and how updates are delivered and audited. In one program, a midstream policy update required tighter residency for derived data; we refactored the pipeline to keep feature engineering entirely in-country and shifted model retraining to a sovereign environment while retaining portable artifacts for deployment. It was a reminder that sovereignty isn’t a stamp—it’s an architectural posture that adapts as policy evolves.
Defence Technologies is a partnership between Defence Holdings PLC and Whitespace, an Oracle Defense Ecosystem member. How does Whitespace’s role accelerate productization? Describe handoffs, toolchains, and decision rights, with one example where ecosystem tooling shaved weeks off delivery.
Whitespace brings a product muscle that turns prototypes into repeatable offerings—clear interfaces, hardened pipelines, and packaging that survives real-world constraints. Handoffs look like this: we define the mission slice and data contracts, Whitespace codifies the integration patterns and CI/CD, and we jointly run the security and user acceptance loops. Decision rights are explicit—mission requirements with us, productization and tooling with Whitespace, and shared sign-off on security controls. Using Oracle Defense Ecosystem tooling for environment templating, we stamped out a compliant landing zone and deployment pipeline in one pass, avoiding bespoke scripting and shaving weeks off the path to first field trial.
You mentioned delivering sovereign AI at scale on OCI. What are the scaling bottlenecks you hit first—data pipelines, model training, inference, networking, or accreditation? Share actual throughput numbers, autoscaling thresholds, and a step-by-step tuning checklist that moved the needle.
The first bottlenecks are usually in data pipelines—schema drift and lineage gaps—followed by inference routing at the edge when links misbehave. Networking quirks surface next, especially when multiple enclaves and cross-domain guards are involved, and accreditation cadence can lag if evidence collection isn’t automated. While I can’t share specific throughput or thresholds, our tuning checklist is consistent: stabilize schemas and contracts, enable backpressure and batching where appropriate, place inference closest to data, right-size model artifacts, and pre-warm capacity for mission windows. Finally, we automate compliance evidence so accreditation scales in lockstep with deployment.
Security and performance can clash. How do you prove you’re not trading one for the other? Walk through a recent deployment’s threat model, control mappings, latency/SLA targets, and the test results that convinced a skeptical security lead to sign off.
We start with an adversary-centric threat model that enumerates likely attacks on data at rest, in transit, and in use, and we map controls to each pathway with clear ownership. For performance, we define mission-centric targets—how quickly data must be processed and how resilient the system must be under stress—so security controls are tested in context. We ran layered tests: crypto on, telemetry verbose, failovers forced, and edge-to-core sync perturbations, and we compared behavior to baselines. The inflection point came when the security lead saw that full controls didn’t degrade the user experience in the field—alerts were timely, interfaces stayed responsive, and the audit trail was complete without extra clicks.
The Oracle Defense Ecosystem aims to let sovereign innovation scale. What programs, reference architectures, or sandboxes did you use, and what gaps remain? Tell a story of a team that accelerated from concept to ATO, including timelines, blockers, and the workaround that unlocked progress.
We leaned on reference architectures for distributed cloud and identity, plus sandboxes that mirrored sovereign constraints so we could test with realistic guardrails. The programs helped us align with best practices and pre-wired security patterns, reducing the guesswork. One team went from concept to an operational trial and then onward to authorization by building directly on those templates and automating evidence collection alongside CI/CD. The blocker was a cross-domain transfer pattern; the workaround was a staged, policy-aware synchronization that preserved provenance at each hop, unlocking stakeholder confidence.
Andy McCartney talked about aligning scale, operating systems, and sovereign apps. How do you translate that into engineering backlogs? Give us your roadmap themes, quarterly milestones, dependency risks, and one hard lesson that reshaped your prioritization.
We translate that alignment into three themes: scalable data and model platforms, sovereign-by-design controls, and mission-ready experiences at the edge. Quarterly milestones tie to deployable increments—edge inference packages, sovereign data services, and governance automation—so each step is fieldable. Dependency risks cluster around identity federation, data residency rules, and cross-domain policy; we surface those early and treat them as first-class backlog items. The hard lesson was underweighting user experience at the edge; after feedback from operators, we elevated UI performance and offline workflows to the top of the roadmap, and everything downstream benefited.
Where are you seeing the fastest wins—UK, NATO, or specific allied nations—and why? Share concrete use cases, adoption metrics, and procurement timelines. If you had to replicate that success elsewhere, outline the playbook step-by-step, including the first three meetings you’d set up.
Momentum is strong where procurement aligns with sovereign cloud availability and where mission owners can co-design with us early—those ingredients let use cases like edge analytics and sovereign data sharing move quickly. Adoption grows when we show a working slice that respects residency and identity constraints and still delivers timely insight. To replicate success, the playbook is: secure executive sponsorship around a specific mission outcome, stand up a sovereign landing zone with test data, and co-run a pilot in a controlled environment. The first three meetings are with the mission lead to anchor outcomes, the security authority to align controls and evidence, and the data stewardship team to agree on contracts and governance.
Do you have any advice for our readers?
Start with the mission and make sovereignty a design input from day one, not an afterthought. Build with distributed cloud patterns so you can put compute where it makes the most sense—edge for immediacy, core for depth—without rewriting everything later. Automate your governance; the more your controls live in code and telemetry, the faster you can move without losing trust. And listen to operators early and often—their feedback will save you from elegant architectures that stumble the moment boots hit the ground.
