AI Intellectual Property Strategy for UK Companies: Protecting Innovation Before Investment and International Expansion

When an investor or acquirer evaluates an AI company, the balance sheet tells only a small part of the story. Physical assets are typically negligible, revenue may still be early-stage, and the customer base may be small relative to the company's ultimate ambitions. What the buyer or investor is actually pricing is the intangible asset base: the model architecture, the accumulated training data and the engineering know-how that would take a competitor years and substantial capital to replicate. Where that intangible asset base is clearly and demonstrably owned by the company, it commands a premium. Where ownership is ambiguous, contested or simply undocumented, the same technology commands a materially lower price, or the transaction stalls entirely pending resolution.

This dynamic is more pronounced for AI companies than for many other categories of technology business because the marginal cost of replicating a working software product has fallen sharply, while the cost of assembling the right team, the right training data and the right accumulated tuning decisions has not. A well-drafted software licence or a defensible patent portfolio in an earlier technology era conferred protection that was relatively legible to a buyer. An AI company's true competitive moat is frequently a combination of proprietary data, accumulated model refinement and institutional know-how that resists simple legal categorisation, which makes the underlying ownership and protection questions more important, not less.

Founders sometimes assume that because their product works and their customers are satisfied, the intellectual property question will resolve itself favourably when it eventually arises. In practice, the question arises at the least convenient possible moment: during exclusivity on a funding round, during exclusivity on an acquisition, or during a dispute with a departing co-founder or a disgruntled early contractor. At each of these moments, the company's negotiating leverage is lower than it was before the process began, and the cost of remediation, in legal fees, in delay and in reduced valuation, is materially higher than the cost of having addressed the issue proactively.

There is also a reputational dimension that is easy to overlook. Enterprise customers procuring AI software increasingly ask, as a standard due diligence question, whether the vendor can warrant clean ownership of the intellectual property being licensed to them, because the customer's own legal exposure depends on that warranty being true. A vendor unable to answer the question cleanly loses credibility independent of the quality of its technology, in much the same way a vendor lacking basic data protection registration loses credibility regardless of product strength.

The practical implication is that AI intellectual property strategy should be treated as a foundational corporate discipline, established early and maintained continuously, rather than a technical legal exercise conducted once, under pressure, when an external counterparty first asks for it. Companies that build this discipline from an early stage typically find the eventual due diligence process materially smoother, faster and less expensive than companies attempting to construct the record retrospectively.

AI companies generate a broader spread of intellectual property than a typical software business, and understanding which legal regime applies to which asset is the necessary first step in building a coherent protection strategy. Source code, including the code implementing a model's training pipeline, inference logic and surrounding application, attracts copyright protection under UK law automatically upon creation, in the same manner as literary work, provided it is original and recorded in a fixed form. This protection extends to the literal expression of the code but not to the underlying method, algorithm or functional idea it implements, a distinction that becomes commercially significant once a competitor builds a functionally similar system using different code.

Documentation, including technical specifications, model cards, internal engineering documentation and user-facing materials, is separately protected by copyright as literary work, and is frequently under-valued as an intellectual property asset despite representing a substantial body of accumulated institutional knowledge. Trained machine learning models occupy a more ambiguous legal position: the code implementing the model architecture is copyright-protected, but the trained weights themselves, the numerical parameters resulting from a training process, are not clearly categorised under existing UK intellectual property statute, and protection in practice tends to rely on a combination of copyright in the surrounding code, contractual restriction, and trade secret protection over the training methodology and resulting artefact.

Training datasets attract protection through a combination of copyright, where the dataset itself involves sufficient originality in selection or arrangement, and database right, a distinct UK and EU-derived right protecting the investment made in obtaining, verifying or presenting the contents of a database, which can apply even where the individual data points within it are not separately protected. For an AI company, the question of whether it has the right to use, retain and commercially exploit its training data, whether that data was licensed, scraped, purchased or generated internally, is now one of the most heavily scrutinised elements of technical due diligence, and provenance failures here can be significantly more damaging than a gap in code ownership.

Patents are available in the UK for computer-implemented inventions, including certain AI-related inventions, but the threshold is genuinely demanding: an invention must make a technical contribution that goes beyond a mere method of doing business, an abstract algorithm, or a computer program as such, categories which UK patent law and the Intellectual Property Office's guidance treat with particular caution. Many AI inventions, particularly at the level of a novel model architecture or training technique, struggle to clear this threshold, which is why trade secret protection, covering the confidential know-how, methodology and undocumented engineering decisions behind a system, frequently does more practical protective work for AI companies than patents do.

Trademark protection, covering the company's brand, product names and logos, sits alongside these other rights and protects market positioning rather than the underlying technology, but should not be neglected: a company that has built genuine goodwill in a product name without registering it as a trademark faces avoidable risk as it expands into new markets and encounters competing users of similar names. A coherent AI intellectual property strategy addresses each of these categories deliberately rather than assuming that a single registration or agreement covers the full spread of the company's actual intangible assets.

