Copyright law deals with familiar acts such as copying, storing and reproducing a protected work. Large Language Models, however, involve technically distinct processes. Each stage from training to the generation of an output serves a different technical function. Notably, training is not the same as retrieval; storing training data is not the same as learning through model parameters; and memorisation is not the same as ordinary generation. When Parliament enacted the Copyright Act, 1957, it could hardly have been imagined that courts would one day be required to draw such distinctions in applying copyright law to AI systems.

The Delhi High Court, however, had the occasion to encounter these questions in ANI Media Pvt. Ltd. v. OpenAI OpCo LLC 2026 SCC OnLine Del 5291. While considering ANI's application for interim injunction, the Court examined not only copyright law but also the functioning of Large Language Models (LLMs). Significantly, the judgment discusses training data, tokenisation, embeddings, model training and Retrieval-Augmented Generation (RAG), concepts that subsequently inform its consideration of storage, memorisation and reproduction.

How ANI v. OpenAI Explains an LLM

The Court considered an understanding of the functioning of LLMs necessary for deciding the issues before it. Based on the submissions of the parties, the Amici Curiae and what it described as common general knowledge, the Court set out the working of an LLM through different stages.

The judgment begins with training data. It describes an LLM as a computational system that predicts the next word from the words preceding it. For making such predictions, the model is trained on an enormous corpus of text, which may include publicly available material scraped from the internet as well as licensed material. The collected data is thereafter filtered for quality and safety.

The judgment then explains data preparation and model training. The raw text is divided into smaller units called tokens, with each token being assigned a numerical Token ID. These tokens are then represented numerically through embeddings. According to the judgment, during training, words or sequences of words are masked and the model is made to predict the next words or sentences. Its predictions are compared with the original text and progressively refined.

The Court separately deals with post-training and user interaction. It explains that the model is further trained to follow instructions and provide useful responses. When a user subsequently provides a prompt, the model generates its response by iteratively producing tokens conditioned on that prompt.

Finally, the judgment explains Retrieval-Augmented Generation (RAG) as a mechanism through which an LLM can refer to a knowledge source outside its training data before generating a response. According to the Court, an information-retrieval component uses the user's prompt to obtain information from an external data source, which is then used along with the model's trained knowledge to generate the response.This account provides the technical foundation for parts of the Court's subsequent analysis. It is therefore useful to examine these concepts more closely, particularly the manner in which an LLM is trained and the distinctions between tokens, embeddings, model parameters and retrieval.

Training, Tokens and Embeddings: Drawing the Technical Lines

The starting point for understanding an LLM is the manner in which text is converted into a form that the model can process. As the judgment explains, raw text is first broken down into smaller units called tokens, each of which is assigned a numerical Token ID. A token does not necessarily correspond to a complete word; depending on the tokenizer used, it may represent a whole word, part of a word, punctuation or another unit of text. Thus, a word such as “unbelievable” may, depending on the tokenizer, be broken into several tokens for example, conceptually, “un” + “believ” + “able” rather than being processed as a single unit. The token is thereafter mapped to an embedding. Embedding is a vector representation that allows it to be processed mathematically by the model. Thus, a token, its Token ID and its embedding represent different stages of processing and should not be treated as interchangeable.

Tokenisation and embedding, however, only prepare the text for processing. The actual learning takes place during training. In a GPT-type model, the model is given a sequence of tokens and learns to assign probabilities to possible next tokens. For example, if the sequence is “The Court dismissed the”, the model assigns probabilities to possible next tokens such as “appeal”, “petition” or “application”. Its prediction is compared with the token that actually occurs in the training text, and the resulting error is used to adjust the model's parameters. Repeated across enormous quantities of text, this process enables the model to learn statistical patterns and relationships in language.

Next-token prediction should, however, be distinguished from masked-language modelling. In masked-language modelling, a token within a sequence is deliberately hidden and the model attempts to identify the missing token from the surrounding context. Thus, “The Court ___ the appeal” asks the model to predict what is missing. An autoregressive model works differently: given “The Court dismissed the”, it predicts what is likely to come next. Although both involve prediction, they are different training objectives. GPT-type models principally use autoregressive next-token prediction rather than masked-language modelling.

Importantly, an embedding should not be equated with the underlying text, nor should the model's parameters be understood simply as a database from which individual training documents can ordinarily be retrieved. During training, it is the model's parameters that are progressively adjusted as the model learns patterns from the training data.

