Governing a model starts with what you fed it.
Model cards and policies describe intent. The obligations that bite are about data: what reached the model, who runs it, what was kept, and whether any of it can be removed.
All of them are data-flow questions.
Which classified fields end up inside a prompt, a fine-tuning set, or an embedding call. This is a taint question and it has a definite answer.
A hosted model provider is a recipient of personal data, whatever the integration looks like in code. If it is not in your RoPA, your RoPA is wrong.
Prompt and completion logs are the new application log: written for debugging, kept indefinitely, full of whatever the user typed.
Erasure has to reach the vector store and the logs, not just the primary database. Usually nobody has checked.
An embedding is still personal data.
A vector database holding embeddings of customer records is holding derived personal data, and most teams do not have it on any inventory. It rarely appears in the data map anyone drew by hand, because the person drawing the map thought of it as infrastructure.
It shows up in the scan because the code puts data there, not because someone remembered it existed.
Advisory where it should be advisory.
The EU AI Act, ISO 42001 and the NIST AI RMF are covered, alongside the RBI FREE-AI recommendations for Indian financial services. Where a mapping is partial or advisory rather than a hard control, findings say so, because overstating a mapping in this area is how a governance programme ends up defending a claim nobody made carefully.