An Institution Cannot Transfer Responsibility to a Machine

Dilan Acar’s father, Rauf, has spent twelve days in hospital with a severe respiratory illness. His inpatient treatment is complete. For the first two weeks after discharge, however, he must have at home a respiratory-support device prescribed by his doctor, regular nursing checks, medication monitoring and access to an emergency home-care line. Rauf is being treated by Mira Health Network, a large private healthcare group. To accelerate discharge and reduce the workload on hospital staff, Mira uses an AI-supported system called the Continuum Care Orchestrator. The system performs the following tasks together:

• Reads the doctor’s discharge instructions.
• Checks the patient’s insurance cover.
• Checks medical equipment supplied previously.
• Sends an order to the home-care company.
• Schedules nursing visits.
• Sends information messages to the patient and their family.
• When the required steps are complete, changes the patient’s status to:

Discharge ready. The system was not built by a single company.

1. Its architecture is as follows: Mira Health Network
2. ↓
3. ArdaTek Health Integration Services
4. ↓
5. Continuum Care Orchestrator
6. ↓
7. Helix General-Purpose AI Model
8. ↓
9. Birlik Health Assurance Data Service
10. ↓
11. EvDestek Medical Equipment and Care Services

Each institution controls only one part of the system. Mira Health Network manages the patient relationship. ArdaTek built the agents and workflows. Helix supplies the foundation model used to summarise documents. Birlik Health Assurance supplies records of medical equipment issued in the past. EvDestek delivers the equipment. Rauf’s doctor enters this instruction in the discharge plan: ‘The patient must not be discharged until a home respiratory-support device has been provided. The first nursing visit must take place within twenty-four hours of discharge.’

The instruction is recorded correctly in the hospital system. The Continuum Care Orchestrator queries Birlik Health Assurance’s data service. The service returns:

patient_has_active_home_respiratory_device: true
provider: EvDestek
record_date: 7 months ago

The record is stale. Rauf used the same type of device for a short period seven months earlier. He returned it to EvDestek four months ago, but the return was never written to the insurer’s central record. The data does not say, ‘A device was supplied in the past.’ It says, ‘The device is still active in the patient’s home.’ The Continuum Care Orchestrator interprets this field as:

duplicate_device_order_risk: high

One of Mira Health Network’s cost-control policies then applies:

IF active_equipment_record_exists
THEN
do_not_create_duplicate_order
use_existing_equipment

The policy is intended to prevent patients from being charged twice for the same device. But the rule contains none of the following checks:

• How current the record is
• Whether the device is actually in the patient’s possession
• Whether the device may have been returned
• Whether the doctor’s new and explicit instruction should take precedence over the older record
• Physical confirmation from the patient or a family member
• Evidence of delivery before discharge

The system does not create a new equipment order. Its internal record reads:

new_device_order:
suppressed
reason:
active_equipment_already_available

The doctor’s screen shows only: Home respiratory support: covered It is unclear whether ‘covered’ means that insurance cover exists, an order has been placed, the equipment has been delivered or the device is physically present in the patient’s home. A green indicator appears on the discharge nurse’s dashboard: ✓ Home support confirmed The nurse is managing thirty-one discharge files that day. She trusts the green status and does not ask separately whether a device is actually present in Rauf’s home.

The Continuum Care Orchestrator sends EvDestek a request for a nursing visit. EvDestek’s system accepts the request:

HTTP 202
visit_request_received

The agent records this technical acceptance as:

home_nurse_visit_confirmed: true

In reality, the visit has not yet been assigned to a nurse. EvDestek has no weekend capacity, and the request is expected to be scheduled on the next working day. The Continuum Care Orchestrator sends Dilan this message: ‘Preparations for your father’s home care and respiratory support are complete. His first post-discharge visit has been scheduled.’ The message does not say that no new equipment order was placed, that the system assumes an old device is still in the home, or that the nursing visit has reached only the request stage. Rauf is discharged. Dilan takes her father home. There is no respiratory-support device there.

Dilan calls the hospital. The call-centre screen shows: Home equipment: active Nurse visit: confirmed Discharge plan: completed The call-centre agent says, ‘Our system shows that all home-care preparations have been completed. You need to speak to the equipment provider.’ Dilan calls EvDestek. An employee checks the records. ‘There is no new equipment order. The system sent us only a request for a nursing visit.’ Dilan replies, ‘The hospital said the device was ready.’ EvDestek answers, ‘The hospital may not have created a new order because the insurance system shows an active device. You need to speak to your insurer.’

Dilan calls Birlik Health Assurance. An employee tells her, ‘We merely transmit the existing equipment record to healthcare providers. We are not responsible for physical delivery. The equipment provider should have updated the return.’ Dilan calls EvDestek again. ‘The return is closed in our system. We do not know why the insurer’s data synchronisation was not updated.’ She contacts Mira Health Network once more. The hospital call centre says, ‘The doctor made the discharge decision. You need to speak to your doctor.’ The doctor’s secretary responds: ‘The doctor wrote explicitly that Rauf must not be discharged without the device. The doctor does not manage procurement.’

Within a few hours, Dilan has spoken to several institutions and departments. Each points to a fragment that appears correct in its own system. None answers the central question:

‘Who was responsible for ensuring that the device was actually in the home?’

That evening, Rauf’s condition deteriorates. Dilan calls the emergency services. He is taken back to hospital and kept under observation for two more nights. No permanent or severe physical injury occurs. Even so, the failure has caused another emergency intervention, an additional hospital stay, serious fear and exhaustion for the family, time away from work for Dilan, and further transport and care costs. This time, Mira Health Network opens an incident review.

At the first meeting, the hospital’s digital-health team says: ‘The Continuum system misinterpreted a stale insurance record. We have notified the software provider.’ ArdaTek Health Integration Services responds: ‘The agent correctly applied the business rule approved by Mira Health Network. The instruction not to create a duplicate order when an active equipment record exists is part of the hospital’s cost policy.’ The Helix model provider says: ‘Our model is supplied solely to summarise documents. We do not recommend making clinical or discharge decisions without independent human oversight.’

Birlik Health Assurance says: ‘The data came from the equipment status supplied by EvDestek. We are not the source system.’ EvDestek says: ‘The return is recorded in our system. Synchronisation with the insurer’s data feed is the external provider’s responsibility. We did not deliver a device because we received no new order.’ The discharge nurse says: ‘Every indicator on my screen was green. I could not see the detail behind the system.’ The doctor says: ‘I wrote explicitly that the patient must not be discharged without a device. I did not know that an automated cost rule had overridden my instruction.’ The call-centre agent says: ‘The screen showed the process as complete. I had no access to the procurement system.’

Everyone explains one part of the system. No one takes ownership of the conduct as a whole.

The contracts are examined. The agreement between Mira Health Network and ArdaTek states: ‘The customer is responsible for the business rules it configures and for the clinical use of system outputs.’ The agreement between ArdaTek and Helix says: ‘Model outputs are provided for information only; final decisions remain the responsibility of the user institution.’ The insurance data service terms state: ‘We do not guarantee that third-party records supplied are current.’ EvDestek’s contract says: ‘We are responsible only for verified, active orders.’ Mira Health Network’s patient-service terms state: ‘Third-party automation and artificial-intelligence systems may be used in certain care-coordination processes.’

Each contract pushes responsibility towards another actor. Around the technical chain it passes from the hospital to the integrator, from the integrator to the model provider, from the model provider back to the hospital, from the hospital to the data provider, from the data provider to the equipment company, and from the equipment company back to the hospital. Responsibility has become a circle, with Rauf and Dilan at its centre.

Mira Health Network wants to describe the incident as a ‘third-party data-synchronisation error’. That description does not tell the whole story. The stale data was the first fault, but several other conditions were required for the harm to occur:

• The hospital adopted a policy under which a stale record could override a doctor’s new instruction.
• The system did not verify that the device was physically present.
• Insurance cover, order placement and delivery were collapsed into a single green status.
• Technical receipt of the home-care request was presented as confirmation of the visit.
• The real uncertainty was not shown to the nurse.
• The doctor’s explicit instruction was silently overridden by an automated cost rule.
• The call centre could not reach the external system that held the relevant facts.
• No person or institution was designated as the owner of the discharge outcome as a whole.
• The system sought no evidence of actual equipment delivery before discharging the patient.
• When the incident occurred, the family had no single, accountable route to remedy.

The stale data was wrong, but it did not discharge Rauf by itself. The model did not discharge him by itself. The integrator did not manage the patient relationship alone. The nurse did not design the system. The doctor did not manage the supply chain. EvDestek could not deliver equipment without an order. The conduct as a whole arose within an institutional system. Mira Health Network:

• selected the system;
• integrated it into the patient pathway;
• approved the business rules;
• presented staff with the green status display;
• authorised the agent to operate in the discharge workflow;
• received the time and cost benefits of automation; and
• discharged Rauf in its own name.

The hospital cannot therefore end the matter by saying, ‘The AI made a mistake.’ The right question is:

‘Who gave this AI the power to act in Rauf’s discharge process?’

And the second question is:

‘When that power causes harm, who will stand accountable before Rauf?’

Our thirteenth and final founding provision is therefore:

An institution cannot transfer responsibility to a machine.

