The post has been translated automatically. Original language: Russian
The second part is about the rights to the AI model. A strong IP architecture does not shut down everything. It decides which layer should attract the ecosystem and which should not leave the controlled environment.
Let's introduce the team before the public release.
Inside the product there is a fully-trained model, its own eval kit, system promptings, a library of tools and a connector to corporate data. The team wants to show the market that the product is not a thin shell over someone else's API. One option is to open a repository and let the developers build the integration. Another one is not to publish anything until the competitors repeat the decision.
Both answers are clear. Both are too big.
In the first article, I analyzed the phrase "our model" by layers: architecture, code, weights, data, training recipe, prompta, infrastructure, API and brand. When this card is assembled, a mirror question arises. Which of its own stacks should the company open on its own?
I formulated the research question for this part as follows: what kind of work should each layer do after the release?
One layer should remain difficult to copy. The other one should be convenient for integration. The third one is needed as proof of technical novelty. The fourth one can bring more value if it turns into a common format.
Therefore, the solution here is not "open source or proprietary". It is accepted by assets.
Start with the function, not the mode name.
A patent, a trade secret, an open license, and a contract answer different tasks. They don't scale from weak protection to strong protection.
| Mode | When can it be useful? | What you need to take in advance |
| The patent | The technical solution can be described, it will retain its value for a long time, and the right to exclude others is important in selected markets. | Disclosure, cost, territoriality, and a separate freedom to operate check |
| Commercial secret | The value depends on the unknown, the asset is difficult to restore for the product, and access can be really limited. | Constant technical and organizational measures; secrecy usually does not stop independent development |
| Deliberate publication or open license | Is distribution, compatibility, trust, or ecosystem more valuable than exclusive control | Loss of secrecy and possible limitation of their own patent strategy |
| Contract plus access architecture | The user needs the result or interface, but not the core itself. | The restrictions apply within the contractual perimeter and require technical execution and control |
One AI product will almost always have several rows from this table at the same time.
For example, a way to speed up inference may be the subject of a patent application. The client SDK code will be released under an open license. The weights, the training recipe, and the eval set will remain inside. Access to the result will go through the API with restrictions on extraction and reverse engineering.
A mixed design does not mean that the strategy is not defined. For AI, it is usually a strategy.
Don't patent the word "AI"
Patent activity around generative AI is growing very fast. According to the WIPO Technology SPARK update, more than 56,000 new patent families were published in GenAI in 2024 and 2025 alone, more than in the previous decade.
This figure does not mean that every team urgently needs a patent. It means that the abstract idea "we use AI for task X" will be less and less sufficient and will increasingly live in the already dense field of other people's applications.
In the new guide for AI business, WIPO suggests looking at a specific technical solution. For computer-implemented inventions, the requirements depend on the jurisdiction, but the focus remains on novelty, inventive level, technical nature and applicability.
Therefore, the practical question is not "is it possible to patent our AI?", but rather:
What exactly does the system do technically differently?
Can this be seen or restored from the product?
Will the solution retain its value by the time the patent is granted?
In which countries will the law really be needed?
Is the future opportunity to exclude others worth the price of disclosure today?
And there's another border that's easy to miss. The patent gives the right to prohibit others from using the claimed solution. It does not guarantee the right of the company itself to freely bring the product to the market. WIPO separately separates the patent and freedom to operate: broader third-party patents may be used in the product.
A patent for its improvement does not clear the entire stack under it.
Check if the mystery can really remain a mystery.
For AI systems, trade secrets often look natural. Weights, hyperparameters, data composition, eval sets, filtering methods, and internal routing can retain value precisely because a competitor does not see them in their entirety.
But the word `confidential' in the registry does not protect anything by itself.
WIPO associates trade-secret protection with two basic features: information has economic value due to obscurity, and the owner takes reasonable measures to maintain secrecy. The exact requirements depend on the applicable law. In practice, the issue quickly moves from the presentation to the operating system.:
Who has access to the scales and the eval set?
Is it possible to unload them from the production environment?
What do contractors and research partners get?
Which fragments end up in logs, backups, and demos?
What happens to access after an employee changes roles or leaves?
The WIPO Trade Secret Management Guidelines go even further: the value and risk of loss of secrecy change with business, technology, and the market, so the regime needs to be reviewed rather than assigned once.
Secrecy works well where boundaries can be maintained. If the asset is easily restored through reverse engineering or independently developed, closure can only delay the decision.
The most dangerous secret is the one that the company has already actually disclosed, but continues to consider as a closed asset.
Use publishing as a solution, not as a marketing residue.
There is a third way between a patent and a secret: to publish the decision consciously.
Sometimes it is important for a company that a certain approach cannot later be privatized by someone else's patent. WIPO describes defensive publication as a disclosure that creates prior art and may prevent a later patent for the same or a similar solution from being granted.
The cost of this step is serious. Publication can destroy secrecy and significantly limit the company's ability to obtain a patent. Therefore, a blog article, a conference slide, a public repository, and detailed documentation should not appear before a conversation about protection mode.
There is another reason to open an asset: the company does not need a ban, but a distribution.
The open SDK reduces the cost of integration. The public compatibility scheme helps partners. Benchmarks create a common language of quality. An open license for a non-key component can lead to a product from developers that the company could never hire on its own.
Here the question changes:
Are we publishing because the asset has ceased to be valuable?
Or is it because its value grows with the number of people who use it?
These are two completely different solutions.
Agree on what the user doesn't get.
The contract is useful where the classic IP mode does not describe the entire boundary of use.
Copyright may protect the code, but it does not prohibit writing other code with the same function independently. Trade secrets help as long as the information remains private. The patent is valid within the limits of the formula, territory and term. The contract adds relationships between specific parties: why the user gets access, what they can do with the service, and which extraction or playback methods are prohibited.
In terms of OpenAI reverse engineering underlying components, automatic data extraction and outputs, as well as the use of outputs to develop competing models are separately prohibited. The Gemini API terms prohibit reverse engineering, extraction, and replication of service components, including weights.
This is not a universal right against the entire market. Such restrictions apply within the contractual perimeter, taking into account the applicable law and the enforceability of a particular condition.
Therefore, the contract must match the technical architecture. If the weights are freely unloaded, and the only control exists in the Terms of Use, the company transfers the protection to the dispute after the event. The API, access control, rate limits, extraction monitoring, and action log make the same boundary observable before the dispute.
The agreement names the border. The architecture makes it work.
Open the interface if the core needs to stay inside
The Model Context Protocol shows well the separation between interface and implementation.
In December 2025, MCP was transferred to the Agentic AI Foundation under the auspices of the Linux Foundation as one of the basic open source projects for agentic AI. On July 28, 2026, a new MCP specification was released with an updated protocol core, an extension mechanism, and enhanced authorization.
An open protocol tells systems how to connect. It does not require you to open the model, corporate data, internal logic of tools, user credentials, or commercial terms of service.
This is a useful architecture for a broader class of products.:
- open the connection point;
- standardize compatibility;
- leave the implementation and valuable data inside;
- Manage access, identity, and activity log at the border.
An open complement can expand the market for a secure core.
But the very word "standard" does not resolve IP issues. The protocol implementation remains code under a specific license. Extensions, names, compatible products, and data live by their own terms. The openness of one layer cannot be automatically transferred to the entire stack.
Separate the open grammar from your own vocabulary
With the advent of AI agents, more and more internal know-how is shifting from human instruction to executable form.
For example, a company can describe as a Skill the procedure for verifying a contract, reviewing an incident, qualifying a lead, or approving a release. This package contains instructions, scripts, reference materials, and templates. The agent downloads them when it sees a corresponding task.
The Agent Skills specification is open and defines a common format `SKILL.md `. At the same time, it explicitly provides for the `license` field, and in the example it allows proprietary conditions.
It turns out a familiar construction: the grammar is open, a particular dictionary can remain its own.
It is important not to make this a new kind of intellectual property right. Skill does not create a separate legal regime. This is a new container for familiar assets.:
- text and code may be protected by copyright;
- internal methodology and criteria can remain confidential know-how;
- data and external materials continue to live according to their licenses and grounds;
- the name and distribution of the package require a separate decision.
The format itself is portable. What exactly he teaches the agent can be one of the most valuable internal assets of the company.
Therefore, before publishing the Skill, you should ask the same questions as before opening the repository. What is a common way of interacting in it? What does the internal method reveal? What third-party materials went inside? And what business function should the publication perform?
Put the solution before the release
The IP architecture is not broken because the team chose the wrong mode in a beautiful table. More often than not, the solution did not arrive at all at the moment when the asset came out.
The researcher sent the article. The developer opened the repository. The product manager showed the scheme at the conference. The support team gave the contractor an eval kit. Marketing has published a detailed analysis of the method. Each step looked small and reversible.
After publication, some of the options disappear.
Therefore, the minimum system for a small team may consist of one card before a significant release.:
1. An asset. Which layer exactly are we opening, transferring, or leaving inside?
2. Business function. What should the chosen mode give: exclusivity, secrecy, compatibility, trust, distribution?
3. The foundation. Who created the asset, which upstream licenses and other components are still valid?
4. The solution. Patent assessment, secrecy, publication, open license, contractual access, or a combination?
5. The border. What exactly does the outside person get and what remains in the controlled environment?
6. The mechanism. Which accesses, contracts, labeling, repositories, API restrictions, and logs execute the solution?
7. The trail. Where are the decision, date, asset version, responsible and next review recorded?
Not every release requires a patent attorney and a large committee. But every irreversible release requires someone to notice it before publication.
Checking for a single asset
Take one element of an AI product that the team is going to show to a partner, investor, or developers.
And try to answer:
1. What value does this asset provide precisely because it is closed?
2. Is it possible to restore it based on the behavior of the product or independently develop it?
3. What does the company get if it is opened?
4. Did you have time to check the patent issue before publication?
5. What third-party licenses and agreements limit the solution?
6. Where is the technical boundary of access?
7. Which trace will prove in a year that openness or secrecy was a conscious choice?
If the answers lead to different modes for different layers, it's not a contradiction.
In the first article, the phrase "our model" turned into a matrix of rights. Now a second axis is added to it: what kind of work each protection mode does.
A strong IP strategy does not seek to close everything. It leaves open what should travel, and builds a working border around what should not leave the system.
Closing note
This is an operational framework, not a legal conclusion. Patentability, trade secret requirements, the consequences of disclosure, the enforceability of contractual restrictions, and the scope of rights depend on jurisdiction and specific circumstances. Prior to the irreversible publication or filing of an application, the decision must be verified according to applicable law.
Вторая часть о правах на AI-модель. Сильная IP-архитектура не закрывает всё подряд. Она решает, какой слой должен привлекать экосистему, а какой не должен покидать контролируемую среду.
Представим команду перед публичным релизом.
Внутри продукта есть дообученная модель, собственный eval-набор, системные промпты, библиотека инструментов и коннектор к корпоративным данным. Команда хочет показать рынку, что продукт не является тонкой оболочкой над чужим API. Один вариант звучит так: открыть репозиторий и дать разработчикам собрать интеграции. Другой: не публиковать ничего, пока конкуренты не повторили решение.
Оба ответа понятны. Оба слишком крупные.
В первой статье я разбирала фразу «наша модель» по слоям: архитектура, код, веса, данные, рецепт обучения, промпты, инфраструктура, API и бренд. Когда эта карта собрана, возникает зеркальный вопрос. Что из собственного стека компания должна открыть сама?
Исследовательский вопрос для этой части я сформулировала так: какую работу должен выполнять каждый слой после релиза?
Один слой должен остаться трудным для копирования. Другой должен стать удобным для интеграции. Третий нужен как доказательство технической новизны. Четвёртый может принести больше ценности, если превратится в общий формат.
Поэтому решение здесь не «open source или proprietary». Оно принимается по активам.
Начните с функции, а не с названия режима
Патент, коммерческая тайна, открытая лицензия и договор отвечают на разные задачи. Они не выстраиваются в шкалу от слабой защиты к сильной.
| Режим | Когда он может быть полезен | Что нужно принять заранее |
| Патент | Техническое решение можно описать, оно достаточно долго сохранит ценность, а право исключать других важно на выбранных рынках | Раскрытие, стоимость, территориальность и отдельная проверка freedom to operate |
| Коммерческая тайна | Ценность зависит от неизвестности, актив трудно восстановить по продукту, а доступ реально можно ограничить | Постоянные технические и организационные меры; независимую разработку тайна обычно не останавливает |
| Осознанная публикация или открытая лицензия | Распространение, совместимость, доверие или экосистема ценнее исключительного контроля | Потерю секретности и возможное ограничение собственной патентной стратегии |
| Договор плюс архитектура доступа | Пользователю нужен результат или интерфейс, но не само ядро | Ограничения действуют в договорном периметре и требуют технического исполнения и контроля |
У одного AI-продукта почти всегда будет несколько строк из этой таблицы одновременно.
Например, способ ускорить inference может стать предметом патентной заявки. Код клиентского SDK выйдет под открытой лицензией. Веса, рецепт обучения и eval-набор останутся внутри. Доступ к результату пойдёт через API с ограничениями на extraction и reverse engineering.
Смешанная конструкция не означает, что стратегия не определена. Для AI она обычно и есть стратегия.
Не патентуйте слово «AI»
Патентная активность вокруг генеративного AI растёт очень быстро. По обновлению WIPO Technology SPARK, только в 2024 и 2025 годах было опубликовано более 56 000 новых семейств патентов в GenAI, больше, чем за предыдущее десятилетие.
Эта цифра не означает, что каждой команде срочно нужен патент. Она означает, что абстрактная идея «мы используем AI для задачи X» всё реже будет достаточной и всё чаще будет жить в уже плотном поле чужих заявок.
WIPO в новом руководстве для AI-бизнеса предлагает смотреть на конкретное техническое решение. Для computer-implemented inventions требования зависят от юрисдикции, но в центре остаются новизна, изобретательский уровень, технический характер и применимость.
Практический вопрос поэтому звучит не «можно ли запатентовать наш AI?», а точнее:
Что именно делает система технически иначе?
Можно ли это увидеть или восстановить из продукта?
Сохранит ли решение ценность к моменту выдачи патента?
В каких странах право действительно понадобится?
Стоит ли будущая возможность исключать других цены раскрытия сегодня?
И ещё одна граница, которую легко пропустить. Патент даёт право запрещать другим использование заявленного решения. Он не гарантирует право самой компании свободно выводить продукт на рынок. WIPO отдельно разводит патент и freedom to operate: в продукте могут использоваться более широкие патенты третьих лиц.
Патент на своё улучшение не очищает весь стек под ним.
Проверьте, может ли тайна действительно остаться тайной
Для AI-систем коммерческая тайна часто выглядит естественно. Веса, гиперпараметры, состав данных, eval-наборы, методы фильтрации и внутренняя маршрутизация могут сохранять ценность именно потому, что конкурент не видит их целиком.
Но слово `confidential` в реестре ничего не защищает само по себе.
WIPO связывает trade-secret protection с двумя базовыми признаками: информация имеет экономическую ценность из-за неизвестности, а владелец принимает разумные меры для сохранения секретности. Точные требования зависят от применимого права. На практике вопрос быстро уходит из презентации в операционную систему:
Кто имеет доступ к весам и eval-набору?
Можно ли выгрузить их из рабочей среды?
Что получают подрядчики и исследовательские партнёры?
Какие фрагменты попадают в логи, резервные копии и демонстрации?
Что произойдёт с доступом после смены роли или ухода сотрудника?
Руководство WIPO по управлению коммерческой тайной идёт ещё дальше: ценность и риск утраты тайны меняются вместе с бизнесом, технологией и рынком, поэтому режим нужно пересматривать, а не назначать один раз.
Тайна работает хорошо там, где границу можно удерживать. Если актив легко восстановить через reverse engineering или независимо разработать, закрытость может только отсрочить решение.
Самый опасный секрет тот, который компания уже фактически раскрыла, но продолжает учитывать как закрытый актив.
Используйте публикацию как решение, а не как остаток маркетинга
Между патентом и тайной есть третий путь: опубликовать решение осознанно.
Иногда компании важно, чтобы определённый подход нельзя было позднее приватизировать чужим патентом. WIPO описывает defensive publication как раскрытие, которое создаёт prior art и может помешать выдаче более позднего патента на то же или сходное решение.
Цена у этого шага серьёзная. Публикация может уничтожить секретность и существенно ограничить возможность самой компании получить патент. Поэтому статья в блоге, конференционный слайд, публичный репозиторий и подробная документация не должны появляться раньше разговора о режиме защиты.
Есть и другая причина открывать актив: компании нужен не запрет, а распространение.
Открытый SDK снижает стоимость интеграции. Публичная схема совместимости помогает партнёрам. Эталонные тесты создают общий язык качества. Открытая лицензия на неключевой компонент может привести к продукту разработчиков, которых компания никогда не смогла бы нанять сама.
Здесь вопрос меняется:
Мы публикуем потому, что актив перестал быть ценным?
Или потому, что его ценность растёт вместе с количеством тех, кто им пользуется?
Это два совершенно разных решения.
Договоритесь о том, чего пользователь не получает
Договор полезен там, где классический IP-режим не описывает всю границу использования.
Авторское право может защищать код, но не запрещает независимо написать другой код с той же функцией. Коммерческая тайна помогает, пока информация остаётся закрытой. Патент действует в пределах формулы, территории и срока. Договор добавляет отношения между конкретными сторонами: зачем пользователь получает доступ, что он может делать с сервисом и какие способы извлечения или воспроизведения запрещены.
В условиях OpenAI отдельно запрещены reverse engineering underlying components, автоматическое извлечение данных и outputs, а также использование outputs для разработки конкурирующих моделей. Условия Gemini API запрещают reverse engineering, extraction и replication компонентов сервиса, включая веса.
Это не универсальное право против всего рынка. Такие ограничения действуют в договорном периметре, с учётом применимого права и исполнимости конкретного условия.
Поэтому договор должен совпадать с технической архитектурой. Если веса свободно выгружаются, а единственный контроль существует в Terms of Use, компания переносит защиту на спор после события. API, разграничение доступа, rate limits, мониторинг extraction и журнал действий делают ту же границу наблюдаемой до спора.
Договор называет границу. Архитектура заставляет её работать.
Откройте интерфейс, если ядро должно остаться внутри
Model Context Protocol хорошо показывает разделение между интерфейсом и реализацией.
В декабре 2025 года MCP был передан в Agentic AI Foundation под эгидой Linux Foundation как один из базовых открытых проектов для agentic AI. 28 июля 2026 года вышла новая спецификация MCP с обновлённым protocol core, механизмом расширений и усиленной авторизацией.
Открытый протокол говорит системам, как соединяться. Он не требует открыть модель, корпоративные данные, внутреннюю логику инструментов, полномочия пользователей или коммерческие условия сервиса.
Это полезная архитектура для более широкого класса продуктов:
- открыть точку подключения;
- стандартизировать совместимость;
- оставить реализацию и ценные данные внутри;
- управлять доступом, идентичностью и журналом действий на границе.
Открытый complement может расширять рынок для защищённого core.
Но само слово «стандарт» не снимает IP-вопросы. Реализация протокола остаётся кодом под конкретной лицензией. Расширения, названия, совместимые продукты и данные живут по своим условиям. Открытость одного слоя нельзя автоматически переносить на весь стек.
Отделите открытую грамматику от собственного словаря
С появлением AI-агентов всё больше внутреннего know-how переходит из инструкции для человека в исполняемую форму.
Например, компания может описать как Skill порядок проверки договора, разбор инцидента, квалификацию лида или путь согласования релиза. Такой пакет содержит инструкции, скрипты, справочные материалы и шаблоны. Агент загружает их, когда встречает соответствующую задачу.
Спецификация Agent Skills открыта и задаёт общий формат `SKILL.md`. При этом она прямо предусматривает поле `license`, а в примере допускает проприетарные условия.
Получается знакомая конструкция: грамматика открыта, конкретный словарь может оставаться собственным.
Важно не делать из этого новый вид интеллектуального права. Skill не создаёт отдельный правовой режим. Это новый контейнер для уже знакомых активов:
- текст и код могут охраняться авторским правом;
- внутренняя методология и критерии могут оставаться конфиденциальным know-how;
- данные и внешние материалы продолжают жить по своим лицензиям и основаниям;
- название и распространение пакета требуют отдельного решения.
Сам формат переносим. То, чему именно он учит агента, может быть одним из самых ценных внутренних активов компании.
Поэтому перед публикацией Skill стоит задать те же вопросы, что и перед открытием репозитория. Что в нём является общим способом взаимодействия? Что раскрывает внутренний метод? Какие сторонние материалы вошли внутрь? И какую бизнес-функцию должна выполнить публикация?
Поставьте решение перед релизом
IP-архитектура ломается не потому, что команда выбрала не тот режим в красивой таблице. Чаще решение вообще не попало в момент, когда актив вышел наружу.
Исследователь отправил статью. Разработчик открыл репозиторий. Product manager показал на конференции схему. Команда поддержки дала подрядчику eval-набор. Маркетинг опубликовал подробный разбор метода. Каждый шаг выглядел небольшим и обратимым.
После публикации часть вариантов уже исчезает.
Поэтому минимальная система для небольшой команды может состоять из одной карточки перед значимым релизом:
1. Актив. Какой именно слой мы открываем, передаём или оставляем внутри?
2. Бизнес-функция. Что должен дать выбранный режим: исключительность, секретность, совместимость, доверие, распространение?
3. Основание. Кто создал актив, какие upstream-лицензии и чужие компоненты продолжают действовать?
4. Решение. Патентная оценка, тайна, публикация, открытая лицензия, договорный доступ или комбинация?
5. Граница. Что именно получает внешний человек и что остаётся в контролируемой среде?
6. Механизм. Какие доступы, договоры, маркировка, репозитории, API-ограничения и журналы исполняют решение?
7. След. Где записаны решение, дата, версия актива, ответственный и следующий review?
Не каждый релиз требует патентного поверенного и большого комитета. Но каждый необратимый релиз требует, чтобы кто-то заметил его до публикации.
Проверка на один актив
Возьмите один элемент AI-продукта, который команда собирается показать партнёру, инвестору или разработчикам.
И попробуйте ответить:
1. Какую ценность этот актив даёт именно потому, что он закрыт?
2. Можно ли восстановить его по поведению продукта или независимо разработать?
3. Что компания получает, если его открыть?
4. Успели ли проверить патентный вопрос до публикации?
5. Какие сторонние лицензии и договоры ограничивают решение?
6. Где проходит техническая граница доступа?
7. Какой след докажет через год, что открытость или секретность были осознанным выбором?
Если ответы приводят к разным режимам для разных слоёв, это не противоречие.
В первой статье фраза «наша модель» превратилась в матрицу прав. Теперь к ней добавляется вторая ось: какую работу выполняет каждый режим защиты.
Сильная IP-стратегия не стремится закрыть всё. Она оставляет открытым то, что должно путешествовать, и строит работающую границу вокруг того, что не должно покидать систему.
Закрывающая заметка
Это операционная рамка, а не правовое заключение. Патентоспособность, требования к коммерческой тайне, последствия раскрытия, исполнимость договорных ограничений и объём прав зависят от юрисдикции и конкретных обстоятельств. До необратимой публикации или подачи заявки решение нужно проверять по применимому праву.
Share
