Брошюра · Библиотека ДИС

Искусственный интеллект в правовом поле

Помогает проверить AI-проект на правовые риски, безопасно работать с данными и защитить цифровой бренд.

Автор: Степанов Д.А. Дата: 17.09.2026 ✓ Опубликовано

Искусственный интеллект в правовом поле

История развития Правила безопасного применения Защита цифрового бренда

Практическая брошюра для AI-специалистов, разработчиков и владельцев цифровых проектов

Степанов Д.А.

2026

О брошюре

Эта брошюра объясняет, как развивалась идея искусственного интеллекта, какие правовые требования возникают при создании и применении AI-систем и как защищать результаты работы, данные и цифровой бренд. Она предназначена для специалистов, которые используют нейросети в разработке, медицине, образовании, маркетинге, аналитике и бизнес-процессах.

Главный вывод прост: искусственный интеллект не находится в правовом вакууме. Даже при отсутствии единого универсального закона к конкретному проекту применяются нормы об информации, персональных данных, интеллектуальной собственности, рекламе, защите потребителей, договорных обязательствах и отраслевой безопасности. Чем выше возможные последствия ошибки, тем строже должны быть проверка, документирование и человеческий контроль.

Материал отражает состояние источников на 17 сентября 2026 года и носит информационный характер. Он не заменяет юридическое заключение по конкретной ситуации. При работе с медицинскими данными, биометрией, международной передачей информации, регистрацией товарного знака и коммерческими договорами необходима проверка профильным специалистом.

Как пользоваться брошюрой

  • Главы 1 и 2 дают историческую и техническую основу без излишней математики.
  • Главы 3-5 описывают российское правовое поле, работу с данными и интеллектуальные права.
  • Глава 6 содержит самостоятельный план защиты бренда «ДИС» и других цифровых обозначений.
  • Главы 7-9 помогают оформить договор, сравнить международные подходы и провести проверку проекта перед запуском.
  • Словарь и список литературы можно использовать как справочный раздел и основу для дальнейшего обучения.

Содержание

1. От механических вычислений к генеративному ИИ

2. Как устроен современный искусственный интеллект

3. Искусственный интеллект в правовом поле России

4. Персональные данные и информационная безопасность

5. Интеллектуальные права в AI-проектах

6. Защита бренда и цифровой идентичности

7. Договоры, приёмка и ответственность

8. Российская и мировая практика регулирования

9. Проверка AI-проекта перед запуском

10. Заключение

11. Словарь

12. Литература и официальные источники

1 От механических вычислений к генеративному ИИ

1.1 Почему история начинается раньше самого термина

Выражение «искусственный интеллект» закрепилось только в середине XX века, однако его интеллектуальная история начинается значительно раньше. В течение почти двух столетий математики, инженеры и философы постепенно формулировали идеи, без которых современные нейронные сети были бы невозможны: представление рассуждения в виде правил, механизация вычислений, вероятностное описание процессов, обратная связь и обучение на примерах.

Поэтому период в 150-200 лет следует рассматривать не как непрерывную историю готового искусственного интеллекта, а как последовательность предпосылок. Сначала человек научился превращать вычисление в программу, затем - описывать логические операции математически, после этого - моделировать передачу информации и работу нейронов, и только затем появились системы, которые обучаются по данным.

1.2 Бэббидж и Лавлейс

В XIX веке Чарльз Бэббидж разработал проекты разностной и аналитической машин. Аналитическая машина не была завершена при его жизни, но в её архитектуре уже различались устройство вычисления, память и способ задания последовательности операций. Это было принципиально важным переходом от отдельного механического калькулятора к универсальной вычислительной машине.

Ада Лавлейс в примечаниях 1843 года описала алгоритм для аналитической машины и одновременно сформулировала ограничение, которое остаётся актуальным в дискуссиях об ИИ: машина выполняет те операции, которые человек способен выразить в правилах. Современные модели значительно сложнее прямой программы, однако вопрос о границах машинного творчества, авторстве и человеческом контроле возник задолго до появления компьютеров.

1.3 Логика, вероятность и информация

Джордж Буль показал, что логические утверждения можно представить алгебраически. Позднее работы Готлоба Фреге и других логиков создали формальный язык рассуждения. Андрей Марков исследовал последовательности зависимых событий; цепи Маркова стали важным инструментом вероятностного моделирования и сохраняют значение в машинном обучении.

В 1948 году Клод Шеннон предложил математическую теорию информации. Она дала количественный язык для описания передачи сигналов, неопределённости и кодирования. В том же году Норберт Винер опубликовал книгу о кибернетике, где управление рассматривалось через обратную связь. Эти идеи связали вычисление с наблюдением, реакцией и адаптацией.

1.4 Первые модели нейронов и тест Тьюринга

В 1943 году Уоррен Маккаллок и Уолтер Питтс описали математическую модель нейрона, который получает входные сигналы и формирует выход при достижении порога. Эта упрощённая конструкция показала, что сеть элементарных единиц способна реализовывать логические функции. Работа стала одной из исходных точек нейросетевого подхода.

В 1950 году Алан Тьюринг предложил заменить неопределённый вопрос «может ли машина мыслить» проверяемой процедурой общения. Тест Тьюринга не является универсальным доказательством интеллекта, но он изменил постановку проблемы: вместо спора о природе сознания появился эксперимент с наблюдаемым поведением системы.

1.5 Рождение научной области

В предложении к Дартмутскому летнему исследовательскому проекту 1955 года Джон Маккарти, Марвин Минский, Натаниэль Рочестер и Клод Шеннон исходили из предположения, что элементы обучения и интеллекта можно описать настолько точно, чтобы машина могла их воспроизвести. Летняя школа 1956 года обычно рассматривается как момент оформления искусственного интеллекта в самостоятельную область.

Ранние программы решали логические задачи, играли в игры и доказывали теоремы. Параллельно Фрэнк Розенблатт развивал перцептрон - обучаемую модель распознавания. Первоначальный оптимизм оказался чрезмерным: вычислительных ресурсов и данных не хватало, а возможности простых моделей были ограничены. Периоды роста ожиданий сменялись так называемыми зимами ИИ, когда финансирование и интерес сокращались.

1.6 Экспертные системы и возвращение нейронных сетей

В 1970-1980-е годы широкое распространение получили экспертные системы. Их знания задавались правилами вида «если - то». Такие решения были полезны в узких областях, но дорого поддерживались: каждое новое исключение приходилось формализовать вручную, а знания экспертов быстро устаревали.

