When the Vendor's Assurance Falls Away: How AI Liability Lands on the Deployer

The sentence that no longer protects you

There is a sentence that used to end arguments. The vendor said it was safe. For a long time that was enough. You bought the model, you read the marketing, you signed the contract, and if the thing went wrong you pointed upstream. The supplier carried the reputation, so the supplier carried the blame. That arrangement is quietly collapsing, and most organisations deploying artificial intelligence (AI) have not noticed, because the collapse is happening in case law, insurance schedules, and regulatory drafting rather than in headlines.

I run Mickai, a Sovereign Intelligence Operating System (SIOS) that is built and in production. I spend my days thinking about who answers for what a machine does. So let me be direct about where this is going. The risk is moving from the people who build AI to the people who use it. The legal centre of gravity is shifting from the vendor to the deployer, and the only thing that will decide how that lands on any given organisation is the evidence that survives the event. Everything else in this piece follows from that one sentence, so it is worth sitting with before we go further.

Who the law actually means when it says deployer

Start with a definition, because the word does real work. A deployer is the organisation that puts an AI system into use in the real world under its own authority. The hospital that runs a triage model. The bank that runs a credit-scoring system. The insurer that automates a claims decision. The employer that screens applicants. The deployer is not the laboratory that trained the weights and not the cloud provider that hosts them. The deployer is the party whose name is on the decision that reached a human being.

The European Union (EU) Artificial Intelligence Act made this distinction load-bearing. It separates the provider, who develops or markets a system, from the deployer, who uses it under their own authority in a professional capacity. From August 2026 the high-risk obligations begin to bite in earnest, and a meaningful share of them land squarely on the deployer. Human oversight. Monitoring in operation. Keeping the automatically generated logs the system produces. Informing affected people in certain contexts. These are not the provider's duties to discharge on your behalf. They are yours, because you are the one who pointed the system at a real person and let it decide.

That is the structural move worth understanding. Regulators did not draft these regimes to punish researchers. They drafted them to reach the party with operational control, because that is the party who can actually prevent harm in the moment it would occur. Control attracts responsibility. It always has. AI simply makes the question of who held control much harder to answer after the fact, which is exactly why the law now insists on a paper trail rather than taking your account on trust.

Why the vendor's assurance was never as strong as it looked

Consider what the vendor actually promised. Read a typical AI supply contract and you find capability claims, an acceptable-use policy, and a liability cap that is often a small multiple of fees paid. You will rarely find a warranty that the system will reach correct outcomes on your data, in your context, against your population. The vendor warranted the tool. They did not warrant your use of it. That gap is not a drafting accident. It is the entire commercial logic of selling a general-purpose technology to buyers who will apply it in ten thousand situations the seller never saw.

So the comfort of the vendor said it was safe was always thinner than it felt. Safe for what? Tested on whose data? Validated against which edge cases that resemble yours? When a deployer accepts a model and switches it on, the deployer is making an implicit judgement that the tool fits the job. The law is increasingly treating that judgement as the deployer's own act, with the deployer's own duty of care attached. The vendor's assurance becomes one input you considered, not a shield you can hide behind.

There is a useful parallel in older product-safety thinking. A manufacturer who supplies a powerful machine tool is not automatically liable when a factory removes the guard and an operator is injured. The factory chose the configuration. The factory supervised the use. AI deployment looks more like that than people expect. You configure the system, you set the thresholds, you decide where a human checks the output and where one does not. Those choices are yours, and choices generate liability. The harder a vendor's marketing works to make a system feel turnkey, the more important it becomes to record the choices you made on top of it.

The negligence question hiding inside every deployment

Strip away the novelty and most AI liability resolves into an old and unglamorous question. Did the deployer take reasonable care? Negligence law has handled new technologies for two centuries by asking exactly that. What would a competent operator have done? Did this operator meet that standard? Was the harm a foreseeable consequence of falling short? The vocabulary changes with each new machine, but the test does not.

Apply it to a concrete case. An AI system in a lending workflow declines an applicant. The applicant alleges the decision was discriminatory. The question is not whether the model is perfect. No model is. The question is whether the deployer behaved reasonably. Did you test for disparate impact before going live? Did you monitor outcomes across protected groups during operation? When the system produced a borderline result, did a human review it, and did that review mean anything? Did you act on warning signs, or did you let the numbers drift because intervening was inconvenient?

