AI-Assisted Software IP Lawyers Guide For UK Founders

Who Owns AI-Assisted Code? What Every UK Founder Needs to Know Now

The Code Shipped Fast. The Ownership Question Did Not Move as Quickly.

Most product teams in the UK now write code with an AI assistant open in another window. Autocomplete suggestions, generated functions, refactored blocks, entire boilerplate modules — a meaningful share of a modern codebase did not originate purely from a human hand on a keyboard. That shift happened over roughly two years. UK copyright and patent law, by contrast, was not built with this scenario in mind, and Parliament has, for now, deliberately chosen not to legislate a fix.

At PAIL Solicitors, we advise founders, developers, engineering leads and investors on exactly this gap: what happens, legally, when software is written with material AI assistance, who owns it, what warranties a buyer or investor can safely rely on, and what a development agreement needs to say to avoid a dispute two years and one funding round later. This is not a theoretical question. It affects due diligence on every SaaS fundraise, every outsourced build, and every employment contract signed by a developer in the last eighteen months.

This article sets out the current UK legal position on AI-assisted software ownership, where the law remains genuinely unsettled, and the specific contractual provisions founders, engineering leads and commissioning businesses should have in place before the next audit, acquisition or dispute forces the question. It builds on the same framework applied in our earlier guidance on founder IP strategy for international consultants and our broader look at AI's impact on creative and technology businesses.

Who This Article Is For

This article is for you if:

●      you are a SaaS founder and are not certain who legally owns code your team produced with AI coding assistants;

●      you are commissioning a software build and want the development agreement to properly address AI-assisted output;

●      you are a developer or contractor and want to understand what you can and cannot claim ownership of;

●      you are preparing for investment or acquisition due diligence and need your IP position to withstand scrutiny;

●      your business relies on open-source or third-party components inside an AI-assisted codebase; or

●      you need specialist advice from software and technology IP solicitors on ownership, provenance, warranties or licensing risk in a development agreement.

Software IP Law Is Being Rewritten in Real Time — Here Is Where It Stands

Anyone drafting or relying on a software development agreement in 2026 needs to understand that the legal foundations underneath AI-assisted code are moving, not settled. Three developments in the last twelve months matter directly to founders and their advisers.

First, the government has, for now, stepped back from reforming copyright law to accommodate AI. Following its December 2024 consultation, the government published its Report on Copyright and Artificial Intelligence on 18 March 2026. It confirmed that a broad text-and-data-mining exception with an opt-out mechanism — the option the government had previously favoured — is no longer its preferred approach. Instead, the government is monitoring ongoing litigation and the emerging AI licensing market before committing to legislative change. For founders, that means the existing, pre-AI framework of the Copyright, Designs and Patents Act 1988 is what actually governs ownership questions today, uncomfortable as parts of it are for this technology.

Second, the leading UK authority on AI and copyright infringement is not yet final. In Getty Images (US) Inc v Stability AI Ltd [2025] EWHC 2863 (Ch), the High Court rejected Getty's secondary copyright infringement claim, finding that Stability AI's model was not an "infringing copy" within the meaning of sections 22 and 23 of the CDPA because the model weights did not store a reproduction of the underlying works. Getty was subsequently granted permission to appeal that finding, and the Court of Appeal has yet to rule on the meaning of "infringing copy" and "article" as applied to AI systems. Businesses relying on this case as settled law are relying on a decision that remains live on appeal.

Third, and directly relevant to any founder considering patent protection for an AI-assisted product, the Supreme Court fundamentally changed the test for patenting computer-implemented inventions in Emotional Perception AI Ltd v Comptroller-General of Patents, Designs and Trade Marks [2026] UKSC 3, abandoning the long-standing Aerotel four-step test in favour of the European Patent Office's "any hardware" analysis under section 1(2) of the Patents Act 1977. Artificial neural networks remain, technically, "programs for a computer", but AI-related inventions now clear the initial patentability hurdle more easily than under the old test, provided the claim is assessed as a whole rather than broken down feature by feature — which matters for founders who assumed their AI-driven product was simply unpatentable software. The UKIPO's guidelines for examining patent applications relating to AI inventions have been updated to reflect this shift.