В 1986 году Дэвид Румельхарт, Джеффри Хинтон и Рональд Уильямс популяризировали обучение многослойных сетей методом обратного распространения ошибки. Сочетание новых алгоритмов, больших массивов данных и графических процессоров позднее привело к подъёму глубокого обучения. Система перестала зависеть только от вручную заданных правил и стала извлекать сложные закономерности из примеров.

1.7 Трансформеры и генеративные модели

Архитектура Transformer, представленная в 2017 году, позволила модели учитывать связи между элементами последовательности с помощью механизма внимания. Это упростило параллельное обучение на больших корпусах и стало основой современных больших языковых моделей. Такие модели не извлекают готовую фразу из единого справочника, а вероятностно формируют продолжение на основе усвоенных закономерностей.

Генеративный ИИ может создавать текст, изображения, звук, видео и программный код. Однако убедительная форма ответа не гарантирует истинность. Модель способна смешать факты, использовать устаревшую информацию или придумать ссылку. Исторический переход от правил к вероятностной генерации увеличил гибкость систем, но одновременно сделал необходимыми новые способы проверки.

ПериодКлючевая идеяПрактическое значение
1830-1870-еПрограммируемая машина и формальная логикаВычисление можно выразить последовательностью операций
1900-1940-еВероятность, информация, модель нейронаПоявился математический язык для адаптивных систем
1950-1970-еИИ как научная областьЛогические программы, поиск и перцептрон
1970-1990-еЭкспертные системы и обучение сетейПереход от фиксированных правил к обучению
2000-2010-еБольшие данные и глубокое обучениеРост качества распознавания и прогнозирования
2017-2026Трансформеры, LLM и AI-агентыГенерация, работа с инструментами и автоматизация процессов

История ИИ показывает, что ни один технологический скачок не возник изолированно. Современная генеративная модель объединяет идеи программируемого вычисления, формальной логики, вероятности, теории информации, нейронных сетей и масштабного обучения. Поэтому оценивать её следует одновременно как технический инструмент и как часть человеческого процесса принятия решений.

2 Как устроен современный искусственный интеллект

2.1 Система, а не волшебная модель

В практическом проекте искусственный интеллект - это не одна нейросеть. Результат формируется всей системой: источниками данных, способом подготовки информации, моделью, системным промптом, программным кодом, подключёнными инструментами, правилами доступа, интерфейсом, журналированием и действиями человека. Ошибка в любой части может изменить итоговый ответ.

Поэтому правовая и техническая оценка должна охватывать полный жизненный цикл. Недостаточно узнать название модели. Необходимо понимать, какие данные ей передаются, где они обрабатываются, как долго хранятся, на основании каких документов формируется ответ, кто его проверяет и какое действие выполняется после генерации.

2.2 Основные понятия

Модель машинного обучения выявляет зависимости в данных и использует их для прогноза или генерации. Обучение - процесс настройки параметров модели на примерах. Инференс - применение уже обученной модели к новому запросу. Датасет - организованный набор данных, который может использоваться для обучения, тестирования или поиска информации.

Большая языковая модель, или LLM, работает с последовательностями токенов. Она умеет продолжать текст, отвечать на вопросы, преобразовывать формат и следовать инструкции. При этом модель не обладает гарантированным доступом к актуальной реальности. Её ответ нужно рассматривать как вычисленный вариант, а не как автоматически подтверждённый факт.

2.3 Промпт, RAG и инструменты

Промпт задаёт роль модели, цель, ограничения, порядок действий и форму результата. Хороший промпт не устраняет все ошибки, но делает поведение более предсказуемым. Для производственного применения полезно фиксировать версию промпта, допустимые входные данные, требуемую схему ответа, правила отказа и условия передачи человеку.

RAG дополняет модель поиском по контролируемой базе знаний. Сначала система извлекает релевантные фрагменты, затем передаёт их модели для подготовки ответа. Такой подход особенно полезен при работе с внутренними документами, нормативными материалами и регулярно обновляемой информацией. RAG не заменяет точный запрос к базе данных, когда требуется конкретное значение или транзакционная запись.

AI-агент получает возможность выбирать действия и вызывать инструменты: искать документы, создавать записи, обращаться к CRM или запускать workflow. Чем больше у агента полномочий, тем выше риск. Безопасная архитектура разделяет чтение, подготовку предложения, одобрение и исполнение. Удаление, публикация, платёж, медицинское или юридически значимое решение не должны выполняться без предусмотренного контроля.

2.4 Галлюцинации и неопределённость

Галлюцинацией называют правдоподобный, но недостоверный результат генерации. В юридическом тексте это может быть несуществующая статья закона, неверный номер документа или вымышленное судебное решение. В медицине - неподтверждённая дозировка, смешение рекомендаций разных стран или пропуск противопоказания. В разработке - ссылка на функцию, которой нет в используемой версии библиотеки.

Причина не сводится к невнимательности модели. Вероятностная генерация оптимизирует связность продолжения, а не юридическую силу или фактическую истинность каждого предложения. Поэтому система должна уметь указывать источники, сообщать об отсутствии данных и отказываться от окончательного вывода там, где доказательств недостаточно.

2.5 Человеческий контроль

Human-in-the-loop - это не декоративная кнопка «проверено». Для каждого значимого результата нужно определить компетентного проверяющего, предмет проверки, срок, доступ к первичным данным и ответственность за окончательное решение. Врач должен проверять медицинскую рекомендацию, юрист - правовую позицию, редактор - публичный материал, а оператор - действие в CRM.

Контроль необходимо документировать. Система должна сохранять исходный запрос, использованные источники, версию модели и промпта, результат, исправления и данные о лице, которое одобрило действие. Такой журнал помогает расследовать ошибку и улучшать процесс, а также снижает риск того, что ответственность будет необоснованно переложена на абстрактный «алгоритм».

КомпонентРискКонтроль
ДанныеНезаконное получение, утечка, устареваниеОснование обработки, минимизация, актуализация
МодельГаллюцинации, смещение, непрозрачностьТестовый набор, пороги качества, резервный сценарий
ПромптКонфликт инструкций, обход ограниченийВерсионирование, тесты, запреты и эскалация
RAGНеверный поиск или чужой документМетаданные, разграничение доступа, проверка цитат
ИнструментыНеправильное внешнее действиеМинимальные права, схема аргументов, одобрение
ЧеловекАвтоматическое доверие ответуОбучение, чек-лист и персональная ответственность

Практически полезный AI-проект начинается с минимально достаточной автоматизации. Если задача решается обычным правилом или запросом к базе данных, модель не нужна. Нейросеть добавляется там, где требуется работа с неструктурированным текстом, вариативность формулировок или анализ контекста, а её полномочия ограничиваются проверяемыми действиями.

3 Искусственный интеллект в правовом поле России

