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?

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 such as a sensor firmware update, a schema change from a source system, or 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 the Model Evaluation phase; here the concern is the data pipeline itself. The vendor lock-in concern is unrelated, because vendor lock-in is a procurement or architecture concern, not what pipeline-level data monitoring addresses. The claim that this capability replaces the need for a data management plan 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. The cost-of-storing-historical-training-data concern 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: this enabler is about catching problems in the data feeding the pipeline, before they ever reach the model.