Physical AI Is Getting Funded in Bengaluru: Product Liability When the Model Runs on the Robot, Drone or Car

In September 2026, YourStory reported that physical AI company SiMa.ai raised a $150 million Series C at a $1.45 billion valuation, co-led by Fidelity Management & Research and Amplify, taking its total funding to $500 million. StartupFeed reported that the money will scale its Palette software and next-generation hardware targeting up to 1,000 TOPS for humanoid robots, ADAS and AI-powered drones. The company employs about 90 people in India and runs SiMa.ai India Private Limited from Bagmane Tech Park in Bengaluru.

The round was not an outlier. Entrackr's Q3 2026 funding report, published on 1 October 2026, put AI as the top-funded sector of the quarter at $635.3 million, with SiMa.ai ($150M) and Emergent ($130M) among the largest deals. Part of that capital is moving toward AI that does not stay on a screen: models that run on a chip inside a robot arm, a car's driver-assistance stack or a drone's flight controller.

That shift creates an insurance problem Indian buyers have not had to solve before. When a cloud model gives a wrong answer, the loss is usually financial and sits in a tech errors and omissions (E&O) policy. When a machine with a mechanical fault hurts someone, the loss is bodily injury and sits in a product liability policy. When an on-device model misreads a pedestrian, a pallet or a power line and the machine then hits it, the loss is both at once, and Indian policy wordings were written assuming it would be one or the other.

This post does not repeat the general robotics cover set out in our robotics and warehouse-automation startup guide. It focuses on one question: when the model is the defect, which policy pays?

Indian commercial wordings split technology and physical risk along a clean line that physical AI does not respect.

What tech E&O does and does not cover

A technology professional indemnity or E&O policy responds to financial loss a client suffers because of an error, omission or negligent act in the insured's software or services. Most Indian tech E&O wordings carry a bodily injury and property damage exclusion, sometimes with a narrow carve-back for mental anguish or data loss. Under that exclusion, a perception model's mistake stops being an E&O claim the moment the robot it runs on injures a worker. For a pure software company this rarely matters. For an edge AI vendor, it removes cover from the most severe outcome its product can produce.

What product liability does and does not cover

A product liability policy responds to bodily injury and property damage caused by a product the insured manufactured, sold or supplied. It usually excludes pure financial loss, the cost of the product itself, failure of the product to perform its intended function (the efficacy or performance exclusion), and often professional advice or design services provided for a fee. Some wordings also define the insured product narrowly, by reference to physical goods listed in the schedule. A model, a software development kit or a compiler toolchain may not be a scheduled product at all.

The result is a set of losses that each insurer can point to the other for:

• A perception model on an edge chip misclassifies an object, and a humanoid robot strikes a technician. The E&O insurer cites the bodily injury exclusion. The product insurer asks whether software licensed separately from the chip is a scheduled product.
• A model update pushed over the air degrades ADAS braking performance before anyone is hurt. The OEM's cost of disabling the feature is neither third-party injury nor a client's financial loss under a standard wording.
• A drone's onboard vision stack fails to detect a cable, and the drone damages a substation. The property damage looks like product liability, but the root cause sits in software the startup characterises in its contracts as a service.

The Consumer Protection Act, 2019 introduced a statutory product liability regime in India. It allows a claim against a product manufacturer, a product service provider and a product seller, and it defines defect broadly enough to cover design defects, manufacturing defects and inadequate warnings. Physical AI stacks have several parties who could plausibly be the manufacturer of the defective element:

1. The silicon vendor, which designs the edge AI chip and supplies the runtime and compiler that turn a trained model into code that runs on it.
2. The model developer, which may be the chip vendor, the OEM's own team or a third-party perception specialist.
3. The integrator or robot maker, which assembles the chip, sensors, actuators and safety controller into a machine.
4. The OEM or fleet operator, which sells or deploys the finished robot, vehicle or drone under its own brand.

A claimant will name all of them. The question for each party's broker is whether its own policy recognises what it supplies as a product, and whether its contracts push liability up or down the chain in a way the policy will follow.

For Indian startups selling into overseas OEMs, the same analysis runs in reverse. The OEM's supply agreement will usually require the startup to indemnify it for defects in the startup's component, including software, and to carry product liability with worldwide jurisdiction. Startups that buy only an India-jurisdiction policy, or that buy E&O alone because they think of themselves as software companies, are exposed on exactly the claims their customers worry about most.

There are three workable approaches, and the right one depends on where the startup sits in the stack.

Option 1: product liability with an explicit software endorsement. For robot makers, drone manufacturers and integrators, the cleanest fix is to buy product liability that defines the insured product to include embedded and on-device software, firmware, AI models and over-the-air updates supplied with or for the hardware. Ask the insurer to confirm in an endorsement that bodily injury or property damage caused by an error in such software is treated as a product defect, and that the performance or efficacy exclusion does not apply where the failure to perform results in bodily injury or property damage.

