The defense community already has a vocabulary for places where the network doesn't always work. DDIL stands for disconnected, denied, intermittent, and limited. Nobody's going to call it a glamorous acronym. What it describes is the daily operating reality for soldiers in the field, sailors at sea, and anybody whose job runs on technology somewhere the public internet doesn't reliably reach.
Here's what I want to suggest. The DDIL vocabulary applies a lot more broadly than the defense community has used it. There's a large commercial population, growing every year, whose AI deployments hit the exact same constraints. The label is missing from the commercial conversation, and so are the patterns, even though those operators keep rediscovering them on their own.
Naming the category would help. The architectures that work in defense DDIL environments are the same ones that will work for offshore platforms, container ships, rural clinics, mining sites, disaster zones, and remote energy infrastructure. The operators in those environments are buying more AI capability every year, and they keep finding that the cloud assumption baked into most AI offerings doesn't survive contact with how they actually operate.
So let me write down what this reframing looks like, why it matters now instead of in five years, and what changes in the architecture once you stop assuming bandwidth.
Where DDIL applies in commercial contexts
The picture in the defense community is a forward operating base in contested territory. Swap that for any of the following and the constraints rhyme.
An offshore oil platform in the North Sea runs on a satellite uplink with high latency, weather-driven outages that come and go, and a cost per byte steep enough to make streaming inference a non-starter. The platform's engineers want AI for predictive maintenance. A cloud first architecture dies on either the latency or the bill.
A container ship somewhere between Shanghai and Long Beach has VSAT connectivity that's expensive, often degraded by weather, and effectively gone on some legs of the route. The shipping company wants AI for cargo tracking and route optimization. The cloud architecture isn't viable.
A rural healthcare clinic in a county with thin fiber gets DSL that changes speed by the hour. The clinic wants AI assisted triage. The cloud architecture adds enough latency to break the workflow.
A disaster response site in the first 72 hours after a natural event has whatever cellular coverage survived, which is rarely much. The coordinator wants AI for damage assessment off drone imagery. The cloud architecture can't function in the exact window when the work matters most.
A remote pumping station on a pipeline shares one 4G modem with its telemetry traffic. The operator wants AI for anomaly detection on the local sensor stream. The cloud architecture either eats all the bandwidth or sends nothing at all.
None of these five is exotic. Together they cover a big slice of operational AI use cases that get attempted and then quietly abandoned because the architecture never matched the environment.
The architectural shift
Moving from cloud first to DDIL aware AI isn't a watered-down version of cloud architecture. It's a different architecture with different organizing principles. Three of them carry most of the weight.
Principle one. The model lives where the work is. Inference runs on the local hardware. The cloud is, at most, a place to sync the occasional update. The model gets sized to fit the local accelerator, and the accelerator gets sized to fit an operating environment that usually comes with tight power and thermal limits. The model ends up small enough to be genuinely useful on hardware the operator can actually field.
Principle two. The data plane assumes the link is gone. Every operation the system has to perform has to work with zero connectivity. Diagnostic telemetry queues locally. Audit logs pile up locally. Retraining data piles up locally too. When the link comes back, the accumulated data flushes upstream and updates flow back down. When the link is gone, the system keeps running at full capability and doesn't blink.
Principle three. The control plane is local first. The operator on site can configure it, override it, or shut it down cold without phoning anyone. A cloud based control plane that demands a call home before it'll accept a configuration change isn't DDIL compatible. The control plane has to sit on the same side of the network boundary as the operator.
Put those three together and you get an architecture that looks foreign to engineers raised on cloud native patterns. For any deployment where you can't assume the network, they're the right principles.
The sectors that will move first
A few sectors are already moving this way faster than the trade press has noticed, and I think they'll produce the first real commercial DDIL AI vendors.
Maritime. Container shipping, offshore energy, fishing fleet operations. These operators have been buying ruggedized compute for two decades. They get the constraint in their bones. The new wave of AI capability slots cleanly into operational discipline they already have.
Mining and extraction. The operations are remote by definition and the connectivity is hostile by definition. The economic value of AI assisted operations runs high. The procurement officers in this sector are practical, and they'll pay for capability that actually works where they work.
Disaster response and humanitarian operations. The operating environment is unpredictable and rarely has reliable connectivity, the work is high stakes, and the funding sources keep demanding AI capability. The vendors who serve this sector will produce reference architectures the broader commercial DDIL category ends up adopting.
Those are the leading edge. The rest of the commercial DDIL space follows them in the back half of the decade.
What to build
If you're a vendor weighing whether to invest in DDIL aware AI, here's the shape of the build.
A small model. 9 billion parameters or fewer, fine tuned on the relevant domain corpus, optimized for local inference on hardware that fits the operating environment.
A scaffolding layer. Memory, a critic, a post mortem step, a rule library, all the pieces that turn a small model into a working agent. This is the same scaffolding I've argued for elsewhere. In the DDIL case it's non negotiable, because the usual escape hatch of swapping in a bigger model simply isn't on the table.
A local control plane. Configuration and authentication, monitoring, plus the operator interfaces, all running with no cloud dependency. The cloud can be a destination for synchronized data. It can't be a runtime dependency.
A synchronization protocol. Bidirectional and resumable, with explicit handling for network partitions of any duration. It has to be tested against simulated multi week partitions, not just tidy little disconnects.
A deployment package that fits the environment. Power budget, thermal envelope, physical form factor, all of it has to match the operator's reality. Build great software inside a box that doesn't fit the available rack space and you've built the wrong product.
Those five components are the build. None of them is exotic on its own. The integration is the hard part, and the discipline of designing against the constraint from day one is what produces deployments that actually work.
A closing observation
DDIL isn't a niche. It's a substantial slice of commercial AI demand, underserved right now because the vendor ecosystem got optimized for cloud first deployments where bandwidth and connectivity were a given.
The reframing matters because naming the category speeds up the procurement conversation. An offshore platform operator, a fleet manager, a rural healthcare administrator, any of them should be able to walk into a vendor meeting, ask about DDIL compatibility, and have the vendor know what that means and answer it.
The defense community has the vocabulary because it hit the constraint first. The commercial operators are catching up. The vendors who see this coming and ship products that match the operational reality will win the next wave of edge AI deployments. The ones who keep assuming the cloud is reachable will hand those deals to whoever actually shipped for the environment.
The cloud is one operating environment among several, and it isn't the default. Building that recognition into the architecture from the start is what separates a product that ships from a product that only demos.