3.1 Нет единого закона не означает нет правил

Российское регулирование искусственного интеллекта формируется поэтапно. Национальная стратегия определяет направление развития, экспериментальные режимы позволяют проверять отдельные решения, а обязательные требования возникают из уже действующих отраслей права. Проект оценивается не по словам «нейросеть» или «AI», а по совершаемым действиям и последствиям.

Если система собирает сведения о человеке, применяются правила о персональных данных. Если создаёт рекламный материал - требования к рекламе. Если использует чужой текст, изображение или код - нормы интеллектуальной собственности и условия лицензии. Если формирует медицинскую рекомендацию - отраслевые требования к медицинской деятельности, качеству и безопасности. Если действие предусмотрено договором - правила об обязательствах и ответственности.

3.2 Национальная стратегия

Указ Президента Российской Федерации от 10 октября 2019 года № 490 утвердил Национальную стратегию развития искусственного интеллекта до 2030 года. В 2024 году стратегия была обновлена. В документе искусственный интеллект рассматривается как комплекс технологических решений, позволяющий имитировать когнитивные функции человека и получать результаты, сопоставимые с результатами интеллектуальной деятельности человека.

Стратегия относится к документам государственного планирования. Она задаёт цели развития науки, инфраструктуры, кадров, данных, доверенных технологий и нормативного регулирования, но сама по себе не заменяет специальные обязанности, установленные законами. Для практического проекта стратегический документ нужно читать вместе с нормами о данных, информации, договорах, безопасности и правах на результаты.

3.3 Экспериментальные правовые режимы

Федеральный закон № 123-ФЗ создал специальный эксперимент по применению технологий искусственного интеллекта в Москве. Федеральный закон № 258-ФЗ установил общую конструкцию экспериментальных правовых режимов в сфере цифровых инноваций. Их смысл состоит в том, чтобы ограниченно проверять новые технологии при заранее определённых условиях, контроле и оценке рисков.

Экспериментальный режим нельзя понимать как общее освобождение от законодательства. Участник действует только в пределах установленной программы, территории, срока и перечня исключений. Требования к безопасности, защите прав граждан и расследованию причинённого вреда сохраняют значение.

3.4 Основные правовые блоки

  • Федеральный закон № 149-ФЗ - информация, информационные технологии и защита информации.
  • Федеральный закон № 152-ФЗ - обработка и защита персональных данных.
  • Часть четвёртая Гражданского кодекса РФ - авторские права, программы, базы данных и товарные знаки.
  • Федеральный закон № 98-ФЗ - коммерческая тайна.
  • Федеральный закон № 38-ФЗ - требования к рекламе.
  • Закон РФ № 2300-1 - права потребителей.
  • Трудовое, административное и уголовное законодательство - в зависимости от применения.
  • Специальные требования медицины, образования, финансов, транспорта и государственного управления.

3.5 Риск-ориентированный подход

Уровень контроля должен соответствовать возможному вреду. Генератор вариантов заголовка и система, влияющая на диагноз, не могут регулироваться одинаково. При оценке полезно учитывать чувствительность данных, обратимость решения, масштаб пользователей, возможность дискриминации, последствия ошибки и способность человека своевременно вмешаться.

Для низкорисковой функции достаточно редакторской проверки и журнала версий. Для работы с персональными данными требуются правовое основание, минимизация, разграничение доступа и безопасность. Для медицинского, финансового или кадрового решения необходимы валидация, квалифицированный человек, объяснимый порядок проверки и механизм обжалования.

3.6 Официальные источники

Юридическую информацию необходимо сверять по официальным публикациям. Ссылка на закон должна содержать правильное название, номер, дату и действующую редакцию. Ответ нейросети, учебный слайд, пост или справочная статья могут помочь найти направление, но не подтверждают существование нормы.

1. Проверить, существует ли документ и официально ли он опубликован.

2. Установить, действует ли документ на нужную дату.

3. Проверить редакцию и переходные положения.

4. Сопоставить цитируемую статью с оригинальным текстом.

5. Проверить, действительно ли норма относится к рассматриваемой ситуации.

4 Персональные данные и информационная безопасность

4.1 Что считается персональными данными

Персональные данные - любая информация, относящаяся прямо или косвенно к определённому или определяемому физическому лицу. Это не только паспорт, телефон или адрес. В зависимости от контекста к персональным данным могут относиться IP-адрес, идентификатор устройства, фотография, голос, сведения о работе, история обращений и комбинация признаков, позволяющая установить человека.

В медицинском проекте особую чувствительность имеют сведения о состоянии здоровья. Биометрические данные используются для установления личности по физиологическим и биологическим особенностям. Категория определяется не названием поля, а целью и способом использования информации.

4.2 Роли участников

Оператор определяет цели и способы обработки персональных данных. Исполнитель или облачный сервис может обрабатывать данные по поручению оператора. В договоре необходимо указать перечень данных, операции, цели, меры защиты, конфиденциальность, порядок уведомления об инцидентах и действия после прекращения обработки.

Использование внешней AI-платформы не переносит всю ответственность на поставщика. Организация, которая решила отправить данные в сервис, должна оценить законность передачи, условия использования, место обработки, сроки хранения, возможность обучения модели на запросах и права доступа сотрудников поставщика.

4.3 Минимизация данных

Безопасный проект начинает не с вопроса «куда загрузить базу», а с вопроса «какие сведения действительно необходимы». Если задачу можно решить без имени, телефона или полной медицинской истории, эти данные не следует передавать модели. Удаление лишних полей снижает юридический и технический риск.

Обезличивание должно препятствовать идентификации лица без использования дополнительной информации. Простая замена имени на номер не всегда достаточна: редкое заболевание, возраст, место работы и дата обращения в совокупности могут раскрыть человека. Дополнительная таблица соответствий хранится отдельно с ограниченным доступом.

4.4 Локализация и трансграничная передача

Перед подключением зарубежного сервиса необходимо определить, в какой стране находятся серверы и субподрядчики, происходит ли трансграничная передача, какие уведомления и правовые основания требуются, а также возможно ли выполнить российские требования локализации. Эти вопросы проверяются до загрузки реальных данных, а не после запуска.

Если правовая и техническая схема не подтверждена, для прототипа используют синтетические, тестовые или надёжно обезличенные данные. Перенос проекта в промышленную эксплуатацию допускается только после документирования потоков данных и мер защиты.

4.5 Практическая модель защиты

