Essential AI Model Provenance for AIGP
A leaked Australian diplomatic cable, summarised by the Taipei Times, accuses DeepSeek of building parts of its models through unauthorised distillation of Western frontier systems. American agencies have flagged the company as a national security concern. For an AIGP candidate, the regulatory drama matters less than the underlying question. Do you know where your AI model came from, what trained it and whether the legal rights to that lineage carry through to your deployment? AI model provenance is the hinge that Domain III.B turns on, and exam scenarios will not let you avoid it.
Three Core AI Model Provenance Questions
The IAPP's Body of Knowledge (BoK) for the AIGP exam defines every topic the exam covers. It places lawful data sourcing at the centre of Domain III.B. The DeepSeek case extends that question one step back, into the upstream model itself. Three sub-questions structure the AI model provenance analysis examiners expect every candidate to perform.
Question One: Where the Training Data Came From
Domain III.B.1 expects you to assess lawful rights to collect and use data; it then asks you to evaluate quality, integrity and fit-for-purpose. When the data is another model's outputs, the AI model provenance question multiplies. Did training use copyrighted material under a licence that travels to derivative works? Did synthetic outputs come from terms that prohibit redistribution? Article 53 of the EU AI Act now obliges general-purpose AI providers to publish a sufficiently detailed summary of training content. That summary gives downstream deployers a starting point. The GPAI model obligations on transparency are exam favourites; absence of documentation is itself a compliance signal.
Question Two: Whether Safety Mechanisms Survived
Domain I.C.3 covers AI's complexity, opacity and probabilistic behaviour. Domain IV.A.2 asks you to distinguish proprietary, open-source and distilled models on risk. Distillation can preserve task performance while shedding the safety classifiers and refusal behaviours that the upstream provider invested in. The student model inherits capability without inheriting controls. For an AIGP candidate, this is not a technical curiosity. It is why Domain IV.A's deployment-options assessment cannot rest on benchmark performance alone. It is also why the NIST AI Risk Management Framework treats AI model provenance as a Govern function.
Question Three: What Downstream Training Created
Domain III.B.2 requires data lineage and provenance documentation through training and testing; Domain IV.B.2 covers vendor and licensing risk. Fine-tuning, retrieval augmentation and distillation each modify a model's behaviour, and each creates fresh AI model provenance obligations. The fine-tuned model is, in regulatory terms, a different artefact from the base. Its outputs may inherit upstream IP exposure while introducing new contract-of-use restrictions tied to the fine-tuning data. Examiners reward candidates who treat downstream modification as a provenance event of its own, not an inherited continuation of the base model's compliance posture.
AI Model Provenance and the IP-Contract Line
Domain II.B.1 covers intellectual property as it applies to AI; Domain II.B.4 covers product liability. AIGP candidates need to articulate the difference between an IP problem and a contract-of-use problem. The same scenario often contains both, and the remedies differ.
An IP problem arises when training or distillation uses material the upstream owner had a legal right to control: copyrighted text, patented algorithms, trade-secret weights. The remedy sits in IP law; damages, injunctions, takedowns. A contract-of-use problem arises when the deployer accessed the upstream model under terms of service that prohibited certain downstream uses, even without IP infringement. The remedy sits in contract; termination, indemnities, breach-of-licence claims. The OECD AI Principles frame both as part of accountability rather than as separate silos.
The DeepSeek allegations sit on the line. If frontier providers' terms forbade outputs from training competing models, distillation breaches contract regardless of whether copyright applies to model weights. If scraping built the underlying training corpus without licence, IP law engages independently. AIGP scenarios test both legs, and candidates who collapse the distinction lose marks. This is the hidden trap inside vendor governance scenarios; the contract leg often carries the heavier liability.
Exam Framing Around Model Provenance
Three question stems are worth practising. First: a deployer integrates a third-party fine-tuned model into a hiring tool. Which obligations under Domain IV.B.2 apply, and what does Domain III.A.4 require during the impact assessment? Second: a provider distils a competitor's API outputs to train a smaller model for European deployment. Which Article 53 obligations attach to the resulting model? How does the provider, deployer and importer distinction in Domain II.C.6 shift once the provider open-sources it? Third: a deployer discovers that the base model's training data includes material now subject to a takedown order. Which Domain III.C obligations apply, and when does Domain IV.C.7 deactivation become a live option? AI model provenance reasoning is what separates a passing answer from a guess.
Practising AI Model Provenance Reasoning
How do organisations actually document model lineage today? In most cases not at all, beyond the vendor's word and a redacted training-data summary. That gap is precisely where Domain III.B and IV.B intersect on the exam. It is also where examiners probe candidates who have memorised definitions but not learned to reason. Share how your organisation handles it in the AIGP study group. Compare your practice with your peers'. The AI model provenance reasoning the scenarios expect will start to feel routine.
