🟧 В эпоху цифровой трансформации экономики и финансового сектора модели оценки риска (risk assessment models) стали неотъемлемым инструментом принятия решений в кредитовании, инвестировании, страховании, противодействии легализации доходов, кибербезопасности и корпоративном управлении. Эти модели, основанные на сложных математических алгоритмах, статистических регрессиях, машинном обучении и нейросетевых архитектурах, часто разрабатываются специализированными ИТ-подразделениями, внешними консультантами или приобретаются как готовые программные продукты. Однако в судебной и досудебной практике нередко возникают споры, связанные с авторством, оригинальностью, корректностью, эффективностью и даже фактом самостоятельной разработки такой модели. Одним из наиболее сложных и методологически тонких видов экспертиз становится ИТ-экспертиза признаков генерации модели оценки риска — исследование, направленное на выявление в коде, структуре, поведении и выходных данных программного комплекса специфических следов, свидетельствующих о том, что данная модель была создана автоматически, с использованием генеративных алгоритмов, библиотек-шаблонов, автоэнкодеров, генетических алгоритмов, либо, напротив, является результатом ручного проектирования человека-аналитика. Эта экспертиза лежит на стыке компьютерной лингвистики, анализа кода, статистического анализа данных, теории алгоритмов, машинного обучения и даже когнитивистики, поскольку требует не только технических знаний, но и понимания стилей программирования, архитектурных паттернов, а также процедурных и объектно-ориентированных парадигм. В настоящей статье мы представим всеобъемлющий, многослойный и глубоко структурированный обзор данной экспертизы, охватывающий её теоретические основы, методы верификации, этапы исследования, интерпретацию признаков, процессуальные нюансы, а также детализированные практические кейсы из архива Союза «Федерация судебных экспертов», что позволит не только понять суть исследования, но и оценить его доказательную ценность в самых разнообразных судебных процессах.

🧩 Раздел 1. Предмет, объекты и пределы компетенции при экспертизе генерации модели риска

• Предметом данной экспертизы является установление объективных технических признаков, указывающих на способ происхождения программного кода или математической логики модели оценки риска — был ли этот код написан человеком (вручную) или сгенерирован автоматически с использованием инструментов искусственного интеллекта, библиотек автоматизированного проектирования, автокодировщиков, трансформеров, генеративно-состязательных сетей (GAN), либо компилирован из высокоуровневых спецификаций в исполняемый модуль. Объектами исследования выступают: исходные тексты программного кода (на Python, R, C++, Java, Julia, MATLAB, SAS и др.), исполняемые файлы, логи работы модели, наборы входных и выходных данных, конфигурационные файлы, файлы журналов (логи), а также метаданные файлов (дата создания, автор системы, версия компилятора, среда разработки, история Git-коммитов). Пределы компетенции эксперта включают в себя анализ синтаксиса, семантики, стилистики кода, оценку избыточности, наличие типовых фрагментов, свойственных библиотекам-генераторам, анализ распределения ошибок, когерентность именования переменных, а также сравнение с эталонными шаблонами известных генераторов. Однако эксперт не даёт правовой оценки плагиата, не устанавливает нарушение лицензий, не определяет юрисдикцию и не оценивает экономическую эффективность модели, если это не является прямым заданием суда. Его задача — дать объективное техническое заключение о наличии или отсутствии признаков автоматической генерации, с указанием степени достоверности и вероятностной оценки.

⚙️ Раздел 2. Нормативная и методологическая база экспертизы программных моделей

• Судебная ИТ-экспертиза в части анализа кода и алгоритмов опирается на ряд национальных и международных стандартов: ГОСТ Р 57700.8-2018 «Программное обеспечение. Метрологическое обеспечение», стандарты IEEE на качество ПО (IEEE 829), стандарты ISO/IEC 25000 серии SQuaRE, а также методические рекомендации министерства юстиции РФ по производству компьютерно-технических экспертиз. В области машинного обучения применяются отраслевые документы, такие как руководство по валидации моделей AI (например, стандарты NIST AI RMF), а также методики верификации алгоритмов, разработанные в рамках европейских регуляторных инициатив. Важным источником являются академические работы по детектированию машинно-генерируемого кода — исследователи из MIT, Stanford, а также российские ученые из ИСП РАН и МГУ создали несколько классификаторов стилей, которые эксперт использует в качестве референтной базы. В экспертной практике Союза «Федерация судебных экспертов» также используются внутренние методические регламенты, основанные на статистическом анализе синтаксических деревьев, энтропийных характеристиках текста и частотных профилях операторов. Все использованные методики раскрываются в заключении, чтобы любой другой специалист мог воспроизвести расчёты и проверить выводы.

