The model is almost never the reason edge AI fails. Delivery, drift, physical access and governance are. Here is what actually breaks between the data science team and the vessel, the rig, the mine site or the remote site — and what has to be true before it stops breaking.

The model works. That is the frustrating part.

It hits 94% on the validation set. It caught the bearing fault three weeks before the vibration alarm did. The pilot ran for two months on one site and the numbers were good enough that someone put a slide in front of the board with a payback period on it.

Then came the instruction to roll it out to 180 sites, and everything stopped.

This is not a rare outcome. Industry research puts the share of AI projects that never reach production somewhere between half and the overwhelming majority, depending on how failure is defined — Gartner has found that roughly half of AI projects make it to production, while RAND‘s analysis puts the overall failure rate above 80%, about twice that of comparable non-AI IT projects. Nearly half of proofs of concept are abandoned before they ever ship.

In remote operations the failure rate is worse, and the reason is specific: the model was the only part of the problem anyone solved.

  • ~48% of AI projects reach production, per Gartner — with RAND putting overall failure above 80%
  • $1,500+ typical cost of a single technician site visit before you add a vessel, a remote site, a helicopter or a weather window
  • 50–60%of the year that North Sea conditions allow safe crew transfer — dropping below 40% in winter

You solved inference. You didn’t solve delivery.

A quantized small language model in the 3-to-9 billion parameter range now fits comfortably on hardware that draws 20 to 35 watts on a DIN rail. Sub-4B models occupy roughly half a gigabyte to three gigabytes at 4-bit quantization; 7-to-9B models land in the 4-to-6 GB range. Current-generation edge silicon sustains real-time token throughput on a 4-bit 8B model inside a 10-watt envelope. The engineering community solved the hard part.

Now multiply. A 4 GB model artefact across 180 sites is 720 GB of transfer for one version. Do that quarterly and it becomes a recurring line item on an airtime connectivity bill. On a maritime plan sold at roughly 1,200 GB of global priority data per month, a single fleet-wide model push can consume half a month of allowance across the estate — before a single operational byte moves.

The teams that get this right never ship whole images. They ship differences, they resume interrupted transfers rather than restarting them, they stage rollouts by ring, and they schedule pushes against the connectivity conditions each site is actually experiencing. None of that is a data science capability. It is a fleet management capability, and most organizations discover they don’t have one at exactly the moment they need it most.

Your model has a shelf life, and nobody costed the refills.

Models degrade. The world moves away from the conditions the model was trained on — new equipment, a different cargo mix, a resurfaced haul road, a sensor replaced with a different make. Practitioners distinguish data drift from concept drift because they demand different responses, but the operational consequence is identical: performance decays quietly while the model keeps returning confident answers.

Which means the deployment problem you just solved is not a project. It is a permanent operating cadence. Detection, triage, retraining, validation, staged release, and rollback when the new version is worse than the old one — repeating for as long as the model is in service.

A model you cannot update from shore is not an asset. It is a depreciating liability with a countdown on it.

Rollback deserves particular attention. In a data center, a bad release is a bad afternoon. At a remote site with no local IT presence, a bad release that cannot be reverted remotely is a broken system until the next site visit or next port call.

The site cannot be visited. This changes the entire design.

Edge platform vendors put the cost of a single service technician dispatch above $1,500 in labor, travel and vehicle time — and note that a thousand sites visited monthly compounds to roughly $18 million a year. That is the benign case. It assumes roads.

Offshore, every intervention requires a mobilized vessel or helicopter, certified technicians, marine crew and a weather clearance that may last only hours. In the North Sea, safe crew transfer conditions occur only 50–60% of the year and fall below 40% in winter as wave heights routinely exceed transfer limits. Offshore vessel downtime itself runs from around $40,000 a day for supply vessels to over $300,000 a day for specialized installation tonnage.

Design consequence: any architecture where a human must be physically present to provision, patch, recover or troubleshoot the AI stack is already broken. The box has to be droppable in a crate, plugged in by whoever happens to be on site, and provisioned entirely from shore with cryptographic proof that it is the box you think it is running the software you think it is running.

The data cannot leave — and this is why edge exists at all

