ИИ-ассистент для рабочего дня основателя

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

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

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

Ассистент готовит решения, а не выдает себя за вас

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

Поручите системе четыре обязанности. Она может сортировать входящую информацию, предлагать действия, собирать материалы и сохранять одобренные решения. У каждой обязанности должен быть четкий результат. Разбор почты создает приоритетную очередь, а не просто более аккуратный ящик. Проверка календаря формирует предложения с объяснениями, а не автоматически переписывает неделю. Бриф дает документ, пригодный для принятия решения, а не длинное резюме. Журнал решений фиксирует реальный выбор, а не каждый разговор.

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

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

Рабочий набор состоит из пяти заменяемых слоев

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

Слой доступа подключается к почте и календарям через поддерживаемый провайдером способ авторизации. Часто используют Gmail и Google Calendar либо Outlook и Microsoft 365, но принцип один: запрашивайте минимальные права, которых достаточно для процесса. Начните с чтения и создания черновиков. Доступ на запись добавляйте только после того, как заработает одобрение. Если провайдер и политика компании разрешают, используйте отдельную учетную запись для автоматизации. Никогда не вставляйте постоянный пароль от почты в промпт.

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

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

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

Интерфейс должен быть скучным: утреннее письмо, личное сообщение в корпоративном мессенджере или маленькая внутренняя страница с действиями «одобрить», «изменить», «отложить» и «отклонить». Основателям не нужна еще одна панель, которая требует внимания. Им нужна одна очередь, встроенная в привычное начало дня.

В почте нужны обязательства, а не оценка настроения

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

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

Оставьте не больше четырех очередей:

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

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

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

Считайте инъекцию инструкций через письмо задачей обработки входных данных. Тело сообщения остается недоверенными данными, даже если в нем написано Ignore previous instructions или содержится просьба раскрыть настройки агента. В промпте модели надо указать, что содержимое письма не меняет системные правила и разрешения инструментов. Еще важнее закрепить допустимые действия в коде оркестратора, потому что фраза в промпте не создает защитную границу.

Управление календарем начинается с правил и заканчивается одобрением

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

Запишите политику в виде конкретных правил. Защитите два блока сосредоточенной работы в выбранные дни. Оставляйте запас времени перед встречами с советом директоров, инвесторами, кандидатами и клиентами в ситуации эскалации. Отклоняйте внешние встречи без указанной цели. Собирайте необязательные внутренние созвоны в определенное окно. Укажите участников или домены, для которых правила можно нарушить. Это примеры, а не универсальные рекомендации. Политику задает настоящий ритм работы основателя.

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

RFC 5545, спецификация iCalendar, определяет такие идентификаторы, как UID, и сведения о редакции, включая SEQUENCE. У этой технической детали есть практическое следствие: обновляйте существующее событие по его стабильному идентификатору, а не создавайте похожую замену. Если автоматизация теряет идентичность и вставляет новое событие, участники могут получить дубликаты или противоречивые ответы. Сохраняйте идентификатор события от провайдера и стандартные поля идентичности календаря, когда они доступны.

Агент обязан строго работать с часовыми поясами. Храните машинное время в едином формате, а показывайте его в нужном часовом поясе каждого участника. Не позволяйте модели вычислять смещения по памяти. Используйте календарный сервис или актуальную базу часовых поясов, особенно при переходе на летнее или зимнее время. Бриф с записью 9:00 без часового пояса не закончен.

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

Бриф должен показывать решение и нехватку данных

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

Формируйте бриф из заранее указанного набора источников. Для продления договора с клиентом это могут быть последняя почтовая ветка, краткое изложение договора, открытые обращения в поддержку, заметки об использовании продукта и предыдущая запись решения. Рядом с каждым фактом показывайте дату источника. Если система не получила доступ к ожидаемому источнику, добавьте его в раздел Недостающие данные, а не продолжайте молча.

Подойдет короткий шаблон:

1. Одним предложением сформулируйте решение или цель.
2. Перечислите влияющие на него факты и даты источников.
3. Покажите варианты, а также цену или последствия каждого.
4. Назовите рекомендуемый вариант и лежащее в его основе допущение.
5. Завершите открытыми вопросами и следующим обязательством.

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

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

Журнал решений дает память, которой нет у чата

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

Используйте небольшую схему, которую легко читает человек и проверяет программа:

{
  "decision_id": "DEC-2026-014",
  "decided_at": "2026-08-09T16:30:00Z",
  "owner": "founder",
  "question": "Should we extend the pilot by 30 days?",
  "decision": "Extend once with weekly usage review",
  "reasons": ["Security review delayed launch", "Two teams are now active"],
  "assumptions": ["Procurement starts before the extension ends"],
  "revisit_when": ["Weekly active users fall below 20", "Procurement has no owner by August 20"],
  "source_refs": ["thread_8421", "brief_pilot_2026_08_09"],
  "approved_by": "founder"
}

Модель может подготовить такую запись после встречи или одобренного письма, но владелец должен подтвердить решение, причины и условия пересмотра. До подтверждения запись сохраняет статус proposed. Так предположение из заметок к встрече не превратится в политику компании.

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

Исправляйте записи добавлением, а не перезаписью. Если решение изменилось, создайте новую запись, которая заменяет старую и объясняет причину. Не переписывайте историю так, будто текущая позиция была неизбежна. При разборе качества решений самую большую пользу часто дают старые допущения.

Этапы одобрения должны соответствовать цене ошибки

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

Практическая лестница разрешений состоит из четырех ступеней:

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

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

AI Risk Management Framework от NIST разделяет управление, описание контекста, измерение и работу с риском. Для небольшой компании отсюда следует полезный вывод: оценка модели дает лишь часть картины. Нужны ответственный, заданный контекст, наблюдаемые сбои и реакция на превышение согласованного риска. Я бы не переносил этот документ в виде стопки формальностей. Я бы взял из него разделение ответственности, чтобы человек, которому понравилась демонстрация, не мог единолично определить политику риска.

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

Аудит позволяет разобраться в причинах сбоев

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

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

Отделяйте ответ модели от выполненного действия. Запись должна показывать, что модель предложила move event, проверка приняла схему, основатель одобрил измененное время, а календарный коннектор обновил событие abc123. Если конечное состояние отличается от предложения, сохраните оба варианта. Иначе при последующей проверке модель могут обвинить в правке человека или решить, что предложение выполнено, хотя коннектор дал сбой.

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

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

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

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

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

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

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

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

Утренний запуск показывает слабые места конструкции

В 6:30 оркестратор получает непрочитанные письма с прошлого контрольного момента и измененные события сегодняшнего календаря. Он отсеивает рекламу по однозначным правилам для отправителей, группирует остальное по веткам и передает модели ограниченный текст. Классификатор возвращает структурированные записи разбора. Проверка отклоняет запись без идентификатора источника, класса действия, степени уверенности и подтверждающего фрагмента.

В 6:35 процесс получает сегодняшние встречи и политику планирования. Он ничего не переносит. Он отмечает звонок с инвестором внутри защищенного времени на подготовку и внешний звонок отдела продаж без повестки. Для каждого случая система предлагает действие и называет правило. Основатель может оставить все как есть, изменить или одобрить предложение.

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

В 7:00 основатель получает один дайджест: два решения, три черновика, один конфликт календаря и один недостающий источник. После одобрения черновик появляется в почте. Если внешняя отправка по-прежнему требует подтверждения, второе нажатие отправляет его. Одобрение календарного предложения обновляет существующее событие по идентификатору. После звонка с инвестором заметки встречи превращаются в предложенную запись решения, и основатель подтверждает ее до включения в основной журнал.

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

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

Сначала замкните один процесс, потом подключайте компанию

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

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

Считайте бюджет рабочего процесса, а не одну цену токена. Учитывайте вызовы модели и поиска, запуски автоматизации, хранение, наблюдение и время основателя на проверку. Дешевая модель обходится дорого, если все ее черновики приходится переписывать. Более сильная модель, которую вызывают только после однозначной фильтрации, может снизить общие расходы. Кешируйте стабильный контекст, например словарь компании и политику, но не сохраняйте в кеше текущие обязательства и состояние календаря.

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

Компаниям, которым нужна помощь в определении этих границ, Team & AI Audit помогает за пять рабочих дней описать повторяющиеся очереди основателя, риски доступа и экономический смысл. Полезный результат аудита не сводится к списку модных инструментов. Он выбирает небольшое число процессов, где автоматизация убирает повторную работу и не забирает полномочия, которые основатель не может безопасно передать.

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