Previous essays introduced robot governance as a question of structure, responsibility, and public coordination, and explained why robotic systems cannot be governed through AI governance alone.
This essay turns to one of the first practical frameworks needed for robot governance: the responsibility chain.
When a robot acts in the physical world, who is responsible?
The question sounds simple, but it is rarely answered by looking only at the robot itself. A robotic system may be designed by one party, manufactured by another, sold or leased to another, configured by another, deployed by another, operated by another, maintained by another, and supervised within a particular workplace, facility, or public environment.
Its behavior may depend on hardware design, software updates, sensor conditions, local rules, staff training, maintenance history, user behavior, and the physical layout of the site.
For this reason, responsibility for robotic systems is rarely a single point. It is better understood as a chain.
A responsibility chain is the set of actors, decisions, authorities, records, and institutional duties that connect a robot’s design, deployment, operation, maintenance, supervision, and incident response.
The purpose of identifying this chain is not to assign blame too quickly. It is to make responsibility visible before something goes wrong.
Why responsibility is distributed in robotics
A robot is not only a product. It is also a system placed into an environment.
This is one of the reasons robot governance differs from narrow forms of technology governance. A robotic system does not simply produce information. It moves, stops, carries, cleans, observes, delivers, guides, assists, patrols, or interacts. Its actions occur somewhere, near someone, under specific conditions.
A hospital delivery robot may move through corridors used by patients, nurses, visitors, wheelchairs, carts, and emergency staff. A cleaning robot may operate in a shopping mall where lighting, floor materials, temporary obstacles, children, and crowds change throughout the day. A care robot may interact with older adults, families, caregivers, and medical routines. A security robot may patrol a facility while also collecting images, sounds, or location data.
In each case, responsibility is shaped by more than the robot’s internal software.
It is shaped by deployment approval, operating area design, staff training, abnormal behavior monitoring, maintenance procedures, incident records, and suspension authority.
This is why robot governance needs responsibility chains.
Responsibility chain is not the same as legal liability
A responsibility chain is not the same as a legal liability judgment.
It does not decide in advance who is legally at fault. It does not replace product liability, contractual responsibility, workplace safety rules, insurance requirements, or regulatory investigation.
Instead, it is a governance tool.
It helps clarify the roles, decisions, authority, records, and procedures that make responsibility traceable. Legal responsibility may later depend on courts, regulators, contracts, standards, or specific facts. But before any legal judgment can be made, the governance structure must make it possible to understand what happened, which actors were involved, and which decisions shaped the robot’s behavior.
In that sense, the responsibility chain is prior to blame.
It is a way of examining whether responsibility was designed into the system, or whether it was left to confusion after an incident occurred.
Main roles in the responsibility chain
A robotic system usually involves several roles. These roles do not always correspond to separate organizations. In a small deployment, one company may be the owner, deployer, operator, and supervisor at the same time. In a larger deployment, responsibility may be distributed across manufacturers, software providers, system integrators, service companies, facility managers, maintenance contractors, insurers, and public authorities.
The point is not that every robot must involve all of these actors separately. The point is that each function should be identified.
These roles form the practical structure of responsibility. If they are unclear, responsibility becomes fragmented.
Manufacturers, software providers, system integrators, deployers, operators, facility managers, maintenance providers, and supervisors may each hold only part of the relevant information. The manufacturer may understand the technical limits of the robot. The software provider may understand how updates affect behavior. The system integrator may know how the robot was configured for a particular site. The deployer may understand the original site assumptions. The operator may know what happened during daily use. The maintenance provider may hold inspection and repair records. The facility manager may know how the physical environment changed. The supervisor may be responsible for deciding whether operation should continue.
A responsibility chain helps prevent this fragmentation by identifying each function before deployment and preserving the records needed for later review.
A simple example: a delivery robot in a hospital
Consider a delivery robot used in a hospital.
The robot is introduced to carry supplies between departments. At first, it operates mostly at night. Later, its route is changed so that it moves through a busy corridor during visiting hours. After a software update, the robot begins choosing a route that passes near a narrow waiting area. Staff notice that it often slows down or stops there. Several visitors step around it. One day, the robot blocks the passage while a wheelchair user is trying to pass. A minor collision occurs.
The responsibility chain prevents this situation from being reduced to a single technical failure.
The manufacturer’s design assumptions may be relevant, including corridor width, floor conditions, speed limits, and obstacle detection. The software provider may have changed route selection through an update. The system integrator may have configured the robot’s maps, routes, or connections with hospital systems. The deployer may have approved the new route without reassessing human traffic. The operator may have noticed repeated stops but failed to report them. The facility manager may have allowed temporary furniture to narrow the passage. The maintenance provider may need to check sensors, maps, wheels, and software versions. The supervisor may need to decide whether the robot should continue operating.
The responsibility chain makes these layers visible.
It does not automatically assign fault to one party. It examines whether the system had enough structure to identify, record, review, and correct the problem before it became an incident.
Stage 1: Responsibility before deployment
Robot governance should begin before deployment.
If responsibility is considered only after an incident, the system has already failed at the institutional level. Before a robot is placed into a human environment, the responsibility chain should clarify at least four points.
1. Operating context
The deployment plan should define the environment in which the robot will operate.
This includes the type of site, the people the robot may encounter, the density and movement of human traffic, the physical layout, and any special risks created by the setting. A hospital, school, warehouse, hotel, airport, station, care facility, office, shopping mall, sidewalk, road, or private home each creates different governance requirements.
The presence of children, older adults, patients, workers, customers, visitors, wheelchair users, or people unfamiliar with robots should also be considered.
The environment matters. A robot that is technically safe in a controlled test space may still be unsuitable for a crowded lobby, hospital ward, school corridor, or emergency route.
2. Operating scope
The deployment plan should define what the robot is permitted to do.
This includes permitted tasks, operating areas, time periods, speed limits, restricted zones, prohibited actions, and conditions that require automatic stop or human review.
A robot should not be introduced as a general-purpose machine if the organization has not defined its actual scope of use.
3. Human roles
Human responsibility should be assigned before operation begins.
The organization should identify the people or units responsible for starting the robot, receiving alerts, performing daily checks, explaining the robot to staff or users, contacting the manufacturer or maintenance provider, and suspending operation when necessary.
A common weakness in robotic deployment is the gap between nominal oversight and real oversight. A person may be listed as responsible, but may not have training, time, authority, or access to the information needed to intervene.
4. Records
Deployment decisions should not remain informal.
The organization should record the robot’s identity, approved tasks, operating area, restrictions, maintenance requirements, staff training, site conditions, and risk assumptions. These records are not only administrative documents. They are the basis for later review.
A responsibility chain is only useful if it can be reconstructed.
Stage 2: Responsibility during operation
During operation, responsibility shifts from planning to monitoring, feedback, and intervention.
A robotic system may be designed to operate autonomously, but autonomy does not remove human or institutional responsibility. The issue is not whether a human manually controls every movement. The issue is whether the organization has an adequate system for supervision, response, and review.
Operational responsibility includes confirming that the robot is being used within its intended scope, environmental conditions remain suitable, staff understand abnormal behavior, and users have a clear way to report problems.
For example, if a cleaning robot repeatedly stops near a dark entrance mat, the issue should not be treated only as a minor inconvenience. It may indicate a mismatch between sensor assumptions and site conditions. If nobody records the pattern, the same problem may continue until it creates a larger operational or safety issue.
Similarly, if a delivery robot frequently takes a route that blocks a narrow passage during peak hours, the problem is not only technical. It is also a deployment and facility management issue.
Operational responsibility therefore requires feedback.
Robots in human environments should not be treated as “install and forget”machines. Their behavior should be observed, recorded, and adjusted.
Stage 3: Responsibility after incidents
After an incident, the responsibility chain becomes especially important.
An incident may involve physical contact, obstruction, property damage, injury, privacy concerns, user confusion, emergency interference, or repeated abnormal behavior. Near misses should also be taken seriously. A near miss may reveal a risk before harm occurs.
The first task after an incident is not only to repair the robot. It is to preserve enough information to understand what happened.
Relevant records may include:
- robot identity
- location and time
- task being performed
- operating mode
- software version
- sensor or error logs
- environmental conditions
- recent maintenance history
- human instructions given before the event
- people or objects involved
- immediate response taken
- decision about whether operation continued or stopped
These records help determine whether the incident was related to design, software, site conditions, maintenance, operation, user behavior, or organizational procedures.
After an incident, the review should examine several layers: use according to manufacturer conditions, suitability of the site, staff training, maintenance status, previous abnormal events, stop procedures, recent software changes, and user communication.
This layered review prevents incident response from becoming fragmented or purely reactive.
Why responsibility chains need records
A responsibility chain without records is only a theory.
In practice, responsibility depends on evidence. It must be possible to identify the robot involved, its owner, its deployer, its operator, its maintenance history, its permissions, its operating environment, and the relevant events that occurred before the incident.
This is why robot governance requires identity and lifecycle records.
Robotic systems are not static products. They may change over time through software updates, repairs, component replacements, ownership transfers, new deployment locations, new permissions, and new operating rules. A robot’s current risk profile may not be the same as when it was first purchased.
If records are fragmented across manufacturers, owners, operators, maintenance contractors, and facilities, responsibility becomes difficult to reconstruct. Each party may hold only part of the story.
A stronger governance model would connect the responsibility chain to persistent records. This does not necessarily require a single public database. Different records may have different access levels. Some information may be public, some limited to owners and operators, some available to maintenance providers, insurers, regulators, or affected institutions.
The key point is that responsibility should be traceable.
Robot Passport as a record layer
The Robot Passport Framework can be understood as one possible record layer for responsibility chains.
A robot passport would not make a robot a legal person. It would not declare that a robot has citizenship, independent rights, or human-like status. Its purpose would be more practical: to maintain persistent identity and lifecycle records for a robotic system.
Such records could include:
- robot identity
- ownership and custody
- deployment context
- permitted tasks and operating areas
- restrictions and authority limits
- maintenance history
- software update history
- inspection records
- incident and near-miss records
- transfer history
This would support responsibility chains in several ways.
It would make it easier to identify the exact robot involved in a situation. It would clarify who had authority over the robot at a given time. It would show whether the robot was operating within its approved scope. It would preserve maintenance and update history. It would also support investigation after incidents or abnormal events.
In other words, the Robot Passport Framework is not separate from responsibility. It is one possible infrastructure for making responsibility operational.
From blame to governance
The purpose of a responsibility chain is not to create a culture of blame. It is to create a structure in which responsibility can be understood, assigned, reviewed, and improved.
As robots become more common in workplaces, public spaces, care settings, commercial facilities, logistics networks, and transport environments, societies will need more than technical performance claims. They will need institutional arrangements that clarify approval, monitoring, maintenance, suspension authority, incident recording, recurring problem review, and communication with affected people.
Robot governance should make these responsibilities identifiable before they become urgent.
A responsibility chain is therefore one of the basic building blocks of robot governance. It connects technical systems to human organizations. It turns abstract accountability into concrete roles, records, and procedures.
And it reminds us that when robots enter human environments, responsibility does not disappear into the machine.
It must be designed into the surrounding institutions.