Бесплатный фрагмент - AI — система ПРО

PL • AI PRO SERIES • КНИГА 6

AI-СИСТЕМА PRO

Как собрать искусственный интеллект, агентов, автоматизацию и знания в единую систему для работы, бизнеса и жизни

PL

Русское издание • 2026

От автора

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

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

Это заключительная книга цикла PL • AI PRO SERIES. Её задача — собрать отдельные навыки в единую интеллектуальную инфраструктуру: личную и бизнес-систему, которая помогает думать, создавать, управлять, продавать, анализировать и принимать решения.

Как пользоваться этой книгой

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

В каждой главе обращайте внимание не только на возможности AI, но и на границы: источник истины, права доступа, Human Gate, журнал действий и резервный маршрут. Именно эти элементы превращают эффектный прототип в рабочую систему.

В конце книги мы соберём все элементы в единую AI-операционную систему и составим 30-дневный план её внедрения.

Введение. От набора инструментов к системе

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

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

Рабочая формула этой книги: ЦЕЛЬ → КОНТЕКСТ → ЗНАНИЯ → АГЕНТ/AI → ПРАВИЛО → ДЕЙСТВИЕ → ПРОВЕРКА → ПАМЯТЬ → ОБРАТНАЯ СВЯЗЬ. Это уже не отдельный промпт и не отдельная автоматизация. Это цикл, который способен становиться лучше.

Часть I. От пользователя AI к архитектору системы

Глава 1. Почему набор AI-инструментов ещё не система

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

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

Как это выглядит на практике

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

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

Архитектурный принцип

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

Мини-кейс

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

Что может пойти не так

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

Практика

Создайте понятная карта процессов. Не описывайте идеальную будущую систему — используйте один реальный процесс. Укажите вход, источник фактов, роль AI или агента, правила, Human Gate, результат и место, где сохраняется новое состояние. Затем отметьте один шаг, который можно убрать или автоматизировать уже сейчас.

Контрольные вопросы

• Можно ли объяснить этот элемент системы человеку, который не знает ваших AI-инструментов?

• Что произойдёт, если данных недостаточно или они противоречат друг другу?

• Какой факт должен приходить из Source of Truth?

• Где проходит граница ответственности человека?

• По какой метрике вы поймёте, что система стала лучше?

Глава 2. Главная единица — не приложение, а процесс

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

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

Как это выглядит на практике

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

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

Архитектурный принцип

Контекст должен приходить из системы, а не зависеть от того, вспомнил ли пользователь вставить нужный абзац в промпт.

Мини-кейс

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

Что может пойти не так

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

Практика

Создайте описанный маршрут от входа до результата. Не описывайте идеальную будущую систему — используйте один реальный процесс. Укажите вход, источник фактов, роль AI или агента, правила, Human Gate, результат и место, где сохраняется новое состояние. Затем отметьте один шаг, который можно убрать или автоматизировать уже сейчас.

Контрольные вопросы

• Можно ли объяснить этот элемент системы человеку, который не знает ваших AI-инструментов?

• Что произойдёт, если данных недостаточно или они противоречат друг другу?

• Какой факт должен приходить из Source of Truth?

• Где проходит граница ответственности человека?

• По какой метрике вы поймёте, что система стала лучше?

Глава 3. Определяем, что должна делать ваша AI-система

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

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

Как это выглядит на практике

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

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

Архитектурный принцип

Факты и творческие выводы нужно разделять. Цена, статус, правило или договорённость берутся из Source of Truth; AI может объяснить или оформить их, но не изобретать.

Мини-кейс

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

Что может пойти не так

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

Практика

Создайте список функций системы. Не описывайте идеальную будущую систему — используйте один реальный процесс. Укажите вход, источник фактов, роль AI или агента, правила, Human Gate, результат и место, где сохраняется новое состояние. Затем отметьте один шаг, который можно убрать или автоматизировать уже сейчас.

Контрольные вопросы

• Можно ли объяснить этот элемент системы человеку, который не знает ваших AI-инструментов?

• Что произойдёт, если данных недостаточно или они противоречат друг другу?

