Does the bank own code generated by Cursor or Copilot?

Usually yes, under the enterprise terms of service from Microsoft, GitHub, Anthropic, and OpenAI as of early 2026. The user owns the outputs subject to the licensing of any training data the model reproduces. Ownership in the contract is the easy question; the harder one is provenance, when an open source license attaches to a verbatim snippet.

Can AI-generated code carry GPL contamination?

It can. Independent research and the underlying Doe v. GitHub class action both documented cases where Copilot reproduced training-set code closely enough to raise license questions. Modern models reproduce less, but the rate is not zero. For banks shipping proprietary software, a license scanner in CI catches most cases. A policy that engineers cannot accept multi-line completions without reviewing them catches the rest.

Who is liable if AI-generated code causes a regulatory failure?

You are. No vendor MSA shifts liability for production failures back to the model provider, and no regulator accepts I used AI as a defense. Under DORA Article 28, ICT third-party risk for the model vendor sits with the financial entity. Same logic under FDA 21 CFR Part 11 for pharma. The audit trail on your side has to prove that humans reviewed and approved the code that shipped.

What goes in the audit trail for AI-assisted commits?

At minimum: prompt content (or a hash plus retention reference), model name and version, reviewer identity, timestamp, and the diff of accepted vs suggested. SOX-style log immutability is enough; you do not need a blockchain. Store it for the same retention window as your other engineering audit logs, typically seven years for banks under FFIEC.

Who Owns AI-Generated Code in a Bank?

A general counsel at a top-50 US bank asked me this question in February. The bank had been quietly piloting AI coding tools across two teams for nine months. The CEO had just read a Bloomberg piece about Copilot reproducing GPL code, and the GC had a board meeting on Thursday. He wanted a one-page memo. I wrote three pages. He sent the three pages.

This article is the long version of that memo, with the bank-specific bits replaced with industry-generic ones.

The headline answer is reassuring. Under the enterprise terms of GitHub Copilot, Cursor, Anthropic Claude (through API or Claude Code), and OpenAI (through API), the customer owns the generated code. The vendor disclaims ownership of outputs. As of April 2026, none of the major enterprise contracts retain rights to your generated code, and most include some form of indemnification against third-party IP claims tied to the model output.

That is the easy part. The hard part is everything that happens after the engineer hits accept.

Three risks that are not in the contract

Ownership is settled. What is not settled is provenance, liability, and audit trail. Each one bites differently in regulated environments, and each one is missed by general-purpose IT policies written before AI agents existed.

Provenance. Your model occasionally reproduces training data verbatim. The rate is low, but it is non-zero. GitHub's own published research and the underlying class-action complaint in Doe v. GitHub both establish that some completions match training-set code closely enough to raise license questions. When that happens, the snippet may carry an open-source license your legal team would not have signed off on. GPL is the famous case. Affero GPL is worse. Even Apache 2.0 has attribution requirements that nobody enforces in CI, until somebody does. For a bank shipping a proprietary trading system, an AGPL contamination event is a recall-grade defect.

Liability. When AI-generated code causes a customer-facing failure, the regulator does not care that an AI wrote it. Under DORA Article 28, the financial entity carries the ICT third-party risk for the model vendor. The pattern across the ECB, BaFin, FCA, and US prudential regulators in 2024-2026 is consistent: the duty of care for production code does not transfer to the model provider. If your AI-assisted KYC pipeline rejects a sanctions-listed entity incorrectly, the answer Cursor wrote that branch will not work in the consent decree. (We covered the broader DORA architecture in our DORA compliance guide.)

Audit trail. This is the one I get asked about most. When the FFIEC examiner pulls a sample of production commits from your audit window, you need to be able to identify which were AI-assisted, who reviewed them, what data the prompt contained, and what model version produced the suggestion. If you cannot answer those four questions for any commit in the sample, the examiner will widen the sample. That is bad. The architectural pattern that makes this answerable is in our AI agent audit trail architecture deep dive.

What the contract actually says

I want to be specific here, because the contractual position is widely misunderstood and the misunderstanding usually runs in the direction of overconfidence.

GitHub Copilot Business and Enterprise: customer owns suggestions, GitHub indemnifies against third-party IP claims if the customer has the duplication detection filter enabled, no training on customer prompts or code.

