Суть задачи

Протокол — это не короткий пересказ

Встреча закончилась, и участники помнят её по-разному. Один уверен, что срок поставки утвердили, другой слышал только предложение. Автоматический пересказ сгладит эту разницу красивой формулировкой. Поэтому задача ИИ — не написать «что обсудили», а разнести реплики по статусам: принятое решение, предложение, открытый вопрос и поручение на проверку. Если запись не даёт оснований назвать фразу решением, в протоколе должна остаться неопределённость, даже если это выглядит менее аккуратно.

Исходные данные

Получите согласие на запись

До встречи сообщите участникам, ведётся ли запись, где она будет храниться и кто получит доступ к расшифровке. Правила могут зависеть от организации и местной юрисдикции. Если согласия нет, работайте с заметками, а не тайно записанным аудио. После встречи сохраните исходный файл и не редактируйте его вместо исправления протокола. В копии для внешней нейросети удалите личные данные, цены и детали договора, которые нельзя передавать. Иногда безопаснее использовать локальную расшифровку: [обзор Whisper.cpp на ИИШКА Про](https://iishkapro.ru/article/obzor-whisper-cpp-lokalnaya-rasshifrovka-intervyu-20261012-b2/) объясняет этот маршрут.

Рабочий маршрут

Проверьте речь до смысла

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

Проверка

Дайте модели четыре корзины

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

Практический пример

Не смешивайте участников и функции

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

Риски

Пример с поставщиком

Команда обсуждает задержку сырья. Менеджер предлагает альтернативного поставщика, логист обещает узнать дату, руководитель просит сначала сравнить спецификации. Неправильный автоматический протокол звучал бы так: «Решено сменить поставщика до пятницы». Корректная запись: «Предложен альтернативный поставщик; логист уточняет дату текущей поставки; ответственному за продукт нужно сверить спецификации; решение о смене не принято». Отдельно можно назначить дату возвращения к вопросу, но только после согласования. Такой пример показывает, почему протокол не равен сравнению предложений.

После запуска

Согласование и рассылка

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

Внедрение

Когда автоматизация окупается

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

План на день

После встречи не теряйте контекст

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

Вывод

Вывод и FAQ

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