Персональный ИИ-ассистент руководителя

Цикл

Встреча → Протокол → Согласование → Календарь → Контроль исполнения

Стек

Hermes Agent · Orchestrator · Arena · Bg-Review · MemPalace · Pseudonymizer

ИБ

Zero Trust · подтверждение человеком · локальная память

Контур

Любой корпоративный мессенджер · on-prem календарь · локальный STT

Роль

Архитектор · разработчик · интегратор

Что делает помощник руководителя

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

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

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

Цикл «Встреча → Протокол → Согласование → Календарь → Контроль»

Архитектура — что под капотом

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

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

Заменяемость компонентов. Языковая модель, распознавание речи, календарь, мессенджер — это слои с чёткими интерфейсами. Замена одного из них (например, перевод на on-prem GPU вместо облачной модели) не требует переписывания всей системы.

Интеллектуальный routing моделей

Один и тот же ассистент обслуживает короткие справочные запросы, работу с кодом и архитектурные обсуждения с длинным контекстом. Запускать всё это через самую дорогую модель — расточительно; запускать через самую дешёвую — не вытянет сложные туры. Оркестратор моделей решает задачу маршрутизации перед каждым вызовом: классифицирует запрос по эвристикам (без ML) и направляет в один из трёх tier'ов.

Классификатор — эвристический, без ML. Решение принимается по размеру контекста, количеству tool calls в туре, наличию ключевых маркеров (код, длинные документы, многошаговые планы). Это даёт предсказуемость: при разборе инцидента видно, по какой именно эвристике запрос ушёл в heavy.

Эскалация и экономия квоты. При качественной ошибке (модель не справилась, отдала невалидный ответ, упёрлась в лимит контекста) задача проходит ordered escalation chain из 5 шагов — от повтора в том же tier с уточнённым промптом до подъёма на следующий tier. Каждый шаг изолирован: если ошибка повторилась — следующий шаг, иначе выход. На типичном распределении (70% light, 25% medium, 5% heavy) такая схема даёт ~47% экономии квоты по сравнению с запуском всех туров на heavy.

Учёт квоты — двухпороговый cap. На каждый tier ведётся счётчик расхода. При остатке 20% оркестратор переходит в режим предупреждения и старается не эскалировать без необходимости; при остатке 8% — hard cap, запросы остаются в более лёгком tier даже ценой повторов. Это исключает ситуацию «квота кончилась к 14:00, ассистент молчит до полуночи».

Наблюдаемость агентной системы

Когда ассистент работает в продакшене, нужны метрики уровня эксплуатации, а не «логи в консоли». Каждый вызов модели проходит через инструментированный gateway: модель, tier, исход, latency, токены — пишутся в локальную SQLite-таблицу. Это превращает поток обращений в наблюдаемый сигнал: видно, какая модель чем занимается, где растут задержки, какой tier приближается к лимиту.

State schema v12. Хранилище — расширение основной SQLite-базы агента, не отдельная инфраструктура. Миграция добавляет две таблицы (model_arena_attempts и session_verdicts) и индексы по времени и tier'у. Объём данных порядка 1–2 МБ в сутки на активного пользователя — без ротации легко держится годами.

Самообучение и рефлексия

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

• Tool whitelist. Background review имеет доступ только к memory- и skill-инструментам. Он не может отправить сообщение пользователю, дёрнуть внешний API, выполнить shell-команду. Минимизация blast radius — рефлексия не сломает основной поток.
• Fixed light model strategy. Background review всегда работает на light-модели и не наследует runtime платных моделей основного тура. Это предотвращает ситуацию «рефлексия съела квоту, которой не хватило основному диалогу».
• Журнал решений. Каждое решение пишется в orchestrator.jsonl: bgreview_decision (что решено обновить и почему) + bgreview_usage (сколько токенов потрачено). Постфактум видно, на чём именно агент учится.
• Не блокирует тур. Daemon стартует после возврата ответа пользователю — ожидание пользователя не растёт от рефлексии.

Речевой конвейер — как принимается голос