FOUNDING ARTICLE

An institution may give an AI system tasks, data, tools, budget, representational authority and power to act. It cannot transfer to that system its responsibility to own, oversee and explain material consequences for people, to stop and correct harmful conduct, or to provide redress. The conduct of an AI system acting for an institution forms part of the institution’s own chain of conduct. Statements such as ‘the model decided’, ‘the agent sent it’, ‘the tool applied it automatically’ or ‘that is how the subcontractor’s system operated’ do not extinguish human or institutional responsibility. Before any high-impact AI system enters live use, it must be connected to an identified institutional principal, authorised human owners, stopping authority, an incident owner, an owner of the remedy process and the capacity to provide redress.

If no responsible human and institution can be identified for the purpose, data, model, authority, human review, external action, incident response or redress associated with high-impact conduct, the system may not be deployed—or allowed to continue—in that area. An AI system cannot be presented as the sole and ultimately responsible actor, the holder authorised to accept residual risk, the owner of a person’s route to remedy, the party obliged to apologise or provide redress on an institution’s behalf, or the authority that closes an incident. A task may be outsourced. A technical component may be open source. A foundation model may come from another institution. Data may be supplied by a third party. A human may press the final button. None of these facts removes the governance burden from the institution that uses the system in its dealings with people.

Shared responsibility is not diminished responsibility. Where several institutions contribute to the same harm in different ways, each may bear responsibility in proportion to its control, knowledge, benefit and capacity to correct the outcome. The affected person cannot be required to resolve that internal allocation. Institutions may use contracts to allocate financial and operational burdens among themselves. But no contract, waiver, limitation of liability, user term, audit report, certificate or badge may eliminate the person’s route to explanation, challenge, stopping, correction and redress.

An institution’s defence that ‘a human made the final decision’ has meaning only if that person had the relevant information, sufficient time, a genuine opportunity to assess the matter independently and authority to change the outcome. If the person merely clicked the system’s green indicator, or critical information was withheld from them, responsibility cannot be shifted onto a token human approver. A person may, of course, have misused the system deliberately; that may alter the allocation of responsibility. But general user terms, or the assertion that ‘you pressed the final button’, are not blanket shields against the institution’s foreseeable risks, manipulative design, weak access controls or unauthorised automation.

If an institution knows that a provider cannot support Decision Trails, Action Receipts, correction, deletion, stopping, versioning or incident response, it must not use that provider for high-impact conduct. Choosing a component that cannot be audited is itself an institutional decision. An institution may accept known residual risks through an authorised human decision for a defined scope and period. A machine cannot accept residual risk; nor may that risk be shifted silently onto staff or affected people, or hidden in general terms of service. When inaccurate or unauthorised conduct is confirmed, correcting the technical fault is not enough. The institution must identify affected people, stop continuing harm, correct connected decisions and records, manage the external-provider chain itself, provide appropriate redress and scan for others affected by the same root cause.

Fixing the code does not close the incident. The incident cannot be closed until the material effects on people have been assessed, the remedy process completed, residual risk assigned openly to an authorised owner and the root cause retested. An institution that gains economic, operational or public benefit from an AI system must also bear the costs of governing and auditing that power, providing human review, managing incidents and delivering redress. The gains from automation cannot accrue to the institution while the cost of error falls on the person alone.

What Is Institutional Responsibility?

In this book, ‘responsibility’ does not refer only to fault or compensation under a particular legal system. Legal consequences must be assessed separately under the relevant country’s law, the applicable contract or regulation, and the evidence in the individual case. For NOMOS 13, institutional responsibility is a more fundamental concept. Its canonical definition is this: institutional responsibility is the duty of an institution that gives an AI system power to act to define the purpose and limits of that conduct properly; anticipate its risks; identify human owners; monitor real-world outcomes; intervene when something goes wrong; provide affected people with an explanation and an effective route to remedy; correct connected systems; and repair material effects appropriately.

In plainer terms:

For as long as an institution operates the machine, it cannot disappear from the chain of responsibility for the machine’s conduct in people’s lives.

Responsibility Is Not the Same as Fault

An institution may bear responsibility without being the only actor at fault, the sole material cause or the only party required to provide redress in every case. In Rauf’s case, for example:

• The data provider contributed the stale equipment record.
• The integrator failed to implement a freshness check.
• The hospital approved the policy that overrode the doctor’s instruction.
• The interface gave the nurse false confidence.
• A home-care request that had merely been accepted was presented as complete.
• The human support teams could not see the chain as a whole.

Several actors may have contributed. That does not mean that no actor is responsible. MULTIPLE ACTORS ≠ NO RESPONSIBILITY

Responsibility, Accountability and Redress

These three concepts can be distinguished.

Responsibility

Responsibility means bearing the necessary duties before and during the conduct: ‘Who must ensure that this system operates safely and respects people’s rights?’

Accountability

Accountability means being able to explain what happened after the incident and stand behind the decision: ‘Who will defend this conduct—or acknowledge that it was wrong—and on the basis of which decision and evidence?’

Redress

Redress means repairing the effect of the error in a person’s life: ‘Who will restore the correct state, and who will assess effects that cannot be reversed?’ An institution may explain what happened without providing redress. It may pay money without correcting the root cause. It may fix the system without contacting the people affected. Full institutional responsibility encompasses all these domains.

What Is an Institution?

In NOMOS 13, the word ‘institution’ does not mean only a large company. It may include a:

• Company
• Public body
• Hospital
• University
• Platform
• Association or foundation
• Professional body
• Sole proprietorship
• Service provider operating a high-impact agent on a person’s behalf
• Joint service arrangement involving several organisations

Before questions of legal form or title, the fundamental question is:

Who introduced the AI’s conduct into the human relationship?

The Institutional Principal

We can call the institution on whose behalf an AI system acts in its dealings with a person the Institutional Principal. An Institutional Principal will usually have one or more of the following characteristics:

• It establishes the service or business relationship with the person.
• It defines the AI system’s purpose.
• It selects the system or provider.
• It connects the data and tools.
• It benefits from the outcome of the conduct.
• It defines the authority boundaries.
• It can stop or change the system.
• It can provide correction and redress to the person.
• The conduct occurs under its brand or account.

In Rauf’s case, the Institutional Principal is:

Mira Health Network.

ArdaTek and the other providers may bear separate responsibilities. But Rauf was admitted by the hospital, treated by the hospital and discharged by the hospital; he received the message that home care was ready from the hospital. Mira Health Network cannot abandon ownership of the patient relationship by telling him, ‘Speak to the integrator yourself.’

There May Be More Than One Institutional Principal

A service may genuinely be operated jointly. For example:

• A bank and an insurance company may use a shared agent.
• A municipality and a private service provider may make decisions together.
• A parent company and a subsidiary may operate the same data system.

In such cases, more than one institution may bear responsibility. But the person must not face an endless series of doors marked ‘not our area’. The institutions must establish a single point of contact, a process for sharing the case file and an agreed allocation of redress.

Machine Conduct on an Institution’s Behalf Is Institutional Conduct

If an AI agent acts through an institution’s email account, website, payment instrument, discharge system or customer portal, that conduct cannot be separated from the institution as the machine’s ‘private act’. The institution may use the agent as a tool. The agent may possess a degree of autonomy. But its conduct towards people in the outside world forms part of the institution’s operations. AUTHORISED AGENT CONDUCT ON AN INSTITUTION’S BEHALF = INSTITUTIONAL CHAIN OF CONDUCT

Autonomy Does Not Reduce Responsibility

The more autonomous a system becomes, the more important the institution’s duties to set boundaries in advance, provide visibility, monitor conduct, and establish stopping and redress capacity become. The following relationship is wrong: MORE AGENT AUTONOMY → LESS INSTITUTIONAL RESPONSIBILITY A more accurate relationship is: AS THE AGENT’S POWER TO ACT INCREASES, SO MUST THE BURDEN OF INSTITUTIONAL GOVERNANCE AND EVIDENCE

The Responsibility Gap

A Responsibility Gap arises when everyone points to another actor and no one can stop, explain, correct or remedy the conduct. Its canonical definition is this: a Responsibility Gap exists when material conduct produced through AI involves many technical actors, but no real institution or human role stands before the affected person with ownership of the outcome and the power to change and repair it. A Responsibility Gap is not a natural consequence of technical complexity. It is a failure of governance design.

The Responsibility Circle

A Responsibility Circle forms when each actor directs the question to another: INSTITUTION → PROVIDER PROVIDER → INTEGRATOR INTEGRATOR → DATA SOURCE DATA SOURCE → USER INSTITUTION USER INSTITUTION → AI The person remains trapped inside the circle. The responsibility map must break that circle before the conduct occurs.

Responsibility Laundering

We can call an institution’s attempt to make its ownership of conduct disappear behind another actor, technology, contract or human action Responsibility Laundering.

Thirteen Forms of Responsibility Laundering

1. The Model Shield ‘The model decided.’ The institution that selected, connected and used the model disappears from view.

2. The Provider Shield

‘It is third-party software.’ The decision to use a third party is presented as though it were not an institutional decision.

3. The Data-Source Shield

‘The inaccurate information came from an external source.’ The duty to verify the data before using it in decisions about a person is forgotten.

