Quick Read
Section 10.16 of SPK DDMS2000:2026 addresses a specific governance risk: AI-assisted due diligence findings can appear polished and confident while being factually wrong, creating an unintended lowering of evidentiary standards if organisations cannot reliably distinguish correct outputs from incorrect ones. The standard requires organisations to maintain inventories of all AI tools in use, calibrate human verification requirements upward (not downward) with the stakes of each finding, and retain underlying source material to ensure AI summaries and conclusions remain traceable to evidence rather than standing as evidence themselves. These controls apply across the entire due diligence lifecycle and work alongside competence requirements to govern AI use without prohibiting it.
Why This Whitepaper Exists
AI-assisted tools are now a routine part of due diligence research — summarising adverse media, aggregating screening results, drafting findings, translating source material across languages an analyst may not read. None of this is, in itself, a problem SPK DDMS2000:2026 is trying to prevent. The problem the standard addresses at Section 10.16 is narrower, and in some ways harder to see: an AI-assisted finding can look exactly as polished and confident as a properly researched one while being wrong, and a due diligence process that cannot reliably distinguish the two has quietly lowered its own evidentiary bar without anyone deciding to lower it.
This matters more, not less, as these tools improve. A visibly poor AI output is easy to catch — an analyst notices the summary is incoherent or the citation is obviously wrong. A fluent, well-formatted, confidently wrong output is the genuinely dangerous case, because it passes a casual read exactly as well as a correct one does. Section 10.16 is built around this specific risk, not around AI use in general.
An AI summary or conclusion is not itself evidence, and the organisation shall retain and be able to produce the underlying source material a finding is based on.
What the Standard Actually Says
Section 10.16 is cross-cutting, applying to AI use in any of the modules in Section 10.5 through 10.24, and works alongside the AI-related competence requirements at Section 9.3.8 and 9.3.9. Each of its seven requirements addresses a distinct point in the lifecycle of an AI-assisted finding, from inventory through to error tracking.
10.16.1 — Know what tools are actually in use
The organisation must maintain an inventory of AI tools used anywhere in the DD lifecycle — research, screening, drafting, summarisation, translation, or risk scoring — recording each tool's intended use, data sources, and known limitations. This sounds administrative, but in practice it is the control that catches the most common failure mode: informal AI use by individual analysts, adopted case by case without ever being formally approved, inventoried, or governed. A tool an organisation does not know it is using cannot be subject to any of the other requirements in this section.
10.16.2 — Scale verification up with stakes, not down
The organisation must determine, per tool and per use case, the level of human review required before an AI-assisted output can be relied upon, calibrated to the DD tier. The clause is explicit about direction: higher-tier DD requires a higher standard of human verification, not less. This runs directly against a common informal instinct — trusting AI tools more, not less, on the most consequential cases, because the volume of material to review is often largest precisely where the stakes are highest, and time pressure pushes toward accepting the tool's output rather than interrogating it.
10.16.3 — The evidentiary rule
An AI summary or conclusion is not itself evidence. The organisation must retain and be able to produce the underlying source material a finding is based on. This connects directly to the evidence and source quality standard at Section 10.4.8 — an AI-generated finding is held to exactly the same corroboration bar as a human-generated one, with no exception carved out for how it was produced. A case file that cites an AI tool's conclusion, with no retrievable underlying source, fails this requirement regardless of whether the conclusion happens to be accurate.
10.16.4 — Naming the failure modes
The organisation must assess and document known failure modes relevant to DD use, and put proportionate mitigations in place.
Failure mode | What it looks like in a DD context | A mitigation worth considering |
|---|---|---|
Hallucination | A plausible adverse media summary or corporate history detail with no basis in any real source | Mandatory source-link verification before a finding leaves draft status |
Training-data staleness | Confident description of ownership, sanctions status, or leadership as current when the underlying data predates a material change | Cross-check AI-derived ownership or status claims against a live screening source, not the tool's own training data |
Source fabrication | A citation attached to an AI finding that does not exist, or does not say what the finding claims | Random-sample citation spot-checks as a standing QA practice, not only when something looks wrong |
Coverage bias | Weaker or uneven coverage of non-English-language media or certain jurisdictions, producing a falsely clean result | Explicit tool validation across the organisation's actual jurisdiction and language mix, not only the vendor's default benchmark |
Coverage bias deserves particular attention because it is the failure mode least likely to be caught by a reviewer working in the same language and jurisdiction the tool happens to perform best in. An organisation whose due diligence subjects span multiple jurisdictions and languages should specifically test whether its AI tools perform consistently across that range, rather than assuming a tool validated on English-language, well-documented subjects performs equally well on a subject based in a jurisdiction with thinner digital records.
10.16.5 — Interoperating with an existing AI management system
Where the organisation already maintains an AI management system conformant to ISO/IEC 42001, it may cross-reference and rely on that system's controls — model risk assessment, data governance, incident management — rather than establishing parallel controls under this standard. This is a deliberate design choice: SPK DDMS2000:2026 does not ask organisations to build AI governance twice. The cross-reference should be recorded explicitly in the Applicable Obligations Register, consistent with the standard's general approach to ISO interoperability elsewhere.
10.16.6 and 10.16.7 — Logging and separated error tracking
AI tool use must be logged at the individual DD-file level, sufficient to demonstrate on audit which parts of a given finding were AI-assisted and what human verification was applied to them. AI-related errors identified through QA sampling must be tracked as their own category, distinct from human analyst error. This separation is not a bureaucratic nicety. A rising error rate driven by a specific tool's declining reliability calls for revalidating or replacing that tool; a rising error rate driven by human reviewers becoming complacent about verifying AI output calls for a completely different intervention. Blended error reporting cannot distinguish these two problems; separated reporting can.
The Competence Connection
Section 10.16 does not operate in isolation from the competence framework addressed elsewhere in this series. Section 9.3.8 requires that a competent human remain accountable for reviewing and accepting AI-assisted output, and Section 9.3.9 goes further, naming the ability to critically evaluate AI-assisted output as its own explicit competence requirement, distinct from module-specific knowledge. An analyst who cannot recognise a plausible-sounding but unsupported AI output is not competent for the purposes of this standard, regardless of how much general training they have completed. A well-governed AI tool used by an analyst who cannot critically evaluate its output still produces exactly the failure Section 10.16.3 is designed to prevent — governance and competence have to work together, not as substitutes for each other.
Building AI Governance in Practice
Start the inventory with informal use, not formal procurement
The tools most likely to be missing from a first-pass inventory are not the enterprise platforms the organisation formally procured — those tend to already be visible. It is the AI features embedded in everyday productivity software, or the free-standing tools individual analysts have adopted informally, that create the real gap against Section 10.16.1.
Define verification tiers before you need them, not case by case
Section 10.16.2's tier-scaling requirement is easiest to satisfy consistently if the organisation defines, in advance, what “higher standard of human verification” actually means at each tier — full source re-derivation at Tier 4, spot-check corroboration at Tier 2, for example — rather than leaving the level of scrutiny to each reviewer's individual judgement in the moment.
Make the source link a structural requirement of the case file template
Section 10.16.3 is far easier to satisfy consistently if the case management system's file structure requires a source link for every AI-assisted finding before the case can be submitted, rather than relying on analyst discipline to remember to attach one.
Validate tools against your own jurisdiction and language mix
Vendor-provided accuracy benchmarks are rarely built around any specific organisation's actual subject population. Organisations with meaningful non-English-language or lower-documentation-jurisdiction exposure should run their own validation exercise against representative subjects before trusting a tool's general reputation.
Common Misconceptions Worth Correcting
“Our AI tool is well known and widely used, so we don't need to validate it ourselves.” Reputation is not the same as validation against an organisation's own specific subject population and language mix.
“Senior analysts can be trusted to verify AI output without a defined tier-based standard.” Section 10.16.2 requires the verification standard itself to scale with tier — informal trust in seniority is not a substitute for a documented standard.
“If the AI tool cites a source, that satisfies the evidence requirement.” Section 10.16.3 requires the underlying source material itself be retrievable and producible — a citation the organisation cannot independently verify does not satisfy this.
“We already have an AI policy, so Section 10.16 is covered.” A policy document is not the same as the specific inventory, tiered verification standard, file-level logging, and separated error tracking the clause actually requires.
Common Gaps Worth Checking
No inventory of AI tools used across the DD lifecycle exists, or the inventory omits tools adopted informally by individual analysts.
Human verification requirements are the same, or lighter, for Tier 3–4 cases than for Tier 1–2, rather than scaling up as Section 10.16.2 requires.
A finding traces back to an AI-generated summary with no underlying source material retained or producible.
Coverage bias across languages and jurisdictions has never been specifically tested, only assumed not to be a problem.
QA error tracking does not distinguish AI-related errors from human analyst errors, obscuring which is actually driving quality trends.
How Speeki Sentinel Certification Assesses This
Certification against SPK DDMS2000:2026 tests whether the AI tool inventory is current and complete, whether human verification requirements genuinely scale with DD tier rather than only on paper, and whether a sample of AI-assisted findings can be traced back to retrievable underlying sources. An unsupported AI-generated finding in the case sample is treated as a gap against Section 10.16.3, regardless of how accurate the finding happened to be.
Speeki Sentinel is the certification product through which this assessment is delivered. Organisations may build and operate their own AI governance framework on a self-assessed basis, including bridging to an existing ISO/IEC 42001 system where one exists, without ever seeking Speeki Sentinel certification. Speeki Sentinel certification — the independent verification of that DDMS against the standard — is available once an organisation believes its framework is ready to be independently tested.
Speeki is an accredited certification body. For current information on the specific accreditations Speeki holds and their scope, please refer to speeki.com rather than relying on this whitepaper, as accreditation status and scope are maintained centrally and can change.
Closing Note
Section 10.16 does not ask organisations to distrust AI-assisted tools, or to stop using them. It asks organisations to keep one specific fact in view at all times: a confident, well-formatted AI output and a verified finding are not the same thing, and the gap between them only closes when a competent human, working to a defined standard, checks the underlying source. Governance, in this context, is not a brake on using AI — it is the mechanism that keeps a human genuinely inside the process rather than merely present alongside it.