Every one of those questions is answered with evidence or it is not answered at all. And here is the uncomfortable truth a security realist learns early. In the absence of evidence, the gap is filled by the least charitable plausible story. If you cannot show what the system did, what the human did, and when, the court, the regulator, and the claimant will each assume the version that suits them. Silence is not neutral. Silence is read against the party who should have been keeping records and was not. That is the asymmetry no contract clause repairs for you.

Liability is consolidating because the alternatives do not work

You might expect the law to spread AI liability evenly across the whole supply chain. It is not really going that way, and the reason is practical. A regulator or a claimant needs one party who can be identified, served, and held to account. Chasing a foundation-model laboratory across jurisdictions, through layers of fine-tuning and integration, to prove that a specific training decision caused a specific harm, is close to impossible in an ordinary dispute. The deployer, by contrast, is right there. Local. Named on the decision. Holding operational control. The path of least resistance runs to the deployer, and law, like water, tends to follow that path.

Insurance is reinforcing the same direction. Underwriters are not waiting for case law to settle. They are already asking deployers how they govern AI, what they log, how they oversee automated decisions, and whether they can reconstruct what happened after an incident. Organisations that cannot answer are quoted higher premiums or excluded from cover for AI-related claims. That is risk shifting onto the deployer through the price of insurance long before any court delivers a judgment. The market is pricing the gap that the contract left open, and it is doing so quietly, line by line, in renewal terms most boards never read closely.

Regulatory liability runs in parallel with civil liability and does not require a victim to sue. A data-protection authority, a financial conduct regulator, or a market-surveillance authority under the Artificial Intelligence Act can open an inquiry on its own initiative. The first thing every one of them asks for is records. Show us your logs. Show us your oversight. Show us how this decision was reached and who was accountable for it. A deployer who can produce a clean, complete, tamper-evident account is in a fundamentally stronger position than one who is reconstructing events from memory and partial screenshots after the fact.

The evidence problem is harder than the liability problem

Here is where my work actually lives, so let me be precise. Knowing that the deployer carries the risk is the easy part. The hard part is that ordinary AI systems are terrible at producing evidence that holds up under adversarial scrutiny. Most logging was built for engineers debugging their own software, not for a sceptical outsider trying to establish what truly happened. The two purposes look similar and are not the same thing at all.

Think about the properties evidence needs when someone is motivated to dispute it. It must be complete, so nothing inconvenient was quietly dropped. It must be ordered, so you can prove the sequence in which things occurred. It must be tamper-evident, so no one could have edited it after the incident, including you. And it should be verifiable by someone who does not trust you, because the moment that matters most is precisely the moment your word is in question. A log file you can open and edit fails every one of these. A database row with a timestamp your own administrators can change fails most of them. A vendor dashboard that shows you a curated view, hosted on the vendor's infrastructure, controlled by the vendor's access policies, fails the one that counts. You are trusting the very party whose product is under examination to tell you the truth about its own behaviour.

There is a second, sharper problem. Most systems log what happened after the fact. They record that a decision was made once it has already been made. But the decision that causes harm is the one that executed. If the record is written afterward, there is always a window, however small, in which the action and the record can diverge, by accident or by design. For evidence that has to survive an adversary, after the fact is the wrong moment. The commitment has to come before the act, not after it. That single shift, from describing the past to committing to the future, is the difference between a story and a proof.

What it actually means to sign before you act

This is the design principle Mickai is built on, and I will state it plainly because it is the whole point. Every action the system takes is signed before it executes, not after. Each record is hash-chained to the one before it, so the history is append-only and any attempt to remove, reorder, or alter an entry breaks the chain and is immediately detectable. We call this the Open Audit Record (OAR). It is not a feature bolted onto Mickai. It is the spine the whole Sovereign Intelligence Operating System is arranged around, sitting beneath the fifty brains (twenty-five domain and twenty-five operational) that run on the Poseidon silicon substrate.