None of this gives a founder a clean answer. It confirms that ownership, infringement risk and patentability in this space are being worked out case by case, and that a development agreement drafted on the assumption that "the law will sort this out" is a liability, not a shortcut. There is also a wider international dimension UK-based teams cannot ignore — addressed in the cross-border section below.

This is worth distinguishing from the separate, older question of AI systems as inventors in their own right, which UK law has already answered. In Thaler v Comptroller-General of Patents [2023] UKSC 49, the Supreme Court held that an inventor named on a patent application must be a natural person, and that an AI system — in that case, Dr Thaler's DABUS system — cannot itself be an inventor under the Patents Act 1977. That question is settled. What remains unsettled, and what this article focuses on, is the different and more commercially pressing question of ownership where a human developer uses AI tools as an aid to their own work, rather than claiming the AI system as inventor or author in its own right.

Your Software IP Risk Framework

The ownership question for AI-assisted software breaks down into six practical areas. Each carries a different legal test, and most disputes we see involve more than one at once.

Employees, Contractors and Founders: Who Owns the Underlying Code?

Before any AI-assistance question arises, the basic UK ownership rule still governs. Under section 11 of the CDPA 1988, where a literary work — which includes computer code — is created by an employee in the course of their employment, the employer is the first owner of copyright, subject to any agreement to the contrary. Section 9 of the same Act identifies the author, and it is this authorship question that becomes genuinely difficult once AI tools are involved in producing the work, addressed below.

Contractors sit on the opposite side of a rule that catches out a large number of early-stage founders. Absent a written assignment, a contractor who writes code retains copyright in that code, even where the founder paid for the work and believes they own it outright. The founder typically holds, at most, an implied licence sufficient for the purpose for which the work was commissioned — which is rarely broad enough to support a funding round, a sale, or exclusive commercial exploitation. This is precisely the gap our June/July 2026 article on employment and founder IP strategy examined for cross-border consultants, and it applies with equal force to AI-assisted development.

This is not a new problem AI has created, but AI-assisted development has made it more likely to surface. The leading authority remains Robin Ray v Classic FM plc [1998] EWHC Patents 333, in which Lightman J emphasised that, absent an express or implied term to the contrary, a commissioned contractor retains copyright in what they create — the fact that the client paid for the work does not, by itself, transfer ownership. The Court of Appeal reached a similar result on different facts in R Griggs Group Ltd v Evans [2005] EWCA Civ 11, the well-known Dr Martens/AirWair logo dispute, where a freelance designer's failure to deal expressly with ownership at the point of commissioning left the question to be resolved through implied terms years later. Neither case is about AI, but both illustrate exactly the exposure an AI-assisted development relationship inherits by default: a contractor who used an AI coding assistant extensively, and was never asked to sign an assignment, is in no different a position than any other unassigned contractor.

A related and frequently overlooked version of the same problem arises before a company even exists. Founders who write early code, or bring existing personal tools and libraries into a new business, sometimes assume the company automatically owns whatever they contributed once it is incorporated. It does not, unless those rights have actually been assigned — a gap that is straightforward to close with a founder IP assignment at incorporation, and expensive to unwind once outside investors are asking to see it.

The equivalent position for inventions is set out in sections 39 and 40 of the Patents Act 1977. An invention made by an employee belongs to the employer where it was made in the course of the employee's normal duties, or duties specifically assigned to them, and where an invention might reasonably be expected to result from carrying out those duties. Founders who code alongside contractors, co-founders on informal terms, or early hires without signed IP assignment and invention clauses are exposed on both the copyright and patent side simultaneously — a gap that becomes visible, expensively, at due diligence stage.

This is also where the Employment Rights Act 1996 becomes relevant in a way founders often underestimate. Whether an individual is properly classified as an employee, a worker or a self-employed contractor directly determines which statutory ownership rule applies to what they build. A developer engaged as a contractor on paper but managed like an employee in practice can create genuine uncertainty over which regime governs the IP they produce — getting the classification right, and documenting it consistently, is not a separate HR question from the IP ownership question. In most disputes we see, the two are the same question asked twice.