Here is the arithmetic that ends the “just send it to the cloud” conversation. A single 1080p camera recording continuously generates on the order of 30 to 60 GB per day. Motion-triggered capture reduces that to roughly 1 to 5 GB per day.

Monthly data volume — one camera vs. a typical LEO allowance

  • One 1080p camera, continuous (upper estimate) ~1,800 GB
  • One 1080p camera, continuous (lower estimate) ~900 GB
  • Representative LEO priority allowance ~1,200 GB
  • Same camera, inference local, events only ~30–150 GB

Illustrative planning figures, derived from published camera bitrate guidance and published reseller plan data. Actual volumes vary with codec, scene complexity, frame rate and duty cycle.

One camera can consume an entire remote site’s monthly priority data allowance. A typical installation has eight to twenty. The backhaul-everything architecture was never viable at remote sites, and no realistic improvement in satellite economics makes it viable — because the moment bandwidth gets cheaper, someone adds more cameras and higher resolution.

Inference has to happen where the data is born. What crosses the satellite link is the event, the exception, the aggregate and the model update. That is a 10-to-50x reduction, and it is the whole commercial case for edge compute in remote operations.

Your model has to share a box with a 20-year-old SCADA system

Remote sites are not greenfield. The AI workload arrives into an environment already running a Windows-based SCADA package, an HMI, a historian, a video management system and a handful of vendor appliances that nobody is authorized to touch. Several of those will never be containerized, because the vendor no longer exists or the certification would have to be redone.

An edge platform that only runs containers forces a choice between modernizing the AI stack and keeping the plant running. In practice that means a second box, a second management tool, a second patching regime and a second security boundary — which is how a fleet of 180 sites becomes an estate of 360 unmanaged endpoints.

What is required is a bare-metal foundation with a hypervisor underneath, so that legacy virtual machines and modern containers run side by side on the same hardware, under one lifecycle, with one set of policies. Not as a migration step. As the permanent operating model.

An unmanaged AI box is now a class and compliance problem

This is the reason that catches maritime and offshore operators late. IACS Unified Requirements E26 and E27 apply cyber resilience obligations to newly contracted vessels, organized around five functions: identify, protect, detect, respond and recover. E26 addresses the vessel as a whole; E27 addresses individual computer-based systems and the suppliers who provide them.

The “identify” obligation is the one that matters here. It requires a maintained inventory of computer-based systems onboard and their software versions — so that when a vulnerability is published, the operator can determine within reasonable time which vessels and remote sites are exposed and need updating.

 

The awkward question

An AI inference box, installed by a project team, running a model of unknown provenance, patched by whoever remembers, with no central version record — which remote site is it on, what is it running today, and who can prove it?

If that question cannot be answered from headquarters in minutes, the edge AI program has quietly become a class finding waiting to happen.

The counterintuitive part: LEO connectivity doesn’t reduce the need for edge management. It multiplies it.

The reasonable assumption is that as LEO capacity expands and cost per bit falls, and the case for local compute weakens. Everything can just go to the cloud.

The opposite happens, for three reasons.

  • LEO makes the payload deliverable, not the volume unlimited. Low latency and hundreds of megabits make it practical to push a multi-gigabyte model to a remote site for the first time. It does not make continuous raw sensor backhaul economic, because the data volumes at the site grow faster than the link does.
  • Capability arriving everywhere creates a fleet problem where none existed. When only your five best-connected sites could run AI, five boxes were manageable by hand. When every site can, you have 180 — heterogeneous hardware, drifting configurations, inconsistent patch levels, expiring certificates. Scale is the new failure mode.
  • Better links do not mean reliable links. Obstruction, weather, handover, congestion, high-latitude coverage gaps and regulatory market access all persist. The site still has to keep making decisions on its own while disconnected, then reconcile when the link returns. That is an architectural property, not a bandwidth property.

LEO makes the remote site reachable. Edge orchestration makes what sits at the far end of that link governable. Neither is sufficient alone.

The requirement set: What actually has to be true

