AI Due Diligence for SaaS Vendors: The Evidence Pack

An enterprise deal for a SaaS product with AI features now runs into a second security review. The first one covers hosting, access control and data protection. The second asks about the model inside the feature: who built it, what it was trained on, what it is allowed to do, how you test it, and what changes when the provider ships a new version. A chief technology officer who cannot answer those questions in writing watches the deal sit in procurement while the buyer's risk team waits.

The pressure is structural. KeyBanc's 16th annual Private SaaS Survey found that 67% of private SaaS companies already monetise AI themselves, so AI features are now part of what many SaaS vendors sell. On the buyer side, McKinsey's State of AI survey reports that 88% of organisations use AI in at least one function while only 33% have it in production, and the gap between the two is where procurement and risk teams live.

This guide is for the CTO or VP Engineering of a UK SaaS company who owns the answer. It covers the evidence a SaaS vendor can now demand from its own model provider under the EU AI Act, how to turn that into an evidence pack the buyer's questionnaire can be answered from, and how to keep the pack true as models change. It deliberately cedes three neighbouring frames: the sector overview sits in our AI for SaaS companies hub, the technical design of a five-layer evaluation harness sits in our evaluation harness engineering post, and the buyer-side mechanics of running a security questionnaire sit in our AI security questionnaire guide.

This guide is shipped by the team behind DATS, the five-stage AI consulting system from DILR.AI, delivered by senior practitioners who ship code, not decks. Or see our AI operating model work, which covers governance, RACI and lifecycle, audit-ready by design.

What does enterprise AI due diligence ask a SaaS vendor in 2026?

Enterprise AI due diligence asks a SaaS vendor to evidence four things about each AI feature: which model sits underneath and who provides it, what data the feature sends to that model and whether it is retained, how the feature is tested before and after release, and who inside the vendor owns it. We recommend holding those answers as documents, not as reassurance on a sales call.

In our experience the questions arrive in a few shapes: an AI annex added to the questionnaire a buyer already sends, or a published AI question set adopted as it stands. Regulated buyers, particularly in financial services, may also ask how the feature fits their own model risk and outsourcing rules, which is why our guide to the UK sector regulators' AI risk expectations is useful reading for any SaaS team selling into banks.

What changed in 2025 and 2026 is that a SaaS vendor is no longer guessing at the upstream half of the answer. The EU AI Act now obliges the companies that build general-purpose models to hand documentation down the chain, which means the vendor can source the model facts from the party that actually holds them. The rest of this guide is about collecting that documentation, adding the vendor's own layer on top, and keeping both current. The DATS methodology covers governance, RACI and lifecycle in its operating model stage, which in our view is where an evidence pack like this belongs.

The cost of not doing it is commercial. In our view, a deal that stalls in AI review stalls at an expensive point, after the buyer has decided it wants the product. An evidence pack that exists before the questionnaire arrives turns a round of follow-up calls into a document exchange.

What must your model provider give you under Article 53 and Annex XII?

Under Article 53(1)(b) of the EU AI Act, a provider of a general-purpose AI model must draw up, keep up to date and make available documentation to providers of AI systems that integrate the model. A SaaS company building an AI feature on that model is such a downstream provider, and the minimum content is set out in Annex XII. The duty binds the model provider, not the SaaS company.

That obligation has applied since 2 August 2025, when Chapter V of the Act came into application under Article 113. Article 53(1)(b) sets the purpose of the documentation plainly. It must:

"enable providers of AI systems to have a good understanding of the capabilities and limitations of the general-purpose AI model and to comply with their obligations pursuant to this Regulation"

That wording comes from the Official Journal text of Regulation (EU) 2024/1689. The second half of the sentence matters most to a SaaS vendor: the documentation exists so that you can meet your own obligations, which is a reasonable basis for asking for it.

