Почему ТЗ на внедрение ИИ не стоит поручать ChatGPT и его «коллегам» — VogueTech

Что произошло

Бизнес массово пробует внедрять ИИ‑сервисы — от чат-ботов до предиктивной аналитики. Параллельно растёт число людей, которые уже уверенно пользуются ChatGPT, GPT‑5.4, Gemini 3.1 Pro, DeepSeek и похожими моделями.

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

Автор материала разбирает, что происходит, когда руководитель или менеджер реально так делает, и показывает на реальных (обезличенных) примерах, к чему это приводит.

Зачем это нужно

Логика у заказчиков простая:

ИИ уже помогает писать письма, отчёты, регламенты.
ТЗ — это тоже текст с формальной структурой.
Значит, можно сэкономить время: описать задачу в одном-двух абзацах, отдать в ChatGPT или другую модель и получить «готовое ТЗ».

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

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

Для заказчика это опасно по трём причинам:

В ТЗ появляются требования, которых он никогда не хотел и которые не соответствуют реальным процессам.
Исчезает фокус на реальной бизнес-проблеме: ТЗ превращается в общее описание «цифрового помощника», а не конкретного решения.
Руководитель верит в формальную «проработанность» документа и не видит, что ключевые вещи либо не описаны, либо описаны неверно.

Что меняет для рынка

Как ИИ «дорисовывает» лишние требования

Пример из реального ТЗ, сгенерированного с помощью ИИ (фрагмент функциональных требований):

3.1. Модуль первичного контакта (чат-бот + голосовой интерфейс)
– Прием запросов в Telegram, Slack, корпоративном портале и по телефону (IVR + распознавание речи).
– Автоматическое определение сути вопроса: отпуск, справка, больничный, обучение, увольнение, зарплата, вакансия.
– Поддержка русского и английского языка (ввод текста и голос).

3.2. Помощник по кадровым документам
– Выдача справок: формирование PDF справки 2‑НДФЛ, с места работы, о периоде отпуска по шаблонам.
– Подписание документов: интеграция с КЭП / простой ЭП (запрос подписи у сотрудника через бота).
– Обработка заявлений: прием заявления на отпуск, увольнение, материальную помощь — валидация полей, проверка остатков дней, создание задачи в 1С/СБИС.

На бумаге всё выглядит солидно: мессенджеры, IVR, голос, русский и английский, интеграции с 1С и СБИС, электронная подпись. Но при разговоре с заказчиком выяснилось:

Компания не использует Slack.
Кадровые запросы не принимают ни с корпоративного портала, ни по телефону.
Основная боль — только одна: приём сотрудников на временную работу.

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

ИИ, не имея этих деталей, просто сгенерировал «стандартный» набор каналов и функций HR‑бота. Руководитель получил красивое, но нерелевантное ТЗ, которое описывает не его процесс, а усреднённую картинку из обучающей выборки модели.

Второй пример — «Техническое задание на разработку ИИ‑агента для системы закупок». Фрагмент:

1. Система предиктивной аналитики
1.1. Анализ факторов:
– Исторические данные
– Сезонные колебания
– Маркетинговые акции

2. Автоматизация процессов
2.1. Роботизация процессов:
– Обработка входящих документов, консолидация с 1С
– Извлечение, внесение данных
– Верификация информации
– Формирование отчетности (предиктивная аналитика)

Дальше в документе идут технические требования к ПО, точности, интеграциям. Но нигде не объяснено, что именно должен делать этот «ИИ‑агент для системы закупок»: какие решения принимать, какие сценарии закрывать, какие метрики улучшать.

Для интегратора такое ТЗ означает одно: нужно тратить время на интервью, чтобы заново выяснить, в чём суть задачи. Для рынка в целом это означает рост числа проектов, которые стартуют с иллюзии «у нас всё уже описано», а потом упираются в то, что нужно переписывать постановку задачи.

Почему «дать ИИ больше контекста» не решает проблему

