Patent Protection for Artificial Intelligence

Yes. Both the European Patent Convention and Polish industrial property law exclude from patenting only mathematical methods and computer programs "as such" – and a machine learning algorithm considered in isolation from any application is classified precisely as a mathematical method. What is patentable are computer-implemented inventions in which the algorithm serves a specific technical purpose – for example, noise reduction in medical imaging, control of an industrial process, or data compression – or has a specific technical implementation tailored to the hardware architecture. The European Patent Office (EPO) grants such patents regularly and its case law in this area is well settled; the Polish Patent Office (UPRP) grants protection for such solutions much less often. So the right question is not "is this AI?" but "what technical problem does the system solve, and by what mechanism?"

The European Patent Office (EPO) assesses this under an established methodology: when examining inventive step, it considers only the features that make a technical contribution, while the mathematical model itself enters the analysis merely as a boundary constraint. A technical contribution can be shown in two ways. The first is a technical application: the algorithm processes physical quantities or acts on a device – sensor data as input, a control signal as output, a measurable improvement in process parameters. The second is a specific technical implementation motivated by the internal workings of the computer – lower memory consumption, reduced latency, better use of bandwidth or computing resources. One important caveat: the technical effect must go beyond merely running calculations on a computer and must be credible across the entire scope of the patent claim.

Copyright protects source code automatically, with no formalities and for a long time – but only against copying of that specific code, not against recreating its functionality. A competitor who implements the same mechanism in their own code does not infringe copyright. A patent protects the technical solution regardless of how it is implemented – even against someone who developed it independently – but it requires filing an application, disclosing the essence of the solution, meeting the patentability requirements, and bearing the costs. With AI there is an added complication: the copyright status of model weights is debatable, because parameters produced by a training process are hard to classify as a creative work within the meaning of copyright law. For the model itself, the realistic alternative to a patent is therefore a trade secret rather than copyright. In practice, these regimes complement one another: copyright protects the code, a patent the mechanism, and secrecy the weights and training data.

No – that question has already been settled. In the cases concerning DABUS, a system put forward as an "AI inventor," courts and patent offices in the US, at the EPO, in the UK, and in other jurisdictions consistently ruled that only a natural person can be the inventor. The practically important question is the follow-on one: who is the inventor when AI played a substantial part in arriving at the solution. The accepted view is that a human must make a significant contribution to the conception of the invention – simply running a tool and accepting its output is not enough. When working with generative systems, it therefore pays to document the human contribution: defining the problem, selecting and evaluating the candidates the system generates, modifying and verifying them. An invention created with the help of AI is patentable in the normal way; an invention with no identifiable human contribution may be left without protection.

The application must disclose the invention clearly and completely enough for a person skilled in the art to reproduce it without any further creative effort. For an AI system, that means in practice: the model architecture and data flow, the characteristics of the training data (its type and how it was obtained and prepared – usually not the data itself, but information that makes the training reproducible), the training procedure with the parameters that matter for the result, and at least one complete working example. The second pillar is measurable evidence of the technical effect: comparative results against the prior art (latency, memory consumption, accuracy), because the model's performance is examined both for inventive step and for sufficiency of disclosure. Before filing, decide deliberately which elements are to remain trade secrets – withholding information needed to reproduce the solution risks invalidation of the patent, so the line between patent and secrecy is drawn between system components, not inside a single claim.

The difficulty is that the system keeps changing in operation, so a momentary snapshot of its weights makes a poor subject of protection. The strategy therefore focuses on what stays constant: the architecture, the training method, and the update mechanism – the learning loop itself (how the feedback signal is collected, the criteria and procedure for fine-tuning) is often the most valuable part of the invention. Claims drafted this way cover every instance of the system obtained by the protected method, however it has evolved after deployment. The current state of the model – the weights, the data, the update log – is protected as a trade secret. The application should describe the learning mechanism in enough detail to reproduce it, while the decision whether to patent should factor in the detectability of infringement: when the model runs only behind an API on the operator's servers, enforcing a patent can be difficult and secrecy may give better protection in practice.

There is no automatic bar – but there are three distinct risks. First: publishing your own code (for example, in a public repository) before filing is a public disclosure and, in Europe, irreversibly destroys the novelty of the solution; the rule is "file first, disclose later." Second: using third-party open-source components does not prevent you from patenting your own invention, because a patent protects the technical solution while OSS licenses govern the code – but some licenses contain patent clauses: Apache 2.0 grants a patent license and terminates it for anyone who brings a patent lawsuit (so-called patent retaliation), and GPLv3 has a similar mechanism. Third: copyleft licenses (GPL) can force you to release your product's code, which undermines trade secret protection, though not the patent itself. The practical takeaway: audit the licenses of your dependencies and keep the filing-before-publication discipline.

Start by separating the system from its outputs – they are often two different objects of protection. Four factors drive the decision. First, how easily the mechanism can be reconstructed: if it can be reverse-engineered from the product's behavior, secrecy is illusory, which argues for a patent. Second, detectability of infringement: a patent whose infringement you cannot establish (a model accessible only via an API) has limited enforcement value. Third, the pace of competition: a trade secret does not protect you against independent development of the same solution – a patent does. Fourth, the patentability of the system's outputs themselves. A typical hybrid strategy for generative AI: the method or architecture – a patent or secrecy, depending on detectability; the weights and training data – a trade secret; valuable outputs of the system (such as chemical compound structures) – separate product patents. Make the decision early and deliberately: publication of a patent application irreversibly destroys secrecy for everything it discloses.

The goal is the same; the procedures differ somewhat. The EPO applies a stable, predictable methodology: it requires a technical effect that goes beyond implementation on a computer, and the assessment follows a repeatable path; the price is rigorous requirements on disclosure and on the effect holding across the entire scope of the claim. The US applies the Alice/Mayo test (the exclusion of "abstract ideas"), which is less predictable in application and more exposed to shifts in case law – the current line (including the 2025 Recentive decision) holds that applying conventional machine learning techniques to a new field of data is not eligible for protection, while applications that demonstrate an improvement in the technology itself hold up. One procedural difference matters greatly: the US offers a 12-month grace period after your own disclosure; Europe offers none. For companies planning both markets, the conclusion is simple – the application must be drafted from the start to meet the requirements of both systems.

Yes – and it pays to plan for the interplay. From August 2026, high-risk AI systems are subject to the obligations of the AI Act, including the duty to maintain detailed technical documentation covering algorithms, data, and test protocols. There is one critical point of contact with patent law: Europe applies absolute novelty, so any information that reaches the public domain through the compliance process before your filing date can destroy the patentability of the solution. Our recommendation: synchronize your patent filing schedule with your compliance schedule – file before the regulatory documentation is drawn up and shared. Documentation submitted to supervisory authorities is not public as a rule, and the regulation obliges the authorities to protect its confidentiality; still, the growing number of parties with access to a description of your system increases the risk to trade secrets. For systems whose key protection is secrecy, it is worth deciding in advance what goes into the mandatory documentation, and at what level of detail.