Какие сведения должно содержать объяснение решения с участием ИИ, чтобы затронутый человек мог эффективно его оспорить?

Объяснение должно показывать не только, что произошло, но и какие данные, правила, роли ИИ и людей существенно повлияли на результат.

Эффективное объяснение сначала называет точное решение и его последствия для человека. Затем оно показывает роли ИИ и людей, существенные использованные данные и их источник, а также правила, пороги и неопределённость, повлиявшие на итог. Должны быть ясны недостающие или исправимые сведения и путь оспаривания. Фраза «Так рассчитал алгоритм» не объясняет причину результата.

При отказе по заявлению фраза «Система признала вас не соответствующим требованиям» бесполезна. Нужно знать, какие сведения посчитали неверными или недостающими, какое правило применили и что можно исправить либо оспорить.

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

Общее объяснение описывает работу модели в целом; объяснение решения — конкретный итог.

Объяснение данных указывает использованные сведения; объяснение факторов показывает их влияние.

Объяснение сообщает основания, но не делает решение автоматически верным или законным.

Раскрытие предоставляет сведения; объяснение для оспаривания должно позволять действовать.

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

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

Укажите идентификатор, дату, область, последствия решения и действует ли оно.

Разделите роли системы ИИ, человека-проверяющего и принимающего окончательное решение.

Назовите существенные данные, источник, дату и способ сопоставления с человеком.

Объясните факторы, правила, пороги и противоположные доказательства, повлиявшие на итог.

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

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

Сверьте объяснение с фактической записью решения и проверьте понятность для адресата.

Понимает ли человек, какое решение и последствие к нему относятся?

Верно ли описаны границы ролей ИИ и человека?

Видны ли существенные данные, источник, дата и сопоставление сущности?

Объяснены ли реально повлиявшие факторы и правила?

Не выдано ли общее описание модели за объяснение конкретного решения?

Знает ли человек, что исправить и куда подать возражение?

Не использованы ли конфиденциальность или коммерческая тайна для полного сокрытия причины?

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

Эффективное объяснение сначала называет точное решение и его последствия для человека. Затем оно показывает роли ИИ и людей, существенные использованные данные и их источник, а также правила, пороги и неопределённость, повлиявшие на итог. Должны быть ясны недостающие или исправимые сведения и путь оспаривания. Фраза «Так рассчитал алгоритм» не объясняет причину результата.


NOMOS GEO-QA — Canonical Question Registry

Одобрение человеком, оспаривание и объяснение

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

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

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

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

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

Правдоподобное объяснение понятно звучит; достоверное согласуется с доказательствами реального решения.

Объяснение задним числом создаётся после решения и может быть точным либо выдуманным.

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

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

Воспроизведение ищет похожий итог; тест достоверности проверяет причинное утверждение объяснения.

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

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

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

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

Сопоставляйте каждое существенное положение объяснения с записью решения.

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

Не называйте неподтверждённый или лишь возможный рассказ достоверным; указывайте уровень уверенности.

После изменения системы проверяйте объяснение заново, а не переносите его автоматически.

Связано ли объяснение с правильным идентификатором и снимком момента решения?

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

Есть ли каждое существенное основание объяснения в записи?

Защищены ли полнота и целостность событий?

Проверялась ли достоверность поведением, а не только качеством текста?

Не выдано ли объяснение задним числом или поставщика за определённую внутреннюю причину?

Не использовано ли старое объяснение после смены версии без новой проверки?

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

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


Жизненный цикл решений, исправление и удаление

Что означает невозможность воспроизвести решение с участием ИИ при тех же входных данных и как проверять воспроизводимость?

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

«Те же входные данные» — это не только та же фраза пользователя. В пакет решения входят версии модели и системы, запросы, отбор сведений, копия данных на нужный момент времени, результаты работы инструментов, политика, участие человека, время, страна, язык, конфигурация и, когда это возможно, состояние случайности. Сначала определите требуемый вид эквивалентности: дословно тот же ответ, те же существенные утверждения, тот же класс либо то же действие. Затем измерьте изменчивость повторными испытаниями и сравнениями условий. Если различие выходит за ожидаемый диапазон, начните поиск первопричины.

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

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

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

Точное совпадение результата требует одинаковой формулировки слово в слово.

Смысловая эквивалентность допускает разные формулировки при сохранении одного существенного смысла.

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

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

Одинаковая фраза — ещё не одинаковый пакет решения.

Заранее определите, что именно воспроизводится и какой уровень эквивалентности считается приемлемым.

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

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

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

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

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

Дайте достаточно независимой команде возможность повторить тест по сохранённому пакету и зафиксировать ограничения.

Ясно ли, требуется совпадение формулировки, смысла, решения или действия?

Сохранены ли все существенные части реального пакета решения?

Не объявлен ли успех или провал по одному повтору?

Проверены ли дрейф модели, данных, отбора сведений, инструментов, политики и времени?

Не скрыты ли изменения критических решений внутри средней оценки сходства?

Имеет ли независимая проверка доступ к тем же доказательствам и правилам решения?

Оставлены ли необъяснённые различия в состоянии UNRESOLVED вместо ложной уверенности?

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

«Те же входные данные» — это не только та же фраза пользователя. В пакет решения входят версии модели и системы, запросы, отбор сведений, копия данных на нужный момент времени, результаты работы инструментов, политика, участие человека, время, страна, язык, конфигурация и, когда это возможно, состояние случайности. Сначала определите требуемый вид эквивалентности: дословно тот же ответ, те же существенные утверждения, тот же класс либо то же действие. Затем измерьте изменчивость повторными испытаниями и сравнениями условий. Если различие выходит за ожидаемый диапазон, начните поиск первопричины.


Нужно ли пересматривать прежние решения, когда меняются модель, данные, запрос, политика или версия инструмента системы ИИ?

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