ЭтапВопросДокумент или контроль
СборЗачем нужны эти сведения?Цель, основание, уведомление или согласие
ПередачаКому и куда уходят данные?Схема потоков, договор, оценка трансграничной передачи
ОбработкаКакие действия выполняет AI?Регламент, минимизация, ограничение промпта
ХранениеКак долго и где сохраняются данные?Сроки, шифрование, резервные копии
ДоступКто видит данные и ответы?Роли, аутентификация, журнал доступа
УдалениеКак завершить обработку?Порядок удаления и подтверждение исполнения
ИнцидентЧто делать при утечке или ошибке?План реагирования, уведомления, расследование

4.6 Информационная безопасность

AI-система добавляет к обычным угрозам новые сценарии: извлечение секретов через промпт, внедрение вредоносной инструкции в документ, утечку контекста между пользователями, чрезмерные полномочия агента и небезопасную обработку результата модели. Текст из интернета, письма или загруженного файла следует считать недоверенным вводом.

Практические меры включают изоляцию секретов, минимальные права сервисных аккаунтов, разрешённый список инструментов, проверку аргументов, лимиты запросов и стоимости, журналирование, резервный сценарий и возможность быстро отключить интеграцию. Модель не должна получать ключи API внутри пользовательского промпта.

5 Интеллектуальные права в AI-проектах

5.1 Какие объекты встречаются в проекте

AI-проект объединяет несколько результатов: программный код, базу данных, дизайн, тексты, изображения, аудио, видео, промпты, методические материалы и товарное обозначение. Для каждого элемента нужно установить автора или правообладателя, основание использования и условия передачи заказчику.

Нельзя описывать весь проект одной фразой «права принадлежат заказчику», если часть компонентов поставляется по открытым лицензиям, часть - сторонними API, а часть создана сотрудниками и подрядчиками. Реестр компонентов помогает разделить собственные разработки, лицензированные материалы и сервисы, доступные только на условиях подписки.

5.2 Исходные материалы и обучение

Публикация материала в интернете не означает разрешение на любое использование. Текст, изображение, музыка, код и база данных могут охраняться независимо от удобства технического копирования. Перед использованием в датасете, RAG-базе или рекламном материале проверяются лицензия, цель, объём и условия доступа.

Особое внимание требуется к внутренним документам клиента. Даже если компания обладает экземпляром файла, это не всегда означает право передавать его внешней модели или использовать для обучения. Помимо авторского права могут действовать режим коммерческой тайны, договорная конфиденциальность и требования о персональных данных.

5.3 Результаты генерации

Правовой режим AI-результата зависит от юрисдикции, степени человеческого творческого вклада и характера исходных материалов. Поэтому рискованно обещать заказчику безусловное исключительное право на любой сгенерированный объект. В договоре следует описывать процесс: кто формирует задание, кто отбирает варианты, кто перерабатывает результат и кто проверяет отсутствие очевидного копирования.

Чем больше самостоятельного творческого вклада человека - композиции, отбора, редактирования и переработки, - тем проще документировать авторский результат. Сохранение версий, исходников и истории правок важно не только для качества, но и для доказательства процесса создания.

5.4 Код и открытые лицензии

Генерация программного кода не отменяет лицензионную проверку. В проекте необходимо учитывать зависимости, условия open source, уведомления об авторстве, требования раскрытия исходного кода и совместимость лицензий. Автоматическая проверка состава программного обеспечения дополняет, но не заменяет анализ спорных компонентов.

Заказчику передают не только архив с кодом, но и перечень зависимостей, инструкции по развёртыванию, лицензионные уведомления, список внешних сервисов и ограничения. Если решение перестаёт работать без платного API, это должно быть явно указано в документации и смете эксплуатации.

5.5 Практический реестр прав

ОбъектИсточникОснованиеЧто фиксировать
КодСотрудник, подрядчик, open sourceТрудовой договор, отчуждение, лицензияАвтор, репозиторий, версия, лицензия
ДанныеКлиент, открытый источник, партнёрСогласие, договор, открытая лицензияПроисхождение, цель, ограничения
Текст и графикаАвтор, AI-сервис, фотобанкАвторское право, лицензия, условия сервисаИсходники, промпты, редактура
МодельПоставщик или собственная разработкаAPI-условия или исключительное правоВерсия, запреты, место обработки
БрендВладелец проектаТоварный знак и авторские праваСвидетельство, классы, доказательства использования

5.6 Что передавать заказчику

При завершении проекта заказчику передаются не только готовый интерфейс и пароль. Комплект должен включать исходный код в согласованном объёме, инструкции по запуску, перечень внешних сервисов, лицензионный реестр, структуру базы знаний, версии промптов, результаты тестов и сведения о необходимых подписках.

Передача оформляется актом с перечнем файлов и доступов. Секреты и ключи передаются защищённым способом, после чего временные доступы исполнителя отзываются. Такой порядок уменьшает зависимость от конкретного разработчика и подтверждает, какие результаты фактически получил заказчик.

6 Защита бренда и цифровой идентичности

6.1 Бренд состоит из нескольких объектов

Бренд - это не только логотип. Для проекта «ДИС» охране могут подлежать название, линейка обозначений «ДИС 360», графическое исполнение, маскот, фирменные шаблоны, домены, аккаунты, тексты, видеоролики, интерфейс и программный код. Каждый объект защищается собственным механизмом, поэтому одной регистрации недостаточно.

Товарный знак защищает обозначение для выбранных товаров и услуг. Авторское право может охранять оригинальную графику, текст, фотографию, видео и код. Домен и имя аккаунта требуют организационного контроля. Коммерческая тайна защищает конфиденциальные материалы при введённом режиме. Договор закрепляет передачу прав от дизайнера, автора или разработчика.

6.2 Инвентаризация активов ДИС

АктивПредполагаемая защитаПервое действие
ДИССловесный товарный знакПроверить различительную способность и сходные знаки
ДИС 360 и названия продуктовОтдельные словесные или комбинированные знакиВыделить реально используемые обозначения
ЛоготипКомбинированный знак и авторское правоСохранить исходник и договор с дизайнером
МаскотАвторское право, при необходимости товарный знакОписать персонажа, версии и разрешённое использование
Сайт и интерфейсАвторское право на элементы и кодЗафиксировать авторов и передачу прав
Домены и аккаунтыРегистрация и административный контрольОформить на владельца бренда, включить 2FA
Методики и материалыАвторское право, договоры, режим доступаВести архив публикаций и исходных файлов

6.3 Предварительный поиск

Перед подачей заявки проводится поиск по зарегистрированным товарным знакам и заявкам. Проверяются не только полные совпадения, но и сходные по звучанию, написанию и смыслу обозначения в однородных товарах и услугах. Короткое обозначение «ДИС» может иметь повышенный риск совпадений, поэтому предварительный поиск обязателен.

