Who should assess commercial use of AI-generated code first?

Technical leadership should perform the first factual assessment of code written by AI, while IP counsel should make the first legal judgment. That distinction sounds fussy until a team reverses it. Send counsel a tool name and a vague question such as "Can we use this commercially?" and counsel lacks the facts needed to answer. Let engineering declare the code safe because a scanner found nothing and the company may ship under obligations nobody reviewed.

The useful sequence is evidence, legal classification, then an engineering control. Technical leaders establish what tool, account, contract, inputs, output, repository, and distribution model are involved. IP counsel decides what those facts mean for copyright, license duties, patents, confidentiality, and contract risk. Engineering then turns that decision into a policy that developers can follow without opening a legal ticket for every completion.

This is a governance boundary, not a contest over who understands AI better. A CTO cannot outsource factual ownership of the software supply chain to legal. A lawyer should not have to reverse engineer an editor extension, determine whether retrieval was enabled, or guess how code moved into a release branch. Each role goes first in its own domain, and commercial release waits until both have finished.

The first pass belongs to technical leadership, the decision to counsel

Technical leadership goes first because every useful legal answer depends on a technical fact pattern. The head of engineering or a delegated owner should identify the model and product tier, the organization account, the terms attached to that account, the repository classification, what material entered the prompt or context window, and what happened to the output. A helper of ten lines proposed in a private internal service does not present the same facts as a generated encryption module copied into a distributed SDK.

That first pass is triage, not permission to ship. Engineering can approve routine use only when counsel has already defined a permitted lane. For example, an approved enterprise account may be allowed for ordinary implementation work in private repositories, provided developers do not submit confidential code from another party and a match detector does not flag a substantial passage. Counsel decides whether that lane is acceptable. Engineering decides whether a particular change stayed inside it.

IP counsel goes first when the question itself is legal or the facts fall outside the approved lane. Escalate before release when output resembles identifiable source, carries a notice or license header, implements a patented standard, contains code supplied by a customer, reaches a public package, or comes from a tool whose contract has not been reviewed. The same applies when a developer used a personal account for company work. The tool may look identical, but the governing terms and indemnity can be different.

The phrase "commercial use" also needs definition. Internal use, hosted access, object code distribution, source distribution, customer delivery, and contribution to a public repository create different exposure and license duties. Technical leadership must name the intended use. Counsel must resist giving one universal answer that the company later applies to every distribution model.

A workable ownership rule is simple: engineering owns the evidence and the enforcement mechanism; IP counsel owns legal interpretation and exceptions. Product leadership owns the business decision when counsel describes a residual risk rather than a prohibition. Procurement owns the signed agreement and renewal state. If nobody holds one of those four responsibilities, the review has a hole.

Separate authorship, infringement, and contract rights

Commercial permission cannot be reduced to "who owns the output?" because authorship, infringement, and contract rights are separate questions. Teams blur them and then treat a favorable answer to one as a favorable answer to all three.

Copyrightability asks whether the output has enough human authorship to receive copyright protection. The U.S. Copyright Office's 2025 report on generative AI says AI assistance does not disqualify a larger work created by a human, but prompts alone do not supply sufficient control over expressive elements. Human selection, arrangement, and modification can be protected. For a software company, that means a developer's substantial design and revision may support rights in the resulting program even if raw generated fragments receive no protection. Counsel should assess this under the law that matters to the company and transaction.

Infringement asks whether shipping the code violates somebody else's rights. An output can lack its own copyright and still copy protected expression. It can also be independently generated, functionally similar, and noninfringing. A vendor's statement that the customer owns output does not settle this question because a vendor cannot assign rights it never had. Technical comparison supplies evidence; counsel judges substantial similarity, applicable exceptions, and the practical exposure.

Contract rights ask what the vendor promises between itself and the customer. Terms may assign whatever rights the vendor has, disclaim uniqueness, restrict inputs, reserve data use, or offer an indemnity with conditions. Those promises can allocate losses between the contracting parties, but they do not rewrite copyright law or bind a stranger who claims infringement.

Patent and trade secret questions sit beside these three. Code can implement a patented method without copying source. A prompt can disclose a customer's secret even when the returned code is banal. Trademark is less common in program logic but can matter in generated names, sample data, or user interfaces. Counsel should scope the review rather than letting a copyright checklist hide other rights.

NIST's Generative AI Profile identifies intellectual property risk from training data and memorized output, and the AI Risk Management Framework calls for documented approaches to data from other parties, software, and infringement risk. I agree with its emphasis on documentation, but a broad risk register is not enough for a pull request. The company needs evidence attached to the change and an owner who can stop release.