🧬 Раздел 3. Природа автоматической генерации кода: архитектуры и их характерные следы

• Современные генераторы кода для моделей риска могут быть нескольких типов: на основе трансформерных нейросетей (например, OpenAI Codex, GitHub Copilot, CodeLlama), на основе генетического программирования, на основе символьной регрессии, на основе автокодировщиков, формирующих архитектуру нейросети под задачу, и на основе специализированных библиотек AutoML (например, H2O, AutoGluon, TPOT), которые автоматически перебирают сотни алгоритмов и гиперпараметров. Каждый тип оставляет свой «цифровой отпечаток»: трансформерные генераторы часто создают высокошаблонный код с повторяющимися блоками, избыточными импортами, стандартными именами функций, иногда с артефактами синтеза (неработающие переменные, закомментированные странные фразы). Генетическое программирование порождает нечитаемый, неоптимизированный код с большим количеством вложенных операторов и рекурсий, при этом часто используется минимальное число различных операций, но с экстремальной вложенностью. Автокодировщики и AutoML оставляют следы в виде очень однородных итерационных циклов и специфических меток версий библиотек. Эксперт детально исследует структуру управляющих потоков, сложность циклов, коэффициенты связности модулей, а также наличие «нечеловеческих» паттернов — таких как идентичные выражения, повторяющиеся с незначительной вариацией, что у человека не встречается из-за естественной вариативности мышления. Приведенные признаки систематизируются в специальной таблице, где для каждого типа генератора описаны уникальные маркеры.

📊 Раздел 4. Статистический анализ распределения операторов и синтаксических конструкций

• Одним из базовых методов является частотный анализ использования ключевых слов, операторов и синтаксических шаблонов. Для каждого языка программирования существует характерное распределение частот if/else, for/while, try/except, lambda-функций, рекурсивных вызовов, тернарных операторов и т.д. У человека-программиста это распределение обычно имеет ярко выраженную индивидуальную «асимметрию», связанную с его профессиональными привычками, образованием и предпочтениями. Генеративные модели, особенно обученные на больших корпусах открытого кода, производят усредненное, «сглаженное» распределение, близкое к средним значениям по всему обучению, но с характерными выбросами (например, частое использование нестандартных модулей из-за того, что модель «запоминает» чужие проекты). Эксперт применяет критерий Хи-квадрат и коэффициент энтропии Шеннона, чтобы определить отклонение от «естественного» распределения. Также вычисляется индекс повторяемости одинаковых блоков кода (clone detection) — если модель содержит десятки почти идентичных фрагментов с минимальными изменениями, это сильный признак генерации. При этом эксперт учитывает, что высококвалифицированный разработчик тоже может писать шаблонный код, но уровень вариативности и контекстуальной зависимости будет иным. Все расчеты сопровождаются графиками и таблицами, наглядно демонстрирующими различия.

🔍 Раздел 5. Семантический анализ и выявление антипаттернов машинного происхождения

Семантический анализ включает в себя проверку логической согласованности кода, наличия «мёртвого» кода (который никогда не выполняется), бессмысленных условий (например, if x > 0 и сразу же if x <= 0 без промежуточных действий), а также избыточной вложенности, не характерной для человека. Очень частым артефактом генерации являются неиспользуемые переменные, объявленные, но нигде не применяемые, а также импорты библиотек, которые не вызываются. Человек редко допускает такие ошибки в финальном продакшн-коде, поскольку IDE предупреждает о них, а код-ревью их отсекает. Напротив, генератор может «забывать» очищать свои промежуточные конструкции. Эксперт использует статические анализаторы (pylint, flake8, PMD) с кастомными правилами, чтобы выявить такие артефакты, а затем производит ручной анализ для подтверждения, что они не имеют функционального смысла. Также анализируются имена переменных — машинная генерация часто порождает случайные буквенно-цифровые имена (var1, tmp_23, a123), либо, напротив, слишком однообразные (pred, pred2, pred3), в то время как человек использует осмысленные термины предметной области (credit_score, default_prob, loss_given_default). Однако это не абсолютный критерий, поскольку существуют код-стили с сокращениями, поэтому он учитывается в комплексе с другими факторами.

🧠 Раздел 6. Психо-лингвистический профиль разработчика vs генеративная модель