Before any edge AI program survives contact with a distributed estate, all of the following need to hold. Not most.

  • Zero-touch provisioning. Hardware ships to site, is plugged in by a non-technical person, and self-provisions against a cryptographic identity. No engineer, no USB stick, no local login.
  • VMs and containers under one lifecycle. Legacy OT software and modern AI workloads on the same node, managed identically.
  • Bandwidth-aware software distribution. Differential updates, resumable transfers, ring-based rollout, scheduling that respects each site’s real conditions and data plan.
  • Remote rollback that works from shore. Every deployment reversible without a site visit, including OS-level recovery.
  • Local autonomy when disconnected. The site keeps inferring and acting, buffers what it cannot send, and reconciles on reconnection.
  • Hardware-rooted trust. Measured boot and a hardware root of trust, so a node that cannot prove its software state does not release keys or run workloads — on equipment that is physically accessible to strangers.
  • Fleet-wide version and configuration visibility. One authoritative answer to what is running where, on demand, for operations and for class.
  • Multi-path connectivity underneath all of it. LEO primary, GEO, cellular and terrestrial in combination, with intelligent path selection — because the management plane is worthless if it loses the site.

Where SIGMA fits: Connectivity and orchestration as one system

Speedcast built SIGMA for exactly this gap. Not as an AI product — as the operational substrate that lets an AI program reach a distributed estate and survive there.

What breaks What SIGMA does about it
Provisioning needs a skilled engineer on site Cloud-native orchestration with policy-driven configuration across the device lifecycle, designed for automated rollout to tens of thousands of edge devices
Legacy OT can’t be containerized Virtual machines and containerized software are both treated as applications, with identical management and lifecycle capabilities on the same node
Model and software updates too large or too fragile for the link API-based control to push updates and deploy applications remotely, plus an application marketplace for repeatable deployment across sites
Physically exposed hardware, no local IT Hardware-based TPM and measured boot — the system halts until state is verified — with zero-trust role-based access, data encryption and disabling of unused physical ports
Class and cyber obligations on onboard systems A building block for addressing IACS E26 and E27, including the system inventory and version visibility the “identify” function requires
The link itself is variable Multipath architecture across Starlink, OneWeb, other emerging constellations like Amazon Leo and traditional services, with patented SIGMA Blended AI selecting the best path against real-time conditions

The combination matters more than either half. As a tier-one Starlink reseller and Eutelsat OneWeb distribution partner, Speedcast can size the link and the compute against the same workload — and then operate both as one managed service, from one portal, with one accountable party when something at a remote site stops working.

What none of this fixes

Orchestration solves distribution, governance and access. It does not solve the things that kill the majority of AI pilots, and it would be dishonest to imply otherwise.

  • Data quality. Mislabeled sensors, inconsistent tag naming and gaps in historian data will defeat a well-orchestrated model exactly as thoroughly as a badly orchestrated one.
  • Use case economics. Some edge AI use cases do not pay for themselves yet. Crew-facing generative assistants are frequently in this category; vibration-based drivetrain monitoring, where condition-based strategies have been shown to cut unplanned downtime by 30–50% and O&M cost by 20–30% with payback in two to four years, usually is not.
  • Ownership. Research on pilot failure points consistently at organizational and governance gaps rather than technical limits. If no one owns the model’s performance after go-live, it will decay regardless of the platform underneath it.
  • Model accuracy. Platforms deploy models. They do not improve them.

What orchestration does is remove the failure modes that are purely infrastructural — so that when a use case fails, it fails for a reason worth learning from, rather than because a technician could not get to a rig in November.

Where to start: Four steps that don’t require a platform decision

  1. Cost your update path before you cost your model. Take the artefact size, multiply by site count and expected annual release cadence, and price it against each site’s actual data plan. If that number surprises you, the architecture is not ready.
  2. Count the site visits your design assumes. Walk the deployment, patch and failure-recovery paths and mark every step needing a human on site. Multiply by a realistic access cost for your worst location, not your best.
  3. Answer the class question now. Can you produce, from shore, the current software inventory and version state of every compute node across the fleet? If not, fix that before adding AI workloads to it.
  4. Pick the use case with the shortest path to a hard number. Condition monitoring on rotating equipment and vision-based safety compliance tend to produce defensible figures fastest. Save the ambitious work for after something is genuinely in production.

The perfect model was never the achievement. Getting it onto 180 sites, keeping it current, proving what is running where, and doing all of it without sending anyone offshore in a winter storm or thousands of kilometers away to a remote site — that is the achievement.

Ready to make the edge governable?

Contact Speedcast today.