Сначала зафиксируйте версию, цель, охват и существенное влияние изменения. Затем определите, какие классы прежних решений могли измениться с точки зрения идентичности, данных, доказательств, полномочий, объяснения, безопасности, справедливости, правовых последствий или связанных действий в нижестоящих системах. Где возможно, измерьте влияние на выборке и в сравнительных тестах. Для критических результатов и решений, которые продолжают действовать, проведите целевой пересмотр. Новая версия не исправляет прошлое автоматически, а новое правило не делает прежнее решение автоматически ошибочным.

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

Повторный разбор всех прошлых решений без разбора создаёт несоразмерные затраты. Полный отказ от пересмотра позволяет известной ошибке и дальше влиять на людей и системы.

Смена версии — техническое событие; существенное влияние требует отдельного доказательства.

Исправление, внесённое сегодня, само по себе не меняет прежнее решение.

Историческую точность оценивают по сведениям и правилам того времени; текущую действительность — по сегодняшнему состоянию.

Ретроспективный анализ влияния выявляет группу риска; повторное рассмотрение заново решает конкретный случай.

Продолжающееся действие означает, что прежнее решение и сегодня вызывает последствия для человека или системы.

Обновление системы не исправляет прошлое автоматически.

Сопоставьте изменённые модель, данные, запрос, политику, инструмент и конфигурацию с предыдущей версией поле за полем.

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

Определите затронутые типы решений, периоды, группы людей, сущности и связанные последующие результаты.

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

Начните целевой пересмотр при критической ошибке, подмене лица, продолжающемся вреде или правовом основании.

Исправьте пересмотренные решения и передайте результат во все затронутые системы.

Обоснованно зафиксируйте область, признанную незатронутой, исключения и оставшуюся неопределённость.

Зафиксированы ли все изменённые компоненты и их версии?

Не признано ли изменение несущественным без проверки влияния?

Определены ли затронутые периоды, решения, люди и нижестоящие системы?

Сравнивались ли старая и новая версии в одинаковых условиях?

Пересмотрены ли критические решения с продолжающимися последствиями?

Не перезаписала ли новая версия исторические записи без следа?

Есть ли доказательства исправленного результата в действующей системе и его распространения?

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

Сначала зафиксируйте версию, цель, охват и существенное влияние изменения. Затем определите, какие классы прежних решений могли измениться с точки зрения идентичности, данных, доказательств, полномочий, объяснения, безопасности, справедливости, правовых последствий или связанных действий в нижестоящих системах. Где возможно, измерьте влияние на выборке и в сравнительных тестах. Для критических результатов и решений, которые продолжают действовать, проведите целевой пересмотр. Новая версия не исправляет прошлое автоматически, а новое правило не делает прежнее решение автоматически ошибочным.


Как отличать историческую точность прежнего решения с участием ИИ от его действительности сегодня?

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

Для каждого решения задавайте как минимум два вопроса о времени. Историческая точность показывает, подтверждался ли результат фактами, источниками, правилами и полномочиями в момент принятия. Текущая действительность показывает, остаётся ли решение активным сегодня и не истекло ли оно, не было ли приостановлено, отозвано, исправлено или заменено. Прежнее решение может продолжать вызывать последствия даже после утраты силы; такие последствия нужно отдельно обнаружить и устранить.

Водительское удостоверение, действовавшее в прошлом году, тогда было настоящим. Если срок истёк сегодня, старый документ не становится поддельным — он просто больше не даёт права управлять автомобилем.

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

Историческая точность — соответствие фактам на опорный момент решения.

Историческая действительность — наличие полномочий и силы решения в тот момент.

Текущая точность — соответствие исходных фактов сегодняшнему состоянию.

Текущая действительность — наличие у решения правовой или операционной силы сегодня.

Продолжающееся действие — последствия, которые утратившее силу решение всё ещё вызывает в системах.

Решение, правильное вчера, не обязательно применимо сегодня.

Храните отдельно время принятия решения, опорное время данных, начало действия и конец срока.

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

Различайте состояния: активно, приостановлено, срок истёк, отозвано, исправлено и заменено.

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

Ищите продолжающиеся последствия в профилях, выплатах, доступе, рекомендациях и представлении.

Связывайте новое решение со старым явным отношением и датой вступления в силу.

Проверяйте исправление на затронутых действующих и нижестоящих поверхностях.

Различены ли время решения и опорное время данных и правила?

Записаны ли условия начала и окончания действия?

Не используется ли прежнее решение как текущее полномочие вместо исторической записи?

Не изменили ли новые сведения задним числом оценку точности прежнего решения?

Видны ли связи приостановления, отзыва, исправления и замены?

Искали ли продолжающиеся последствия утратившего силу решения?

Выбирает ли действующая система текущее уполномоченное решение?

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

Для каждого решения задавайте как минимум два вопроса о времени. Историческая точность показывает, подтверждался ли результат фактами, источниками, правилами и полномочиями в момент принятия. Текущая действительность показывает, остаётся ли решение активным сегодня и не истекло ли оно, не было ли приостановлено, отозвано, исправлено или заменено. Прежнее решение может продолжать вызывать последствия даже после утраты силы; такие последствия нужно отдельно обнаружить и устранить.


Как в машиночитаемой форме фиксировать начало и окончание действия, приостановление, отзыв, исправление и замену решения с участием ИИ?

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

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

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

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

Идентификатор решения обозначает одно семейство решения; идентификатор версии — конкретное содержание.

Событие фиксирует уполномоченное изменение состояния решения.

Текущее состояние — представление, вычисленное по событиям; история событий — цепочка доказательств.

Исправление устраняет неточное содержание; замена показывает, что новое решение заняло место прежнего.

Приостановление — временное операционное состояние; отзыв — уполномоченное прекращение действия решения.

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

Определите постоянный идентификатор решения, неизменяемый идентификатор версии и явную схему.

Записывайте каждое изменение жизненного цикла отдельным идентификатором события и надёжной временной меткой.

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

Задайте допустимые переходы состояний и блокируйте недопустимые машиночитаемыми правилами.

Связывайте исправление, отзыв и замену в обе стороны, не удаляя прежнюю версию.