Параллельно проверяются фирменные наименования, домены, социальные сети, магазины приложений и маркетплейсы. Цель этапа - не выдать абсолютную гарантию, а заранее увидеть препятствия и решить, какую форму обозначения регистрировать: словесную, графическую или комбинированную.

6.4 Правообладатель и архитектура бренда

До регистрации нужно определить владельца. Товарный знак может быть оформлен на индивидуального предпринимателя или юридическое лицо; выбор должен соответствовать тому, кто реально заключает договоры и развивает продукты. Если бренд используется несколькими проектами, права оформляются централизованно, а другим участникам предоставляются лицензии.

Архитектура «ДИС» должна различать главный бренд и продуктовые названия. Главный знак формирует узнаваемость, а обозначения «ДИС Аналитик 360», «ДИС Репутация 360», «ДИС Lingua 360» и другие используются как названия решений. Регистрировать сразу все возможные варианты дорого и не всегда полезно; приоритет получают фактически используемые и коммерчески значимые обозначения.

6.5 Классы МКТУ

Товарный знак действует в отношении указанных товаров и услуг. Для цифровой экосистемы «ДИС» предварительно могут рассматриваться классы 9, 35, 41 и 42, а для самостоятельного медицинского направления - класс 44. Однако номер класса не заменяет точного перечня. Слишком узкий перечень оставит важные услуги без защиты, а чрезмерно широкий увеличит затраты и риск неиспользования.

  • Класс 9 - загружаемое программное обеспечение и цифровые продукты.
  • Класс 35 - деловое консультирование, маркетинг и обработка коммерческой информации.
  • Класс 41 - обучение, публикации и образовательные программы.
  • Класс 42 - разработка ПО, технологическое проектирование и AI-консалтинг.
  • Класс 44 - медицинские услуги, если они оказываются под данным обозначением.

6.6 Регистрация в Роспатенте

1. Зафиксировать владельца и утверждённое изображение обозначения.

2. Сформировать перечень товаров и услуг по выбранным классам.

3. Провести предварительный поиск и оценить сходство.

4. Подать заявку и сохранить подтверждение приоритета.

5. Ответить на запросы экспертизы в установленные сроки.

6. После положительного решения уплатить пошлины и получить свидетельство.

7. Вести календарь продления и хранить доказательства использования.

Разумная последовательность для «ДИС»: сначала оценить словесное обозначение как основу всей линейки, затем решить вопрос с комбинированным знаком и логотипом. Если словесный знак сталкивается с препятствиями, графическое решение не всегда устраняет риск, но может предоставить охрану конкретной композиции.

6.7 Авторские права и договоры

Логотип, маскот, видеоролик или дизайн могут охраняться с момента создания при наличии творческого характера, но принадлежность прав нужно доказать. Если работу выполнял подрядчик, договор должен содержать условие об отчуждении исключительного права либо понятную лицензию. Оплата услуги сама по себе не всегда означает передачу всех прав.

Хранятся техническое задание, договор, акт, исходные файлы, переписка, версии и сведения об авторе. Для произведений, созданных сотрудником, фиксируются служебное задание и связь результата с трудовыми обязанностями. Для AI-материалов дополнительно сохраняются промпт, варианты, человеческий отбор и редактура.

6.8 Домены, аккаунты и безопасность

Домены и аккаунты регистрируются на контролируемые владельцем реквизиты, а не на личную почту случайного подрядчика. Используются двухфакторная аутентификация, резервные коды, корпоративный менеджер паролей и перечень администраторов. При увольнении или завершении договора доступы отзываются по чек-листу.

Полезно заранее зарегистрировать ключевые варианты домена и имён аккаунтов, но не следует создавать десятки неуправляемых профилей. Единый реестр должен содержать площадку, адрес, владельца учётной записи, способ восстановления и дату последней проверки.

6.9 Защита на маркетплейсах и площадках

При копировании названия, карточки, изображения или описания сначала фиксируется доказательство: адрес страницы, дата, скриншоты, карточка продавца, контрольная покупка при необходимости. Затем определяется, какое право нарушено: товарный знак, авторское право, правила конкуренции или условия самой площадки.

Жалоба должна быть конкретной. В ней указываются правообладатель, регистрационные документы, спорный объект, ссылка, характер нарушения и требуемое действие. Если площадка не реагирует или нарушение причинило существенный вред, рассматриваются претензия, обращение в компетентный орган и судебная защита. Порядок зависит от страны и площадки.

6.10 Международная охрана

Российская регистрация действует на территории Российской Федерации. Для выхода в другие страны составляется перечень приоритетных рынков, проверяется обозначение и выбирается национальная подача либо Мадридская система. Международная заявка не создаёт единого безусловного права во всём мире: каждое указанное ведомство оценивает знак по своему законодательству.

До международного продвижения также проверяются домены, локальные значения слова, транслитерация и требования к рекламе. Особое внимание уделяется тому, совпадает ли фактическое использование с зарегистрированным перечнем товаров и услуг.

6.11 План защиты ДИС на 90 дней

СрокДействиеРезультат
1-15 дниИнвентаризация названий, логотипов, доменов, авторов и договоровРеестр активов и пробелов
16-30 дниПредварительный поиск «ДИС» и продуктовых названийКарта совпадений и решение по заявке
31-45 дниУтверждение владельца, классов и перечня услугГотовый комплект для подачи
46-60 дниПодача приоритетной заявки и упорядочивание договоровДата приоритета и цепочка прав
61-75 дниЗащита доменов, аккаунтов и доступовРеестр учётных записей и 2FA
76-90 дниНастройка мониторинга и шаблона претензииРегламент реагирования на нарушения

Результатом 90-дневного этапа должна стать не только поданная заявка, но и управляемая система: понятный владелец, единый реестр активов, подтверждённая цепочка прав, защищённые аккаунты и заранее подготовленный порядок реагирования. После этого мониторинг включается в обычный цикл управления брендом.

7 Договоры приёмка и ответственность

7.1 Правильный вид договора

Договор подряда ориентирован на создание и передачу результата, а договор оказания услуг - на совершение согласованных действий. В AI-проекте отношения часто смешанные: исполнитель анализирует процесс, создаёт программный модуль, настраивает сторонние сервисы, передаёт документацию и оказывает поддержку. Поэтому содержание важнее названия договора.

Предмет должен отвечать на вопрос, что именно обязан сделать исполнитель. Формулировка «создать умного бота» непригодна для приёмки. Нужно перечислить сценарии, интеграции, ограничения, входные и выходные данные, среду размещения и документы, которые передаются заказчику.

7.2 Техническое задание