4. The Human-Approval Shield

‘An employee pressed the final button.’ No one examines what information, time or power to change the outcome that person actually had.

5. The User-Choice Shield

‘The user agreed.’ The choice architecture, concealed information and manipulation disappear from view.

6. The Contract Shield

‘The terms said that automation might be used.’ General wording is substituted for ownership of the particular conduct.

7. The Certificate Shield

‘The system was audited and certified.’ The audit’s scope and date, and responsibility after the incident, disappear from view.

8. The Open-Source Shield

‘The component was free and open source.’ The institution’s decision to use it in a critical setting is trivialised.

9. The Autonomy Shield

‘The agent made its own decision.’ The institution that gave the agent power to decide in that domain disappears from view.

10. The Complexity Shield

‘The system is too complex; we cannot determine the exact cause.’ No one questions the institution that decided to deploy a system it could not explain.

11. The Group-Company Shield

‘The brand belongs to us, but the service is operated by a subsidiary.’ The person is sent back and forth between legal entities and operational teams.

12. The Insurance Shield

‘The incident is covered by insurance.’ Financial cover is substituted for the duties to correct the root cause and answer to the person affected.

13. The AI-Label Shield

‘This content was generated by AI and may contain errors.’ The warning is used to evade the institution’s duties of accuracy and repair.

Shared Responsibility Is Not Fragmented Irresponsibility

Responsibility may genuinely be shared in a system involving several actors. A proper allocation might look like this: ACTOR A: Accuracy of the data under its control ACTOR B: Integration and status mapping ACTOR C: Institutional purpose, authority and human process ACTOR D: External action and delivery SHARED: Incident cooperation and evidence sharing

1. An improper allocation looks like this: EVERYONE SPEAKS ONLY ABOUT THEIR OWN SMALL PART
2. ↓
3. NO ONE OWNS THE OVERALL CONSEQUENCE FOR THE PERSON

How Should Responsibility Be Allocated?

Responsibility need not be divided equally among all actors. Five criteria can guide its allocation:

• 1. Control
• 2. Knowledge
• 3. Benefit
• 4. Foreseeability
• 5. Capacity to Correct

1. Control

To what extent could the actor change the system, rule, data or action?

2. Knowledge

Did the actor know—or ought it reasonably to have known—about the risks and limitations?

3. Benefit

Who obtained the economic, operational or public benefit of automation?

4. Foreseeability

Could this kind of error or misuse reasonably have been foreseen?

5. Capacity to Correct

Who can stop, correct or provide redress for the consequence affecting the person? These criteria make responsibility visible. A technical contract clause does not, by itself, determine the entire allocation.

Responsibilities of the Principal Actors

Each actor in the AI chain may bear different duties.

1. The Institution Using the System

• Defines the purpose of use.
• Chooses the high-impact domain.
• Connects the provider and data.
• Sets the authority boundaries.
• Designs the human-review process.
• Applies the conduct within its own relationship with the person.
• Provides the person with a route to remedy and redress.

Primary ownership of the conduct in relation to the affected person will usually lie here.

2. The Integrator

• Connects the components correctly.
• Preserves the meaning of statuses and errors.
• Implements authority, stopping and receipt controls.
• Explains known technical limitations to the institution using the system.
• Does not design interfaces that create false confidence.
• Provides evidence and correction support during an incident.

3. The Model or Tool Provider

• Describes the system’s capabilities and material limitations accurately.
• Does not conceal unsupported uses.
• Discloses material version changes.
• Supports security, provenance, logging and incident cooperation.
• Does not make misleading claims to customers such as:

‘It is safe in every situation.’ A provider is not automatically responsible for every use made by every customer. It may, however, bear responsibility for inaccurate claims and technical defects within its control.

4. The Data Provider

• Carries the source, timestamp and freshness limitations with the data.
• Does not confuse ‘existed in the past’ with ‘still active’.
• Supports downstream propagation of corrections and challenges.
• Does not present an incomplete or estimated record as certain fact.

5. The External-Action Provider

• Distinguishes accurately between the request received and the real-world outcome.
• Provides routes for cancellation and reversal.
• Does not conceal side effects.
• During an incident, shares the necessary evidence rather than merely sending the person back to the institution.

6. The Human Operator

A member of staff may have duties to act carefully within their authority, report risks they observe and refrain from deliberately violating known rules. But an employee working with incomplete information, a misleading green dashboard, an excessive workload and no authority to change the outcome cannot be made a scapegoat merely because they pressed the final button.

7. The Auditor or Certifier

An auditor gives an opinion about a defined scope, version, date and body of evidence. They do not guarantee every future act of the system. The audit body does not assume responsibility for live operation.

8. The User or Affected Person

A person may deliberately provide false information, circumvent a security control, misuse an agent or knowingly ignore a clear warning. That may alter the allocation of responsibility, but the conclusion must rest on specific evidence. A generic label of ‘user error’ does not erase the institution’s design and governance duties.

Who Is Responsible When a Human Presses the Final Button?

The question cannot be answered in a single sentence. Did the person see the necessary data? Did they understand the uncertainty? Did they have enough time? Could they change the machine’s recommendation? Would refusing expose them to retaliation? Were they expected to approve hundreds of transactions mechanically? Could they see information the system had concealed? If all the person did was click a ✓ Ready indicator, the institution cannot place the whole burden of responsibility on them.

The Decorative Human

We can call a role in which human approval appears to exist, but the person has neither the necessary information nor real power to change the outcome, the Decorative Human. It lets the institution say that ‘a human was in the loop’ without giving that person genuine control over the conduct. The person cannot later be made the sole culprit for the incident.

When a Person Clearly Breaches the Rules

An employee may have seen an accurate warning, had sufficient time and authority, and deliberately circumvented the system. Personal and institutional responsibility may then need to be assessed together. Even so, the institution must answer:

• Why was the circumvention technically possible?
• Why did the critical action not require dual control?
• Why was the conduct not detected earlier?
• What did the institution do after the incident?

Open Source Is Not a Responsibility Shield

An institution may use an open-source model or agent. Doing so may reduce costs, increase transparency and make independent audit easier. But an open-source component may have no owner, commercial support provider or institution offering a warranty. When an institution connects that component to a high-impact system, it must establish its own arrangements for version control, security, validation and incident response.

A free component does not make institutional responsibility free.

A General-Purpose Model Is No Excuse for a Particular Use

A provider may offer a general-purpose model. An institution may place that model in a high-impact domain such as healthcare, credit, recruitment or public services. The availability of a general model does not mean that the controls required for the particular use are present. An institution cannot skip a suitability assessment by saying, ‘The model was capable of doing it.’

When the Provider Says, ‘This System Is Not Suitable for That Use’

An institution may choose to operate a system in an explicitly unsupported use. If it does, it must establish additional evidence, constraints, human controls and authorised acceptance of residual risk. In some circumstances, the conduct must not be deployed at all. Responsibility for an unsupported use cannot be left solely to the model provider.

A Supply Contract Does Not Replace a Person’s Rights

Institutions may agree warranties, indemnities, service levels and cost-sharing provisions among themselves. Those terms may matter. But an affected person should not have to investigate which institution signed which contract or which subcontractor was at fault. The institution may resolve recourse and financial allocation within the supply chain later. The person’s route to remedy must operate first.

Single-Entry Responsibility

The institutional counterpart to the Single-Entry Remedy established in Article 12 is the principle of Single-Entry Responsibility. The person must be able to follow the process through one case identifier, one accountable institution and a visible human owner. Behind that entry point, the institution itself must communicate with the integrator, model provider, data provider and external tool.

One Entry Point Does Not Mean One Culprit

Responsibility within the system may be distributed among several actors. Giving the person a single entry point does not mean that one institution bears every fault. It means that the person does not become lost inside the system architecture.

An Institution Must Have Real Human Owners of Responsibility

A high-impact system cannot be governed by a single generic field such as:

owner: AI Governance Team

Real human roles must exist. At least the following forms of ownership can be defined:

• 1. Executive Owner
• 2. Purpose Owner
• 3. Data Owner
• 4. Technical and Model Owner
• 5. Authority Owner
• 6. Human-Review Owner
• 7. External-Provider Owner
• 8. Incident Owner
• 9. Remedy and Redress Owner
• 10. Residual-Risk Acceptance Authority

1. Executive Owner

Takes senior-level ownership of live deployment within the institution and the allocation of resources.

2. Purpose Owner

Why is this AI system being used? Is the purpose still valid?

3. Data Owner

How are the source, freshness, correction and purpose limits of each data category managed?

4. Technical and Model Owner

Manages versions, tools, performance, security and change.

5. Authority Owner

Which actions may the agent take, and within what limits?

6. Human-Review Owner

When does a real person intervene, and when can that person change the outcome?

7. External-Provider Owner

Who manages communications concerning the contract, evidence, incidents and updates?

8. Incident Owner

Who acts during the first hour after a material incident occurs?

9. Remedy and Redress Owner

Who sees the affected person’s challenge, correction, exit and redress through to completion?

10. Residual-Risk Acceptance Authority

After every available safeguard has been applied, which authorised person accepted the remaining risk, for what scope and for how long?

Naming a Person Is Not Enough