AI-Generated and AI-Assisted Code: Where UK Copyright Law Actually Stands

This is the question founders ask most often, and UK law gives a more nuanced answer than most people expect.

Where a human developer materially directs, edits, selects and arranges AI-suggested code — which describes the overwhelming majority of real-world AI-assisted development — ordinary authorship principles under section 9 of the CDPA apply. The human developer, or their employer under section 11, is the author and first owner, because the work reflects the human's own skill, judgement and labour, exercised over and through the AI tool's output. Copyright protection is not lost simply because a developer used an AI assistant, in the same way protection was never lost because a developer used a compiler, an IDE or a code-completion library.

The position becomes genuinely uncertain at the other end of the spectrum, where a work is generated with no identifiable human author. Section 178 of the CDPA 1988 defines a "computer-generated" work as one generated by computer in circumstances such that there is no human author. Section 9(3) — the provision most commonly cited in this debate — was drafted for a pre-generative-AI world and has never been tested against a modern large language model in a reported UK judgment. Whether output from a modern coding assistant, produced from a prompt with minimal human curation, falls within this provision, and if so who counts as the person "by whom the arrangements necessary for the creation of the work are undertaken", remains an open legal question. The March 2026 government report acknowledged this gap directly and declined to resolve it by legislation.

The practical consequence for founders is this: the less human editorial and creative input that went into a piece of AI-assisted code, the weaker the copyright position, and the more important it becomes to build ownership through contract — assignment clauses, work-for-hire drafting and provenance records — rather than relying on default statutory ownership rules that were not written for this scenario.

There is a second, distinct question underneath this one that is easy to conflate with it: even where a human is clearly the author, does the work clear the originality threshold at all? The Court of Appeal's modern test, applying the "author's own intellectual creation" standard, was set out in THJ Systems Ltd v Sheridan [2023] EWCA Civ 1354, concerning graphical charts produced using software, where the Court held the works were original because free and creative choices had been made about presentation and layout, even though the degree of creativity was modest. The significance for AI-assisted code is that authorship, originality and ownership are three separate questions, not one — establishing the author under section 9 does not, by itself, establish that copyright subsists in the work at all.

There is a further wrinkle that catches out technically sophisticated teams as often as inexperienced ones: moral rights. Under sections 77 to 80 of the CDPA 1988, an author generally has the right to be identified as such and to object to derogatory treatment of their work. These rights sit separately from economic copyright ownership and are not automatically transferred by an assignment clause — they require an express waiver. Where an early contributor has left on poor terms, or a product has been substantially modified since their involvement ended, an unwaived moral right can give them a genuine point of pressure even where economic copyright was properly assigned.

Open-Source and Third-Party Components Inside an AI-Assisted Codebase

AI coding assistants are frequently trained on, and will reproduce patterns from, vast quantities of publicly available and open-source code. This creates a licence compliance risk that is easy to overlook because it does not announce itself the way a missing assignment clause does.

If AI-generated suggestions reproduce code that is, in substance, derived from a copyleft-licensed project — GPL-family licences being the clearest example — incorporating that output into a proprietary, closed-source product may trigger licence obligations the founder never intended to accept, including disclosure or redistribution requirements. A buyer's technical due diligence team will run software composition analysis tooling against the codebase precisely to catch this. Founders should treat AI-suggested code the same way they would treat a snippet copied from a public repository: it requires the same licence scrutiny, not less, simply because it arrived via an AI tool. This connects directly to how a product's customer-facing terms are drafted — see our related guidance on website terms and conditions and our digital technology legal services more broadly.

Training Data, Inputs and Confidentiality Risk

The inverse risk — information flowing out of the business rather than unlicensed code flowing in — is equally significant and less well understood by engineering teams. Pasting proprietary source code, credentials, architecture documents or client data into a third-party AI tool as a prompt can constitute disclosure of confidential information and trade secrets, engaging the Trade Secrets (Enforcement, etc.) Regulations 2018. Depending on the AI provider's terms, that input may also be retained or used to train future models, which is very difficult to reverse once it has happened. This connects directly to the questions raised in the Getty v Stability AI litigation discussed above: where training data comes from, and what a developer had the right to input into a system, are live legal issues, not settled ones — a responsible AI usage policy inside a development team is now a genuine IP protection measure.