Техническое задание превращает ожидания в проверяемые условия. Оно описывает роли пользователей, нормальный процесс, исключения, объём данных, производительность, безопасность, интерфейс, журналирование и порядок обновления. Отдельно фиксируются неподдерживаемые функции, чтобы демонстрационный прототип не воспринимался как готовая промышленная система.

  • Перечень пользовательских сценариев и допустимых запросов.
  • Источники знаний и порядок их обновления.
  • Требуемая структура ответа и поведение при отсутствии данных.
  • Разрешённые интеграции, модели и внешние сервисы.
  • Метрики качества, тестовый набор и критерии приёмки.
  • Требования к доступу, журналам, резервному копированию и восстановлению.
  • Условия передачи оператору и остановки автоматического действия.

7.3 Приёмка AI-системы

Нельзя обещать, что вероятностная модель всегда даст «правильный ответ». Приёмка строится на представительном наборе тестов и измеримых критериях. Проверяются обычные, сложные, неоднозначные, некорректные и потенциально вредоносные запросы. Результат оценивается по фактической точности, полноте, безопасности, соблюдению схемы и способности отказаться от ответа.

В договоре фиксируется версия модели, промпта и базы знаний, на которых проводилось испытание. Иначе обновление поставщика может изменить поведение системы после подписания акта. Для существенных изменений предусматривается повторная проверка.

7.4 Распределение интеллектуальных прав

Договор должен разделять ранее созданные компоненты исполнителя, новые результаты, сторонние библиотеки и сервисы заказчика. Заказчику передаются только те права и материалы, которые прямо указаны. Доступ к аккаунту внешнего сервиса не равен исключительному праву на сам сервис или модель.

Для каждого результата указываются способ передачи, территория, срок, возможность модификации, право выдавать лицензии и момент перехода исключительного права. Также определяется, может ли исполнитель использовать обезличенные наработки и общие технические решения в других проектах.

7.5 Ответственность и контроль человека

Искусственный интеллект не является самостоятельным участником договора. Ответственность определяется действиями людей и организаций: кто выбрал модель, предоставил данные, определил цель, настроил доступ, должен был проверить результат и принял окончательное решение.

Для высокорисковых сценариев договор закрепляет обязательный человеческий контроль. Указывается, какая сторона назначает проверяющего, что именно он проверяет и какие действия запрещены без подтверждения. Отдельно описываются уведомление об ошибке, приостановка функции, исправление и анализ причин.

7.6 Минимальный договорный комплект

ДокументНазначение
Основной договорПредмет, сроки, цена, права, ответственность
Техническое заданиеФункции, ограничения, интеграции и критерии приёмки
NDAРежим конфиденциальной информации
Поручение на обработку данныхОперации, цели, безопасность и удаление
Лицензионный переченьСторонние компоненты и условия использования
Протокол испытанийТесты, версии, результаты и замечания
Акт передачиПолученные материалы, доступы и документация
Регламент поддержкиИнциденты, обновления и сроки реакции

8 Российская и мировая практика регулирования

8.1 Российский подход

Российская модель сочетает стратегическое планирование, применение общих отраслевых законов, стандартизацию и экспериментальные режимы. Значительную роль играют требования к данным, информационной безопасности, технологическому суверенитету и развитию отечественной инфраструктуры.

Наряду с обязательными нормами развивается саморегулирование. Кодекс этики в сфере искусственного интеллекта и отраслевые дополнения формулируют принципы человекоцентричности, недискриминации, прозрачности, безопасности и ответственности. Эти документы не заменяют закон, но могут использоваться при создании внутренних политик и договорных требований.

8.2 Европейский союз

Европейский AI Act использует риск-ориентированную модель. Он различает запрещённые практики, высокорисковые системы, отдельные требования прозрачности и регулирование моделей общего назначения. Большая часть режима применяется с 2 августа 2026 года, при этом для отдельных положений предусмотрены специальные сроки и переходные правила.

Практический урок для российского разработчика состоит в том, что требования могут применяться не только по месту регистрации компании. Если продукт предлагается пользователям в ЕС или его результат используется там, необходимо отдельно оценить территориальную применимость, роль поставщика и пользователя, классификацию риска и обязанности по документации.

8.3 Международные принципы

Рекомендация ЮНЕСКО по этике ИИ рассматривает влияние технологий на права человека, культуру, образование, окружающую среду и общество. Принципы ОЭСР делают акцент на инклюзивном росте, человекоцентричных ценностях, прозрачности, устойчивости и подотчётности. Конвенция Совета Европы связывает жизненный цикл ИИ с правами человека, демократией и верховенством права.

Эти документы различаются по юридической силе, но формируют общий язык ответственного использования. Для компании они полезны как основа внутренних политик, оценки поставщика, обучения сотрудников и объяснения пользователю того, как работает система.

8.4 Стандарты управления

NIST AI Risk Management Framework предлагает рассматривать управление риском через функции управления, картирования, измерения и контроля. ISO/IEC 42001 устанавливает требования к системе менеджмента искусственного интеллекта. Оба подхода помогают перейти от разрозненных проверок к постоянному процессу с владельцами рисков, документами, метриками и корректирующими действиями.

Стандарт или рамочная методика не гарантирует законность и безопасность конкретного продукта. Они задают управленческую дисциплину, которую необходимо наполнить отраслевыми требованиями, тестами и доказательствами.

8.5 Сравнение подходов

ПодходОсновной акцентЧто взять проекту
РоссияСтратегия, отраслевые нормы, данные и экспериментыПравовая карта проекта и локальный контроль данных
Европейский союзКлассификация по риску и обязательства участниковИнвентаризация систем, прозрачность и документация
NISTУправление рисками в течение жизненного циклаМетрики, тесты, мониторинг и корректирующие действия
ISO/IEC 42001Система менеджмента AIРоли, политика, аудит и постоянное улучшение
ЮНЕСКО и ОЭСРЭтика, права человека и общественное довериеПринципы для внутренних правил и обучения

8.6 Медицина как высокорисковая область

В медицине AI может поддерживать поиск информации, сортировку документов, анализ изображений и подготовку черновика, но последствия ошибки требуют особенно строгого контроля. Необходимо различать информационный сервис, систему поддержки решения и медицинское изделие. Назначение, заявленные функции и способ использования влияют на требования.

Практика ответственного внедрения включает клиническую валидацию, оценку качества на целевой группе, защиту медицинских данных, контроль смещения, объяснение ограничений и сохранение решения за квалифицированным медицинским работником. Кодекс этики ИИ в медицине и документы Всемирной организации здравоохранения полезны как ориентиры, но не заменяют обязательные национальные процедуры.