Who owns AI intellectual property depends, as a matter of UK law, on who created it and under what relationship. Copyright in work created by an employee in the course of their employment vests automatically in the employer, without any need for a separate assignment, provided the work genuinely falls within the scope of that employment. This default rule is helpful but should not be relied upon without a written contract of employment that expressly confirms it, because disputes commonly arise over whether a particular piece of work, developed outside strict working hours or slightly outside a job description, genuinely falls within the scope of employment as the statute requires.

Work created by a self-employed contractor or an external agency follows the opposite default rule: in the absence of a written agreement stating otherwise, the contractor retains ownership of the intellectual property they create, and the commissioning company acquires, at most, an implied licence to use it for the purpose for which it was commissioned. This default is a frequent source of avoidable exposure for early-stage AI companies, which often engage contractors, freelance engineers or offshore development teams during the earliest and most technically formative period of the company's life, precisely when no formal IP assignment paperwork has yet been put in place.

Work created by a founder before the company was incorporated presents the same problem in a different guise. Code, model prototypes and documentation developed by a founding team in the months before incorporation belong, as a matter of law, to the individuals who created them, not to the company that is subsequently formed to commercialise that work. Unless each founder executes a written assignment transferring pre-incorporation intellectual property to the company, the company's actual legal ownership of its own founding technology can be genuinely unclear, a gap that due diligence teams are specifically trained to look for and that is remarkably common in early-stage technology businesses.

Work created using cloud infrastructure, third-party APIs or foundation models licensed from external providers introduces a further layer of complexity, because the terms of those underlying services frequently include their own ownership, usage and output rights that constrain what the AI company can subsequently claim to own or exclusively exploit. A company that fine-tunes a third-party foundation model, for example, should understand precisely what the underlying provider's terms say about ownership of the fine-tuned artefact, before representing to an investor or customer that the resulting model is proprietary.

The overarching principle for founders to internalise is that ownership does not follow intention or informal understanding; it follows the specific legal relationship in place at the moment the work was created, and the applicable law of the jurisdiction in which the creator was working. Where the underlying legal default does not deliver the outcome the founders assume, only a written agreement executed at the right time closes that gap, and it cannot generally be closed retrospectively with the same legal certainty once a dispute or a due diligence process has already begun.

Should founders assign IP to the company? In almost every case, yes, and doing so promptly at incorporation is one of the highest-leverage governance steps an AI startup can take. A founder IP assignment agreement is a formal, written document under which each founder transfers to the newly incorporated company all rights, title and interest in the intellectual property they created relating to the business, whether developed before or after incorporation, in exchange for their shareholding and role in the company. Without this document, the company's ownership of its own founding technology rests on an informal and legally uncertain understanding between people who, at the time, may not have been thinking about the eventual scrutiny that understanding would face.

The mechanics of a founder assignment are relatively straightforward but are frequently done poorly or not at all in the rush of early-stage incorporation. The agreement should specifically describe, or reference a schedule describing, the pre-existing intellectual property being assigned, rather than relying on vague catch-all language, because a due diligence reviewer will want to see that the founders and the company had a shared, specific understanding of what was actually being transferred. It should also address any intellectual property the founder brings into the business that was created for or is owned by a previous employer, since a founder who inadvertently uses code or methods still owned by a former employer creates a latent claim against the new company.

A related and commonly overlooked issue is prior employer restrictions. Founders who leave a previous role to start an AI company should review their former employment contract for intellectual property assignment clauses, confidentiality obligations and non-compete or non-solicitation restrictions before building anything resembling their previous employer's technology. A well-drafted founder assignment agreement for the new company does nothing to protect against a claim brought by a former employer whose own contractual rights were breached in the process of building the new company's core technology.

For AI companies specifically, founder assignment agreements should also address ownership of any models, datasets or research outputs a founder developed during a previous academic affiliation, since university technology transfer policies frequently claim institutional ownership over research outputs, including code and datasets, created using university resources or during the course of a founder's academic employment or studies. This is a genuinely common source of dispute for university spin-out AI companies and should be resolved, ideally through a formal licence or assignment from the university, before the company represents to investors that it owns its core technology outright.

Boards and early investors should treat the existence of a properly executed founder IP assignment agreement as a condition of investment rather than a formality to be tidied up later, because the cost of obtaining it after a founder has left on bad terms, or after a dispute has arisen, is substantially higher, both financially and in terms of deal risk, than the cost of obtaining it cleanly at the outset.

A coherent AI intellectual property position depends on every person who has contributed to the company's technology, whether as an employee, a contractor, an agency engineer, an intern or an advisor, having signed an agreement that clearly and specifically assigns their intellectual property contribution to the company. This is sometimes described as the company's ownership chain, and diligence reviewers will typically ask to see the full chain, cross-referenced against the company's actual historical headcount and contractor list, rather than accepting a general assurance that appropriate agreements are in place.

For employees, UK employment contracts should contain an express intellectual property clause confirming that all work created in the course of employment belongs to the company, in addition to the statutory default, because the express clause removes ambiguity about the scope of employment and covers situations, such as work created partly outside formal working hours or using personal equipment, that might otherwise be contested. The contract should also include confidentiality obligations that survive termination of employment, given that departing engineers frequently move to competitors or start their own ventures in the same technical field.

