2.1. Proposed Methodological Limitations

The study is conceptual and doctrinal, and does not test the framework against a sample of certified organisations, certification bodies, audit files, or judgements. The standards and EU implementation environment are recent, while liability remains partly national and contract-specific. Cross-jurisdictional examples therefore illustrate possible reasoning rather than universal outcomes. Future research should test the framework through anonymised audit-file analysis, interviews with certification bodies and regulators, comparative national case studies, and longitudinal examination of whether particular audit findings are later used in supervisory, contractual, or judicial proceedings. Such studies should record audit scope, sampling, team competence, timing, and the factual connection between reviewed controls and the incident, so that contextual evidentiary value can be evaluated rather than assumed. The literature review was targeted rather than systematic and was limited to sources identified between February and July 2026 through databases, institutional repositories, and citation-searching procedures described above. Accordingly, the study does not claim exhaustive coverage of all legal, technical, or governance scholarship. The identified research gap should therefore be understood as a gap within the reviewed corpus and search scope, rather than as a proof that no related analysis exists in any jurisdiction or disciplinary field.

5.1. Comparison with the Existing Conceptual Models of AI Auditing and Governance

Recent AI-auditing and governance literature can be grouped into four complementary strands.

First, scope and architecture: Mökander distinguishes legal, ethical, and technical approaches to AI auditing [8]; Mökander et al. distinguish governance, model, and application audits [9]; Raji et al. propose lifecycle-oriented internal algorithmic auditing [18]; and Mökander et al. place conformity assessment and post-market monitoring within an EU auditing ecosystem [19].

Second, accountability and ethics: Novelli et al. conceptualise accountability through relations among actors, forums, and consequences [10] while Laine et al. show that ethics-based auditing produces different forms of knowledge for stakeholders [11]; and Birhane et al. caution that audit findings do not necessarily produce accountability outcomes [21].

Third, organisational and methodological work: It addresses legal, ethical, and technological risk taxonomies, organisational AI governance, and continuous auditing [20,22,23].

Fourth, risk- and regulation-centred models: They operationalise AI Act risk categories, Article 9 risk management, and the role of civil society access in the audit ecosystem [24–26].

The governance-evidence-liability framework shares the premise that accountability requires structured, documented, and assessable governance, but it asks a different question. The existing models primarily classify audit objects, methods, actors, or accountability mechanisms. The present framework traces what happens when a management-system audit output leaves the assurance setting and is invoked in a regulatory or liability assessment. Its distinctive component is contextual evidentiary value: the weight of an audit output depends on audit scope, timing, connection between the audited process and the event, and corroboration by technical and factual evidence. Multidisciplinary competence may strengthen the reliability of an assessment within that boundary; it does not erase the boundary.

The contribution is therefore deliberately limited. The framework is not a new technical audit method, a scoring model for audit quality, or a liability rule. It is an analytical structure for distinguishing the governance object assessed in RQ1, the credibility and limits of competence-informed evidence in RQ2, and the conditions of legal relevance examined in RQ3. Its originality and limitations should be tested empirically against certification practice and, as decisions emerge, regulatory and judicial use of AIMS material.

7.1. Application of RQ1–RQ3 to the Legal Analysis

The legal analysis applies the three research questions stated in the Introduction. RQ1 identifies the organisational object and forms of evidence assessed in third-party AIMS certification audits. RQ2 examines how ISO/IEC 42006 competence requirements affect the credibility and limits of that evidence. RQ3 asks under what conditions AIMS documentation and certification outputs may be relevant, without being determinative, in regulatory, civil, criminal, professional-, and product-liability assessments.

For professional-liability analysis, RQ1 and RQ2 direct attention to the agreed audit object, scope, sampling, objective evidence, and competence of the certification body and audit team. Those factors may inform whether the applicable standard of care was met. An implementer’s position depends separately on its agreed role and applicable law.

For regulatory and product-liability analysis, RQ3 requires consideration of whether a governance record is timely, within scope, connected to the relevant AI system and incident, and supported by technical or operational evidence. Under Directive (EU) 2024/2853, such material may be relevant to disclosure, statutory presumptions or defectiveness, but does not by itself establish defectiveness, compensable damage, or causation [13]. Under the AI Act, where relevant provisions apply, it may evidence process compliance but does not determine civil or criminal liability [3]. The PLD’s evidentiary mechanisms do not determine criminal fault or causation.

