Liability and Insurance for Remote Robot Operation

A remote operator connects to your SO-100, drives it for forty minutes, and somewhere in minute thirty-one the gripper closes on the bench edge instead of the block. A servo strips. Or the arm sweeps a full mug into a laptop. Or the operator was recording an episode in a room where a colleague walked through frame, and that frame is now in a public dataset.

None of that is exotic. It is the ordinary result of letting a stranger move a motor inside your building. The question is not whether it happens but whether you decided in advance who carries it. Below are the questions to settle before the first session, and the parts that teleoperation practice in regulated fields has already worked out. Remote driving has had regulators looking at it for years, and most of their conclusions transfer straight to a 110 EUR arm on a desk.

What actually breaks, and who gets blamed

Start with the physical inventory, not the legal theory. List what one session can destroy, what it costs, and who has no idea they are exposed. On an SO-100 class arm the numbers are small, which is why people skip this and then discover the interesting cases were never about the arm.

The last column is the whole article. In almost every row, the person who could have prevented the damage is not the person who was driving. That is why regulators in remote driving landed where they did, and why an agreement that dumps everything on the operator will not survive a real claim.

Four parties, three contracts, one gap

Most people think in two parties: me and the operator. There are four, and the gap is usually between the hardware owner and whoever supplies the connection, because that is the boundary nobody wrote anything about.

Read that last row rather than assuming it. LeRobot, the code most SO-100 stacks run, ships under Apache-2.0. Section 7 provides the work on an "AS IS" basis without warranties of any kind. Section 8 excludes liability for direct, indirect, special, incidental or consequential damages arising from use or inability to use it, in tort or contract, even where the contributor was warned. If a default in that code contributes to a broken servo, the fix is yours and so is the bill.

The two config lines that decide the argument

Before drafting a clause, read the configuration you actually run. This is the SO follower config for the SO-100 and SO-101 on the LeRobot main branch, read 24 August 2026.

@dataclass
class SOFollowerConfig:
    """Base configuration class for SO Follower robots."""

    # Port to connect to the arm
    port: str

    disable_torque_on_disconnect: bool = True

    # `max_relative_target` limits the magnitude of the relative positional target
    # vector for safety purposes. Set this to a positive scalar to have the same
    # value for all motors, or a dictionary that maps motor names to the
    # max_relative_target value for that motor.
    max_relative_target: float | dict[str, float] | None = None

    # cameras
    cameras: dict[str, CameraConfig] = field(default_factory=dict)
    use_degrees: bool = True

    # Position-mode PID gains written to Feetech STS3215 motors at connect time.
    position_p_coefficient: int = 16
    position_i_coefficient: int = 0
    position_d_coefficient: int = 32
    num_read_retries: int = 2

With the cap set, ensure_safe_goal_position clips the difference between goal and present position to plus or minus the cap, per joint, per step, and logs a warning naming the original and clipped target. That warning is evidence: it records an instruction the machine declined. The second line points the other way. disable_torque_on_disconnect defaults to True, so a dropped client relaxes the arm. Correct for a bench arm with a human beside it, wrong if the arm is holding something over a hard surface, because the safe state is then "fall". Pick one, write it down, and test it by pulling the cable rather than by reasoning about it.

What remote-operation practice has already settled

Remote driving is the same problem with worse consequences, examined in public by people whose job is allocating blame. In February 2023 the Law Commission of England and Wales published advice to the UK Government on remote driving, after an issues paper surveying the safety literature. Their findings read like a checklist for remote arms.

Two of those transfer unmodified. First, jitter: choosing between a stable 180 ms link and one averaging 90 ms with spikes to 400, take the stable one. That is the same conclusion our inference latency page reaches from the other direction, and it is why the honest limit on remote work is slow pick-and-place rather than fast reactive motion. Second, fatigue: if operators are paid per session and nothing stops them running six hours straight, you have imported a known failure mode from rail signalling and chosen not to mitigate it.

The regulation calendar, if you touch the EU