• Какой факт должен приходить из Source of Truth?

• Где проходит граница ответственности человека?

• По какой метрике вы поймёте, что система стала лучше?

Глава 4. Пять уровней зрелости работы с AI

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

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

Как это выглядит на практике

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

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

Архитектурный принцип

Каждый переход между этапами должен иметь понятный формат результата. Это позволяет заменить один компонент, не разрушая всю систему.

Мини-кейс

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

Что может пойти не так

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

Практика

Создайте оценка текущего состояния. Не описывайте идеальную будущую систему — используйте один реальный процесс. Укажите вход, источник фактов, роль AI или агента, правила, Human Gate, результат и место, где сохраняется новое состояние. Затем отметьте один шаг, который можно убрать или автоматизировать уже сейчас.

Контрольные вопросы

• Можно ли объяснить этот элемент системы человеку, который не знает ваших AI-инструментов?

• Что произойдёт, если данных недостаточно или они противоречат друг другу?

• Какой факт должен приходить из Source of Truth?

• Где проходит граница ответственности человека?

• По какой метрике вы поймёте, что система стала лучше?

Глава 5. Карта цифрового хаоса

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

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

Как это выглядит на практике

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

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

Архитектурный принцип

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

Мини-кейс

Контентная система сначала ищет релевантные материалы в базе знаний, затем агент готовит черновик, критик проверяет факты и повторы, а публикация происходит только после Human Gate. Автоматизация ускоряет подготовку, но не превращает бренд в бесконтрольный генератор текста.

Что может пойти не так

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

Практика

Создайте карта цифрового хаоса. Не описывайте идеальную будущую систему — используйте один реальный процесс. Укажите вход, источник фактов, роль AI или агента, правила, Human Gate, результат и место, где сохраняется новое состояние. Затем отметьте один шаг, который можно убрать или автоматизировать уже сейчас.

Контрольные вопросы

• Можно ли объяснить этот элемент системы человеку, который не знает ваших AI-инструментов?

• Что произойдёт, если данных недостаточно или они противоречат друг другу?

• Какой факт должен приходить из Source of Truth?

• Где проходит граница ответственности человека?

• По какой метрике вы поймёте, что система стала лучше?

Глава 6. Роли человека и искусственного интеллекта

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

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

Как это выглядит на практике

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

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

Архитектурный принцип

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

Мини-кейс

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

Что может пойти не так

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

Практика

Создайте матрица ролей. Не описывайте идеальную будущую систему — используйте один реальный процесс. Укажите вход, источник фактов, роль AI или агента, правила, Human Gate, результат и место, где сохраняется новое состояние. Затем отметьте один шаг, который можно убрать или автоматизировать уже сейчас.

Контрольные вопросы

• Можно ли объяснить этот элемент системы человеку, который не знает ваших AI-инструментов?

• Что произойдёт, если данных недостаточно или они противоречат друг другу?

• Какой факт должен приходить из Source of Truth?

• Где проходит граница ответственности человека?

• По какой метрике вы поймёте, что система стала лучше?

Глава 7. Что должно оставаться у человека

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

Представьте, что завтра один из используемых вами AI-сервисов исчезает. Если вместе с ним исчезает и ваш рабочий процесс, у вас была зависимость от инструмента, а не система. Хороший результат этой главы — список Human Gate: его можно объяснить другому человеку, перенести в другой инструмент и проверить независимо от конкретной модели.

Как это выглядит на практике

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

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

Архитектурный принцип

Контекст должен приходить из системы, а не зависеть от того, вспомнил ли пользователь вставить нужный абзац в промпт.

Мини-кейс

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

Что может пойти не так

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

Практика

Создайте список Human Gate. Не описывайте идеальную будущую систему — используйте один реальный процесс. Укажите вход, источник фактов, роль AI или агента, правила, Human Gate, результат и место, где сохраняется новое состояние. Затем отметьте один шаг, который можно убрать или автоматизировать уже сейчас.

Контрольные вопросы

• Можно ли объяснить этот элемент системы человеку, который не знает ваших AI-инструментов?