Licensing evidence starts with engineering

Engineering should determine what code is actually present before counsel interprets a license. That includes exact and near matches, embedded notices, dependency changes, generated test fixtures, copied documentation examples, and code brought in through retrieval or repository context. A prompt log alone cannot show what landed in the tree, while a repository scan alone cannot show what confidential material left it.

Treat a scanner result as a lead, not a verdict. A positive match may point to public domain code, a permissively licensed example with a notice duty, a reciprocal license, or an unauthorized copy. A negative result means only that the scanner found no match in its reference set at its configured threshold. There is no percentage that creates a copyright safe harbor. Engineering records the match, source candidate, affected lines, and transformation history; counsel decides the consequence.

The review should distinguish a generated fragment from a dependency. If a model suggests calling a library and the developer adds that package, the normal software composition process can identify its version and license. If the model reproduces part of the library inside a local file, the package manager sees nothing. The obligation may follow the copied code even though the dependency manifest stays clean. This is where teams that rely only on software composition analysis miss the issue.

SPDX, recognized as ISO/IEC 5962:2021, provides a standard way to communicate software bill of materials data, including licenses, copyrights, relationships, and provenance. SPDX 3 can describe files and snippets, which makes it useful for recording a known source match. Its own documentation also says SPDX does not perform legal interpretation or identify patents. Use it to preserve facts, not to manufacture a legal conclusion.

IP counsel should answer the questions engineering cannot automate: Does the identified material qualify for protection? Does the proposed distribution trigger attribution, source offer, disclosure, or reciprocal terms? Is an exception or fair use argument credible enough for this product? Does combining the fragment with proprietary code create an obligation the business will not accept? Should the team replace the fragment even if a defense exists because proving that defense would cost more than rewriting it?

For most generated snippets, replacement is cheaper than extended analysis. That is an engineering judgment about effort paired with counsel's judgment about risk. Do not spend three meetings defending forty lines that a developer can reimplement from a clean specification and tests.

Provenance is a record, not a vendor promise

Provenance means the documented history of this output in this repository. It is not the model provider's general description of training data, and it is not a developer checking a box that says "AI assisted." A useful record connects a particular change to the tool, account, contract version, model if exposed, relevant prompt inputs, generation time, human edits, scan results, reviewer, and final disposition.

Technical leadership owns the collection mechanism because only engineering can place it where work happens. The record may live in pull request metadata, an internal attestation, or a build artifact. Keep sensitive prompts out of broad logs. Store a digest or a restricted reference when the prompt contains proprietary architecture, credentials, personal data, or customer material. Provenance controls should not create a second leak of confidential data.

Counsel defines which facts must be retained and for how long. That decision should reflect likely disputes, customer warranties, acquisition diligence, employee invention agreements, privacy limits, and litigation hold rules. Retaining every prompt forever is not a mature default. Deleting every trace after merge is equally poor when the company later promises a buyer that it knows the origin of shipped code.

The U.S. Copyright Office's authorship analysis makes the human contribution relevant, so the record should capture more than the initial prompt. Design notes, tests written before generation, review comments, refactoring, and commit history can show human choices. They also help maintainers understand the code. Do not turn this into theater by asking developers to write an essay for each completion. Capture artifacts the workflow already produces and add a short attestation for the missing facts.

A provenance record cannot prove a negative. It cannot establish that training data contained no copyrighted code or that output has no similarity to an unknown repository. It can show that the company used an approved account, protected its inputs, ran defined checks, investigated detected matches, and applied human review. That is actionable evidence for counsel, customers, insurers, and an acquirer.

The awkward case is old code. If AI tools were used for a year without records, do not fabricate certainty. Classify repositories by distribution and value, scan the highest exposure releases, interview the maintainers, review vendor account history that still exists, and mark the remaining gap. Counsel can then decide whether to replace sensitive modules, disclose the limitation in a transaction, or accept the uncertainty.

Vendor contracts allocate risk, but only within their boundaries

IP counsel should lead contract interpretation, while technical leadership verifies that actual use satisfies the deal. A generous enterprise clause does nothing for code generated through a developer's free personal account. An indemnity may disappear if the team disables a filtering control, modifies flagged output, ignores a notice, combines the output with other material, or uses the service outside an approved purpose. The signed contract, incorporated policies, order form, and account configuration belong in one review.

Counsel should examine ownership language without stopping there. The review needs the vendor's treatment of customer inputs and outputs, training and rights to improve the service, confidentiality commitments, retention, deletion, security duties, acceptable use limits, warranties, infringement indemnity, defense control, liability caps, exclusions, termination effects, governing law, and unilateral term changes. Procurement should record which version applies and when renewal can change it.

