Изобретения с применением ИИ: правовой статус и патенты в 2026 году
В конце 2025-го у меня был разговор с инженером из Казани. Он показывал демо: нейросеть подбирает режимы работы для городских светофоров так, что пробка «сдувается» на глазах, но в отчёте о разработке на один абзац больше, чем в реальном коде. И вот сидим мы, кофе остывает, и человек спрашивает: «Эльвира, а патент-то тут чей? Мой, команды, или “того самого ИИ”?» Вопрос звучит почти смешно, пока не открываешь практику и не понимаешь: если на старте не договориться с собой и с документами, потом будет не до шуток.
2026 год в этой теме ощущается как перекрёсток. С одной стороны, ИИ в разработках стал настолько будничным, что его используют и в медицине, и в промышленности, и в городском хозяйстве. Роспатент в 2024 году фиксировал 1 650 заявок на патенты, связанные с ИИ, это около 3–4% от всех изобретений; за первые 10 месяцев 2025-го таких заявок было уже 1 270. С другой стороны, право любит ясность, а ИИ любит вероятности. На стыке получается знакомая российская картина: технология мчит, а юридическая часть догоняет, иногда на одной ноге.
После этого текста вы сможете разложить по полочкам, кого и как указывать в заявке, как описывать «участие ИИ» так, чтобы не подставиться, что собирать в доказательства разработки и где чаще всего люди теряют месяцы. Я буду говорить из практики, с человеческими оговорками, потому что идеальных проектов вобще не бывает. И да, если вы параллельно хотите держать руку на новостях по товарным знакам и патентам, вот нормальный вариант без лишней мишуры: Телеграмм канал Патентного бюро Лирейт».
Пошаговый гайд: как подготовить патент на изобретение с ИИ так, чтобы не покраснеть на экспертизе
Шаг 1. Определите, где в вашем решении «изобретение», а где просто удобный ИИ-инструмент
Первое, что мы делаем, это честно отвечаем: ИИ у вас внутри технического решения или он только помог с расчётами, подбором параметров, написанием кода, генерацией вариантов? Зачем это нужно: патент защищает техническое решение, а не факт, что вы пользовались модной моделью. Типичная ошибка: пытаться «запатентовать нейросеть» без конкретного технического эффекта и без связки с устройством, способом, системой. Проверка простая, почти бытовая: сформулируйте одной фразой, что именно изменилось в мире после вашей разработки. Например, «система по данным датчиков прогнозирует очаги лесных пожаров и корректирует маршруты патруля» или «алгоритм автоматически измеряет размеры опухоли на снимках и снижает разброс между врачами». Если вместо этого выходит «ИИ анализирует данные и повышает эффективность», это тревожный звоночек, надо копать глубже.
Мини-кейс из работы: у команды из Новосибирска был прототип для заводской линии, ИИ подбирал режимы нагрева, чтобы меньше брака уходило в утиль. Они сначала хотели описывать «архитектуру нейросети», слои, эмбеддинги, вот это всё. На экспертизу такая подача обычно действует как туман: вроде много слов, а результата не видно. Мы переформатировали описание вокруг способа управления линией и измеримого техэффекта (без фантазий и цифр «от потолка»), а ИИ оставили как часть реализации. И внезапно текст стал понятнее даже инженеру из соседнего цеха, а это хороший тест.
Шаг 2. Решите вопрос с авторством: ИИ в заявку не ставим, людей ставим аккуратно
В 2026 году главная практическая линия всё ещё человеческая: изобретателем указывают человека (или людей), которые внесли творческий вклад в техническое решение. Зачем: от этого зависят права, договоры, отношения с работодателем, и банально то, кто имеет право подпись поставить. Типичная ошибка: «ИИ всё придумал, а я просто нажал кнопку». Во-первых, это опасно рассказывать вслух, во-вторых, даже если вам так кажется, в большинстве проектов человек всё равно задаёт цель, подбирает данные, ограничивает область поиска, выбирает вариант и проверяет применимость. Проверка: соберите короткое описание, кто принимал ключевые инженерные решения. Если в ответе есть конкретные фамилии и решения (выбор датчиков, критериев оптимизации, архитектуры системы, схемы взаимодействия), вы на правильной стороне реальности.
Тут обычно всплывает конфликт: руководитель проекта хочет быть «везде», а разработчик не хочет делиться. Я видела, как из-за одной лишней фамилии в заявке люди переставали здороваться в коридоре. Мой подход простой и немного занудный: смотрим вклад в решение, а не должность и не KPI. И если проект корпоративный, ещё и проверяем внутренние документы, потому что «служебное изобретение» в компаниях устроено не по принципу дружбы.
Шаг 3. Документируйте процесс так, будто через год вам придётся доказывать, что вы не маг и не плагиатор
Что делаем: фиксируем этапы разработки, включая участие ИИ. Не роман в трёх томах, а рабочие артефакты: версии, протоколы экспериментов, логи запусков, датасеты (хотя бы их состав и источник), критерии отбора результата, внутренние отчёты. Зачем: при споре или вопросах экспертизы вы сможете показать, что решение родилось в инженерной работе, а не в «сгенерировали на коленке». Типичная ошибка: надеяться на память и переписку в мессенджере, которая потом внезапно исчезает вместе с телефоном бывшего сотрудника. Проверка: попробуйте через месяц восстановить цепочку «постановка задачи → тесты → выбор конфигурации → подтверждение эффекта». Если вы сами путаетесь, эксперту будет ещё веселее.
Кейс из жизни: ИП из Подмосковья делал систему контроля качества для небольшого производства, там камера смотрит на изделие, модель отмечает дефекты, а дальше идёт команда на отбраковку. Разработчик аккуратно хранил только финальные веса модели, а исходные эксперименты, почему выбрали именно такие признаки и пороги, нигде не фиксировал. Когда пришло время готовить заявку, мы потратили две недели на «вспомнить как было» и ещё неделю на повтор экспериментов, потому что иначе описание выходило рыхлым. С тех пор я повторяю как мантру: документирование это не бюрократия, это страховка от собственной забывчивости.
Шаг 4. Подготовьте описание изобретения: меньше магии, больше инженерии
Что делаем: пишем заявку так, чтобы было ясно, из каких частей состоит решение и как они взаимодействуют. Если у вас система, то какие модули, какие входные данные, какой выход, что происходит при сбое, какие режимы работы предусмотрены. Если способ, то последовательность действий, условия, параметры, что именно изменяется. Зачем: патент живёт на формулировках, и «понятно мне» не равно «понятно эксперту». Типичная ошибка: уходить в пересказ датасайенс-терминов без привязки к реальному объекту или процессу. Проверка: дайте черновик человеку из вашей команды, который не писал код, и попросите объяснить, что происходит. Если он может пересказать без слов «ну, оно там само», это хороший знак.
Кстати, в 2024 году появился PatentGPT, языковая модель для автоматизации составления патентных документов, и сама идея многим кажется спасением. Я к этому отношусь спокойно: такие инструменты могут помочь с черновиком структуры и с аккуратностью формулировок, но не заменят инженера и патентного поверенного. Самая неприятная ошибка тут такая: доверить генератору описать технический эффект, а потом обнаружить, что он «улучшил» вашу разработку несуществующими свойствами. Проверка простая: каждое утверждение в тексте должно иметь источник в ваших тестах или документации. Если источника нет, вычёркиваем, даже если звучит красиво.
Шаг 5. Проверьте новизну и уровень техники: не бойтесь, но и не фантазируйте
Что делаем: смотрим, не опубликовано ли уже что-то очень похожее. Это поиск по патентам, статьям, иногда по релизам компаний, если речь про прикладные решения. Зачем: иначе вы можете потратить время и деньги на заявку, которая развалится на первом же сравнении. Типичная ошибка: ограничиться поиском «в гугле» и парой статей на Хабре. Проверка: составьте набор ключевых признаков решения и по каждому найдите аналоги, а затем честно выпишите отличия. Если отличий нет, значит, вы либо не то ищете, либо действительно изобретение не тянет на патент, и это тоже полезно узнать пораньше.
Немного контекста для настроения: по данным ВОИС, в 2024 году в мире подали 3,7 млн патентных заявок, рост на 4,9%. В такой толпе легко наступить на чужую идею просто потому, что кто-то уже сделал похожее в другой стране и на другом рынке. А ещё в 2024 году число действующих патентов в мире выросло на 6% и дошло до 19,7 млн, лидируют Китай, США и Япония. На практике это означает одно: «похожего нет» без нормального поиска звучит как «я не смотрел».
Шаг 6. Подайте заявку и следите за сроками: цифровизация помогает, но расслабляться нельзя
Что делаем: готовим комплект документов и подаём в Роспатент, дальше аккуратно отвечаем на запросы экспертизы. Зачем: даже сильная заявка может зависнуть, если пропустить письмо или не уложиться в срок. Типичная ошибка: думать, что подача это финал марафона, и можно выдохнуть. На деле начинается переписка, уточнения, иногда корректировки формулы, и лучше быть на связи. Проверка: назначьте внутри команды одного ответственного за коммуникацию и храните всю переписку в одном месте, а не «у кого в почте осталось».
Из хорошего: Роспатент последние годы действительно ускоряет процессы благодаря цифровой трансформации, и по их данным срок рассмотрения заявки на изобретение сокращался с 8 до 4 месяцев. Это не значит, что все дела летят за квартал, но общий ритм стал быстрее. И вот тут появляется новая ловушка: когда всё движется быстро, ошибки становятся дороже, потому что времени «передумать» меньше. Я обычно советую: перед подачей сделайте финальную техническую вычитку тем же инженером, который будет потом отвечать эксперту. Иначе вы поймаете себя на том, что в формуле одно, в описании другое, а в прототипе третье.
Шаг 7. Разведите патент и софт: иногда нужна двойная защита
Что делаем: отдельно думаем про патент на изобретение и отдельно про охрану программного кода, баз данных, интерфейсов, документации. Зачем: патент прикрывает техническое решение, но многое в ИИ-проектах живёт в софте и данных, и там свои инструменты защиты. Типичная ошибка: пытаться «впихнуть» весь продукт в один патент, чтобы было «всё моё». Проверка: разложите продукт по слоям. Есть ли у вас технический способ/система, которую можно описать без привязки к конкретному репозиторию? Есть ли уникальные датасеты и разметка? Есть ли бренд, под которым вы выходите на рынок? Ответы покажут, где нужны разные правовые режимы, и это нормально.
И тут я осторожно напомню про бренд. Иногда команда делает сильную технологию, но в публичное поле выходит под названием, которое уже занято, и потом начинается не юридический спор, а бытовой кошмар: карточки на маркетплейсах, домены, соцсети, путаница в клиентах. Если вы на стадии запуска, посмотрите в сторону Регистрация товарного знака и того, что коллеги называют Монополия на бренд. Это не про «красивую бумажку», а про то, чтобы не отдавать имя проекта первому, кто быстрее дошёл до регистрации.
Подводные камни: где чаще всего ломается патентование ИИ-изобретений
Первое больное место это расплывчатость. ИИ-проекты любят говорить языком вероятностей: «лучше», «точнее», «быстрее». Но патентному описанию нужны признаки и причинно-следственная связь: за счёт чего именно получается эффект. Когда этого нет, заявка превращается в эссе, а экспертиза не обязана угадывать вашу задумку. Я иногда вижу, как команда стесняется признаться, что часть решения держится на инженерных мелочах: калибровке датчика, фильтрации сигнала, правильном окне агрегации. А зря, именно там часто и живёт новизна.
Второе место это данные и «чужое». Если вы обучали модель на материалах, происхождение которых никто не может внятно объяснить, вы рискуете не только репутацией, но и спором о правах. При этом патент не требует раскрывать весь датасет в заявке, но общая добросовестность разработки должна быть. Ещё одна типичная история: подрядчик сделал часть работ, ИИ настраивал он же, а договором не закрепили, кому принадлежат результаты. Потом стартап ищет инвестиции, инвестор спрашивает «а права где?», и тишина, только кондиционер гудит.
Третье место это ожидания. Люди часто думают, что патент это быстрый талисман от копирования. На практике патент это инструмент, который работает, когда у вас есть внятные формулировки, стратегия и готовность защищать права. Иногда правильнее начать с внутреннего режима коммерческой тайны, иногда с регистрации софта, а патент делать, когда решение стабилизировалось и вы понимаете, что именно защищаете. Я не романтизирую: патентование требует дисциплины, а не вдохновения, и именно поэтому многие хорошие разработки остаются без защиты.
Когда имеет смысл подключать юристов по интеллектуальной собственности
Если у вас разработка не «для диплома», а для рынка, то поддержка обычно окупается нервами. Особенно когда в проекте есть несколько команд, подрядчики, гранты, совместные права, или когда технологию нужно показывать партнёрам, не раскрывая лишнего. Я видела, как люди теряли месяцы просто потому, что не могли договориться о составе авторов и правообладателе, хотя технически всё было готово. В таких ситуациях ценна не «магия юриста», а спокойная раскладка по документам и сценариям: кто что сделал, кто за что отвечает, как фиксируем вклад, что публикуем, а что держим под NDA.
Ещё один частый запрос это связка «патент плюс бренд». Технология может быть сильной, но рынок запоминает название, и если с ним беда, вы будете потом переименовываться в самый неудобный момент. Когда нужно быстрее сориентироваться, я обычно отправляю людей в Юридическая защита интеллектуальной собственности и прошу хотя бы один созвон, чтобы не изобретать велосипед. Ну и да, новости и разборы кейсов я сама читаю в телеге, поэтому ещё раз оставлю ссылку без уговоров: Telegram-канал.
FAQ
Вопрос: Можно ли указать ИИ изобретателем в заявке на патент в России в 2026 году?
Ответ: На практике в заявках указывают людей, которые внесли творческий вклад. ИИ рассматривают как инструмент, даже если он сильно помог с подбором решений. Если сомневаетесь, лучше разложить вклад по шагам разработки и зафиксировать, какие решения принимали конкретные участники.
Вопрос: Если ИИ сгенерировал идею, а я её только проверил, я изобретатель?
Ответ: Обычно важен именно творческий вклад в техническое решение: постановка задачи, выбор ограничений, отбор и проверка результата, инженерная интеграция. «Только проверил» бывает по-разному, иногда это и есть ключевая часть работы. Но фраза «только нажал кнопку» почти всегда означает, что документации у проекта ноль, и это проблема.
Вопрос: Нужно ли в заявке раскрывать, на каких данных обучалась модель?
Ответ: Полный датасет раскрывать не обязаны, но описание должно быть достаточным, чтобы специалист мог воспроизвести решение. Обычно указывают типы данных, источники в общем виде, подход к подготовке и важные параметры. И важно, чтобы происхождение данных было легальным и понятным внутри команды.
Вопрос: Что патентуют чаще в ИИ-проектах: алгоритм или продукт?
Ответ: Чаще патентуют техническое решение: способ, систему, устройство, где ИИ является частью реализации и даёт технический эффект. «Чистый алгоритм» без привязки к технической задаче обычно выглядит слабее для патентования.
Вопрос: Реально ли подать и получить решение быстрее, чем раньше?
Ответ: Роспатент отмечал ускорение рассмотрения заявок благодаря цифровизации, срок мог сокращаться с 8 до 4 месяцев. Но это не кнопка «турбо»: на сроки влияют качество заявки, переписка с экспертизой и загруженность. Быстрее стало, но халтура всё равно догоняет.
Вопрос: Можно ли использовать инструменты вроде PatentGPT для подготовки заявки?
Ответ: Можно как вспомогательный инструмент для черновиков и формулировок, но финальный текст должен опираться на ваши реальные материалы и проверки. Самая частая беда от таких помощников это «улучшенные» свойства, которых у решения нет, а потом эти слова приходится вычищать, пока не поздно.
Вопрос: Если у нас уже есть патент, товарный знак не нужен?
Ответ: Это разные вещи. Патент защищает техническое решение, а товарный знак защищает название и обозначения, под которыми вас узнают. В реальном бизнесе их часто используют вместе, потому что копируют обычно не только технологию, но и узнаваемость.