An AI governance committee at a mid-size asset management firm approves the deployment of an NLP sentiment model that scores corporate earnings call transcripts on a scale of –1.0 to +1.0 to generate a management credibility signal. Six months into live deployment, a compliance audit reveals that the model was trained on a dataset of transcripts supplied by a third-party vendor in which all forward-looking statements containing negative qualifiers (e.g., 'risk,' 'uncertainty,' 'decline') had been redacted to satisfy the vendor's content licensing restrictions. The model's training corpus systematically underrepresents negative management sentiment. This situation most directly illustrates a failure in which governance control?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Nobody checked what was actually in the training data before building the model. The vendor redacted the negative language for licensing reasons — and nobody asked 'wait, are these transcripts complete?' before feeding them into the sentiment model. A model trained on selectively sanitized transcripts will score every CEO as slightly rosier than they actually are. This is a data due diligence failure at the governance level — it should have been caught before the first line of training code was written.
Full explanation below image
Full Explanation
AI data governance in investment management extends well beyond model validation into the upstream process of data sourcing, vetting, and documentation. The failure described here is a third-party data due diligence failure: the training dataset was materially altered by the vendor for licensing compliance reasons, and the AI development team either did not know this or did not assess its implications before training.
A robust AI data governance framework for financial applications — aligned with frameworks such as the SEC's guidance on AI in investment advisory, the FCA's machine learning in financial services discussion paper, or internal AI governance standards modeled on SR 11-7 (model risk management) — requires explicit documentation of data provenance at the point of model development. This includes: the identity and version of every training dataset, the vendor's content terms and any content restrictions or modifications, a completeness audit comparing training data against the expected full-text corpus, and a bias assessment examining whether any modifications systematically skew the label distribution.
In this case, redacting negative forward-looking statements creates a training corpus with a positive sentiment bias. The model learns that 'normal' executive language is measured and constructive (because all the alarming language was removed), making it structurally unable to detect warning signals in live transcripts. This is not a model drift problem (the model's parameters did not change), not an explainability problem (attention weights would show the model attends to remaining positive language, which it was trained to do), and not a holdout-set validation problem (the bias exists in both training and test sets if drawn from the same vendor corpus).
The correct control — third-party data due diligence — is a pre-development governance gate that requires any externally sourced training dataset to be assessed for completeness, representativeness, and potential licensing-driven alterations before it is used to build or fine-tune a production model.