Who is accountable when an AI-enabled mobility system causes harm?

Accountability should sit with the programme that defined the control boundaries, not only the vendor that supplied the technology. Organisations need named owners for model governance, machine identity, operational safety, and emergency override. Frameworks such as the NIST Cybersecurity Framework 2.0 help structure that accountability across functions.

Why This Matters for Security Teams

AI-enabled mobility systems move accountability into a failure domain that is both software-defined and safety-critical. When a vehicle stack, dispatch agent, or route-planning model makes a harmful decision, the issue is rarely just “the vendor’s bug” or “the operator’s mistake.” It is usually a control failure across model governance, machine identity, operational oversight, and emergency response. NIST’s control language in NIST SP 800-53 Rev 5 Security and Privacy Controls helps teams separate those responsibilities, but the organisation still has to name who owns each layer.

This is why AI mobility governance cannot stop at procurement or product risk reviews. If the system can make autonomous choices, then the accountability chain must include the programme that approved the deployment, the team that set the guardrails, and the function that can override behaviour under stress. NHIMG’s research on DeepSeek breach shows how quickly exposed credentials and unsafe exposure patterns can turn an AI system into a broader operational risk, not just a data problem.

In practice, many security teams discover accountability gaps only after an incident forces them to answer who was authorised to stop the system, rather than through intentional design of those decision rights.

How It Works in Practice

Accountability for AI-enabled mobility systems should be assigned by control boundary, not by software origin. The organisation that defines when the system may act, when it must defer, and who can intervene is the accountable party for those decisions. That includes the model owner, the machine identity owner, the safety engineer, and the operational incident commander. Current guidance suggests that these roles should be documented before deployment and tested during exercises, not assembled after a failure.

Practitioners usually need four layers of control:

• Model governance: define the acceptable use case, the safety constraints, and the conditions that require human review.

• Machine identity: issue workload identity to the AI service, the edge controller, and supporting agents so actions can be traced to a cryptographic identity, not a shared account.

• Operational safety: set runtime checks for route changes, speed limits, sensor confidence, and fallback behaviour.

• Emergency override: ensure a named team can suspend autonomy, revoke credentials, or force safe mode when conditions degrade.

This is also where secrets hygiene becomes part of accountability. If an attacker can abuse exposed API keys or service tokens, the organisation that failed to protect and rotate those credentials owns the operational blast radius. NHIMG’s LLMjacking research highlights how credential abuse becomes a direct AI attack path, which means machine identity and secrets governance are not secondary concerns.

Best practice is evolving toward runtime policy enforcement, short-lived credentials, and clear incident authority, because static approval gates do not hold up when the system is making decisions continuously. These controls tend to break down when mobility systems depend on shared service accounts and fragmented vendor-operated APIs because accountability becomes technically impossible to prove in real time.

Common Variations and Edge Cases

Tighter control often increases operational overhead, requiring organisations to balance safety assurance against deployment speed and service availability. That tradeoff is especially visible when the AI system spans a vehicle OEM, a fleet operator, and a third-party autonomy platform. There is no universal standard for this yet, so the practical answer is to define accountable ownership in contracts, runbooks, and technical controls together.

One common edge case is shared responsibility across vendors. A supplier may own the model, but the operator still owns the deployment context, the access policy, and the decision to keep the system online. Another edge case is emergency authority: if the organisation cannot prove who may trigger a stop, incident response becomes performative rather than actionable. For that reason, many teams map accountability to NIST CSF functions, then translate that into named operational roles and testable controls.

Another subtle failure mode is over-reliance on post-incident blame assignment. That approach does not answer who had the authority to prevent harm in the moment. The more autonomous the system, the more important it becomes to align accountability with runtime control. In AI mobility, the accountable party is usually the organisation that accepted the operational risk and controlled the guardrails, even if a vendor supplied the underlying platform.

Related resources from NHI Mgmt Group

• Who is accountable when an AI system causes harm across multiple vendors?
• Who is accountable when biased AI causes harm in a business process?
• Who is accountable when an AI-generated answer causes harm?
• Who is accountable when generative AI causes privacy, copyright, or compliance harm?