Anthropic Claude Enterprise (and API with Zero Data Retention): customer owns outputs, no training on inputs, no retention beyond the request lifecycle, indemnification for third-party IP claims subject to standard caps.

OpenAI Enterprise and API (with ZDR): similar shape, customer owns outputs, no training, indemnification with caps.

Cursor Business: customer owns outputs, prompts not used for training, third-party model providers are bound by Cursor's contracts with them. (This is the layered piece, since Cursor passes your prompts to Anthropic or OpenAI under their own terms. Audit those too.)

The catch in all four: indemnification has a cap, and the cap is usually in the low six figures. For a bank, the cap is meaningless. A single regulatory consent decree exceeds it by an order of magnitude. So you treat the indemnification as nice-to-have garnish, and you build the controls assuming you are on the hook for everything.

The audit trail that actually works

After advising on this for about a year, I have converged on a four-element trail that has survived FFIEC, OCC, and one DORA mock examination so far.

First, prompt logging. Every prompt sent to a model gets stored, in your environment, with a 7-year retention default. You can hash the prompt and store the plaintext separately if data classification requires it. The point is that an examiner can ask show me what was sent on May 14, 2026 by engineer X and you can produce it. A proxy layer (LiteLLM, custom gateway, or Cloudflare AI Gateway) is the only sane way to do this.

Second, commit attribution. The PR template asks one question: was AI used in this change? The commit trailer encodes it: AI-Assisted: cursor 0.45 / claude-3.7-sonnet. Engineers complain about the friction for about two weeks, then it becomes muscle memory. Auditors love it.

Third, named human review. CC8.1, separation of duties, etcetera. The reviewer cannot be the prompter, and the reviewer's GitHub identity has to map to a real person in HR. (You would think this was obvious. I have seen banks where it was not.)

Fourth, license scanning. Run a tool like ScanCode or FOSSA in CI on every diff. Flag anything matching known GPL/AGPL fingerprints. Block the merge if the scanner confidence is above a threshold. This catches the verbatim-reproduction case before it ships.

Those four elements together give you something defensible. They do not give you zero risk. Nothing does. They give you an audit trail that an examiner can follow and that a regulator will accept as evidence of due care.

A note on pharma, which is different

The article so far has been bank-flavored. Pharma is structurally similar but with one twist: 21 CFR Part 11 and the GxP world require predicate rule compliance for any system involved in regulated decisions. AI-generated code that touches a clinical trial pipeline, a batch record system, or an electronic submission has to be qualified the same as any other software in scope. That means risk assessment, validation, change control, the whole IQ/OQ/PQ song. (For the broader EU regulatory layer that sits over agentic systems in pharma and finance, see our EU AI Act compliance checklist.)

The audit trail expectations are stricter than banking. Specifically, FDA inspectors will ask whether you can reconstruct the exact state of any system that produced regulated data, going back to the original source of every change. AI-generated code without a logged prompt and a named reviewer fails this test the same way a developer hand-edit on a production server fails it. Same control, different vocabulary.

The good news is that pharma teams already understand this. They have been doing change control for decades. AI is just another source of change, and the existing GxP framework absorbs it cleanly if you map it deliberately.

What I tell boards

When I get asked the GC question (the one that started this article), my short answer is: ownership is fine, indemnification is theatrical, the real exposure is provenance and audit trail. If your engineering org is using AI coding tools today (it is, even if you have not approved it) and you do not have prompt logging, commit attribution, named review, and license scanning in place, you are accumulating risk that will surface at the next audit or the next regulator visit.

The fix is not to ban the tools. That ship sailed sometime in 2024. The fix is to deploy them in a way that is auditable, contractually sound, and aligned with the segregation-of-duties controls you already have. It is six weeks of work for a mid-size bank. It is a lot less than the cost of a single MRA.

If your team needs help mapping AI-SDLC controls onto your existing risk framework, that is the work we do across banking, insurance, and pharma. We have built reference control matrices for FFIEC, DORA, and FDA Part 11 environments. Reach out and we can share the relevant template for your scope.

Daniella Mitchell leads compliance engineering at The BrightByte. She advises CISOs and General Counsel in regulated sectors on AI governance, including IP and liability frameworks for AI-generated code.