Правила использования ИИ уже есть. Где они работают на самом деле?

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

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

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

На бумаге правило осталось простым: перед внешним использованием должен проверить человек.

Но где именно оно должно сработать?

Когда ИИ закончил черновик? После редакторской доработки? Непосредственно перед отправкой? Достаточно ли того, что сотрудник открыл документ? Считается ли обычное редактирование проверкой или требуется отдельное подтверждение?

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

Но без ответа хотя бы на уровне данного процесса правило остаётся намерением.

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

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

Поэтому я бы не начинала с вопроса «достаточно ли хорошо написана наша AI policy».

Сначала я бы взяла одно конкретное правило и спросила: в какой точке реальной работы оно должно стать действием?

Здесь возникает предыдущий слой.

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

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

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

Из этого не следует, что организация столкнулась с массовым нарушением правил или каким-то особым «теневым ИИ». Чтобы появилась неполная картина, никому не обязательно действовать недобросовестно.

Достаточно того, что реальная система меняется.

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

С внутренними правилами логика та же.

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

Управлять абстрактным «использованием ИИ в компании» невозможно.

Правило встречается не с ИИ вообще, а с конкретным инструментом, данными, действием и рабочей ситуацией.

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

Переписывание policy само по себе этого расхождения не исправит.

Во многих правилах работы с ИИ появляется требование человеческого участия.

Человек проверяет. Человек подтверждает. Человек принимает окончательное решение. Система не должна выполнять определённые действия самостоятельно.

Все эти формулировки имеют смысл.

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

Вернёмся к условному отчёту.

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

Нужно решить, где находится остановка.

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

Это не спор о том, что лучше — ручная процедура или технический контроль.

Мне важно другое различение.

Фраза «человек должен вмешаться» и реальная возможность вмешательства — не одно и то же.

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

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

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

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

Здесь уже не очень важно, насколько красиво сформулирован исходный документ.

Вопрос стал операционным: какое изменение в реальном действии должно произойти благодаря этому правилу?

Предположим, отчёт получился хорошим.

Он точен, понятен и ушёл клиенту без проблем.

Доказывает ли это, что правило человеческой проверки было выполнено?

Нет.

Можно получить качественный результат и при этом не знать, проходил ли он предусмотренную проверку.

Возможна и обратная ситуация: подтверждение проверки существует, но сам результат всё равно оказался слабым.

Это два разных вопроса.

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

Здесь мне нужен только один узкий мост из той темы.

След важен не для того, чтобы заново доказывать качество выполненной задачи, а чтобы ответить на другой вопрос:

можем ли мы подтвердить, что установленное правило действительно сработало в нужный момент?

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

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

Смысл не в том, чтобы собирать как можно больше журналов и доказательств.

Смысл в соответствии.

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

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

Есть ещё одна причина, по которой правила и практика могут расходиться без явного решения «не соблюдать policy».

Рабочая система меняется.

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

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

Это не значит, что так происходит в каждой организации.

Но для operational layer из этого следует важный вопрос:

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

Снова появляется разница между тремя состояниями.

Мы можем знать, что ограничение требуется.

Можем знать, каким механизмом оно реализовано.

И можем отдельно проверять, что механизм остаётся в том состоянии, на которое рассчитываем.

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

Документ задаёт норму.

Рабочая система имеет состояние.

Между ними нужен способ сохранять соответствие.

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

Иногда причина действительно может быть такой.

Но из самого расхождения это ещё не следует.

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

Это не список универсальных причин и не готовая диагностика.

Наоборот, смысл такого разбора как раз в том, чтобы не назначать причину заранее.

Потому что разные механизмы требуют разных действий.

Если фактическая карта использования изменилась, новая редакция policy сама по себе не восстановит картину.

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

Если механизм работает, но подтверждения нет, проблема отличается и от плохого правила, и от его нарушения.

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

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

Только после этого появляется содержательный следующий шаг.

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

Я бы не делала такого вывода.

Правила бывают разными. Рабочие процессы — тоже.

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

Здесь речь не о максимальном количестве контрольных механизмов.

Вопрос гораздо проще:

если правило считается важным, есть ли у него реальная форма существования в той работе, которой оно касается?

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

Иногда этого достаточно, чтобы увидеть очень небольшой разрыв.

Иногда обнаруживается, что рабочий слой вообще не был спроектирован.

А иногда оказывается, что всё уже устроено разумно — просто это никогда не было явно связано с формулировкой policy.

Во всех трёх случаях новая большая policy может быть совершенно не нужна.

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

Это другая работа.

Если исходный вопрос именно о применимости регулирования и правовом маршруте, для него существует отдельный Checklist AI Act 2026.

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

На странице «AI-правила в реальной работе» эта территория описана шире: роли, решения, человеческий контроль, исключения, ответственность и подтверждения.

В конкретной работе я бы не начинала сразу со всего этого списка.

Мне гораздо полезнее взять одно уже существующее правило и провести его через реальную систему.

Где оно должно сработать?

К каким сценариям относится?

Кто и что должен сделать?

Может ли действие пройти дальше без этого?

Что происходит в нетипичной ситуации?

И по чему потом можно увидеть, что правило действительно было частью процесса?

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

Внутренние правила использования ИИ нужны.

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

Но документ не может самостоятельно перенестись в каждую точку работы.

Поэтому после вопроса «что у нас написано?» появляется следующий:

где именно это правило живёт в реальной работе?

Не вообще в культуре компании и не абстрактно «в процессах».

В конкретном сценарии использования ИИ. В конкретном действии. В моменте, когда что-то должно остановиться, потребовать человека, изменить состояние или не произойти без подтверждения.

И затем ещё один:

что позволит нам отличить правило, которое действительно сработало, от правила, которое просто существует в документе?

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

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

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

С этого уже можно начинать разбирать конкретную систему — можно просто написать мне.