Глава 4. Бремя II: human oversight, точность, логи, post-market monitoring

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

Продуктовая гордость «Компаса» — бесшовность: рекрутёр открывает вакансию и сразу видит готовый ранжированный список кандидатов, можно работать. Именно эта бесшовность сталкивается с требованием human oversight. Закон спрашивает: где здесь человек, который реально понимает, на чём основан ранг, и может его отменить, — а не просто нажимает «принять» на том, что ему показали?

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

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

Human oversight (Art. 14). Высокорисковая система проектируется так, чтобы её можно было эффективно контролировать человеком: человек должен понимать возможности и ограничения системы, замечать её сбои, не переоценивать её вывод (защита от automation bias — слепого доверия машине) и иметь возможность вмешаться или отменить результат. Ключевое: это не «человек присутствует рядом», а спроектированная возможность реального вмешательства. Кнопка «подтвердить», которую жмут не глядя, требованию не удовлетворяет.

Accuracy, robustness, cybersecurity (Art. 15). Система должна достигать адекватного уровня точности (с заявленными метриками), быть устойчивой к ошибкам и сбоям и защищённой от атак, включая специфичные для ИИ (adversarial-манипуляции, data poisoning). Для скоринга людей возникает тонкий вопрос: точность ранжирования — это метрика чего именно и как она соотносится со справедливостью.

Record-keeping / логи (Art. 12). Система автоматически ведёт журналы событий на протяжении срока службы — для трассируемости, расследования инцидентов и доказательства работы в рамках. Для «Компаса» это неизменяемый след каждого решения скоринга.

Post-market monitoring (Art. 72). Provider выстраивает систему наблюдения за поведением системы в реальной эксплуатации — активно собирает и анализирует данные о её работе, а не ждёт жалоб.

Serious incident reporting (Art. 73). О серьёзных инцидентах provider обязан сообщать надзорному органу в установленные сроки. Что считать «серьёзным» и как быстро сообщать — часть процесса, который надо построить заранее.

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

«Компас» переделывает UX рекрутёра: вместо «утвердить список» — видимые основания оценки (почему кандидат в этом ранге), возможность переопределить ранг и залогировать переопределение. Это и есть meaningful oversight: человек не штампует вывод машины, а работает с ним, и система это фиксирует.

Логи решений скоринга становятся неизменяемым трейсом — здесь курс стыкуется с инженерной стороной (control plane и audit plane из соседнего курса ai-governance): требование закона (Art. 12) реализуется конкретной архитектурой аудита.

«Компас» заводит процесс post-market monitoring (метрики качества и дрейфа в проде) и runbook инцидентов со сроками нотификации — до того, как случится первый инцидент, а не после.

Где ломается

Oversight легко имитировать. Самая тонкая грань — «meaningful». Кнопка «подтвердить» без реальной возможности понять и оспорить основания — это задокументированный automation bias, а не контроль. Сделать интерфейс, где человек действительно может вмешаться, а не только формально одобрить, — продуктовая, а не юридическая задача.

«Accuracy» скоринга людей — метрика чего? Точность ранжирования (насколько порядок совпал с неким «эталоном») не равна справедливости и не гарантирует отсутствия дискриминации. Высокая метрика точности может сопровождаться систематическим перекосом против группы.

Границы incident reporting размыты. Что именно «серьёзный инцидент» для HR-системы и в какие сроки сообщать — на практике неочевидно, разъяснений мало. Лучше иметь заведомо избыточный процесс, чем пропустить порог.

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

Проектировать human oversight как продуктовую функцию — объяснимость оснований + реальный override + лог переопределения — и тестировать, что человек действительно может отменить вывод, а не только согласиться. Oversight, который нельзя использовать, юридически хуже, чем честно описанное его отсутствие.

Включить логирование решений и процесс мониторинга/инцидентов до релиза. Post-market monitoring и runbook — не то, что дописывают после первого разбирательства.

Провокация

Human oversight — единственное требование AI Act, которое нельзя закрыть документом: оно меняет сам продукт. И здесь прячется парадокс — кнопка «подтвердить», которую рекрутёр жмёт не читая, юридически хуже её отсутствия. Потому что каждое такое нажатие — это задокументированное, залогированное доказательство, что контроля человека не было, оформленное вашими же руками.

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

• Дальше: Value chain — Кто отвечает: provider, deployer и цепочка поставки
• Все главы курса →
• Подключить эксперта как MCP →