Who Owns Code Built by Offshore AI Developers? UK & EU Guide

Paying for offshore AI development does not necessarily give your business copyright in the code. Under UK rules, an employer normally owns work created by an employee in the course of employment, subject to contrary agreement. Commissioned work normally belongs to its creator unless ownership is agreed otherwise in writing. The UK Intellectual Property Office distinguishes commissioning work from owning its copyright. For a Philippine staffing arrangement, check how rights reach the legal employer and then your company. Keep evidence of that ownership chain alongside client-controlled repositories and accounts.

Ownership depends on the hiring model

Putting code in your GitHub organisation gives you practical possession, but it does not repair a defective copyright assignment. Conversely, a sound assignment is less useful operationally if the supplier controls the only repository, deployment keys or cloud account. Employers need both legal rights and practical control.

For UK contractor engagements, review tax status separately. HMRC's off-payroll guidance distinguishes labour supply from genuinely contracted-out services and warns against relabelling contracts. Determine whether the rules apply to the actual arrangement; a tax-status conclusion does not replace your IP review.

How Borderless Recruit helps

Borderless Recruit sources and vets dedicated, full-time Philippine AI developers, handles local employment contracts, payroll and HR, and charges a flat monthly client fee. The standard AI Developer price starts from £1,330 / €1,540 per month ($1,750). The developer works only for you during your UK or European business hours, on a Philippine shift aligned with those hours. The Philippines does not observe daylight saving, so agree how the shift follows seasonal clock changes. Have your adviser check the proposed IP terms before signing.

How Philippine law affects the ownership chain

The Philippine Intellectual Property Code protects computer programs. For employee-created work, copyright generally belongs to the employer when the work results from regularly assigned duties, unless agreed otherwise. Work outside those duties can belong to the employee even when employer resources were used. For commissioned work, ownership of the delivered work and copyright are distinct: copyright remains with the creator unless a written stipulation provides otherwise.

For a staffing arrangement, ask how the employment terms cover software, documentation and AI assets, then check the provider's transfer to your company. Do not assume that every contribution needs a fresh developer assignment if the employer already owns it by law; ask your adviser to establish and document the correct route. European employers should also check the customer contract's governing law and mandatory local rules rather than treating the UK position as universal.

What the written assignment should cover

A clause saying that the client owns the code can leave gaps. Give your adviser an inventory of the expected work product and ask them to distinguish newly created material from existing tools and third-party components. Use the following as a drafting brief, with wording adapted to the governing law.

• Define deliverables: source code, tests, deployment scripts, infrastructure configuration, database schemas, technical documentation and workflow exports.
• Include client-specific prompts, agent instructions, retrieval pipelines, evaluation suites, guardrails and model configuration, covering whatever transferable rights exist.
• Identify datasets, annotations and model artefacts separately, with permitted uses and delivery obligations rather than an indiscriminate promise to own all data.
• Specify the rights transferred, when transfer takes effect and any payment conditions. Address existing work, future work and further signatures where needed.
• List pre-existing material and secure a licence that supports operation, modification, maintenance and any intended onward transfer of the system.
• Address confidentiality, lawful treatment of moral rights, authorised subcontracting and assistance with confirming ownership later.
• Require disclosure of material belonging to former employers or other clients, and a process for replacing contributions the supplier cannot authorise.

Assignment, licence and NDA serve different purposes

An assignment transfers specified rights. A licence grants permission to use material while ownership remains elsewhere. An NDA addresses confidentiality; it does not transfer copyright. A project may need each: ownership of custom code, a continuing licence to an approved utility library and confidentiality protection for business information. Check that rights and licences needed to maintain the system continue after the staffing engagement ends.

Treat AI artefacts as a defined asset register

AI development creates valuable material outside conventional source files. Identify these assets even where their copyright status is uncertain. Keep ownership, permission to use and practical access in separate columns: a supplier cannot transfer rights it does not hold, and a contract cannot make a provider-controlled model exportable.

Do not assume that provider terms allocating output to a customer settle copyright protection or exclusivity in every jurisdiction. Require approved coding assistants and organisation-managed accounts, review terms before submitting confidential material, and record material AI assistance. Human review supports accountability but should not be presented as proof of copyright ownership. The guide to vibe coding versus traditional development provides context for choosing an engineering approach.

Control open-source and third-party dependencies

Plan for approved dependencies rather than assuming the finished system contains only client-owned material. Require a register recording each component's version, source, licence, purpose and modifications. Have the relevant terms reviewed for your intended use, including distribution, hosted services and later sale of the business. Review model APIs, coding assistants and commercial software development kits as well as code libraries.

• Reject copied snippets whose origin or permission to use cannot be established.
• Use dependency and secret scanning, supported by human review of licence obligations and unresolved findings.
• Separate custom code from reusable supplier tools and document the licence for each approved exception.
• Require written approval before publishing project material as an open-source contribution or portfolio example.

Protect personal data accessed from the Philippines

Code ownership does not resolve data protection. Overseas access to personal data can engage international-transfer requirements. For UK work, establish who accesses the data, their relationship to your organisation and whether the arrangement is a restricted transfer. Where required, document an appropriate transfer mechanism and assessment using the ICO's international-transfer guidance. For EU work, assess the corresponding framework described by the European Commission.

Before granting access, agree processing instructions, approved subprocessors, incident reporting, retention and deletion. Prefer synthetic or appropriately de-identified data for development; masking alone should not be assumed to remove data-protection obligations. Use named accounts, least-privilege permissions, multi-factor authentication and access logs. Keep secrets in a managed vault, and check whether approved AI tools send code, prompts or logs to additional providers.

Set up client control before development begins

Assign an internal owner to each account and register. Ask an authorised colleague to locate the latest release, identify its dependencies and follow the recovery instructions. If they need the developer's personal account to proceed, the handover is incomplete even if the code is already in your repository.

A hiring test for ownership and maintainability

Use a fresh fictional brief rather than asking candidates to disclose another employer's code. The following is an illustrative assessment: build a small internal policy assistant using supplied fictional documents. It should cite its source material, decline unsupported answers and handle a failed model request. Agree payment and permitted use of the submission before the assessment.

• Ask for source code, setup instructions, a dependency and licence register, prompt files, test results and disclosure of AI tools used.
• Include a fictional confidential document that the brief explicitly excludes from external AI services. Check whether the candidate spots and respects that restriction.
• Ask the candidate to identify anything they brought from an existing library or personal project and explain the proposed permission to use it.
• Have another engineer attempt setup from the written instructions using fresh credentials. Record missing files, account dependencies and undocumented steps.
• Discuss an untraceable code snippet: the candidate should investigate, replace or remove it rather than assume working code is acceptable.

Judge the submission on traceability, safe handling of the brief and reproducibility as well as functionality. A convincing demo with missing dependencies or undisclosed borrowed material should not pass the ownership review. Combine this exercise with the broader offshore AI developer vetting checks.

Offboarding without losing code, knowledge or access

Make handover a continuing obligation. Before departure, preserve outstanding branches, collect current asset and dependency registers, and verify documentation against the deployed system. Confirm that client administrators can access essential resources before revoking the departing developer's access. Rotate credentials they could access and remove source-control, cloud, model-provider and communications permissions.

Obtain confirmation of the return or authorised deletion of confidential information, with documented exceptions for legal retention. Keep signed agreements, contributor records, licences, AI-tool approvals and data-transfer documentation together. These records should let a future maintainer or reviewer understand both how the system runs and which rights your company holds.