Формируйте и пересчитывайте вид текущего состояния из потока событий по однозначным правилам.

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

Уникальны, постоянны и версионированы ли идентификаторы решения и событий?

Не перезаписано ли прежнее содержание решения или событие?

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

Блокируются ли недопустимые или неуполномоченные переходы?

Прослеживаются ли связи исправления, отзыва и замены в обе стороны?

Можно ли заново получить текущее состояние из сохранённых событий?

Достигли ли нижестоящие системы того же текущего состояния?

Добавление событий без перезаписи усиливает неизменность и прослеживаемость, но само по себе не доказывает фактическую правильность или правомерность события. Нужны также надёжные средства времени, идентификации, полномочий и целостности.

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


Как передавать исправление, отзыв или признание недействительным решения с участием ИИ в нижестоящие системы и доказывать завершение?

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

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

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

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

Подтверждение получения показывает, что событие дошло до цели; подтверждение применения — что изменение обработано.

Обратное считывание означает независимое чтение текущего состояния целевой системы.

Равенство полей проверяет одно значение, смысловая эквивалентность — один смысл, поведенческая — правильное действие.

Прямая цель получает решение первой; косвенная затрагивается через другую систему.

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

Отправка — ещё не распространение; распространение подтверждается изменением в целевой системе.

Внесите в перечень все прямые и косвенные цели, кеши, экспорты, отчёты и сторонние системы, получающие решение.

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

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

Соберите подтверждения получения и применения с идентификатором решения и версией цели.

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

Ведите неудачные, задержанные и внешние цели как открытые задачи с ответственным и датой повторной попытки.

Не объявляйте распространение завершённым, пока не проверена каждая обязательная цель.

Все ли прямые и косвенные цели действительно внесены в перечень?

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

Различены ли получение и применение?

Считано ли текущее состояние независимо из целевой системы?

Правильно ли ведёт себя критическая цель или совпало только значение поля?

Не закрыты ли неудачные или внешние цели как завершённые?

Может ли нижестоящая система позднее восстановить старое решение?

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

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


Как предотвратить повторное появление старого решения из кеша, архива, резервной копии, экспорта, памяти ИИ или у третьей стороны после исправления всех известных систем?

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

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

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

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

Постоянная отметка удаления, иногда называемая tombstone, показывает, что объект удалён или больше не является текущим.

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

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

Аннулирование кеша устраняет видимую копию; машинное разучивание касается усвоенного моделью влияния.

Повторное появление — возвращение старого содержания в активное состояние через восстановление, импорт или внешний источник.

Старая копия может вернуться; прежнее решение не должно вернуть себе силу.

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

Для исправления или отзыва запишите постоянную отметку удаления, последовательность исправления и приоритет версии.

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

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

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

Проверяйте память ИИ, векторные записи и влияние модели отдельно; не заявляйте о машинном разучивании без доказательств.

Периодически наблюдайте внешние платформы и ответы моделей; при повторном появлении открывайте инцидент.

Известны ли все источники, способные вернуть старое решение, и их владельцы?

Живёт ли отметка исправления дольше резервных копий и старых снимков?

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

Может ли исторический архив попасть в отбор текущих сведений?

Проверялись ли кеш, векторная запись, память и влияние модели отдельно?

Не объявлено ли машинное разучивание завершённым лишь по команде или заявлению поставщика?

Есть ли мониторинг и маршрут повторного открытия при внешнем появлении?

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

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


Как согласовать запрос на удаление решения или данных с требованиями аудита, происхождения, правового хранения и исторической записи?

Удаляйте ненужное содержимое; сохраняйте только минимальную запись, необходимую для подотчётности, на явном основании и при строгом контроле доступа.

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

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

Удаление всего может уничтожить доказательства для аудита или восстановления прав. Хранение всего «ради аудита» лишает запрос на забвение смысла. Разделение объектов и целей удерживает систему от обеих крайностей.

Удаление прекращает доступ и обычное использование; технический способ зависит от ситуации.

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

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

Правовой запрет на удаление — временное и проверяемое ограничение хранения ради конкретной юридической необходимости.

Квитанция аудита доказывает операцию; она не является полной резервной копией удалённого содержания.

Удаляйте ненужное; сохраняйте лишь минимальные доказательства, необходимые для подотчётности.

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

Для каждого объекта определите владельца, цель, основание, срок хранения и подходящее действие.

Удалите или уничтожьте ненужное; минимизируйте содержание и доступ любой сохраняемой записи.

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

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

В квитанции оставьте идентификатор объекта, метод, охват, время, результат и сохраняющееся исключение.

Проверьте, что ограниченные записи нельзя повторно использовать, а истёкшие запреты действительно снимаются.

Разложен ли запрос на все объекты данных и решений?

Есть ли у каждого сохраняемого поля конкретная цель, основание и срок?

Не сохранена ли полная копия удалённого содержания под предлогом аудита?

Узок, уполномочен, датирован и регулярно пересматривается ли правовой запрет?

Учтены ли нижестоящие системы, резервные копии, экспорты и третьи стороны?

Не спутано ли удаление хранимых данных с устранением влияния на модель?

Объяснены ли заявителю квитанция, исключение и оставшаяся неопределённость?

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

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


Если система ИИ заявляет «Я удалила данные», как доказать удаление, невозможность восстановления и прекращение использования данных моделью или памятью?

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

Сначала определите охват удаления и перечислите все пути появления копий. Для каждой цели примените подходящий способ. Затем проверьте отсутствие записи, запрет недопустимого доступа, невозможность повторного использования, очистку кешей и памяти, поведение при восстановлении резервной копии и, где уместно, фактическое уничтожение ключа шифрования. Удаление хранимых данных не устраняет автоматически то, чему на них научилась модель. Заявление о машинном разучивании или переобучении проверяют отдельно подходящими тестами запоминания, принадлежности и поведения. Если доказательств нет, результат — «не подтверждено».

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

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

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