These regimes apply different legal tests. Professional liability concerns an applicable standard of care, while product liability concerns defectiveness, compensable damage, and causation without requiring proof of fault. The AI Act imposes regulatory duties but does not create a general civil-liability cause of action. Criminal liability depends on the applicable national offence and attribution rules. The analysis therefore remains conceptual and jurisdiction-sensitive, consistent with the methodological limits stated above.

7.2. Product Liability Regime

Under Directive (EU) 2024/2853, an economic operator may be liable without proof of fault for damage caused by a defective product. The claimant must establish damage, defectiveness, and causation, subject to the directive’s disclosure and rebuttable-presumption rules. Fault is not an element of this cause of action and should not be conflated with the separate assessment of damages or with criminal responsibility [13].

Directive (EU) 2024/2853 expressly includes software in the definition of a ‘product’, whether supplied on a device or accessed through a communications network or cloud technology. An AI system is therefore covered insofar as it constitutes software or is integrated into another product; the directive does not create ‘AI systems’ as a separate product category. Member States must transpose the directive by 9 December 2026, and it applies to products placed on the market or put into service on or after that date [13].

The AI Act and the revised PLD are complementary but apply different legal tests. Under the PLD, a software developer or provider may qualify as a manufacturer or other liable economic operator in the circumstances specified by the directive. Failure to provide safety-related updates within the manufacturer’s control may be relevant to defectiveness, but liability still requires the directive’s conditions, including damage and causation; it does not follow merely from a person being labelled a provider under the AI Act [13].

The revised PLD does not impose a general reversal of the burden of proof. Article 9 permits proportionate disclosure of relevant evidence, subject to protection of confidential information and trade secrets. Article 10 establishes rebuttable presumptions of defectiveness and/or causation only in specified circumstances, including non-compliance with mandatory safety requirements, failure to disclose evidence, obvious malfunction during reasonably foreseeable use, or excessive technical or scientific complexity. The claimant must still establish the elements not covered by a presumption [13].

Two mechanisms deserve particular attention. AIMS records may be within the scope of a proportionate disclosure order where they are relevant and controlled by a defendant, but this is case-specific. Certification evidence is not automatically one-sided: it cannot conclusively establish product safety, yet it may support either party depending on what it shows and may be considered among the circumstances relevant to defectiveness. Any claim of evidentiary asymmetry is therefore a hypothesis requiring empirical validation rather than a settled consequence of Articles 9 and 10 [13,38,39].

In summation, whereas the new European framework for product liability places a considerably elevated burden of accountability of the production/service side, it, at the same time, enables the ingress protection (IP) safety zone environment that the producers can control and direct. The position of auditors and implementers in relation to IP is sensitive from the perspective of required non-disclosure agreements and trade secrets, where a certain level of trust is required to enable the performance of such services. Any effect of insurance on an auditor’s or implementer’s exposure depends on the policy wording and applicable law; insurance held by a producer does not, by itself, reduce another actor’s legal liability.

7.3. Exposure to Criminal Liability

Criminal liability in the AI context continues to be governed primarily by traditional criminal-law concepts. The AI Act establishes regulatory penalties, including administrative fines, but does not create a harmonised EU criminal-liability regime. Criminal liability remains primarily governed by domestic law. The elements to be proved depend on the specific national offence, including whether it requires intent, negligence, causation, endangerment, or a harmful result.

If a person knowingly and intentionally (dolus) uses an AI system to commit a crime, traditional intent requirements are still equally applicable as in other non-AI-related offences. For instance, using a deepfake generated by genAI tools to falsely represent someone may result in fraud or identity theft, provided that it is possible to prove that the actor intended to deceive another person(s). Another obvious example is that of a developer who deliberately introduces harmful code snippet into an AI system (malicious backdoor, crawler, and similar), and who could be liable for digital misuse if intent is proven. Croatia is a specific national example: Article 215.a of the Criminal Code, introduced by NN 136/2025, criminalises intentional or negligent endangerment of life or limb, or property of considerable scale through specified conduct involving an AI system [40]. Liability of a developer, manager, auditor, implementer, or deployer is not automatic; the conduct of a particular accused must satisfy the statutory offence and applicable attribution rules. Whistleblower material or commercial communications may be relevant evidence in an individual case but neither is a general method of proving intent, and dolus eventualis should not be presented as a civil-law analogue.

