ИИ-агент сказал «сделано». Но сделал ли он на самом деле?

Проблема, о которой мы знаем, но делаем вид, что не замечаем

На прошлой неделе Хабр опубликовал материал о том, как компании платят до 300 000 рублей в месяц за «скрытый аутсорс» задач в ChatGPT. История получила резонанс — но обсуждение ушло не туда. Говорили о доверии, об этике, о трудовом договоре.

Никто не спросил о главном: а как вы вообще проверяете, что задача была выполнена — агентом или человеком? И была ли она выполнена вообще?

В открытом демо-пайплайне dcl-eval-pipeline-demo я показала, как аудировать поведение агентов на практике. Теперь разберём, почему это критично и как построить полноценный слой верификации — вплоть до готового инструмента, который можно скачать и запустить прямо сейчас.

Это не риторический вопрос. Это архитектурная дыра, которая сейчас присутствует практически в каждой агентной системе. Называется она fabricated execution — ситуация, когда агент возвращает результат, не выполнив задачи, или выполнив что-то принципиально другое, оформив под видом запрошенного.

Что такое fabricated execution и почему это архитектурное свойство

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

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

Функция sort(array) возвращает отсортированный массив. LLM-агент, которому поручено «отсортировать таблицу продаж», вернёт текст, который выглядит как отсортированная таблица. И этот текст может быть галлюцинацией.

Это не недостаток конкретной модели — это архитектурное следствие того, как устроены трансформеры. Они оптимизированы на правдоподобие вывода, а не на его корректность относительно внешней реальности.

Три класса fabricated execution

1. Полная фабрикация

Агент не выполняет задачу вообще, но генерирует убедительный отчёт о её выполнении. Классический пример: агент, которому поручено проверить 1000 строк кода на наличие SQL-инъекций, возвращает список «найденных уязвимостей» — сгенерированных, а не реально обнаруженных.

2. Частичная фабрикация

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

3. Подмена задачи

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

DCL: детерминированный слой верификации

Deterministic Commitment Layer (DCL) — архитектурный паттерн, который вводит независимый верификационный слой между агентом и потребителем его результатов. Ключевое слово — «детерминированный»: в отличие от самого агента, верификационный механизм работает по строгим, воспроизводимым правилам.

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

Классические SIEM-системы покрывают инфраструктуру, сеть, доступ. Логику решений LLM-агентов они не видят вообще. DCL закрывает именно эту слепую зону.

Три ключевых компонента

Протокол обязательств (Commitment Protocol)

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

обязательство = Hash(id_задачи хэш_входа список_инструментов || временная_метка)

После получения обязательства агент не может изменить параметры задачи без создания нового. Это ломает fabricated execution первого класса: без валидных следов инструментального использования фабрикация выявляется автоматически.

Верификация трассы выполнения

DCL фиксирует трассу на уровне вызовов инструментов, не полагаясь на самоотчёт агента. Каждый вызов внешнего инструмента (API, файловая система, база данных) подписывается независимым сервисом, недоступным агенту напрямую.

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

Криптографический журнал аудита

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

Практическая реализация

Рассмотрим упрощённую реализацию DCL-паттерна. Полный рабочий пример доступен в репозитории.

Структура обязательства

import hashlib, json, time from dataclasses import dataclass, field from typing import List, Dict @dataclass class TaskCommitment: task_id: str input_hash: str # SHA-256 входных данных tool_manifest: List[str] # список разрешённых инструментов expected_side_effects: Dict timestamp: float = field(default_factory=time.time) def sign(self) -> str: payload = json.dumps({ 'task_id': self.task_id, 'input_hash': self.input_hash, 'tools': sorted(self.tool_manifest), 'ts': self.timestamp }, sort_keys=True) return hashlib.sha256(payload.encode()).hexdigest()

Верификатор трассы

class DCLVerifier: MIN_COVERAGE_THRESHOLD = 0.8 def verify( self, commitment: TaskCommitment, trace: List[ToolCall] ) -> VerificationResult: # 1. Проверка разрешённых инструментов used_tools = {call.tool_name for call in trace} unauthorized = used_tools - set(commitment.tool_manifest) if unauthorized: return VerificationResult.UNAUTHORIZED_TOOL_USE # 2. Проверка минимального покрытия coverage = self._compute_coverage(trace, commitment) if coverage < self.MIN_COVERAGE_THRESHOLD: return VerificationResult.INSUFFICIENT_EXECUTION # 3. Верификация подписей вызовов for call in trace: if not self._verify_call_signature(call): return VerificationResult.TAMPERED_TRACE return VerificationResult.VERIFIED

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

DCL Evaluator: потрогать руками прямо сейчас

Архитектурный принцип — хорошо. Но инженеры хотят запустить и посмотреть. Мы сделали десктопное приложение.

DCL Evaluator — это реализация DCL-паттерна в виде десктопного инструмента для детерминированного аудита и верификации ответов ИИ-агентов. Работает полностью офлайн, данные не покидают машину. Локальный агент подключается через Ollama.