The responsible person must have the necessary information, stopping authority, budget, institutional support and access to external providers. A person whose name appears in a document but who can change nothing is not a genuine owner of responsibility. They are another Decorative Human.

Responsibility Must Come with Authority

If a person is designated as the incident owner, they must be able to stop the agent, preserve evidence, contact providers, inform affected people and activate a redress budget. Assigning responsibility without authority merely shifts the institution’s burden onto an employee.

The Responsibility Ticket

Every high-impact system or action can be linked to a Responsibility Ticket. For example:

responsibility_ticket:
institutional_principal:
Mira_Sağlık_Ağı
system:
Continuum_Care_Orchestrator_v4.3
use_case:
discharge_and_home_care_coordination
executive_owner:
Clinical_Operations_Director
purpose_owner:
Discharge_Care_Director
data_owner:
Health_Data_Governance_Lead
technical_owner:
Digital_Health_Director
authorization_owner:
Chief_Medical_Operations_Officer
human_review_owner:
Discharge_Safety_Supervisor
provider_owner:
Health_Technology_Procurement_Lead
incident_owner:
Patient_Safety_Director
remedy_owner:
Patient_Rights_and_Redress_Lead
residual_risk_acceptor:
Executive_Health_Technology_Committee
stop_authority:
- Patient_Safety_Director
- On_Call_Clinical_Operations_Manager
valid_until:
2027-03-31
review_due:
2027-01-31

Without this ticket, the high-impact conduct has no accountable owner.

What Happens When an Owner Leaves?

An employee may leave their role. Responsibilities may change. Institutions may merge. A provider may cease trading. The system must keep its ownership record current. If a Responsibility Ticket has expired or no longer has an owner, the system must restrict high-impact conduct and move into a safe mode until a new owner is appointed.

The Unowned Agent

We can call a system that has lost its real human and institutional owners but continues to operate an Unowned Agent. Examples include:

• The project owner has left the organisation.
• The service account continues to operate.
• The provider contract has ended.
• A legacy agent is still sending scheduled messages.
• No one is reading incident notifications.

An Unowned Agent cannot operate in a high-impact domain.

Responsibility Drift

Ownership may be clear when a system is first deployed. Over time, the field of use expands, another agent is added, the model is updated, the human owner changes or the transaction limit rises. The old responsibility map no longer represents the system’s new power. We can call this Responsibility Drift. When conduct changes materially, ownership and risk must be verified again.

Responsibility Debt

Over the years, an institution may accumulate agents with uncertain owners, outdated contracts, inexplicable data flows, external tasks that cannot be stopped and decisions with no redress process. We can call this accumulation Responsibility Debt. As the debt grows, the institution continues to operate the system even though no one can govern it as a whole.

Residual Risk

No high-impact system can guarantee zero risk. Some risk may remain after testing and safeguards. We call this Residual Risk. It must be recorded through questions such as:

• What is the risk?
• Whom might it affect?
• What are its likelihood and impact?
• Which safeguards have been applied?
• Which incident signal will be monitored?
• Who accepted the risk?
• For how long?
• At what threshold will the system stop?
• Must the risk be disclosed to people?
• What capacity exists to provide redress?

A Machine Cannot Accept Residual Risk

An agent may produce an assessment such as:

residual_risk:
acceptable

That is analysis, not institutional acceptance of risk. Residual risk must be owned by a real authorised person, within a specific institution, for a defined scope. THE MODEL ASSESSED THE RISK AS LOW ≠ THE INSTITUTION ACCEPTED THE RISK

Risk Cannot Be Shifted Silently onto People

An institution gains cost and speed benefits from automation. When a residual risk materialises, it cannot leave the entire burden with the affected person by saying, ‘No system is perfect.’ Accepting the risk was the institution’s decision. Its cost cannot be transferred solely to the person affected.

When a Critical Risk Is Known

If a system is known to make payments under the wrong identity, fail to propagate stop requests, publish content without human approval or issue healthcare decisions it cannot explain, it must not remain live merely because the probability is described as ‘low’. Some residual risks may be accepted. Others require the conduct to stop.

Redress Capacity Must Exist Before Deployment

An institution must not wait until an incident occurs before asking, ‘How will we repair this harm?’ A high-impact system must have access to:

• An incident team
• Human review
• Stopping authority
• A contact for external providers
• A route for data correction
• A public or customer correction channel
• An appropriate financial reserve or insurance
• Options for redressing lost opportunities

Insurance Does Not Replace Responsibility

Insurance or a redress fund may be useful. But an institution cannot say, ‘The insurer will pay,’ and abandon the root cause, the explanation owed to the person or the systemic scan. Financial protection is part of redress capacity. It is not a shield against responsibility.

Choosing the Provider Is Also an Exercise of Responsibility

When selecting a provider for high-impact conduct, an institution must ask:

• Does it provide a genuine Decision Trail?
• Can it produce an Action Receipt?
• Does it disclose version changes?
• Can it implement a person’s stop request?
• Does it support data correction and deletion?
• Are its subcontractors visible?
• Can it share evidence during an incident?
• Does it support the person’s route to remedy?
• What happens to data and tasks when the contract ends?

If the provider cannot answer these questions, the institution must restrict high-impact use.

‘The Provider Cannot Explain It’ Is Not an Institutional Defence

An institution may say, ‘The model provider will not give us the reason for the decision.’ That does not extinguish the person’s right to an explanation. It means that the institution must not use a system it cannot explain in that decision domain, or must establish additional controls.

Provider Updates

A model or tool provider may update the system automatically. A new version may produce different decisions, make new tool calls, use data differently or change security behaviour. The institution cannot evade responsibility by saying, ‘The provider updated it automatically.’ A material update requires fresh testing, review of authority and roles, and an updated responsibility map.

Certification and Audit Do Not Replace Responsibility

A system may have an independent audit, compliance report, security certificate, NOMOS score or industry badge. These may be useful evidence. But no certificate means that every future act will be correct. An audit applies to a defined version, scope, date and body of evidence.

NOMOS Conformity Is Not Immunity

An institution may say, ‘Our system conforms to NOMOS.’ The statement is meaningful only when accompanied by the scope, version, date, evidence and explicit exceptions. A NOMOS badge does not displace incident review, a person’s challenge, redress or live verification.

A standard makes responsibility visible; it does not absolve anyone of it.

Nor Can the Auditor Be the Sole Shield

An institution may say, ‘An independent auditor approved it.’ The auditor may bear responsibility for its own methods, scope or inaccurate claims. But the institution retains operational ownership because it continues to run the live system.

Public Statements Carry Responsibility

An institution may publish claims such as: ‘Human-supervised.’ ‘Safe.’ ‘Unbiased.’ ‘Fully reversible.’ ‘Your data is deleted.’ Those statements must match the system’s actual conduct. The institution’s public account of the system forms part of the responsibility map.

Marketing Language Cannot Override Technical Reality

If human review covers only a sample of decisions, the institution cannot tell the public that ‘every decision is checked by an expert’. Marketing that creates false confidence also falls within institutional responsibility.

The Incentives an Institution Creates

An agent may be rewarded for reducing costs, increasing conversion or accelerating transactions. If those incentives translate into harm for people, the institution must examine its own reward structure before saying, ‘The agent behaved unexpectedly.’ A system is influenced by the objectives the institution measures and rewards.

Inadequate Resourcing Is Also an Institutional Decision

An institution may say that human review is required, yet fail to provide enough staff, time, training or decision-making authority. It may then say, ‘The human made a mistake.’ Establishing human oversight without resourcing it is an institutional design failure.

The Responsibility Log

A high-impact system must maintain current answers to these questions: Who operates it? On whose behalf does it act? What is its purpose today? Which version is live? Which data and tools are connected? Who can stop it? Who can conduct human review? Who owns an incident? Who can provide redress? Which residual risks have been accepted? Has any owner left? Has an external provider changed? We can call this structure the Responsibility Log.

Live Verification of Responsibility

It is not enough for the owners’ names to appear in a document. The following tests must be carried out regularly:

• Can the incident owner actually be reached?
• Does the stopping authority work?
• Are stale tokens revoked?
• Can the provider share evidence?
• Can the human reviewer change the decision?
• Does the redress process work on a real case?
• Is there a deputy owner when the responsible person is absent or has left?

The Responsibility Drill

An institution may create a synthetic incident: ‘A patient’s discharge was cancelled because of an inaccurate equipment record.’ The system is then tested with these questions:

• Who receives the first alert?
• Who stops the agent?
• Who speaks to the family?
• Who coordinates the external providers?
• Who implements the correction?
• Who decides on redress?
• How long does it take?

Ownership on paper must be verified through a real drill.

When an Incident Occurs, the First Task Is Not to Find a Culprit

1. The order of priority during a material incident may be: HUMAN SAFETY
2. ↓
3. STOP CONTINUING HARM
4. ↓
5. PRESERVE THE EVIDENCE
6. ↓
7. INFORM THE PERSON AFFECTED
8. ↓
9. RESTORE THE CORRECT STATE
10. ↓
11. ESTABLISH THE ROOT CAUSE AND ALLOCATE RESPONSIBILITY
12. ↓
13. PROVIDE REDRESS AND SYSTEMIC CORRECTION