How should contractors assign IP? Every contractor and consultancy agreement should include an explicit, present-tense assignment clause, one that assigns intellectual property as it is created rather than merely promising to assign it in the future, together with a waiver of any moral rights the contractor might otherwise retain under UK copyright law, since moral rights, including the right to be identified as the author and the right to object to derogatory treatment of a work, do not transfer automatically even where economic ownership does. Agencies and offshore development shops should be required to flow the same assignment obligations down to their own individual engineers, since an agency's own assignment to the client is only as good as the agency's own chain of ownership from its staff.

AI companies working with specialist data labelling contractors, annotation vendors or crowdsourced labour platforms face a particular version of this problem, because the output of that work, labelled or annotated training data, is itself a valuable intellectual property asset, and the underlying service agreement should specifically address ownership and usage rights over the labelled dataset, not merely the fee arrangement for the labelling service. Companies that overlook this frequently discover, only when a diligence reviewer asks, that they have no clear contractual right to the very data underpinning their model's performance.

Finally, companies should maintain a simple, living register mapping every material contributor to the company's technology, whether current or departed, against the corresponding signed assignment or employment agreement. This register is one of the first documents a serious investor's or acquirer's legal team will request, and its absence, or its incompleteness, is treated as a material governance gap independent of whatever the underlying agreements actually say.

Because a meaningful proportion of an AI company's most valuable intellectual property, particularly training methodology, hyperparameter choices, data pipeline design and undocumented engineering judgement, does not qualify cleanly for copyright or patent protection, trade secret protection carries disproportionate practical weight for this sector. Unlike registered rights, trade secret protection under UK law, principally through the law of confidence and the Trade Secrets (Enforcement, etc.) Regulations 2018, exists only for as long as the information genuinely remains secret and is subject to reasonable steps to keep it that way; it confers no protection at all against a competitor who arrives at the same technique independently.

This makes the company's own internal confidentiality discipline the primary determinant of whether its trade secrets are legally protectable at all, not merely a matter of prudent business practice. Reasonable steps typically include restricting access to sensitive technical material on a need-to-know basis, marking confidential documentation clearly, requiring confidentiality undertakings from every employee, contractor and advisor with access to sensitive material, and maintaining access logs and technical controls, such as permissioned repositories, that would allow the company to demonstrate, if ever required, that it treated the information as genuinely confidential.

Non-disclosure agreements with prospective investors, partners, customers and acquirers are a related but distinct protection, and AI founders should resist the instinct to disclose model architecture, training methodology or dataset composition in detail during early commercial conversations without an executed NDA in place, however commercially awkward the request may feel in a competitive fundraising or sales process. A signed NDA does not guarantee that confidential information will not leak, but its absence removes a meaningful legal remedy if it does, and its presence signals a level of institutional discipline that sophisticated counterparties expect to see.

Trade secret protection interacts closely with employee mobility. Because UK law does not generally enforce broad, unqualified non-compete restrictions against employees, and enforces even narrower restrictions against contractors, companies should not assume that a departing senior engineer can be prevented from working for a competitor purely through a restrictive covenant; the more durable protection is a robust confidentiality obligation, properly drafted and genuinely enforced, combined with practical measures such as revoking system access immediately on departure and conducting a structured exit interview addressing confidentiality obligations explicitly.

Boards should also recognise that trade secret protection is inherently fragile in the AI sector because talent mobility between AI companies is high, technical conferences and publications encourage disclosure as a matter of professional culture, and open collaboration with academic partners can inadvertently place material into the public domain. A deliberate internal policy on what may and may not be discussed publicly, published in a paper, or disclosed to a research partner is a necessary complement to the contractual protections described above, not an alternative to them.

Can AI software be copyrighted? Yes, in the sense that the source code implementing an AI system, including its training pipeline, inference engine and surrounding application layer, is protected by copyright automatically under UK law from the moment it is created in fixed form, in the same manner as any other computer program, provided it is original in the sense of being the author's own intellectual creation. This protection does not require registration, a formality that does not exist for copyright under UK law, and arises without any positive act beyond creation and fixation.

The important qualification is that copyright protects the specific expression of the code, not the underlying idea, method, algorithm or functional approach it implements. A competitor who studies a company's published research, observes its product's behaviour, or independently develops functionally similar software without copying the actual code has not infringed copyright, even if the resulting system performs a very similar function using a conceptually similar approach. This is a materially different and generally weaker form of protection than patent protection would confer, where available, because a patent, once granted, can in principle prevent a competitor from practising the same inventive concept even if they arrived at it through entirely independent development.

A further complication specific to AI systems concerns authorship of AI-generated output itself. UK copyright law contains a specific provision addressing computer-generated works that have no identifiable human author, attributing authorship to the person who made the arrangements necessary for the work's creation, but the application of this provision to outputs generated by modern generative AI systems remains an area of genuine legal uncertainty and active policy debate, both in the UK and internationally. Companies building products that generate text, images, code or other creative output for customers should treat the copyright status of that output as an open question requiring specific advice, and should be cautious about the warranties they give customers regarding the ownership or exclusivity of AI-generated deliverables.

Documentation, including model cards, training methodology write-ups, internal wikis and customer-facing technical materials, benefits from the same automatic copyright protection as literary works, and companies should ensure that this documentation, which frequently represents years of accumulated institutional knowledge, is captured within the same ownership and assignment framework applied to source code, since it is often created by the same mix of employees and contractors and is equally exposed to the ownership gaps described earlier in this paper.