Option 2: tech E&O with a bodily injury carve-back. For chip vendors, model developers and SDK providers whose revenue is mostly licences and services, the E&O policy is often the main policy. Some insurers will write a carve-back to the bodily injury and property damage exclusion where the injury arises from a technology product or service, usually sub-limited and sometimes excess of an underlying product liability policy. Our note on AI SaaS model risk insurance covers the financial-loss side of model failures; the carve-back is what extends that thinking to physical harm.

Option 3: a combined technology and product programme from one insurer. Where possible, place professional indemnity and product liability with the same lead insurer, on aligned wordings, with matching retroactive dates and a single aggregate structure. This does not remove the coverage question, but it removes the incentive for two insurers to argue over which of them pays. A single lead also simplifies subrogation disputes when the OEM's insurer pursues the component supplier.

Whichever route is chosen, read three clauses side by side: the definition of product, the bodily injury exclusion in the E&O wording, and the professional services exclusion in the product liability wording. The gap almost always sits in the overlap of those three.

A defect in a physical AI model is rarely limited to one unit. Every robot, car or drone running that model version carries it. That makes physical AI recall exposure different from conventional component recall in two ways.

First, the fix is often a software update rather than a physical retrieval. Standard product recall wordings were built around withdrawing goods from the market: notification, transport, disposal and replacement. They may not respond to the cost of developing, validating and deploying an emergency model patch, or to the cost of geofencing or disabling a feature fleet-wide while the patch is built. Ask specifically whether the recall policy covers software remediation, remote disablement and customer notification where no physical unit is retrieved.

Second, the trigger is less clear. A recall policy usually responds when there is a reasonable belief that use of the product could cause bodily injury or property damage, or when a regulator orders a withdrawal. A model that is drifting toward worse performance under certain lighting or weather conditions may cross that threshold gradually. The startup should agree with the insurer, before a loss, what evidence of a safety risk triggers cover.

For OEMs, the bigger exposure is often the cost they incur on the startup's behalf, for example taking vehicles off the road or grounding drones, and then recover from the supplier under the contract. That recovery claim is a financial loss to the OEM, which may fall under the startup's E&O, its recall policy, or neither. Our coverage of BVLOS drone manufacturer product liability shows how quickly a single airframe issue becomes a fleet-wide grounding.

Indian insurers have limited loss data on physical AI, so underwriting relies on process evidence. Startups that prepare it get better terms and fewer exclusions. Expect questions on:

• Where the model runs and what it controls. Is the model advisory (it flags a hazard to a human) or does it actuate (it steers, brakes or grips)? Is there an independent safety controller that can override it?
• Validation and release discipline. How is each model version tested before deployment, on what datasets, against which safety requirements, and who signs off?
• Version tracking and rollback. Can the startup tell, for any incident, which model version was running on which unit, and can it roll back remotely?
• Contract terms with OEMs. Caps on liability, exclusion of consequential loss, indemnity scope and the insurance the startup has promised to carry.
• Geography. Where products are sold and used, which drives jurisdiction and limit requirements, especially for exports to the US and EU.
• Revenue split. How much income comes from hardware, licences and services, since this drives whether product liability or E&O is the primary rating base.

Startups should also disclose honestly where their software is used. Under the principle of utmost good faith, failure to tell the insurer that a vision stack is going into humanoid robots or road vehicles, rather than warehouse inspection cameras, can give the insurer grounds to avoid the policy.

Insurance only follows liability that the policy recognises. Contracts can create liability the policy does not. For physical AI supply deals, four contract points need to match the insurance programme:

1. Indemnity scope. If the startup indemnifies the OEM for all losses arising from defects in its software, that indemnity covers bodily injury, property damage, recall costs and financial loss. The startup's programme needs to answer each of those heads, or the indemnity should be narrowed.
2. Liability caps. A cap tied to contract value is common in software deals, but OEMs often carve out bodily injury and recall from the cap. Where they do, the startup's product liability and recall limits become its real ceiling.
3. Insurance requirements. OEMs may ask for named limits of product liability, E&O and recall, additional insured status and waivers of subrogation. Check that the policy permits these before signing.
4. Definition of the deliverable. Contracts that describe the model as a licensed service, while the insurance treats it as a product, invite the exact dispute this post describes. The wording in the contract and the wording in the policy should describe the same thing.

For OEMs and fleet operators, the mirror image applies. The OEM's own product liability policy will typically respond first to a third-party claim. The OEM then needs confidence that its supplier's insurance is real, adequate and aligned, so that the recovery claim lands somewhere. Requesting certificates is not enough; ask for the relevant definitions and exclusions.

Physical AI is moving faster than Indian policy wordings. The startups raising money in Bengaluru today can be sued as product manufacturers, whatever their pitch deck says. Buying cover that treats the on-device model as part of the product is the most direct way to make sure a model failure is someone's claim, rather than everyone's exclusion.