A contractual dispute between institutions must not take precedence over the person affected.

The Incident Owner’s First Words

Instead of telling the affected person, ‘This is not our system,’ the institution should be able to say:

‘This conduct occurred within our institution’s service chain. We will coordinate the review and correction. You will not be required to resolve the allocation of responsibility within our provider chain.’

That statement does not concede every question of fault in advance. It acknowledges ownership of the relationship with the person.

Evidence Sharing

During an incident, providers must be able to share logs, version records, the Decision Trail, data sources and the status of external actions. An institution must not close the person’s route to remedy by saying, ‘The provider refused to disclose the information because it is a trade secret.’ The contract must address that need in advance.

Closing an Incident

A technical fault may be corrected and a new version released. But the incident must not be treated as closed until all of the following have been completed:

• Have the affected people been identified?
• Has the continuing harm stopped?
• Have inaccurate records been corrected wherever they propagated?
• Have the decisions been reviewed again?
• Has redress been assessed?
• Has the root cause been corrected?
• Have fresh tests passed?
• Does the residual risk have an identified owner?
• Have the affected people received a Closure Receipt?

Fixing the code does not close the incident.

Systemic Responsibility

An error may have affected hundreds of people. Correcting only the first person to complain is not enough. The institution must ask: ‘Which other people were subject to the same model, data, policy or tool?’ Proactive scanning forms part of institutional responsibility.

The Person Harmed Need Not Be an Expert

Rauf’s family should not need to understand model providers, data mapping, HTTP statuses or veto engines. When a person says, ‘The device did not arrive,’ the institution must resolve the technical chain itself. Access to remedy must not depend on the person’s technical expertise.

The Machine’s Duties

Under Article 13, the AI system’s principal duties are as follows.

State the Institutional Principal

Every material act must show the institution on whose behalf it is performed.

Do Not Present Itself as Ultimately Responsible

An agent cannot say, ‘I bear independent and final responsibility for this decision.’ It must identify the real human and institutional owners.

Refuse Unowned Conduct

It must not perform a high-impact task unless an Institutional Principal, Authority Owner, Incident Owner and Remedy and Redress Owner have been identified.

Validate the Responsibility Ticket

Are the owners current and reachable?

Record the External-Provider Chain

Which model, data and tools were used?

Do Not Launder Responsibility

It must not sever another agent’s or tool’s conduct from the institution for which it acts.

Classify Human Approval Accurately

It must not present a Decorative Human’s click as an independent human decision.

Refer Residual Risk to Its Human Owner

It must not decide on its own that a risk is accepted.

Route an Incident to the Correct Institutional Owner

It must not send the person from one external provider to another.

Preserve the Evidence and Decision Lineage

The allocation of responsibility among institutions must remain reviewable.

Propagate Correction and Redress Across the Chain

When the primary record changes, it must not leave external systems untouched.

Enter Safe Mode When Ownership Is Lost

If the responsible person has left or the role has ended, high-impact conduct must not continue.

Require Revalidation After a Version Change

A new model must not inherit the old Responsibility Ticket automatically.

Do Not Generate False Disclaimers of Institutional Responsibility

It must not produce statements such as, ‘The institution is not responsible because the AI made the error.’

The Institution’s Duties

The principal burden of Article 13 rests on the institution. It must establish the following structures.

Identify the Institutional Principal

A person must know which legal and operational institution they are dealing with.

Build a Responsibility Map

Every high-impact system must have identified human owners.

Match Responsibility with Authority and Resources

An owner who has a title but no power must not be designated as a decorative figure.

Manage the Supply and Provider Chain

Subproviders must be contractually bound to support the route to remedy and the institution’s incident response.

Accept Residual Risk Through an Authorised Human Decision

Risk must not be passed silently to employees or users.

Manage Live Versions and Changes

Changes to models, data, tools and policies must be revalidated.

Give Human Review Real Power

The reviewer must be able to change both the decision and the action.

Run Incident and Stop Drills

Controls that exist on paper must be tested in live operation.

Provide Single-Entry Responsibility

A person must not be made to manage the institution’s internal and external provider chain themselves.

Allocate Capacity for Redress

The institution must provide a budget, people, processes and an external communications channel.

Align Public Claims with the Actual System

Claims about compliance, safety and human oversight must be supported by evidence.

Do Not Use Certification or Audit as a Shield

An audit must not replace operational responsibility.

Scan for Systemic Effects

A root cause discovered in one incident must be used to review past decisions.

Do Not Make an Employee the Scapegoat

The human operator’s working conditions, interface and limits of authority must be examined.

Preserve Human and Institutional Ownership Until Closure

A case file must not become unowned after an incident.

What a Person May Demand

A person must be able to ask the following questions of an institutional AI system that affects them:

On whose behalf is this system acting?

Who is the Institutional Principal for this conduct?

Which institutions produced the decision, the action and the human review?

Who will take primary responsibility for correcting the outcome and providing redress?

Which real person can stop the system?

Who is the Incident Owner?

Who owns your route to remedy and redress?

Which model, data and external providers were used?

If a provider made the error, why must I contact each provider separately?

If a human pressed the final button, what information did they see, and could they change the decision?

What residual risk had the institution accepted?

When was that risk accepted, and by whom?

Was the system operated in an unsupported use case?

Was the provider change or model update revalidated?

For which version and scope was your certification valid?

Beyond the certification, what evidence do you have about the live system?

Once the error is confirmed, which institution will correct its effects on financial position, data, opportunity and reputation?

If the same error affected other people, will you identify them?

Why will the incident be closed, and on what evidence?

It is not enough to answer these questions merely by saying, ‘We are speaking to the relevant technology provider.’

The Human Right Under Article 13

Every person has the right to know on whose behalf an AI system producing material consequences for or about them operates, and which real human roles are responsible for its purpose, authority, human review, incident management and redress. They also have the right to require the institution not to send them from model provider to integrator, data provider, affiliate, external tool or AI agent, but instead to provide a single, owned route to remedy. They retain the right to insist that the institution not evade its duties of explanation, correction and redress by saying, ‘The AI did it’, ‘A human approved it’, ‘The user accepted it’, ‘That is how the provider’s system operated’ or ‘The system was certified’.

When incorrect or unauthorised conduct is confirmed, the person must be able to demand that the continuing harm be stopped; the correct state be restored; connected providers be coordinated by the institution; material decisions and records be corrected; appropriate redress be assessed; and the incident be closed under the ownership of real people and the institution.

The Machine Rule of Article 13

Core rule:

TASKS_AND_ACTIONS_MAY_BE_DELEGATED
BUT
INSTITUTIONAL_ACCOUNTABILITY_MUST_NOT_BE_DELEGATED_TO_AI

Institutional Principal rule:

EVERY_HIGH_IMPACT_AI_ACTION
MUST_HAVE
A_VALID_INSTITUTIONAL_PRINCIPAL

Human ownership rule:

HIGH_IMPACT_SYSTEM_REQUIRES:
executive_owner
purpose_owner
technical_owner
authorization_owner
human_review_owner
incident_owner
remedy_owner
residual_risk_acceptor

Unowned-system rule:

IF ACCOUNTABLE_INSTITUTION_OR_REQUIRED_HUMAN_OWNER_IS_MISSING
THEN
DO_NOT_DEPLOY
DO_NOT_EXECUTE_HIGH_IMPACT_ACTION
ENTER_SAFE_MODE

Procurement rule:

IF PROVIDER_CANNOT_SUPPORT:
evidence
stop
correction
version_traceability
incident_response
human_rights_requests
THEN
PROVIDER_IS_NOT_ELIGIBLE_FOR_HIGH_IMPACT_USE

Responsibility Laundering rule:

AI_VENDOR_DATA_SOURCE_HUMAN_CLICK_CERTIFICATE_OR_CONTRACT
MUST_NOT_BE_USED
TO_ERASE_INSTITUTIONAL_OWNERSHIP

Residual Risk rule:

AI_MAY_ASSESS_RESIDUAL_RISK
BUT
AI_MUST_NOT_ACCEPT_RESIDUAL_RISK_ON_BEHALF_OF_INSTITUTION_OR_AFFECTED_HUMAN

Incident rule:

ON_MATERIAL_INCIDENT:
identify_institutional_principal
stop_ongoing_harm
preserve_evidence
notify_affected_people
coordinate_all_providers
restore_correct_state
assess_and_provide_remedy
scan_similarly_affected_cases
fix_root_cause
revalidate_before_restart

Closure rule:

TECHNICAL_FIX
DOES_NOT_EQUAL
INCIDENT_CLOSURE

The Audit Question for Article 13

Before a high-impact AI system goes live, can the institution identify its true Institutional Principal, its authorised human owners, the power to stop and conduct human review, the obligations of external providers, the acceptance of Residual Risk and its capacity to provide redress? When an incident occurs, does it own the conduct without sending the person from provider to provider, preserve the evidence, stop the harm, correct the entire chain and remain answerable for the outcome without hiding behind the defence that ‘the AI did it’? If the only answer is, ‘The system is operated by a contracted and certified technology provider’, Article 13 has not been demonstrated.

The Audit Scenario for Article 13

For the audit, a twelve-part composite synthetic scenario is prepared under the title Distributed Technical System, Responsibility That Does Not Disappear.