Copyright protection, while automatic and cost-free to obtain, is only as valuable as the company's ability to demonstrate, when required, that it owns the copyright in question, which in practice means maintaining clear version-controlled records of code authorship and creation dates, alongside the underlying employment and contractor assignment agreements described above. A company that owns copyright as a matter of law but cannot evidence that ownership convincingly during due diligence faces much the same practical difficulty as a company whose ownership is genuinely in question.

Training data is, for most AI companies, as commercially significant as the code that processes it, and yet its legal protection and provenance are frequently addressed with far less rigour. UK database right, a right distinct from copyright that survived the UK's departure from the EU in modified form, protects databases in which there has been substantial investment in obtaining, verifying or presenting the contents, independent of whether the individual data points within the database are themselves original or protectable. A carefully assembled, cleaned and labelled training dataset can therefore attract its own standalone protection, separate from any copyright in the individual documents, images or records it contains.

The more pressing practical question for most AI companies is not whether their dataset is protected from copying by others, but whether they themselves have the right to use, retain and commercially exploit the data in the first place. Data obtained through web scraping, through licensing arrangements with third-party data providers, through customer usage of the product itself, or through publicly available but rights-encumbered sources, each raises a distinct provenance question, and increasingly sophisticated investors and enterprise customers ask for a clear, documented answer to it as a standard part of technical due diligence.

Companies that train models using data scraped from the public internet should be aware that the underlying content is frequently protected by copyright belonging to third parties, and that the legal position on whether and when training a model on such content constitutes infringement, and whether any exception applies, is genuinely unsettled and the subject of active litigation and policy development in multiple jurisdictions, the UK included. A defensible position requires more than an assumption that publicly accessible content is free to use for any purpose; it requires a considered, documented data sourcing policy, ideally developed with specific legal input, that the company can describe coherently if challenged by a customer, regulator or claimant.

Where training data derives from customer usage of the company's own product, the company's terms of service and privacy notice must clearly and lawfully establish the company's right to use that data for model training and improvement, distinct from simply providing the contracted service, and enterprise customers increasingly negotiate specific restrictions on this point, sometimes prohibiting the use of their data to train models that will serve other customers. A company that has not thought through this question before scaling its enterprise customer base risks discovering, mid-negotiation, that its default data usage practice is commercially unacceptable to the customers it most wants to win.

A practical data provenance record, mapping each material dataset used in training to its source, the licence or legal basis under which it was obtained, and any restrictions on its use, is now a standard element of the technical due diligence pack that sophisticated investors request, and companies that maintain this record contemporaneously, as datasets are acquired, find the eventual diligence process considerably less burdensome than companies attempting to reconstruct the record retrospectively across years of accumulated data acquisition.

UK patent law permits protection for inventions, including computer-implemented inventions, provided they are new, involve an inventive step, are capable of industrial application, and are not excluded subject matter. Section 1(2) of the Patents Act 1977 specifically excludes, among other categories, a scheme, rule or method for performing a mental act or doing business, a program for a computer, and a method of presenting information, each considered as such, meaning in isolation from any wider technical contribution. This exclusion regime, together with the case law that has developed around it, means that many AI-related inventions, particularly those best characterised as a novel algorithm, model architecture or training method without a demonstrable further technical effect, face genuine difficulty clearing the patentability threshold.

The UK Intellectual Property Office and the courts have nonetheless recognised that some computer-implemented AI inventions can be patentable where the invention makes a technical contribution beyond the excluded categories, for example where an AI technique produces a genuine technical improvement in how a computer system operates, in a physical process being controlled, or in a specific technical field such as image processing, signal analysis or industrial control, rather than merely applying a known type of computation to a business or administrative problem. Assessing whether a specific invention meets this threshold is a specialist exercise requiring patent attorney input at an early stage, ideally before any public disclosure of the invention, since prior disclosure can itself destroy the novelty required for a valid patent application.

For many AI companies, the more realistic strategic conclusion is that patent protection, where obtainable at all, should be pursued selectively for genuinely distinctive, technically demonstrable innovations, such as a novel hardware-software integration, a distinctive technical method for improving model efficiency in a measurable way, or an application-specific technical process, rather than as a blanket strategy applied to every piece of proprietary technology the company develops. Patent applications are also public documents, published in due course regardless of whether the patent is ultimately granted, which means a company pursuing a patent is making a deliberate trade-off between the prospect of exclusive legal protection and the certainty of public technical disclosure.

International patent strategy adds a further layer of complexity for AI companies planning cross-border expansion, since patent rights are jurisdictional and an invention patented in the UK receives no protection in the United States, the European Union or elsewhere without separate applications in each jurisdiction, typically pursued through the Patent Cooperation Treaty route within defined priority deadlines. Companies expanding internationally should factor patent filing strategy into their expansion timeline deliberately, because missing a priority deadline in a target jurisdiction can permanently foreclose patent protection there.

