3

WebTech

Личный кабинет

Проекты, коммерческие предложения, документы и отчёты — в одном месте.

Войти Зарегистрироваться Забыли пароль?
Этика и комплаенс

Требования нужно закладывать в архитектуру, а не прикручивать после

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

Или сразу: +7 (962) 368-39-51 Telegram

152-ФЗ
обработка данных
on-prem
локальный контур
аудит
журналы и объяснимость
bias
проверка предвзятости
Задачи

Риски, которые обнаруживаются на финальной стадии

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

Персональные данные ушли во внешний сервис

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

Решение невозможно объяснить

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

Система воспроизводит дискриминацию

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

Нет следов работы системы

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

Данные хранятся бессрочно

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

Ответственность размыта

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

Решения

Что разбираем в руководстве

Четыре направления, которые определяют, пройдёт ли система юридическую и внутреннюю проверку.

Данные и правовые основания

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

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

Локальный контур против облака

Считаем экономику и риски двух вариантов размещения: собственные мощности и российское облако против внешних сервисов.

  • Требования локализации и допустимость трансграничной передачи
  • Стоимость владения своим контуром против оплаты по запросам
  • Выбор открытых моделей и ускорителей под задачу и бюджет
  • Гибридные схемы: чувствительные данные локально, общие задачи в сервисе

Объяснимость и контроль предвзятости

Делаем решения системы понятными и проверяем, не воспроизводит ли она смещения исторических данных.

  • Объяснение решения в терминах признаков, понятных сотруднику и клиенту
  • Проверка распределения решений между группами при сопоставимых данных
  • Исключение прямых и косвенных признаков, не связанных с задачей
  • Порядок разбора жалоб и пересмотра решения человеком

Журналирование и готовность к аудиту

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

  • Журнал решений с привязкой к версии модели и версии данных
  • Ролевой доступ к данным и журнал действий пользователей
  • Регламент реагирования на инциденты и порядок уведомления
  • Документация системы: для чего, на каких данных, с какими ограничениями
Процесс

Как мы работаем с требованиями

Комплаенс встраивается в проект на этапе проектирования, а не проверяется в конце.

  1. 01 3–5 дней

    Инвентаризация данных

    Описываем, какие данные попадают в систему, откуда приходят, где хранятся и кто имеет к ним доступ.

  2. 02 1 неделя

    Выбор контура

    Сравниваем варианты размещения по требованиям законодательства, стоимости и производительности, фиксируем решение.

  3. 03 1–2 недели

    Проектирование контроля

    Закладываем журналирование, объяснимость, проверку предвзятости и порядок разбора жалоб в архитектуру системы.

  4. 04 1–2 недели

    Проверка и документация

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

152-ФЗ и AI: что нужно учесть

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

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

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

On-premise или облако: как выбирать

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

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

Наиболее практичный вариант для многих компаний — гибридная схема. Чувствительные задачи, связанные с персональными данными и коммерческой тайной, обрабатываются локально; общие задачи вроде генерации текста или суммирования публичных документов идут через внешние сервисы. Такая схема позволяет получить экономию, не создавая правовых рисков. Мы всегда считаем экономику обоих вариантов на ваших объёмах, а не рекомендуем один подход всем.

Объяснимость и контроль предвзятости на практике

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

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

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

Частые вопросы

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

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

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

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

Материалы об AI: другие направления

Смежные задачи, которые обычно решаются в одном проекте с этой.

Нужно, чтобы AI-система прошла проверку безопасности и юристов?

Расскажите, какие данные предполагается обрабатывать, — предложим архитектуру, которая соответствует требованиям, и подготовим документацию для аудита.