Журнал аудита AI: что записывать в интеграции и зачем

Короткий ответ

В AI-интеграции журнал аудита хранит ответ на один вопрос: «почему это произошло?» Когда клиент спрашивает «почему вы мне позвонили?», менеджер — «почему бот назвал эту цену?», а аудитор — «кто смотрел данные этого клиента?», ответ должен быть в журнале. Для AI журнал шире, чем для обычных систем: ответ AI и использованные знания, вызванные API, автоматические действия и причины несделанных действий, вмешательства людей, изменения настроек и доступы. Ценность журнала зависит от того, кто и когда его читает: если никто не смотрит, это просто хранимые данные.

Почему аудит важнее для AI

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

К тому же поведение AI меняется настройками: одна строка инструкции или один новый документ знаний меняют тысячи ответов. Если эти изменения не записаны, вопрос «почему вчера он отвечал иначе?» остаётся без ответа.

Что записывать: шесть групп

1. 1Ответы AIТекст ответа, использованные фрагменты знаний, модель и версия, время.
2. 2Вызовы инструментов и APIКакой API, с какими параметрами, что вернул, была ли ошибка.
3. 3Автоматические действияСоздан лид, сделан звонок, отправлено сообщение — а если нет, то почему.
4. 4Вмешательство человекаОператор остановил бота, исправил ответ, взял диалог.
5. 5Изменения настроекИнструкции, база знаний, правила маршрутизации — кто, когда, что.
6. 6ДоступКто вошёл, чьи данные клиента смотрел, что выгружал.

Причина несделанного действия

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

Что содержит хорошая запись

• Точное время с часовым поясом.
• Кто или что: пользователь, AI, учётная запись интеграции.
• Какой объект: диалог, клиент, лид — с идентификатором.
• Что сделано и результат: успешно, ошибка, пропущено.
• Причина или источник: название правила, использованные знания, код ошибки.
• Версия: по какой инструкции или версии правила.

Хранение и доступ

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

Кто читает и когда

• Поддержка: при конкретной жалобе клиента — «почему вы звонили?», «почему бот так сказал?».
• Качество: еженедельная выборка — соответствуют ли ответы AI базе знаний?
• IT: при ошибках и проблемах интеграции.
• Руководство: чтобы проверить результат изменения настроек.
• Аудиторы: в регулируемых отраслях — по доступам и изменениям.

Иллюстративный пример

Это иллюстративный пример. Клиент жалуется, что бот назвал ему старую цену. Открывают журнал: в ответе использован фрагмент знаний со старым прайсом; новый добавили три дня назад, но старый не отключили. Журнал настроек показывает, кто и когда добавил новый документ.

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

Типичные ошибки

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

Ограничения

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

Проверка журнала на практике

Лучший способ проверить, что журнал работает, — заранее провести «учения». Раз в квартал возьмите вымышленную жалобу — «клиент говорит, что ему позвонили в 23:00» — и попробуйте найти ответ в журнале: был ли звонок, по какому правилу и почему в это время? Если ответ не находится за 15 минут, в журнале либо не хватает данных, либо по нему трудно искать. Учения нужны, чтобы не терять время, когда придёт настоящая жалоба.

Владелец журнала

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

Журналы в Vexvon

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

Следующий шаг

Возьмите три жалобы клиентов за прошлый месяц и проверьте по каждой: может ли журнал показать, что произошло и почему? Где ответа нет, там пробел журнала. Обработка ошибок разобрана в статье об ошибках API и правилах повторов. Другие статьи — в разделе о корпоративной интеграции; требования к журналу можно разобрать во время демо.