Очистка носителя стремится сделать доступ к целевым данным практически невозможным при заданном уровне усилий.

Криптографическое стирание при подходящих условиях прекращает доступ, делая ключ шифрования непригодным.

Очистка кеша или памяти не устраняет автоматически влияние обучающих данных на модель.

Машинное разучивание стремится уменьшить или устранить влияние заданных обучающих данных; результат всё равно требует проверки.

Команда удаления — это действие; доказательство удаления проверяет результат и его границы.

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

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

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

Проверьте обратное считывание, поиск, доступ и повторное использование целевого объекта.

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

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

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

Охватывает ли удаление каждую копию и производный объект?

Подходит ли выбранный метод носителю и чувствительности данных?

Есть ли доказательства помимо собственного заявления поставщика системы?

Проводились ли фактические тесты обратного считывания, доступа и повторного использования?

Возвращаются ли старые данные после восстановления резервной копии или перестроения кеша?

Не выдано ли удаление из хранилища за машинное разучивание?

Явно ли указаны оставшаяся неопределённость и непроверяемые третьи стороны?

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

Сначала определите охват удаления и перечислите все пути появления копий. Для каждой цели примените подходящий способ. Затем проверьте отсутствие записи, запрет недопустимого доступа, невозможность повторного использования, очистку кешей и памяти, поведение при восстановлении резервной копии и, где уместно, фактическое уничтожение ключа шифрования. Удаление хранимых данных не устраняет автоматически то, чему на них научилась модель. Заявление о машинном разучивании или переобучении проверяют отдельно подходящими тестами запоминания, принадлежности и поведения. Если доказательств нет, результат — «не подтверждено».


Как не допустить влияния соответствующих данных на новые решения ИИ, пока удаление или машинное разучивание ещё продолжается?

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

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

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

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

Временное хранение не разрешает обычное использование в решениях или обучении.

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

Карантин отделяет объект; правило неиспользования блокирует каждый относящийся к делу путь применения.

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

Снятие ограничения требует подтверждённых условий, а не одного лишь истечения времени.

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

Запишите ограниченные данные, человека, цель, системы, причину, ответственного, начало и дату пересмотра.

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

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

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

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

Фиксируйте заблокированные попытки и ошибочные использования в записях инцидента и оповещениях.

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

Явны ли ограниченный объект, причина, охват, ответственный и сроки?

Внесены ли все пути решений и использования данных в перечень?

Действительно ли ограничение обеспечено в извлечении, обучении, памяти, экспорте и инструментах?

Не продолжается ли запретное использование через производные данные или кеш?

Есть ли безопасная остановка или человеческая альтернатива для решения с серьёзными последствиями?

Обнаруживаются ли нарушения и разбираются ли они как инциденты?

Запускает ли истечение срока автоматическое использование или проверку доказательств перед снятием?

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

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


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

Снимайте ограничение потому, что причина устранена, системы готовы и уполномоченное лицо одобрило доказательства, а не потому, что истёк срок.

Для каждой причины ограничения должны быть пройдены заранее определённые условия снятия. Проверьте текущие уполномоченные данные и состояние решения, изучите доказательства удаления, исправления или машинного разучивания и получите нужный уровень уверенности для модели, слоя извлечения и нижестоящих систем. Пересмотрите решения, принятые во время ограничения, завершите необходимые уведомления и подготовьте откат и мониторинг. Уполномоченный владелец решения — человек — фиксирует PASS, FAIL или UNRESOLVED по каждому условию. Условное снятие допустимо лишь в узкой области и с дополнительными мерами контроля.

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

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

Истечение срока начинает проверку, а не автоматически снимает ограничение.

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

Полное снятие открывает все разрешённые способы использования; частичное — только определённую область меньшего риска.

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

Решение о снятии и фактическое включение в нижестоящих системах — разные уровни доказательств.

Календарь не разрешает снятие ограничения; это делают проверенные условия и уполномоченный человек.

Перечислите исходные причины ограничения и измеримые условия снятия для каждой.

Заново проверьте текущий полномочный источник данных, решения, идентичности, полномочий и исправления.

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

Определите людей и решения, затронутые за время ограничения, и внесите необходимые исправления.

Получите одобрение уполномоченного лица, достаточно независимого от исполнителя изменения.

Запишите, является ли снятие полным, частичным или условным, а также откат, оповещения и пороги мониторинга.

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

Закрыта ли отдельно каждая причина ограничения?

Проверены ли текущие полномочные данные и состояние решения?

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

Рассмотрены ли решения и вред, возникшие в период ограничения?

Одобрено ли снятие уполномоченным и достаточно независимым человеком?

Готовы ли откат, мониторинг и условия повторного ограничения?

Совпадают ли запись решения и фактическое использование в нижестоящих системах?

Требуемые доказательства зависят от архитектуры, типа данных, риска, доступа поставщика и применимого права. Некоторые эффекты во внешних моделях нельзя проверить полностью; тогда узкое ограничение или результат UNRESOLVED могут быть уместнее полного снятия.

Для каждой причины ограничения должны быть пройдены заранее определённые условия снятия. Проверьте текущие уполномоченные данные и состояние решения, изучите доказательства удаления, исправления или машинного разучивания и получите нужный уровень уверенности для модели, слоя извлечения и нижестоящих систем. Пересмотрите решения, принятые во время ограничения, завершите необходимые уведомления и подготовьте откат и мониторинг. Уполномоченный владелец решения — человек — фиксирует PASS, FAIL или UNRESOLVED по каждому условию. Условное снятие допустимо лишь в узкой области и с дополнительными мерами контроля.


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

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

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

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

Бессрочная задержка позволяет создать последствия отказа без объяснения причин и возможности оспорить. Со временем растут потеря услуги или возможности и нагрузка на человека.

Обоснованное ожидание — промежуточное состояние с владельцем, прогрессом, связью и маршрутом решения.

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

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

Скрытый отказ создаёт устойчивое последствие отказа без явного решения об отказе.

