AI Training Data Provenance Checker
Vendor-licensed · source class

Credit reference extract

Credit data is personal, regulated and licensed for stated purposes; training a pricing or lending model on it is the purpose question.

What to record for it

The agency, the licence purpose, the fields, the extract date, and the basis for using it in the model.

Personal data is likely: the checker assumes it where your personal data column is blank, labels the assumption, and words any finding that rests on it as a question.

A line that places here

example

Credit reference extract | credit reference agency | vendor licence

Check this line

What the checker reads on these lines

9 of the 12 findings

Clauses

5 regimes
RegimeClause
ISO/IEC 42001ISO/IEC 42001 A.7.3 Acquisition of data
ISO/IEC 42001 A.10.3 Suppliers
NIST AI RMFNIST AI RMF MP-4.1 Legal risks of components and third-party data
NIST AI RMF MN-3.1 Third-party resources monitored
NIST AI RMF GV-6.1 Third-party and intellectual property risk policy
EU AI ActEU AI Act Art. 10 Data and data governance
EU AI Act Art. 17 Quality management system
GDPRGDPR Art. 14 Information where personal data have not been obtained from the data subject
GDPR Art. 28 Processor
UK GDPRUK GDPR Art. 14 Information to be provided where personal data have not been obtained from the data subject
UK GDPR Art. 28 Processor

The clauses, set out

ISO/IEC 42001 A.7.3Acquisition of data

The organization shall determine and document details about the acquisition and selection of data used in AI systems, including provenance and consent where applicable.

What an auditor asks to see: Data acquisition records; Provenance documentation; Consent records; Source identification; Licensing or consent evidence; Selection criteria and rejection rationale
What an auditor will probe: Is data provenance traceable to lawful sources?
Source: ISO/IEC 42001:2023
ISO/IEC 42001 A.10.3Suppliers

Establish a process ensuring that the organization's use of services, products or materials provided by suppliers aligns with its approach to the responsible development and use of AI systems.

What an auditor asks to see: Supplier assessment criteria covering responsible AI; Completed assessments for AI suppliers including model, dataset and component providers; Contract terms binding suppliers to the organization's AI requirements
What an auditor will probe: Standard security due diligence used with nothing AI specific; Datasets and pre-trained models sourced with no assessment; No reassessment when the supplier changes its model
Source: ISO/IEC 42001:2023
NIST AI RMF MP-4.1Legal risks of components and third-party data

Approaches for mapping AI technology and legal risks of its components – including the use of third-party data or software – are in place, followed, and documented, as are risks of infringement of a third-party’s intellectual property or other rights. There is a followed approach for mapping the technology and legal risk carried by each component, including data and software obtained from third parties and the rights position attached to them.

What an auditor asks to see: The documented approach for mapping component technology and legal risk; Component inventory identifying third-party data, models and software; Intellectual property and rights analysis for each third-party component; Evidence the approach was followed for the components actually in use
What an auditor will probe: Approach documented but not applied to components adopted since; Pre-trained models used with no analysis of the provenance of their training data; Rights reviewed for commercial components only, not for freely obtained ones
Source: NIST AI Risk Management Framework
NIST AI RMF MN-3.1Third-party resources monitored

AI risks and benefits from third-party resources are regularly monitored, and risk controls are applied and documented. Third-party data, model, software and hardware dependencies are monitored on an ongoing basis, not assessed once at procurement, and the controls applied are recorded.

What an auditor asks to see: The inventory of third-party resources the AI system depends on; Monitoring records showing regular review of those dependencies; The risk controls applied to each and evidence they are in place; The route by which a third-party change reaches the risk owner
What an auditor will probe: Third parties assessed at onboarding and not monitored afterwards; Model or API version changes by the provider go unnoticed; Controls documented in the contract with no operational evidence
Source: NIST AI Risk Management Framework
NIST AI RMF GV-6.1Third-party and intellectual property risk policy

Policies and procedures are in place that address AI risks associated with third-party entities, including risks of infringement of a third party’s intellectual property or other rights. Third-party AI risk is addressed by policy covering data, models, software and services obtained externally, including the rights position on training data and model outputs.