Annex XII then lists the minimum content in two sections. Section 1 is a general description of the model, with eight items: the tasks the model is intended to perform and the AI systems it can be integrated into; the acceptable use policies; the date of release and methods of distribution; how it interacts with hardware or software outside the model; the versions of relevant software; the architecture and number of parameters; the modality and format of inputs and outputs; and the licence. Section 2 describes the elements of the model and its development, with three items: the technical means required for integration, such as instructions for use and tools; the modality, format and maximum size of inputs and outputs, such as context window length; and information on the data used for training, testing and validation, where applicable, including its type, provenance and curation.

Three practical points follow. First, providers whose models were on the market before 2 August 2025 have until 2 August 2027 to comply, under Article 111(3), so documentation for older models may still be thin. Second, the General-Purpose AI Code of Practice, published on 10 July 2025, includes a Model Documentation Form in its Transparency chapter, which gives providers that sign it a standard shape for this material. Third, Article 53(2) exempts providers of models released under a free and open-source licence whose weights, architecture information and usage information are publicly available from the Article 53(1)(a) and (b) duties, unless the model carries systemic risk. If your feature runs on an open-weight model, the public model card and repository are your source, and the gap-filling falls to you.

When does fine-tuning make a SaaS company a model provider?

A SaaS company that fine-tunes or modifies a general-purpose model becomes a provider of that model only in exceptional circumstances, according to the European Commission: when the modification uses more than one-third of the original model's training compute. The Commission says this high threshold means most fine-tuning, adaptations and minor modifications will not make developers providers of the model.

The Commission published its guidelines on the scope of obligations for general-purpose AI model providers on 18 July 2025. Its accompanying questions and answers set out two thresholds a CTO should know. The indicative test for whether a model is general-purpose at all is training compute above 10^23 floating point operations plus the ability to generate language, text-to-image or text-to-video, with exceptions. And where a modifier does cross the one-third line, the Commission limits its documentation duty to the modification itself, meaning the changes made and the new training data used, rather than the whole model.

For the evidence pack, the consequence is simple. Record what you did to the model: base model and version, the fine-tuning data and its provenance, the compute used if you trained at all, and the evaluation results before and after. A buyer asking "is this your model or theirs?" gets a factual answer, and if your compute ever approaches the threshold, you find out from your own records rather than from a regulator. Our enterprise AI consulting guide covers where this sits in the wider move from pilot to production.

Which question sets will the buyer's AI questionnaire draw on?

A UK enterprise buyer's AI questionnaire often draws on one of three public frameworks: the Cloud Security Alliance AI Controls Matrix and its AI-CAIQ question set, ISO/IEC 42001 for AI management systems, and the NIST AI Risk Management Framework. In our experience, a SaaS vendor that maps its evidence pack to all three can answer many bespoke questionnaires by cross-reference rather than by rewriting.

The CSA AI Controls Matrix contains 243 control objectives across 18 security domains, builds on CSA's Cloud Controls Matrix, and maps to ISO 42001, ISO 27001, NIST AI RMF 1.0 and BSI AIC4. It ships with the AI-CAIQ, a set of questions CSA describes as suitable for a self-assessment or an evaluation of third-party vendors, and a guide to submitting that self-assessment to the STAR for AI registry. A buyer who sends you AI-CAIQ questions is asking you to evidence controls you can see in advance, which is the strongest argument for building the pack before the request.

ISO/IEC 42001:2023, published in December 2023 by the joint ISO and IEC committee on artificial intelligence, defines an AI management system: the policies, roles, risk processes and lifecycle controls around AI rather than the behaviour of one model. Our ISO 42001 procurement guide explains what a certificate does and does not prove, and the scope-statement trap buyers fall into. The NIST AI Risk Management Framework, released on 26 January 2023, is intended for voluntary use, and some buyers, particularly those with US parents, frame their questions in its terms.

The buyer has more help than it used to. The Department for Science, Innovation and Technology's Assuring a Responsible Future for AI, published on 6 November 2024, estimated 524 firms supplying AI assurance goods and services in the UK, including 84 specialised AI assurance companies, against 17 identified in the government's 2023 AI Sector Study. That gives a large customer somewhere to send your answers for independent review, which is a good reason to keep them precise.