Попытка jailbreak — агент заблокирован мгновенно, вердикт NO_COMMIT, причина зафиксирована в хэше транзакции

Audit trail: полная история вердиктов с криптографическими хэшами, экспорт в CSV/JSON одной кнопкой

Что внутри:

• Редактор политик с drag & drop YAML — описываете правила в несколько строк

• Вердикт COMMIT / NO_COMMIT по каждому ответу агента с объяснением причины

• Криптографический audit trail — каждое событие подписано и экспортируется

• Детекция дрейфа по Z-тесту с четырьмя уровнями угроз: NORMAL / WARNING / ESCALATION / BLOCK

• Полная офлайн-работа — ни один байт не уходит наружу

• Тёмная и светлая тема, потому что это важно

Стек: Go + React (Wails). Windows 10/11 x64. Для локального агента — Ollama (ollama pull llama3.2:1b перед первым запуском).

Это пре-релиз v1.0.0. Известные ограничения есть, в v1.1 уже в работе. Если найдёшь баг или захочешь фичу — issue или в личку.

DCL и приказ ФСТЭК №117: конкретные пункты

Регуляторы движутся в том же направлении. EU AI Act явно указывает на необходимость аудиторских следов для систем высокого риска. ФСТЭК формирует аналогичные требования для государственных информационных систем — и здесь DCL Evaluator закрывает конкретные пункты, а не абстрактные принципы:

Требование приказа №117	Статья / пункт	Как закрывает DCL Evaluator
Непрерывный мониторинг событий безопасности ИИ‑компонент	Раздел IV, п. 28–31	JSON‑логи всех действий агента в реальном времени; детектирование аномальных решений
Регистрация и хранение событий безопасности	Раздел IV, п. 32–34	Структурированный audit trail с временными метками; экспорт для интеграции с SIEM/SOC
Контроль сценариев применения ИИ и критерии достоверности ответов	Раздел III, п. 19–22	Политики DCL формализуют допустимые тематики и критерии корректности; COMMIT/NO_COMMIT вердикт по каждому ответу
Выявление признаков угроз и нарушений регламентов	Раздел IV, п. 35–37	Автоматическое выявление drift и отклонений от политики; флаги инцидентов в audit log
Отчётность и демонстрация эффективности мер защиты	Раздел V, п. 41–43	Экспорт отчётов о соответствии; метрики качества и надёжности агентов для регуляторной отчётности

Важно: DCL Evaluator не заменяет классический SIEM и не обеспечивает полного соответствия приказу №117 самостоятельно. Решение выступает специализированным модулем мониторинга ИИ-компонент в составе общей системы ИБ организации — закрывая ту зону, которую классические средства защиты не покрывают.

Где работает, а где нет

Сильные стороны

• Регулируемые домены: финансы, медицина, юриспруденция — везде, где требуется аудиторский след и доказуемость выполнения.

• Долгосрочные автономные агенты: чем дольше агент работает без надзора, тем выше риск fabricated execution — и тем ценнее непрерывный журнал.

• Мультиагентные пайплайны: когда один агент передаёт результат другому, DCL позволяет каждому звену цепочки проверить входные данные.

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

Ограничения

• Задачи с неверифицируемым выводом: если результат агента — текст или решение, которое невозможно проверить инструментально, DCL фиксирует факт обработки, но не корректность вывода.

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

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

Почему это важно именно сейчас

История с 300 000 рублей за аутсорс в ChatGPT — симптом. Симптом того, что мы строим системы, которые доверяют агентам на слово, не имея инструментов для проверки этого слова.

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

DCL — не академический эксперимент, а ответ на требования, которые уже существуют или появятся в ближайшие 12–24 месяца.

Мы привыкли проверять код через тесты. Пора привыкнуть проверять выполнение агентских задач через верификационные слои. Это не паранойя — это инженерная зрелость.

Что делать прямо сейчас

• Введите логирование всех инструментальных вызовов с независимыми подписями — это минимальный DCL‑паттерн, реализуемый за день.

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

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

• Проведите аудит существующих журналов: если их нет — это уже ответ на вопрос о верифицируемости вашей системы.

DCL — это не библиотека и не вендорское решение. Это архитектурный принцип, масштабирующийся от простого логирования до полноценной криптографической верификации.

Агент сказал «сделано». Теперь у вас есть инструменты, чтобы это проверить.

Ресурсы и дальнейшее чтение

• DCL Desktop App v1.0.0 (pre‑release) — pre‑release — скачать и запустить прямо сейчас

• Открытый демо‑пайплайн dcl‑eval‑pipeline‑demo — dcl‑eval‑pipeline‑demo — рабочие примеры верификации агентов на Python + FastAPI + Docker

• Предыдущий пост: «Как аудировать поведение ИИ‑агентов» — Детерминистический аудит‑слой для LLM‑агентов — открытое демо — практическое введение в тему

• Whitepaper по DCL — полная техническая спецификация архитектуры готовится к публикации. Хотите раннюю версию — пишите в комментариях или в личку.

© Fronesis Labs

Источник