In cases of criminal negligence, different standards will apply pending domestic law variations. Depending on national law, offences, such as negligent homicide or bodily harm, may apply where a product defect resulting from inadequate care causes the legally required harm [41]. In general, main emphasis is placed on the control aspect: who is responsible for the risky action or lack of required action, and whether the action or lack of appropriate action led to a foreseeable consequence.

European Union’s product-safety and consumer-protection rules may help define regulatory duties or expected conduct but they do not harmonise corporate criminal liability. Member States differ in whether and how individuals and legal persons may be held criminally, quasi-criminally, or administratively liable [41]. Should, for example, an auditor be induced to falsify AI findings, and should such facts become known, the conduct could be assessed under applicable criminal or administrative rules, but only if their constituent and attribution elements are proved.

7.4. Assigning the Blame

In the realm of AI-powered products or services, such determination is more complex, given the nature of algorithms, AI explainability, and lack of technical expertise (in certain areas) and related technical standards (under continuous development). For example, the growing number of accidents involving motor vehicles controlled by (dynamic control) AI system opens a plethora of causation and foreseeability-related questions. The key issues under examination are centred on the role of AI navigation/advanced driving assistance systems developers and backend operators in vehicle operation. The principal question that requires practical determination is the realistic ability of vehicle users to control the behaviour of an AI system, assume control over the motor vehicle, and, ultimately, predict the behaviour of the AI system well in advance to resume control (automated transition request scenarios or voluntary control assumption) and prevent the occurrence of accident, or mitigate negative consequences. If the path to causation leads to the software (AI) development phase, a question may be raised whether there existed information or indication of foul play or inadequate quality and risk management checks and controls. Such evidence may raise questions about the conduct and responsibility of relevant actors, including auditors and implementers, within their defined roles.

To what extent it may be possible to attribute a substantive role of a developer, or potentially auditor/implementer, in the causation link leading to the damaging outcome, especially having in mind the proximate causation doctrine (necessity to establish a direct link), significantly depends on the ability of experts to understand, evaluate, and attest to such connection and accountability. The PLD provides limited disclosure and rebuttable-presumption mechanisms for civil product liability claims, but these do not resolve criminal proof. AIMS material may be relevant under RQ3, without determining criminal fault or causation. More precisely, damage suffered by a client due to an AI system whose safety-related risks were allegedly not adequately governed by the provider and where governance deficiencies were not identified during the audit could only potentially be linked to the auditor’s negligence where it can be demonstrated that the auditor failed to apply a reasonable risk- and sampling-based audit approach, ignored clear objective indicators requiring further investigation, or otherwise departed from the expected professional standard of care. The mere fact that a governance deficiency was not detected during a sampling-based audit would not, in itself, constitute evidence of negligence.

However, as explained in previous text, the role of an auditor and implementer is not focused on product/service safety/quality but rather on processes and procedures employed by producers/service providers. This distinction directly addresses RQ1 and corresponds to the distinction drawn in the recent AI auditing literature between governance audits of the organisation that develops or deploys a system, model audits of the system itself, and application audits of a specific deployed use case; of these, only the first falls within the object of an ISO/IEC 42001 certification audit [9]. Given the scope-bound and management-system nature of ISO/IEC 42001 certification audits, establishing a proximate causal link between audit findings and subsequent AI system malfunction would typically require evidence that the alleged failure relates directly to governance processes that were explicitly within the certified AIMS scope and demonstrably overlooked despite clear and objective indicators. The audit provides a time-bound, sampling-based assessment of evidence within the defined AIMS scope and does not guarantee continuing product or service quality. The applicable causation test varies by jurisdiction: a but-for inquiry may address factual causation, while legal causation or normative attribution requires a separate assessment. It would, hence, be necessary to link any actions or omissions on the side of auditors and implementers at the time of their service with the damage occurring during the scope of product/service lifecycle. In practice, it is very difficult to establish such direct links due to sheer number of other potentially relevant factors and causes.

The principal question to that end for the auditor is whether the auditor’s contractual service stipulations promise a definitive (and time-durable) confirmation of validity, or whether they, as argued throughout this paper, point to a temporary confirmation of the existing evidence, or lack of evidence regarding certain indicators related to AIMS. The causation inquiry should assess whether, absent the alleged audit failure, the client would probably have acted differently and prevented or reduced the harm, subject to the applicable legal test. Given the nature of an ISO audit, as thoroughly examined through this paper, it would appear that, in practice, it would be very difficult to successfully create a valid proximate cause link.