What belongs in a SaaS AI feature evidence pack?

A SaaS AI feature evidence pack holds one record per AI feature, combining the upstream model facts the provider supplies with the vendor's own facts about how the feature uses the model. We recommend it covers model identity and version, intended use, data flows, evaluation results, transparency, change management, incident handling and a named owner. Each entry should point to a document, not a promise.

The table below is our recommended structure, not a regulatory template. The first column names the evidence item and the second says what the buyer is really asking; the last two columns say where the answer comes from and who inside the vendor should hold it.

Two items deserve a note. On data flow, a buyer will want to know whether the model provider is a sub-processor and how it was authorised, which our sub-processor authorisation guide covers in detail. On transparency, Article 50 duties for chatbot and generated-content features have applied since 2 August 2026, and providers of generated-content systems already on the market before that date have until 2 December 2026 for the marking duty in Article 50(2), under Article 111(4). Our Article 50 disclosure guide covers the disclosure duty in detail and the FAQ below covers when a UK company is caught, so this pack only records your conclusion and its basis.

If you want help building the pack alongside your own team, our AI execution office is the embedded DATS engagement, with production placements the client owns.

How do you keep the evidence pack true as models change?

A SaaS vendor keeps its AI evidence pack true by tying every entry to a model version and re-running the relevant checks whenever that version changes. Pin the model version in production, log every provider update, re-run evaluations before promoting a new version, and update the pack in the same change. An evidence pack that describes last quarter's model is worse than none, because it is confidently wrong.

Model providers ship new versions, and Annex XII asks them to state the model's date of release and methods of distribution, which gives you a dated reference point; the exact version your feature calls still has to come from your own records. In practice we recommend four habits. Keep a register of every AI feature and the exact model version it calls; our AI tool inventory guide sets out the columns regulators expect, and they transfer well to a vendor's own register. Subscribe to the provider's deprecation and release notices and assign someone to read them. Gate version changes behind your evaluation suite, with the results filed in the pack. And write the change into the customer-facing record when it alters behaviour the customer relies on.

The evaluation suite is where most packs are weakest. Buyers do not need your test code, but they do need to see that a defined set of cases runs before release, what it measures, and what threshold blocks a release. The evaluation harness engineering post covers how to build the layers themselves, including drift detection and regression testing. One of the six named DATS solutions on our enterprise AI solutions page is evaluation and observability for production agents, which is the same problem viewed from the run side.

Change also runs upstream of the model. If your provider relies on other providers for hosting, safety filtering or retrieval, the chain is longer than it looks, and our AI supply chain assurance guide shows how to map it and which links you can audit and which you can only monitor. For a SaaS pack, a one-line chain diagram per feature is usually enough.

Who should own AI due diligence inside a SaaS company?

AI due diligence inside a SaaS company works best with one accountable owner, usually the CTO, and named contributors for each part of the evidence pack: engineering for model, version and evaluation records, product for intended use and transparency, data protection for data flows, and the security team for questionnaire assembly. Without a single owner, each questionnaire becomes a new project.

The owner's job is not to write every answer. It is to make sure the pack exists, is current, and is the only source sales and security teams answer from. That last point is the one that fails most often in practice: a sales engineer under deal pressure answers a question from memory, the answer drifts from the pack, and the inconsistency surfaces in the next renewal review.

A light operating rhythm helps. Review the pack whenever a feature ships or a model version changes, and on a fixed cadence otherwise. Keep a log of questions buyers asked that the pack could not answer, because those are next quarter's additions. And agree in advance which items are shared openly, which under NDA, and which only in a buyer's data room. Ownership of this kind is a governance question, and governance, RACI and lifecycle are what the DATS operating model covers, and our post on AI operating models versus centres of excellence covers where that ownership sits structurally.

There is also a commercial reason to own this deliberately. When the buyer's questions are answered quickly and consistently, AI review stops being the step where the deal waits. That is a revenue outcome, which is why the CTO and the chief revenue officer should both care who owns the pack.

