DSIT just told buyers what an AI supplier owes them. Your contract still needs to say it.

What the toolkit actually covers

DSIT’s toolkit is built around the full lifecycle of an AI-enabled product, from the design choices a developer makes through to how a business actually procures, runs and delivers that product to end users. That last part matters for anyone reading this as a buyer rather than a builder.

The guidance is explicit that commercial solutions and supplier procurement sit inside its scope. It sets out how an organisation should identify AI risks, assess how likely and how severe they are, and justify the treatment strategy it chooses, whether that is mitigation, transfer, acceptance or refusal to proceed.

None of that is new as a discipline. What is new is a government-published reference point that a procurement team, an auditor, or an enterprise customer’s legal function can point to and ask: where is your equivalent assessment for this supplier.

Why procurement teams should care about guidance, not law

The toolkit is not legislation. It imposes no statutory duty and carries no penalty of its own. That is worth saying plainly, because it is easy to either overstate its force or dismiss it for lacking any.

The practical effect sits in between. Enterprise buyers now have a published, citable standard for what a responsible AI procurement process looks like. Once that standard exists, a supplier who cannot show an equivalent risk assessment starts to look like the exception rather than the norm, and exceptions lose deals or get pushed into longer, more expensive diligence cycles.

For suppliers, the same logic runs the other way. Being able to produce a clear, DSIT-aligned risk assessment on request is becoming a sales asset, not just a compliance cost.

What “risk allocation” actually means in a contract

Risk allocation is not a slogan, it is a list of specific questions a contract has to answer, each with a named owner:

• Model performance. Who is responsible when the model’s output quality drifts or degrades after go live, and how is that measured.
• Data quality and provenance. Whose job is it to confirm the training and input data is fit for purpose, licensed, and not contaminated.
• Human oversight. What checking is the customer expected to do before relying on an output, and what happens if that oversight is skipped.
• Security. Who is accountable for the security of the model, its data pipeline, and any integration points.
• Monitoring. Who watches the system in production, how often, and who sees that data.
• Remediation. When something goes wrong, who pays to fix it, and who pays for the consequences downstream.

Left unallocated, every one of these risks defaults to whichever generic warranty clause happens to catch it, which is rarely the party best placed to manage it and rarely the outcome either side actually intended.

What to ask a supplier before you sign

• What risk domains does your own assessment cover, and does it map onto the categories DSIT sets out, or something narrower.
• What evidence backs any performance or accuracy claim, and can we see it before we commit spend.
• How are model updates tested and communicated before they reach our production environment.
• What human oversight does the product assume on our side, and is that documented anywhere we can rely on.
• What monitoring and incident data will you share with us, and how quickly after an incident occurs.
• Who owns the cost of remediation if the model underperforms once it is live with our customers or staff.

A supplier that answers all six without hesitation has done the work already. A supplier that treats any of them as a surprise is telling you where the gap in the contract needs to sit.

What actually needs to be in the agreement

• Performance warranties tied to measurable acceptance criteria, not marketing language about accuracy or reliability.
• A data quality and provenance warranty, covering both training data and any data the customer feeds in.
• A human oversight clause stating precisely what the customer is expected to check, so responsibility cannot be assumed away from either side after the fact.
• Security and monitoring obligations with a defined reporting cadence, not “reasonable efforts” left undefined.
• A remediation mechanism, including service credits or fix timelines, so a failure has a contractual consequence rather than just an apology.
• An indemnity that reaches AI-specific harm, biased, unsafe or materially wrong output, and not only the general IP infringement and confidentiality wording carried over from ordinary SaaS terms.

None of this requires a bespoke framework built from scratch. It requires treating the DSIT toolkit’s risk categories as a checklist against your existing master services agreement, and being honest about which ones the current wording actually reaches.

What it costs to skip this

There is no penalty regime attached to the toolkit itself, so the immediate risk of ignoring it is not regulatory. It is commercial. A standard software warranty was written for bugs and downtime, not for model drift, data poisoning, or a biased output reaching a real customer. Without a contract that says otherwise, that gap is absorbed by whoever bought the tool, in full, after the fact, when it is most expensive to fix.

The second cost is quieter and arrives earlier: as enterprise buyers start benchmarking suppliers against the DSIT toolkit during due diligence, a supplier who cannot evidence its own risk assessment risks losing the deal before price is ever discussed. Risk allocation, done properly, is now a competitive advantage as much as a defensive one.