AI governance and risk, answered
125 questions on AI liability, AI governance and vendor risk assessment, answered in plain English for technology and SaaS businesses.
AI liability, AI governance and vendor risk assessment, answered directly, drawn from what technology and SaaS businesses actually search for.
AI governance, AI clauses and who is liable
When an AI system gets something wrong, the contract usually decides who pays.
There is no general rule making an AI system responsible for anything, because a system is not a legal person. Liability lands on the humans and companies in the chain: the developer, the deployer, the supplier who put it in a product, and the customer who used it. Which of those pays is decided by contract first, then by ordinary negligence and product liability rules, then by regulation.
In the EU, the AI Act takes a risk-based approach with prohibitions on certain practices, transparency duties for general purpose models, and a heavier set of obligations for high risk uses, phased in over several years from its 2024 entry into force. Timing has been the subject of live debate and proposed amendment, so the safest position is to check the current phasing rather than rely on a date quoted in an article. The proposed AI Liability Directive was later dropped from the Commission’s work programme, which leaves the revised Product Liability Directive, which does extend to software, plus national tort and contract law. The UK has taken a principles-based route through existing regulators rather than a single AI statute.
For most businesses the practical work is not regulatory. It is: an AI use policy staff actually follow, a record of which AI tools touch which data, vendor due diligence for AI suppliers, contract clauses on training data and output ownership, and a DPIA where the processing is high risk. Those five things answer almost every question a customer or regulator asks.
Who is legally responsible when an AI system makes a mistake?
A person or company, never the system. Responsibility is allocated first by the contracts in the chain, then by negligence, product liability and consumer law, and then by sector regulation. If your contracts are silent on AI outputs, you are relying on default rules that were not written with AI in mind.
Who is liable for AI decisions in a business context?
Usually the deployer, meaning the business that put the system in front of the customer, because that is who owed the duty to the affected person. The deployer may then have a claim against the AI supplier, but only if the supply contract gives them one. Most standard AI vendor terms do not.
Who helps with AI liability and risk clauses in software contracts?
A commercial lawyer who drafts technology contracts. The clauses worth getting right are training data rights, ownership of outputs, accuracy disclaimers, human oversight obligations, indemnities for third party IP claims arising from outputs, and how AI-related loss interacts with your liability cap. Eliga drafts and negotiates these for software and SaaS businesses.
What is AI governance?
The set of policies, roles, records and controls a business uses to decide what AI it will use, on what data, with what oversight, and who is accountable. In practice it is an AI use policy, an inventory of AI systems and their data, a risk assessment process, human oversight requirements, and a review cycle.
What does a responsible AI policy contain?
Approved and prohibited use cases, rules on what data may be entered into which tools, a requirement for human review before AI output is relied on externally, disclosure rules for customers, accuracy and bias checks, record keeping, and a named owner. Short and enforced beats long and ignored.
What is AI risk, and how is it assessed?
AI risk covers accuracy and hallucination, bias and discrimination, data protection, confidentiality leakage, IP infringement in training data or outputs, security, and dependence on a supplier. Assessment means identifying the use case, the data involved, who is affected, the potential harm, and the controls, then recording the conclusion. Frameworks like the NIST AI Risk Management Framework and ISO/IEC 42001 give you a structure.
What should an AI vendor risk assessment ask?
Where the model is hosted, whether your data is used for training, what the retention and deletion terms are, sub-processors and their locations, security certifications, evaluation and accuracy testing, what happens on model change, incident notification, indemnity for IP claims on outputs, and exit and data return.
Do we need a DPIA for an AI tool?
If the AI processes personal data and involves automated decisions with significant effects, large scale profiling, or novel technology applied to sensitive data, yes. In practice most customer-facing AI decisioning meets the high risk threshold and a DPIA is the cheapest way to demonstrate you thought about it.
What are the main legal issues with using AI in business?
Confidentiality of what staff paste into tools, personal data going into systems without a lawful basis, IP ownership of outputs and infringement risk, accuracy where output is relied on by customers, contractual promises you cannot keep if the model changes, and sector regulation. Almost all of these are manageable with a policy and a contract review.
Are AI contract review tools a substitute for a lawyer?
They are good at extraction and consistency: finding clauses, flagging missing terms, comparing against a standard. They are weak at judgement: whether this cap is acceptable for this deal at this margin. Used as a first pass they save time. Used as the decision they create risk nobody has priced.
Risk assessment, vendor due diligence and compliance frameworks
Enterprise buyers do not audit your product. They audit your paperwork.
Once you start selling to larger organisations, you enter their vendor risk process. That means a security questionnaire, evidence of your controls, your DPA, your sub-processor list, your incident process, and often proof of certification. Failing that process is a common and avoidable reason deals stall late.
The frameworks people reference do different things. ISO 27001 certifies an information security management system. SOC 2 is a US attestation report on controls against trust services criteria. HIPAA is a US healthcare regime that reaches you through business associate agreements if you touch protected health information. SOX is financial reporting control, relevant to you mainly as a supplier to listed companies. NIST publishes frameworks rather than certifications. None of them are GDPR, and having one does not give you another.
Running due diligence in the other direction matters just as much. Before you take on a supplier who touches customer data, you want to know their security posture, their sub-processors, their location, their incident notification commitment, and what happens to your data when the relationship ends. That is your Article 28 obligation as well as good practice.
What is a vendor risk assessment?
A structured review of a supplier before and during the relationship, covering security, data protection, financial stability, compliance and concentration risk. The output should be a decision, a set of contract requirements, and a review date.
What should a vendor risk assessment procedure cover?
Tiering suppliers by criticality and data access, a questionnaire proportionate to the tier, evidence review such as certifications and penetration test summaries, contract requirements including the DPA and security schedule, sign-off, and periodic reassessment.
What are the software compliance requirements for a SaaS business?
Data protection obligations wherever you have users, security commitments made to customers in contracts, any sector regime your customers pull you into such as healthcare or financial services, licence compliance for third party and open source components you ship, and accessibility or consumer rules where you sell direct.
Does HIPAA apply to a SaaS company?
It applies if you handle protected health information on behalf of a covered entity, which makes you a business associate and requires a business associate agreement plus the associated safeguards. It is a US regime and it does not substitute for UK or EU data protection compliance on the same data.
Do we need ISO 27001 or SOC 2 to sell to enterprise?
Not legally, but commercially it is often the fastest way through procurement. Before certifying, check what your actual buyers ask for: UK and EU buyers tend to ask for ISO 27001, US buyers for SOC 2. Certifying for the wrong one is an expensive detour.
What is a software compliance checklist for a growing company?
Data protection records and notices, a DPA for every processor in and out, a security policy set with evidence, an asset and sub-processor inventory, open source licence review, an incident response plan that has been tested, contract commitments tracked against what you can deliver, and a named owner for each.
How do we allocate risk in a contract?
Through the liability cap and its carve-outs, indemnities, warranties, insurance requirements, and termination rights. The principle worth applying is that risk should sit with the party best able to control it, and the cap should bear some relationship to the contract value and your insurance.
Still the wrong answer for your situation?
General answers only go so far. If you are deploying an AI feature, negotiating an AI vendor contract, or preparing for an enterprise security review, the useful conversation is about your facts.
Book a call: calendly.com/dhruve-eligaconsultancy
This page is general information about UK and EU commercial and technology practice. It is not legal advice and it does not create a solicitor-client relationship.