Governing PII for a Churn Model and an AI Assistant
Vantage Insurance plans a churn-prediction model and a customer-service summarization assistant. Feature engineering pulls 40 customer attributes from a Snowflake warehouse populated by PowerCenter; 14 of those attributes are classified PII, including national ID, date of birth, address, phone, email, and health-claim codes. Data scientists work in a shared development schema containing unmasked production data, and a third-party analytics vendor accesses extracts over a VPN. The model retrains weekly. The insurer operates in the EU and two US states, and the DPO has asked for evidence that personal data used in training is lawful, minimized, and traceable. Assets in place include IDMC, Enterprise Data Catalog, Axon Data Governance, and a masking policy configured but never applied to the development schema. Audit is in eight weeks.
1. What controls do you put in place before go-live, in priority order?
Read the worked answer
Priority is driven by exposure and ease of fix, not by completeness of the framework.
- Stop the leaking exposure. Apply the existing masking policy to the development schema and replace the vendor VPN extracts with a controlled, minimized data share. Unmasked production PII in a shared schema is the largest breach and regulatory risk, and the policy is already built.
- Classify and tag the 14 attributes in the catalog, link each to a glossary term, a policy, and a named owner in Axon, and confirm a lawful basis and stated purpose per attribute.
- Minimize the feature set. Test whether full date of birth or national ID actually improves the model; replace with age bands and hashed tokens where accuracy holds. Most churn models lose little from generalization and gain defensibility.
- Build lineage from source table through transformation to feature table to model version.
- Complete the DPIA, model documentation, and access reviews.
Steps 1–3 fit the eight weeks; lineage and documentation follow, with honest gaps recorded.
2. How do you satisfy EU data residency and the vendor access requirement?
Read the worked answer
Map where processing physically occurs before promising anything: IDMC hosting region and secure agent location, Snowflake account region, and where the vendor's analysts actually sit. Residency is about processing location, not only storage.
Keep data in the EU region, run a secure agent inside that region, and provide the vendor an EU-hosted tenant with pseudonymized extracts rather than production access. Contractual controls go alongside, not instead: a data processing agreement, standard contractual clauses where relevant, deletion at termination, no re-identification, and named individual access with logging.
If a US team needs model performance metrics, share aggregate metrics, not row-level data, and do not replicate the feature store across regions for convenience. Log every transfer with purpose and legal basis so the DPO can reconstruct it.
Where the vendor needs raw records for an approved purpose, document that decision explicitly as a risk acceptance with an owner, rather than letting it happen through a VPN exception.
3. What evidence package do you assemble to prove lawfulness, minimization, and traceability?
Read the worked answer
Assemble a dated, reproducible package rather than a narrative.
Lineage: catalog lineage from source tables through PowerCenter transformations to feature tables and to each model version, with confidence noted where an edge was manually stitched.
Governance: glossary terms linked to policies, owners, and classification tags; the DPIA and its approval; the minimization decisions with the accuracy tests that justified each dropped or generalized attribute.
Operational proof: masking policy application logs, access reviews, vendor transfer logs, retention job runs with results, and a snapshot hash and date for the exact training dataset.
Reproducibility matters - a regulator or auditor should be able to take a model version and trace back to the data state used to train it. Name an accountable owner per asset and keep a change history. State limitations plainly, including where lineage is inferred rather than parsed; an audit pack that overstates coverage is worse than one with declared gaps.