Meridian's fraud-detection pipeline has been running for a year, and the PM wants the pipeline itself, not just the model's output, to surface a warning when the incoming data's format, volume, or statistical properties suddenly change from what the pipeline expects. What is this pipeline-level capability primarily protecting against?
Select an answer to reveal the explanation.
Short Explanation
A pipeline that quietly starts receiving different data than it was designed for is a slow-motion failure — the model degrades and nobody knows why until it's too late. Built-in monitoring at the pipeline level is how you catch that early, before it shows up as bad predictions.
Full Explanation
Engineering AI-optimized pipelines includes monitoring for changes in incoming data's format, volume, or statistical distribution at the pipeline level, so that upstream changes (a sensor firmware update, a schema change from a source system, a shift in data volume) are caught early rather than silently degrading downstream model performance. This complements, but is distinct from, model-level drift monitoring covered in Domain II's Model Evaluation phase — here the concern is the data pipeline itself. Option A is unrelated; vendor lock-in is a procurement/architecture concern, not what pipeline-level data monitoring addresses. Option C is wrong and overstates the capability's scope — pipeline monitoring is an operational safeguard, not a replacement for the governance-level data management plan, which covers retention, quality standards, and access broadly. Option D misattributes the purpose to cost management, when the actual goal is early detection of data problems that could silently harm the AI system. For the exam, keep this distinct from 'model drift' (Domain II): this enabler is about catching problems in the data feeding the pipeline, before they ever reach the model.