• Что произойдёт, если данных недостаточно или они противоречат друг другу?

• Какой факт должен приходить из Source of Truth?

• Где проходит граница ответственности человека?

• По какой метрике вы поймёте, что система стала лучше?

Глава 8. Source of Truth для всей системы

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

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

Как это выглядит на практике

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

Для темы «Source of Truth для всей системы» полезно задать четыре вопроса: что является входом; какие факты нельзя придумывать; какое решение требуется; кто отвечает за последствия. Ответы сразу показывают, где достаточно правила, где полезен AI, где нужен специализированный агент, а где действие должно остановиться до подтверждения человека.

Архитектурный принцип

Факты и творческие выводы нужно разделять. Цена, статус, правило или договорённость берутся из Source of Truth; AI может объяснить или оформить их, но не изобретать.

Мини-кейс

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

Что может пойти не так

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

Практика

Создайте реестр источников истины. Не описывайте идеальную будущую систему — используйте один реальный процесс. Укажите вход, источник фактов, роль AI или агента, правила, Human Gate, результат и место, где сохраняется новое состояние. Затем отметьте один шаг, который можно убрать или автоматизировать уже сейчас.

Контрольные вопросы

• Можно ли объяснить этот элемент системы человеку, который не знает ваших AI-инструментов?

• Что произойдёт, если данных недостаточно или они противоречат друг другу?

• Какой факт должен приходить из Source of Truth?

• Где проходит граница ответственности человека?

• По какой метрике вы поймёте, что система стала лучше?

Глава 9. Human Gate как принцип архитектуры

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

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

Как это выглядит на практике

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

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

Архитектурный принцип

Каждый переход между этапами должен иметь понятный формат результата. Это позволяет заменить один компонент, не разрушая всю систему.

Мини-кейс

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

Что может пойти не так

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

Практика

Создайте правила остановки. Не описывайте идеальную будущую систему — используйте один реальный процесс. Укажите вход, источник фактов, роль AI или агента, правила, Human Gate, результат и место, где сохраняется новое состояние. Затем отметьте один шаг, который можно убрать или автоматизировать уже сейчас.

Контрольные вопросы

• Можно ли объяснить этот элемент системы человеку, который не знает ваших AI-инструментов?

• Что произойдёт, если данных недостаточно или они противоречат друг другу?

• Какой факт должен приходить из Source of Truth?

• Где проходит граница ответственности человека?

• По какой метрике вы поймёте, что система стала лучше?

Глава 10. Проектируем систему на одном листе

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

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

Как это выглядит на практике

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

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

Архитектурный принцип

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

Мини-кейс

Контентная система сначала ищет релевантные материалы в базе знаний, затем агент готовит черновик, критик проверяет факты и повторы, а публикация происходит только после Human Gate. Автоматизация ускоряет подготовку, но не превращает бренд в бесконтрольный генератор текста.

Что может пойти не так

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

Практика

Создайте одностраничная архитектура. Не описывайте идеальную будущую систему — используйте один реальный процесс. Укажите вход, источник фактов, роль AI или агента, правила, Human Gate, результат и место, где сохраняется новое состояние. Затем отметьте один шаг, который можно убрать или автоматизировать уже сейчас.

Контрольные вопросы

• Можно ли объяснить этот элемент системы человеку, который не знает ваших AI-инструментов?

• Что произойдёт, если данных недостаточно или они противоречат друг другу?

• Какой факт должен приходить из Source of Truth?

• Где проходит граница ответственности человека?

• По какой метрике вы поймёте, что система стала лучше?

Часть II. Личный AI-штаб

Глава 11. Что такое личный AI-штаб

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

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

Как это выглядит на практике

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

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

Архитектурный принцип

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

Мини-кейс

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

Что может пойти не так

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

Практика

Создайте набор функций штаба. Не описывайте идеальную будущую систему — используйте один реальный процесс. Укажите вход, источник фактов, роль AI или агента, правила, Human Gate, результат и место, где сохраняется новое состояние. Затем отметьте один шаг, который можно убрать или автоматизировать уже сейчас.