Signing before execution changes the evidentiary meaning of the record. It is no longer a description of what the system claims it did. It is a commitment the system made about what it was about to do, captured at the moment of intent, which the action then either matches or does not. There is no comfortable gap to hide in. The cryptography is post-quantum, built on the United States National Institute of Standards and Technology (NIST) standard Federal Information Processing Standard 204 (FIPS 204), the Module-Lattice Digital Signature Algorithm at the ML-DSA-65 parameter set, so the signatures do not quietly weaken as computing advances and a record made today remains a record decades from now, when a dispute about it might still surface.

The property I care about most is the last one, because it is the one ordinary systems cannot offer. The Open Audit Record is verifiable offline, in an ordinary web browser, with no trust in the vendor and no call home to Mickai. A regulator, a court-appointed expert, an opposing lawyer, or your own auditor can take the record and check the entire chain themselves, on their own machine, while believing nothing I tell them. That is the correct standard for evidence. Not trust me. Verify it yourself, without me in the room. For the longest horizons, the audit root is anchored to a sovereign Layer 1 chain, Pantheon, whose own root is in turn anchored to Bitcoin, so the integrity of the record does not depend on Mickai continuing to exist. If the proof of what your AI did depends on trusting the company that sold you the AI, you do not have proof. You have a marketing claim wearing the costume of an audit trail.

Honest limits, because evidence cuts both ways

I would be a poor security realist if I pretended a signed record solves liability. It does not, and the deployers who treat it as a magic shield will be unpleasantly surprised. A perfect record of a negligent process proves you were negligent with admirable precision. If you never built oversight into the workflow, the Open Audit Record will faithfully document that you never built oversight in. The record is only as good as the practice it captures. Evidence is a mirror, not a costume.

So the honest position is this. A signed, offline-verifiable record is necessary but not sufficient. You still have to do the underlying work. Test before deployment. Define where humans intervene and make those interventions real rather than decorative. Monitor outcomes in operation and act on what you see. Set thresholds you can defend to a stranger. The record's value is that it lets you prove you did those things, and lets the rare bad actor be caught when they did not. It turns reasonable care from an assertion into a demonstrable fact. What it cannot do is manufacture care that was never there. Anyone who tells you a technology removes the duty to behave responsibly is selling you the next liability, not protecting you from this one.

Why I build this in the open, and on owned ground

A reasonable reader will ask why any of this should be believed coming from a vendor, given that distrust of vendors is the whole argument. Fair. The answer is that I have tried to remove myself from the trust equation by design rather than by promise. The verification needs no server I control. The cryptography is a published public standard anyone can scrutinise, not a private scheme you have to take on faith. The chain of records can be checked by your adversary as easily as by you. I have deliberately built a system whose evidence is strongest precisely when nobody believes me, because that is the only kind of evidence worth having.

That posture extends to how the underlying capability is owned and developed. The methods behind this are protected as a portfolio of 101 filed United Kingdom patent applications, covering roughly 2,234 claims, owned by Mickai LTD with myself as the named inventor. We are actively training our own models now, fine-tuning and specialising open foundations such as Llama 3.2 and Qwen 2.5 and building a sealed corpus, with funding scaling the work toward fully native weights. I mention this not to wave credentials but because provenance is part of the argument. A system that asks regulators and courts to rely on it had better be able to show clear title to what it is, and a clear account of how it was made. Sovereignty over the substrate and openness of the proof are not in tension. They are the same commitment seen from two sides.

Where this leaves you before August 2026

Let me bring the arc to a point. The legal world is moving from the vendor said it was safe to the deployer is responsible for what it did, and that move is most of the way complete in the regimes that will govern the next decade. The Artificial Intelligence Act assigns concrete operational duties to deployers. Negligence law asks whether you took reasonable care and answers the question with your records. Insurers are pricing the risk onto you now. Regulators can come asking on their own initiative, and the first thing they want is the evidence.

When that event arrives, and for any organisation running AI at scale it is a matter of when and not if, exactly one thing will determine the outcome. Whether you can produce a complete, ordered, tamper-evident account of what your system did and what your people did, an account that a hostile outsider can verify without trusting you. Build for that future. Assume the risk has already shifted to you, because legally it largely has, and the only protection that holds when the vendor's assurance falls away is a record that was true the moment it was made and stays provable long after everyone has stopped taking your word for anything.