No G 2/26 Record Yet: Where EPO AI Patentability Actually Stands
As of 25 August 2026, the European Patent Office’s public list of pending referrals to the Enlarged Board of Appeal does not contain a case numbered G 2/26. The currently verifiable 2026 referral is G 1/26, concerning claim interpretation in the “Coated steel strips” case, and the Boards of Appeal communications page does not show an official 20 August notice addressing the patentability of AI-generated code, algorithmic architectures or data pipelines. Any claim that G 2/26 has already signalled an EBA position on such issues therefore lacks support in the EPO’s public record at this stage.
The underlying legal question, however, is real and increasingly important. The EPO Guidelines for Examination 2026 continue to treat artificial intelligence and machine-learning models, taken in isolation, as mathematical methods, while allowing patentability where claimed features contribute to a technical solution to a technical problem or are adapted to a specific technical implementation. Decision T 0528/25 of 5 February 2026 also confirmed that the patentability provisions of Article 52 EPC and following do not exclude inventions merely because they were generated by, or mainly with the assistance of, AI. The practical task is to separate inventorship from patentability and to identify the technical contribution with precision.
G 2/26 should be treated as unverified, not as settled EPO news
For applicants and counsel, the main risk is not missing a headline. It is allowing an unverified case number or an alleged “preliminary view” to shape claim strategy, client advice or internal investment decisions. When a question is formally referred to the Enlarged Board of Appeal, the EPO normally identifies the case on its pending-referrals page and links the referring decision and later procedural material. The public record currently identifies G 1/26 as a 2026 referral; it does not show a G 2/26 entry dealing with AI-generated software or data structures.
That may change if a new referral is filed or published later. What cannot responsibly be done today is to present an alleged 20 August procedural direction, or a supposed EBA preference for a “direct synergistic effect” with hardware, as an established legal development without an official source. Companies preparing European filings should therefore use the published Guidelines and existing Boards of Appeal case law as the operative baseline and monitor future EBA referrals separately.
AI generation does not by itself defeat patentability
T 0528/25 is particularly useful because it separates two issues that are often collapsed into one. The decision maintains the EPO position that an inventor designated under the EPC must be a natural person with legal capacity; an AI system itself cannot be named as inventor. At the same time, the Board stated that the patentability provisions under Article 52 EPC and following do not exclude an invention simply because it was generated by AI or produced mainly with AI assistance. Inventive step still turns on whether the claimed subject matter would have been obvious to the skilled person over the prior art.
The absence of direct human engineering at every generation step is therefore not an independent patentability bar. It is more likely to matter first for inventorship, entitlement and evidentiary consistency. Businesses using large language models, generative design systems, automated optimisation or search tools should retain records showing who framed the technical objective, selected constraints, assessed outputs, validated candidates and decided which solution to adopt. Those records help establish a credible chain of human contribution without pretending that AI played no substantive role.
The real boundary for code and data structures is technical contribution
The 2026 EPO Guidelines set out a more nuanced test than a rule requiring every software invention to be tied directly to physical hardware. AI and machine-learning models are abstract mathematical methods when considered on their own, but their features can contribute to technical character where they serve a technical purpose or are adapted to a specific technical implementation. Computer programs may also qualify where, when executed, they produce a further technical effect going beyond the normal physical interactions between software and a general-purpose computer.
Data structures are assessed along a similar line. The Guidelines distinguish functional data from cognitive data. A data structure or format may contribute technically where it has a predetermined technical use and produces a technical effect in that use—for example by representing technical properties of a device, controlling device operation or encoding instructions for manufacturing equipment. By contrast, a structure whose value lies only in information meaning, business classification or human-facing semantics will usually not become technical merely because its organisation is efficient.
This distinction is crucial for AI-generated data pipelines. Claims that a pipeline achieves higher throughput, cleaner ordering, faster convergence or more efficient processing are not enough by themselves. The case becomes stronger where the improvement is tied to concrete computational constraints such as GPU/CPU task allocation, memory hierarchy, caching, network transfer, parallel execution, storage architecture, latency or energy use. Purely abstract algorithmic efficiency without a technical purpose or specific technical implementation remains vulnerable.
Draft the technical causal chain, not just the AI label
For AI software, compute-optimisation and data-infrastructure companies, the practical response is not to add generic words such as “processor”, “server” or “AI model” to the claims. The application should articulate a technical causal chain: what technical problem is being solved; which inputs carry technical meaning; what computation, communication, storage, control or device behaviour is changed; how that change produces a measurable technical effect; and whether the effect is plausibly achieved across the scope of the claim.
Where the inventive point lies in compute architecture, the description should identify relevant implementation constraints—thread scheduling, memory access, GPU/CPU allocation, model compression, network transmission, cache behaviour, latency, power consumption or similar parameters—and explain how the claimed algorithm interacts with them. Where the invention lies in a data structure, the filing should explain why particular fields, relationships or encodings serve a technical system rather than merely organising information. If a technical effect depends on particular characteristics of training data, the application should disclose those characteristics sufficiently to reproduce the effect without assuming that the entire training corpus must necessarily be disclosed.
Inventorship records should also connect with patent drafting. AI may generate code, propose architectures and rank candidate solutions, but internal records should still capture who defined the technical objective, chose constraints, evaluated candidates, ran validation and adopted the final solution. The current EPO line is not that “AI cannot invent”. The more defensible conclusion is narrower: applicants need a compliant natural-person inventorship designation and a claim that can be defended as a concrete technical solution rather than an abstract algorithm or data organisation scheme.
