Если вы решили внедрять ИИ в ваш проект, то скорее всего наступит момент, когда потребуется техническое задание. Так как внедрять ИИ часто начинают уже «прокачанные» пользователи ChatGPT, возникает соблазн отдать написание этого самого ТЗ самому ИИ. А возможно, ещё и разослав это ТЗ разным исполнителям, оценить с помощью ИИ их предложения. Что может при этом пойти не так, разберём в этой статье.
Кому может помочь эта статья
- Разработчику, если ваш начальник или клиент сгенерировал ТЗ с помощью ИИ, — найти аргументы, почему этого недостаточно (хотя не факт, что они помогут)
- Руководителю, использующему ИИ и планирующему внедрение ИИ в организацию
Что есть в этой статье
- Какие проблемы могут быть в сгенерированном ИИ ТЗ на внедрение ИИ (с примерами)
- К чему приведёт использование такого ТЗ
- Небольшой совет, для чего всё-таки можно использовать ИИ при подготовке такого ТЗ
Приведенные примеры изменены для защиты конфиденциальности, но основаны на реальных ТЗ полученных от заказчиков.
Описанное ниже актуально на момент написания статьи. Ситуация может и скорее всего изменится в будущем, но не факт, что обязательно в лучшую сторону. Итак, начнём.
ИИ легко добавит в ваше ТЗ ненужных требований и сделает его непонятным
Возьмём, например, такой фрагмент:
3. Функциональные требования (по модулям)
3.1. Модуль первичного контакта (чат-бот + голосовой интерфейс)
- Прием запросов в Telegram, Slack, корпоративном портале и по телефону (IVR + распознавание речи).
- Автоматическое определение сути вопроса: отпуск, справка, больничный, обучение, увольнение, зарплата, вакансия.
- Поддержка русского и английского языка (ввод текста и голос).
3.2. Помощник по кадровым документам
- Выдача справок: формирование PDF справки 2-НДФЛ, с места работы, о периоде отпуска по шаблонам.
- Подписание документов: интеграция с КЭП / простой ЭП (запрос подписи у сотрудника через бота).
- Обработка заявлений: прием заявления на отпуск, увольнение, материальную помощь — валидация полей, проверка остатков дней, создание задачи в 1С/СБИС.
Красивый текст. Что с ним не так? Оказывается, компания, приславшая ТЗ, не использует Slack (ожидаемо), не принимает кадровых запросов с корпоративного портала и по телефону. Не зная нужных деталей, ИИ вставил все эти требования сам.
Но это полбеды. При разговоре с заказчиком выясняется, что он хотел автоматизировать только один процесс — приём сотрудников на работу. Что суть проблемы в том, что на один почтовый ящик приходят пачки несортированных документов большого числа нанимаемых на временную работу сотрудников (такая специфика организации) и сейчас бухгалтер вручную сортирует и группирует их по сотрудникам. Как получилось такое ТЗ? Кто-то написал общий запрос вроде «Составить ТЗ для разработки ИИ-сотрудника отдела кадров» — и вот оно возникло.
Или вот такой пример:
1. Система предиктивной аналитики
1.1. Анализ факторов:
- Исторические данные
- Сезонные колебания
- Маркетинговые акции
2. Автоматизация процессов
2.1. Роботизация процессов
- Обработка входящих документов, консолидация с 1С
- Извлечение, внесение данных
- Верификация информации
- Формирование отчетности (предиктивная аналитика)
Что вообще необходимо сделать в этой задаче? Если вы думаете, что далее в тексте будет объяснение, то нет. Далее следуют технические требования к ПО, к точности работы, интеграции с разными приложениями и т. п. Но для понимания сути у нас есть вот эти «функциональные требования» и название «Техническое задание на разработку ИИ-агента для системы закупок».
Вы можете подумать, что это слишком уж очевидные ошибки и «в моём-то ТЗ точно такого не будет». Действительно, на первый взгляд решение этой проблемы на поверхности — дать ИИ больше контекста. Что за организация, в чём суть проблемы, как сейчас протекает процесс, несколько кейсов.
Но тут важно разделять ситуации. Если вы разработчик и пишете ТЗ сами, то вполне нормально, собрав нужную информацию, дать ИИ оформить её в ТЗ, проверив после этого тщательно результат. Но если вы руководитель или менеджер и описываете бизнес-задачу для отправки разработчику, то информацию нужно собрать, а вот шаг оформления с помощью ИИ лучше пропустить. Если какие-то аспекты текста были непонятны грамотному человеку-специалисту до обработки ИИ, то после обработки они не станут яснее, а вот мутировать во что-то иное вполне смогут, и далеко не всегда вы сможете эту «мутацию» обнаружить. Если будет так нужно, получивший задачу специалист сможет вставить требования в чат и оформить красиво.
Но, возможно, ИИ сможет добавить ценные технические подробности и описать способы реализации системы?
ИИ плохо проектирует системы с ИИ
И на то есть много причин. Самая очевидная — это отставание моделей по времени. Если мы спросим основные модели о том, когда собирались данные для их обучения, то (на момент написания статьи — апрель 2026) мы узнаем следующее:
• Deepseek: My knowledge cutoff is July 2024• Gemini 3.1 Pro: Currently, my core foundational training generally extends into early 2024• GPT 5.4: My knowledge cutoff is 2024-06.
Лишённые инструментов поиска 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 3 — это если вам ещё повезёт. Не так редко приходят ТЗ, где анализировать, например, правильность составления договоров предлагается исключительно с помощью NLTK, извлечения сущностей и синтаксического разбора предложений. И не в роли вспомогательных инструментов, а в качестве основных средств реализации.
Хорошо, но ведь есть инструменты веб-поиска, они могут найти нужную информацию. Но найти информацию и суметь её верно применить — это совершенно разные вещи. Внешне за счёт веб-поиска ваше ТЗ станет более современным — в него вставятся осовремененные версии моделей, новые фреймворки и крутые технологии. Но понимания возможностей, ограничений, результатов, которые эти технологии дают, из десятка найденных в интернете статей у ИИ не появится.
Даже если мы забудем проблему отставания по времени, ИИ в целом плохо предсказывает, что он может, а что не может делать (https://arxiv.org/pdf/2512.24661). Исследования показывают, что хотя ИИ имеет определенные представления о том, окончатся ли его действия успехом или неудачей (что уже удивительно), на практике модели слишком «самоуверенны» и плохо понимают свои ограничения.
А как же, спросите вы, постоянно появляются новости о том, что ИИ разработал новый ИИ лучше, чем человек? Такие новости действительно есть (напримерhttps://arxiv.org/abs/2505.22954) илиhttps://arxiv.org/abs/2603.19461). Но это вовсе не означает, что кто-то вставил задачу в ChatGPT и получил лучший ИИ. Такие вещи возможны, когда взят ИИ-агент, обычно специально написанный под задачу и, возможно, специально обученный на нужных данных, и ему дали конкретную задачу, результат которой можно автоматически проверить и выразить числом. Далее этот ИИ-агент начал пробовать различные решения в большом количестве и смотреть, что получается, обучаясь на полученном результате, и в итоге нашёл некоторое улучшение по сравнению с известным ранее. При этом было потрачено прилично денег на вычисления и времени на подготовку данного эксперимента. Когда же вы даёте ChatGPT или DeepSeek или подобному ИИ задачу написать ТЗ, то оно пишется чисто умозрительно, без возможности проверить вводимые допущения на практике, и результат этого часто бывает плачевным.
ИИ вставит в ваше ТЗ лишние технологии и бесполезные критерии проверки
Вот, например, требования к технологиям, которые должны присутствовать:
Технологии
Библиотеки / Инструменты
Python 3.11+
FastAPI / Django
fastapi, pydantic
LLM Оркестрация
LangChain / LlamaIndex
langchain, llama-index
Векторная БД
Milvus / Weaviate / Qdrant
qdrant-client, weaviate-client
Кеширование
RabbitMQ / Kafka
celery, kafka-python
Monitoring
Prometheus + Grafana
Опять, на первый взгляд всё хорошо и красиво расписано. Но. А нужна ли вам в конкретном проекте вообще очередь, нужен ли там мониторинг с Prometheus, требуется ли кеширование с Redis?
Какие основные риски при внедрении ИИ? Что этот ИИ будет работать неправильно, что в задаче обнаружатся подводные камни, которые были неизвестны ранее, или задача вообще поставлена неправильно. Наконец, что люди, которые должны будут с ИИ так или иначе взаимодействовать, не смогут или не захотят это делать. Чтобы их минимизировать, нужно сначала сделать максимально быстро и малыми затратами прототип, где будет присутствовать основная функция, которую ИИ должен выполнять.
Такой прототип часто позволяет узнать много интересного. Например, была компания, внедрявшая ИИ в работу менеджеров продаж. На этапе запуска выяснилось, что основная функция разработанного ИИ в реальности не нужна, так как процесс работы менеджера в реальности сильно отличается от представлений руководства о нём. Данный риск есть в разработке любого ПО, но ИИ вносит дополнительные факторы неопределённости, которые в целом мешают сначала всё спроектировать «как нужно» и потом делать. Поэтому, если уж совсем честно, написать и оценить ТЗ на внедрение правильно можно только после создания прототипа.
Теперь посмотрим на критерии оценки качества. Вот, например, как ИИ предлагает нам оценивать «ИИ-юриста»:
Ключевые метрики качества
Инструмент
Точность ответов
RAGAS, человеческая оценка
Время ответа
Prometheus
Hallucination rate
Fact verification
Цитирование
100% источников
Citation checker
Monitoring
Время ответа меньше трёх секунд не соответствует задаче. Какая рассуждающая модель может ответить меньше чем за три секунды на любой запрос? Учитывая, что ещё ТЗ подразумевает поиск документов в базе, их чтение и анализ, а суть вопроса может быть сколь угодно сложна, это невыполнимое требование, если мы хотим качественных ответов.
Инструмента «Citation checker» не существует, он нигде не определен в тексте ТЗ и не ясно, что это вообще такое должно быть.
Точность ответов 90% — откуда эта цифра? Ответ тут только такой — она красивая и ИИ так захотелось.
Как нужно определять желаемую цифру? Правильная точность — это та, которая позволяет решать бизнес-задачу. Если вы заменяете труд сотрудника, то в качестве разумного приближения можно измерить, насколько точно работает сотрудник сейчас. В ряде случаев для бизнес-задачи может подойти и меньшая точность — если, например, существует возможность автоматически определить/отфильтровать подозрительные результаты. Почему вообще нельзя сюда вписать любую цифру, которая нравится?
Для начала, точность — это не та цифра, которую можно заложить при проектировании. То есть ИИ — это не мост или небоскрёб, где можно сказать «требуется такая-то прочность конструкции» и по формулам посчитать, сколько будет стоить и как должно быть устроено. В ИИ точность — это не параметр, который вы сможете заложить в проект. Точность — это параметр, который вы измеряете, когда всё уже готово и работает. Если она достаточная — это хорошо. Если нет — нужно работать ещё.
Даже если в похожей задаче ранее была получена определённая точность, это ещё не означает, что такое же решение покажет тот же результат у вас. Точность может меняться со временем и зависеть от самых разных факторов. Существует много способов измерения точности, но это тоже отдельная тема.
Что важно сказать сейчас — это то, что существует кривая соотношения точности и затрат (рис. 1) — максимальной точности, которую можно получить на данной задаче при выбранном бюджете. Ловушка заключается в том, что «небольшое» с точки зрения заказчика увеличение точности может вести к огромному увеличению затрат. Условно говоря, попасть с 60% до 85% точности может стоить 40 тысяч рублей, а с 90% до 92% — десять миллионов. Отсюда вставленная с лёгкой руки ИИ случайная красивая цифра может привести к многократному удорожанию разработки при отсутствии реальной пользы для бизнес-задачи.
Рисунок 1. Кривая соотношения точности и затрат
Также, не следует, посмотрев на кривую, просто менять промт на что-то вроде «напиши оптимальное значение точности при данных затратах). Ибо ИИ не знает для вашей конкретной задачи (кроме, возможно самых тривиальных случаев) конкретных параметров кривой. Хуже того, в общем случае никто в мире их не знает точно.
Тут можно много сказать о оптимальной стратегии поиска нужной точки, но это потянет на отдельную статью. Например про то, что увеличение точности по выбранной метрике может вообще вести к ухудшению выполнения бизнес-задачи. Поэтому пока ограничимся фактом — вставленные ИИ критерии являются догадками, часто плохими и на них не следует полагаться.
Также не следует, посмотрев на кривую, просто менять промпт на что-то вроде «напиши оптимальное значение точности при данных затратах». Ибо ИИ не знает для вашей конкретной задачи (кроме, возможно, самых тривиальных случаев) конкретных параметров кривой. Хуже того, в общем случае никто в мире их не знает точно.
Тут можно много сказать об оптимальной стратегии поиска нужной точки, но это потянет на отдельную статью. Например, про то, что увеличение точности по выбранной метрике может вообще вести к ухудшению выполнения бизнес-задачи. Поэтому пока ограничимся фактом — вставленные ИИ критерии являются догадками, часто плохими, и на них не следует полагаться.
Какие последствия в итоге будут от сгенерированного ТЗ
Итак, вы пошли в ChatGPT, сгенерировали ТЗ и разослали его в 30 компаний. Что произойдёт?
Есть несколько основных вариантов:
- Его прочитают, поймут, что это проблемное ТЗ, и честно постараются обсудить с вами проблему. Вроде: а действительно ли вам нужна точность 99%? Но вступить в сложные обсуждения с клиентом на этом этапе почти наверняка значит клиента потерять, поэтому давление естественного отбора приводит к постепенному исчезновению такого подхода.
- Его прочитают, честно оценят все пункты и сделают честное КП на основании этого ТЗ. Получится правильное КП, но не на тот продукт, который вам нужен, и соответственно с далёкими от реальности оценками сроков и стоимости.
- Его выкинут в мусорку, продажник сделает предложение, которое, с его точки зрения, вы хотите увидеть больше всего и которое скорее продвинет вас по воронке продаж, рассчитывая реальную цену и объём работ «уточнить» позже.
В итоге вы соберёте предложения, но они вообще ничего не будут означать — всё равно что получить набор случайных чисел. Как потом эти предложения сравнивать, вообще непонятно. Впрочем, непонятно это мне. Но есть люди, которые нашли выход — загрузить все эти предложения в ChatGPT и пусть он выберет лучшее. Если вам пришла в голову такая же идея, то желательно постараться её забыть. Во-первых, бессмысленно сравнивать предложения, полученные с использованием изначально неправильных входных данных. Во-вторых, ИИ имеет ряд неприятных свойств, например предпочитать сгенерированные тексты написанным вручную(https://arxiv.org/abs/2404.13076) .
Эта проблема присутствует как в старых моделях вроде GPT-4, так и в более новых. Более того, в новых моделях она становится хуже. В современных моделях, начиная где-то с GPT-5, в ходе фазы обучения с подкреплением есть цикл — один ИИ пишет текст, второй оценивает. Поэтому модель учится выдавать тексты, которые нравятся другим моделям, при этом они могут быть вообще бессмысленными, но получать высокие оценки (https://www.christoph-heilig.de/en/post/gpt-5-is-a-terrible-storyteller-and-that-s-an-ai-safety-problem).
Наконец, появились специально оптимизированные под ИИ коммерческие предложения, написанные так, чтобы ИИ предпочитал именно их по сравнению со всеми остальными. Это несложно сделать, генерируя предложения и проверяя, какие из них получают у ИИ более высокую оценку.
Как можно использовать ИИ при составлении ТЗ
На вопрос «как заказчику правильно написать ТЗ на внедрение ИИ с помощью ИИ» правильный ответ — никак. ТЗ должен писать исполнитель, а не заказчик. Заказчику же нужно создать условия, чтобы исполнитель смог это сделать адекватно. В частности, можно сделать неформальное описание задачи — что собственно нужно. Для этого можно спросить ИИ что-то вроде «Я хочу сделать XYZ. Сформулируй вопросы, ответы на которые помогут разработчику понять и оценить задачу». И получив список вопросов, найти и написать ответы на них вручную. Можно устроить с ИИ обсуждение, попросив покритиковать написанное, спросить, какой информации всё ещё не хватает, что можно уточнить.
Источники, упомянутые в статье
- Barkan C. O., Black S., Sourbut O. Do Large Language Models Know What They Are Capable Of? //arXiv preprint arXiv:2512.24661. – 2025.
- Zhang, Jenny, et al. “Darwin godel machine: Open-ended evolution of self-improving agents.” arXiv preprint arXiv:2505.22954 (2025).
- Zhang J. et al. Hyperagents //arXiv preprint arXiv:2603.19461. – 2026.
- Panickssery A., Bowman S. R., Feng S. Llm evaluators recognize and favor their own generations //Advances in Neural Information Processing Systems. – 2024. – Т. 37. – С. 68772-68802.
- Christoph Heilig. GPT-5 Is a Terrible Storyteller – And That’s an AI Safety Problemhttps://www.christoph-heilig.de/en/post/gpt-5-is-a-terrible-storyteller-and-that-s-an-ai-safety-problem
