Аудиторский след: процесс как продукт

Чему вы научитесь

• Объяснить принцип «процесс как продукт» и почему он важен в юридической работе
• Проектировать структуру events.jsonl: что писать на каждом шаге, какие поля обязательны
• Собирать из лог-событий единый case-report.md и opinion.docx
• Использовать аудиторский след для контроля качества и как доказательство должной осмотрительности
• Применять требования к аудиту в российском контексте с учётом 152-ФЗ и режима адвокатской тайны

«Процесс как продукт»: почему важен след каждого шага

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

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

• «Откуда взялась эта ссылка и кто её проверил?»
• «Что делал AI, а что — человек?»
• «Если завтра выяснится ошибка — как мы можем её отследить и исправить?»

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

В архитектуре KP Legal Orchestrator каждый шаг работы агентов пишется в events.jsonl, а по завершении задачи формируется единый case-report.md и opinion.docx. Именно эта пара — лог событий плюс итоговый отчёт — составляет аудиторский след.

Что такое events.jsonl

events.jsonl — это файл в формате JSON Lines (одна запись на строку), в который записывается каждое событие в рабочем процессе: вызов агента, найденный источник, вердикт ревьюера, решение юриста.

Формат JSON Lines удобен тем, что:

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

Пример записи в events.jsonl — событие передачи задачи research-агенту:

{
  "event_id": "evt_001",
  "timestamp": "2026-05-28T10:14:32Z",
  "agent": "research-agent",
  "step": "source_lookup",
  "input": "Каков порядок обжалования решения налогового органа по НК РФ?",
  "sources_found": [
    {
      "grade": "A",
      "title": "Налоговый кодекс РФ, часть первая",
      "article": "ст. 137-139.3",
      "url": "https://www.consultant.ru/document/cons_doc_LAW_19671/",
      "quote": "Каждое лицо имеет право обжаловать акты налоговых органов ненормативного характера..."
    }
  ],
  "status": "completed"
}

Пример записи — вердикт Senior Review-агента по конкретной ссылке:

{
  "event_id": "evt_004",
  "timestamp": "2026-05-28T10:22:11Z",
  "agent": "senior-review-agent",
  "step": "citation_check",
  "ref_id": "ref_002",
  "draft_quote": "согласно ст. 101.2 НК РФ срок обжалования составляет 10 дней",
  "source_quote": "Решение о привлечении к ответственности за совершение налогового правонарушения... может быть обжаловано в судебном порядке только после обжалования этого решения в вышестоящем налоговом органе",
  "verdict": "Manual Review Required",
  "note": "Срок 10 дней не найден в указанной статье; требуется проверка по актуальной редакции НК РФ в КонсультантПлюс."
}

Что должно остаться после задачи

1. events.jsonl — полный лог всех событий: каждый вызов агента, каждый найденный источник, каждый вердикт ревьюера. Минимальные поля: event_id, timestamp, agent, step, status.

2. case-report.md — человекочитаемый отчёт по задаче: постановка вопроса, список использованных агентов, сводка найденных источников с Grade, итог по каждому вердикту ревьюера, финальное решение юриста.

3. opinion.docx (или аналог) — итоговый документ с позицией: заключение, меморандум, проект договора. Должен содержать только ссылки, прошедшие вердикт Pass или закрытые юристом вручную.

4. Список закрытых замечаний — для каждого Manual Review Required: как замечание закрыто (исправлена ссылка, исключён фрагмент, подтверждено юристом по первоисточнику) и кем.

5. Метаданные задачи — дата, исполнитель (роль, не имя — для анонимизации при необходимости), использованные модели, версии агентов.

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

Как читать аудиторский след: контроль качества

Аудиторский след — это не архивный документ. Это инструмент контроля качества в реальном времени и ретроспективно.

При проверке конкретной задачи смотрите на три сигнала:

Соотношение Pass / Manual Review Required. Высокий процент Manual Review Required — сигнал, что промпт writer-агента требует доработки или что источники подобраны недостаточно аккуратно. Нормального порога не существует — он зависит от типа задачи, но любые повторяющиеся паттерны ошибок стоит анализировать.

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

Закрытие замечаний. Если в events.jsonl есть Manual Review Required без соответствующей записи о закрытии — значит, замечание висит открытым. Это недопустимо: документ с незакрытыми замечаниями не готов к использованию.

flowchart TD
    A[Постановка задачи] -->|event: task_start| L[(events.jsonl)]
    A --> B[Research-агент\nпоиск источников]
    B -->|event: source_lookup| L
    B --> C[Senior Review-агент\nсверка ссылок]
    C -->|event: citation_check\nвердикт Pass / MRR| L
    C --> D{Все Pass?}
    D -->|Да| E[Юрист\nфинальная проверка]
    D -->|Нет| F[Редактирование\nзакрытие замечаний]
    F -->|event: issue_closed| L
    F --> E
    E -->|event: task_complete| L
    L --> G[case-report.md\n+ opinion.docx]

Применимость к российскому праву

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

Три важных ограничения для применения в РФ.

152-ФЗ и персональные данные. Если в events.jsonl попадают фрагменты текста, содержащие персональные данные (имена клиентов, реквизиты физических лиц, данные из договоров), — это обработка ПД в смысле 152-ФЗ. Лог должен храниться в соответствии с требованиями оператора: срок, место, доступ. Не передавайте лог с ПД в публичные сервисы.

Адвокатская тайна. Если задача касается сведений, составляющих адвокатскую тайну, — events.jsonl с фрагментами позиции клиента должен находиться в закрытом контуре. Использование публичных AI-сервисов для хранения или обработки такого лога недопустимо.

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

Чек-лист перед сдачей задачи

Перед тем как финальный документ уходит клиенту или в дело, проверьте по следующим пунктам:

• В events.jsonl есть запись о каждом существенном шаге задачи.
• Все вердикты Manual Review Required имеют соответствующую запись о закрытии.
• opinion.docx содержит только ссылки, прошедшие Pass или закрытые юристом по первоисточнику.
• Если в логе есть фрагменты с ПД — убедитесь, что они хранятся в соответствии с политикой обработки ПД вашей организации.
• case-report.md подписан (в метаданных указан) юристом, принявшим финальное решение.