Контрольные вопросы

• Можно ли объяснить этот элемент системы человеку, который не знает ваших AI-инструментов?

• Что произойдёт, если данных недостаточно или они противоречат друг другу?

• Какой факт должен приходить из Source of Truth?

• Где проходит граница ответственности человека?

• По какой метрике вы поймёте, что система стала лучше?

Глава 12. Главный координатор системы

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

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

Как это выглядит на практике

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

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

Архитектурный принцип

Контекст должен приходить из системы, а не зависеть от того, вспомнил ли пользователь вставить нужный абзац в промпт.

Мини-кейс

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

Что может пойти не так

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

Практика

Создайте роль координатора. Не описывайте идеальную будущую систему — используйте один реальный процесс. Укажите вход, источник фактов, роль AI или агента, правила, Human Gate, результат и место, где сохраняется новое состояние. Затем отметьте один шаг, который можно убрать или автоматизировать уже сейчас.

Контрольные вопросы

• Можно ли объяснить этот элемент системы человеку, который не знает ваших AI-инструментов?

• Что произойдёт, если данных недостаточно или они противоречат друг другу?

• Какой факт должен приходить из Source of Truth?

• Где проходит граница ответственности человека?

• По какой метрике вы поймёте, что система стала лучше?

Глава 13. AI для мышления и принятия решений

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

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

Как это выглядит на практике

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

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

Архитектурный принцип

Факты и творческие выводы нужно разделять. Цена, статус, правило или договорённость берутся из Source of Truth; AI может объяснить или оформить их, но не изобретать.

Мини-кейс

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

Что может пойти не так

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

Практика

Создайте шаблон анализа решения. Не описывайте идеальную будущую систему — используйте один реальный процесс. Укажите вход, источник фактов, роль AI или агента, правила, Human Gate, результат и место, где сохраняется новое состояние. Затем отметьте один шаг, который можно убрать или автоматизировать уже сейчас.

Контрольные вопросы

• Можно ли объяснить этот элемент системы человеку, который не знает ваших AI-инструментов?

• Что произойдёт, если данных недостаточно или они противоречат друг другу?

• Какой факт должен приходить из Source of Truth?

• Где проходит граница ответственности человека?

• По какой метрике вы поймёте, что система стала лучше?

Глава 14. AI-исследователь

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

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

Как это выглядит на практике

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

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

Архитектурный принцип

Каждый переход между этапами должен иметь понятный формат результата. Это позволяет заменить один компонент, не разрушая всю систему.

Мини-кейс

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

Что может пойти не так

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

Практика

Создайте исследовательский протокол. Не описывайте идеальную будущую систему — используйте один реальный процесс. Укажите вход, источник фактов, роль AI или агента, правила, Human Gate, результат и место, где сохраняется новое состояние. Затем отметьте один шаг, который можно убрать или автоматизировать уже сейчас.

Контрольные вопросы

• Можно ли объяснить этот элемент системы человеку, который не знает ваших AI-инструментов?

• Что произойдёт, если данных недостаточно или они противоречат друг другу?

• Какой факт должен приходить из Source of Truth?

• Где проходит граница ответственности человека?

• По какой метрике вы поймёте, что система стала лучше?

Глава 15. AI-редактор и критик

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

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

Как это выглядит на практике

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

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

Архитектурный принцип

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

Мини-кейс

Контентная система сначала ищет релевантные материалы в базе знаний, затем агент готовит черновик, критик проверяет факты и повторы, а публикация происходит только после Human Gate. Автоматизация ускоряет подготовку, но не превращает бренд в бесконтрольный генератор текста.

Что может пойти не так

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

Практика

Создайте чек-лист критика. Не описывайте идеальную будущую систему — используйте один реальный процесс. Укажите вход, источник фактов, роль AI или агента, правила, Human Gate, результат и место, где сохраняется новое состояние. Затем отметьте один шаг, который можно убрать или автоматизировать уже сейчас.

Контрольные вопросы

• Можно ли объяснить этот элемент системы человеку, который не знает ваших AI-инструментов?

