DSCI Floats Framework To Determine Liability For Harm Caused By AI Agents
DSCI proposes an industry framework for deciding liability when autonomous AI agents cause harm. Its central idea is simple: responsibility should follow the participant’s decisions and control over the system. The proposal does not create a new regulatory regime. Instead, it applies existing laws, contractual duties and sectoral regulations to agentic AI. The framework examines decisions such as model selection, system configuration, tool access, permissions and human oversight. For example, a deploying company may be responsible for choosing a risky use case or granting excessive permissions. An integrator may be responsible for poor system design, while a product company may face responsibility for misleading claims or unsafe default settings. DSCI’s authority map would connect each harmful decision to the participant who controlled it and could have prevented or limited the damage. The council also recommends six safeguards, including monitoring, human approval, safe scaling back and clearly owned kill switches.
What framework has DSCI proposed for deciding who is liable when an autonomous AI agent causes harm?
DSCI proposes an industry framework for deciding liability when autonomous AI agents cause harm. Its central idea is simple: responsibility should follow the participant’s decisions and control over the system. The proposal does not create a new regulatory regime. Instead, it applies existing laws, contractual duties and sectoral regulations to agentic AI.
The framework examines decisions such as model selection, system configuration, tool access, permissions and human oversight. For example, a deploying company may be responsible for choosing a risky use case or granting excessive permissions. An integrator may be responsible for poor system design, while a product company may face responsibility for misleading claims or unsafe default settings.
DSCI’s authority map would connect each harmful decision to the participant who controlled it and could have prevented or limited the damage. The council also recommends six safeguards, including monitoring, human approval, safe scaling back and clearly owned kill switches.
What is an agentic AI system, and how is it different from a conventional generative AI system?
An agentic AI system can do more than produce text, images or other outputs for a person to review. It can independently plan tasks, access tools, interact with application programming interfaces and execute instructions with limited human intervention. This makes it more like an operating system for completing tasks than a passive answer generator.
For example, an agent might connect to business software, call an API and initiate a payment. If its permissions are too broad or its reasoning goes wrong, it could make an incorrect payment without a person checking every step. Multiple agents may also interact or delegate work, allowing one mistake to spread across organisations.
Conventional generative AI mainly creates outputs for human review. Agentic AI can act on those outputs and change systems or real-world workflows. DSCI therefore highlights risks including data breaches, loss of control, operational failures and wider disruptions from cascading errors.
How many major groups does DSCI identify across the AI value chain, and what roles do they play?
DSCI identifies five groups involved in enterprise AI deployment. They are end-user organisations; service providers and integrators; product companies and startups; tool and framework providers; and cloud and infrastructure providers. AI model providers are examined separately because they develop the underlying capabilities and safety measures.
Their roles differ across the system. End-user organisations choose use cases, permissions and human approval requirements. Integrators design systems and approval mechanisms. Product companies provide products, model versions and default settings. Tool and framework providers supply orchestration, memory and safety features. Cloud and infrastructure providers support isolation, identity management, data retention and platform logs.
This structure spreads accountability instead of placing it solely on the deployer or technology supplier. The proposed authority map would examine who controlled each important decision. Responsibility could therefore shift depending on how a model was configured, connected, monitored and used.
What kinds of harm could autonomous AI agents cause, such as unauthorised transactions, data breaches, discrimination or AI-enabled cybercrime?
Autonomous AI agents could cause both direct harm and system-wide disruption. DSCI identifies 12 areas, including privacy breaches, security threats, discrimination, safety risks, inaccurate outputs, intellectual property violations, deepfakes, loss of control and AI-enabled cybercrime. The article also highlights unauthorised transactions, incorrect payments and data breaches.
A practical example is an agent with access to business tools and payment systems. If it misunderstands an instruction or receives excessive permissions, it could send money incorrectly or expose data. If several agents interact or delegate tasks across organisations, an early mistake could produce cascading errors and wider disruption.
Liability becomes harder to assess because model behaviour can change, people may suffer approval fatigue and agents may delegate decisions. Investigators may also struggle to reproduce how an agent reached a particular action. DSCI’s safeguards target these risks through permission limits, monitoring, human approval and kill switches.
How would the proposed authority map determine which participant is responsible for a harmful AI decision?
DSCI’s authority map is a method for tracing responsibility through an AI system. It asks who controlled a particular decision and whether that participant could have prevented or limited the resulting harm. This approach reflects the system’s distributed design, where several organisations may shape one agent’s behaviour.
Suppose a company chooses a risky use case and grants an agent broad permissions. The deploying company could be responsible for those choices. If the system’s approval mechanism fails, the integrator may be accountable. A product company could face responsibility for unsafe defaults or product claims, while infrastructure providers may have duties involving identity management, isolation or logs.
The map connects control with existing principles such as duty of care, product liability, causation and comparative negligence. It avoids assuming that one party is always responsible. Instead, liability depends on each participant’s decisions, control and ability to reduce the harm.
Why might using an open-source AI model on a company’s own infrastructure create more responsibility than using a closed model through a managed API?
An open-source or open-weight model run on a company’s own infrastructure places more of the system under that company’s control. DSCI therefore says the company would take greater responsibility for auditing, modifying and monitoring the model. It must also manage how the model is configured and connected to tools.
By contrast, a company using a closed model through a managed application programming interface may have less direct control over the underlying model. If a problem occurs, it could seek contractual recourse against the model provider. That remedy depends on the contract’s terms and any applicable liability caps, so it is not automatic.
The distinction follows DSCI’s control-based approach. Model providers remain responsible for capabilities, safety measures, known limitations and significant behaviour changes. Their liability may reduce, however, when another participant controls deployment and use. Responsibility still depends on the whole arrangement.
What do concepts such as duty of care, causation, product liability and comparative negligence mean when applied to AI systems?
Duty of care means taking reasonable steps to avoid foreseeable harm. In AI, that could include assessing risks, limiting permissions and requiring approval for significant actions. Causation asks whether a participant’s decision actually led to the harm. Without that link, responsibility may not follow simply because the participant was involved.
Product liability concerns harm connected to a product’s defect, unsafe design, misleading claim or faulty operation. Comparative negligence divides responsibility when several participants contributed to the outcome. For instance, a product company might provide unsafe defaults, while a deploying organisation might ignore risks and grant excessive access.
DSCI applies these established principles to agentic AI rather than creating new rules. Its authority map would help identify control, prevention and contribution. The result could be shared or reduced liability, depending on each participant’s role, decisions, ability to intervene and contractual arrangements.
This brief was written by AI from the original reporting and checked by other models. Names, figures and quotes come from the source; read it for full context.
Read more in the JupiteX app
Pulse is free. New stories every 4 hours, each one broken into the questions that explain it.
Or read more news on the web