Who Is Liable When a Security Robot Misses an Incident

Liability in robotic security is not allocated by marketing language; it is allocated by who held the decision at the moment the decision had to be made.

The temptation is to treat a security robot as either an autonomous agent or a piece of equipment, and to argue liability from one of those two poles. Both framings fail under scrutiny. An autonomous agent has no legal personality and cannot indemnify anything. A piece of equipment, by contrast, does not select targets or escalate alarms. The honest description sits in between, and the legal analysis has to sit there with it. What matters is the chain: a sensor produces a reading, software classifies the reading, the platform either resolves the event locally or routes it to an operator, the operator either acts or does not act, and a contract between manufacturer, integrator, service provider and end customer defines who answered for what. Liability follows that chain. It does not follow the brochure.

This article reconstructs the chain in the form courts and insurers can read it. The objective is not to rehearse statutes, which differ by jurisdiction, but to give operators a stable model of where exposure sits, where it migrates, and how it is documented in the contracts that come back when something has gone wrong.

What an incident actually is

Before liability can be assigned, the event in question has to be defined. The industry uses the word "incident" loosely, and that looseness is the first place where disputes begin. An incident is not the moment a person climbs a fence. It is the moment the security architecture was supposed to detect, classify and react to that climb, and either did or did not. The legal question is rarely whether something happened on the perimeter. The legal question is whether the system performed the function it was contractually and technically promised to perform, in the time it was promised to perform it.

This matters because most so-called missed incidents are not single failures. They are sequences of partial failures along the chain. A thermal sensor registered movement but the classifier dismissed it as wildlife. The platform suppressed the alarm under a noise-reduction rule that had been enabled by an integrator three months earlier. The operator console showed a low-priority flag, which the night shift cleared without dispatch. By morning, copper had left the site. Each link in this chain has a contractual owner. A court asked to allocate liability does not look at the outcome. It looks at the links and asks who was responsible for each one, what the documented performance was, and whether the failure at that link was a breach of duty, a design limit that had been disclosed, or an operational choice the customer made.

This is also the reason CISA, NIST CSF 2.0 and IEC 62443 converge on the same logic, even though they address different domains. They demand that the architecture be described, that detection and response functions be assigned to identified roles, and that the boundaries between automated decision and human decision be drawn before the system is put into service. ISO 27001 expresses the same requirement through control ownership. The standards are not in agreement by accident. They reflect what an after-the-fact investigation needs in order to be conclusive: a system whose links can be examined separately.

The manufacturer's exposure

A manufacturer of security robotics is exposed in three areas, and only three. The first is product safety in the conventional sense: the device must not harm persons or property through defect, and it must comply with applicable directives on machinery, electromagnetic compatibility and radio equipment. This exposure is well understood and is handled through certification, conformity assessment and the documentation of safety-relevant design choices. It is not the area where most disputes arise.

The second area is fitness for the stated function. A manufacturer who claims that a platform detects intrusions on a perimeter at a defined range, under defined light and weather conditions, with defined false-positive and false-negative rates, is bound by those claims. Where claims are vague, exposure expands. Where claims are precise and supported by test evidence, exposure contracts. The discipline at Boswau and Knauer is to publish capability envelopes that are narrower than what the platform can deliver in the laboratory, so that field performance lives inside the envelope rather than outside it. This is the opposite of the standard industry practice, which advertises peak performance and then negotiates around field disappointment. Peak performance is not a legal commitment. Capability envelopes are. The difference is visible in court.

The third area is the integrity of the decision logic. If the platform classifies events, escalates them and suppresses them, the rules by which it does so are part of the product. A manufacturer who ships a black-box classifier with no way for the operator to inspect why an event was suppressed has transferred decisional authority to a system that cannot be audited. Courts increasingly treat this as a design defect, regardless of how the contract is written. The remedy is architectural. Decisions made by the platform must be logged with their inputs, the rule that fired, and the version of the model in force at that moment. NIST 800-53 control families on audit and accountability point in the same direction, and IEC 62443 makes the requirement explicit for industrial environments. The manufacturer who builds this in carries less exposure than the manufacturer who builds it on. The platform is then defensible because it is legible.

