Can Developers Use AI Coding Tools Safely? Legal Risks and Controls for Software Companies

For a software company, the practical question is not whether AI coding tools are useful. It is whether developers can use them without submitting client or proprietary code under the wrong provider terms, allowing to train AI models on that data.

This question commonly arises when a client restricts AI use, a development team wants access to a new coding assistant, or an investor or buyer examines the provenance of the company’s software. In each case, the company must be able to explain which tools developers may use, what information may be submitted, how generated code is reviewed and what records support its ownership and compliance position.

The short answer is that AI-assisted coding does not necessarily need to be prohibited. It does, however, need to be governed through approved tools and account types, project-specific contractual rules, human review and appropriate code-scanning controls.

This article provides a jurisdiction-neutral overview of confidentiality, ownership, copyright and open-source licence risks. The precise legal analysis depends on the applicable law, contracts and tools. Security, reliability and code-quality risks are outside its primary scope.

AI-Assisted Coding: Where Do the Legal Risks Arise?

In general, using AI coding tools (or AI-assisted coding) creates three principal legal risks for software companies:

1. Disclosure of confidential information,
2. Uncertainty over output ownership, and
3. Infringement of third-party rights.

This section briefly outlines each risk. The contractual, organisational and technical measures for addressing them are discussed in the following section.

Ownership of AI-Generated Code

The first question is whether the company can claim and transfer sufficient rights to code produced with the assistance of an AI tool. This is particularly important for software development providers that are required to assign all intellectual property rights in deliverables to their clients, as well as for product companies that may later need to demonstrate clean ownership to investors or buyers.

Tetiana Kontariova recently analysed this question in depth in her article about who owns AI-generated content.

Copyright Infringement and Open-Source Licence Risks

AI coding tools may produce outputs that resemble existing open-source or proprietary materials. This may happen even where the developer did not intentionally copy from a third-party repository. That can create several legal issues, including copyright infringement claims for the developer or its client who received the deliverables.

If the output incorporates open-source code, it may also trigger licence obligations. Under certain copyleft licences, this may require the relevant derivative software to be distributed under the same licence and its source code to be disclosed.

Similarity risks are not limited to source code: AI tools may also reproduce distinctive product wording, interface elements, feature structures or user flows, which may lead to breach of trademark, copyright, or trade secret, depending on the circumstances.

Confidentiality Risks Involving Client Code

Developers may use AI tools to process client code, internal documentation, database schemas, technical specifications, product roadmaps, API structures or business logic. Such materials will generally constitute confidential information. Submitting them to an external AI tool without the client’s authorisation may therefore breach the applicable NDA, software development agreement or client’s internal security policy.

This is increasingly important because many clients now include express restrictions on AI use in their contracts with service companies. We observe an increasing number of clients’ NDAs prohibiting the submission of code, confidential information or project materials into AI systems without consent. However, blanket restrictions of this kind may be difficult to implement in practice, as AI-assisted tools are becoming embedded in ordinary software development workflows and solutions.

At the same time, simply using an AI tool and hoping the client will not find out is not a serious legal strategy. The better approach is to identify the client’s actual concern and regulate the use of AI clearly in the contract and internally.

What Controls Should a Software Company Put in Place?

Companies do not necessarily need to ban AI-assisted coding. But they should govern it through contracts, internal policies and technical controls.

1. Set Company-Wide and Project-Specific AI Rules

Before addressing individual confidentiality concerns, a company should establish an internal framework for the use of AI-assisted development tools. The framework should identify approved tools and account types, determine what categories of information may be processed by AI, allocate responsibility for reviewing AI-generated code and provide a process for dealing with client-specific restrictions.

A single internal policy may not be sufficient for every project. Software development providers should review the relevant NDA, services agreement, security requirements and client policies before work begins and communicate any applicable restrictions to the development team. Where the client’s requirements differ from the company’s standard AI policy, those requirements should be incorporated into the project-specific development and security procedures.

The next step is to identify the actual client’s concern underlying the restriction on using confidential information in AI tools. In particular, the company should determine which of the following issues the restriction is intended to address:

• Will the AI provider use confidential code or other inputs to train its models?
• Will the provider store the submitted information, and if so, for how long?
• Where will the data be processed and stored?
• Does the client require data processing to take place in a particular jurisdiction?

Once the underlying concern is identified, the contractual restriction can be tailored to address it directly. For example:

• if the concern is model training, the parties may permit only enterprise or business versions of AI tools that do not use inputs or outputs to train their models;
• if the concern is information security, the agreement may require the provider to meet specified security standards or certifications;
• if the concern is data retention, the parties may limit how long submitted information may be stored;
• if the concern is data location, the agreement may require processing and storage to take place in an approved jurisdiction.

2. Review Provider Terms and Output Rights

Many major AI providers state that they do not claim ownership of user outputs. OpenAI’s terms provide that the user owns output as between the user and OpenAI, and OpenAI assigns any rights it may have in that output. Anthropic’s commercial terms similarly provide that the customer owns outputs and that Anthropic assigns any rights it may have.

However, this only answers part of the question. These clauses resolve the contractual allocation of rights between the customer and the AI provider. They do not necessarily establish that the output qualifies for copyright protection, that it is unique or that its use cannot infringe third-party rights. Under many copyright regimes, copyright protection depends on sufficient human authorship. If material parts of the code are generated with little meaningful human contribution, you may use the code but may have limited ability to prevent third parties from reproducing the same, because the code would not be protected by copyright. This can reduce the commercial value of the software.

To manage this risk, the service provider should consider meaningful human involvement in selecting, reviewing, modifying and integrating AI-generated code. The provider should also consider retaining development records, such as version histories and code reviews.

Whether an AI-generated output infringes third-party rights is a separate issue and is considered in the following section.

3. Control Code Provenance and Open-Source Licence Risk

The more significant IP risk is often not whether the company owns the AI-generated output, but whether that output reproduces or is substantially similar to third-party code.

An AI coding tool may generate fragments that resemble proprietary or open-source code, even where the developer did not intentionally copy from an identifiable repository. Depending on the circumstances, use of that output may expose the company to copyright claims or trigger obligations under an open-source licence.

The first layer of protection is the way in which AI tools are used. Companies should not instruct an AI tool to imitate a competitor’s codebase, recreate a particular proprietary product or copy the structure of a named platform. Developers should also preserve copyright notices, licence headers and attribution information where these appear in generated code.

The second layer of protection is the use of technical controls tailored to the relevant risk. Because prompt rules alone cannot prevent an AI tool from generating code that resembles third-party materials, companies should also use technical controls appropriate to the different types of risk.

Open-Source Dependency Scanning

Dependency-scanning tools identify open-source packages, libraries and other components included in a codebase. They can help the company determine which licences apply, whether required notices have been retained and whether any components are subject to restrictive or copyleft obligations.

This is particularly important where AI tools recommend or insert third-party packages without the developer separately reviewing their licence terms.

Code Similarity Checks

A similarity checker serves a different purpose. It may identify generated code that closely resembles existing third-party code even where that code has not been included as a formal package or dependency.

This can help detect copied or near-copied fragments that would not appear in a standard dependency report. Similarity findings should be assessed in context, including the length and originality of the relevant code, whether licence notices were removed and whether the similarity may result from standard or functional programming conventions.

Dependency and similarity scans are useful risk controls, but neither conclusively determines whether copyright has been infringed or an open-source licence has been breached. Material findings should therefore be reviewed by developers and, where necessary, legal counsel before the code is delivered.

Read our guide to protecting software IP and managing open-source licence risks.

The Practical Test: Can the Company Evidence Responsible AI Use?

The relevant question is not simply whether developers use AI coding tools. It is whether the company can demonstrate that such use is controlled.

At a minimum, the company should be able to identify the approved tools and account types, explain what information developers may submit, produce the applicable client or project rules, show how material AI-generated code is reviewed and retain the results of relevant dependency, licence and similarity checks.

These controls should reflect the actual risk. A client concerned about model training may require a commercial account with appropriate data-use restrictions. A client concerned about data location may require approved processing locations. A company concerned about IP provenance may require human modification, code review, scanning and development records.

The objective is not to eliminate every theoretical risk. It is to establish a defensible process that protects confidential information, preserves commercially usable rights and produces evidence the company can provide during client review, investment or acquisition due diligence.

What Controls Should Apply Before Developers Use AI Coding Tools?

AI-assisted coding does not necessarily need to be prohibited, but it should not be treated as an informal developer practice. Before approving an AI coding tool, or allowing it to process client or proprietary code, a software company should connect each use case to a specific risk and an appropriate control. The table below summarises the minimum controls companies should consider.

How Aurum Can Help

Aurum advises software and product companies on the legal governance of AI-assisted development. We help clients prepare internal AI-use policies, review provider terms, negotiate AI provisions in software development agreements and establish contractual safeguards for confidential information.