What is the best way to answer enterprise AI due diligence in 2026?

The best way for a UK SaaS vendor to answer enterprise AI due diligence in 2026 is to build a standing evidence pack per AI feature, sourced from the model provider's Annex XII documentation and mapped to the CSA AI Controls Matrix, ISO 42001 and NIST AI RMF. The right route to building it depends on what the buyer demands, and no single route wins every case.

Judged on three criteria, which are what the buyer will accept, how fast the pack exists, and whether it stays current after the first deal, the options fall out like this.

If your largest customers demand third-party attestation, a certification route wins. An accredited ISO 42001 certification, or an assurance engagement from an audit firm such as Deloitte, PwC, EY or KPMG, produces third-party evidence an internal pack cannot provide on its own. The trade-off is time and scope: a certificate covers a defined management system, and the buyer will still ask about individual features.

If you need the pack quickly and have engineering capacity, building it in-house wins. A team with good architecture records can assemble a first version from those records and the provider's documentation without outside help. The risk is that it decays once the person who built it moves on.

If the gap is less the document than the operating habit behind it, the governance, ownership and evaluation discipline that keeps the pack true, that is where an AI consulting partner earns its place. AI consultancies of very different sizes sell this kind of help, from global integrators such as Accenture to UK technology consultancies such as Kainos. DATS, from DILR.AI, is a five-stage system that starts with a diagnostic producing a ranked roadmap of where AI belongs and where it does not, and whose operating model covers governance, RACI and lifecycle, audit-ready by design. Read about our approach to placing AI inside enterprise systems. A team that already has a working pack and a named owner probably does not need outside help for this step at all.

Does a UK SaaS company need to comply with the EU AI Act at all?

A UK SaaS company falls within the EU AI Act when it places an AI system on the EU market or when the output of its AI system is used in the EU, even though the UK has no equivalent statute. For a UK SaaS vendor with European customers, that means its own Article 50 transparency duties apply, while the Annex XII documentation duty sits with its model provider.

The second limb comes from Article 2(1)(c) of the Official Journal text, which covers providers and deployers located in a third country where the output is used in the Union. Even where a feature is UK-only, enterprise buyers may still ask the same questions. Our post on the EU AI Act Omnibus delay explains which obligations moved and which did not: under the amended Article 113, high-risk duties for Annex III systems now apply from 2 December 2027 and for Annex I systems from 2 August 2028, while the general-purpose model chapter has applied since 2025.

What if your model provider will not share the Annex XII information?

If a model provider will not share Annex XII information, a SaaS vendor should first check whether the model was placed on the market before 2 August 2025, because those providers have until 2 August 2027. Otherwise, record the request and the response in the evidence pack, and treat the gap as a supplier risk the buyer may ask about.

Article 53(1)(b) applies without prejudice to intellectual property rights, confidential business information and trade secrets, so expect summaries rather than raw data, particularly on training data. That is a reason to ask precise questions mapped to the Annex XII items rather than general ones. A provider that signs the Code of Practice and uses its Model Documentation Form gives you a predictable format, which is worth weighing when you choose between providers.

Do open-weight models change the evidence pack?

Open-weight models change where the evidence comes from, not what the evidence pack must contain. Under Article 53(2) of the EU AI Act, a provider of a model released under a free and open-source licence with public weights, architecture and usage information is exempt from the downstream documentation duty, unless the model carries systemic risk. The SaaS vendor fills the gap itself.

In practice that means assembling the model card, licence, published evaluation results and repository history yourself, then adding your own testing on top. Running an open-weight model inside your own cloud on Azure, AWS or Google Cloud can simplify the data-flow answer, because customer data need not leave your environment, but it moves the evaluation burden firmly onto your team. Our AI for SaaS companies hub sets out where AI pays first for a UK SaaS business once that groundwork is done.

Want to put this in place? See how DATS AI consulting runs, browse our enterprise AI solutions, read about Dilr.ai, or explore more industry AI guides from the team.

Written by the Dilr.ai engineering team, practitioners who ship enterprise AI in production. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.