Most development teams I speak with now use AI coding assistants every day, and the gain in speed is real. The tools do, however, raise two legal questions that I think founders should answer early. The first is what the team is sending to the tool, since prompts can contain customer data and confidential code, and the second is what rights the company has in the code that comes back and ends up in the product.
The answers depend on the provider's terms and on how much the developers actually contributed to the final code. Customers and investors have started to ask about this, so I advise companies to put a policy and a record in place before the question comes up.
Start with the account and terms you use
The first step is to find out which tools the team uses and on which plan. Many developers use personal or free accounts, and those often come with different data terms from a paid business or enterprise plan, which means the protections the company expects to rely on may only exist on the higher tier.
The provider's terms on output also need to be read. Most say the user owns the output as far as the law allows, or they assign whatever rights the provider has, but none of them promise that nobody else can claim similar code. The company should save the version of the terms it accepted and note the settings it chose.
Where the company builds a customer feature on a provider's API, it should treat that API as a platform the product depends on, with its own usage limits and the provider's right to change or withdraw the service. I cover those contract terms in before your business depends on another platform.
What copyright protects
Copyright protects human creative work. The US Copyright Office's 2025 report on AI and copyrightability says that purely AI‑generated material is not protected in the United States, although human selection and arrangement of that material can be, and the US courts have confirmed that a human author is required. Nigeria's Copyright Act 2022 does not deal with AI output directly, so protection here depends on how the Act's rules on originality and authorship apply to the human contribution.
In practice, this means the company should keep a record of what its developers designed and wrote themselves, such as the architecture and any substantial rewriting of generated code. That record helps show which parts of the codebase are protected and which were accepted largely as the tool produced them.
The company still needs written assignments from employees and contractors covering everything they contribute, whether or not they used AI tools, and I explain that chain of documents in making sure the company has the rights to its software.
Control what goes into the tool
A prompt containing customer data or confidential source code discloses that material to the provider. Before anyone does that, the company should check that its customer contracts allow it and that the provider's terms on retention and training are acceptable, since many customer agreements prohibit sharing their data with third parties at all.
The training setting is not the only one that matters. Providers may also store prompts and logs for abuse monitoring, and human reviewers may be able to see them, so the company should note these settings alongside the terms it accepted.
Personal data in prompts needs a lawful basis and, if the provider processes it outside Nigeria, a valid route for the cross‑border transfer under the Nigeria Data Protection Act and the GAID 2025. Removing names is often not enough to anonymise data, because the remaining details can still identify a person, so the team should either use an approved tool or remove the personal data properly before sending a prompt.
Review the output like any other code
Generated code should go through the same engineering and security review as code written by a person. Someone who understands the code should test it under the conditions the product will face, and the review should be recorded with the commit so that it can be traced later.
Some tools flag output that matches publicly available code. Where that happens, the licence of the matched code, and of any dependency the tool suggests, should be checked, because copyleft terms can be triggered by distribution or by offering the software over a network. The source and the licence version should then be recorded.
When a scan finds a problem, it should be followed through to a decision, which will usually be to comply with the licence or to replace the code, and the company should keep a record of what it did.
Read the indemnity before relying on it
Several large providers offer to defend business customers against copyright claims relating to the tool's output, but these promises come with conditions. They often apply only to certain plans and exclude output the customer has modified or combined with other code, and some require particular filters to be switched on, so the company should check whether its team's actual use qualifies.
The claims process is also worth reading closely, including who controls the defence and whether the provider can settle on terms that restrict the company's product. The company should also check whether the remedy pays the claim or only gives the provider the right to modify or replace the affected code, and compare that with what replacing the code would cost in engineering time and disruption to customers.
Customers are beginning to ask for warranties about the use of AI, so whatever the company promises should match how its team actually works, and the wording should be agreed before delivery.
Give the team a policy they can follow
A short policy is more useful than a long one that nobody reads. It should name the approved tools and say what may and may not be included in prompts, and it should explain how generated code is reviewed and recorded, with a way for engineers to request an exception.
If a problem appears after release, the company should preserve the affected versions and identify where the code is used. It should then check whether its contracts require it to notify customers, and keep a record of the fix so that it can show the correction reached the product customers are using.
This article is general information and not legal advice. For guidance on your specific circumstances, speak with us directly.