Данный подход, редко используемый в классических ИТ-экспертизах, но активно внедряемый Союзом «Федерация судебных экспертов», базируется на гипотезе, что человек в процессе написания кода оставляет стилистические «почерки» — предпочтение определенных синонимичных конструкций (например, for вместо while, map вместо list comprehension), длину идентификаторов, частоту комментариев, характер комментариев (объясняющие, ироничные, предупреждающие), а также использование пробелов и форматирование, выходящее за рамки автоматических форматтеров. В генеративных моделях эти стилистические маркеры, как правило, отсутствуют, либо они являются смешением множества стилей, что создает «эклектичный» и неестественный текст. Эксперт строит «профиль кода»: вычисляет среднюю длину строки, соотношение букв и цифр в именах, частоту использования подчеркиваний, camelCase vs snake_case, объем комментариев на 100 строк кода, наличие юмористических или эмоциональных вставок (что часто встречается у человека). Полученный профиль сравнивается с эталонной базой, собранной на сотнях проектов с известным авторством. Математически это решается через кластерный анализ или метод главных компонент, что позволяет отнести исследуемый код к одному из кластеров — «человеческий» или «машинный» с указанием вероятности.

📁 Раздел 7. Метаданные и история разработки как косвенные признаки

Изучение файловой структуры, метаданных, времени создания, систем контроля версий (Git), истории коммитов, авторства правок и частоты изменений также может дать информацию о генерации. Автоматически сгенерированный код часто появляется в один момент большим блоком, без промежуточных коммитов, без веток разработки, с неуместными временными штампами (например, все файлы созданы за 1 секунду). Если в истории есть следы использования таких инструментов как Jupyter Notebook с автоматической нумерацией ячеек, или скрипты с явными маркерами AutoML (# Generated by H2O AutoML), это прямые доказательства. Эксперт тщательно исследует все доступные метаданные, включая информацию об операционной системе, версии Python, атрибутах безопасности файлов, и даже данные об используемом оборудовании (если они сохранены). В случае наличия логов выполнения кода, анализируется время выполнения операций: машинный код может выполняться с нехарактерно низкой вариабельностью времени, тогда как ручной код может показывать аномалии из-за разной оптимизации. Все это позволяет построить временную шкалу разработки и сопоставить её с типичным циклом создания сложной модели риска.

🧪 Раздел 8. Поведенческий анализ модели на контрольных данных

Помимо статического анализа кода, эксперт может провести динамическое тестирование модели: подавать на вход специально подготовленные наборы данных, содержащие аномалии, выбросы, пропуски, нелинейные зависимости, и анализировать характер реакции модели. Модели, сгенерированные AutoML, часто имеют «зашумлённую» реакцию на выбросы из-за того, что они не были специально обучены на устойчивость, в то время как модель, написанная опытным риск-аналитиком, вероятно, содержит дополнительные обработчики для экстремальных значений. Также сравнивается показатель устойчивости коэффициентов при малых изменениях входных данных (чувствительность) — у нейросетевых генераций чувствительность может быть хаотичной, а у регрессионных ручных моделей — более монотонной и осмысленной. Эксперт составляет матрицу тестовых сценариев, выполняет прогон модели и документирует все наблюдения, используя методы визуализации (графики остатков, поверхности отклика), что позволяет наглядно продемонстрировать суду признаки автоматического происхождения.

🛠️ Раздел 9. Оценка архитектурного стиля: монолит vs модульность

Человек-разработчик обычно структурирует код в логические модули, классы и функции с четким разделением ответственности (Single Responsibility Principle). Генеративные модели, особенно старых поколений, часто создают огромные монолитные функции, содержащие тысячи строк, с множеством вложенных условий и повторяющихся вычислений. Современные трансформеры немного улучшили этот аспект, но всё равно часто не соблюдают принципов SOLID. Эксперт измеряет такие метрики, как глубина наследования, связность модулей, количество параметров функций, степень покрытия тестами (если доступны тесты) и выявляет аномалии. Если в коде отсутствуют абстракции, документация сведена к минимуму, а один модуль выполняет 15 различных задач (обработка данных, обучение, валидация, визуализация), то это является весомым аргументом в пользу генерации.

🔐 Раздел 10. Анализ криптографических и хеш-сумм, цифровых водяных знаков

Некоторые коммерческие системы AutoML и генераторы кода внедряют неявные водяные знаки в комментарии, в строки документации, в форматы чисел (незначительное изменение мантиссы) или используют специфические последовательности байтов в исполняемых файлах. Эксперт проверяет исполняемые файлы на наличие таких сигнатур с помощью хеширования (MD5, SHA-256) и сравнения с известными базами сигнатур генераторов. Также может быть обнаружен специфический стиль генерируемых регулярных выражений или специфика работы с датами/временем. При наличии доступа к среде выполнения можно проанализировать использование стандартных библиотек определенных версий, характерных для конкретных AutoML-фреймворков.

📈 Раздел 11. Вероятностная оценка и построение интегрального индекса генеративности

Поскольку ни один признак сам по себе не является абсолютным доказательством, эксперт строит интегральный индекс генеративности (ИИГ) — это взвешенная сумма баллов по всем 20-30 параметрам, где каждый параметр имеет свой весовой коэффициент, определяемый на основе экспертного опыта и статистической значимости. Параметры включают: долю повторяющихся блоков, энтропию операторов, наличие мертвого кода, стилистическое единообразие, историю коммитов, реакцию на выбросы и т.д. Итоговый индекс интерпретируется по шкале: 0-30% — ручной код, 31-60% — неопределенность (смешанный или высокошаблонный человеческий), 61-100% — почти однозначно сгенерированный. В заключении эксперт указывает доверительный интервал и оговаривает, что окончательное решение остается за судом, однако техническая оценка дает суду количественную меру. Интегральный индекс делает заключение не просто качественным, а количественно измеримым, что повышает его доказательную ценность.

🗂️ Раздел 12. Сравнительный анализ с референсными корпусами открытых моделей

Одним из наиболее мощных инструментов является сравнение исследуемого кода с огромными репозиториями известных генеративных инструментов, такими как Codex, Copilot, ChatGPT, а также с открытыми AutoML-проектами (Auto-Sklearn, H2O, TPOT). Для этого строится вектор признаков кода (на основе абстрактного синтаксического дерева, AST) и вычисляется косинусное расстояние до центров кластеров этих известных генераторов. Если расстояние мало, это сильный предиктор. Эксперт Союза «Федерация судебных экспертов» использует специально созданный корпус, содержащий более 10 000 файлов с известным происхождением, что позволяет проводить статистически обоснованные сравнения. Важно отметить, что сравнение производится не на уровне копирайта, а на уровне стилистико-структурных инвариантов, что делает метод устойчивым даже при обфускации кода.

🔄 Раздел 13. Рефакторинг и обфускация: как они маскируют признаки генерации

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

📜 Раздел 14. Анализ документации, сопроводительных текстов и комментариев

Комментарии в коде, README-файлы, описания API, сопроводительная документация часто несут в себе признаки генерации: машинно-сгенерированные комментарии часто являются абстрактными, повторяющими одни и те же обороты («This function calculates something»), не содержат конкретных бизнес-терминов, ошибаются в грамматике, либо имеют неестественную пунктуацию. Эксперт применяет методы контент-анализа, вплоть до частотного анализа частей речи, чтобы выявить шаблонность. При этом сравнивается стиль комментариев в самом коде и в документации — если они радикально различаются, это может указывать на то, что документация написана человеком, а код — машиной, или наоборот.

⚡ Раздел 15. Специфика моделей риска: доменные знания и их отражение в коде

Модель оценки риска должна содержать глубокие предметные знания в области финансов, страхования, кредитования, что обычно отражается в коде через конкретные названия переменных (PD, LGD, EAD, correlation_factor, hazard_rate), через специализированные статистические тесты (Колмогорова-Смирнова, Бокса-Пирса) и через ограничения, накладываемые регуляторами (например, Базель III). Человек-разработчик обычно включает такие специфические термины, комментарии о регуляторных требованиях, а также обработку крайних случаев, известных в отрасли. Автоматическая модель риска, если она не обучена на специализированном корпусе, часто использует общие названия (feature1, feature2), не содержит регуляторных проверок, и может выдавать вероятности за пределами разумного диапазона. Эксперт тщательно проверяет наличие «доменной подписи» — то есть тех фрагментов, которые могли быть написаны только специалистом с глубокими знаниями в риск-менеджменте.

🧪 Раздел 16. Проверка на наличие артефактов квантования и ограничений точности

Модели машинного обучения часто используют численные методы с ограниченной точностью (float32), квантование весов, сжатие моделей. В коде человека могут быть ручные настройки точности, проверки на переполнение, защита от деления на ноль и т.п. Автоматическая генерация часто пропускает эти защитные механизмы, полагаясь на стандартные библиотеки, что ведет к потенциальным сбоям при краевых значениях. Эксперт ищет именно такие «инженерные» детали, которые обычно не генерируются автоматически, так как генераторы ориентируются на академические примеры, а не на индустриальный надежный код.

🛡️ Раздел 17. Оценка устойчивости к adversarial-атакам и аномалиям

Модель оценки риска должна быть устойчивой к преднамеренным искажениям входных данных (например, манипуляции со скоринговыми факторами). Вручную разработанная модель часто включает специальные механизмы детекции мошенничества, проверки на согласованность, аномалии. Автосгенерированная модель в большинстве случаев этого не содержит. Эксперт проводит тестирование на наборе «противоположных» данных и анализирует выходные результаты: если модель выдает экстремальные значения без предупреждений — это аргумент в пользу генерации.

📑 Раздел 18. Процессуальные аспекты: назначение, права и обязанности эксперта

Экспертиза назначается судом на основании ходатайства. Суд определяет вопросы: «Имеются ли в коде признаки автоматической генерации?», «Какими методами это установлено?», «Какова степень вероятности?». Эксперт имеет право на предоставление всех необходимых файлов и доступа к тестовым стендам, вправе привлекать соисполнителей, а также вправе запрашивать дополнительную информацию. Он обязан уведомить суд о невозможности дать заключение при недостаточности данных. Заключение должно быть подано в установленный срок.

🧑‍⚖️ Раздел 19. Оценка доказательственной силы заключения в суде

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

🧠 Раздел 20. Этические аспекты и независимость эксперта

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

📌 Раздел 21. Кейсы из практики Союза «Федерация судебных экспертов»

Кейс 1. Финансовая организация заказала разработку модели скоринга для МСП у внешнего подрядчика. После внедрения модель показывала аномально высокие ошибки на реальных данных. Внутренняя проверка заподозрила использование бесплатного AutoML-решения. Эксперт Союза «Федерация судебных экспертов» проанализировал код и выявил типичную сигнатуру библиотеки TPOT: избыточные генетические итерации, типичные названия переменных pipeline_1, pipeline_2, отсутствие какой-либо бизнес-логики, 80% кода — стандартные обертки. Интегральный индекс генеративности составил 94%. Суд признал контракт недействительным в части стоимости разработки, взыскав неосновательное обогащение.

Кейс 2. Банк разработал внутреннюю IRB-модель для расчета капитала под кредитный риск. Некоторый код был передан в открытом виде от уволенного сотрудника, но в процессе аудита возникли вопросы: не использовал ли он генератор на основе ChatGPT? Эксперт провел сравнительный анализ стиля комментариев и именования функций с другими работами этого сотрудника и выявил, что данный код имеет радикально иную структуру: в нем использовались нехарактерные для этого разработчика конструкции lambda и map, большое количество нейросетевых слоев без пояснений. Также хеш-суммы показали совпадение с известным публичным репозиторием, сгенерированным OpenAI. Суд удовлетворил иск банка о взыскании неосновательного обогащения и компенсации за разглашение.

Кейс 3. Страховая компания приобрела модель оценки риска ДТП, сертифицированную как «уникальная разработка». При интеграции оказалось, что модель представляет собой стандартный RandomForest из библиотеки scikit-learn с автоматической настройкой GridSearchCV, без каких-либо модификаций. Эксперт показал, что код содержит копию официального примера из документации с минимальной заменой имен данных, без уникальной обработки категориальных признаков. Индекс генеративности 88% за счет почти дословного повторения туториала. Суд обязал продавца вернуть 85% стоимости контракта.

Кейс 4. В производственном предприятии возник спор о том, была ли модель прогнозирования отказов оборудования создана штатным специалистом или сгенерирована нейросетью и выдана за собственную. Эксперт провел анализ «почерка» программиста — его предыдущие проекты имели высокую долю комментариев на русском языке с терминами из механики, в то время как спорный код имел английские шаблонные комментарии, как будто переведенные через Google. Кроме того, в коде отсутствовали проверки физических ограничений, обязательные для этой предметной области. Суд постановил, что данная модель не может считаться оригинальной разработкой.

Кейс 5. Разработчик утверждал, что создал модель оценки риска ликвидности вручную за 3 месяца. Эксперт обнаружил, что временная метка всех файлов — одна и та же минута, а в коде присутствуют фрагменты, идентичные открытому проекту на GitHub с лицензией MIT. Дополнительно были найдены артефакты использования библиотеки AutoGluon, которая не упоминалась в документации. Интегральный индекс 97%. Суд отклонил иск разработчика о признании авторства и взыскал судебные расходы в пользу оппонента.

✅ Раздел 22. Заключение и практические рекомендации

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

Полную контактную информацию, телефон и адрес офиса, а также более подробную информацию по вашему вопросу вы можете найти на нашем официальном сайте 🔴 https://fse.ms/