Интуитивный ответ многих пользователей: «Надо просто написать ИИ побольше вводных — и он всё сделает правильно».

Это частично верно, если вы сами разработчик или аналитик:

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

Тогда ИИ полезен как стилистический и структурный помощник: он превращает заметки в аккуратное ТЗ, но не подменяет собой постановщика задачи.

Если же вы руководитель или менеджер, который описывает бизнес‑проблему для передачи разработчику, ситуация другая:

ИИ не добавит вам понимания процесса — он только переформулирует то, что вы уже понимаете (или не понимаете).
Неполные или размытые вводные он превратит в уверенный, логичный, но местами неверный текст.
Вы можете не заметить, где именно документ «съехал» — особенно если формально он выглядит профессионально.

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

Почему ИИ плохо проектирует системы с ИИ

Автор отдельно поднимает вопрос: может ли ИИ не только оформить текст, но и подсказать архитектуру, технические решения, подходы к внедрению?

Здесь появляется ещё один пласт проблем — отставание по времени и ограниченность знаний о текущем стеке.

На момент написания материала (апрель 2026 года) крупные модели сами честно признают свои границы:

DeepSeek сообщает: knowledge cutoff — июль 2024.
Gemini 3.1 Pro говорит, что основное обучение заканчивается в начале 2024.
GPT‑5.4 указывает срез знаний июнь 2024, но при этом «знает» о событиях начала 2025 года.

Простой тест: если отключить у DeepSeek и Gemini 3.1 доступ к поиску, они называют президентом США Джо Байдена. GPT‑5.4 без инструментов уже знает про Трампа как президента в начале 2025 года. Для политических новостей это мелкая погрешность. Для ИИ‑проектирования — нет.

Пример: Claude Code вышел в декабре 2025 года. Если спросить «чистый» GPT‑5.4 (без внешних инструментов), какие последние модели Claude он знает, он отвечает:

As of early 2025, the latest major Anthropic Claude models are:
– Claude 3.5 Sonnet — widely used general-purpose flagship
– Claude 3 Opus — highest-capability Claude 3 model
– Claude 3 Haiku — fastest/lightest Claude 3 model

Никакого Claude Code в его картине мира нет. Это значит, что при проектировании системы, где выбор между «написать свой инструмент» и «взять уже существующий Claude Code», ИИ просто не предложит второй вариант — он о нём не знает.

Когда вы проектируете внедрение ИИ или целую ИИ‑систему, такие лакуны по времени превращаются в технический долг ещё на этапе ТЗ:

в документ не попадают свежие продукты и подходы, появившиеся за последние полтора-два года;
архитектура опирается на устаревшие представления о возможностях моделей;
закладываются лишние ограничения и костыли, которые уже не нужны в текущем стеке.

В итоге рынок получает ТЗ, которые выглядят современными, но уже на момент написания отстают от доступных инструментов и практик.

Что это значит для вас

Если вы руководитель или владелец продукта:

Не поручайте ИИ писать ТЗ «под ключ». Используйте его максимум как помощника по структуре и языку после того, как вместе с аналитиком разобрали процессы.
Не отправляйте подрядчикам текст, который вы не можете сами объяснить по пунктам. Если вы не понимаете, зачем в ТЗ IVR, Slack или предиктивная аналитика, — этого там быть не должно.
Заложите время и бюджет на нормальную постановку задачи: интервью, описание текущих процессов, формулировку метрик успеха. Это дешевле, чем переделывать проект после красивого, но ошибочного ТЗ.

Если вы разработчик или интегратор:

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

Если вы активно пользуетесь ChatGPT, GPT‑5.4, Gemini 3.1 Pro или DeepSeek:

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

ИИ отлично справляется с ролью редактора и помощника. Но когда вы поручаете ему написать ТЗ на внедрение ИИ «с нуля» и без технического собеседника рядом, вы по сути отдаёте управление проектом модели, которая уверенно говорит о мире, которого уже нет или которую вы сами не до конца понимаете.

И это уже не про экономию времени, а про системный риск для бюджета и результата.