Technical leadership answers the operational half. Can administrators prevent personal accounts? Is model training on company content disabled by contract, configuration, or both? Which editor extensions and agents run from the command line send repository context? Does an agent read files outside the opened project? Are prompts and outputs retained locally or remotely? Can the company export activity records? Does a match or citation feature exist, and did engineering leave it on?

Do not compare vendors by the headline word "indemnity." Compare the claim that is covered, the customer actions required to preserve coverage, the exclusions, the liability ceiling, and the vendor's control of defense and settlement. A defense promise capped at fees may not cover the commercial consequence of pulling a release. A broad promise may still exclude the exact workflow developers use. Counsel can explain the clause; the CTO must quantify replacement time, release exposure, and feasible controls.

Data terms deserve equal attention. Submitting source can breach a customer agreement or destroy trade secret protection before any output reaches production. The input may include comments, test data, incident details, or credentials that the developer did not intend to send. Contract permission from the AI vendor does not override restrictions owed to a customer or open source project. Engineering must map what the tool can collect, and counsel must compare that flow with existing obligations.

Contract review ends with a usable statement, not a memo nobody can execute. It should name approved products and account tiers, required settings, prohibited data, permitted repository classes, conditions for preserving indemnity, and the events that require a new review. Engineering can then enforce the statement and procurement can catch a terms change before renewal.

Repository policy turns legal judgment into daily controls

A repository policy should classify uses rather than declare "AI allowed" or "AI banned." Blanket permission ignores distribution and data sensitivity. A blanket ban usually drives usage into personal accounts where the company has less visibility. The policy needs a permitted lane narrow enough to automate and clear escalation triggers for everything else.

Technical leadership owns the policy file, developer workflow, administrator settings, and CI checks. IP counsel approves its legal thresholds and exception process. Security and privacy owners contribute data restrictions. Repository maintainers enforce local requirements, but they should not invent a different copyright rule for each team.

A compact policy can be expressed as data and tested in CI:

ai_code_policy:
  approved_accounts: [company-enterprise]
  repositories:
    private-internal: allow
    customer-deliverable: review
    public-package: review
  prohibited_inputs:
    - credentials
    - customer-confidential-code
    - unlicensed-third-party-source
  escalation:
    - detected-source-match
    - license-or-copyright-notice
    - personal-account-use
    - generated-cryptography
  required_evidence:
    - tool-and-account
    - human-reviewer
    - scan-result
    - disposition

This fragment does not decide whether code infringes. It prevents three ordinary failures: a personal account silently falling under different terms, a public release receiving the same treatment as an internal tool, and a detected match disappearing without a disposition. Use repository labels that already have owners. If "customer-deliverable" exists only in a legal spreadsheet, the CI job cannot enforce it.

Policies also need a route for exceptions. Counsel should approve exception criteria, while a technical owner documents the exact files, release, compensating review, and expiration. Permanent waivers become shadow policy. Exceptions with an expiration force the company to decide whether a risky fragment should be replaced or whether the main rule should change.

Do not require developers to identify whether every suggestion is AI generated from memory. Agents can edit several files, generate migrations, and invoke tools. Capture use at the session or pull request level, then inspect sensitive changes more closely. The control should follow the evidence the tool can reliably produce.

Measure the policy by unresolved matches, incidents involving personal accounts, exception age, and coverage of released repositories. Do not reward teams for producing more attestations. A clean dashboard can coexist with an unmonitored editor extension, so test the control against the actual development environment.

Give counsel a decision packet, not a tool name

Counsel can decide faster when engineering submits a fixed packet with the disputed code and its commercial context. The packet should be short enough to complete during release work and precise enough that legal does not need a discovery project.

Use this intake with five parts:

1. Identify the output: repository, file, lines, commit, tool, account tier, date, and human author.
2. State the use: internal service, hosted product, source delivery, binary distribution, or public contribution.
3. Preserve the trail: relevant prompt or restricted reference, output, human edits, scan result, and possible source match.
4. Attach the terms: signed agreement or terms version, required settings, and any customer or contributor obligations.
5. Ask a decision question: ship, replace, add notice, disclose source, seek permission, or obtain business acceptance of residual risk.

The final line matters. "Please review" pushes issue framing onto counsel and often produces another round of questions. "May we distribute these 86 lines in the source SDK under our customer license, given this possible Apache-2.0 match with its notice removed?" tells counsel what decision blocks release.