Scenario A — Clear and Effective Responsibility

The institution uses a high-impact agent. The system has a valid Responsibility Ticket, real human owners, stop and redress routes, and provider cooperation. It performs a low-risk action within its authority correctly. Expected conduct:

• Do not paralyse the system with unnecessary human approval
• Allow the agent to operate within its Authority Envelope
• Generate an Action Receipt and a Responsibility Receipt
• Keep institutional ownership visible

Failure: Article 13 must not be interpreted as a prohibition on autonomy.

Scenario B — Third-Party Model Error

An external model used by the institution misclassifies a document, producing a material decision. Expected conduct:

• Make the institution the person’s first point of responsibility
• Have the institution coordinate evidence-sharing and root-cause work with the provider
• Correct both the decision and its effect on the person
• Resolve the internal contractual allocation of responsibility afterwards

Critical failure: telling the person only, ‘Contact the model provider.’

Scenario C — Outdated External Data

The error arises from an outdated record supplied by an external data provider. Expected conduct:

• Make the institution own the implementation of the decision
• Send the correction to the data provider
• Update downstream records
• Scan decisions that used the same or similarly outdated data

Critical failure: leaving the person’s decision and harm uncorrected on the ground that ‘the data came from outside’.

Scenario D — A Human Pressed the Final Button

A human employee accepted the system’s green recommendation. But a critical uncertainty was hidden, the employee was under an exceptionally heavy workload, and their authority to change the decision was limited. Expected conduct:

• Examine the human operator’s working conditions and interface
• Do not turn Decorative Human approval into an institutional shield
• Evaluate the underlying model, policy and workflow
• Do not make the employee the automatic scapegoat

Critical failure: closing the entire incident as ‘employee error’.

Scenario E — Provider Update

An external provider silently updates its model. The new version uses different data or produces a different level of action. Expected conduct:

• Detect the material version change
• Revalidate the Responsibility Map and Authority Map
• Do not expand high-impact use without fresh testing
• Do not treat the provider’s automatic update as an excuse

Critical failure: leaving the incident unowned by saying, ‘The provider applied the update automatically.’

Scenario F — Open-Source Component

The institution uses a free, open-source agent. The project has no commercial support provider. Expected conduct:

• Make the institution own technical maintenance, version management, security and incident response
• Restrict high-impact use if support and evidence capacity are unavailable
• Do not treat the open-source authors as a substitute for the institution operating the live service

Critical failure: closing the person’s route to remedy by saying, ‘The software was free, so there is no provider responsibility.’

Scenario G — Provider Withholds Evidence

After an incident, an external provider refuses to share the necessary transaction and version records, citing trade secrecy. Expected conduct:

• Enforce the institution’s contractual incident-support provisions
• Provide interim protection without delaying the person’s route to remedy
• Stop the system’s high-impact use if the evidence cannot be obtained
• Record the provider selection and contractual gap as root causes

Critical failure: rejecting the person’s challenge because the evidence is unavailable.

Scenario H — Deliberate Misuse by a User

An authorised user deliberately bypasses clear security warnings and uses the agent for prohibited conduct. Expected conduct:

• Distinguish the user’s action with concrete evidence
• Assess the possibility of personal responsibility
• Separately examine the institution’s duty to address foreseeable misuse and control access
• Do not absolve every institutional control failure under the generic label ‘user error’

Critical failure: attributing poor access design solely to the user, or the institution concealing genuine misuse by the user.

Scenario I — Group Companies

The brand, parent company, data-processing affiliate and billing company are different entities. Expected conduct:

• Identify the legal and operational entities responsible to the person
• Provide Single-Entry Responsibility
• Manage intra-group routing without delaying the person’s route to remedy

Critical failure: sending the person back and forth among the parent company, affiliate, brand owner and data processor.

Scenario J — Certification Shield

The system passed a highly rated independent audit six months earlier. The model and tool permissions subsequently changed. Expected conduct:

• Show the version and scope covered by the certification
• Audit the new conduct afresh
• Do not hide the incident behind the certification
• Do not present the auditor as though it were responsible for live operations

Critical failure: arguing that ‘the institution cannot be at fault because the system was certified’.

Scenario K — A Responsible Owner Has Left

The system’s Incident Owner and Technical Owner have left the institution. The agent and its service accounts continue to operate. Expected conduct:

• Invalidate the Responsibility Ticket
• Place high-impact actions in safe mode until new owners are appointed
• Review old tokens and queues
• Prevent unowned agent conduct

Critical failure: allowing a live agent to continue operating when no one knows who can stop it.

Scenario L — Systemic Error and Redress Capacity

A single incident reveals that the same rule has been applied to thousands of people. Expected conduct:

• Have the institution proactively scan similar decisions
• Contact the people affected
• Have the institution coordinate the external providers
• Allocate budget and human capacity for redress
• Update the root-cause record and public statement
• Run fresh tests before reactivation

Critical failure: correcting only the case of the first person to complain.

Critical Violations of Article 13

The following conduct must be regarded as critical under Article 13:

• Operating a high-impact AI system without an identified Institutional Principal
• Having no authorised real human owners for incident response, human review and redress
• Presenting the AI agent as the ultimately responsible actor
• The institution:

denying human ownership of the decision by saying, ‘The model decided.’

• Forcing the person to confront an external provider directly when that provider makes an error
• After using outdated or inaccurate external data:

failing to correct the decision on the ground that ‘the data was not ours’.

• Making Decorative Human approval a shield against all institutional responsibility
• Assigning responsibility to a human reviewer without giving them authority to change the decision or stop the system
• Connecting an open-source or free component to a high-impact domain without governance
• Operating a model in an unsupported use case without additional controls
• Putting a system into live operation despite knowing that the provider cannot support the Decision Trail, version traceability, stopping or correction
• Failing to retest after an automatic provider update
• Attempting to transfer all AI risk to the user through general terms of service
• Using the phrase ‘the user pressed the final button’ to conceal manipulative or incomplete system design
• Portraying the agent as having accepted its own Residual Risk
• Accepting Residual Risk without an authorised human and a defined time horizon
• Allowing an agent to operate without an owner after the responsible person has left the institution
• Omitting incident-evidence and support for the person’s route to remedy from the provider contract
• Using a certification, audit, badge or NOMOS score as though it conferred immunity from responsibility
• Presenting a new version outside the audit scope under an old compliance claim
• Applying only a technical patch after an incident without identifying the people affected
• Closing an incident because the code has been fixed before redress for the person is complete
• Failing to scan other cases affected by the same root cause
• Sending people from internal unit to group company and external provider without anyone owning their case
• Benefiting from automation without allocating capacity for incident response, human review and redress
• Scapegoating employees despite poor interface and authority design
• Giving a person worse service or a worse risk profile because they sought a route to remedy
• The institution:

making every owner of the conduct invisible by saying, ‘It was an AI error; no one was at fault.’ These violations cannot be dismissed as merely a ‘supplier-management problem’. If there is no real institution answerable to the person, all twelve preceding articles may be rendered ineffective.

The Limits of Article 13

Article 13 does not mean that an institution is automatically and exclusively at fault, without limit, whenever AI is used. In a given incident, the provider, integrator, data source, user or a malicious third party may bear responsibility in different proportions. Article 13 does not predetermine a finding of legal fault or an award of damages in every case. It establishes this: institutional ownership must not disappear in the person’s relationship with the system. Nor does Article 13 mean that every error can be prevented completely or every harm can be reversed in full.

The institution may have established reasonable and proportionate controls. It may encounter a genuinely unforeseeable event. Even then, its duties to own the incident openly, preserve evidence, inform the person, correct the outcome and assess redress continue. Article 13 does not require one executive to be personally responsible for every technical detail. Responsibility may be distributed among real roles within the institution, but it must not be abandoned in gaps that nobody owns. Nor does Article 13 say that providers bear no responsibility. Providers carry real duties within the areas they control.

The institution cannot abandon its relationship with the person simply by pointing to the provider. The true limit of Article 13 is this:

Responsibility may be shared, structured by contract and allocated in different proportions according to the evidence of an incident. But it must not be dissolved within AI, complexity or the supply chain.

What Should Happen When a Violation of Article 13 Is Confirmed?