The same question is much more complex regarding the implementers, where the implementation of risk management systems may prove to be detrimental on further behaviour of AI providers (or operators in general), as the client might generally rely on AIMS when placing the product/service on the market. In this scenario, the ‘but-for’ test would have to carefully analyse the role of implementer with that of developer and deployer, and assert, to what extent the role of implementer potentially differs from auditor’s to the extent that this role becomes an irreplaceable component of product/service placement (level on reliance on implementer’s service as an important component of final product/service).

Coming back to the example of semi-autonomous motor vehicles, especially in high-impact cases involving fatalities (as, unfortunately, track record in the United States confirms), the investigation following such an incident may point to buggy sensor software (hardware–software error matrix). Such a defect has the potential to lead to manufacturer’s strict liability in accordance with PLD, regardless of the level of due diligence on the side of motor vehicles or automated driving system producer, or fleet operator’s conduct (especially if remote operation is available). From the perspective of criminal law, a CEO, CTO, fleet operator, or another person could face charges only under a specific national offence and where that person’s relevant duty, conduct or omission, required fault, and causal or endangerment link are proved [42]. In such a scenario, the auditors and implementers would generally face significant challenges in being linked directly to the causation chain unless it can be demonstrated that governance deficiencies within the certified scope were clearly identifiable and materially connected to the harmful outcome.

The matter is further complicated with the above-mentioned AI explainability and the inter-connected AI-related foreseeability capacity. Bearing in mind the technological levels or readiness of many AI systems (many of them still situated in the early stages of development), and lack of mid- to long-term practice and experience in utilising such systems, it may prove to be very difficult to apply traditional standard of foreseeability for every misuse or failure. The latter is true not just for the developers and providers of AI-related services and products but also for the auditors and implementers who are faced with the challenges of evaluating and implementing novel systems and procedures for which relevant standards or performance evidence may still be incomplete. This is especially true for incidents arising outside of the reasonably contemplated utilisation scenarios or processes that (currently) are increasingly difficult to answer and resolve (such as, for example, the problem related to the hallucination of AI general models). Once a risk is documented, repetition may become more relevant to later foreseeability and fault assessments without automatically establishing liability.

For example, bias related to the inadequate level of data diversity representation present in a data training set may, if undetected and unconsidered, produce unwanted and potentially harmful consequences through AI generation. A widely reported illustration is the image-classification incident in which photographs of individuals belonging to a particular ethnic group were assigned an animal label. Publicly available accounts attribute the outcome to the under-representation of certain groups in the training data set, and the provider’s initial remedial step consisted of suppressing the affected labels rather than correcting the underlying data. Two features of the incident are analytically relevant here. First, the deficiency was located in a technical artefact, the training data set, which lies outside the object of an AIMS certification audit. Second, an AIMS audit could nonetheless be expected to establish whether the organisation maintained any documented process for assessing data representativeness and for escalating classification errors identified after release. The incident therefore illustrates how governance findings and technical defects operate at different layers of the framework proposed in this paper, and why evidence generated at one layer cannot be substituted for evidence required at another.

Following a documented incident, comparable risks may become more foreseeable, but the legal consequences remain case-specific. Auditors and implementers are increasingly under pressure to keep track of technological progress and developments in the AI realm to be able to recognise good and bad practices, and what is expected from diligent and reasonable AI systems’ developers and providers. It is necessary to note that such expectations still remain limited to the auditor’s competence in assessing AI-related governance processes within the defined scope of an AIMS, and do not extend to technical verification of AI model performance, algorithmic correctness, or product safety characteristics; this competence boundary directly informs RQ2. Absence of the noted qualification may lead to a failure to recognise instances where certain types of oversight related to risk management may, in turn, lead to allegations of negligence on the side of their clients, consequently raising questions of their own accountability. Such a conclusion triggers further contemplations related to the relevance of actual AI products and services produced or provided by the client, and the unusual relevance of such factors for provision of auditing and implementation services. Under the revised product-liability framework, post-market updates, upgrades, or connected services may be relevant where they remain within the manufacturer’s control; this is not a general guarantee of all promised functions throughout the product lifecycle.

