Meridian Regional Airlines' demand-forecasting model uses booking data from European codeshare partners, including passengers based in the European Union. A passenger emails asking Meridian to delete their personal data from the forecasting system. What GDPR-related obligation must the AI project account for?

The correct answer is that the project must have a defined, workable process to identify and remove or de-identify an individual's personal data across every data store it touches, including training and inference pipelines, not only a single customer-facing database. GDPR-style compliance treats data-subject rights, including erasure, as operational requirements a project must plan for from the start, and CPMAI frames this as a project-management obligation rather than an implementation detail to defer. The 'aggregated output' distractor is a common trap: the model's final forecasts may be aggregated, but the underlying training data pipeline typically still contains identifiable or linkable individual booking records upstream of that aggregation, and the obligation attaches to the personal data being processed, not only to the shape of the final output. Limiting the obligation to Meridian's own employees ignores that GDPR protects any EU-based data subject whose personal data is processed, including codeshare-partner passengers, regardless of who employs them. Conditioning the obligation on the issuing bank of a payment card invents a criterion GDPR does not use; the relevant factors are the data subject's location and the nature of the processing, not a payment instrument's country of issuance. Planning for erasure operationally, across every pipeline a project owns, is the discriminator the exam is testing here.