Halo Cloud is Dronehub's in-house AI anomaly-detection platform — built end-to-end, owned end-to-end, deployed end-to-end on sovereign infrastructure. That ownership architecture is the load-bearing element behind the platform's procurement-grade properties: sub-licensable capability, operator-accruing improvements, EU+US data sovereignty by design, and the 95%+ accuracy at Deutsche Bahn national scale that established the platform as the reference for AI rail inspection in NATO Europe. This post is the architecture deep-dive.
If you're evaluating the platform for licensing, building a partnership around a new asset class, or just trying to understand how AI inspection at national-infrastructure scale actually works behind the marketing surface — this is the technical-and-commercial briefing.
The ownership argument
Most AI inspection platforms in the drone industry are integrations of third-party vision AI. The drone captures imagery, the operator-facing software uploads to a hyperscaler vision API, the API returns classifications, the operator-facing software wraps the classifications into a report. The architecture is simple to build and adequate for low-stakes commercial use cases.
It's structurally wrong for the use cases that matter at procurement scale, for three reasons.
Sub-licensing. Operators in the licensing-pool — utilities, rail operators, defense integrators, port authorities — want to license the inspection capability to their own downstream customers. A utility running grid inspection wants to license the capability to municipal grid operators in its region. A defense integrator wants to sub-license to allied ministries of defense. A rail operator wants to support neighbouring rail networks. A third-party SaaS subscription cannot be sub-licensed — the SaaS vendor's terms expressly prohibit it. Halo Cloud is Dronehub-owned IP, and the licence terms support sub-licensing as part of the operator's capability deployment.
Model improvement accrual. When an AI model trains against operator-specific data, the improvements accrue to whoever owns the model. With a third-party AI, the improvements accrue to the third party. The operator's data has trained the third party's product, with no durable benefit to the operator or to Dronehub. With Halo Cloud, the per-asset taxonomy improves with operator data, and the improvements stay inside the IP that's licensed to the operator. The operator gets a model that keeps getting better against their specific asset class; Dronehub gets a model that keeps getting better as a licensable capability.
Data sovereignty. Third-party AI inference typically routes data through the third party's cloud — frequently hyperscaler regions in jurisdictions that don't align with the operator's sovereign data-path requirements. EU NIS2 requires critical-infrastructure operators to keep operational data on sovereign infrastructure. US CISA critical-infrastructure frameworks impose equivalent rules. Defense procurement adds tighter restrictions. A third-party AI that routes inference through non-sovereign jurisdictions is disqualifying for most of the procurement surface that actually pays. Halo Cloud runs entirely on EU and US sovereign infrastructure by architecture.
The combined effect of these three: the platforms that built on top of third-party vision AI sit in the consumer-and-commercial category. The platforms that own the AI sit in the federal-civil, defense, and regulated critical-infrastructure category. The procurement frame collapses to the second category for buyers with meaningful regulatory exposure, which is most of the market that actually buys this kind of capability.
The three-layer architecture
Halo Cloud's deployment architecture splits the inference workload across three layers. Each layer has a specific responsibility, and the split is what makes the system operationally viable at national scale.
Layer one: edge classification
The Nvidia Jetson on-board the drone runs a lighter-weight version of the per-asset detector in real time during flight. Every captured frame is classified — the edge layer's job is to decide whether a frame contains a potential anomaly or whether it's routine.
The output is binary at the per-frame level: candidate or not. Most frames — the no-anomaly-detected routine ones — never travel further. The candidate frames travel to the cloud for deeper review.
The bandwidth economics are the structural advantage. A drone captures imagery continuously during inspection; the raw video stream is gigabytes per hour. Streaming gigabytes per hour to a cloud-side classifier requires continuous high-bandwidth uplink, which is operationally available only in a narrow subset of deployment environments. Rail corridors pass through cellular dead zones. Pipelines run through worse environments. Transmission corridors traverse mountain ranges. Offshore wind sites operate beyond reliable cellular range. Defense-grade deployments operate under deliberate RF denial.
Edge-first inverts the assumption. The drone's onboard compute runs the first-pass classifier locally. Bandwidth-thin operation becomes the default rather than a fallback. The cloud connection only needs to handle the candidate frames — kilobytes per minute, not gigabytes — which works over LTE, satellite, or degraded RF in the operationally-available bandwidth.
The Jetson hardware itself is operationally robust. Industrial-grade Jetson modules survive the temperature ranges, vibration profiles, and electromagnetic environments of the deployment sites. The same compute platform runs across the Dronehub product family — rail inspection, wind inspection, drone-in-a-box, mobile-dock — which simplifies the supply chain and the maintenance pipeline.
Layer two: cloud-side deep analysis
The cloud-side layer runs per-asset specialised detectors against the candidate frames flagged by the edge. The specialisation is the property that produces the high accuracy at scale.
A single generic detector trained on all asset classes simultaneously underperforms a federation of per-asset specialised detectors by a meaningful margin. The generic detector has to learn to discriminate across distributions that don't generalise well — rail fasteners look nothing like wind-blade defects, which look nothing like pipeline welds, which look nothing like port quay walls. Forcing all of these into one model produces a detector that's mediocre at all of them.
The federation approach trains:
- A rail-fastener detector against labelled rail-fastener imagery
- A wind-blade detector against labelled wind-blade imagery
- A pipeline-weld detector against labelled pipeline imagery
- A port-quay-wall detector against labelled port-infrastructure imagery
- A transmission-tower-corrosion detector against labelled transmission imagery
Each detector is a separate model, trained on a narrower distribution, with a more disciplined per-asset taxonomy. The combined accuracy across the asset classes is substantially higher than the generic model would deliver.
The cloud orchestration routes each candidate frame to the appropriate per-asset detector based on the deployment context — the operator knows which asset class they're inspecting, and the routing is explicit rather than inferred from the imagery alone. This is computationally cheaper, structurally cleaner, and operationally easier to debug than imagery-based routing would be.
Layer three: operator handoff
The third layer is the integration with the operator's existing maintenance-planning infrastructure. This is the layer most AI inspection platforms underinvest in, and it's the layer that determines whether the technical capability becomes operationally usable.
Maintenance planners don't want raw classifications. They want prioritised lists of defects with severity scores, GPS coordinates, asset identifiers, historical comparison against the last inspection of the same asset, and recommended action classes. The planner's existing workflow already has those fields — in spreadsheets, in CMMS systems (Maximo, SAP PM, IBM Asset Management, custom platforms), in regulatory-compliance trackers.
The integration layer ships Halo Cloud's output into the operator's existing workflow rather than asking the operator to consume the output from a new vendor-specific console. The format adaptation, the field-mapping, the alert-priority routing, the historical-comparison data attachment — all of this is handled in the integration layer. The planner's experience of the platform is "the inspection reports show up where I expect them, faster and more accurately than before."
This integration layer is what we underestimated when the platform was first deployed at Deutsche Bahn. We corrected on it during the rollout, and it has since been the layer we replicate first on every new operator engagement. The technical inspection capability matters; the operator-handoff layer is what makes it operationally usable.
Data sovereignty in detail
Sovereignty is enforced by architecture rather than by configuration setting.
The edge inference happens on the drone. The drone's onboard compute runs the first-pass classifier locally and emits no telemetry to non-sovereign endpoints during routine flight. The telemetry that does leave the drone — the candidate-frame uploads — goes to sovereign cloud infrastructure.
The cloud-side processing runs on infrastructure inside EU and US jurisdictions only. The specific deployment regions vary by operator deployment (an EU rail operator's data stays in EU regions; a US federal-civil deployment stays in US regions). No inference, storage, or audit logging passes through hyperscaler regions in adversarial jurisdictions. Cross-region data movement happens only inside the sovereign envelope.
The operator's data path is auditable end-to-end. The audit trail covers ingest, inference routing, model versions used, detection events, operator review decisions, and downstream actions. The audit data lives inside the sovereign envelope with the same residency properties as the operational data.
EU NIS2 compliance, US CISA critical-infrastructure framework alignment, and defense-grade data-protection requirements all map to the architecture without configuration changes. For operators that also handle classified or export-controlled data, additional segmentation can be applied within the sovereign envelope — air-gapped deployment regions, dedicated tenant clusters, customer-managed encryption keys.
Deploying a new asset class
The pattern for bringing a new asset class onto the platform follows three phases.
Phase one — taxonomy definition. Dronehub works with the operator to define the per-asset defect taxonomy. The taxonomy is the input to model training and the output to maintenance-planning workflows; it has to align with the operator's existing inspection categories, the regulator's reporting requirements, and the asset class's physical defect modes. Typical engagement: 2-6 weeks of joint sessions with operator's senior inspection staff and Dronehub's AI team.
Phase two — initial training. Using labelled data from the operator's existing inspection archive — typically photographs from manual inspection rounds with inspector annotations — plus synthetic supplementation for rare defect classes. The synthetic data uses physics-based defect simulation augmented onto base imagery, which closes the gap on operationally critical but statistically rare defect categories. The initial model trains in days to weeks depending on archive size; deployment-ready accuracy is typically reached after the first training cycle but improves significantly during phase three.
Phase three — on-deployment retraining. As the deployment runs, the model gathers new labels from three sources: operator feedback on detections (false positives confirmed by ground-truth inspection, missed defects identified during scheduled maintenance), ambiguous cases resolved by senior inspectors (which become high-value training examples for the model's hard categories), and structured retraining cycles that incorporate the new data into the next model version. Improvements deploy back to the edge and the cloud on a release cadence appropriate to the operator's change-management process.
The accuracy ceiling moves up over the first 6-18 months of deployment as the training data deepens. The initial deployment is operationally useful; the deployment at month 12 is meaningfully better; the deployment at month 24 approaches the per-asset accuracy ceiling that's been validated at the Deutsche Bahn-class deployments.
Where Halo Cloud deploys today
Rail inspection. Deutsche Bahn at national scale — 33,000 km network, 95%+ per-fastener accuracy, sub-15-minute report latency. The reference deployment for the platform.
Wind inspection. Offshore and onshore wind farms — per-blade defect detection across utility-scale operators. The platform deploys on the turbine-mounted dock or on the operator's existing inspection drones depending on the deployment architecture.
Pipeline integrity. Linear-infrastructure inspection along pipeline corridors — coating-condition assessment, weld integrity, support-bracket inspection.
Port infrastructure. Quay wall condition, container-handling-equipment inspection, perimeter overwatch.
Energy grid. Transmission tower condition, substation asset-condition monitoring, conductor-defect detection.
Critical infrastructure perimeter. Critical-asset surveillance pattern detection for security and operational anomalies.
For the rail inspection deep-dive, see /blog/ai-rail-inspection-national-scale-deutsche-bahn. The Deutsche Bahn case study is at /projects/deutsche-bahn. The wind-farm inspection narrative is at /blog/do-drone-less-wind-farms-stay-behind-yes-they-do. The drone-in-a-box product page is at /drone-in-a-box. The rail-industry context is at /industries/rail; energy at /industries/energy. For a deployment conversation, open the contact form.
Key facts
Halo Cloud is Dronehub's in-house AI anomaly-detection platform — built end-to-end rather than licensed from third parties. The base classifier, the per-asset taxonomy detectors, the cloud orchestration, and the operator-handoff layer are all Dronehub-owned IP.
Source · Halo Cloud platform architecture documentation
Edge first-pass classification runs on Nvidia Jetson compute on-board the drone — most frames never travel to the cloud. Only frames carrying potential anomalies are uploaded for deeper review.
Source · Halo Cloud edge architecture specifications
Cloud-side processing runs per-asset specialised detectors — rail-fastener classifier, wind-blade defect classifier, pipeline-weld classifier, port-quay-wall classifier, transmission-tower-corrosion classifier — each trained on labelled data from operator deployments.
Source · Halo Cloud per-asset taxonomy architecture
Halo Cloud operates at 95%+ per-fastener defect detection accuracy at Deutsche Bahn national scale (33,000 km network), with sub-15-minute report latency from drone landing to maintenance-planner dispatch.
Source · Dronehub × Deutsche Bahn deployment validation metrics
EU and US data sovereignty is enforced by architecture — imagery, telemetry, build records, detection logs, and audit traces remain on infrastructure inside EU and US jurisdictions, satisfying EU NIS2 and US CISA critical-infrastructure frameworks by design.
Source · EU NIS2 Directive; US CISA critical-infrastructure framework; Halo Cloud deployment topology
The bandwidth-thin operation enabled by edge-first architecture works over LTE, satellite, or degraded RF — critical for linear-infrastructure deployments (rail corridors, pipelines, transmission lines, offshore wind clusters) where continuous high-bandwidth uplink is not available.
Source · Halo Cloud operational deployment patterns
FAQ
- Why build in-house instead of licensing third-party AI?
- Three structural reasons. First, sub-licensing — operators who want to license the inspection capability to their downstream customers (utilities reselling to municipal grids, defense integrators reselling to allied MoDs) cannot sub-license a third-party SaaS subscription. Halo Cloud is Dronehub-owned IP, sub-licensable as part of a capability licence. Second, model accrual — when the AI improves against operator-specific data, the improvement accrues to the IP owner. With a third-party model the improvement accrues to the third party, not to Dronehub and not to the operator. Third, data sovereignty — third-party AI typically routes inference through the third party's cloud, which means operator data leaves the operator's data path. For regulated, defense-grade, or critical-infrastructure operators that's disqualifying. Halo Cloud runs entirely on sovereign infrastructure.
- What's the technical architecture?
- Three layers. (1) Edge classifier on Nvidia Jetson on-board the drone — runs a lighter-weight version of the per-asset detector in real time during flight, classifying every captured frame. Most frames — the no-anomaly-detected routine frames — never travel further. (2) Cloud-side deep-analysis layer — runs the heavier, more accurate per-asset detectors against the candidate frames flagged by the edge. The cloud layer's per-asset specialisation is what produces the high accuracy at scale. (3) Operator-handoff layer — annotated, severity-scored, GPS-pinned detections route into the operator's existing maintenance-planning stack via the integrations the operator already uses (CMMS systems, asset-management workflows, regulatory-compliance trackers).
- How does the per-asset taxonomy actually work?
- Instead of training one generic detector on all asset classes, Halo Cloud trains a federation of per-asset specialised detectors. The rail-fastener classifier is trained on labelled rail-fastener imagery (loose bolts, missing fasteners, plate damage, weld condition). The wind-blade classifier is trained on labelled wind-blade imagery (leading-edge erosion, surface cracks, delamination markers, bonding-line condition). The pipeline-weld classifier is trained on labelled pipeline imagery (weld defects, coating condition, support-bracket integrity). The cloud orchestration routes each candidate frame to the appropriate per-asset detector based on the deployment context (the operator knows what asset they're inspecting; the classifier doesn't have to figure it out from the imagery alone). The combined accuracy at scale is significantly higher than a single unified detector trained on all asset classes simultaneously.
- What about data sovereignty?
- Enforced by architecture rather than by configuration. The edge inference happens on the drone — no telemetry leaves the device during routine flight. The cloud-side processing runs on infrastructure inside EU and US jurisdictions only — no inference, storage, or audit logging passes through hyperscaler regions in adversarial jurisdictions. The operator's data path is auditable end-to-end. EU NIS2 compliance, US CISA critical-infrastructure framework alignment, and defense-grade data-protection requirements all map to the architecture without configuration changes. For operators that also handle classified or export-controlled data, additional segmentation can be applied within the sovereign envelope.
- How does Halo Cloud compare to general-purpose vision AI services?
- Different optimisation point. General-purpose vision AI services (the major hyperscaler offerings, the API-based vision platforms) are optimised for broad applicability across many use cases at acceptable accuracy. They don't specialise on inspection workflows specifically; they don't expose the per-asset taxonomy that the inspection domain needs; they don't run on sovereign infrastructure for the critical-infrastructure use case; they don't integrate into the operator's CMMS / maintenance-planning workflow. The general-purpose services have their place — image search, content moderation, accessibility, generic object detection. They are not the right tool for per-fastener defect detection at national rail scale, per-blade wind-turbine inspection, or pipeline-integrity monitoring.
- What's the deployment pattern for a new asset class?
- Three phases. (1) Taxonomy definition — Dronehub works with the operator to define the per-asset defect taxonomy based on the operator's existing inspection categories and the regulator's reporting requirements. The taxonomy is the input to model training. (2) Initial training — using labelled data from the operator's existing inspection archive (typically: photographs from manual inspection rounds with inspector annotations) plus synthetic supplementation for rare defect classes. The initial model trains in days to weeks depending on archive size. (3) On-deployment retraining — as the deployment runs, the model gathers new labels (operator feedback on detections, missed defects identified by ground-truth inspection, ambiguous cases resolved by senior inspectors). The model retrains continuously, with improvements deployed back to the edge and the cloud on a release cadence. The accuracy ceiling moves up over the first 6-18 months of deployment as the training data deepens.