Businesses handling personal data alongside proprietary code — most SaaS products with a user base — face a related, frequently overlooked overlap with data protection law. Where a prompt to an AI coding assistant includes production data or logs containing personal data, that may itself constitute processing under the UK GDPR, engaging separate obligations under the Data Protection Act 2018 quite apart from the trade secrets analysis above.

Warranties, Indemnities and Disclosure in Modern Development Agreements

A development agreement drafted before 2023 was not written to address any of the risks above, and yet a significant number of SaaS businesses are still trading under agreements in that form. Modern software development and services agreements need four specific mechanisms that older templates typically lack.

Before any of these four mechanisms can work properly, the agreement needs to distinguish between background IP and foreground IP — a standard commercial drafting distinction that AI-assisted development makes more important, not less. Background IP is the developer's pre-existing material: libraries, frameworks, internal tools and know-how brought to the project rather than created for it. Foreground IP is what was created specifically for this project. A clause simply stating "all IP belongs to the client" is inadequate where the deliverable, as most AI-assisted builds do, embeds both — it risks either accidentally assigning a developer's entire toolset, or leaving a client with less than it thought it had bought. The commercially sound structure is usually an assignment of foreground IP combined with a sufficiently broad licence to any embedded background technology, set out expressly rather than left to be inferred.

First, an express IP assignment clause covering all deliverables, including code produced with the assistance of AI tools, drafted broadly enough to capture future rights and moral rights waivers under sections 77 to 89 of the CDPA where relevant. Second, a disclosure obligation requiring the developer to identify, at delivery, which components of the codebase were produced with material AI assistance, and which third-party or open-source components are embedded in the product — increasingly documented as a software bill of materials on larger projects. Third, a warranty that the developer has not input the client's confidential information into any AI tool in a manner inconsistent with the client's instructions, and has appropriate licences for any open-source or AI-generated content incorporated into the deliverable. Fourth, an indemnity allocating responsibility if a third-party claim later arises from AI-assisted content — a clause that is now regularly negotiated, and regularly missing, on both sides of commissioning relationships we advise on.

Provenance and Audit Trails: What Founders Need to Prove Ownership

Ownership arguments in this area are won or lost on evidence, not assertion. A founder facing an investor's due diligence questionnaire, or a competitor's infringement allegation, needs to be able to show, not simply state, how a given piece of code came into existence — through version control history, signed assignment paperwork, and treating AI tool selection itself as a legal decision rather than a purely technical one. The checklist below sets out what this looks like in practice.

The Cases UK Founders Need to Know

Alongside the AI-specific authorities above, a small set of older software copyright cases still does most of the work in UK disputes over what, exactly, is protected in a piece of software — and they matter just as much to an AI-assisted codebase as to a hand-written one.

In Nova Productions Ltd v Mazooma Games Ltd [2007] EWCA Civ 219, the Court of Appeal confirmed that copyright protects the expression of a computer program, not the underlying ideas, rules or functionality it implements — a competitor is generally free to build a product that does the same thing, provided they do not copy the way it is expressed in code. In SAS Institute Inc v World Programming Ltd [2013] EWCA Civ 1482, the Court of Appeal held that programming languages, data file formats and functionality are not protected as copyright expression merely because a program uses them. And in Navitaire Inc v easyJet Airline Co Ltd [2004] EWHC 1725 (Ch), the High Court held that reproducing a program's "look and feel" or business functionality, without copying the underlying source code, does not by itself amount to infringement.

Taken together, this line of authority means AI coding assistants — frequently used to reproduce familiar functionality and standard architectural patterns rather than verbatim code — are less likely to create infringement exposure purely by replicating what software does. The open-source exposure identified earlier arises specifically where an AI tool reproduces the expression, the actual code, of an existing work, not merely its function — the single most useful mental model for assessing AI-assisted code for infringement risk. For comparative context, US courts reached a broadly similar functional conclusion in Google LLC v Oracle America Inc, 593 U.S. 1 (2021), though that decision turns on the US fair use doctrine, which has no direct UK equivalent.

UK, EU and US Rules: The Cross-Border Position