Given these constraints, trade secret protection frequently does more practical protective work for AI companies than patents, particularly for model architecture, training methodology and data pipeline design that either cannot meet the patentability threshold or that the company prefers to keep confidential rather than disclose publicly through a patent application. A coherent strategy typically combines selective, well-chosen patent filings for genuinely patentable and strategically significant inventions with disciplined trade secret protection for the broader body of proprietary know-how, rather than treating the two approaches as mutually exclusive.

Almost every AI company builds on a substantial foundation of open-source software, machine learning frameworks, pre-trained model weights and open datasets, and the licences governing that foundation vary widely in the obligations they impose, from permissive licences that impose minimal conditions to copyleft licences that can, in certain circumstances, require a company to release its own derivative source code publicly if the licensed component is incorporated in particular ways. A company that has not tracked which open-source components it uses and under which licences cannot give a credible answer when an investor or acquirer's technical due diligence team asks the now-standard question of whether any copyleft obligations affect the company's ability to keep its own code proprietary.

The risk is not theoretical. Copyleft licences such as certain versions of the GNU General Public License can, depending on how a component is integrated, technically compromise a company's ability to license its own combined software as proprietary, closed-source code, an outcome that can materially affect a company's commercialisation strategy and, in an acquisition context, can require costly remediation, including rewriting affected components, before the deal can close on the terms originally contemplated. Pre-trained model weights and foundation models carry their own licence terms, which vary enormously between fully open, permissively licensed models and more restrictive licences that limit commercial use, require attribution, or prohibit certain downstream applications such as competing commercial products.

A disciplined AI company should maintain a software bill of materials, or an equivalent structured inventory, listing every material open-source component and third-party model incorporated into its product, together with the applicable licence and a brief note on any obligations or restrictions that licence imposes. This inventory should be reviewed periodically, ideally as part of the same governance cycle used for the broader intellectual property audit described later in this paper, and updated whenever a new dependency is introduced, since open-source usage tends to accumulate incrementally and can become difficult to reconstruct retrospectively once a codebase has grown substantially.

Legal review of open-source licence compliance is a specialist exercise, and companies preparing for a funding round or acquisition should expect the buyer's or investor's technical counsel to run, or request evidence of, an automated open-source licence scan against the company's codebase as a standard part of diligence. Discovering a compliance issue during this scan, rather than having identified and addressed it proactively, is a common and entirely avoidable source of last-minute deal friction.

Companies should also establish an internal policy governing the circumstances under which engineers may introduce new open-source dependencies or third-party models into the product, requiring at minimum a licence check before adoption, rather than leaving the decision entirely to individual engineering judgement made under delivery pressure. This is a modest governance investment that meaningfully reduces the risk of an accumulated, undocumented licence exposure emerging later.

Intellectual property ownership and shareholder arrangements are more closely linked than founders sometimes appreciate, particularly in the event of a founder departure on poor terms. A shareholders' agreement should address, explicitly, what happens to a departing founder's shares, but the more subtle and equally important question is what happens to the intellectual property that founder was principally responsible for creating, and whether the company's ownership of that intellectual property is genuinely secure independent of the founder's continued goodwill and cooperation.

Where the founder IP assignment described earlier in this paper has been properly executed at incorporation, a subsequent founder departure, however acrimonious, does not disturb the company's ownership of the technology, because that ownership was transferred permanently and unconditionally at the outset rather than resting on the founder's continued involvement. Where the assignment was never properly executed, or was drafted ambiguously, a departing founder retains genuine leverage, since they may be able to argue a continuing personal interest in intellectual property the company has been commercialising as if it were fully and exclusively owned.

Good and bad leaver provisions in a shareholders' agreement, which typically determine the price at which a departing founder's shares are bought back depending on the circumstances of departure, work most effectively when paired with unambiguous intellectual property ownership, because the two mechanisms address different but related risks: the good and bad leaver provisions manage the equity consequences of departure, while the intellectual property assignment manages the technology ownership consequences, and a gap in either leaves the company exposed at the precise moment relations with a departing founder have deteriorated.

Companies should also consider, as part of their broader governance framework, what access and control arrangements exist over the company's core repositories, model weights and infrastructure credentials, since a departing founder or senior engineer with continued access to production systems after a disputed exit represents an operational and security risk quite separate from the underlying legal ownership question. Immediate, systematic revocation of access on departure, applied consistently regardless of the seniority or personal relationship involved, is a governance discipline that should be established well before it is ever actually needed.

Boards and early investors should treat the review of intellectual property assignment documentation, alongside the shareholders' agreement, as a single combined exercise conducted at the time of initial investment, rather than as separate work-streams handled by different advisers at different times, because the practical protection the company enjoys depends on these two sets of documents working coherently together rather than in isolation.

Once intellectual property ownership is secure, AI companies face a distinct set of commercial decisions about how that intellectual property is licensed to customers, partners and, in some cases, competitors. The choice between a software-as-a-service model, in which the customer never receives the underlying code or model and access is granted purely through a hosted service, and a licensed-software or on-premises model, in which the customer receives and operates a copy of the software or model directly, has significant implications for how tightly the company can control its intellectual property and how exposed it is to unauthorised copying, reverse engineering or redistribution.

