Глава 3. Бремя I: система управления рисками, данные, документация

Ситуация на «Компасе»

«Компас» — high-risk (глава 2). Теперь перед командой разворачивается список обязанностей provider'а высокорисковой системы (Art. 8–17): восемь позиций, каждая с подпунктами. Первая реакция — «распишем задачи, наймём человека, закроем к дедлайну». И тут выясняется главное свойство этой главы: три из обязанностей невозможно закрыть задним числом, потому что они описывают не документ, а следы решений, которые уже приняты или ещё будут приниматься по ходу разработки. Их нельзя собрать за неделю до аудита — их можно только начать вести сейчас.

Более того, часть требований бьёт по решениям, сделанным ещё до того, как команда услышала про AI Act, — по данным, на которых настроена логика скоринга. Эта глава — про три обязательства, которые задают темп всему проекту: систему управления рисками, data governance и техническую документацию.

Что говорит норма

Risk Management System (Art. 9). Не разовый артефакт, а непрерывный итеративный процесс на весь жизненный цикл системы: систематически выявлять и анализировать риски для здоровья, безопасности и основных прав людей, оценивать их, принимать меры снижения, тестировать остаточный риск. Для «Компаса» ключевое слово — «основные права»: риск здесь не техсбой, а дискриминация кандидата, непрозрачный отказ, systemic bias против группы. RMS обязана жить на протяжении всей эксплуатации, а не закрыться подписью на старте.

Data & data governance (Art. 10). Требования к обучающим, валидационным и тестовым наборам данных: релевантность, достаточная репрезентативность, отсутствие ошибок насколько возможно, полнота под назначение. Отдельно — обязанность рассматривать возможные смещения (bias), которые влияют на здоровье, безопасность или ведут к дискриминации. Для найма это центр тяжести: если данные, на которых система училась различать «сильных» и «слабых» кандидатов, отражают исторические перекосы (кого нанимали раньше), система их закрепит и масштабирует.

Technical documentation (Art. 11 + Annex IV). Технический файл, который составляется до вывода на рынок и поддерживается актуальным: описание системы и назначения, архитектура, использованные данные, метрики точности, оценка рисков, меры human oversight. Это основной артефакт, который вы предъявляете регулятору и аудитору. Важнейшее свойство: документация не пишется постфактум как отчёт — она фиксирует проектные решения по мере их принятия. Technical file, восстановленный по памяти перед проверкой, — это фикция, и опытный аудитор её видит.

Как это ложится на продукт

«Компас» заводит RMS как процесс, а не PDF: реестр рисков (дискриминация, дрейф качества, ошибочные отказы), привязанный к релизам — каждое существенное изменение системы проходит ре-оценку риска. Это ложится на принцип явных переходов состояний: статус риска — внешняя запись в реестре, а не «если» в чьей-то голове.

Data governance: «Компас» заводит паспорт данных скоринга — откуда данные, насколько репрезентативны по демографии, какие тесты на bias прогнаны и с каким результатом. Здесь же всплывает специфика: логика «Компаса» частично определяется чужой foundation-моделью, чьи обучающие данные команда не контролирует. Что из требований Art. 10 переадресуется провайдеру модели, а что остаётся на «Компасе» — предмет глав 5 и 7; но зафиксировать разрыв нужно уже сейчас.

Technical file заводится с первого дня по структуре Annex IV и растёт вместе с продуктом. Не отдельный документ «к дедлайну», а живой артефакт, куда стекаются решения.

Где ломается

Чужая модель ломает Art. 10. Provider «Компаса» не контролирует обучающие данные foundation-модели — но формально отвечает за качество данных своей системы. Как выполнять требования к репрезентативности и bias для того, что обучалось не у тебя, — вопрос без чистого ответа; частичное решение (документация от провайдера GPAI) в главе 7, но зона остаётся мутной.

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

RMS легко выродить в театр. Реестр рисков, который завели ради галочки и не трогают, — это тот же PDF, только в другом файле. Живой процесс отличается от мёртвого тем, что изменение продукта реально запускает ре-оценку, а не остаётся незамеченным.

Что делать инженеру/продакту

Завести technical file и реестр рисков сейчас, а не перед аудитом, и привязать их обновление к релиз-процессу — так документация фиксирует решения в момент их принятия, а не реконструируется задним числом. Явные статусы вместо инкапсулированной логики: риск, версия данных, результат bias-теста — наблюдаемые записи.

Для чужой модели — истребовать у провайдера документацию, нужную для Annex IV и Art. 10 (карта модели, summary данных, ограничения), и письменно зафиксировать, что именно недоступно. Разрыв ответственности, признанный на бумаге, лучше разрыва, обнаруженного аудитором.

Провокация

Три требования этой главы объединяет одно свойство: их физически нельзя предъявить задним числом. Система управления рисками, собранная к дате аудита, доказывает ровно обратное тому, что требует закон, — что при проектировании рисками никто не управлял. Data governance, предъявленный постфактум, честно отвечает аудитору «мы не знаем, на чём это училось». В high-risk комплаенсе выигрывает не тот, кто быстрее пишет документы, а тот, кто раньше начал их вести.

Читать дальше

• Дальше: Obligations II — Human oversight, логи и мониторинг после релиза
• Все главы курса →
• Подключить эксперта как MCP →