Most UK SaaS founders are not building for a UK-only market, and the legal position on AI-assisted software ownership and compliance genuinely differs once a product is sold, hosted, or developed across borders.

The European Union. Software copyright within the EU is harmonised by the Software Directive 2009/24/EC, which broadly mirrors the UK's idea/expression distinction above, reflecting the two frameworks' shared origin prior to Brexit. The EU's approach to AI training data sits in the Digital Single Market Directive 2019/790, whose Articles 3 and 4 provide text-and-data-mining exceptions, including a rights-holder opt-out — the mechanism the UK government considered and, as discussed above, chose not to adopt. EU trade secret protection sits under Directive (EU) 2016/943, the direct counterpart to the UK's 2018 Regulations, and any UK business placing an AI system on the EU market, or whose AI system affects people in the EU, also needs to assess its obligations under Regulation (EU) 2024/1689 (the AI Act), which regulates AI systems by risk category, largely independently of the IP ownership questions addressed elsewhere in this article.

The United States. The US Copyright Office has taken a materially more restrictive position than the UK on protecting AI-generated material, set out in its ongoing AI initiative and its Part 2 report on the copyrightability of AI outputs, which confirms that US copyright protection requires human authorship under 17 U.S.C. § 102, and that purely AI-generated material is not registrable — a firmer line than the UK's still-unresolved section 178 question above. The US Defend Trade Secrets Act, 18 U.S.C. § 1836 provides a federal civil cause of action broadly analogous to the UK's 2018 Regulations, and the NIST AI Risk Management Framework, while not binding law, is widely used by US investors as a benchmark for AI governance maturity during due diligence.

The practical takeaway: do not assume an ownership position, licensing structure or training-data justification that works under UK law transfers cleanly to a product sold into the EU or the US. Each framework starts from a different premise about what AI-assisted authorship requires, and a cross-border SaaS business needs its IP strategy reviewed against all three, not just the one its head office sits in.

A Practical Software IP Checklist for Founders

Before the next funding round, acquisition conversation or contractor engagement, founders and engineering leads should be able to answer the following with documentation, not recollection.

Ownership paperwork. Every employee, founder, co-founder and contractor who has touched the codebase should have signed a written IP assignment covering copyright, database rights, and where relevant, an obligation to cooperate with future patent applications under section 7 of the Patents Act 1977. Verbal agreements between friends or former colleagues are the single most common gap corrected under time pressure during due diligence.

AI tool governance. The business should have a written policy identifying which AI coding assistants are approved, what categories of code or data may be submitted to them, and how each tool's terms affect the business's rights in prompts and output alike. Review this whenever a new tool is adopted.

Provenance records. Version control history should, as far as practicable, demonstrate human review and editorial input into AI-assisted commits rather than raw AI output committed unchanged. Flag components generated with minimal human curation as higher-risk assets requiring closer contractual protection.

Open-source and third-party licence audit. Run software composition analysis periodically, not only before a fundraise, so copyleft or otherwise problematic dependencies introduced via AI-assisted suggestions are caught early rather than discovered during an investor's technical due diligence.

Development agreement review. Check agreements with external developers, agencies or outsourced teams against the four provisions above — assignment, disclosure, warranty and indemnity — and update anything that predates AI-assisted development becoming standard practice in that relationship.

What We Are Seeing in Practice

Three patterns come up repeatedly in the software IP matters PAIL Solicitors advises on, and each illustrates why this cannot be treated as a purely technical issue. They sit alongside the wider AI governance risks — vendor terms, liability allocation, regulatory exposure — that we set out in SaaS Artificial Intelligence Lawyers: Top Eight Legal Risks.

The first is the pre-funding-round scramble. A founding team built a substantial share of an early product using AI coding assistants and a mix of contractors engaged on informal terms, sometimes friends or former colleagues, without signed assignment paperwork. The gap only surfaces when an investor's due diligence team asks a straightforward question — who owns this code, and can you prove it — that the founders had never been asked before. Resolving it retrospectively, once a contractor has left the country or a relationship has soured, is considerably harder than addressing it at the point of engagement.