7.5. Exposure to Professional Liability

Professional liability generally depends on the duty undertaken by the professional, the applicable standard of care, breach, causation, and damage, as determined by the governing contract and applicable law. Auditors and implementers may therefore face civil claims for professional negligence where those elements are established. The content of the applicable standard of care is jurisdiction- and contract-specific. In civil-law systems it may be shaped substantially by statutory and professional rules, while contractual undertakings may further define the required level of skill and care. In common-law systems, contractual formulations such as reasonable skill and care, reasonable endeavours, or best endeavours may also affect the content of the undertaking. Accordingly, the required standard should be assessed by reference to the applicable law, professional rules, the agreed scope of services, and the specific contractual undertaking.

In general, should an AI developer negligently design or implement an AI system that causes harm, they could potentially be sued for damage due to professional negligence. Equally so, should a physician use AI tools and AI-enhanced medical devices in everyday practice, the physician remains subject to the applicable professional standard of care [43]. Should a recommendation coming from the AI system be faulty, and provided that a physician ‘blindly’ follows such a recommendation (absence of independent medical judgement), resulting in an injury to a patient, the physician (not the AI) could potentially face malpractice claims. A related concern has already reached the Court of Justice of the European Union in the context of automated credit scoring. In SCHUFA Holding, the Court held that the automated generation of a probability value concerning a person’s ability to meet future payment obligations constitutes an automated individual decision within the meaning of Article 22 of the general data protection regulation, where the lender draws strongly on that value [44]. The judgement does not address professional liability as such. It does, however, indicate a judicial willingness to look behind the formal allocation of decision-making authority and to ask who, in substance, determined the outcome, which is the same question that professional negligence analysis must answer.

The question that arises is whether, and to what extent, such a practitioner may reasonably rely on audit findings or implementation outputs indicating that governance mechanisms intended to support the safe and reliable operation of AI systems were implemented and maintained. The unresolved question, which future case law may clarify, is the extent to which an audit finding or implementation output may be relevant when liability is attributed for harm arising from an AI-enabled product or service supplied by the client or a third party. It is also necessary to remind that the role of an AIMS implementer must also be distinguished from that of a certification body. While implementers may assist in designing governance structures, they do not assume operational control over AI systems unless explicitly contracted to do so. Liability assessment must, therefore, carefully distinguish between advisory support provided by the implementer and decision-making authority retained by the organisation.

If a physician blindly follows recommendations of an AI medical device that points to the necessity of conducting a surgery, in cases where AI system errs, the physician is expected to notice such an error to the extent that a reasonably good physician would notice the same. If a developer has tested the noted AI system prior to deployment, and found a higher level of false positive and false negative results, and despite knowing this proceeded to offer the product on the market, those facts may be relevant to knowledge, breach or fault, but do not by themselves establish deception or criminal intent. If an auditor or implementer identifies a lack of evidence supporting the existence or effectiveness of governance mechanisms intended to identify, assess, monitor or mitigate safety-related risks, and nevertheless issues positive audit findings or implementation outputs, their performance may very well fall under the scrutiny of adjudicatory examination of professional misconduct.

Many professions and professional associations impose (voluntary) ethical or competence standards (non-binding instruments that may become contractually binding or evidentially relevant when incorporated into applicable contractual terms). In direct reference to the AI systems’ development, engineers and IT professionals are regularly bound by codes of practice (such as IEEE Code of Ethics, ISO standards, American National Standards Institute [ANSI], and similar) that insist on prioritising safety, supervision, risk mitigation, and reporting. In line with the previous examples, lawyers and physicians have confidentiality and diligence guidelines and ordinances that are slowly starting to incorporate new technologies. Failure to meet such standards, pending internal acts, and contractual stipulations can constitute a breach of professional duty that, in itself, and depending on the jurisdictions, constitutes either a direct breach of contract (common law) or represents a key element in establishing a breach of contract (continental law). The European ethics guidelines for trustworthy AI [45] and industry standards (although non-binding in principle) also set expectations of transparency and accountability, especially when organisations voluntarily incorporate them into their general terms and conditions, and/or require their implementation as a prerequisite for entering a certain guild/association.