• Что произойдёт, если данных недостаточно или они противоречат друг другу?

• Какой факт должен приходить из Source of Truth?

• Где проходит граница ответственности человека?

• По какой метрике вы поймёте, что система стала лучше?

Глава 16. AI-планировщик

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

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

Как это выглядит на практике

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

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

Архитектурный принцип

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

Мини-кейс

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

Что может пойти не так

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

Практика

Создайте план с контрольными точками. Не описывайте идеальную будущую систему — используйте один реальный процесс. Укажите вход, источник фактов, роль AI или агента, правила, Human Gate, результат и место, где сохраняется новое состояние. Затем отметьте один шаг, который можно убрать или автоматизировать уже сейчас.

Контрольные вопросы

• Можно ли объяснить этот элемент системы человеку, который не знает ваших AI-инструментов?

• Что произойдёт, если данных недостаточно или они противоречат друг другу?

• Какой факт должен приходить из Source of Truth?

• Где проходит граница ответственности человека?

• По какой метрике вы поймёте, что система стала лучше?

Глава 17. AI-аналитик

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

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

Как это выглядит на практике

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

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

Архитектурный принцип

Контекст должен приходить из системы, а не зависеть от того, вспомнил ли пользователь вставить нужный абзац в промпт.

Мини-кейс

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

Что может пойти не так

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

Практика

Создайте шаблон аналитической сводки. Не описывайте идеальную будущую систему — используйте один реальный процесс. Укажите вход, источник фактов, роль AI или агента, правила, Human Gate, результат и место, где сохраняется новое состояние. Затем отметьте один шаг, который можно убрать или автоматизировать уже сейчас.

Контрольные вопросы

• Можно ли объяснить этот элемент системы человеку, который не знает ваших AI-инструментов?

• Что произойдёт, если данных недостаточно или они противоречат друг другу?

• Какой факт должен приходить из Source of Truth?

• Где проходит граница ответственности человека?

• По какой метрике вы поймёте, что система стала лучше?

Глава 18. AI-секретарь

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

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

Как это выглядит на практике

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

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

Архитектурный принцип

Факты и творческие выводы нужно разделять. Цена, статус, правило или договорённость берутся из Source of Truth; AI может объяснить или оформить их, но не изобретать.

Мини-кейс

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

Что может пойти не так

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

Практика

Создайте единый формат итогов и задач. Не описывайте идеальную будущую систему — используйте один реальный процесс. Укажите вход, источник фактов, роль AI или агента, правила, Human Gate, результат и место, где сохраняется новое состояние. Затем отметьте один шаг, который можно убрать или автоматизировать уже сейчас.

Контрольные вопросы

• Можно ли объяснить этот элемент системы человеку, который не знает ваших AI-инструментов?

• Что произойдёт, если данных недостаточно или они противоречат друг другу?

• Какой факт должен приходить из Source of Truth?

• Где проходит граница ответственности человека?

• По какой метрике вы поймёте, что система стала лучше?

Глава 19. Единый вход для задач

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

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

Как это выглядит на практике

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

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

Архитектурный принцип

Каждый переход между этапами должен иметь понятный формат результата. Это позволяет заменить один компонент, не разрушая всю систему.

Мини-кейс

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

Что может пойти не так

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

Практика

Создайте единая очередь. Не описывайте идеальную будущую систему — используйте один реальный процесс. Укажите вход, источник фактов, роль AI или агента, правила, Human Gate, результат и место, где сохраняется новое состояние. Затем отметьте один шаг, который можно убрать или автоматизировать уже сейчас.

Контрольные вопросы

• Можно ли объяснить этот элемент системы человеку, который не знает ваших AI-инструментов?

• Что произойдёт, если данных недостаточно или они противоречат друг другу?

• Какой факт должен приходить из Source of Truth?

• Где проходит граница ответственности человека?

• По какой метрике вы поймёте, что система стала лучше?

Глава 20. Ежедневный цикл работы с AI-штабом

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

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

Как это выглядит на практике

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

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

Архитектурный принцип

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

Мини-кейс