Самый чувствительный шаг цикла — приём голоса. Конвейер собран как авторский модуль на проверенных open-source компонентах и работает полностью локально: записи, дорожки и черновые транскрипции не попадают во внешние сервисы. Результат — не «запись встречи», а структурированный транскрипт: кто говорил, что именно говорил, с точностью до слова и секунды.

Три ступени

• Распознавание речи. Локальная модель, специально обученная на русской речи. На выходе — слова с таймкодами, уверенная работа с именами, корпоративной терминологией, номерами договоров. Это область, где универсальные модели часто сбоят на собственных именах и аббревиатурах.
• Разделение спикеров (диаризация). Модуль определяет, кто когда говорил. Количество спикеров — автоматически; при необходимости подсказывается оператором (мягкий диапазон, не жёсткая блокировка). Выход — размеченный таймлайн: «участник А — с 00:14 по 02:31, участник Б — следующий».
• Идентификация голосов. Каждый спикер сравнивается с локальной базой голосовых отпечатков. При совпадении выше порога «Speaker A» становится «Иванов И.И. (директор департамента)». База пополняется адаптивно: новый чистый образец усредняется с предыдущими — точность распознавания растёт с эксплуатацией.

Из чего собран конвейер

Классификация типа встречи

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

Согласование протокола — детально

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

Персональный портал и фиксация согласия экспериментальный модуль

После того как руководитель или служба контроля одобрили финальную версию (см. предыдущую секцию), ассистент рассылает её участникам в письме. Внутри каждого письма — своя индивидуальная ссылка на страницу с финальным протоколом. Сам факт перехода по ссылке фиксируется как акт согласия участника с протоколом, выводами, задачами и сроками. Аналогично тому, как маркетинг отслеживает переходы клиента по UTM-меткам — но здесь отслеживается не клик по объявлению, а согласование документа.

Зачем отдельный портал, а не только почта. Портал нужен для удобства участника. В почте протокол быстро тонет в цепочке обсуждений — реплики, цитаты, ответы, пересылки. Финальная версия неочевидна, можно случайно согласиться со старой редакцией. На портале участник видит только финальную версию документа на этот момент: одна страница, без переписки. Если за время согласования формулировки уточняются — ссылка всегда ведёт на актуальную версию, не на копию из почты.

Контроль исполнения — без напоминалок руководителю

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

• За оговорённый срок до контрольной точки (3 дня, день — настраивается) — задаёт исполнителю вопрос о статусе: «Как идёт задача X из протокола от 15 мая? Что нужно от руководителя?».
• Ответ исполнителя ассистент сверяет с формулировкой обязательства и оценивает: «исполнено», «в графике», «есть риск», «срок сорван». Обоснование сохраняет — на случай разбора.
• При риске или срыве — эскалирует руководителю с фактами: что было обещано, что ответил исполнитель, чем это грозит. Решение о реакции — за руководителем.
• Раз в неделю — сводка по всем активным обязательствам: сколько в графике, сколько с риском, сколько просрочено. Без поименного перечисления, если руководитель не попросит детализацию.

Задачи из мессенджера — отдельный поток

Не все задачи проходят через встречи. Часто руководитель назначает поручение прямо в чате — голосовым или текстом. Ассистент следит за каналами, где руководитель работает, и подхватывает поручения автоматически:

• Голосовое сообщение — расшифровывается локально.
• Текст с формулировкой задачи и адресатом — ассистент распознаёт намерение и оформляет: задача, исполнитель, срок (если назван), привязка к проекту/теме.
• Если срок не назван — уточняет у руководителя в личном диалоге, не беспокоя адресата.
• Подтверждённая задача попадает в тот же список контроля и календарь, что и задачи из протоколов встреч — единая воронка контроля.

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

Зрелость компонентов

Ассистент собран из компонентов разного уровня готовности: промышленные open-source решения, собственные авторские модули и интеграционные адаптеры под конкретный контур. Ниже — карта зрелости по ключевым блокам:

На демонстрации показывается работающая сборка этих компонентов на короткой реальной встрече — от аудио до сформированного протокола, заведённых контрольных точек и запланированной сверки статуса. Точный состав демонстрации согласовывается отдельно по условиям ИБ.