ISO/IEC 42001:2023 and National Institute of Standards and Technology’s (NIST) AI risk management framework [46] are prime examples of frameworks that organisations can use to support structured AI governance without thereby demonstrating compliance with all ethical, technical, or legal requirements, as discussed in detail throughout this paper. Auditors, implementers, and certification bodies working within their respective AIMS roles could, as noted earlier, also potentially be liable if their performance falls below professional standards. Under ISO/IEC 42006:2025, certification bodies auditing AIMS are required to fulfil the relevant competence requirements (including ISO 17021-1). If an AIMS certification auditor negligently assesses the conformity of the AIMS within its defined scope (e.g. a failure to identify a clear absence of required governance processes or documented risk controls may be relevant to an alleged breach of professional duty), liability could potentially arise under general professional negligence principles.

In general, the concept of due diligence permeates AI governance. When the relevant AI Act provisions become applicable under the amended phased timetable, high-risk operators will be subjected to specified mandatory obligations. Compliance may then be evidence-relevant to an assessment of due diligence [3,28,47,48]. A caveat is warranted here. Regulatory compliance and trustworthiness are not interchangeable notions: the AI Act operationalises trustworthiness largely as the acceptability of residual risk, so evidence of compliance speaks to the quality of risk management rather than to the absence of harm [49,50]. Compliance evidence should accordingly be assessed for what it demonstrates about the process followed, not as a proxy for a safe outcome. Courts will likely assess whether all reasonable precautions were taken and safety mechanisms were introduced (reasonable measures, in line with the risk tolerance principle where mitigation measures must be proportional to potential probability and scope of harm). Existence of a thorough audit trail, adherence to relevant technical, legal, and ethical standards, and established response mechanisms may be relevant to, but does not determine, liability. Conversely, absence of documentation or ignoring best practices (e.g. lack of impact assessment) may point to less diligent, potentially negligent behaviour.

The diligent audit trail must demonstrate the systemic approach as promulgated by ISO/IEC 42001 [2]. Potentially multi-stage audit(s) must examine the readiness of policies and documentation, and evaluate actual implementation and control effectiveness [5–7]. Successful findings may provide evidence relevant to the assessment of organisational due diligence. Where the relevant high-risk provisions apply, providers must keep up-to-date risk assessments (AI Act Article 9). Where relevant to the audit objectives and within scope, auditors may examine records of hazard analyses and mitigation actions. Confirming through evidence that risks were systematically identified and addressed may support the provider’s argument that reasonable governance measures were implemented. Furthermore, the developers are encouraged to maintain an ‘audit trail’ of system design and maintenance, including documentation on training data sources, model scope, limitations, and update procedures and history. In potential litigation, these records could help establish the facts concerning what was known and done at what stage of product development and deployment. An analysed and qualified risk that results in controlled and mitigated damage (known risk, or system limitation) may result in a more favourable adjudication outcome. Similarly, update and AI model re-training logs, especially those connected to the incident response procedures, might prove particularly relevant when adjudicators determine whether an implementer has adequately addressed the emerging threats (e.g. analysis of security vulnerabilities and implementation of appropriate mitigation measures). Hence, it may be surmised that comprehensive documentation reviewed by auditors or prepared by implementers may serve as evidence relevant to the assessment of whether implementers and operators exercised an appropriate standard of due care, without itself eliminating or reducing liability exposure. This evidence addresses RQ1, while the following competence analysis addresses RQ2. The competence requirements of ISO/IEC 42006, read together with the audit methodologies described in the assurance literature [19,20,23], supply reference points against which a court could assess whether a reasonably competent auditor would have pursued a given objective indicator further. What they do not supply is a duty to verify technical performance, and the absence of such a duty remains the principal limit on the exposure of auditors.

7.6. Civil Liability for Damage

The following discussion uses Croatian civil law as an illustrative example of broader European liability principles applicable to AI-related damage.

The concept of damage occupies a central place in civil law, particularly in tort law, precisely because the existence of damage represents a conditio sine qua non for the obligation to provide compensation. In a broader sense, damage refers to any reduction of someone’s property or the violation of personal rights and interests, and it is defined in Article 1046 of the Croatian Civil Obligations Act [14] as: a reduction of someone’s property (actual damage), prevention of its increase (lost profit), and infringement of personal rights (non-pecuniary damage) [51–58].