SaaS-delivered AI products generally offer stronger practical intellectual property protection than on-premises licensing, precisely because the customer never gains direct access to the underlying code, model weights or training methodology, and the company can enforce usage restrictions through technical controls in addition to contractual ones. This is one of the reasons the SaaS model has become the default commercialisation approach for a large proportion of AI companies, independent of the other commercial advantages, such as recurring revenue and simplified deployment, that the model offers.

Where an AI company does license its underlying model or software for on-premises or embedded use, for example to an enterprise customer with strict data residency requirements that preclude a hosted service, the licence agreement should address, with precision, the scope of permitted use, restrictions on reverse engineering, prohibitions on using the licensed technology to train a competing model, audit rights allowing the licensor to verify compliance, and clear terms governing what happens to the licensed technology on termination. Ambiguity in any of these areas is commercially tolerable while the relationship is amicable and commercially expensive the moment it is not.

Some AI companies pursue a deliberate open-source or open-weight strategy for a portion of their technology, releasing certain models or tools publicly while retaining proprietary control over a more advanced or specialised version, a strategy that can build market adoption, developer goodwill and inbound talent interest, but which requires a carefully considered licence choice for the released component and a clear internal boundary defining precisely what remains proprietary. Companies pursuing this strategy should resist releasing components under a licence more permissive than intended purely for expediency, since licence terms, once granted publicly, cannot generally be revoked retrospectively for existing users.

Cross-licensing and technology partnership arrangements, increasingly common as AI companies integrate foundation models, specialised hardware or complementary software into their products, require particular care over the allocation of intellectual property created jointly during the partnership, since a poorly drafted collaboration agreement can leave both parties with an unclear or overlapping claim to jointly developed improvements, a problem that surfaces with particular force if the partnership later ends and both parties wish to continue developing the technology independently.

How do investors verify ownership of a target company's intellectual property? The process typically begins with a structured request list covering employment and contractor agreements for every individual who has contributed to the technology, the founder IP assignment agreement, any university or previous employer disclosures relevant to the founding technology, the open-source software bill of materials, the training data provenance record, and any registered intellectual property such as patents, trademarks or design rights. This request list is now standard practice across institutional venture capital and growth equity investors evaluating AI companies specifically.

Investors' legal counsel will typically cross-reference the company's actual historical headcount and contractor engagements, drawn from payroll records, board minutes and cap table history, against the population of signed assignment and confidentiality agreements, looking specifically for gaps: individuals who contributed to the technology but for whom no assignment can be located. This exercise, sometimes described informally as chain-of-title review, is one of the more time-consuming elements of AI-focused technical and legal due diligence, precisely because early-stage companies frequently have incomplete records covering their earliest and most technically formative period.

Beyond the paperwork review, sophisticated investors increasingly conduct a substantive technical diligence exercise addressing training data provenance directly, asking the company to describe, and in some cases evidence, exactly where its training data came from, under what legal basis it is used, and whether any of that data derives from sources, such as scraped web content or a previous employer's proprietary datasets, that could expose the company to a future infringement or misappropriation claim. A company able to answer these questions confidently and with documentary support is treated materially differently from a company that has clearly never considered the question before being asked.

Investors also probe for dependency risk: whether the company's technology relies on a single founder's undocumented knowledge that has never been captured in code, documentation or a transferable form, since this represents a form of key-person risk closely related to, but distinct from, formal intellectual property ownership. A model or system that only one person genuinely understands, however well the underlying ownership is documented, is itself a diligence concern, because its value depends on that person's continued availability and goodwill.

Companies preparing for a funding round or acquisition process should conduct this same exercise on themselves in advance, engaging intellectual property counsel to run a structured internal audit and remediate any gaps identified, well before external diligence begins. This is materially less expensive, both financially and in terms of negotiating leverage, than discovering the same gaps for the first time when a buyer's or investor's lawyer raises them during exclusivity, at which point the company has comparatively little room to negotiate the terms of remediation.

AI companies expanding internationally, whether by establishing a UK entity as the parent for a global structure, opening a subsidiary in the United States, Germany, Singapore or France, or migrating founding intellectual property from an overseas jurisdiction into a UK holding structure, must address intellectual property ownership as a discrete workstream within that broader expansion plan, rather than assuming that ownership questions resolved for one jurisdiction automatically translate to another. Default ownership rules for employee and contractor-created work vary between jurisdictions, and a rule that operates reliably in the UK cannot be assumed to produce the same outcome for a team member employed in a different country.

Where a group intends to consolidate intellectual property ownership within a single entity, typically the ultimate holding company or a specific intellectual property holding subsidiary, for reasons of tax efficiency, investor clarity or licensing simplicity, that consolidation requires a formal intra-group assignment or licence, properly valued and documented, and in many cases with specific tax advice on transfer pricing implications, since moving valuable intellectual property between group entities, particularly across borders, can trigger tax consequences in the transferring jurisdiction that are entirely separate from the corporate law question of ownership.

Companies expanding into the United States should be aware that federal and state law addressing employee invention assignment and, in states such as California, restrictions on the enforceability of certain assignment clauses relating to inventions developed entirely outside working hours using no employer resources, differ meaningfully from the UK position, and US employment and contractor agreements should be drafted by counsel familiar with the relevant state law rather than adapted informally from a UK template. Similarly, expansion into Germany engages specific statutory provisions governing employee inventions, including inventor compensation obligations that have no direct UK equivalent and that materially affect how AI companies should structure employment terms for research and development staff based there.