What an auditor asks to see: Third-party AI policy covering data, pre-trained models, software and services; Due diligence records for third-party AI components in use; Contract terms addressing intellectual property, data rights and liability for AI components; The intellectual property position recorded for training data and model outputs
What an auditor will probe: Standard vendor due diligence applied with no AI-specific questions; Open source models adopted with no review of the licence or the training data provenance; Policy addresses suppliers but not freely obtained models and datasets
Source: NIST AI Risk Management Framework
EU AI Act Art. 10Data and data governance applies if this system is high-risk under Annex III

High-risk AI systems that make use of techniques involving the training of AI models shall use training, validation and testing data that meet the quality criteria in Art.10(2)-(5): appropriate data governance, examination for possible biases, identification of data gaps/shortcomings, statistically relevant datasets to the intended purpose, and considerations specific to the geographical, contextual, behavioural or functional setting of intended use.

What an auditor asks to see: Data governance procedures; Bias examination records and remediation; Data-quality assessment per dataset
What an auditor will probe: Training data used without bias examination; Datasets not representative of the deployment context
Source: EU AI Act
EU AI Act Art. 17Quality management system a provider duty

Providers must put in place a quality management system that ensures compliance with the Regulation, documented systematically in written policies, procedures and instructions, covering at least: a regulatory compliance strategy including conformity assessment and management of modifications; design, design control and design verification techniques; development, quality control and quality assurance techniques; examination, test and validation procedures before, during and after development and the frequency at which they run; technical specifications and standards to be applied and, where harmonised standards are not applied in full, the means used instead; data management systems and procedures spanning acquisition, collection, analysis, labelling, storage, filtration, mining, aggregation and retention; the Art.9 risk management system; the Art.72 post-market monitoring system; Art.73 serious incident reporting procedures; handling of communication with authorities, notified bodies, other operators and customers; record-keeping; resource management including security of supply; and an accountability framework setting out the responsibilities of management and staff for every one of those aspects. Implementation is proportionate to the size of the provider's organisation, but the degree of rigour required to make the systems compliant is not reducible.

What an auditor asks to see: The written quality management system covering all thirteen Art.17(1) aspects, with a cross-reference showing where each is addressed; The accountability framework naming responsibilities of management and staff for each aspect; Change management records for modifications to the high-risk AI system; Test and validation procedures with their defined frequency, and completed records against them; Where harmonised standards are not applied in full, the documented alternative means of meeting the Section 2 requirements; For financial institutions, the mapping of which internal governance arrangements are relied on under Art.17(4), with evidence that points (g), (h) and (i) are still discharged separately
What an auditor will probe: An existing quality system adopted wholesale without checking it covers the AI-specific aspects (g), (h) and (i); The accountability framework named in policy but never allocated to identified roles; Data management procedures documented for training data only, omitting acquisition, labelling, retention and deletion; Proportionality read as permission to omit aspects rather than to scale the depth at which each is addressed
Source: EU AI Act
GDPR Art. 14Information where personal data have not been obtained from the data subject

Where personal data has not been obtained from the data subject, provide the same identity, contact, purpose, legal basis, recipient and transfer information as Article 13, plus the categories of personal data concerned and the source the data came from including whether it was a publicly accessible source. Provide it within a reasonable period and at the latest within one month of obtaining the data, or at the latest at the first communication with the data subject if the data is used to communicate with them, or at the latest when the data is first disclosed to another recipient. The obligation does not apply where the data subject already has the information, where provision proves impossible or would involve disproportionate effort in which case appropriate protective measures including making the information publicly available must be taken, where obtaining or disclosure is expressly laid down by Union or Member State law with appropriate safeguards, or where the data must remain confidential under an obligation of professional secrecy.

What an auditor asks to see: A source register showing, per dataset, where the data came from and whether the source was publicly accessible; Evidence of the notification sent with its date, tested against the one month, first communication and first disclosure triggers; The disproportionate effort assessment where the exemption is relied on, showing what was weighed rather than only that a conclusion was reached; The alternative protective measures put in place under that exemption, including where the information was made publicly available; Supplier contract terms requiring the source of the data and the lawfulness of its collection to be disclosed
What an auditor will probe: Purchased or enriched marketing data used with no Article 14 notification at all, which is the most common finding in this area; Disproportionate effort claimed because notifying is inconvenient or costly rather than genuinely disproportionate; The source recorded as a vendor name with no indication of where the vendor itself obtained the data; Notification sent at the first marketing contact months after the data was obtained, missing the one month limit
Source: GDPR
GDPR Art. 28Processor