Where the integrator and operator sit

Between the manufacturer and the end customer there is almost always at least one intermediary. The integrator configures the platform for the site, sets detection zones, defines escalation rules and connects the system to the operator's command and control. The operator, often a security services company, monitors the platform during defined hours, dispatches response and maintains the incident record. Each of these actors carries liability for the link they own.

The integrator's exposure begins where the manufacturer's envelope ends. If the manufacturer warrants detection up to thirty meters under low ambient light, and the integrator places the device to cover an approach of forty meters, the gap is the integrator's. If the integrator disables a class of alarms to reduce console noise without documenting the reasoning and obtaining customer acknowledgement, the suppression is the integrator's. Most disputes between manufacturer and customer evaporate when the integrator's configuration file is produced in evidence. The configuration file is the contract translated into machine state. ASIS International guidance on security program design has been making this point for years; the operational reality is that few sites actually retrieve the file before signing off the installation.

The operator's exposure sits in the response. A platform that produces a correct, timely alarm and an operator who fails to dispatch within the contracted response time has converted a working system into a failed outcome. Courts and insurers, including those guided by NICB methodology in asset recovery cases and GDV statistics in the German market, look at response logs before they look at sensor data. The sensor data establishes that the system worked. The response log establishes whether the human chain worked. The two together describe the incident in legally usable terms.

The customer's exposure, finally, sits in scope. A customer who buys perimeter coverage and then expects perimeter plus interior plus rooftop has bought less than they imagined. This is not a defect; it is a scope dispute. The remedy is at procurement, not at trial.

Why controlled autonomy is the only model that holds

Full autonomy is a marketing posture. No serious manufacturer in this field ships a platform that takes consequential decisions without a defined human role, because no insurance market will accept the resulting exposure and no court will accept the resulting opacity. What works is controlled autonomy: the platform takes routine decisions inside a published envelope, escalates anything outside the envelope to a named human role, and documents both kinds of decision in a single auditable stream. This is the architecture set out in chapter seven of BOSWAU + KNAUER. From Building to Security Technology, and it is the architecture the legal system can read.

Controlled autonomy has three properties that matter for liability. First, the decision boundary is explicit. Each class of event is assigned in advance either to the platform or to a human operator, and the assignment is documented in the operating manual, the service contract and the platform configuration. When an incident is investigated, the boundary is not reconstructed from memory. It is read from the file. Second, escalations are not optional. If an event crosses the boundary, the platform must escalate, and the escalation must be acknowledged. A system that allows silent dismissal of escalations is a system that has imported the operator's bad day into the manufacturer's liability. Third, the audit trail is unified. Sensor reading, classification, rule fired, escalation, acknowledgement and response are recorded in a single sequence with synchronized time. NIST CSF 2.0 names this as a baseline expectation under the detect and respond functions, and BSI guidance for critical infrastructure operators makes the same demand in more prescriptive terms.

The effect on liability is direct. When a missed incident is investigated, the question is no longer who is responsible in general. The question is which link of the documented chain failed, and who owned that link at that moment. Manufacturer, integrator, operator and customer can each defend their position with evidence drawn from the same record. Disputes contract. Insurance responds. The platform that produces this kind of record is more expensive to engineer and cheaper to live with. The platform that does not is the inverse.

Rental and service contracts: where the chain bends

Liability does not behave the same way under purchase, rental and full-service arrangements, and operators frequently underestimate the difference. Under a purchase contract, the customer owns the hardware, controls the configuration after handover and bears the residual risk of operation. The manufacturer retains exposure for product defects and for the capabilities described in the specification. The integrator's exposure ends at acceptance, subject to any maintenance contract. This is the cleanest allocation and the one most aligned with classical product liability doctrine.

Under a rental contract, ownership stays with the lessor, which is typically the manufacturer or a dedicated rental entity. The lessor's exposure now extends through the rental period, because the asset under use is the lessor's asset. Maintenance obligations, software updates and end-of-life decisions sit with the lessor. The customer's exposure narrows to operational use within the agreed parameters. This is the model that suits construction sites and time-bound industrial deployments, because it matches the duration of risk with the duration of contractual responsibility. It is also the model that most clearly favors the customer when an incident is investigated, provided the rental contract specifies the performance envelope and the maintenance regime in writing. A handshake rental is a liability disaster waiting to happen.