The second is the commissioned-build dispute. A business commissions a software product from a development agency, the agency's team uses AI assistance extensively to accelerate delivery, and the resulting agreement is silent on how that assistance affects ownership, licensing of third-party components, or warranties. When the commissioning business later wants to extend, resell or white-label the product, it discovers the agreement's IP clause was drafted for a pre-AI development process and does not clearly capture what was actually built or how. The problem is often compounded where the agency itself used subcontractors — the real chain runs individual developer to subcontractor to agency to client, and the agreement with the agency does not, by itself, prove that every link in that chain actually transferred the rights it needed to.

The third pattern involves departing developers rather than external agencies. A technical co-founder or senior engineer leaves a business on difficult terms, having used AI tools extensively throughout their tenure, sometimes on a personal account rather than a company-managed one. The remaining team then has to establish both that their code was properly assigned notwithstanding the AI assistance involved, and that no confidential information was retained in that individual's personal AI tool history in a way that could support a competing product. Both problems are far easier to prevent through clear tool governance and assignment paperwork at the point of hiring than to resolve after the relationship has broken down. All three patterns are avoidable with the right clauses in place before development begins, not after a dispute has crystallised.

Why Choose PAIL Solicitors for Software and AI IP Advice

Peter Adediran founded PAIL Solicitors on the basis that internet, technology and IP law needed specialist practitioners who understood both the legal framework and how software businesses actually operate. He authored A Practical Guide to Business, Law & the Internet (Kogan Page, 2002), recognised as the UK's first internet law textbook, and has advised on digital media, technology and IP matters throughout the period in which software development has been transformed twice over — first by the shift to cloud and SaaS delivery, and now by AI-assisted development.

This background matters directly to the questions in this article. Advising on AI-assisted software ownership requires more than applying the CDPA and Patents Act by rote; it requires judgement about where those statutes were not written with this technology in mind, and where a client's commercial position needs to be protected by contract rather than relied upon through statute alone. PAIL Solicitors is SRA-regulated (SRA No. 827265) and works with founders at every stage, from first engagement letters and contractor assignment agreements through to investment-round due diligence and, where necessary, dispute resolution over disputed code ownership.

Peter Adediran will present a dedicated session on this subject, IP in Software Agreements — Drafting, Negotiating and Protecting Ownership, for MBL Seminars on 12 March 2027, reflecting the firm's ongoing specialism in this exact area. Founders and in-house teams working through these issues now are welcome to get in touch directly for a fixed-fee assessment of their current agreements and IP position, through our technology and AI legal services or our IP licensing team.

Software IP questions also rarely arrive in isolation: a gap in a contractor assignment clause is often connected to a wider employment structuring question, and a licensing risk in an AI-assisted codebase is often connected to a commercial contract with a customer or distribution partner. The firm's practice spans commercial contracts, executive and technical employment, and copyright and patent disputes alongside the firm's full legal services for IP protection, so a founder does not need to instruct a different specialist for each connected issue.

What Happens When You Instruct PAIL Solicitors

1. Confidential IP Position Review

We begin with a review of your current agreements — employment contracts, contractor agreements, development and services agreements — against the ownership risks set out in this article, identifying gaps in assignment, disclosure and warranty coverage before they become a live problem.

2. Provenance and Audit Assessment

Where AI tools have been used extensively in development, we advise on what evidence is realistically available to support your ownership position, and what should be captured going forward to strengthen it before the next funding round, sale or dispute.

3. Contract Drafting and Negotiation

We draft or renegotiate development, employment and contractor agreements to properly address AI-assisted output, open-source components, confidentiality obligations around AI tool usage, and appropriate warranties and indemnities on both sides of a commissioning relationship.

4. Due Diligence Support

For founders preparing for investment or acquisition, we prepare the IP data room, respond to technical and legal due diligence queries, and remediate gaps identified before they affect valuation or deal terms.

5. Dispute Resolution

Where an ownership dispute has already arisen — with a former contractor, a co-founder, or a commissioning client — we advise on the available legal routes under copyright, patent, confidentiality and contract law, and represent clients through negotiation or litigation as required.

Frequently Asked Questions

Does using an AI coding assistant mean I lose copyright in my software?

