The post has been translated automatically. Original language: Russian
The button records the person's participation. Control begins where his disagreement can change the outcome.
Let's imagine Friday, 17:40. The AI agent has prepared a pull request for several hundred lines. The tests are green. The description is low risk, and this description was also compiled by an agent. There are twenty minutes until the release window closes.
The reviewer reviews the changes and clicks Approve.
On Monday, the team finds an error. The log looks perfect: the check is scheduled, the person has confirmed, the time is recorded.
But the magazine doesn't answer the main question. Could the examiner have seen a significant error? Did he have enough information and time? And would Reject have stopped the release, or would it only have created additional work for whoever pushed it?
The button recorded the presence of a person. Did she record the control?
In the article about AI tools, I suggested naming who checks the result and by what criteria. Here I want to focus on the following question: does this test stand up to a real disagreement?
The button captures the event, not the quality of the check.
When I see the human-approved block in the diagram, it's not enough for me to know who clicks Approve. I'm more interested in an alternative route.: what happens if this person doesn't agree.
Consent is compatible with very different processes. In one case, a person independently compared the result with the source and came to the same conclusion. In another, I saw only a resume prepared by the system and found no apparent reason to object. In the third case, doubt appeared, but there were twenty minutes left before the release, and Reject required a separate justification and a conversation with the supervisor.
In all three cases, the same entry will remain in the log.
Approve confirms that the route has reached the person. The quality of control is seen by whether a person is able to disagree.
This is not a question of distrust of an employee. You can't demand a meaningful decision from a person who hasn't been shown the right context, hasn't been given time, or has been given responsibility without authority.
A person may not notice what they haven't been shown.
Verification always involves comparison.
The calculation is checked against the initial values and the rule. The output is based on the document itself. Changing the code with the requirement, architecture, tests, and expected behavior of the system.
If the examiner sees only the AI's recommendation, confidence level, and explanation created by the same AI, he may not have an independent point of support. The explanation helps to understand the logic of the answer, but by itself does not confirm that the answer is correct. The system actually selected the facts, formulated a conclusion, and explained why it was worth agreeing with.
This does not mean that everyone needs to be shown all the data and the internal structure of the model. The amount of context depends on the possible consequences and the known error method. But there should be enough on the screen to notice a significant deviation in this particular task.
Otherwise, the control breaks even before the button is pressed. The person did not miss a visible mistake. They didn't create the conditions for him to see her.
Disagreement is also projected
The interface is never limited to displaying information. He sets the order of attention and the price of each action.
A large risk assessment appears before the initial facts. The green check mark is reassuring before viewing the details. Approve takes one click, and Reject opens four required fields. The queue is measured by speed, but there is no time to sort out a controversial case in yandex.metrica.
Even a competent specialist in such conditions does not face a neutral choice. The system has already made consent the cheapest way to continue working.
In the appendix to the NIST AI RMF, the question is raised separately, to what extent people are really authorized and motivated to challenge the AI result. It also noted the possible value of data on the frequency and reasons for the cancellation of recommendations. This is an important shift: it is not the presence of a position in the scheme that is being tested, but the real ability to go against the proposed answer.
Therefore, the right to disagree does not consist of a single button. A person needs access to relevant data, a clear criterion, time, competence, the ability to request additional information, correct the result, transfer the case above, or stop the action before the consequences occur.
If the next step happens automatically anyway, Reject remains an interface element, not a control mechanism.
The ability to intervene is more important than the signature
This logic also appears in the professional framework. For certain high-risk AI systems, Article 14 of the EU AI Act builds effective control around the capabilities of the designated person. To an appropriate and proportionate extent, such a person must understand the limitations of the system, interpret the result correctly, take into account the risk of excessive trust in AI, refuse to use the system or result, change or cancel the result, interfere with the operation and safely stop the system.
This is not a universal and already valid duty for any AI. After the entry into force of Digital Omnibus 2026, the relevant requirements for high-risk systems are applied according to a delayed schedule: for systems from Annex III from December 2, 2027, for applicable systems from Annex I from August 2, 2028. The contexts of the European law and the NIST voluntary framework are different. But in both cases, human control is described through the ability to influence the outcome, rather than through the mere fact of human presence.
A person is not required to check every result.
For some applications, the check is really worth it until the next step. Where speed or scale make it a fiction, human control has to be transferred: to pre-launch testing, escalation thresholds, selective monitoring, and the ability to stop or correct consequences.
These mechanisms are not interchangeable. A subsequent audit does not turn an action that has already been performed into a decision that has been verified in advance by a person. The point is not the amount of manual work, but that the intervention takes place before the irreversible consequences.
A case test that cannot be approved
The usual question "are you checking the AI answers?" almost always gets a positive response. I would have checked differently: I took a secure historical or synthetic case with a known significant defect in advance and ran it through the usual interface, instructions, deadlines, and credentials.
Did the person see the problem? Could I confirm it from an independent source? What happened after Reject? Has the next step stopped?
If the defect is not noticed, the problem may be in the presentation of information, criteria, training, or workload. If you noticed but couldn't influence it, the problem is with the authority or the route of escalation. If a person pressed Reject, but the action happened anyway, the sequence of the process itself is disrupted.
These are different malfunctions. An additional check mark "verified by human" will not fix any of them.
This test does not test the employee's loyalty, but the system's performance. Therefore, there are no hidden checks and mixing errors into live solutions: only a secure case and a known defect in advance.
The Kazakh framework already distinguishes between autonomy and the possibility of cancellation
In Kazakhstan, the Law "On Artificial Intelligence" already links levels of autonomy with a person's ability to influence the outcome: with low autonomy, the final choice remains with the person, with medium he can adjust or cancel the decision, with high such intervention is impossible. The law also requires constant monitoring within the role and the preservation of human autonomy.
The Digital Code, which entered into force on July 12, 2026, defines a fully automated decision as one made without human involvement in assessing the circumstances or approving the result, with a reservation about the cases provided for by the laws of Kazakhstan or the agreement. The presence of human participation is included in the formal definition of this category, however, article 43 itself does not establish criteria for the content of such participation. The entity in respect of which such a decision is being made has the right, in cases and in accordance with the procedure established by the legislation of Kazakhstan, to request a review with the participation of an authorized specialist if the decision entails legal consequences or may affect its rights and legitimate interests.
These general rules set the direction, but by themselves do not answer the operational question. Specific requirements may follow from industry legislation, agreements, and the context of the decision. Within their limits, companies will still have to determine what the employee will see, how much time and what authority they will receive, whether pressing Reject will stop the next step, and then test the mechanism in real load.
The log should store more than just Approve
For a meaningful solution, one "user clicked Approve" entry is not enough.
A useful trace allows you to restore which version of the result and source data the person was working with, so that they could check whether they changed the recommendation, requested additional information, and where they transferred the disputed case. NIST practice materials suggest documenting the extent of human control and tracking cancellations, complaints, errors, reaction times, revisions, and escalations. The recording depth again depends on the consequences. It makes no sense to turn every low-risk AI draft into a small investigation.
Another important thing is that the Reject number should not become a quota. A high proportion of consents does not in itself prove that verification is decorative. But if a person never changes the result, stops the action, or raises a controversial case, the team has a good reason to conduct a disagreement test.
Let's return to the pull request from the beginning of the article. If the reviewer could see the defect, had the time and the right to stop the release, and the system was really waiting for his decision, human control worked, even if the code was approved after clarification.
If a person saw only the AI output, and disagreement did not change the next step, a human signature remained in the log. There is almost nothing left in the man's decision.
Therefore, when I see the Approve button, I would first ask what happens after Reject.
If there is no answer, we still don't know if the solution has been verified.
Кнопка фиксирует участие человека. Контроль начинается там, где его несогласие способно изменить исход.
Представим пятницу, 17:40. AI-агент подготовил pull request на несколько сотен строк. Тесты зелёные. В описании стоит low risk, и это описание тоже составил агент. До закрытия окна релиза двадцать минут.
Проверяющий просматривает изменения и нажимает Approve.
В понедельник команда находит ошибку. Журнал при этом выглядит безупречно: проверка назначена, человек подтвердил, время записано.
Но журнал не отвечает на главное. Мог ли проверяющий увидеть существенную ошибку? Было ли у него достаточно информации и времени? И остановил бы Reject релиз или только создал бы дополнительную работу тому, кто его нажал?
Кнопка записала присутствие человека. Записала ли она контроль?
В статье про AI-инструменты я предлагала назвать, кто проверяет результат и по какому критерию. Здесь хочу задержаться на следующем вопросе: выдерживает ли эта проверка реальное несогласие?
Кнопка фиксирует событие, а не качество проверки
Когда я вижу в схеме блок «согласовано человеком», мне недостаточно знать, кто нажимает Approve. Мне интереснее альтернативный маршрут: что произойдёт, если этот человек не согласится.
Согласие совместимо с очень разными процессами. В одном человек самостоятельно сопоставил результат с источником и пришёл к тому же выводу. В другом увидел только подготовленное системой резюме и не нашёл видимой причины возражать. В третьем сомнение появилось, но до релиза оставалось двадцать минут, а Reject требовал отдельного обоснования и разговора с руководителем.
Во всех трёх случаях в журнале останется одинаковая запись.
Approve подтверждает, что маршрут дошёл до человека. Качество контроля видно по тому, способен ли человек не согласиться.
Это не вопрос недоверия к сотруднику. Нельзя требовать содержательного решения от человека, которому не показали нужный контекст, не оставили времени или дали ответственность без полномочий.
Человек может не заметить того, что ему не показали
Проверка всегда предполагает сравнение.
Расчёт сверяют с исходными значениями и правилом. Вывод по документу с самим документом. Изменение кода с требованием, архитектурой, тестами и ожидаемым поведением системы.
Если проверяющий видит только рекомендацию AI, уровень уверенности и объяснение, созданное тем же AI, у него может не быть независимой точки опоры. Объяснение помогает понять логику ответа, но само по себе ещё не подтверждает, что ответ верен. Система фактически отобрала факты, сформулировала вывод и рассказала, почему с ним стоит согласиться.
Это не означает, что каждому человеку нужно показывать все данные и внутреннее устройство модели. Объём контекста зависит от возможных последствий и известного способа ошибки. Но на экране должно быть достаточно, чтобы заметить существенное отклонение именно в этой задаче.
Иначе контроль ломается ещё до кнопки. Человек не пропустил видимую ошибку. Ему не создали условия, в которых её можно было увидеть.
Несогласие тоже проектируется
Интерфейс никогда не ограничивается отображением информации. Он задаёт порядок внимания и цену каждого действия.
Крупная оценка риска появляется раньше исходных фактов. Зелёная отметка «проверка пройдена» успокаивает до просмотра деталей. Approve занимает один клик, а Reject открывает четыре обязательных поля. Очередь измеряется скоростью, но время на разбор спорного случая в метрике не предусмотрено.
Даже компетентный специалист в таких условиях встречается не с нейтральным выбором. Система уже сделала согласие самым дешёвым продолжением работы.
В приложении к NIST AI RMF отдельно поставлен вопрос, насколько люди действительно уполномочены и мотивированы оспаривать результат AI. Там же отмечена возможная ценность данных о частоте и причинах отмены рекомендаций. Это важное смещение: проверяется не наличие должности в схеме, а реальная способность пойти против предложенного ответа.
Поэтому право не согласиться состоит не из одной кнопки. Человеку нужны доступ к релевантным данным, понятный критерий, время, компетенция, возможность запросить дополнительную информацию, исправить результат, передать случай выше или остановить действие до наступления последствий.
Если следующий шаг всё равно происходит автоматически, Reject остаётся элементом интерфейса, а не механизмом контроля.
Способность вмешаться важнее подписи
Эта логика появляется и в профессиональных рамках. Для определённых высокорисковых AI-систем статья 14 EU AI Act строит эффективный контроль вокруг возможностей назначенного человека. В надлежащем и соразмерном объёме такой человек должен понимать ограничения системы, правильно интерпретировать результат, учитывать риск чрезмерного доверия к AI, отказаться от использования системы или результата, изменить или отменить результат, вмешаться в работу и безопасно остановить систему.
Это не универсальная и уже действующая для любого AI обязанность. После вступления в силу Digital Omnibus 2026 соответствующие требования к высокорисковым системам применяются по отложенному графику: для систем из Annex III с 2 декабря 2027 года, для применимых систем из Annex I с 2 августа 2028 года. Контексты у европейского закона и добровольной рамки NIST разные. Но в обоих человеческий контроль описан через возможность повлиять на исход, а не через сам факт присутствия человека.
Человек не обязан проверять каждый результат
Для одних применений проверка действительно стоит до следующего шага. Там, где скорость или масштаб делают её фикцией, человеческий контроль приходится переносить: в тестирование до запуска, пороги эскалации, выборочный мониторинг и возможность остановить или исправить последствия.
Эти механизмы не взаимозаменяемы. Последующий аудит не превращает уже исполненное действие в решение, заранее проверенное человеком. Смысл не в количестве ручной работы, а в том, чтобы вмешательство происходило до необратимого последствия.
Тест случая, который нельзя одобрить
Обычный вопрос «вы проверяете ответы AI?» почти всегда получает положительный ответ. Я бы проверяла иначе: взяла безопасный исторический или синтетический кейс с заранее известным существенным дефектом и пропустила его через обычный интерфейс, инструкции, сроки и полномочия.
Увидел ли человек проблему? Смог ли подтвердить её по независимому источнику? Что произошло после Reject? Остановился ли следующий шаг?
Если дефект не заметили, проблема может быть в представлении информации, критерии, подготовке или нагрузке. Если заметили, но не смогли повлиять, проблема в полномочиях или маршруте эскалации. Если человек нажал Reject, а действие всё равно произошло, нарушена последовательность самого процесса.
Это разные неисправности. Дополнительная галочка «проверено человеком» не исправит ни одну из них.
Этот тест проверяет не лояльность сотрудника, а работоспособность системы. Поэтому никаких скрытых проверок и подмешивания ошибок в живые решения: только безопасный кейс и заранее известный дефект.
Казахстанская рамка уже различает автономность и возможность отмены
В Казахстане Закон «Об искусственном интеллекте» уже связывает уровни автономности с возможностью человека влиять на исход: при низкой автономности окончательный выбор остаётся за человеком, при средней он может скорректировать или отменить решение, при высокой такое вмешательство невозможно. Закон также требует постоянного контроля в пределах роли и сохранения человеческой автономии.
Цифровой кодекс, вступивший в силу 12 июля 2026 года, определяет полностью автоматизированное решение как принятое без участия человека в оценке обстоятельств либо утверждении результата, с оговоркой о случаях, предусмотренных законами Казахстана или соглашением. Наличие человеческого участия входит в формальное определение этой категории, однако сама статья 43 не устанавливает критериев содержательности такого участия. Субъект, в отношении которого принимается такое решение, вправе в случаях и порядке, установленных законодательством Казахстана, потребовать пересмотра с участием уполномоченного специалиста, если решение влечёт юридические последствия либо способно повлиять на его права и законные интересы.
Эти общие нормы задают направление, но сами по себе не отвечают на операционный вопрос. Конкретные требования могут следовать из отраслевого законодательства, соглашения и контекста решения. В их пределах компаниям всё равно предстоит определить, что увидит сотрудник, сколько времени и какие полномочия получит, остановит ли нажатие Reject следующий шаг, а затем проверить механизм в реальной нагрузке.
Журнал должен хранить не только Approve
Для значимого решения одной записи «пользователь нажал Approve» мало.
Полезный след позволяет восстановить, с какой версией результата и исходных данных работал человек, что он мог проверить, менял ли рекомендацию, запрашивал ли дополнительные сведения и куда передал спорный случай. Практические материалы NIST предлагают документировать степень человеческого контроля и отслеживать отмены, жалобы, ошибки, время реакции, пересмотры и эскалации. Глубина записи снова зависит от последствий. Нет смысла превращать каждый низкорисковый AI-черновик в маленькое расследование.
Важно и другое: число Reject не должно становиться квотой. Высокая доля согласий сама по себе не доказывает декоративность проверки. Но если человек никогда не меняет результат, не останавливает действие и не поднимает спорный случай, у команды появляется хороший повод провести тест несогласия.
Вернёмся к pull request из начала статьи. Если проверяющий мог увидеть дефект, имел время и право остановить релиз, а система действительно ждала его решения, человеческий контроль работал, даже если после уточнений код всё же был одобрен.
Если человек видел только вывод AI, а несогласие не меняло следующий шаг, в журнале осталась человеческая подпись. В решении человека почти не осталось.
Поэтому, встречая кнопку Approve, я бы сначала спросила, что происходит после Reject.
Если ответа нет, мы ещё не знаем, было ли решение проверено.
Share