Expansion into Singapore, often used as a regional hub for AI companies targeting the broader Asia-Pacific market, and into France, frequently a gateway for European Union market access, each carry their own variations on employee and contractor IP default rules, data protection requirements affecting training data sourced from local users, and in France specific statutory protections for employee inventors broadly analogous to, though not identical to, the German regime. Companies should resist the temptation to treat international IP documentation as a simple translation exercise from a UK template and should instead obtain local counsel input for each material jurisdiction in which technical contributors are based.

A well-structured international expansion plan for an AI company should therefore map, jurisdiction by jurisdiction, where technical contributors are or will be based, what local law says about default ownership of their work, and what specific local-law-compliant assignment and confidentiality documentation is required to ensure that, regardless of where a given piece of the company's technology was created, it ultimately and unambiguously belongs to the intended group entity.

Intellectual property protection for an AI company is not achieved through legal documentation alone; it depends materially on the technical and organisational controls that prevent unauthorised access to, or exfiltration of, the underlying model weights, training data and source code. A comprehensive AI governance framework, addressing who may access production model artefacts, how training data is stored and segmented, and what controls exist over the deployment pipeline, functions as a practical extension of the company's trade secret protection, since a trade secret that is not genuinely restricted in access is, by definition, at risk of losing the legal protection that depends on it remaining secret.

Cybersecurity failures represent one of the most direct routes by which an AI company's core intellectual property can be lost entirely, whether through a breach that exposes source code and model weights to a competitor, an insider incident involving a departing employee copying proprietary material before leaving, or a supply-chain compromise affecting a third-party tool with access to the company's development environment. Board-level oversight of information security, including a clear incident response plan naming an accountable individual, should be treated as inseparable from the company's broader intellectual property strategy rather than as a purely technical operational matter delegated entirely to the engineering function.

Access control discipline deserves particular attention for AI companies because the artefacts most worth protecting, trained model weights and curated training datasets, are frequently large, easily transferable files that can be copied in their entirety by anyone with sufficient system access, in a way that is qualitatively different from copying a smaller, more easily monitored source code repository. Segmenting access so that only personnel with a genuine operational need can retrieve full model artefacts, logging and monitoring that access, and revoking it immediately on role change or departure are practical measures that materially reduce this risk.

Companies should also give thought to the intellectual property implications of their own AI governance policies as customer-facing assurance material. Enterprise customers and public-sector buyers increasingly ask AI vendors to describe their internal model governance, including how training data is sourced and how proprietary information is protected against leakage through model outputs, and a company that can answer these questions with a genuine, board-approved governance policy demonstrates the same institutional discipline that underpins its intellectual property protection more broadly.

AI compliance, in this sense, extends well beyond regulatory obligation and functions as a direct commercial asset: a company with demonstrable governance and cybersecurity discipline is better positioned to protect its intellectual property, more credible to enterprise buyers and investors, and less exposed to the catastrophic loss of competitive advantage that a serious security incident involving core model or data assets would represent.

The single most common mistake observed among early-stage UK AI companies is delay: founders correctly identify that intellectual property assignment and confidentiality documentation matter, but treat the task as one that can be addressed later, once the company has more resources or once a funding round makes it unavoidable. In practice, the population of people who have contributed to the company's technology only grows over time, and the difficulty and cost of obtaining a clean, retrospective assignment from a contractor who has since become uncooperative, or from a founder who has since fallen out with the rest of the team, grows correspondingly.

A second recurring mistake is treating intellectual property documentation as a generic legal formality rather than a technically informed exercise specific to the company's actual architecture and data sources. Template agreements adapted casually from a generic source, without specific attention to how the company's model is actually trained, what data it actually uses, and which third-party components it actually incorporates, frequently fail to address the precise questions a future investor or acquirer will ask, leaving the company with documentation that exists but does not actually answer the questions it needs to answer.

A third mistake is underestimating the significance of open-source licence compliance, on the assumption that because a component is free to use, it carries no meaningful legal obligation. As discussed earlier in this paper, certain open-source licences carry conditions that can affect a company's ability to keep its own code proprietary, and a company that has never conducted a structured review of its dependencies is exposed to a risk it has simply never measured.

A fourth mistake, increasingly significant as AI-specific scrutiny intensifies, is failing to document training data provenance contemporaneously, resulting in a company that, several years and several datasets later, genuinely cannot reconstruct where a meaningful proportion of its training data originated or under what legal basis it was obtained. This gap is disproportionately expensive to close retrospectively and disproportionately damaging to discover during a live due diligence process.

A fifth mistake is neglecting the intellectual property implications of international expansion, assuming that agreements and practices that work well in the UK translate automatically to team members or entities established in other jurisdictions. As international teams grow, this assumption becomes an accumulating source of risk that is best addressed proactively, jurisdiction by jurisdiction, as each new location is established, rather than retrospectively once the company has already scaled its international footprint.

Experienced technology transaction advisers and investors tend to read an AI company's intellectual property file in a particular order, and understanding that order helps founders anticipate what will actually be scrutinised rather than over-investing in areas that matter less. The first thing reviewed is almost always the founder cap table cross-referenced against the founder IP assignment agreement, because a gap here calls into question the company's ownership of its most foundational technology and tends to colour the reviewer's approach to everything that follows.

