Аудиторский след ИИ: как восстановить прошлое решение

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

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

Это различие становится вопросом устройства продукта. Workiva 15 сентября 2026 года анонсировала Agent Studio и автоматизированные аудиторские проверки, описав агентов, связывающих сбор свидетельств, тестирование и документацию. Internet-Draft Разы Шарифа от 5 сентября разделяет воспроизводимость записей и решений. Это индивидуальный рабочий проект, а не принятый стандарт IETF. Оба события делают актуальным один практический вопрос: что сохранится после изменения системы?

Что должен подтверждать аудиторский след ИИ?

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

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

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

Достаточно ли сохранённого результата для повтора решения?

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

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

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

Что мы обнаружили в производственных данных Norman?

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

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

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

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

Какие версии необходимо сохранять для воспроизведения?

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

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

Ниже приведён иллюстративный манифест пакета для повторения детерминированного расчёта. Это не внутренняя схема Norman:

{
  "scope": "deterministic-calculation",
  "input_snapshot": "retained-input-v1",
  "calculation_revision": "calculator-r7",
  "configuration_snapshot": "retained-config-v3",
  "reference_data_snapshot": "retained-reference-v2",
  "expected_output": "retained-output-v1",
  "external_effects": "disabled"
}

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

Как безопасно проверить историческую реконструкцию?

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

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

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

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

Что стоит попросить продемонстрировать поставщика ИИ?

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

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

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