Контентная система сначала ищет релевантные материалы в базе знаний, затем агент готовит черновик, критик проверяет факты и повторы, а публикация происходит только после Human Gate. Автоматизация ускоряет подготовку, но не превращает бренд в бесконтрольный генератор текста.

Что может пойти не так

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

Практика

Создайте ежедневный цикл. Не описывайте идеальную будущую систему — используйте один реальный процесс. Укажите вход, источник фактов, роль AI или агента, правила, Human Gate, результат и место, где сохраняется новое состояние. Затем отметьте один шаг, который можно убрать или автоматизировать уже сейчас.

Контрольные вопросы

• Можно ли объяснить этот элемент системы человеку, который не знает ваших AI-инструментов?

• Что произойдёт, если данных недостаточно или они противоречат друг другу?

• Какой факт должен приходить из Source of Truth?

• Где проходит граница ответственности человека?

• По какой метрике вы поймёте, что система стала лучше?

Часть III. Память и база знаний

Глава 21. Почему память важнее длинного промпта

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

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

Как это выглядит на практике

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

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

Архитектурный принцип

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

Мини-кейс

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

Что может пойти не так

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

Практика

Создайте модель памяти. Не описывайте идеальную будущую систему — используйте один реальный процесс. Укажите вход, источник фактов, роль AI или агента, правила, Human Gate, результат и место, где сохраняется новое состояние. Затем отметьте один шаг, который можно убрать или автоматизировать уже сейчас.

Контрольные вопросы

• Можно ли объяснить этот элемент системы человеку, который не знает ваших AI-инструментов?

• Что произойдёт, если данных недостаточно или они противоречат друг другу?

• Какой факт должен приходить из Source of Truth?

• Где проходит граница ответственности человека?

• По какой метрике вы поймёте, что система стала лучше?

Глава 22. Что система должна помнить о проектах

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

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

Как это выглядит на практике

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

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

Архитектурный принцип

Контекст должен приходить из системы, а не зависеть от того, вспомнил ли пользователь вставить нужный абзац в промпт.

Мини-кейс

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

Что может пойти не так

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

Практика

Создайте карточка проекта. Не описывайте идеальную будущую систему — используйте один реальный процесс. Укажите вход, источник фактов, роль AI или агента, правила, Human Gate, результат и место, где сохраняется новое состояние. Затем отметьте один шаг, который можно убрать или автоматизировать уже сейчас.

Контрольные вопросы

• Можно ли объяснить этот элемент системы человеку, который не знает ваших AI-инструментов?

• Что произойдёт, если данных недостаточно или они противоречат друг другу?

• Какой факт должен приходить из Source of Truth?

• Где проходит граница ответственности человека?

• По какой метрике вы поймёте, что система стала лучше?

Глава 23. Что система не должна помнить

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

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

Как это выглядит на практике

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

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

Архитектурный принцип

Факты и творческие выводы нужно разделять. Цена, статус, правило или договорённость берутся из Source of Truth; AI может объяснить или оформить их, но не изобретать.

Мини-кейс

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

Что может пойти не так

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

Практика

Создайте политика хранения. Не описывайте идеальную будущую систему — используйте один реальный процесс. Укажите вход, источник фактов, роль AI или агента, правила, Human Gate, результат и место, где сохраняется новое состояние. Затем отметьте один шаг, который можно убрать или автоматизировать уже сейчас.

Контрольные вопросы

• Можно ли объяснить этот элемент системы человеку, который не знает ваших AI-инструментов?

• Что произойдёт, если данных недостаточно или они противоречат друг другу?

• Какой факт должен приходить из Source of Truth?

• Где проходит граница ответственности человека?

• По какой метрике вы поймёте, что система стала лучше?

Глава 24. Личная база знаний

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

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

Как это выглядит на практике

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

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

Архитектурный принцип

Каждый переход между этапами должен иметь понятный формат результата. Это позволяет заменить один компонент, не разрушая всю систему.

Мини-кейс

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

Что может пойти не так

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

Практика