Three instruments land within roughly fourteen months and all three reach remote robot work. None was written with hobby arms in mind, which is the point: they are written in terms of software, products and platform work, and that is what you are running.

The operator agreement: ten clauses that earn their space

A remote operator agreement does not need to be long, only specific about the few genuinely contested things. Most templates spend three pages on confidentiality and one sentence on what happens when the arm breaks.

Classification is the row that changed. Directive (EU) 2024/2831 introduces a rebuttable presumption of employment for platform work where facts indicate direction and control, with the burden of proof on the platform. It also requires written notice before automated monitoring or decision systems are used, meaningful human oversight by people with authority to override, and a human decision before an account is suspended. If your marketplace scores and deactivates operators automatically, that is algorithmic management and it is regulated in the EU from 2 December 2026.

Forum matters more than expected once operators are international. The Law Commission worked through a vehicle driven in England from a control room abroad and found the legal test usually satisfiable but the practical problems dominant: evidence from a foreign control centre is hard to obtain, and extradition adds delay and expense and is not guaranteed everywhere. Translated to a robot arm, your realistic remedy against an individual abroad is deactivation and withheld payment, not litigation. Design controls on that assumption. The RoboTurk work on crowdsourced teleoperation is the precedent: 137.5 hours of manipulation data from remote workers, with the real engineering in tolerating whoever showed up.

Six things to do before the first session

1. 1
   Cap the motion before anyone connects

   Set a per-step limit so no single frame can command a full-range move. Start tight, loosen only after watching a full session.

   python

   from lerobot.robots.so_follower import SO101Follower, SO101FollowerConfig
   
   config = SO101FollowerConfig(
       port="/dev/tty.usbmodem585A0076841",
       id="cell-a-follower",
       max_relative_target=5.0,            # degrees per joint, per control step
       disable_torque_on_disconnect=True,  # arm relaxes when the client goes away
   )
   
   robot = SO101Follower(config)
   robot.connect()

2. 2
   Calibrate, and keep the file with the arm id

   Calibration is a liability artefact as much as a technical one. An uncalibrated arm makes every joint-limit argument unresolvable.

   bash

   lerobot-calibrate \
       --robot.type=so101_follower \
       --robot.port=/dev/tty.usbmodem58760431551 \
       --robot.id=cell-a-follower

3. 3
   Bound the workspace physically

   Clear the reachable volume of anything you would mind losing, add a hard stop where the arm can reach the table edge, keep the power switch within reach of the person in the room. OSHA's robot safety chapter is blunt: most incidents happen during setup, programming and maintenance rather than normal operation, and every worked example involves somebody inside the restricted space when motion resumed.

4. 4
   Record every session, not just the good ones

   Drive through the recording path so there is a file when someone disputes what happened. Two camera angles beat one, because the argument is nearly always about depth.

   bash

   lerobot-record \
       --robot.type=so101_follower \
       --robot.port=/dev/tty.usbmodem585A0076841 \
       --robot.id=cell-a-follower \
       --robot.cameras="{ front: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30}}" \
       --teleop.type=so101_leader \
       --teleop.port=/dev/tty.usbmodem58760431551 \
       --teleop.id=cell-a-leader \
       --display_data=true \
       --dataset.repo_id=${HF_USER}/session-log \
       --dataset.num_episodes=5 \
       --dataset.single_task="Remote operator session" \
       --dataset.push_to_hub=False

5. 5
   Test the disconnect instead of reasoning about it

   Give the arm a payload over a soft surface, kill the network, watch. Whatever happens is your safe state, and it is now a fact. Repeat after every firmware or config change.

   bash

   sudo ip link set dev eth0 down
   sleep 5
   sudo ip link set dev eth0 up

6. 6
   Write the two-page agreement

   Use the ten-clause table above. Two pages naming the arms, the abort conditions and the liability cap beat twenty pages of boilerplate that never mentions the gripper.

Doing it yourself, or on the platform