The second area of focus is typically the completeness of the employee and contractor assignment chain relative to the company's actual historical headcount, established by comparing signed agreements against payroll records, board minutes referencing new hires, and invoices from contractors and agencies. Reviewers are specifically looking for individuals who clearly contributed to the technology, evidenced perhaps by commit history or product changelogs, but for whom no corresponding assignment can be located.

The third area, and increasingly the one that receives the most substantive technical attention for AI companies specifically, is training data provenance. Sophisticated reviewers ask pointed, specific questions: where did this dataset come from, who obtained it, under what licence or legal basis, has it been used in a way consistent with that basis, and would the company be comfortable if a journalist, regulator or claimant asked the same question publicly. A hesitant or evasive answer here is treated as a significant negative signal, often more significant than a gap in the paperwork trail, because it suggests the company has not seriously engaged with a risk that regulators and courts are increasingly focused on.

The fourth area is open-source licence compliance, typically verified through an automated scan of the codebase cross-referenced against a licence compatibility matrix, looking specifically for copyleft components that could compromise the company's ability to license its own software as proprietary. The fifth and final area is registered intellectual property, patents, trademarks and any registered designs, reviewed less for their existence as a checkbox and more for whether the company's claimed protection genuinely covers what it says it covers.

The consistent theme across each of these areas is that experienced reviewers are not looking for perfection; they are looking for evidence of a company that has taken the question seriously, addressed it proactively, and can answer follow-up questions coherently and with documentary support. A company with a smaller number of genuinely well-documented protections is generally viewed more favourably than a company with an impressive-sounding but poorly evidenced intellectual property narrative.

A periodic, structured intellectual property audit, ideally conducted annually and refreshed before any material fundraising, partnership or acquisition process, is the most effective single practice a UK AI company can adopt to maintain investor and enterprise readiness. The audit should be led or reviewed by intellectual property counsel rather than conducted purely as an internal administrative exercise, since the value of the audit lies substantially in an independent, legally informed assessment of whether the company's documentation would actually withstand external scrutiny.

The audit should begin with a comprehensive inventory of the company's intellectual property assets: source code repositories, trained models, training datasets, documentation, registered trademarks and patents, and brand assets, mapped against the specific legal protection regime applicable to each. This inventory forms the baseline against which the remaining audit steps, focused on verifying ownership and identifying gaps, are conducted.

The ownership verification stage cross-references the company's full historical headcount and contractor engagement history against the population of signed assignment and confidentiality agreements, flagging any individual who contributed to the company's technology without a corresponding written assignment on file. Any gaps identified should be remediated as a priority, recognising that remediation becomes progressively harder to achieve on favourable terms as time passes and relationships with departed contributors cool.

The audit should also review training data provenance against the record described earlier in this paper, confirm that open-source and third-party model licence obligations have been tracked and assessed for compatibility with the company's commercialisation model, and verify that confidentiality and access control practices around core model artefacts meet the standard required to sustain trade secret protection. Finally, the audit should confirm that international contributors and entities are covered by jurisdiction-appropriate documentation rather than UK templates applied without local adaptation.

The output of the audit should be a short executive summary identifying material gaps, a prioritised remediation plan with named owners and target dates, and a refreshed intellectual property asset register suitable for immediate presentation to an investor, acquirer or enterprise customer's due diligence team. Boards should treat this audit as a standing governance item, reviewed at least annually, rather than a one-off exercise commissioned only when a transaction is already imminent.

For a founding team building an AI company from the ground up, intellectual property strategy should follow a sequence that mirrors the company's own growth, rather than being addressed all at once or deferred entirely. At incorporation, the immediate priorities are the founder IP assignment agreement, addressing any prior employer or university obligations, and putting in place employment and contractor templates that include express assignment and confidentiality clauses from the very first hire, so that the ownership chain never has a gap to begin with.

As the company builds its first working product, priorities shift to establishing a training data provenance discipline from the outset, rather than retrofitting one later, and to introducing a lightweight open-source dependency review process before the codebase accumulates untracked third-party components. This is also the stage at which the company should begin thinking, even briefly, about which elements of its technology might eventually warrant patent protection, since early public disclosure, including through published research or conference presentations, can foreclose that option permanently if not carefully managed.

As the company approaches its first institutional fundraising round, the priority becomes conducting the executive intellectual property audit described above, proactively identifying and remediating gaps before external legal due diligence begins, and preparing the documentation pack that investors will expect to see, framed around the same categories a due diligence team will actually request. Companies that complete this work before entering a fundraising process typically experience a materially smoother and faster diligence phase than companies that begin addressing these questions only once a term sheet is on the table.

As the company scales internationally and pursues enterprise or public-sector customers, the priority shifts to jurisdiction-specific documentation for international team members and entities, a mature AI governance and cybersecurity framework protecting core model and data assets, and a deliberate licensing and commercialisation strategy suited to the customer base being pursued. At each of these stages, the underlying discipline is the same: identify what intellectual property the company actually depends on, confirm who owns it and under what protection, and close any gap before an external counterparty finds it first.