No, not in the ordinary case. Where a human developer directs, edits, selects and arranges the output of an AI coding assistant, the resulting work is protected the same way as any other code written with modern development tools, and the developer, or their employer under section 11 of the CDPA 1988, remains the owner. The genuinely uncertain territory is output with minimal human input, where the "computer-generated works" provisions in section 178 have not yet been tested against modern AI tools by a UK court, and the government's March 2026 report chose not to resolve the point by legislation.

Do I own code written by a contractor using AI tools, if I paid for it?

Not automatically. Paying for development work does not, by itself, transfer copyright. Under UK law, a contractor who authors code retains ownership unless there is a written assignment transferring it to you, and without one you typically hold only an implied licence sufficient for the immediate purpose of the engagement. This applies whether or not AI tools were used in the development process, and it is one of the most common gaps we see in early-stage founder agreements at due diligence stage.

Can AI-assisted software be patented in the UK?

Potentially, yes, and the position has become more favourable following the Supreme Court's 2026 decision in Emotional Perception AI Ltd v Comptroller-General of Patents, which replaced the older Aerotel test with an approach aligned to the European Patent Office. Artificial neural networks remain, technically, programs for a computer under section 1(2) of the Patents Act 1977, but the claim is now assessed as a whole rather than broken into isolated features, so AI-related inventions clear the initial threshold more readily than before, subject to the usual novelty and inventive step requirements.

What should a software development agreement say about AI-assisted code?

At minimum, it should include a broad IP assignment clause expressly covering AI-assisted deliverables, a disclosure obligation identifying which parts of the codebase were produced with material AI assistance and which third-party or open-source components are embedded within it, a warranty regarding appropriate licensing and confidential information handling, and an indemnity allocating responsibility for third-party claims arising from AI-generated content. Older template agreements, drafted before AI-assisted development became standard practice, will typically lack all four provisions and should be reviewed rather than relied upon as-is.

Is it safe to use AI tools on client or proprietary code?

Not without a policy in place. Pasting confidential source code, credentials or client data into a third-party AI tool as a prompt can amount to disclosure of confidential information and trade secrets, engaging protections under the Trade Secrets (Enforcement, etc.) Regulations 2018, and may result in that information being retained or used by the AI provider depending on its terms of service. Development teams should have a clear, enforced policy on which tools may be used, on which categories of code or data, before this becomes a live incident rather than a hypothetical risk.

What happens if AI-generated code reproduces open-source or copyleft-licensed material?

It creates the same licence compliance exposure as if a developer had manually copied that code from a public repository. If AI-suggested output reproduces material substantially derived from a copyleft licence, incorporating it into a proprietary product may trigger disclosure or redistribution obligations the founder did not intend to accept. This is precisely the kind of issue that surfaces in software composition analysis during technical due diligence, and it should be audited for specifically, not assumed away because the code originated from an AI tool rather than a direct copy-paste.

Is Getty Images v Stability AI settled law that I can rely on?

Not yet. The High Court's November 2025 judgment in Getty Images (US) Inc v Stability AI Ltd rejected Getty's secondary copyright infringement claim, but Getty was subsequently granted permission to appeal the finding on the meaning of "infringing copy" under sections 22 and 23 of the CDPA. The Court of Appeal has not yet ruled. Businesses building AI-related legal positions on the assumption that this case has finally settled the relevant questions should treat that assumption as provisional until the appeal is resolved.

Does the EU AI Act apply to a UK software business?

It can, depending on how the product is placed on the market. Regulation (EU) 2024/1689 applies to AI systems placed on the EU market or whose output is used within the EU, regardless of where the provider is established, meaning a UK-based SaaS business selling into EU customers may fall within scope even though it has no EU office. This sits alongside, and is separate from, the IP ownership questions addressed elsewhere in this article — a UK software business selling into the EU should treat AI Act compliance and IP ownership as two distinct workstreams requiring separate review, not a single combined assessment.

Useful Links and Resources

●      PAIL Solicitors

●      PAIL Solicitors — AI and Technology Legal Services

●      PAIL Solicitors — IP Licensing Agreements

●      Government Report on Copyright and Artificial Intelligence, March 2026