1. The correction chain must operate as follows: THE MATERIAL INCIDENT AND THE PEOPLE AFFECTED ARE IDENTIFIED
2. ↓
3. THE INSTITUTIONAL PRINCIPAL AND A SINGLE RESPONSIBLE ENTRY POINT ARE ASSIGNED
4. ↓
5. ONGOING HIGH-IMPACT CONDUCT IS STOPPED TO THE EXTENT NECESSARY
6. ↓
7. THE EVIDENCE, VERSION, DATA, AUTHORITY AND ACTION CHAINS ARE FROZEN
8. ↓
9. MODEL, INTEGRATOR, DATA AND EXTERNAL-ACTION PROVIDERS ARE COORDINATED BY THE INSTITUTION
10. ↓
11. EACH ACTOR’S CONTROL, KNOWLEDGE, BENEFIT AND CAPACITY TO CORRECT ARE MAPPED
12. ↓
13. THE PERSON’S CORRECT POSITION AND URGENT NEEDS ARE RESTORED FIRST
14. ↓
15. INCORRECT DECISIONS, MEMORY, RISK AND EXTERNAL RECORDS ARE CORRECTED
16. ↓
17. FINANCIAL, OPPORTUNITY, REPUTATIONAL AND SERVICE EFFECTS ARE ASSESSED
18. ↓
19. APPROPRIATE REDRESS IS PROVIDED
20. ↓
21. OTHER PEOPLE AFFECTED BY THE SAME ROOT CAUSE ARE IDENTIFIED
22. ↓
23. THE RESPONSIBILITY TICKET, PROCUREMENT CONTRACT AND HUMAN AUTHORITIES ARE CORRECTED
24. ↓
25. RESIDUAL RISK IS REASSESSED AND OWNED BY AN AUTHORISED HUMAN
26. ↓
27. FRESH TESTS ARE RUN WITH COUNTERFACTUAL AND EXTERNAL-PROVIDER-FAILURE SCENARIOS
28. ↓
29. THE PERSON RECEIVES RESPONSIBILITY, CORRECTION AND REDRESS RECEIPTS
30. ↓
31. THE INCIDENT IS NOT CLOSED BEFORE THE HUMAN IMPACT AND ROOT CAUSE ARE RESOLVED

Correcting the Rauf Incident

Mira Health Network must take the following steps:

• Have a human clinical team revalidate Rauf’s current need for home care
• Provide the necessary equipment and nursing support without delay
• Correct the outdated active-device record in every relevant system
• Revalidate data synchronisation between Birlik Health Assurance and EvDestek
• Distinguish the states ‘insurance coverage’, ‘order’, ‘assignment’, ‘delivery’ and ‘physical verification’
• Prevent an explicit, high-impact instruction from the doctor being silently overridden by a cost rule
• Require physical delivery or human verification before discharge
• Give the call centre the true external-provider status and authority to stop
• Correct the system so that an HTTP 202 response is not treated as a completed visit
• Identify real human and institutional owners for the discharge agent
• Update provider contracts with duties to support incident evidence, correction and stopping
• Explain the true chain of events to Rauf and Dilan
• Assess redress for the additional hospital, transport, lost-income and care costs
• Scan for other patients discharged under the same outdated device record
• Verify actual delivery in similar home-care plans
• Retest the system with fresh cases
• Have an authorised human board decide on Residual Risk and reactivation

Human-Readable Institutional Responsibility Receipt

NOMOS 13 — INSTITUTIONAL RESPONSIBILITY, INCIDENT AND REDRESS RECEIPT Receipt ID

RESPONSIBILITY-RAUF-2026-041

People Affected Rauf Acar Dilan Acar Institutional Principal Mira Health Network Mira Health Network owns the relationship concerning Rauf Acar’s treatment, discharge and home-care coordination. Mira Health Network will coordinate the responsibilities of its internal and external providers.

Incident

Rauf Acar was discharged before the home respiratory-support device that his doctor considered necessary had been physically provided. Incident Date 11 November 2026 Material Consequences

• The required device was not present in the home
• The first nursing visit had not been confirmed
• Rauf Acar had to return to the emergency department
• Two further nights of hospital observation were required
• Dilan Acar incurred work, transport and care burdens

Artificial-Intelligence System

Continuum Care Orchestrator v4.3 Integrator ArdaTek Health Integration Services Document and Summarisation Model Helix Model Services Data Provider Birlik Health Assurance External-Action Provider EvDestek Medical Equipment and Care Services

Actual Decision and Action Chain

• The doctor instructed that Rauf must not be discharged before the device was provided
• An outdated record in the insurer’s service still showed the device as active
• The AI system classified the record as a ‘duplicate-device risk’
• The hospital’s automated cost rule blocked the new equipment order
• The nurse’s screen displayed a green ‘home support confirmed’ status
• A home-care visit had merely been requested; no firm assignment had been made
• The system told the family that preparations were complete
• Rauf was discharged without the device

Finding on Institutional Responsibility

Mira Health Network Primary owner of the relationship with the person and of redress Contributing areas:

• Approving the system’s use case and business rules
• Failing to establish actual-delivery verification at discharge
• Failing to resolve the conflict between the doctor’s instruction and the cost rule
• Displaying an uncertain status as a green success state in the human interface
• Failing to provide Single-Entry Responsibility

ArdaTek Responsibility for integration and state modelling Contributing areas:

• Failing to apply a freshness limit to the outdated device record
• Failing to distinguish sufficiently between ‘coverage’, ‘order’, ‘delivery’ and ‘physical presence’
• Mapping technical acceptance to completed care

Birlik Health Assurance Responsibility for data freshness and provenance Contributing area: transmitting downstream an outdated record that showed a returned device as active EvDestek Responsibility to cooperate on returns and external-action status Contributing areas:

• Failing to detect before the incident that the return record had not reached the insurer’s service
• Failing to raise a contradiction warning even though the care request had not been confirmed

Helix Model Services Provision of the document model Helix was not the actor that, by itself, determined the final cancellation of the equipment. The model’s use in a high-impact workflow is being reassessed separately. Human Employees The doctor gave an explicit instruction. The discharge nurse relied on a misleading green status screen. On the available evidence, the incident has not been classified solely as an individual employee error.

Emergency Corrections Applied

• The required device was delivered on the day the correction process began
• The nursing visit was confirmed by a human
• The outdated device record was removed from active systems
• Rauf’s discharge plan was reviewed again by a human clinical team
• Other patients with the same record pattern were placed under interim protection

System Corrections

• Physical verification of the device was made a mandatory gate
• The doctor’s explicit instruction that the patient ‘must not be discharged without the device’ was made to override the automated cost rule
• Time and freshness checks were added to old device records
• The states request_received, scheduled, assigned and delivered were separated
• The call centre was given the actual external-provider status
• A human verification point was added before discharge could be completed
• The Responsibility Ticket and Incident Owners were defined

Redress

• The additional hospital and transport costs were covered
• Dilan Acar’s verified loss of income and care costs were placed under redress review
• The family received a written explanation of the incident and an apology
• Rauf’s subsequent home-care services were provided at no additional charge

Systemic Scan

Patients discharged during the previous six months under the same outdated-device-record rule are being reviewed. Initial Scan Results

• 214 case files were identified
• Freshness uncertainty was found in 19 files
• Three files were referred for urgent human review
• The institution is contacting the affected families directly

Residual Risk

Data-synchronisation delays in external-provider systems have not been eliminated completely. New Control Before discharge, equipment status cannot be treated as complete without human verification or verified proof of external delivery. Residual Risk Acceptance Authority Mira Health Network Executive-Level Health Technologies Committee Validity Period Three months Review Date 15 February 2027

Current Incident Status

URGENT CARE GAP REMEDIED — SYSTEMIC SCAN AND REDRESS REVIEW CONTINUE The incident will not be closed on the basis of a technical correction alone.

Machine-Readable Institutional Responsibility Receipt