This leads to a further question: if the model is not simply storing the text, what does it mean to say that it has “learned” from that text, and how can it sometimes memorise it?

Storage, Learning and Memorisation: Are They the Same?

Storage, learning and memorisation describe different technical phenomena. A work may first exist as part of a training dataset, where it is stored in the ordinary sense as data. During training, however, the model does not ordinarily learn by retaining each document as a separately retrievable record. Instead, exposure to the training data results in adjustments to a very large number of numerical parameters, through which the model learns statistical patterns and relationships present across the data. When generating a response, these learned parameters are used to assign probabilities to possible next tokens, from which the output is generated sequentially.

Learning from a work is therefore not necessarily the same as memorising it. A model may learn patterns from millions of texts without being capable of reproducing any particular text. Memorisation refers to circumstances in which particular sequences from the training data can be reproduced by the model under appropriate conditions. Even then, memorisation and the actual appearance of that material in a generated response are conceptually distinct. The latter is often described as regurgitation.

RAG, Search and Retrieval: Where Does the Information Come From?

An LLM's response need not depend exclusively upon what it learned during training. An AI system may also be designed to obtain information from an external source at the time a user makes a query. Retrieval-Augmented Generation (RAG) is one method of doing so.

In a typical RAG system, the user's query is used to search an external knowledge base for relevant information. The retrieved material is then supplied to the LLM as additional context for generating its response. The process therefore involves two distinct components: retrieval, which identifies information relevant to the query, and generation, in which the LLM uses that retrieved information together with the user's prompt to formulate a response.

RAG should not, however, be treated as synonymous with every form of access to external information. An AI system may obtain current information through web search, browsing, an application programming interface (API), or other tools connected to external sources. These mechanisms may be combined with an LLM, but the mere fact that information was obtained from outside the model's training data does not, by itself, establish that a RAG architecture was used.

This distinction becomes particularly relevant where a response contains information relating to an event that occurred after completion of the model's training. Such information may indicate that it was not derived from that particular training dataset, but that fact alone does not identify the mechanism through which it reached the system. Whether it was obtained through RAG, web search, an API or another connected tool, or generated without a reliable external source, remains a separate technical question.

Why Technical Architecture Matters to Copyright

The technical distinctions discussed above matter because copyright consequences depend upon what has actually happened to the protected work. Consider, for example, a copyrighted legal commentary. It may form part of the dataset on which an LLM was trained; passages from it may have been memorised during training; the commentary may be retrieved from an external database in response to a query; or portions of its text may appear in the model's generated response. Although the same work is involved in each situation, the technical process is different.

The distinction becomes clearer where the commentary was published after the cut-off date of the model's training data. If the model is asked about that work and produces a response, the response itself does not reveal where the information came from. The system may have accessed the commentary through RAG, web search, an API or another external tool. It may also generate a response without having accessed the commentary at all, resulting in information that appears plausible but is unsupported or incorrect, commonly referred to as a “hallucination”. Its ability to respond about a post-training work therefore does not, by itself, establish how the information was obtained or generated.

Technology does not determine the copyright consequence. It does, however, help identify the act to which copyright law is being applied. The inquiry must therefore begin with a simple question: what has the AI system actually done with the protected work?

ANI v. OpenAI brings into focus an emerging difficulty in applying copyright law to generative AI. Familiar legal concepts such as copying, storage and reproduction now encounter technological processes that do not always fit neatly within those descriptions.

The contribution of the judgment lies also in bringing the technical functioning of LLMs into the copyright inquiry. Training data, tokenisation, embeddings, model training, memorisation and RAG are no longer concepts confined to computer science; they have entered the vocabulary of copyright adjudication. ANI v. OpenAI is an early illustration of this development in Indian law.

As generative AI continues to evolve, courts are likely to encounter these concepts in increasingly varied factual settings. ANI v. OpenAI marks a point at which Indian copyright jurisprudence has begun engaging directly with the architecture underlying these systems. The judgment therefore provides not only a determination of the dispute before the Court at the interim stage, but also an early framework for understanding how questions concerning the architecture of generative AI may arise within copyright law. In that sense, ANI v. OpenAI marks the beginning of a larger conversation between the technical architecture of generative AI and the principles of copyright law.

Author is a Judicial Officer presently serving as an Additional District and Sessions Judge in Haryana. Views are personal.