AI-generated code and Cyprus IP Box eligibility

AI assistance and an AI-generated asset are different facts

A developer may use an AI tool to suggest a function, explain an error or generate a draft, then design, revise and integrate the resulting software. Another business may rely almost entirely on generated output with little identifiable human authorship. Those cases should not be collapsed into a blanket statement that all AI-produced code is copyrighted software.

Directive 2009/24/EC protects original computer-program expression and distinguishes it from underlying ideas and principles. Its authorship and originality framework is relevant when examining AI-assisted work. It does not supply an automatic tax approval for every model output.

Start with the asset actually exploited by the company. An application can contain human-authored code, generated suggestions, third-party libraries, model access and datasets. Map those layers and the rights in each before drawing a conclusion about the qualifying software.

Commercial-use terms do not answer every copyright question

Review the tool provider’s current terms for the service and account used. Permissions, contractual allocation of rights and restrictions can matter to the business. They should not be mistaken for a legal determination that copyright exists in every output under the law relevant to the claim.

Also consider whether generated material reproduces or incorporates third-party code and whether dependencies have their own licence terms. A statement that the company may use an output commercially does not remove the need to review material rights issues in the product.

This article does not claim that a particular percentage of human edits guarantees protection. The analysis is fact-sensitive. Where eligibility depends on uncertain rights in a material asset, obtain advice on that asset rather than using a universal AI eligibility label.

Record the development process in a useful way

Preserve evidence of human design and development decisions, material revisions, integration and testing. Repository history, design records and project documentation may help explain how the software was created. The purpose is to describe actual work, not to generate a ceremonial record after the fact.

Do not collect or publish confidential prompts, customer data or personal information unnecessarily. Evidence can often be organised through project references, decision records and controlled internal documentation. Keep the record proportionate to the ownership and expenditure questions.

Distinguish a company’s own software from the external model it calls. Paying for access to a third-party AI API does not mean the company owns the provider’s model or weights. The company may have a separate original application, but that application needs its own asset and income analysis.

• Identify the software asset and material components.
• Document human design, development and revision work.
• Keep relevant tool terms and licence information.
• Track third-party dependencies and rights exceptions.
• Link supported development expenditure to the asset.
• Review uncertain copyright or ownership issues explicitly.

AI expenditure is not automatically qualifying R&D

A subscription to a coding assistant can support development, training, routine support and other activities. Compute expenditure can support experiments or live customer inference. Classify the use and connection with the asset rather than treating every AI-related bill as QE.

Likewise, a valuable output does not establish a particular amount of expenditure. Do not assign an invented development cost based on how many engineer hours the tool may have saved. The nexus schedule concerns relevant expenditure actually incurred under the applicable rules.

Where activities are mixed, document a supported allocation. Keep the annual net-income calculation separate from the nexus expenditure history so production costs and development costs are not conflated.

Review what customers are paying for

An AI service may charge for original application functionality, pass-through model access, consulting or a mixture. The presence of generated code in the platform does not establish that all customer receipts are qualifying IP income.

Review contracts and how the product creates value. Where the software contribution is embedded in a wider service, identify a defensible income allocation and relevant costs. Do not adopt a standard qualifying percentage simply because other AI companies advertise one.

Only after the asset, rights, income and expenditure have been established should the nexus and deduction calculation be applied. Approximately 3% is a full-nexus corporate illustration, not a certification attached to the words “AI software”.

Use changes in tooling as review points

Tool terms, development practices and product architecture can change. Retain the versions relevant to material work and review new dependencies or delivery models. A conclusion based on an earlier workflow may not describe a later product built differently.

Where an issue remains unresolved, state the uncertainty in the internal assessment. A credible claim distinguishes established facts from legal questions that still need analysis; it does not turn uncertainty into an unconditional marketing promise.