Under a full-service or security-as-a-service arrangement, the customer buys an outcome rather than an asset. The provider supplies hardware, configuration, monitoring and response under a single contract, against agreed service levels. Exposure consolidates on the provider, which is operationally simpler but commercially more expensive. The customer's residual liability is largely confined to scope, access provision and any acts or omissions on their side that defeat the service. This model is appropriate where the customer has no internal security competence and no appetite to build one. It is inappropriate where the customer wants to retain control over decisions that affect their own operations, because outcome contracts necessarily transfer those decisions to the provider.

Whichever model is chosen, the architecture beneath it should remain controlled autonomy. The contract describes who owns which link of the chain. The platform produces the evidence. The two together form the legal position that survives the incident.

What holds

Liability in security robotics is not a question of technology in general. It is a question of which link in a defined chain failed, who owned that link, and what the documented performance at that link was supposed to be. Operators who treat the question this way procure differently, contract differently and litigate differently from operators who treat the platform as a black box. The first group has fewer disputes, and the disputes they have are shorter.

The practical conclusion for any operator considering robotic security is that the architecture matters more than the brand. A platform built on controlled autonomy, with capability envelopes that are narrower than peak performance, with decision logs that are auditable end to end, and with contracts that allocate links rather than outcomes, is a platform that holds under examination. A platform that markets autonomy and ships opacity is a platform that fails the first serious insurance review. The choice is made at procurement, not at the moment of the incident.

For operators who want to test where their current arrangement sits on this spectrum, the appropriate starting point is a confidential sixty-minute conversation under Path I from the book referenced above. Where the picture is unclear and the contracts have accumulated over several years, the three-to-five-day audit under Path II produces the documented chain that procurement and legal can both work with. Where a specific site is the right place to validate the model in operation, the ninety-day pilot under Path III delivers the data on which a scaling decision can be defended.

Frequently asked questions

Who is liable when a security robot misses an intrusion?

Liability follows the chain. The manufacturer is liable for product defects and for failure to meet the published capability envelope. The integrator is liable for configuration, placement and rule design within that envelope. The operator is liable for monitoring and response within the contracted service level. The customer is liable for scope, access and operational compliance. A missed intrusion is rarely the failure of one party; it is the failure of a specific link, identifiable in the audit trail. The legal answer depends on which link failed, not on who is most visible.

Does liability shift to the operator or the manufacturer?

It does not shift; it sits where the contract and the architecture place it. The manufacturer carries the design and capability exposure, including the integrity of the decision logic shipped with the platform. The operator carries the response exposure, including monitoring quality and dispatch timing. Shift only occurs when one party assumes functions normally owned by another, for instance when an operator modifies platform configuration without manufacturer authorization, or when a manufacturer takes over monitoring as part of a service offering. Each modification of role modifies the allocation, which is why these arrangements have to be documented.

How is liability handled in a rental contract?

Under a rental contract, the lessor retains ownership of the asset and therefore retains responsibility for its condition, maintenance and software state throughout the rental period. The customer's exposure narrows to operational use within agreed parameters. This makes rental attractive for time-bound deployments such as construction sites, because the duration of contractual responsibility matches the duration of operational risk. The contract must specify the performance envelope, the maintenance regime, the response obligations and the escalation paths. Without that specification, rental converts into an undocumented service relationship, which is the worst position for both parties.

What insurance is appropriate for robot deployment?

Three layers are typically required. Product liability insurance held by the manufacturer covers defects and failure of the device itself. Professional indemnity or errors-and-omissions cover held by the integrator and the operator covers configuration and response failures. Property and business interruption cover held by the customer covers the residual loss when the chain has done its work and a loss has still occurred. Cyber cover is increasingly relevant where the platform is networked, in line with NIST CSF 2.0 and IEC 62443 expectations. The layers must be coordinated so that gaps and overlaps are identified before an incident, not after.