Полезное обновление сообщает о выполненной работе, препятствии и следующей дате, а не просто «на рассмотрении».

Ожидание должно вести к прогрессу, защите, эскалации или решению; оно не может навсегда заменить решение.

Сразу запишите причину и охват ограничения, ответственного за дело и решение и влияние на человека.

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

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

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

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

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

По достижении предела запускайте эскалацию, формальное мотивированное решение, право оспаривания и уместное средство исправления.

Есть ли у каждого ожидающего дела причина, владелец, следующее действие и дата?

Идёт ли содержательный прогресс или рассылается только общий статус?

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

Не скрывает ли цепочка продлений общую длительность?

Не обнулили ли перевод или повторное открытие исходный срок дела?

Оценены ли потеря услуги, нагрузка на человека и безопасные альтернативы?

Не стало ли ожидание фактическим отказом без мотивированного решения и пути оспаривания?

Точные сроки ответа и последствия скрытого либо подразумеваемого отказа зависят от юрисдикции, отрасли, договора, операции и типа решения. NOMOS GEO не устанавливает единое число дней; он предлагает правила управления, не позволяющие временной мере стать бесхозной и безграничной.

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


Безопасность, манипуляции и целостность при инцидентах

Как управлять безопасной остановкой, временными мерами, человеческим контролем и перезапуском системы ИИ в аварийной или высокорисковой ситуации?

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

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

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

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

Остановка прекращает рискованную операцию; ограничение затрагивает только заданные функции или пользователей.

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

Откат возвращает проверенное прежнее состояние, но не обязательно устраняет первопричину.

Перезапуск — не нажатие кнопки, а прохождение определённых условий безопасности.

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

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

Запишите идентификатор инцидента, причину, время, охват остановки и лицо, принявшее решение.

Остановите только необходимые для контроля риска компоненты и не расширяйте влияние без причины.

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

Неизменно сохраните записи инцидента, версии модели и данных, запросы, ответы и трассировки инструментов.

Зафиксируйте первопричину, ответственного за устранение, срок и условия перезапуска.

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

Возвращайте услугу поэтапно с живым мониторингом, планом отката и порогом повторной остановки.

Обоснованы ли остановка и её охват конкретным риском?

Рассмотрены ли безопасная альтернатива и непрерывность услуги?

Сохранены ли доказательства инцидента с защитой целостности?

Отличена ли первопричина от видимого симптома?

Были ли условия перезапуска проверяемыми и заданными заранее?

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

Проверены ли действующий результат и готовность отката при поэтапном возврате?

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

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


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

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

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

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

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

При прямом внедрении атакующая инструкция находится во вводе пользователя.

При косвенном внедрении инструкция спрятана во внешнем содержании, которое читает система.

Jailbreak — разновидность внедрения, направленная на обход защитных правил.

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

Вредный ответ и неуполномоченное действие в реальном мире — разные уровни воздействия.

Не каждое читаемое предложение является исполняемой командой.

Присвойте системным, пользовательским и внешним инструкциям разные уровни доверия.

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

Дайте модели и каждому инструменту минимальные полномочия, нужные для задачи.

Проверяйте имя инструмента, параметры, цель и результат однозначным кодом, списком разрешений и схемой.

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

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

Регулярно испытывайте прямые, косвенные, многоязычные и текстовые, визуальные или звуковые атаки и сохраняйте трассировки.

Видны ли источник и уровень доверия каждой инструкции?

Может ли внешнее содержание получить тот же уровень полномочий, что системная политика?

Нет ли у модели лишних полномочий к данным, инструментам или сети?

Запускается ли инструмент по тексту модели или вызов проверяет код?

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

Сохраняются ли заблокированные и успешные попытки внедрения в цепочке инцидента?

Не приняты ли извлечение с дополнением контекста или дообучение за полную защиту?

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

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


Как выявлять и исправлять отравление источников, отравление данных, искусственный консенсус и отмывание источников?

Повтор одного утверждения во многих местах не означает, что его поддерживает множество независимых источников.

Отравление источников или данных загрязняет информационную среду, из которой система учится или извлекает сведения, вводящим в заблуждение содержанием. Множество страниц, копирующих друг друга, может создать видимость несуществующего согласия. NOMOS GEO называет это «искусственным консенсусом». Когда слабому утверждению придают надёжный вид цепочкой копий и ссылок, происходит «отмывание источника». Проверяйте самый ранний источник, независимость, историю изменений и то, действительно ли каждый источник подтверждает утверждение, а не число страниц.

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

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

Отравление данных намеренно искажает данные обучения, дообучения или векторного хранилища.

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

Искусственный консенсус выдаёт зависимые повторы за независимое согласие.

Отмывание источника придаёт слабому или выдуманному утверждению силу цепочкой копий и ссылок.

Ложные сведения не всегда являются атакой; если намерение не доказано, оно остаётся UNRESOLVED.

Сто копий — не сто независимых доказательств.

Для каждого существенного утверждения найдите самый ранний доступный источник и связи последующего копирования.

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

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

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

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

Определите затронутые индексы, векторные записи, кеши и производные данные и перестройте их под контролем.

После исправления повторите проверку тем же вопросом и набором источников.

Сколько источников имеют действительно независимое происхождение?

Доказывает ли самый ранний источник утверждение или только заявляет его?

Не посчитаны ли копии или круговые ссылки независимым подтверждением?

Сохранены ли владелец источника, дата публикации и история изменений?

Какие модели, индексы, векторные записи и ответы затронуло подозрительное содержание?

Исправлена ли только видимая страница или каждая производная поверхность?

Не объявлено ли злонамеренное намерение установленным без доказательств?

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

Отравление источников или данных загрязняет информационную среду, из которой система учится или извлекает сведения, вводящим в заблуждение содержанием. Множество страниц, копирующих друг друга, может создать видимость несуществующего согласия. NOMOS GEO называет это «искусственным консенсусом». Когда слабому утверждению придают надёжный вид цепочкой копий и ссылок, происходит «отмывание источника». Проверяйте самый ранний источник, независимость, историю изменений и то, действительно ли каждый источник подтверждает утверждение, а не число страниц.


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

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

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

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

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