●      Copyright, Designs and Patents Act 1988

●      Patents Act 1977

●      Trade Secrets (Enforcement, etc.) Regulations 2018

●      UKIPO Guidelines for Examining AI Patent Applications

●      UK GDPR and Data Protection Act 2018

●      Getty Images (US) Inc v Stability AI Ltd [2025] EWHC 2863 (Ch)

●      Emotional Perception AI Ltd v Comptroller-General of Patents [2026] UKSC 3

●      Thaler v Comptroller-General of Patents [2023] UKSC 49

●      Robin Ray v Classic FM plc [1998] EWHC Patents 333

●      R Griggs Group Ltd v Evans [2005] EWCA Civ 11

●      THJ Systems Ltd v Sheridan [2023] EWCA Civ 1354

●      Nova Productions Ltd v Mazooma Games Ltd [2007] EWCA Civ 219

●      SAS Institute Inc v World Programming Ltd [2013] EWCA Civ 1482

●      Navitaire Inc v easyJet Airline Co Ltd [2004] EWHC 1725 (Ch)

●      Regulation (EU) 2024/1689 — the EU AI Act

●      US Copyright Office — AI and Copyright Initiative

A Note on Terms of Service and AI Provider Contracts

One further point is easily missed: the contract a business has with its AI coding tool provider is itself a source of IP risk. These terms vary significantly between providers, change more frequently than most commercial contracts a business signs, and typically govern what rights the provider retains over submitted prompts, whether that input trains the provider's own models, and what indemnity, if any, applies if generated output later infringes a third party's rights. A founder who has carefully drafted internal assignment and disclosure clauses but has not reviewed their AI tool provider's terms has closed one gap while leaving another open immediately upstream of it — a review that should happen whenever a new tool is adopted at scale, not once and forgotten.

Conclusion — The Tools Changed Fast. Your Agreements Should Catch Up.

AI-assisted development is not a future risk for UK software businesses to plan for eventually. It is the current, ordinary way that most code gets written, and the legal framework governing who owns the result is being worked out through litigation and government reports that are still, as of this article, unresolved. That uncertainty is exactly why contractual protection matters more now, not less — a properly drafted assignment clause, disclosure obligation and provenance record does the work that statute alone cannot yet reliably do.

Two distinctions are worth holding onto above everything else in this article. Having contractual rights against a developer or an AI provider does not, by itself, establish that the resulting output is protected by copyright at all. And owning copyright in a piece of AI-assisted code does not, by itself, establish that the code is free of somebody else's rights. Ownership, subsistence and infringement risk are three separate legal questions, and a founder who has only asked one of them has not actually finished the analysis.

If you need advice on software IP ownership, AI-assisted development agreements, contractor and employee IP assignment, or due diligence preparation ahead of a funding round or sale, contact PAIL Solicitors for a confidential assessment of your position. Whether you are a solo founder formalising early agreements for the first time, an engineering lead managing a distributed team's AI tool usage, or an investor assessing a target's IP position before a term sheet is signed, the underlying legal questions in this article will affect the value and defensibility of the software you build, buy or fund — and they are considerably cheaper to address now than after a dispute, an audit failure or a collapsed deal has already made the answer urgent.

Need help with AI-assisted software IP ownership, a development agreement, contractor or employee IP assignments, or preparing your software IP position for investment or due diligence? Contact PAIL® Solicitors for a confidential assessment.

Call: 0207 305 7491
Email: peter@pailsolicitors.co.uk

Call now Email us

This article is for general information purposes only and does not constitute legal advice. Nothing in this article creates a solicitor-client relationship between the reader and PAIL Solicitors Limited. If you have a specific situation involving software IP ownership, AI-assisted development, or development agreement disputes, you should seek independent legal advice. Contact PAIL Solicitors for a confidential, fixed-fee consultation: peter@pailsolicitors.co.uk | 0207 305 7491 | pailsolicitors.co.uk

PAIL Solicitors Limited is authorised and regulated by the Solicitors Regulation Authority (SRA No. 827265). Peter Adediran is the author of A Practical Guide to Business, Law & the Internet (Kogan Page, 2002), the UK's first internet law textbook.