Для медицинского проекта особенно важно отделять поиск и систематизацию информации от постановки диагноза и назначения лечения. Пользователь должен понимать роль системы, а врач - видеть источники, ограничения и уровень уверенности. При недостатке доказательств безопасное поведение состоит в передаче вопроса специалисту, а не в уверенной генерации ответа.

Любое расширение назначения требует повторной оценки. Модель, проверенная для подготовки черновика выписки, не считается автоматически проверенной для клинической рекомендации, сортировки пациентов или анализа медицинского изображения. Новый сценарий означает новые данные, риски, тесты и ответственность.

9 Проверка AI-проекта перед запуском

9.1 Шаг 1 Определите назначение

Опишите проект одним проверяемым предложением: кто использует систему, для какого действия, на основании каких данных и какой результат получает. Отдельно укажите, чего система не делает. Если назначение расплывчато, невозможно правильно определить ни качество, ни юридические требования.

9.2 Шаг 2 Составьте карту участников и данных

Перечислите владельца продукта, разработчика, оператора данных, поставщика модели, облачную площадку, интеграции, пользователей и лицо, принимающее окончательное решение. Нарисуйте путь данных от получения до удаления. Для каждого перехода укажите основание, страну обработки и ответственного.

9.3 Шаг 3 Проверьте источники и права

Для датасетов, документов, изображений, кода и моделей зафиксируйте происхождение и условия использования. Убедитесь, что подрядчики передали необходимые права, а открытые лицензии совместимы с продуктом. Исключите материалы, происхождение которых нельзя подтвердить.

9.4 Шаг 4 Оцените риск

Оцените возможный вред пользователю, компании и третьим лицам. Учтите чувствительность данных, дискриминацию, финансовые и медицинские последствия, публичность результата и обратимость действия. Для высокого риска установите независимую проверку и запрет автоматического исполнения.

9.5 Шаг 5 Проведите испытания

Тестовый набор должен отражать реальные обращения, сложные случаи, ошибки формата, противоречивые данные, попытки обхода ограничений и запросы, на которые система обязана отказаться отвечать. Результаты сохраняются вместе с версиями модели, промпта и базы знаний.

9.6 Шаг 6 Подготовьте эксплуатацию

До запуска назначаются владелец продукта и владелец риска, утверждается инструкция пользователя, настраиваются журналы и оповещения, резервный сценарий и отключение функции. Команда должна знать, как сообщить об ошибке и кто принимает решение о приостановке.

9.7 Итоговый чек-лист

Контрольный вопросСтатус
1Назначение и ограничения системы описаныДа / Нет
2Определены роли владельца, оператора и поставщиковДа / Нет
3Составлена карта потоков данныхДа / Нет
4Проверены основания обработки персональных данныхДа / Нет
5Проверены права на код, данные и контентДа / Нет
6Зафиксированы внешние сервисы и лицензииДа / Нет
7Есть тестовый набор и критерии приёмкиДа / Нет
8Определены случаи обязательного отказаДа / Нет
9Высокорисковые действия требуют одобренияДа / Нет
10Настроены журналирование и мониторингДа / Нет
11Есть резервный сценарий и возможность отключенияДа / Нет
12Пользователь информирован об ограниченияхДа / Нет
13Подготовлен порядок работы с инцидентамиДа / Нет
14Назначена дата следующего пересмотраДа / Нет

Решение о запуске принимается только после закрытия критических пунктов. Если не определено правовое основание обработки данных, отсутствует человек, отвечающий за высокорисковое действие, или система не может быть быстро отключена, запуск следует отложить. Остальные замечания фиксируются в плане доработки с владельцем и сроком.

После запуска проверка не заканчивается. Необходимо отслеживать качество, жалобы, инциденты, стоимость, задержку, изменение поведения модели и актуальность базы знаний. Существенное обновление модели, промпта, источников или инструментов рассматривается как изменение системы и требует повторных тестов.

Заключение

История искусственного интеллекта показывает постепенный переход от механизации вычислений к системам, которые обучаются на данных, генерируют новые материалы и используют внешние инструменты. Рост возможностей не отменил человеческую ответственность. Напротив, чем убедительнее и автономнее выглядит система, тем важнее проверять источники, права, данные и последствия её действий.

Правовая устойчивость AI-проекта создаётся на стадии архитектуры. Минимизация данных, ограниченные полномочия, документированные источники, измеримые тесты, человеческое одобрение и понятный договор эффективнее, чем попытка исправить последствия после запуска.

Для бренда «ДИС» следующим практическим шагом является инвентаризация активов, предварительный поиск обозначения, выбор приоритетных классов МКТУ и упорядочивание договоров с авторами и разработчиками. Защита бренда должна развиваться вместе с продуктами, а не после появления копий и споров.

Словарь

AI-агент. Система, которая использует модель для выбора действий и обращения к ограниченному набору инструментов.

Большая языковая модель. Модель, обученная на больших массивах текстовых и иных данных для обработки и генерации последовательностей.

Галлюцинация ИИ. Правдоподобный, но фактически неверный или неподтверждённый результат генерации.

Датасет. Организованный набор данных для обучения, проверки, анализа или поиска.

Договор возмездного оказания услуг. Договор, в котором исполнитель совершает согласованные действия; акцент делается на процессе оказания услуги.

Договор об отчуждении исключительного права. Договор, по которому исключительное право передаётся приобретателю в полном объёме.

Договор подряда. Договор, по которому исполнитель создаёт и передаёт заказчику определённый результат работы.

Инференс. Применение обученной модели к новому запросу или набору данных.

Контроль человека. Процедура проверки, подтверждения или исправления результата системы до значимого действия.

Лицензионный договор. Соглашение о предоставлении права использования объекта интеллектуальной собственности в установленных пределах.

Машинное обучение. Методы, при которых модель настраивает своё поведение на основе данных и заданного критерия.

NDA. Соглашение о неразглашении конфиденциальной информации.

Обезличивание. Действия, после которых определить принадлежность данных конкретному лицу без дополнительной информации невозможно.

Оператор персональных данных. Лицо, которое определяет цели, состав и действия по обработке персональных данных.

Промпт. Инструкция и контекст, передаваемые модели для получения требуемого результата.

RAG. Архитектура, в которой перед генерацией система ищет релевантные фрагменты в контролируемой базе знаний.

Составной договор. Договор, объединяющий элементы нескольких договорных конструкций.

Техническое задание. Документ с функциями, ограничениями, требованиями и критериями приёмки результата.

Товарный знак. Обозначение, зарегистрированное для индивидуализации товаров или услуг.

Трансграничная передача. Передача персональных данных на территорию иностранного государства иностранному органу, лицу или организации.

Human-in-the-loop. Архитектура процесса, предусматривающая обязательное участие человека в проверке или решении.