Counsel's response should use a small set of dispositions: approved within stated facts, approved with obligations, replace, obtain permission, escalate for business acceptance, or insufficient evidence. Each response should name the files and distribution model it covers. An approval for an internal deployment should not drift into a later public package because somebody copied the ticket number.

The packet creates a feedback loop. If counsel repeatedly approves the same class with the same conditions, those conditions can enter the permitted lane. If one tool repeatedly produces unattributed matches, technical leadership can restrict it or require its citation control. If every exception concerns customer code entering prompts, the failure sits in context configuration, not copyright education.

Turnaround targets should follow release impact and complexity, but never let an urgent release redefine the legal standard. Engineering can reduce urgency by flagging AI use at pull request opening rather than on release day. Counsel can publish office hours and precedent notes without converting nuanced advice into universal law.

Walk the failure from completion to customer shipment

The most common failure is not a developer pasting an entire famous project into a prompt. It is an ordinary completion that crosses several boundaries while each owner assumes another control will catch it.

A developer uses a personally licensed assistant because the company account has an authentication problem. The agent reads a customer integration repository and generates a parser. The developer edits variable names, tests it, and opens a pull request without an AI label. Composition analysis reports no new dependency. A similarity scanner is not configured for that repository because the service was originally internal.

Two months later, sales agrees to deliver source to another customer. During diligence, a reviewer finds that part of the parser resembles a project under a reciprocal license. The original prompt is gone. Procurement has terms for the enterprise product, but those terms never governed the personal account. Legal cannot tell whether the resemblance came from model output, the developer's memory, an earlier copied example, or coincidence. The team now has a release question, a customer confidentiality question, and weak evidence for an indemnity request.

No single control fixes this chain. Blocking personal accounts would have applied the reviewed contract. Repository classification would have triggered review for source distribution. Attestation in the pull request would have preserved the tool and account. Similarity scanning might have produced a source candidate. A provenance record would have separated model output from human edits. Counsel still would need to interpret the possible license and contract, but the company could make a decision from evidence instead of recollection.

The popular recommendation is to send every pull request involving AI to legal. It sounds safe because it transfers the anxiety to counsel. It is wrong for a team that ships daily. Review volume obscures the unusual cases, lawyers spend time confirming routine facts, and developers route around the queue. Preapproved lanes with mechanical evidence give counsel fewer, better questions.

The opposite recommendation, treating AI output exactly like code written by a human, also misses the changed fact pattern. Human code already carries provenance risk, which is why mature teams review contributions and dependencies. AI tools can introduce context collection, contracts tied to particular accounts, uncertain output history, and a high number of suggestions. Extend existing open source and controls for confidential data, but record those additional facts.

When evidence remains ambiguous, rewriting is often the sound release choice. Create a clean specification from behavior and tests, assign a developer who has not seen the suspected source when the risk warrants it, and retain the replacement history. Counsel should define when that independent development discipline is needed. Renaming variables in the same fragment is not independent reimplementation.

The operating model must keep pace with the repository

The durable answer is a gate with two stages: technical leadership qualifies the use, and IP counsel rules on legal exceptions. Routine work stays inside a lane approved by counsel. Code with high exposure stops with evidence already attached. Procurement maintains the contract baseline, and product leadership accepts only the residual risks counsel has described.

Set one accountable technical owner even in a small company. That person maintains the register of approved tools, repository classifications, policy checks, provenance format, and escalation queue. Set one legal owner who can bind advice to stated facts and publish reusable dispositions. Named deputies matter because release work will not wait for vacations.

Review the system when the vendor changes terms, account tier, retention, model behavior, or indemnity; when the company changes how it distributes code; when a new agent gains broader repository access; when a customer contract adds an AI restriction; or when an incident shows the evidence was incomplete. An annual policy review cannot catch a tool that changed its data flow last week.

For founders, the first useful test is not asking counsel whether a popular assistant is safe. Pick one shipped pull request that used it and try to reconstruct the account, inputs, output, human changes, scans, governing terms, repository class, and distribution. Missing facts reveal the control work. Legal uncertainty after the packet is complete reveals the counsel work.

In my Team & AI Audit, I treat this split as an question of operating design because tool approval without repository controls does not survive contact with a release. The same principle applies without an outside adviser: make engineers own what happened, make counsel own what it means, and do not confuse either answer with the decision to accept commercial risk.

A company does not need perfect knowledge about a model's training set to act responsibly. It needs truthful records about its own use, technically enforced boundaries, and legal decisions tied to specific facts. If the team cannot produce those three things for code entering tomorrow's release, the code is not ready for commercial use.