Заявление об идентичности говорит, кто перед нами; аутентификация проверяет это заявление.

Аутентифицированный человек не обязательно уполномочен на каждую операцию.

Действующий сеанс может быть взломан; доверие к сеансу контролируют отдельно от личности.

Дипфейк — синтетическое содержание, похожее на человека по виду или голосу; оно не даёт полномочий на операцию.

Общее одобрение и одобрение, привязанное к конкретной цели, сумме, охвату и времени, — не одно и то же.

Узнать человека — ещё не значит доказать его право на конкретное действие.

Для высокорисковых операций проверяйте личность, сеанс, текущую роль и полномочие действия отдельными средствами.

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

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

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

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

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

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

Какие независимые доказательства подтвердили личность инициатора?

Проверены ли сигналы риска взлома сеанса?

Действовали ли роль и полномочия человека в тот момент?

Охватывало ли одобрение конкретное действие и его последствия?

Не приняты ли лицо, голос, письмо или открытый сеанс за единственное окончательное доказательство?

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

Сохранено ли достаточно доказательств для отзыва, оспаривания и разбора инцидента?

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

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


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

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

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

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

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

Персональные данные относятся к определённому или определяемому человеку; точный правовой охват зависит от юрисдикции.

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

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

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

Журналирование, кеширование, хранение памяти и экспорт — отдельные операции обработки.

Передавайте данные только туда, куда необходимо, только в нужном объёме и только на нужный срок.

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

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

Удаляйте лишние поля до сбора; где возможно, применяйте маскирование, редактирование или псевдонимы.

Передавайте пароли, API-ключи и подобные секреты во время выполнения через защищённый менеджер секретов, а не вставляйте их в запрос.

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

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

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

Какие данные, в какую систему и какому поставщику передаются и ради какой цели?

Нет ли в запросе лишних персональных, чувствительных или конфиденциальных полей?

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

Ограничены ли доступ и секреты минимальными полномочиями задачи?

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

Можно ли по окончании срока подтвердить удаление всех относящихся копий?

Есть ли процесс реагирования и уведомления при нарушении или неправомерном раскрытии?

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

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


Как фиксировать и проверять ответственность за сторонние модели, наборы данных, API, плагины, инструменты и поставщиков инфраструктуры?

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

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

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

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

Поставщик предоставляет продукт; внедряющая или использующая организация применяет его к конкретной цели.

Технический оператор, владелец решения и юридически ответственная сторона не всегда совпадают.

Набор данных, базовая модель, дообучение, API, плагин и инфраструктурная услуга — отдельные элементы поставки.

Распределение ответственности в договоре не обязательно снимает все обязанности перед затронутыми людьми.

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

Внешний компонент использовать можно; заставить ответственность исчезнуть — нельзя.

Учтите на уровне версий каждую модель, набор данных, API, плагин, инструмент и инфраструктурную зависимость.

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

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

Минимизируйте данные и полномочия инструментов; не давайте поставщику лишний доступ.

Требуйте уведомление и повторное тестирование при смене версии, сбое, инциденте с данными или существенном изменении условий.

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

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

Известны ли все сторонние компоненты и их вложенные зависимости?

Назван ли внутри организации ответственный человек за каждый риск и решение?

Проверено ли заявление поставщика независимыми или иными уместными доказательствами?

Понятно ли зафиксированы использование данных, хранение, субподрядчики и ограничения?

Можно ли обнаружить тихую смену версии или конфигурации?

Работают ли условия доступа к записям, уведомления, сотрудничества и отката во время инцидента?

Проверен ли план выхода на реальных данных и зависимостях?

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

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


Как управлять обнаружением, классификацией, сдерживанием, уведомлением, исправлением и предотвращением повторения инцидента ИИ или представления?

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

Ведите весь инцидент под одним идентификатором. Сначала подтвердите сигнал, затем определите тип, серьёзность и область воздействия. Сдержите вред, сохраните доказательства и выполните необходимые уведомления. После устранения первопричины повторите испытание системы в тех же условиях. Нельзя закрывать инцидент только потому, что «мы внесли изменение». Для закрытия нужны доказательства исправления затронутых поверхностей, отсутствия новой ошибки и работы мер против повторения.

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

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

Ошибка — отклонение от ожидаемого поведения; не каждая ошибка является инцидентом безопасности.

Инцидент безопасности затрагивает или угрожает конфиденциальности, целостности либо доступности.

Нарушение приватности или персональных данных может требовать отдельной правовой и операционной оценки.

Инцидент представления существенно показывает сущность неточно, неполно, устарело или без доказательств.

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

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

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

Определите тип, серьёзность, затронутых людей и поверхности, не скрывая неопределённость.

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

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

Где применимо, вовремя уведомите затронутых людей, клиентов, поставщиков или компетентные органы.

Устраните первопричину и исправьте производные записи, кеши, векторные хранилища и нижестоящие поверхности.

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

Есть ли у инцидента один идентификатор, владелец и полная временная линия?

Определены ли тип, серьёзность и охват воздействия по доказательствам?

Снизило ли сдерживание вред, не создавая лишней потери услуги?

Сохранены ли доказательства в форме, пригодной для разбора?

Записаны ли решение об уведомлении, получатели, сроки и причины?

Отличена ли первопричина от видимого симптома?

Не закрыт ли инцидент без доказательств исправления, живого повторного теста, проверки регрессий и предотвращения повторения?

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

Ведите весь инцидент под одним идентификатором. Сначала подтвердите сигнал, затем определите тип, серьёзность и область воздействия. Сдержите вред, сохраните доказательства и выполните необходимые уведомления. После устранения первопричины повторите испытание системы в тех же условиях. Нельзя закрывать инцидент только потому, что «мы внесли изменение». Для закрытия нужны доказательства исправления затронутых поверхностей, отсутствия новой ошибки и работы мер против повторения.