Identifying the type of damage is not only of theoretical significance but also directly affects judicial practice, since the method of compensation depends on the type of damage [19]. As Klarić and Vedriš emphasise, a systematic classification of damage enables consistent application of the principle of monetary compensation and also ensures that arbitrariness in court assessments is avoided [54].

The primary and most practically significant classification is that of material (pecuniary and property) and non-material (non-pecuniary and non-property) damage. Material damage encompasses any reduction or prevention of an increase in the victim’s property, while non-material damage refers to violations of personal rights [58]. Pecuniary damage, according to the Croatian Obligations Act (Zakon o obveznim odnosima or ZOO), manifests in the form of actual damage (damnum emergens) and lost profit (lucrum cessans). Non-material damage is not expressed in the property (monetary) sphere but through the violation of an individual’s moral, physical, and spiritual values. The Croatian Obligations Act, in Article 1046, defines it as a violation of personal rights under Article 19 of the Act. For such a relationship to arise at all, the following cumulative conditions must be met: subjects of the obligation – the injured party and the tortfeasor, harmful act, occurrence of damage, causal link (causal nexus) between the act and the damage, illegality (unlawfulness).

In the case of subjective or fault-based liability, in addition to the general conditions, the fault of the tortfeasor (intent or negligence) is also required [59]. The basic rule is that fault is presumed (Article 1045, paragraph 1 of the Croatian Obligations Act), so it is up to the injured party to prove, in support of their claim, the harmful act, the damage, the causal link, and the elements of unlawfulness. The tortfeasor, on the other hand, can exonerate themselves by proving that the damage occurred without their fault, or that one of the basic conditions is missing. On the other hand, in the case of strict (objective) liability, fault is not required [56]. That is, liability arises solely on the basis of the fact that the general conditions are met (harmful act, damage, causal link, and unlawfulness). Strict liability must rest on a specific statutory basis and remains subject to the elements and defences of that regime.

The development of autonomous vehicles and AI-based systems brings significant advantages in terms of safety, efficiency, and mobility. However, with the increasing functionality of autonomous systems, new legal challenges also emerge, particularly in the area of civil liability for damage caused by such vehicles. The traditional legal framework of liability, based on fault or the principle of strict product liability, faces challenges due to the complexity of algorithms, the unpredictable behaviour of systems, and their interaction with users and the environment [55,60].

The following autonomous vehicle illustrations distinguish product liability from possible operator and professional liability. They are analytical examples, not predictions of how a court would allocate responsibility in a particular case.

This paper focuses on the legal analysis of cases in which autonomous vehicles cause damage to third parties or property, and examines the liability of manufacturers, operators, implementers, and AIMS certification auditors. Special attention is given to the principle of strict liability under PLD and the role of professional duty of care (due diligence) in the governance implementation and AIMS certification. The aim is to demonstrate how civil liability can be applied in practice, taking into account the technical, operational, and legal aspects of using autonomous vehicles [61].

Civil liability for damage caused by an AI-operated vehicle is based on the principles of strict product liability and liability for professional negligence. Under the revised EU PLD, a economic operator may be held liable without proof of fault only where a defective product caused compensable damage and the other statutory conditions are met. Software is included within the definition of a product, and an AI system is covered insofar as it constitutes software or is integrated into another product. Accordingly, where an autonomous vehicle allegedly causes damage, a claim may be brought against the manufacturer or, where applicable under the directive, another liable economic operator, provided that defectiveness, compensable damage, and causation are established. An erroneous AI output does not by itself establish defectiveness, causation, or liability.

For example, imagine a situation in which an autonomous vehicle of brand X, equipped with an AI-based vehicle control system and an advanced driver assistance system, fails to stop in front of a pedestrian due to a sensor algorithm error. The pedestrian is injured, and the vehicle suffers property damage; under the revised PLD, damage to the allegedly defective product itself is excluded from compensable property damage. From a civil liability perspective, the incident raises the question whether the malfunction constitutes a product defect and whether it caused damage attributable to a liable economic operator. If it is established that the manufacturer failed to carry out an adequate risk assessment, omitted appropriate safety testing, or failed to implement necessary software updates, such omissions may constitute relevant evidence in assessing defectiveness. However, strict product liability arises only where the statutory conditions, including defectiveness, compensable damage, and causation, are satisfied [62–64].

