Pre-Launch vs. Launch Phase Coverage Boundaries
Autonomous hardware faces a coverage gap between pre-launch and field operations.
The most dangerous moment for a company building autonomous hardware is the stretch just before a robot operates without supervision, when the pre-launch insurance stack has already stopped matching the risk and the launch-phase policy hasn't been signed yet. Insurance, as an industry, was built around a simple picture: a person acts, a machine follows orders, and loss happens in predictable, repeatable ways. Physical AI systems break that picture because they use sensors, software, and models to decide how to act as conditions change, and traditional liability frameworks were never designed to price that flexibility. A standard business policy can simply fail to respond to a loss, either because it carries an AI exclusion or because the event doesn't fit the policy's definition of an "accident. And when something does go wrong, the fault rarely sits with one party: the hardware maker, the AI model supplier, and the company operating the machine in the field usually all carry some exposure, and the contracts that attempt to divide responsibility among them on paper rarely settle the dispute that follows a real incident.
What "pre-launch" means in coverage terms
Pre-launch coverage is a stack, not a single policy, and each line in that stack was underwritten around a specific picture of a company whose hardware has not yet left controlled conditions. Inland marine and equipment coverage is the one hardware companies lean on hardest before launch: it covers robots and rigs in transit and on-site, which matters enormously for a pre-revenue company whose single most valuable asset is often a handful of prototype units that a standard property policy won't follow once they leave the building. That coverage is priced on one working assumption: the hardware moves between known, controlled locations, under the company's own supervision, the whole time. Tech E&O, in its pre-launch form, covers professional errors in software and system design, but the forms carriers use for it were written for an earlier software era, one where human error drove most claims and a failure usually meant a system crash or a coding mistake someone could trace. Many of the off-the-shelf E&O policies sold through general platforms carry that same legacy design: they lack the flexibility a tech or AI company needs and often can't keep pace as a startup ships new features or retrains its models. D&O enters the picture earlier than either of these, usually at the close of a venture funding round, since incoming board members typically won't join without coverage already in place. That makes D&O one of the first lines a hardware startup binds, often well before any unit reaches the field. CGL rounds out the pre-launch stack, and it generally covers premises liability and narrow operational exposures that haven't yet been tested against anything resembling autonomous behavior in public or industrial spaces.
How each coverage line fractures when field operations begin
Every line in that pre-launch stack rests on an assumption about human oversight, a controlled environment, or a bounded failure mode, and field deployment knocks out all three at once. CGL and products liability coverage illustrate the problem cleanly. Product liability may respond to bodily injury or property damage, but only in jurisdictions willing to treat AI software as a product in the first place, and even where it does respond, financial losses from the same failure (production losses when a robot shutdown halts a line, for instance) typically get no coverage. Carriers have also started closing the door formally: effective January 1, 2026, Verisk's ISO division released three new generative AI exclusion endorsements for commercial general liability policies, CG 40 47, CG 40 48, and CG 35 08, formalizing an industry-wide retreat from AI-related CGL claims. A flaw in one widely deployed AI model can propagate instantly across every business running it, in every industry and country simultaneously, producing an accumulation problem unique to software-driven hardware, a kind of risk that has no geographic ceiling the way a hurricane or a factory fire does.
Tech E&O fractures in a related but distinct way. Autonomous agents making decisions that produce financial loss, paired with self-learning algorithms that change their own behavior over time, push well past what legacy "failure of technology to perform" language was built to address. Grey-zone exposures such as algorithmic bias, data poisoning, and AI-driven discrimination tend to fall between cyber exclusions and professional liability triggers, so neither one covers them cleanly. By the time a claim involving one of these exposures reaches a courtroom, the underlying model has usually iterated several versions past whatever the policy was written to describe.
Cyber coverage carries its own version of the same problem. An insurer can deny an AI-related breach claim outright when a company attested to a specific control on its application but post-breach forensics show that control wasn't actually maintained; this already happened industry-wide with multi-factor authentication, and carriers are starting to check AI governance controls the same way after a loss. Physical damage caused by a cyberattack that hijacks a robot's controls is a launch-phase exposure that standard cyber policies were never written to anticipate.
D&O exclusion language, not gaps in scope, is where D&O coverage fractures. Carriers including Berkley have begun attaching "absolute AI exclusions" to D&O, E&O, and fiduciary liability policies, removing coverage for "any actual or alleged use, deployment, or development of AI by any person or entity connected to the insured." That language is broad enough to swallow most AI-related D&O claims the moment field deployment is underway.
Inland marine and equipment coverage fractures last but perhaps most completely. Once hardware is operating autonomously in the field, interacting with members of the public, working across sites the carrier never assessed, and running software versions that postdate the policy entirely, the controlled-environment assumption that priced the coverage in the first place no longer describes reality. These fractures commonly occur in clusters across several coverage lines at once. A single autonomous field incident can cross several of these lines simultaneously, triggering a CGL denial, a Tech E&O dispute, and a cyber coverage question out of one event.
What purpose-built launch coverage covers that standard policies miss
Purpose-built launch coverage is a deliberately structured program built around the specific ways autonomous hardware fails in the field: bodily injury and property damage from AI navigation or perception errors, physical damage from a cyberattack that takes over a robot's controls, and production losses from a software update or sensor failure that takes a unit offline even when nothing is physically broken. Axis Insurance built a program specifically for companies that make and deploy autonomous robots, covering bodily injury and property damage arising from AI navigation or perception failures, physical damage caused by a cyberattack that seizes control of a robot, production losses tied to a software update or sensor failure that sidelines a unit without any physical damage occurring, and cases where a defect in a third-party sensor or component triggers a failure but the resulting claim lands on the company that integrated the part.
The autonomous vehicle sector shows what purpose-built structuring can look like at scale. In March 2026, Marsh Risk and Apollo's ibott launched the Autonomous Vehicle Insurance Program for autonomous vehicles operating on Uber's global platform, so Uber can offer its self-driving partners primary and excess liability coverage at preferred rates that reflect their safety performance. The program wraps developers, fleet operators, vehicle manufacturers and owners, and original equipment manufacturers into a single master policy built to eliminate overlapping gaps between them, and it prices exposure using metrics like per-mile, per-delivery, or per-trip rates rather than the conventional motor insurance models built for human drivers.
Neither of these programs solves the liability chain completely. Specialist coverage narrows that multi-party exposure but doesn't eliminate it, which is the honest boundary of what even the best launch-phase coverage can do on its own.
Why the transition window is the operational risk
The more common failure is entering field operations while the switch from pre-launch to launch coverage is still in progress, a window where the old coverage has already started to fail and the new coverage hasn't bound yet. Enterprise and government customers tend to compress that window under real deadline pressure. At the close of an enterprise pilot, the customer's legal team commonly demands a certificate of insurance showing Tech E&O and Cyber coverage at specific limits before anyone countersigns, and if underwriting takes several weeks, it can stall the entire pilot launch. That leaves a company with two bad options: start field operations without adequate coverage, or lose the contract waiting for the paperwork.
The law hasn't caught up to the deployment either. Liability attribution for autonomous systems acting in shared public and residential spaces remains unsettled at the level of doctrine, and deployment ambition has moved faster than the accountability frameworks meant to govern it. So if a company operates during the transition window, it's exposed to disputes that neither its expiring pre-launch coverage nor its not-yet-bound launch coverage was ever written to resolve.
What the underwriting submission must prove to bind launch-phase coverage
Binding launch-phase coverage without delay now depends on the quality of the underwriting submission itself, and for autonomous systems, that submission has to prove technical architecture, not just revenue and headcount. A thin or generic submission tends to draw either an outright decline or a quote loaded with exclusions, because the carrier can't price what it can't see. Policyholders need to show continuous telemetry tracking and automated intervention mechanisms, because after a cyber-physical incident, the burden of proof rests on audit logs. Underwriters also want proof of deterministic safeguards that stop runaway execution cycles; without those architectural proofs built into the system design, risk teams run into coverage denials or premiums priced as a penalty.
For cyber coverage specifically, underwriters now routinely ask for a complete inventory of the AI tools in use, data-handling and redaction controls, red-teaming results for high-stakes models, written contracts with AI vendors, and audit logging, and alignment with the NIST AI Risk Management Framework or a comparable international standard is increasingly treated as table stakes. The distinction between automated and autonomous systems matters here too: an organization deploying tools that are actually automated but calling them autonomous risks cutting human oversight exactly where it's needed most, and a submission that can't say clearly where a system sits on that spectrum tends to get priced as though it sits at the riskiest end regardless of the truth. Better submission data shortens the time to quote and lets carriers make standardized decisions instead of manual ones, which means the quality of the submission is what actually compresses the transition window.
That complexity is why specialist brokers who focus on autonomous hardware place submissions with carriers that have explicitly agreed to cover it, instead of routing startups through generic forms built for conventional business risk. Risklytics, a licensed commercial insurance brokerage built specifically for companies deploying autonomous systems and frontier hardware, drafts submissions from first principles around the actual technology and operational model, so carriers understand what they're underwriting before a loss occurs. A company describes what it builds in plain English, or just shares its URL, and Risklytics drafts the full application from public information; then a licensed broker brings it to carriers who explicitly cover autonomy and who read the policies themselves instead of slotting autonomous hardware into forms meant for conventional businesses. If a company builds this kind of submission before the transition window opens, it can bind launch coverage ahead of need, and that shrinks the danger zone down to almost nothing.
A practical checklist for managing the pre-launch to launch coverage transition
Managing this transition well starts with treating it as a scheduled operational milestone with a date on the calendar, not a paperwork task that gets handled after field operations have already started. A company should map its pre-launch coverage stack against the specific date field deployment begins, line by line, so it knows in advance exactly which assumption, controlled locations, bounded software errors, limited operations, breaks first, before a loss occurs. It should start the underwriting submission for launch-phase coverage well before that date, building in the technical detail carriers now expect: telemetry and intervention mechanisms, deterministic safeguards against runaway execution, an inventory of AI tools and vendor contracts, and a clear account of where the system sits between automated and autonomous. Enterprise and government customers should be told early, not at contract close, that Tech E&O and Cyber certificates at specific limits take real underwriting time, so that a multi-week process doesn't collide with a pilot's go-live date. The assumptions buried in each pre-launch line, that hardware moves between known locations under supervision, that professional errors are mostly coding mistakes, that operations stay bounded, are rarely spelled out anywhere but the policy language itself, so reviewing the actual forms and endorsements before binding lets a licensed broker catch where a standard form omits the rider language or exclusion detail that changes how a line responds once field deployment begins. The transition happens on a specific operational date rather than gradually, so the timing of when launch-phase coverage binds relative to when the first autonomous system enters the field decides whether a loss during those hours is defensible or denied. Closing that gap is a matter of days, not weeks, and specialist brokers who understand the mechanics of that boundary are equipped to close it. Knowing exactly where the pre-launch boundary ends and the launch boundary begins is, in the end, the specific piece of operational knowledge that keeps a real incident from becoming a denied claim.