Информационная безопасность — входное условие

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

1. Маршрутизация данных по уровню чувствительности — что обрабатывается локально, что отдаётся в защищённый внешний контур, что вообще не покидает периметр. Голос и черновые транскрипции — без внешних API.
2. Псевдонимизация перед облачной моделью — собственный сервис обезличивает ФИО, контакты, ИНН, договоры, суммы. После ответа модели — обратное восстановление в безопасном контуре.
3. Подтверждение человеком на критических действиях — отправка наружу, юридические формулировки, финансовые суммы — всегда явное «Принять» от руководителя или уполномоченного сотрудника.
4. Локальная память — векторное хранилище и граф знаний оффлайн, без внешних API для эмбеддингов.
5. Маскировка секретов в логах и ответах — встроенный движок редактирования автоматически распознаёт и заменяет на маркер вида *** API-ключи, токены доступа, пароли, JWT, приватные ключи и аналогичные секреты во всех артефактах ассистента (логи, ответы в чате, отчёты, отправляемые письма). Работает на каждом слое — служба безопасности получает чистые логи для аудита без риска утечки.
6. Аудит навыков — любой подключаемый компонент агента проходит ИБ-аудит по чек-листу до установки.
7. Журналирование — структурированные логи в формате, совместимом с корпоративным SIEM (ELK, Splunk и аналогами).

Исследования и факт-чекинг

Помимо контроля встреч, ассистент работает как личный аналитик руководителя — собирает справочные материалы для подготовки решений и проверяет фактуру перед публичными выступлениями или подписанием документов.

• Брифинги перед встречами. Профиль контрагента: организационная структура, ключевые лица, история взаимодействия, последние новости из открытых источников, выписки из реестров, финансовое состояние из публичной отчётности. К каждому факту — ссылка на источник, чтобы можно было перепроверить.
• Поиск с подтверждёнными источниками. Запрос «что известно по теме X» возвращает не пересказ, а структурированную выжимку со ссылками. Без галлюцинаций — если данных недостаточно, ассистент честно говорит «по этому пункту источников не нашёл, нужно уточнение».
• Анализ конкурентов и рынка. По шаблону: профиль продукта, сегментация (корпоративный/массовый), ценовая модель, отличия. Файлы складываются в выделенный архив, чтобы вернуться через месяц без повторного сбора.
• Синтез из множества источников. Не один пересказ, а сопоставление — где источники сходятся, где расходятся, какие расхождения существенны. Это снимает риск принятия решения на одной точке зрения.
• Работа с документами. Поиск конкретных фактов в больших PDF-файлах, выделение цитат с указанием страницы, проверка цифр и формулировок на соответствие первоисточнику. Подсветка расхождений перед подписанием.

Курирование портфеля направлений

У руководителя в активной фазе одновременно — десятки направлений, проектов, поручений. Информация о статусе разбросана между почтой, протоколами встреч, мессенджером и отчётами от руководителей блоков. Ассистент собирает её в единую карту:

• Карта направлений. Список активных проектов и инициатив с фазой («подготовка», «реализация», «контроль», «приёмка»), ответственным лицом, ближайшей контрольной точкой.
• Сводный статус. По каждому направлению: где принято решение, где есть риск, где блокер от другой стороны. Видно сразу — без необходимости расспрашивать руководителей блоков по одному.
• Регулярные синхронизации. Раз в неделю (или с настраиваемой периодичностью) ассистент сам собирает статус от руководителей направлений по согласованной форме — короткое сообщение в мессенджере или почту. Ответы агрегируются в одностраничник.
• Подсветка блокеров. Кто кого ждёт, кто что не передал. Цепочки зависимостей видны явно, не приходится восстанавливать их в голове.
• Связь с протоколами. Каждое обязательство из встречи привязано к направлению или проекту. Если по теме провалов несколько — видно паттерн, а не отдельный инцидент.

Автоматизация рутины секретариата

Часть работы секретариата — это типовые операции, которые не требуют самостоятельного решения, но съедают время. Ассистент берёт их на себя в режиме «черновик готов — секретарь вычитал — отправили»:

• Стандартные письма. Приглашения на встречи, переносы, благодарности, ответы на типовые запросы — по корпоративным шаблонам, с подстановкой контекста.
• Рассылки по списку. Анонсы, поручения подразделениям, информация для контрагентов. Списки берутся из адресной книги, ассистент может фильтровать по подразделению или роли.
• Сбор подтверждений. «Кто подтвердил участие в совещании 22 мая» — собирается автоматически из ответов в почте и мессенджере, выводится в сводку.
• Черновики приказов и распоряжений. По шаблону организации, с подстановкой реквизитов из задач протокола. Без отправки — только на проверку профильным службам и подпись руководителя.
• Поиск контактов и истории. «Найди телефон финансового директора компании X» — ассистент ищет в корпоративной адресной книге и почтовом архиве, возвращает контакт с указанием последней переписки.
• Повестка следующих встреч. Перед очередной встречей ассистент готовит проект повестки на основе непроработанных пунктов прошлых встреч с теми же участниками.

Адаптация и навыки

Ключевое отличие от коробочных решений — ассистент не статичен. Он развивается вместе с регламентами организации и подстраивается под стиль конкретного руководителя.

Навыки — модульный рост возможностей

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

• Новые навыки добавляются без перезапуска и без участия разработчика — это часть инструментария секретариата.
• Навыки переиспользуются: один и тот же шаблон («собрать статус от руководителей направлений и свести в одностраничник») работает и для направления строительства, и для направления цифровизации.
• Доступ к навыкам разграничивается ролями — секретарь видит навыки секретариата, служба контроля — свои, руководитель — все.
• История применения каждого навыка хранится — видно, что регламент применялся 8 пятниц подряд, а на 9-й сбойнул и почему.

Персонализация — изучение стиля и предпочтений

• Стиль писем и сообщений — после нескольких подтверждённых ответов от лица руководителя ассистент перенимает обороты, длину, степень формальности. Черновики становятся всё ближе к финальной версии.
• Личные предпочтения по работе. «По понедельникам не назначать встречи до 11:00», «материалы к совещанию присылать накануне до 18:00», «бриф по контрагенту — не более одной страницы». Эти правила запоминаются и применяются автоматически.
• Дневник важных событий. Что решал руководитель, какие договорённости фиксировал, какие коррекции делал в ответах ассистента. Через 2–3 месяца эксплуатации ассистент работает не как чат-бот, а как сотрудник, понимающий руководителя.
• Корректирующая обратная связь. Каждая правка в формулировках, каждое «не так, переформулируй» сохраняется в копилку правил — ассистент перестаёт ошибаться в той же точке.

Ожидаемые эффекты от внедрения

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

• Время от встречи до согласованного протокола сокращается с нескольких рабочих дней до часов — черновик готов сразу после встречи, согласование — в персональном портале или почте по кнопке.
• Доля «забытых» договорённостей снижается до нуля — все обязательства фиксируются, привязываются к календарю и попадают в общий список контроля.
• Просрочки видны заранее — за несколько дней до даты, а не постфактум. Появляется возможность вмешаться, а не «разбираться, почему сорвано».
• Загрузка секретариата перераспределяется — вместо механического написания протоколов и рассылки напоминаний — содержательная вычитка, верификация, работа с эскалациями.
• Юридическая значимость протоколов повышается за счёт фиксации согласия каждой стороны (нажатие на персональной странице с отметкой времени).
• Управленческий обзор смещается с «по поступившим письмам» на «по направлениям и обязательствам» — руководитель видит портфель целиком, а не последний оперативный пожар.
• Сводное информационное поле — все договорённости, контрольные точки и брифы лежат в одной системе, не разбросаны между почтой, мессенджером и блокнотом секретаря.

Что планируется измерить на пилоте. Среднее время «встреча → подписанный протокол», доля подтверждённых договорённостей в общем числе обязательств, доля задач, выполненных в срок, доля рутинных писем, отправленных без переписывания секретарём. Эти показатели сравниваются с состоянием «до» — по выборке из 1–2 месяцев работы организации до запуска ассистента.

Технологический стек

Этапы внедрения