Your most-adopted AI system is also your least governed one
In most banks, insurers and health systems, the AI with the highest daily active usage isn't the flagship pilot the board hears about. It's the coding assistant, adopted bottom up, one developer at a time, often on individual licences expensed to a team budget. Nobody chartered it, nobody classified it, and there's usually no record of which code it touched. That gap between adoption and control is where AI coding controls for regulated industries have to start. Not with a policy document. With the honest question: if an auditor asked which of your production code was AI-assisted, could you answer?
Banning it does not remove it, it just moves it
The first reflex in a regulated shop is to block the assistant at the network. It's a satisfying decision that solves nothing, because the developer opens the tool on a personal account, on a personal laptop, and pastes code back. Now the same activity is happening with none of the enterprise controls, no tenancy agreement, no training opt-out, and no logs at all. Ungoverned use is a demand signal, not a discipline problem. Your engineers are telling you which capability they need. The job is to pull that use onto a path you can support, not to pretend it stopped. There's a second cost to the ban that rarely gets counted. The developers who comply are the ones who follow rules, which are disproportionately your senior engineers on your most sensitive systems. The ones who route around it skew junior. You have inverted the risk profile: your least experienced people are now the ones using an unlogged tool on code nobody is watching.
The controls belong at the repo and the review gate
Trying to control what a developer types is a losing game. Control what lands. Mark AI-assisted changes at the pull request, so provenance travels with the code rather than living in someone's memory. Run licence and IP scanning on every PR, because suggested code can echo training data and a copyleft licence appearing in a proprietary payments service is a legal problem, not a style one. Keep secrets scanning on both directions: what the assistant emits, and what your developers paste into it. Require human review on the paths that matter, and be specific about which ones those are: payments, credit decisions, clinical logic, anything touching PHI or cardholder data. On those paths, an AI-assisted change gets a named human reviewer who is accountable for it, full stop. None of this is exotic. It's the review discipline you already run, with the assistant made visible inside it.
Four decisions to make this month
Which repos are in scope. Not all of them, and pretending otherwise guarantees the policy is ignored. Start with the regulated services and the ones with customer data. What may go into a prompt. The default that survives audit: no production data, no customer PII, no secrets, no unreleased financials. Say it in one line that a developer can remember. Which endpoints are allowed. Enterprise tenancy with training opt-out and a data retention term you have actually read. The consumer tier of the same product usually has different retention behaviour, and the difference is the whole ballgame. What gets retained, and for how long. If the vendor keeps prompts for 30 days, that's 30 days of your source code sitting somewhere. Decide whether you accept that, and write down that you decided.
Where the EU AI Act actually bites, and where it does not
Teams burn quarters classifying the coding assistant itself. That's usually the wrong object. A general-purpose coding assistant used to write software is not, on its own, a high-risk system under the EU AI Act. The obligations attach to what you build. If the assistant helps you ship a credit-scoring engine, a recruitment filter, or a system that decides who gets access to credit or public benefits, the Annex III obligations land on that system, whatever wrote its code. The Commission's Digital Omnibus proposal would push the high-risk Annex III obligations out to December 2027, which changes the calendar and changes nothing about the design work. So the practical read is unglamorous: govern the coding assistant with engineering controls, and spend your regulatory effort on the systems it helps you build. Getting that backwards is the most common expensive mistake we see.
The record you will wish you had
When the assessment comes, the questions are concrete. Which model version wrote this? Who reviewed it? What data was in the prompt? Was the vendor allowed to train on it? Capture that as the change happens, because reconstructing it after the fact is close to impossible and everybody knows it. The teams that stay calm in an audit are the ones who can produce the trail on request. The rest spend six weeks writing retroactive documentation that convinces nobody, including themselves.
Where to start
Inventory first. Find out which assistants are actually in use, on which accounts, against which repos. It takes a week and the answer is always worse than the CIO expected. Then pick one regulated service, put the repo controls and the PR provenance in place, and run it for a month. One governed path that developers accept beats a policy nobody follows, and it gives you something real to show the risk committee instead of an intention. A reasonable first month: week one, inventory. Week two, agree the four decisions above and publish them as a single page, not a 40 page standard nobody reads. Week three, turn on PR provenance, licence scanning and secrets scanning in one regulated repo. Week four, review what the scans caught and take that to the risk committee. The output you want at the end isn't a policy. It's one service where you can say, with evidence, which code was AI-assisted, which model produced it, who reviewed it, and what data never left the building. Once one service can answer that, the pattern is repeatable and the argument with the regulator stops being theoretical.