Измерение, аудит и соответствие

Как создавать Truth Pack и эталонную истину и как определять правильный ответ при конфликте доказательств?

Сравнивайте ответ ИИ не с памятью аудитора, а с Truth Pack, где зафиксированы область, время, источники и неопределённость.

Truth Pack — это версионированный пакет доказательств, содержащий утверждения, принятые за ориентир аудита, и причины их принятия. Храните каждое утверждение отдельно и фиксируйте сущность, область, время действительности, источник, полномочность источника, независимость, конфликты и человеческое суждение. При конфликте не выбирайте автоматически самую часто повторяемую фразу. Сопоставляйте полномочную запись, подходящую типу утверждения, прямые доказательства, время и область. Если безопасный вывод невозможен, не выдумывайте его: оставьте статус UNRESOLVED.

Представьте проверку счёта матча. Память зрителя, старый снимок экрана и официальный протокол могут расходиться. Сначала уточните матч и дату, затем найдите своевременную и уполномоченную запись счёта. Если документы всё равно противоречат друг другу, не угадывайте.

Без устойчивого эталона один аудитор отметит ответ правильным, а другой — ошибочным. Устаревшее доказательство или источник не той сущности может испортить всё измерение. Скрытая неопределённость создаёт ложную уверенность в установлении истины.

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

Полномочная запись — источник, которому поручено решать или фиксировать определённый тип утверждения.

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

Человеческое суждение — обоснованный выбор между источниками; оно не заменяет сами источники.

UNRESOLVED явно означает, что доказательств недостаточно или они противоречат друг другу.

Правильный ответ — не самый часто повторяемый, а проверяемый по наиболее подходящим доказательствам.

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

Разделите длинные описания на отдельные проверяемые атомарные утверждения.

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

Сохраните копию источника, дату доступа, версию, хеш файла и связь происхождения.

Разбирайте конфликты по полномочности источника, прямоте, актуальности, области и независимости.

Запишите суждение, причины и владельца решения; при невозможности безопасного вывода используйте UNRESOLVED.

Версионируйте Truth Pack и показывайте, какое утверждение и когда изменилось вместе с реальностью.

Создан ли Truth Pack для правильной сущности, области и времени?

Есть ли у каждого существенного утверждения отдельная запись и ссылка на доказательство?

Не выдано ли заявление самой сущности за независимое подтверждение?

Сохранены ли происхождение, версия, срок действительности и целостность источников?

Следует ли решение конфликта заранее определённым критериям и записанному обоснованию?

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

Отмечены ли неразрешённые случаи как UNRESOLVED вместо ложной определённости?

Некоторые факты меняются со временем, некоторые понятия допускают толкование, а часть споров может разрешить только компетентный орган. Truth Pack не заявляет абсолютную вечную истину; это проверяемый эталонный пакет для определённой области и момента.

Truth Pack — это версионированный пакет доказательств, содержащий утверждения, принятые за ориентир аудита, и причины их принятия. Храните каждое утверждение отдельно и фиксируйте сущность, область, время действительности, источник, полномочность источника, независимость, конфликты и человеческое суждение. При конфликте не выбирайте автоматически самую часто повторяемую фразу. Сопоставляйте полномочную запись, подходящую типу утверждения, прямые доказательства, время и область. Если безопасный вывод невозможен, не выдумывайте его: оставьте статус UNRESOLVED.


Измерение, аудит и соответствие

Как выбирать набор вопросов, выборку, язык, страну, время, модель и границы версий для аудита GEO?

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

Проводите аудит GEO по заранее определённому и версионированному реестру вопросов. Реестр включает идентичность сущности, намерение пользователя, тип вопроса, уровень риска, язык, страну, дату, модель, поверхность продукта и известную версию. Не выбирайте только примеры, которые, вероятно, дадут выгодный результат. Сбалансированно охватывайте основную идентичность, доказательства, сравнение, ограничения, актуальность, ошибки с серьёзными последствиями и реальные намерения пользователей. Если область изменилась после теста, сообщайте старые и новые результаты как разные версии.

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

Выбор вопросов после просмотра ответа позволяет искусственно повысить или понизить успех. Представление, которое выглядит надёжным в одном языке, стране или модели, может не работать в другом условии. Без записи области два аудита нельзя честно сравнить.

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

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

Регрессионное тестирование проверяет, не сломало ли изменение прежнее правильное поведение.

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

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

Спроектируйте проверку до того, как увидите оценку.

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

Разделите реальные намерения пользователей и критические риски представления на категории вопросов.

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

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

Записывайте название модели, способ доступа, дату, время, языковую настройку, страну и видимые сведения о версии.

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

При смене области открывайте новую версию реестра и не смешивайте её результаты со старой.

Явны ли целевая совокупность и цель решения, ради которого проводится измерение?

Зафиксированы ли вопросы до просмотра результатов?

Не создали ли лёгкие или выгодные вопросы смещение отбора?

Достаточно ли представлены идентичность, доказательства, ограничения, актуальность и ошибки высокого риска?

Записаны ли язык, страна, модель, поверхность, дата и версия?

Не обобщён ли результат одного условия на непроверенные условия?

Не удалены ли из результата отсутствующие, неудачные или заблокированные тесты без раскрытия?

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

Проводите аудит GEO по заранее определённому и версионированному реестру вопросов. Реестр включает идентичность сущности, намерение пользователя, тип вопроса, уровень риска, язык, страну, дату, модель, поверхность продукта и известную версию. Не выбирайте только примеры, которые, вероятно, дадут выгодный результат. Сбалансированно охватывайте основную идентичность, доказательства, сравнение, ограничения, актуальность, ошибки с серьёзными последствиями и реальные намерения пользователей. Если область изменилась после теста, сообщайте старые и новые результаты как разные версии.


Измерение, аудит и соответствие

Как разделять ответы ИИ на атомарные утверждения и оценивать точность, полноту, актуальность, доказательность и серьёзность?