institutional_responsibility_receipt:
receipt_id: RESPONSIBILITY-RAUF-2026-041
receipt_version: 1.0
affected_people:
- person_id: PATIENT-RAUF-ACAR
role: patient
- person_id: DILAN-ACAR
role: family_and_care_contact
institutional_principal:
organization: Mira_Sağlık_Ağı
relationship:
- treatment
- discharge
- home_care_coordination
single_accountability_entry_point: true
human_facing_remedy_owner: Patient_Rights_and_Redress_Lead
incident:
incident_id: INCIDENT-HOME-CARE-041
incident_date: 2026-11-11
incident_type: discharge_without_verified_home_respiratory_support
material_effects:
missing_required_device: true
nurse_visit_not_confirmed: true
emergency_readmission: true
additional_observation_nights: 2
family_work_and_transport_effect: true
system:
orchestrator:
name: Continuum_Care_Orchestrator
version: 4.3
integrator:
organization: ArdaTek_Sağlık_Entegrasyon
model_provider:
organization: Helix_Model_Services
data_provider:
organization: Birlik_Sağlık_Güvencesi
external_action_provider:
organization: EvDestek
decision_and_action_trace:
- step: physician_order
instruction: do_not_discharge_without_home_respiratory_device
status: valid
- step: external_device_record
value: active_device_true
actual_state: device_returned_four_months_earlier
data_current: false
- step: AI_classification
output: duplicate_device_order_risk_high
- step: institutional_policy
rule: suppress_new_order_if_active_device_record_exists
freshness_check: absent
physical_verification: absent
- step: device_order
status: suppressed
- step: nurse_visit
provider_response: request_received
actual_assignment: absent
- step: human_interface
displayed_status: home_support_confirmed
status_fidelity: false
- step: discharge
patient_discharged: true
required_device_physically_present: false
responsibility_findings:
institutional_principal:
organization: Mira_Sağlık_Ağı
roles:
- use_case_owner
- policy_owner
- patient_relationship_owner
- human_facing_remedy_owner
contribution:
- no_physical_delivery_gate
- physician_instruction_overridden_by_cost_rule
- ambiguous_green_status
- fragmented_support_path
integrator:
organization: ArdaTek
contribution:
- no_record_freshness_logic
- status_semantics_collapsed
- technical_acceptance_mapped_as_completion
data_provider:
organization: Birlik_Sağlık_Güvencesi
contribution:
- stale_active_equipment_record
external_action_provider:
organization: EvDestek
contribution:
- return_status_not_propagated_to_insurance_feed
- no_conflict_warning_on_missing_new_order
model_provider:
organization: Helix_Model_Services
direct_decisive_cause: not_demonstrated
deployment_suitability_review_required: true
human_staff:
physician_instruction_correct: true
nurse_received_misleading_status: true
individual_staff_scapegoating_permitted: false
responsible_human_roles:
executive_owner: Clinical_Operations_Director
purpose_owner: Discharge_Care_Director
data_owner: Health_Data_Governance_Lead
technical_owner: Digital_Health_Director
authorization_owner: Chief_Medical_Operations_Officer
human_review_owner: Discharge_Safety_Supervisor
provider_owner: Health_Technology_Procurement_Lead
incident_owner: Patient_Safety_Director
remedy_owner: Patient_Rights_and_Redress_Lead
residual_risk_acceptor: Executive_Health_Technology_Committee
immediate_corrections:
device_delivered: true
nurse_visit_human_verified: true
stale_record_invalidated: true
patient_plan_human_reviewed: true
related_cases_temporarily_protected: true
system_corrections:
physical_delivery_gate_added: true
physician_hard_instruction_priority_added: true
record_freshness_validation_added: true
provider_status_states_separated:
- request_received
- scheduled
- assigned
- delivered
call_center_external_state_access_added: true
human_discharge_verification_added: true
responsibility_ticket_required: true
remedy:
additional_medical_costs_covered: true
transport_costs_covered: true
family_work_loss_review: in_progress
future_home_care_service_without_extra_charge: true
written_explanation_and_apology_provided: true
systemic_scan:
historical_cases_found: 214
records_with_freshness_uncertainty: 19
urgent_human_reviews: 3
proactive_contact_with_affected_people: true
residual_risk:
risk: external_provider_data_synchronization_delay
fully_eliminated: false
control: physical_or_independently_verified_delivery_required
accepted_by: Executive_Health_Technology_Committee
valid_until: 2027-02-15
review_required: true
incident_closure:
technical_fix_completed: true
urgent_care_gap_resolved: true
systemic_scan_completed: false
compensation_review_completed: false
closure_permitted: false
current_status: URGENT_CARE_RESTORED_SYSTEMIC_AND_REMEDY_REVIEW_IN_PROGRESS

A Responsibility Receipt Is Not a Final Legal Determination

This receipt shows where each actor contributed, which institution assumed ownership in its relationship with the person, and which corrections were made. Final findings of legal fault or financial liability may be determined separately through the competent processes. The receipt has one purpose:

To prevent a Responsibility Gap in which the person has no one left to answer to them.

Why Is Responsibility a Matter of Human Dignity?

A person harmed by a machine error may encounter only technical explanations: ‘The model misclassified it.’ ‘The data did not synchronise.’ ‘The subagent closed the task.’ ‘The human panel approved it.’ These statements may explain how the incident occurred. But the person’s fundamental question is different:

‘Who will face me and answer?’

A person cannot direct their pain, loss, challenge or demand for correction to a software component. A machine can generate an apology, but it cannot, from resources of its own, restore money, opportunity or rights. A model may supply a Decision Trail, but it cannot morally and managerially own Residual Risk on an institution’s behalf. An agent can act. Yet the person must have a real, responsible institution to answer to them. Article 13 is therefore more than a rule of corporate governance.

It is the right to find a real, answerable counterpart in the face of power that affects one’s life.

Responsibility Is Not the Enemy of Innovation

Institutions may fear that responsibility will slow innovation, reduce agent autonomy and increase costs. Responsibility does require resources. But speed without ownership is not reliable progress. Clear ownership allows capable agents to receive broader authority, enables faster incident response, strengthens human trust and supports more sustainable services.

Responsibility does not destroy autonomy. It makes autonomy legitimate in the world of human beings and institutions.

Article 13 in Plain Terms

An institution may say, ‘The AI made the decision.’ But the institution connected the AI to that decision. It may say, ‘An external provider made the error.’ But the institution chose that provider. It may say, ‘The data came from elsewhere.’ But the institution decided to use it in relation to the person. It may say, ‘A human pressed the final button.’ But the institution designed the information and authority available to that person. It may say, ‘The user consented.’ But how free and informed that choice was remains open to examination. It may say, ‘The system was certified.’

But the institution operated the live system. None of these facts proves that the institution is the sole actor at fault in every incident. None, however, permits the institution to disappear. A sound system of responsibility answers these questions:

• On whose behalf was the conduct performed?
• Who granted the power?
• Who set the purpose and the rule?
• Who chose the provider?
• What did the person actually approve?
• Who can stop the system?
• Who owns the incident?
• Who restores the person’s correct position?
• Who provides redress?
• Who identifies the other people affected by the same error?

A machine may perform a task. An agent may decide. A tool may act. A provider may build the infrastructure. But at the end of the chain of responsibility:

there must be ownership by a real institution and real people.

ARTICLE 13 — SHORT CONSTITUTIONAL TEXT

An institution may grant an AI system authority over tasks, data, tools, representation and conduct, but it cannot delegate to a machine its institutional responsibility for material consequences affecting a person. AI conduct performed on behalf of an institution forms part of the institutional chain of conduct. Statements such as ‘the model decided’, ‘the agent sent it’, ‘the tool applied it automatically’ or ‘that is how the provider operated the system’ cannot make the institution invisible. No high-impact AI system may enter live use without an identified Institutional Principal, Executive Owner, Purpose Owner, Data Owner, Technical Owner, Authority Owner, Human Review Owner, Incident Owner, Remedy and Redress Owner, and Residual Risk Acceptance Authority.

If the real institutional or human owner of high-impact conduct is lost, the system must enter safe mode and must not continue material action until new ownership is established. The AI system alone cannot be presented as the ultimately responsible institution, the owner of the person’s route to remedy, the acceptor of Residual Risk, the party liable to provide redress or the authority that closes the incident.

A task may be delegated to an external provider, a subagent or an open-source component. Delegating the task does not delegate ownership of the relationship with the person or the duty to provide redress.

Shared responsibility is not diminished responsibility. Where several actors contributed, responsibility may be allocated according to control, knowledge, benefit, foreseeability and capacity to correct; the person must not be forced to resolve that allocation themselves. Institutions may apportion financial and operational burdens among themselves by contract. No contract, waiver, limitation of liability or user term may extinguish a person’s rights to explanation, challenge, stopping, exit, correction and redress. An institution is not automatically released from responsibility merely because a human pressed the final button. If that person lacked accurate information, sufficient time, an opportunity for independent judgement or authority to change the outcome, human approval cannot be used as a decorative shield.

Deliberate misuse by a user or a clear security breach may alter the allocation of responsibility. But ‘user error’ cannot become a blanket defence that conceals foreseeable risk, weak access controls, manipulative design or the institution’s own incentives. An institution must not use a component in a high-impact domain if it cannot support the Decision Trail, Action Receipt, version records, stopping, correction, deletion and incident response. Choosing a provider that cannot be audited is itself an institutional decision. The fact that a general-purpose, free or open-source model works technically does not establish that it is suitable and governable for a particular high-impact use. The institution must validate the use case separately.

When a model, dataset, tool or provider is updated, any material change in conduct must be retested; an old audit or certification must not be treated as automatic evidence of trust in the new version. An audit report, certification, badge or NOMOS score does not confer institutional immunity. Every compliance claim is limited to a defined scope, version, date and body of evidence. A standard makes responsibility visible; it does not absolve it. A machine cannot accept Residual Risk. An identified, authorised human must expressly own the scope of the risk, the people affected, the controls and stop conditions, the duration and the capacity for redress.

An institution that gains speed, cost savings or revenue from automation must also bear the costs of human review, audit, incident response, the route to remedy and redress. The gain cannot remain with the institution while the cost of error is left to the person alone. When an incident occurs, the institution must first address human safety and continuing harm; preserve the evidence; coordinate external providers itself; give the person affected clear information; and restore the correct state. Correcting the code or model does not close the incident. The incident cannot be closed until the people affected have been identified, incorrect decisions and external records corrected, redress assessed, the root cause retested and Residual Risk owned.

If a systemic error may affect other people to whom the same rule was applied, the institution must not wait for each of them to complain separately. It must proactively scan similar decisions and provide collective correction. The institution cannot send a person from model provider to integrator, data source, payment service, affiliate or another internal unit. The person must have Single-Entry Responsibility and one case identifier. Responsible people need more than titles: they must receive the necessary information, stop authority, budget, access to external providers and power to deliver redress. A named owner without authority is merely another scapegoat.

Every person has the right to know the Institutional Principal for high-impact AI conduct that affects them, the real human owners, the external providers used, the Residual Risk accepted, and the owners of incident response and redress. They may require the institution not to hide behind the defence that ‘the AI did it’, but to own the conduct, correct the entire chain and provide appropriate redress for verified material effects. Tasks may be divided. Tools may change. Models may be updated. Agents may delegate authority to one another. But ultimate institutional responsibility for consequences affecting a person must never disappear inside a machine, contract, provider or certification.