Создайте структура базы. Не описывайте идеальную будущую систему — используйте один реальный процесс. Укажите вход, источник фактов, роль AI или агента, правила, Human Gate, результат и место, где сохраняется новое состояние. Затем отметьте один шаг, который можно убрать или автоматизировать уже сейчас.

Контрольные вопросы

• Можно ли объяснить этот элемент системы человеку, который не знает ваших AI-инструментов?

• Что произойдёт, если данных недостаточно или они противоречат друг другу?

• Какой факт должен приходить из Source of Truth?

• Где проходит граница ответственности человека?

• По какой метрике вы поймёте, что система стала лучше?

Глава 25. База знаний компании

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

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

Как это выглядит на практике

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

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

Архитектурный принцип

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

Мини-кейс

Контентная система сначала ищет релевантные материалы в базе знаний, затем агент готовит черновик, критик проверяет факты и повторы, а публикация происходит только после Human Gate. Автоматизация ускоряет подготовку, но не превращает бренд в бесконтрольный генератор текста.

Что может пойти не так

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

Практика

Создайте база знаний компании. Не описывайте идеальную будущую систему — используйте один реальный процесс. Укажите вход, источник фактов, роль AI или агента, правила, Human Gate, результат и место, где сохраняется новое состояние. Затем отметьте один шаг, который можно убрать или автоматизировать уже сейчас.

Контрольные вопросы

• Можно ли объяснить этот элемент системы человеку, который не знает ваших AI-инструментов?

• Что произойдёт, если данных недостаточно или они противоречат друг другу?

• Какой факт должен приходить из Source of Truth?

• Где проходит граница ответственности человека?

• По какой метрике вы поймёте, что система стала лучше?

Глава 26. Структура знаний: факты, правила, решения, примеры

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

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

Как это выглядит на практике

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

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

Архитектурный принцип

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

Мини-кейс

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

Что может пойти не так

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

Практика

Создайте типология записей. Не описывайте идеальную будущую систему — используйте один реальный процесс. Укажите вход, источник фактов, роль AI или агента, правила, Human Gate, результат и место, где сохраняется новое состояние. Затем отметьте один шаг, который можно убрать или автоматизировать уже сейчас.

Контрольные вопросы

• Можно ли объяснить этот элемент системы человеку, который не знает ваших AI-инструментов?

• Что произойдёт, если данных недостаточно или они противоречат друг другу?

• Какой факт должен приходить из Source of Truth?

• Где проходит граница ответственности человека?

• По какой метрике вы поймёте, что система стала лучше?

Глава 27. Версии и актуальность информации

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

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

Как это выглядит на практике

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

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

Архитектурный принцип

Контекст должен приходить из системы, а не зависеть от того, вспомнил ли пользователь вставить нужный абзац в промпт.

Мини-кейс

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

Что может пойти не так

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

Практика

Создайте версионность. Не описывайте идеальную будущую систему — используйте один реальный процесс. Укажите вход, источник фактов, роль AI или агента, правила, Human Gate, результат и место, где сохраняется новое состояние. Затем отметьте один шаг, который можно убрать или автоматизировать уже сейчас.

Контрольные вопросы

• Можно ли объяснить этот элемент системы человеку, который не знает ваших AI-инструментов?

• Что произойдёт, если данных недостаточно или они противоречат друг другу?

• Какой факт должен приходить из Source of Truth?

• Где проходит граница ответственности человека?

• По какой метрике вы поймёте, что система стала лучше?

Глава 28. Поиск по смыслу вместо поиска по папкам

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

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

Как это выглядит на практике

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

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

Архитектурный принцип

Факты и творческие выводы нужно разделять. Цена, статус, правило или договорённость берутся из Source of Truth; AI может объяснить или оформить их, но не изобретать.

Мини-кейс

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

Что может пойти не так

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

Практика

Создайте семантический поиск. Не описывайте идеальную будущую систему — используйте один реальный процесс. Укажите вход, источник фактов, роль AI или агента, правила, Human Gate, результат и место, где сохраняется новое состояние. Затем отметьте один шаг, который можно убрать или автоматизировать уже сейчас.

Контрольные вопросы