ИИ-протокол совещания должен сохранять источник каждой задачи и ждать подтверждения участников

ИИ уже умеет собирать задачи из встречи. На 8 октября 2026 MeetScribe описывает ответственных, сроки и привязку задачи к моменту аудиозаписи. МТС Линк описывает извлечение задач из расшифровки со сроком и ответственным, если они были названы.

Для базы знаний Notion есть Notion AI для встреч: он составляет сводку по записи и заметкам. Согласие участников и ограничения доступа из РФ нужно проверить до выбора сервиса.

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

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

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

ИИ-распознавание рукописных заметок должно возвращать сомнительный фрагмент автору.

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

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

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

Молчание оставляет задачу черновиком. Просмотр протокола, доставка письма или отсутствие возражений до вечера не должны автоматически разрешать отправку. Кто подтверждает каждое поле и кто разрешает спор, компания записывает в требованиях до разработки.

Поправка меняет предмет согласия. Если после подтверждения заменили ответственного, срок или смысл, затронутые согласования запрашивают заново. Эти правила для ИИ-агентов должны исполняться системой, а не оставаться текстом рядом с кнопкой отправки.

Успех заканчивается в рабочей очереди компании. После отправки протокол должен получить номер созданной задачи и ссылку на неё. Надпись «отправлено» при потерянном ответе системы ещё не доказывает, что поручение появилось у исполнителя.

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

Доступ к поручению не означает доступ ко всей записи. Компания отдельно задаёт, кто видит данные участников встречи, фрагмент-источник и полный протокол. Если исполнителю нельзя открыть запись, проверку источника принимает уполномоченный участник, а в очереди остаётся разрешённая выдержка.

Наш опыт относится к разработке и проверке текста на vibecoding.ru. Инженер ведёт машину агентов, задаёт правила и принимает работу. Для будущего протоколировщика этот опыт даёт способ приёмки, но не замер точности распознавания речи.

21 августа 2026 отдельный агент сверил написанный текст с исследованием и поймал выдуманный внутренний замер. В тексте факт выглядел убедительно, а в исходных материалах его не было. В протоколе такая же проверка должна находить поручение без опоры в разговоре.

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

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

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

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

Такой модуль можно поставить первой задачей подписки на агентную разработку. На 8 октября 2026 «Один проект» стоит 250 000 ₽ в месяц: инженер с машиной ИИ-агентов сдаёт правки в репозиторий клиента, одна задача в работе, следующая ждёт. Подписку можно поставить на паузу в любой месяц.

Стоимость разработки не заменяет бюджет работы модуля. На /services отдельно указано, что модели и инфраструктура для ИИ-функций продукта оплачиваются клиентом. Для протокола расходы считают по вашим записям и выбранным сервисам, без обещания цены за минуту до замера.

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

1. Задача должна открывать свой источник. В приёмке проверяют цитату, фрагмент записи и поздние поправки к решению.

2. Найденное поручение начинает жизнь черновиком. Компания задаёт, кто подтверждает смысл, ответственного и срок.

3. Согласие привязано к версии. Изменение важных полей требует повторного подтверждения.

4. Перенос заканчивается номером задачи и обратным статусом. Повтор после сбоя не должен создавать дубль.

5. Первый заказ описывает путь одной встречи. Спорные реплики и отменённые поручения входят в приёмку до запуска модуля.