Use only processors providing sufficient guarantees to implement appropriate technical and organisational measures such that the processing meets the Regulation's requirements and protects the rights of the data subject. A processor must not engage another processor without the controller's prior specific or general written authorisation, and under a general authorisation must inform the controller of intended additions or replacements so the controller can object. The processing must be governed by a written contract or other legal act binding the processor to the controller, setting out the subject matter and duration, the nature and purpose, the type of personal data, the categories of data subjects and the controller's obligations and rights, and stipulating that the processor processes only on documented controller instructions including as to transfers, ensures persons authorised to process are under a duty of confidentiality, takes all Article 32 measures, respects the sub-processor conditions, assists the controller in responding to data subject rights requests, assists with Articles 32 to 36, deletes or returns all personal data at the controller's choice at the end of the service and deletes existing copies unless law requires retention, and makes available all information needed to demonstrate compliance and allows for and contributes to audits and inspections. The processor must immediately inform the controller if it considers an instruction infringes data protection law. The same obligations must be imposed on any sub-processor, and the initial processor remains fully liable for the sub-processor's performance. A processor that determines purposes and means is a controller for that processing.

What an auditor asks to see: A processor inventory reconciled against the vendor register or accounts payable, so no processor is missing from it; The Article 28(3) contract for each processor, checked clause by clause against the eight stipulations the Article names; Due diligence evidence gathered before appointment showing sufficient guarantees, distinct from the signed contract; The sub-processor authorisation position for each processor, the current sub-processor list, and evidence changes were notified; Audit or assurance rights exercised in practice, such as a report reviewed with findings tracked, and end of service deletion certificates
What an auditor will probe: The processor's own standard terms accepted, which commonly omit the audit right, the deletion choice and the instruction infringement notice; A processor inventory that misses tools adopted directly by individual teams, which is where undocumented processing usually sits; Sufficient guarantees evidenced only by the existence of the contract, with no assessment carried out before appointment; Sub-processor lists published by the processor and never actually reviewed, so the right to object is theoretical
Source: GDPR
UK GDPR Art. 14Information to be provided where personal data have not been obtained from the data subject

Where data come from elsewhere the controller must give the Article 13 information plus the categories of data and the source (including whether publicly accessible), within a reasonable period and at the latest one month after obtaining the data, or at first communication with the data subject, or when first disclosing to another recipient, and must tell the data subject before further processing for a new purpose. The duty falls away where the data subject already has the information, where obtaining or disclosure is expressly required by domestic law with appropriate protections, where professional secrecy requires confidentiality, where providing the information is impossible or would involve disproportionate effort (judged by the number of data subjects, the age of the data and the safeguards), or where it would render impossible or seriously impair the purposes; a controller relying on the last two must protect the data subject's interests, including by publishing the information.

What an auditor asks to see: Notices sent to data subjects whose data came from third parties, with dates; Disproportionate effort assessments and the published information; Record of data sources per data set
What an auditor will probe: Enriched or purchased data used with no notice to the people concerned; Disproportionate effort claimed without a written assessment; Notice sent later than one month after receipt
Source: UK GDPR
UK GDPR Art. 28Processor

A controller may use only processors giving sufficient guarantees of appropriate measures. A processor may not engage a sub-processor without prior specific or general written authorisation, and under general authorisation must notify changes so the controller can object. Processing must be governed by a written contract or legal act setting out the subject matter, duration, nature, purpose, data types, data subjects and the controller's rights and obligations, and requiring the processor to act only on documented instructions (including on transfers), bind its staff to confidentiality, take Article 32 measures, respect sub-processing conditions, assist with rights requests and with Articles 32 to 36, delete or return data at the end, and provide information and allow audits, informing the controller if an instruction infringes the law. Sub-processors carry the same obligations and the processor stays liable for them. The Commissioner may adopt standard contractual clauses; a processor that determines purposes and means is treated as a controller.

What an auditor asks to see: Article 28 compliant processing agreements for every processor; Sub-processor list with authorisation and change notices; Processor due diligence and audit records
What an auditor will probe: Processors engaged on standard terms lacking the Article 28(3) clauses; Sub-processors added without notice; No evidence data were deleted or returned at contract end
Source: UK GDPR

Other sources in vendor-licensed