Не оценивайте весь ответ ИИ одним баллом; отдельно проверяйте наименьшие утверждения, способные повлиять на решение.

Атомарное утверждение — наименьшее существенное положение, которое можно отдельно оценить как верное или неверное. Сначала разделите ответ на такие положения. Затем для каждого запишите правильную сущность, точность, полноту, актуальность, поддержку источником, существенность и возможный вред. Рассматривайте упоминание, цитирование и рекомендацию как разные события. Критическая ошибка не должна исчезнуть в среднем значении множества несущественных истин; NOMOS GEO называет это правилом некомпенсируемости.

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

Одна общая отметка «верно/неверно» скрывает существенную ошибку. Высокий средний балл не должен делать приемлемым критический дефект: неверную идентичность, опасный совет или неподтверждённое полномочие.

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

Цитирование означает название источника; само по себе оно не доказывает поддержку нужного утверждения.

Точность — соответствие эталонной истине; полнота спрашивает, не пропущены ли необходимые сведения.

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

Существенность или серьёзность относится к влиянию на решения и возможному вреду, а не к заметности ошибки.

Если в одном предложении три утверждения, проверяйте каждое отдельно.

Разделите ответ на атомарные утверждения о субъектах, связях, свойствах, числах, датах, областях и рекомендациях.

Свяжите каждое утверждение с правильной сущностью и соответствующей записью Truth Pack.

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

Фиксируйте упоминание, цитирование, рекомендацию и результат представления, не смешивая их.

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

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

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

Не оценены ли несколько положений как одно утверждение?

Связано ли каждое утверждение с правильной сущностью и записью Truth Pack?

Разделены ли точность, полнота, актуальность и поддержка источником?

Не засчитано ли простое наличие ссылки автоматически как успех доказательства?

Отмечены ли выгодные, но ложные утверждения как ошибки?

Не компенсирована ли критическая ошибка высоким средним баллом?

Не принуждены ли утверждения UNRESOLVED к классу «верно» или «неверно»?

Атомарное разложение и классификация серьёзности требуют человеческого суждения. Пороговые значения и правило некомпенсируемости NOMOS GEO — предлагаемый метод аудита, а не официальная общая шкала NIST, всех отраслей или применимого права.

Атомарное утверждение — наименьшее существенное положение, которое можно отдельно оценить как верное или неверное. Сначала разделите ответ на такие положения. Затем для каждого запишите правильную сущность, точность, полноту, актуальность, поддержку источником, существенность и возможный вред. Рассматривайте упоминание, цитирование и рекомендацию как разные события. Критическая ошибка не должна исчезнуть в среднем значении множества несущественных истин; NOMOS GEO называет это правилом некомпенсируемости.


Измерение, аудит и соответствие

Как сообщать об изменчивости, неопределённости, размере выборки и доверительных интервалах для вероятностных результатов ИИ?

Один ответ — одно наблюдение; вывод о системе требует повторений, распределения, области и оценки неопределённости.

Вероятностная система может в разное время отвечать по-разному на один и тот же или похожий вопрос. Сообщайте число повторов, условия выполнения, распределение результатов, типы ошибок и неохваченные случаи. Размер выборки — не фиксированное маркетинговое число: он зависит от решения, различия в ошибках, которое нужно обнаружить, ожидаемой изменчивости и допустимой неопределённости. Используйте доверительный интервал или другую статистическую сводку лишь тогда, когда выполняются предпосылки метода.

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

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

Сигнал уверенности модели — собственный вывод модели, а не доверительный интервал результата измерения.

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

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

Изменчивость системы — изменение результатов в одинаковых условиях или со временем.

Неопределённость доказательств означает неполноту или противоречивость самого Truth Pack.

Один ответ — это выборка; сообщайте результат вместе с ограничениями выборки.

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

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

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

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

Сообщайте количества, доли, распределения, выбросы и число критических ошибок, а не только среднее.

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

Перечислите непредставленные группы, неудачные запуски и границы обобщения.

Не выдан ли один результат за постоянное поведение системы?

Видны ли число повторов и условия выполнения?

Обоснован ли размер выборки целью решения и ожидаемой изменчивостью?

Не скрывает ли среднее критические ошибки или различия подгрупп?

Рассчитан ли доверительный интервал методом, подходящим данным и предпосылкам?

Не перепутаны ли уверенность модели и уверенность измерения?

Не обобщён ли результат на ненаблюдаемые языки, страны, модели или периоды?

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

Вероятностная система может в разное время отвечать по-разному на один и тот же или похожий вопрос. Сообщайте число повторов, условия выполнения, распределение результатов, типы ошибок и неохваченные случаи. Размер выборки — не фиксированное маркетинговое число: он зависит от решения, различия в ошибках, которое нужно обнаружить, ожидаемой изменчивости и допустимой неопределённости. Используйте доверительный интервал или другую статистическую сводку лишь тогда, когда выполняются предпосылки метода.


Измерение, аудит и соответствие

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

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

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

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

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

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

Проверка второй стороной — оценка клиента, партнёра или договорного контрагента.

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

Академическая валидация изучает метод и выводы исследовательским процессом; это не автоматическая сертификация.

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

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

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

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

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

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

Дайте контролируемый доступ к исходным ответам, Truth Pack, реестру вопросов, версиям, событиям и обоснованию оценки.

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

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

Не одобряет ли аудитор единолично собственный проект или исправление?

Соответствуют ли компетентность и специальные знания проверяемым рискам?

Раскрыты ли интересы и управляются ли они?

Не изменены ли область и правила решения после просмотра результатов?

Доступны ли исходные доказательства и обоснование оценки для достаточной повторной проверки?

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

Не использованы ли слова «независимый» или «проверенный» при сокрытых ограничениях?

В закрытых сторонних системах состояние модели, обучающие данные или инфраструктуру поставщика нельзя воспроизвести полностью. Аудит должен указать доступные доказательства и предел воспроизведения; слова «независимый» или «академически подтверждённый» не создают формальной аккредитации.

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