The Coding Assistant Across Four Jurisdictions
A multinational bank rolls out a foundation-model coding assistant to 4,000 engineers across the US, UK, India, and Germany. The vendor offers a 'private' instance but logs prompts for 30 days and uses a subprocessor in a country not approved by the bank's data residency policy. Engineers have pasted production database schemas and customer support transcripts into the assistant. The bank's IP policy prohibits sending confidential source code to third parties. An internal survey finds 78% of engineers use the tool daily; 40% say they would 'work around' restrictions if access were limited. The CISO wants to ban it; the CTO wants to expand it.
1. Identify the governance issues and assess the regulatory and risk classification of the coding assistant.
Read the worked answer
Governance issues:
- Data residency and cross-border transfer: the subprocessor location conflicts with policy; prompt logs may contain personal data and confidential code.
- Confidentiality/IP: pasting production schemas and support transcripts may breach the bank's IP policy and third-party contracts.
- Data protection: support transcripts likely contain personal data; the vendor's 30-day logging creates a processing relationship that needs a lawful basis, contract terms, and transfer mechanism.
- Shadow use: 40% willingness to work around restrictions means a ban will drive usage underground, increasing unmanaged risk.
- Vendor opacity: the bank may not know how prompts are used or retained.
Classification: The coding assistant is not high-risk under the EU AI Act Annex III on these facts. It is a productivity tool. But the underlying foundation model may be a general-purpose AI model, with provider obligations on the vendor. The bank is a deployer and a data controller for any personal data in prompts. The risk is high operationally because of data leakage, not because of the AI Act's high-risk list. The CISO's ban and CTO's expansion are both incomplete: one ignores shadow use, the other ignores the data flow.
2. Recommend a path between ban and expansion, with technical, contractual, and policy controls.
Read the worked answer
Recommended path: tiered, gated access - not a ban, not unrestricted expansion.
Technical controls:
- Deploy an approved instance with no prompt retention or a contractual hard limit, regional processing, and no training on bank data.
- Data-loss-prevention filters for secrets, API keys, customer identifiers, and source-code patterns tied to production repositories.
- Restrict the assistant to approved repositories and non-production contexts; block paste of support transcripts.
- SSO, logging, and per-user attribution.
Contractual controls:
- No-training clause; deletion certification; subprocessor approval and notice; audit rights; security attestations; breach notification; liability for data misuse.
- Right to change configuration or terminate if residency requirements are not met.
Policy controls:
- Clear acceptable-use policy: public or non-sensitive code only; no customer data; no production schemas.
- A fast exception process so engineers do not need to work around the tool.
- Training that explains why the restrictions exist and how to use the tool safely.
- A pilot with one business unit before bank-wide rollout.
Why not ban: the survey shows demand and workaround risk. A ban would push usage to unapproved tools with worse controls. Why not expand now: the residency and logging issues are unresolved. Gated access converts a shadow-risk problem into a managed one.
3. How would you measure whether the controls are effective? Name metrics and a review cadence.
Read the worked answer
Metrics:
- DLP incidents per 1,000 prompts, by category (secrets, PII, production schema).
- Percentage of prompts containing sensitive data, sampled monthly.
- Workaround indicators: unapproved tool usage on the corporate network, survey-reported bypass, and help-desk requests.
- Vendor compliance: confirmation of no-training, log retention, subprocessor location, and deletion.
- Incident response: time to detect and contain a leaked secret or customer data.
- Adoption and productivity: active users and self-reported time saved, to show the approved tool is viable.
- Code provenance: percentage of AI-assisted code that passes review without IP flags.
Cadence: weekly during the first month, monthly for the first quarter, then quarterly to the AI governance committee. Trigger a special review after any DLP incident involving customer data or production secrets. The test of effectiveness is not 'zero incidents' - it is whether incidents are detected, contained, and declining, and whether engineers use the approved tool rather than routing around it.