An AIMS auditor or implementer is not a manufacturer merely by performing that role. Potential professional liability would require a duty arising under the applicable contract or law, a breach of that duty and the fulfilment of the other legal requirements necessary to establish liability for damage. Audit trails, testing records, and maintenance documentation may help to establish what the relevant actors knew and did; such records do not automatically excuse a manufacturer or operator. This distinction is relevant to RQ3 because AIMS evidence may be relevant without being determinative.

On the other hand, AIMS auditors and implementers, whose work concerned governance processes within their agreed scope, are not directly liable for the resulting damage unless it is shown that they ignored obvious deficiencies in the risk management system and thereby breached their professional duty of care (due diligence). Such records may be relevant to either party; they do not automatically mitigate liability or demonstrate that all reasonable measures were taken.

This example illustrates how product liability may arise from a technical defect when the statutory conditions are met, whereas professional liability of implementers and auditors requires an applicable duty, breach, causation, and damage. Such an approach allows for a clear distinction between product liability and liability for oversight and management, which is essential for the proper allocation of legal responsibility in the event of damage.

Another example involving an autonomous taxi and civil liability is analysed below. An autonomous taxi of brand Y is driving through city streets without a human driver. During the ride, the pedestrian recognition system incorrectly interprets a group of people at a crosswalk, causing the vehicle to continue moving and strike a pedestrian. The pedestrian is seriously injured, and the taxi sustains property damage.

From a civil liability perspective, a claim against the vehicle manufacturer or software developer depends on whether each is a liable economic operator and whether defectiveness, damage, and causation are established. Since the AI system is considered high-risk, the manufacturer had a legal obligation to assess and mitigate risks, monitor safety tests, and update the software. Such omissions may be relevant evidence, but high-risk classification or non-compliance does not by itself establish defectiveness, causation, or PLD liability [57].

On the other hand, the vehicle operator (if remote control is available) may also be liable if proper supervision or timely intervention was not ensured, whereas an AIMS implementer’s or auditor’s exposure depends on the role-specific duty, breach, causation, and damage established under the applicable law. For instance, an unreasonable failure to pursue clear objective evidence of an absent risk-governance process within the defined AIMS scope may be relevant to a professional negligence claim; technical assessment of the safety model itself is not ordinarily the object of AIMS certification.

This example demonstrates how different actors in the responsibility chain may bear civil liability: manufacturers for technical defects, operators for operational failures, and implementers/auditors only in the context of proven negligence in process management. In practice, documentation and record-keeping may help to distinguish roles, but they do not themselves determine liability or reduce litigation risk.

In the context of AI applications, the most difficult aspect is establishing the causal link. The problem of causation is not limited to identifying a cause [60] but also to selecting the correct one among the multitude of events that may be related to the resulting damage. Damage is almost never the result of a single cause; it is the outcome of a complex interplay of various circumstances. For this reason, it is important to identify the cause that is legally relevant, that is, the one that is commonly and specifically associated with the occurrence of the particular damage. How to decide which direction to take among a multitude of potential possibilities? Croatian legal doctrine has, in this regard, adopted the adequacy theory of causation. According to the adequacy theory, among the various events that could be considered as causes, only the event that is specific to the occurrence of the particular damage is regarded as the cause. Specificity is determined based on life experience; if a particular event regularly leads to a concrete harmful consequence, it is considered a legally relevant cause.

The adequacy theory certainly does not provide an absolute and infallible measure. However, its requirement of specificity (typicality) offers a practical criterion for selecting the cause in complex real-life situations. Legally relevant causation may concern acts, omissions, product defects, dangerous things, or dangerous activities, depending on the legal basis. The burden of proving the causal link, since it is not presumed, falls on the injured party. Article 1063 of the Croatian Obligations Act provides a specific presumption for damage arising in connection with a dangerous thing or activity, unless the contrary is proved; its application to a particular AI-enabled vehicle or activity is case-specific [14].

Finally, the court determines the legally relevant causal link and applicable basis of liability. Strict defective-product liability applies only where the statutory conditions and defences under national law implementing the PLD are satisfied [14].

In response to RQ3, the analysis demonstrates that, in the context of AI and civil liability, the establishment of causation is one of the most challenging legal issues. It is essential to determine the legally relevant role of each participant, the degree of that participant’s control over the relevant event, and their contribution to the occurrence of the damage. AIMS documentation may be relevant, without being determinative, in distinguishing these roles and reconstructing the decision-making process.