Для разработчика разрешение вопроса об «упаковке» ИИ-продукта имеет такое же важное значение, как и выбор бизнес-модели. Без ответа на вопрос, что именно компания продает — лицензию на программу для ЭВМ, доступ к программному интерфейсу приложения (API), результат генерации или услугу с использованием ИИ-модели, — выбрать договорную конструкцию невозможно. Важно определиться: что именно монетизируем? Чем массовая бизнес-модель отличается от кастомизированной? А с налоговой и контрактной точки зрения? Кто возьмет на себя ответственность за работу модели? Что проще внедрить: массовый продукт или индивидуальный?
Что именно монетизируем?
С точки зрения российского гражданского права типичная большая языковая модель, по нашему мнению, — программа для ЭВМ в смысле ст. 1259 и 1261 ГК РФ: программный код, который реализует процесс обработки данных с помощью уже обученной ИИ-модели (код инференса), обвязка, пользовательский интерфейс и системы, управляющие последовательностью задач (оркестратор пайплайнов), в совокупности охраняются авторским правом как единое произведение.
Вместе с тем составные части — веса обученной модели, обучающие наборы данных (датасеты), библиотеки с запросами (промптами), дообученные производные модели — на практике способны выступать самостоятельными предметами коммерциализации. Веса можно передавать в режиме коммерческой тайны как ноу-хау, лицензировать как часть программы для ЭВМ через отдельный договор именно на эту часть, в отдельных сценариях — обсуждать как базу данных (объект смежных прав изготовителя по параграфу 5 главы 71 ГК РФ). Доктринально точный ответ на вопрос о квалификации остается открытым; задача юриста на практике — корректно отграничить друг от друга предметы сделок и подобрать к каждому подходящий правовой режим.
Процедурная сторона здесь критична. Режим ноу-хау работает не сам по себе: требуется определить перечень сведений, ограничить доступ, вести учет получивших доступ лиц, регулировать использование договорами, маркировать носители грифом «коммерческая тайна». Без этих формальностей ссылка на ст. 1465 ГК в споре с уволенным разработчиком, «унесшим» веса, либо с контрагентом, превысившим пределы лицензии, не поможет. Для компонентов с открытым исходным кодом ст. 1286.1 ГК РФ квалифицирует открытую лицензию как разновидность простой неисключительной; совместимость законов об авторском праве (копилефт-режимов) с проприетарной обвязкой и с критериями реестра российского ПО, а также с логикой коммерциализации всего продукта как единого целого требует отдельной экспертизы в каждом новом продукте.
В отдельных сценариях обученную модель с надстройками вокруг нее может быть уместно квалифицировать как сложный объект. Статья 1240 ГК РФ относит к сложным объектам кинофильмы и иные аудиовизуальные произведения, театрально-зрелищные представления, мультимедийные продукты, базы данных и единые технологии. Пункт 44 постановления Пленума ВС РФ от 23.04.2019 № 10 уточняет порядок осуществления прав на сложный объект. Перенос конструкции на «ИИ-комплекс» доктринально дискуссионен, но позволил бы правообладателю единой моделью отвечать за вклады нескольких разработчиков без расщепления исключительного права на десятки лицензионных звеньев.
Массовая модель: подписка и доступ к программному интерфейсу приложения (API)
Юридически возможны два подхода:
-
лицензионный договор: правообладатель предоставляет пользователю простую (неисключительную) лицензию на использование программы для ЭВМ способом удаленного доступа с указанием срока, территории и пределов использования. Подход поддерживается разъяснениями Минфина и сложившейся практикой налоговых органов при квалификации программного обеспечения как услуги (SaaS) для целей подп. 26 п. 2 ст. 149 НК РФ — освобождения от НДС при реализации прав на программы из Единого реестра российских программ;
-
договор возмездного оказания услуг по главе 39 ГК РФ удобен при выраженном сервисном компоненте (модерация, тонкая настройка, гарантированная доступность, постоянное переобучение), но лишает поставщика возможности претендовать на налоговую льготу;
-
смешанный договор по п. 3 ст. 421 ГК РФ — лицензия плюс сопровождение — типичный компромисс. Налоговый риск возникает не от смешения, а от расщепления стоимости: непропорциональное соотношение в пользу лицензии при объективно высоком сервисном компоненте все чаще оспаривается налоговым органом.
Публичная оферта SaaS, заключаемая через нажатие «принимаю», квалифицируется судами как договор присоединения по ст. 428 ГК РФ. Явно обременительные для пользователя условия — об одностороннем изменении тарифа, автопродлении без права отказа, неприменимости общих оснований ответственности — могут быть пересмотрены судом по требованию пользователя. Это требует балансировать оферту: жесткие коммерческие условия — отдельным согласием по чек-боксу, существенные изменения — через уведомление с правом расторжения.
Наконец, следует учитывать правила законодательства о защите прав потребителей.
Индивидуальная модель: внедрение под заказ и под контролем компании (on-premise)
Индивидуальный сценарий встречается там, где заказчик — крупный корпоративный клиент с жесткими требованиями к безопасности, отраслевому регулированию или интеграции. У банковских, страховых, инфраструктурных и государственных заказчиков публичный SaaS-договор практически нереализуем: модель размещается в контуре заказчика, исходящие соединения отключены, поставка оформляется как проект с предпроектным обследованием, ТЗ, поэтапной приемкой и соглашением об уровне обслуживания (SLA).
Могут использоваться три договорные модели:
-
лицензионный договор на конкретные экземпляры программы для ЭВМ с правом установки на заданное оборудование и правом на обновления;
-
договор подряда на разработку программы по ст. 1296 ГК РФ или НИОКР по главе 38 ГК (ст. 769—778) — для случаев с реальным исследовательским компонентом;
-
смешанный сервисный договор, где лицензия сочетается с услугами по внедрению, обучению и гарантийной поддержке.
Распределение исключительных прав в подрядной модели — отдельная история. Статья 1296 ГК РФ передает исключительное право заказчику, если программа создана по договору, прямо имевшему ее создание предметом. Статья 1297 действует, когда программа создана при выполнении работ, прямо ее предметом не имевших, и оставляет право у подрядчика с безвозмездной простой лицензией заказчика.
Граница проходит по формулировке предмета. Разработчику желательно прямо в договоре фиксировать обратное по отношению к ст. 1296 ГК РФ правило: исключительные права на платформу, веса модели (если применимо) и доработки остаются у исполнителя, заказчику передаются права только на интеграционные модули, отраслевые промпт-библиотеки и кастомизированные настройки. Без этой оговорки контроль над собственным продуктом может потеряться уже после первого крупного контракта.
Корпоративный контракт обычно сопровождается поручением на обработку персональных данных по ч. 3 ст. 6 Закона № 152-ФЗ с указанием цели, перечня операций, срока, требований к конфиденциальности и мер защиты; отдельно подписывается соглашение о неразглашении с режимом коммерческой тайны на стороне исполнителя.
Налоговый режим и реестр российского ПО
Льгота по подп. 26 п. 2 ст. 149 НК РФ освобождает от НДС реализацию прав на программы для ЭВМ и базы данных, включенные в Единый реестр российских программ. На практике в смешанном договоре стоимость лицензии и стоимость сопровождения должны быть выделены прозрачно, а каждая позиция — обоснована экономически, иначе налоговый орган переквалифицирует обе части в услугу.
Критерии включения в реестр на стадии запуска ИИ-продукта оказываются жестче (п. 5 Правил, утвержденных ПП РФ от 16.11.2015 № 1236). Для команд, использующих зарубежные наборы инструментов для создания ПО (SDK) и веса моделей, это главный барьер. Обход через построение собственного слоя без вкрапления чужих весов возможен, но требует юридического сопровождения каждой итерации архитектуры.
В индивидуальных внедрениях структура договора обычно лучше совместима с льготой: лицензия на on-premise-установку плюс отдельный договор сопровождения позволяют корректно разделить базы налогообложения.
Персональные данные и режим обработки
Регулирование персональных данных — главный камень, о который спотыкаются и массовые, и индивидуальные ИИ-продукты. Принципиальное различие моделей — статус сторон. В индивидуальном on-premise-внедрении исполнитель, как правило, не становится оператором персональных данных пользователей заказчика, а в чистом сценарии без удаленного доступа к данным остается вне процессорного контура — обработка происходит на инфраструктуре заказчика, статус оператора сохраняется за ним. Если исполнитель в рамках поддержки получает доступ к данным, он квалифицируется как лицо, осуществляющее обработку по поручению (ч. 3 ст. 6 Закона № 152-ФЗ).
В массовой SaaS-модели поставщик автоматически становится либо оператором, либо обработчиком и приобретает ряд обязательств (п. 2 ст. 18.1), с учетом правил трансграничной передачи по ст. 12, определение угроз и применение мер защиты в соответствии с уровнем защищенности. Конкретный набор требований устанавливается подзаконными актами.
Для сервиса для массового потребителя с большим числом субъектов и категориями данных за пределами общедоступных типичный целевой ориентир — уровень защищенности 2 или 3 (в зависимости от категорий данных и модели угроз; обработка специальных категорий и биометрии при актуальных угрозах 1—2-го типа повышает планку до 1-го уровня), со всеми инфраструктурными требованиями: аттестация информационной системы, сертифицированные ФСТЭК средства защиты, организационные меры.
С 30 мая 2025 г. ст. 13.11 КоАП РФ устанавливает за утечки значительные штрафы. Параллельно введена уголовная ответственность по ст. 272.1 УК РФ. Информационная безопасность становится самостоятельным экономическим фактором бизнес-модели, особенно ощутимым в массовом сегменте.
Для генеративных моделей дополнительные обстоятельства— обработка персональных данных в составе промптов: даже без прямого ввода идентификаторов пользователь оставляет в окне модели сведения, квалифицируемые как персональные. В политике обработки разумно прямо описать сценарий промптов, разделить режимы обработки записей промптов для исполнения запроса и для дообучения модели, ограничить их хранение и переиспользование — особенно в массовом продукте. В индивидуальных внедрениях вопрос решается архитектурно: отключением передачи промптов за пределы контура заказчика.
Кому принадлежит результат работы модели
Российский законодатель в действующей редакции ГК РФ не признает ИИ субъектом интеллектуальных прав. Пункт 80 постановления Пленума ВС РФ от 23.04.2019 № 10 разъясняет, что авторские права распространяются на результаты, отвечающие условиям самостоятельности и творческого характера. На этом основании в доктрине последовательно формулируется позиция, что результат, созданный программой без существенного творческого вклада человека, авторско-правовой охране не подлежит.
Применительно к большим языковым моделям это означает, что выходные тексты, полученные по простому пользовательскому промпту, скорее всего, не охраняются; текст, прошедший существенную творческую доработку человеком, переходит в категорию охраняемых. Эксклюзивность выходных данных в массовом продукте существует лишь как договорное обязательство поставщика не использовать конкретный результат для иных пользователей.
Стандартная конструкция: исключительные права на код и веса остаются у поставщика; поставщик отказывается от любых притязаний на охраняемые результаты, возникающие у пользователя при использовании сервиса, и принимает договорное обязательство не использовать конкретные выходные данные конкретного пользователя для иных клиентов и для дообучения модели без явного согласия; если выходные данные сами по себе обладают творческим характером, исключительное право возникает у их фактического автора.
В индивидуальном внедрении распределение жестче: артефакты, созданные при эксплуатации модели на инфраструктуре заказчика, принадлежат заказчику, а исполнитель сохраняет права на улучшения базовой модели только при условии, что они не содержат конфиденциальной информации заказчика.
Критическая информационная инфраструктура
Когда ИИ-решение встраивается в процессы субъекта критической информационной инфраструктуры — банка, оператора связи, энергетической или транспортной организации, медицинского учреждения, государственного органа (см. ст. 2 Федерального закона от 26.07.2017 № 187-ФЗ), — на договор накладывается отдельный контур требований.
Субъект КИИ обязан категорировать собственные объекты (три категории значимости), подключиться к государственной системе обнаружения, предупреждения и ликвидации последствий компьютерных атак, уведомлять ФСБ России о компьютерных инцидентах и обеспечивать защиту значимых объектов по приказу ФСТЭК России от 25.12.2017 № 239. Если ИИ-решение становится частью значимого объекта КИИ, оно наследует требования к этому объекту.
С 01.09.2025 на значимых объектах КИИ обязательно применение программного обеспечения из Единого реестра российских программ, а программно-аппаратные средства должны принадлежать российским лицам или организациям под российским контролем; индивидуальные предприниматели той же поправкой выведены из числа субъектов КИИ.
С 01.09.2026 к субъектам КИИ предъявляются повышенные требования к национальной принадлежности и ужесточена ответственность за их несоответствие.
Параллельно действуют Указ Президента РФ от 30.03.2022 № 166 (запрет иностранного ПО на значимых объектах КИИ для субъектов-заказчиков по 223-ФЗ) и Указ Президента РФ от 01.05.2022 № 250 (запрет на средства защиты информации из недружественных стран); конкретные требования к импортозамещению ПО на значимых объектах раскрыты в постановлении Правительства РФ от 22.08.2022 № 1478, а к доверенным программно-аппаратным комплексам — в постановлении Правительства РФ от 14.11.2023 № 1912. Срок полного перехода на доверенный технологический контур установлен до 2030 г.
Для поставщика ИИ-решения это означает, что включение в Единый реестр российского ПО превращается из налоговой опции в условие допуска к корпоративным заказчикам из числа субъектов КИИ.
Ответственность за работу модели
Российское право не выделяет ответственность за вред, причиненный системой ИИ, как самостоятельный институт; применяются общие нормы о возмещении убытков, об ответственности за качество товаров и услуг, в отдельных случаях — ст. 1064 ГК РФ о деликтной ответственности.
Проект федерального закона «Об основах государственного регулирования сфер применения технологий искусственного интеллекта в Российской Федерации» (ID 02/04/03-26/00166424) вводит риск-ориентированный подход и предполагает специальные правила ответственности. Планируемая дата вступления в силу — 01.09.2027, поэтому до принятия закона и наработки правоприменительной практики строить контрактную защиту неосмотрительно.
Договорное ограничение ответственности поставщика стоимостью уплаченной за период лицензии допустимо между предпринимателями в силу принципа свободы договора (ст. 421 ГК РФ, постановление Пленума ВАС РФ от 14.03.2014 № 16). Пункт 4 ст. 401 ГК РФ делает ничтожным заранее заключенное соглашение об устранении или ограничении ответственности за умышленное нарушение, поэтому случаи умысла лимиту не подлежат.
На грубую неосторожность судебная практика по аналогии нередко идет по тому же пути, и при формулировании лимита разумно прямо вывести оба случая из его действия. Вопрос об ответственности лица, использующего чужую (не им обученную) ИИ-модель, за нелегальные или ошибочные результаты ее работы — один из самых острых и дискуссионных на сегодняшний день и пока ждет системного доктринального ответа.
Стандартный пакет договорных правил: оговорка о неприменимости результатов модели как окончательного решения в юридически значимых ситуациях; лимит ответственности с исключениями на умысел и грубую неосторожность; распределение ответственности за бизнес-решения заказчика и работоспособность инструмента в пределах SLA; гарантии от притязаний третьих лиц по обучающим данным с количественным лимитом возмещения.
Что проще: массовое или индивидуальное?
Массовая монетизация, на первый взгляд, проще: одна публичная оферта, типовая лицензия, автоматические расчеты с клиентами. Сложность смещена в инфраструктуру и соответствие законодательству (комплаенс). Поставщик одновременно становится оператором персональных данных, отвечает за уровень защищенности по ПП РФ № 1119 и приказам ФСТЭК и ФСБ, несет ответственность за утечки по ст. 13.11 КоАП — фиксированную при первичной утечке и оборотную при повторной, выстраивает доказательственную базу для применения льготы по реестру и проектирует оферту с учетом ст. 428 ГК РФ. Ошибка масштабируется на всех клиентов одновременно.
Индивидуальное внедрение тяжелее на старте: каждый контракт требует индивидуальной разработки, согласования соглашения о неразглашении и поручений на обработку, проработки распределения исключительных прав и Закона № 152-ФЗ. Взамен поставщик управляет рисками по каждой сделке отдельно, защищает интеллектуальную собственность и в большинстве случаев освобождается от прямого статуса оператора персональных данных конечных пользователей. Для on-premise безопасность и комплаенс ложатся на инфраструктуру заказчика, ответственность исполнителя ограничивается качеством поставленного инструмента в пределах SLA.
Рациональный путь для большинства новых ИИ-продуктов — пройти стадию индивидуальных внедрений у нескольких якорных корпоративных заказчиков, выработать на них стандартный договорный каркас (лицензия + сопровождение + поручение) и параллельно выходить в массовый SaaS-сегмент уже по отработанной правовой архитектуре.
Перепрыгивать через индивидуальную стадию имеет смысл только продуктам с массовой ценовой моделью и минимальными отраслевыми рисками. В остальных случаях именно индивидуальные внедрения создают ту юридическую дисциплину, без которой массовая монетизация не выдерживает первой проверки, первого спора с пользователем или первого отказа налогового органа в льготе.
В текущей конфигурации — где специальное регулирование ИИ обсуждается, но не принято, налоговый режим программ для ЭВМ опирается на критерии реестра, а ответственность за вред собирается из общегражданских норм и подзаконной обвязки Закона № 152-ФЗ — преимущество получит поставщик, который не пытается решить задачу одной типовой лицензией.