An artificial intelligence system recommends the wrong medication, rejects an applicant, miscalculates an obligation, gives dangerous technical instructions, or produces inaccurate information that is used in a professional decision. The first question is usually, "who is responsible, the AI?" Legally, however, AI is not an autonomous legal person that pays compensation. The people and businesses that designed it, supplied it, integrated it, selected it, and used its output must be examined.
An error also does not automatically amount to compensable damage. There must be specific harm, a legal basis for liability, and a causal link. The same output may be merely irritating in one case and critical in another when it affects health, property, employment, credit, or rights.
If the incident has just occurred: do not rely on a cropped screenshot. Preserve the exact input or prompt, the complete output, the date and time, the account, the model version where displayed, settings, warnings, files provided to the system, logs, the contract, and the human decision that followed. Evidence can easily be lost when the model or application is updated.
1. First distinguish the error from legally recognised damage
A chatbot may give an inaccurate answer without causing damage. If the user detects it and does not act on it, there may be a poor service but no compensable outcome. If, however, the same answer leads, after reasonable use, to financial loss, bodily injury, destruction of data, discrimination, or an infringement of personality rights, the legal assessment changes.
Four questions must be answered separately:
- which precise information or function was incorrect or defective,
- who had a duty to design, test, update, or supervise it,
- what specific damage occurred and how it is valued,
- whether the damage would have occurred without the output at issue or the system failure.
An unpleasant experience, general distrust, or the mere breach of a rule does not by itself become a monetary claim. Likewise, a term stating that "the system may make mistakes" does not automatically exclude all liability when the product or service is used in a foreseeable way.
2. Who may be involved in the chain
The visible application is not always the only potentially responsible party. A system may use a third-party model, data from another provider, additional software, and rules set by the business that made the final decision.
- Model provider or manufacturer: develops or supplies the underlying system and its technical capabilities.
- Application supplier: integrates the model and designs the interface, warnings, and user flows.
- Business or public authority using it: determines the purpose, data, limits, and human oversight.
- Professional: a doctor, engineer, lawyer, accountant, or another professional who uses the output within the scope of their own duty of care.
- Distributor, importer, or authorised representative: may have a specific role under product rules.
- End user: may have disregarded clear limitations, entered incorrect data, or used a tool for an unsupported purpose.
Liability is not mechanically divided among everyone. The assessment considers what each party controlled, what they promised, what they knew or should have known, and which act contributed to the damage.
3. What the AI Act does and does not do
The Regulation (EU) 2024/1689 on artificial intelligence imposes obligations according to the actor's role and the risk presented by the system. It includes rules on risk management, data, technical documentation, logs, transparency, human oversight, and monitoring for specific categories.
The AI Act is not a general law providing automatic compensation. Article 85 provides the possibility of lodging a complaint with a market surveillance authority. Article 86 gives, subject to conditions, a right to a clear and meaningful explanation of the role of a high-risk system in certain decisions that produce legal effects or significantly affect a person. These routes can assist scrutiny, but they do not in themselves award compensation.
The Regulation applies in stages. The official European implementation timeline should be checked for the obligation relevant to each system. It is incorrect to assume that every provision began to apply on the same date or that every AI application is "high-risk".
Common misconception: lodging a complaint under the AI Act, GDPR, or consumer law is not the same as bringing a claim for compensation. It may lead to an investigation, corrective measure, or fine, but a personal claim requires its own legal basis and proof of damage.
4. When the problem begins with a contract or digital service
If you paid for an application, professional platform, or service that includes AI, its description, agreed functions, guarantees, limitations, updates, and support must be examined. A tool sold for a specific professional purpose is assessed differently from a free general-purpose chatbot that warns it does not provide specialist advice.
Important evidence includes the version of the terms in force when the purchase was made, advertising, the invoice, technical documentation, the service level, error reports, and support responses. Later terms should not silently replace those that applied when the event occurred.
Consumer contracts are subject to rules on digital content and digital services, unfair terms, and misleading practices. The official national consumer-protection legislation brings together Law 2251/1994 and the relevant amendments. Depending on the facts, the remedy may be bringing the service into conformity, a price reduction, termination of the contract, or compensation.
5. Tort and the liability of the professional who used the output
General civil liability examines unlawful and culpable conduct, damage, and a causal link. When a professional uses AI, the tool does not remove their own duty of care. The key questions are whether the result should have been checked, whether it was used in an appropriate field, and whether material limitations were disclosed.
There is no single level of scrutiny for every use. A drafting suggestion is one thing; a diagnosis, structural calculation, legal deadline, or hiring decision is another. The greater the foreseeable risk and the harder it is to reverse the decision, the more important genuine human verification becomes.
The professional is not automatically liable for every technical error made by the supplier. Equally, they are not released from liability because "the algorithm said so". It must be examined who had access to the information, who could have detected the problem, and whether the human decision interrupted or reinforced the causal chain.
6. When software may be examined as a defective product
Product liability is not the same as contractual or tortious liability. It examines whether a product provided the safety that the public is entitled to expect, taking into account its presentation, reasonably foreseeable use, the time it was placed on the market, and other factors. An inaccurate result is not, by itself, proof of a defect.
The new Directive (EU) 2024/2853 on liability for defective products expressly includes software and AI systems in the definition of a product. It provides adapted rules for digital products, updates, cybersecurity, disclosure of evidence, and certain presumptions.
This does not mean that the new Directive is already the complete applicable Greek rule for every current incident. It must be transposed into national law by 9 December 2026, and the Greek transposing measure must be checked once it is published.
7. The critical transitional date under the new Directive
Following the corrigendum published on 7 May 2026, the new Directive applies to products placed on the market or put into service after 8 December 2026. For earlier products and incidents, the previous regime and the other available bases of liability must be examined.
This distinction matters for applications that are continuously updated. It is necessary to record which version was used, who supplied the function, and when. It is not safe to select the applicable law solely by the date on which the user noticed the error.
The proposed European Directive specifically on AI liability, COM(2022)496, was withdrawn on 6 October 2025. Its proposed presumptions and disclosure rules are not current law. The official legislative procedure records the withdrawal.
8. What damage must be proved
The claim must describe an actual outcome, not merely the existence of a bug or an infringement. Depending on the legal basis, it may concern bodily injury, property damage, destruction or corruption of data, loss of income, additional costs, an infringement of personality rights, or other recognised harm.
Not every form of pure economic loss is compensated in the same way. The new Product Liability Directive has its own definition of covered damage, while contract, tort, and consumer law have different requirements. Record:
- the original amount or asset before the incident,
- the specific change that was caused,
- invoices, medical records, technical reports, or lost income,
- the reasonable steps taken to mitigate the damage,
- any other causes that may have contributed.
Overstatement weakens a case. A documented chronological and financial account is more useful than a general assertion that "AI destroyed everything".
9. Causation and the human decision
AI applications often involve several intervening stages. An output is shown to an employee, the employee checks it or does not, a business applies a rule, and an outcome then follows. The investigation must show which stage was decisive.
Human involvement does not always release the supplier from liability, nor does it always transfer all liability to the operator. A person may have only a formal approval button, without time, information, or a real ability to depart from the recommendation. By contrast, independent professional judgement may be a strong intervening factor.
Logs are needed to show the input, output, confidence or other indicators where available, warnings, user intervention, the final decision, and timing. If the provider holds critical information, an early preservation request may be necessary before the contractual retention period expires.
10. How to preserve reliable digital evidence
A screenshot shows only what was visible on one screen. It does not always prove which version produced the result, whether other messages came before it, whether the file was altered, or which account was used. Preserve the full export where available and the unedited original file.
- export the entire conversation or report, not only the disputed extract,
- preserve URLs, IDs, headers, timestamps, and transaction confirmations,
- record the model, application version, settings, and connected sources,
- preserve the original input, attachments, and warnings displayed,
- create a file fingerprint when integrity is likely to be disputed,
- do not "clean up" or recreate evidence with AI without preserving the original.
Metadata and hashes do not by themselves prove that the content is true, but they help establish whether a particular file has changed. A serious case may require technical expert evidence and a lawful procedure to obtain information held by third parties.
11. Which route to follow
Begin with written notice to the business or professional that had the direct role. Describe the event, damage, evidence, preservation request, and specific remedy sought. Do not send vague threats to every potentially involved party; they make clarification more difficult.
- Contract or consumer service: seek conformity, a refund, correction, or compensation from the contractual counterparty.
- Personal data: exercise the right of access, objection, or another appropriate right and, where necessary, lodge a complaint with the competent authority.
- AI Act: use the complaint procedure before the competent surveillance authority when the Regulation's rules are breached.
- Professional service: examine the contract, duties of care, liability insurance, and any disciplinary procedure.
- Defective product or software: identify the producer, version, time of supply, and applicable transitional regime.
- Immediate danger or crime: priority must be given to protecting people, systems, and evidence and to contacting the competent public authority.
These routes may coexist. An administrative investigation may provide useful material, but a limitation period, contractual deadline, or opportunity to notify an insurer must not be lost in the meantime.
12. What to remember before taking action
Do not try to prove that "AI is generally unreliable". Prove which system, which version, which input, which result, and which human use are connected to your damage. Map the actors and choose the legal basis that corresponds to the relationship and the type of harm.
The AI Act adds obligations and supervisory routes, while the new European Product Liability Directive modernises liability for software. Neither removes the need to establish the contract, duty of care, actual damage, and causation. Timely preservation of the digital evidential chain is usually the step that cannot be recreated later.
Legal update: this article reflects the framework in force on 24 August 2026. The Greek transposition of Directive (EU) 2024/2853 and the precise timetable for applying individual obligations must be checked again for each new incident. This text is for information only and does not replace an assessment of the specific system, contract, and damage.
Comments
Share your thoughts about this article.
No comments yet. Be the first to comment.
Submit a comment