Прежде чем нанимать архитектора или подписывать чек, фаундеру и инвестору стоит понять одну вещь: специального закона, который регулировал бы именно LegalTech- или FinTech-продукт на базе чужой ИИ-модели, в России пока нет. Но это не означает полного отсутствия правил — правовое поле просто устроено иначе, чем кажется.
Правовой статус ИИ-продукта в 2026: где реальные границы для API-продуктов
Что реально вступило в силу. 1 сентября 2026 года начал действовать 243-ФЗ «О поддержке развития технологий искусственного интеллекта» — первый в России закон именно об ИИ. Но у него узкий предмет: закон регулирует «большие фундаментальные модели» — программы от 1 млрд параметров, способные решать широкий круг задач и служить основой для других продуктов. Это уровень моделей Сбера или Яндекса, а не стартапа, который встраивает в свой продукт готовую модель через API. Для большинства LegalTech- и FinTech-команд этот закон — фон, а не прямое регулирование.
Что готовится. В марте 2026 года Минцифры внесло в Госдуму законопроект «Об основах государственного регулирования сфер применения технологий искусственного интеллекта» — и вот он уже о том, как ИИ используют в продуктах, а не только о том, кто его разрабатывает. Ожидаемый срок вступления в силу — 1 сентября 2027 года. Проектировать архитектуру продукта имеет смысл уже с оглядкой на этот документ: то, что сегодня серая зона, завтра может стать формальным требованием.
Регулирование, которое уже касается вас — не про ИИ, а про интеллектуальную собственность. Пока специального закона нет, работает общее правило Гражданского кодекса: автором результата интеллектуальной деятельности признаётся гражданин, чьим творческим трудом он создан (ст. 1228 ГК РФ). Нейросеть гражданином не является — значит, то, что модель сгенерировала сама по себе, без творческого участия человека, авторского права не получает.
Отсюда практический вывод для архитектуры продукта: защищать имеет смысл не сырой вывод модели, а то, что реально создаёт ваша команда вокруг него, — и у разных частей этой работы разное основание защиты. Код и JSON-схемы логики — объекты авторского права (ст. 1259, 1261 ГК РФ), они охраняются как произведения. Калибровочный датасет — это уже другой механизм: право изготовителя базы данных (ст. 1333–1334 ГК РФ), которое возникает не из творчества, а из существенных затрат на её составление.
Ответственность за галлюцинации: прецедент № А27-7831/2025
Пока новый закон только готовится, ответственность за ошибки ИИ уже наступает — по общим правилам. Принцип простой: отвечает не алгоритм и не модель, а тот, кто применил результат её работы, — соразмерно степени своей вины.
Как это выглядит на практике, показало дело № А27-7831/2025. Кемеровская компания «Центральный Спец Сервис» (ЦСС) подала кассационную жалобу в Арбитражный суд Западно-Сибирского округа со ссылками на судебные акты Верховного и Высшего арбитражного судов. При проверке выяснилось: часть этих решений вообще не существует, а часть вынесена по совершенно другим спорам. Судя по всему, ссылки сгенерировала нейросеть. Как сообщили СМИ со ссылкой на определение от 14 мая 2026 года, суд расценил это как предоставление заведомо ложных сведений и проявление неуважения к правосудию — и наложил на компанию судебный штраф 50 000 ₽. Разбор этого дела с точки зрения архитектуры процесса — в отдельной статье.
Здесь важно не перепутать два разных вида ответственности. То, что произошло с «ЦСС», — это процессуальный штраф: санкция суда за недостоверные сведения в конкретном деле, наложенная на сторону процесса. С обязательствами LegalTech-сервиса перед клиентом это не связано. Другая история — если ваш B2B-продукт выдал клиенту неверную аналитику или ошибочную рекомендацию из-за такой же «галлюцинации», а клиент от этого потерял деньги или сорвал сделку. Тогда это гражданско-правовая ответственность: убытки, некачественная услуга и то, что написано (или не написано) в пользовательском соглашении о её границах.
Для архитектуры продукта вывод один и тот же в обоих случаях: без Triage Logic и матрицы Red Flags, которые останавливают автоматику там, где цена ошибки высока, бизнес рискует реальными деньгами уже сегодня, а не с 2027 года.
Карта регуляторов: кто может спросить с вашего сервиса
Даже без отдельного закона об ИИ у LegalTech- и FinTech-продукта уже есть реальные регуляторы — в зависимости от того, что именно он делает.
- Роскомнадзор (152-ФЗ) — если сервис вообще собирает пользовательские данные, что верно почти для любого продукта. Особенно чувствительная зона — передача персональных данных в API сторонней ИИ-модели без обезличивания. Реальная цена такой утечки — в отдельном разборе.
- Росфинмониторинг (115-ФЗ) — если в продукте есть KYC/AML-логика: проверка клиентов, скрининг по спискам. Разбирали это подробно на примере необанка в статье о разграничении архитектора и разработчика.
- Центробанк — для финтех-продуктов выбрал мягкое регулирование: рекомендации, а не жёсткие требования. Обсуждает реестры участников ИИ-решений, но пока они не обязательны.
- Роспотребнадзор — если продукт работает с конечным потребителем (B2C), а не только с бизнесом: отвечает по общим правилам закона о защите прав потребителей за качество услуги — в том числе если её оказал алгоритм, а не человек.
Инструменты защиты: песочница для крупных, архитектура для всех
Один инструмент часто упоминают как «легальный способ протестировать рискованную гипотезу» — экспериментальный правовой режим (ЭПР) по 258-ФЗ, обновлённому в июне 2026 года. Механизм рабочий: закон даже отдельно оговаривает порядок рассмотрения случаев вреда от решений на основе ИИ в рамках такого режима (ст. 18.1). Но важно понимать его реальный масштаб: по официальному регламенту Минэкономразвития только на рассмотрение заявки у регулятора уходит 30 рабочих дней — и это без учёта времени на её подготовку. ЭПР — это инструмент для серьёзных, институционального масштаба гипотез (например, автоматической выдачи займов без участия человека), а не быстрый способ протестировать MVP за две недели.
Для подавляющего большинства LegalTech- и FinTech-стартапов реальная защита — не в специальном правовом режиме, а в архитектуре самого продукта: Triage Logic, которая заранее решает, что автоматика может делать сама, а что обязана передавать человеку, и матрица Red Flags как жёсткий стоп-кран там, где цена ошибки высока.
Чек-лист due diligence перед инвестраундом
Пять вопросов для due diligence, которые стоит задать фаундеру до подписания term sheet — независимо от того, на какой стадии продукт:
- Кто спроектировал юридическую логику продукта — независимый специалист или та же команда, что писала код? Если модель работает по принципу «сами придумали правила — сами их проверили», это риск для инвестора (разбирали в статье об архитекторе и разработчике).
- Есть ли в продукте Red Flags и точки эскалации на человека — или автоматика решает всё сама без стоп-кранов?
- Что именно защищено как интеллектуальная собственность: код и JSON-схемы логики (авторское право) и калибровочный датасет (право на базу данных)? Или команда пытается защитить сам промпт, который правовой охраны не получает?
- Как устроена изоляция персональных данных при передаче в API сторонней модели — данные обезличиваются или уходят как есть?
- Прописаны ли в пользовательском соглашении границы ответственности сервиса за решения, принятые алгоритмом?
Часто задаваемые вопросы
Значит ли отсутствие специального закона об ИИ, что продукт можно не проверять на юридические риски? Нет. Специального закона для API-продуктов пока нет, но общие нормы — Гражданский кодекс, 152-ФЗ, 115-ФЗ, ответственность перед клиентом — действуют в полном объёме уже сейчас, и первый судебный прецедент это подтвердил.
Что грозит компании, если её ИИ-сервис «галлюцинирует» и это доходит до клиента? Зависит от контекста. Если ошибка попала в судебный документ — процессуальный штраф, как в деле «ЦСС». Если сервис выдал клиенту ошибочный результат и это причинило убытки — гражданско-правовая ответственность, объём которой сильно зависит от того, что прописано в пользовательском соглашении.
Стоит ли стартапу заходить в экспериментальный правовой режим (ЭПР)? Для большинства ранних стартапов — нет: это тяжёлый институциональный инструмент, а не быстрый способ протестировать MVP. Разумнее сначала заложить архитектурные предохранители — Triage Logic и Red Flags.
С чего начать инвестору, который должен провести due diligence LegalTech-стартапа? Зависит от стадии: если продукт уже собран и сделка готовится — начните с формата Audit & Second Opinion: это экспресс-проверка существующей логики и пользовательской оферты перед передачей инвестору. Если инвестиции берутся на сборку ядра с нуля — это уже Core Architecture & Triage Logic.
Планируете инвестировать в LegalTech- или FinTech-продукт с ИИ внутри, или сами его строите? Посмотрите, как устроена юридическая архитектура — форматы работы, включая независимый аудит перед сделкой.