Insurance: the exclusion aimed at exactly this

The instinct is that general liability handles it, because general liability is what businesses buy for property damage. It does not, and the reason is a specific exclusion that has been in commercial general liability policies for decades.

Whether a remotely driven arm is really in the operator's care, custody or control is genuinely arguable, and that is the problem: arguable means slow and expensive. The working definition insurers use is a bailment, an exposure created by holding someone else's property or working on it. You never touched the arm, but you had exclusive authority over its motion. Do not discover which way that goes by making a claim.

Evidence: what the session record has to contain

Most disputes reduce to a factual question that a good record answers in ten minutes and a bad one turns into a month of email. Automotive trialling practice already gives the shape: record continuously at 10 Hz minimum, and around an incident keep a suggested 30 seconds before and 15 seconds after at 50 Hz. A LeRobot recording at 30 Hz already clears the continuous bar.

• Operator identity and session boundaries, to the second.
• Commanded action and measured joint state, both, at the control rate. The gap between them is where clipping and stalls appear.
• Every camera stream the operator could see, not only the ones you kept for training.
• Round-trip latency samples with timestamps, because jitter keeps being the finding and cannot be reconstructed later.
• Any warning from the motion cap, since a clipped target records an instruction the machine declined.
• Configuration at session start: robot id, calibration file, cap value, firmware, software version.

Then decide what happens to the recording. If operator sessions become episodes in a training set and that set goes public, an evidence record has quietly become a publication. The EDPB's Guidelines 3/2019 on processing personal data through video devices, adopted 30 January 2020, are the EU reference for footage capturing people, and a workspace camera that occasionally catches a colleague is video processing whether or not anyone intended it. Keep a private session log with a defined retention period, and treat the training dataset as a separate artefact somebody reviews before publication. Our guide to collecting high-quality VLA training data covers the quality half of that review; the consent half is yours.

Cost is a liability question too

Physical damage is not the only thing an operator can cause. Sessions and training runs cost money, and who pays for a wasted one belongs in the same document. The ranges here are known: a run on the A100 80 GB or H100 tier, where GR00T N1.7 and Pi0.5 sit, takes 3 to 6 hours at 1.20 to 2.00 USD per hour, so roughly 4 to 12 USD. A 24 GB card run for SmolVLA or ACT takes 2 to 5 hours at 0.30 to 0.60 USD per hour, so roughly 1 to 3 USD. Small enough that nobody should be arguing: write down that the owner absorbs the compute cost of a failed run and remove a whole category of dispute for the price of a coffee. Inference pods carry an idle watchdog and destroy themselves after an idle period, so an operator who walks away does not leave a meter running. The billing documentation covers who is charged for what.

Where this does not help

Being honest about limits is part of the risk assessment. Remote operation over the public internet is viable for slow, deliberate pick-and-place, not for fast reactive motion. The control loop here runs between 20 ms per action step for an ACT policy and 485 ms for Pi0.5, and adding public-internet round trips turns a working policy into a hesitant one. If your task needs reaction inside a couple of hundred milliseconds, the answer is not a better contract, it is inference next to the servos.

• The platform does not insure your hardware or stand behind operator conduct. Those are your contracts.
• Nothing here decides whether your operator is an employee, contractor or platform worker. That test is national and fact-driven.
• A bounded session and a recorded dataset are evidence, not immunity. They shorten disputes, they do not prevent them.
• The leader-follower setup that gives the best data quality also maps an operator's hand motion onto real torque. Better data and higher risk arrive together.
• None of this replaces physical controls. If the arm can reach something expensive, eventually it will. See the failure-mode index for what the common ways look like in software.

Questions people actually ask

One last piece of practical advice: run the whole loop yourself, as owner and as operator, before writing anything. Set an arm up with the SO-100 setup guide, record a session with the recording walkthrough, pull the cable mid-move, and read what the log actually contains. Forty minutes of that produces a better agreement than a week of templates, because you will have seen which questions have answers and which ones you were guessing at.