Литература и официальные источники

Исторические и фундаментальные работы

1. Babbage C. On the Economy of Machinery and Manufactures. London, 1832.

2. Lovelace A. Sketch of the Analytical Engine Invented by Charles Babbage. 1843.

3. Boole G. An Investigation of the Laws of Thought. London, 1854.

4. Frege G. Begriffsschrift. Halle, 1879.

5. Markov A. A. An Example of Statistical Investigation of the Text of Eugene Onegin. 1913.

6. McCulloch W., Pitts W. A Logical Calculus of the Ideas Immanent in Nervous Activity. 1943.

7. Wiener N. Cybernetics: Or Control and Communication in the Animal and the Machine. 1948.

8. Shannon C. A Mathematical Theory of Communication. Bell System Technical Journal, 1948.

9. Turing A. Computing Machinery and Intelligence. Mind, 1950.

10. McCarthy J., Minsky M., Rochester N., Shannon C. A Proposal for the Dartmouth Summer Research Project on Artificial Intelligence. 1955.

11. Rosenblatt F. The Perceptron: A Probabilistic Model for Information Storage and Organization in the Brain. 1958.

12. Minsky M., Papert S. Perceptrons. MIT Press, 1969.

13. Rumelhart D., Hinton G., Williams R. Learning Representations by Back-Propagating Errors. Nature, 1986.

14. LeCun Y., Bengio Y., Hinton G. Deep Learning. Nature, 2015.

15. Vaswani A. et al. Attention Is All You Need. 2017.

16. Sutton R., Barto A. Reinforcement Learning: An Introduction. 2nd ed., 2018.

17. Russell S., Norvig P. Artificial Intelligence: A Modern Approach. 4th ed., 2021.

Российские научные работы

1. Колмогоров А. Н. О представлении непрерывных функций нескольких переменных в виде суперпозиций непрерывных функций одного переменного. Доклады АН СССР, 1957.

2. Глушков В. М. Введение в кибернетику. Киев, 1964.

3. Цетлин М. Л. Исследования по теории автоматов и моделированию биологических систем. Москва: Наука, 1969.

4. Искусственный интеллект: справочник в трёх книгах / под ред. Д. А. Поспелова. Москва: Радио и связь, 1990.

5. Гаврилова Т. А., Хорошевский В. Ф. Базы знаний интеллектуальных систем. Санкт-Петербург: Питер, 2000.

6. Осипов Г. С. Искусственный интеллект. Москва: Физматлит, 2014.

7. Николенко С., Кадурин А., Архангельская Е. Глубокое обучение. Санкт-Петербург: Питер, 2018.

Российское регулирование и профессиональные источники

1. Указ Президента РФ от 10.10.2019 № 490 «О развитии искусственного интеллекта в Российской Федерации».

2. Указ Президента РФ от 15.02.2024 № 124 об изменении Национальной стратегии развития искусственного интеллекта.

3. Федеральный закон от 24.04.2020 № 123-ФЗ об эксперименте по внедрению технологий искусственного интеллекта в Москве.

4. Федеральный закон от 31.07.2020 № 258-ФЗ об экспериментальных правовых режимах в сфере цифровых инноваций.

5. Распоряжение Правительства РФ от 19.08.2020 № 2129-р. Концепция развития регулирования отношений в сфере технологий ИИ и робототехники.

6. Гражданский кодекс Российской Федерации. Часть четвёртая.

7. Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных».

8. Федеральный закон от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации».

9. Федеральный закон от 29.07.2004 № 98-ФЗ «О коммерческой тайне».

10. Федеральный закон от 13.03.2006 № 38-ФЗ «О рекламе».

11. ГОСТ Р 59276-2020. Системы искусственного интеллекта. Способы обеспечения доверия. Общие положения.

12. Альянс в сфере искусственного интеллекта. Кодекс этики в сфере искусственного интеллекта.

13. Альянс в сфере искусственного интеллекта. Белая книга этики в сфере ИИ.

14. Альянс в сфере искусственного интеллекта. Кодекс этики в сфере ИИ в медицине и здравоохранении.

15. Роспатент. Официальные материалы по регистрации товарных знаков и зарубежной охране.

Мировая практика

1. UNESCO. Recommendation on the Ethics of Artificial Intelligence. 2021.

2. OECD. Recommendation of the Council on Artificial Intelligence. 2019, revised 2024.

3. NIST. Artificial Intelligence Risk Management Framework AI RMF 1.0. 2023.

4. NIST. Artificial Intelligence Risk Management Framework: Generative AI Profile. 2024.

5. ISO/IEC 42001:2023. Information technology - Artificial intelligence - Management system.

6. European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence.

7. Council of Europe. Framework Convention on Artificial Intelligence and Human Rights, Democracy and the Rule of Law. 2024.

8. WHO. Ethics and Governance of Artificial Intelligence for Health. 2021.

9. WIPO. Revised Issues Paper on Intellectual Property Policy and Artificial Intelligence. 2020.

10. Stanford Institute for Human-Centered AI. AI Index Report. Annual editions.

11. Bommasani R. et al. On the Opportunities and Risks of Foundation Models. 2021.

12. Bender E. et al. On the Dangers of Stochastic Parrots. 2021.

13. Mitchell M. et al. Model Cards for Model Reporting. 2019.

14. Gebru T. et al. Datasheets for Datasets. 2021.

15. Raji I. et al. Closing the AI Accountability Gap. 2020.

16. UK Information Commissioner's Office. AI and Data Protection Risk Toolkit.

Официальные интернет-ресурсы

  • Официальный интернет-портал правовой информации
  • Роспатент
  • Поисковая платформа Роспатента
  • Кодекс этики в сфере ИИ
  • WIPO Madrid System
  • European Commission AI Act
  • NIST AI Risk Management Framework
  • OECD AI Principles
  • UNESCO Ethics of Artificial Intelligence
  • Council of Europe Artificial Intelligence

Примечание о проверке источников

Нормативные акты и стандарты необходимо проверять в действующей редакции на дату практического применения. В брошюру намеренно не включены правовые утверждения из учебных материалов, для которых не был установлен официальный первичный источник.

Об авторе

Степанов Д.А. объединяет клинический опыт невролога с практикой проектирования прикладных AI-систем. В центре его подхода находятся проверяемый результат, понятная архитектура, человеческий контроль и честное описание ограничений технологии.

Проекты серии «ДИС» посвящены практическому применению искусственного интеллекта в аналитике, обучении, медицине, коммуникациях и автоматизации бизнес-процессов. Название серии используется как единый знак авторского подхода и будет развиваться вместе с новыми решениями и методическими материалами.