Заходишь на Хабр.Карьеру, открываешь вакансии системных аналитиков, а в требованиях всё как обычно: построение информационных систем, понимание архитектуры, ТЗ, BPMN, базовый SQL. Нигде ни слова о знании GPT или умении промптить. Формально профессия как будто не изменилась.
Тем временем в свежем отчёте OpenAI о корпоративном применении ИИ опубликовали статистику: использование ChatGPT в корпоративной среде за год выросло в 8 раз, а объём запросов от одного человека — в среднем на 30%.
Мы решили выяснить, что происходит в полях, и поговорили с двумя коллегами по цеху: системным архитектором из финтех-продукта и аналитиком с опытом работы и в госсекторе, и в корпоративных продуктах. Спросили их о самом важном: какие задачи быстрее делать с ИИ, где он пока бесполезен и что вообще стоит прокачивать аналитику, чтобы не выпасть из профессии, пока всех грозятся заменить моделями.
Ниже — выжимка из наших интервью с наблюдениями*, советами и прогнозами от тех, кто видит изменения у себя в компаниях.
Задачи системного аналитика не изменились, в отличие от условий рынка

Павел Бондаренко
Системный архитектор, преподаватель на курсах «Системный и бизнес-аналитик» и «Системный аналитик PRO» в Нетологии
Я всё время шучу, что системного аналитика пока не заставили разве что писать код за разработчиков. Уже давно он стал мультитулом команды: управляет сроками, тестирует, рисует макеты, совмещает бизнес- и системную аналитику. В большинстве компаний это по факту fullstack-аналитик. Если роли разделены — значит, у компании всё очень хорошо.
Задачи остались прежними, но изменился контекст. Бизнес хочет релизы быстрее, команды не растут, как в постковидные времена, а системы, наоборот, усложняются. В такой ситуации единственный способ успевать — найти рутину и переложить её на ИИ.

Дарья Татькова
Fullstack-аналитик со специализацией в финтехе, разрабатывала фронт-системы в СК Росгосстрах и СОГАЗ. Ex-ВТБ, Ex-Сбер, преподаватель и автор курсов по направлению системной аналитики и 1С-аналитики в Нетологии
У нас в команде на восемь разработчиков всего два аналитика. Детально прорабатывать каждую задачу физически невозможно. Поэтому типовые и рутинные вещи я делегирую ИИ, чтобы укладываться в сроки и сохранить качество.
Ещё Дарья рассказала нам, что на уровне компании ИИ тоже активно внедряют. Например, у них разрабатывают LLM, которая будет по внутренним требованиям формализовать задачи вместо аналитиков. Техническое задание на внедрение сложной системы на 300 страниц она не напишет, но типовые задачи, на которые уходит 1–2 часа, ей можно будет доверить.
Другой пример — бот, который подключён к Jira и может выполнить задачу, которую поставили по определённой форме. По сути, это исполнительный джун, который не думает, но быстро делает однотипные вещи.
Какие задачи аналитики уже спокойно перекладывают на ИИ
У системного аналитика есть два типа работы.
Сложные задачи по анализу и проектированию, общение с заказчиками.
Monkey job — рутинная работа по созданию артефактов: диаграмм, спецификаций, документации.
Со второй группой задач ИИ справляется, но до уровня джуна ему пока далеко. Человек понимает причинно-следственные связи и со временем начинает задавать правильные вопросы. ИИ же лишь воспроизводит шаблоны. Если дать ему подробные инструкции, он может сделать аккуратную диаграмму или спецификацию, но не заметит, что нарушены границы ответственности сервисов.

Павел Бондаренко
Системный архитектор, преподаватель на курсах «Системный и бизнес-аналитик» и «Системный аналитик PRO» в Нетологии
По моей оценке, ИИ может сэкономить 20–30% рабочего времени. Правда, недоверие к ИИ всё ещё велико, поскольку инструмент новый. Я не вижу тренда, чтобы все бежали и делегировали всю работу нейросетям.
Прежде чем вы воспользуетесь нашими советами и промптами, убедитесь, что данными, которые будет обрабатывать модель, безопасно делиться. В идеале работодатель должен развернуть модель внутри контура организации, чтобы уберечь данные от утечки. Но даже в этом случае информацию лучше шифровать, а иногда и вовсе не загружать её в модель. Например, вместо реальных названий объектов и классов можно подставлять шаблонные. А вот различные ключи и бизнес-правила ни в каком виде не стоит включать в запросы.
Диаграммы и схемы
Модели пока плохо генерируют сложные изображения с текстом, поэтому на запрос «нарисуй мне sequence-диаграмму», вы получите в лучшем случае красивую бессмыслицу.
Правильный путь лежит через парадигму «документация как код» (docs-as-code). Вместо того чтобы просить картинку, мы просим ИИ написать код для этой картинки на PlantUML или Mermaid. Это текстовый файл, который легко версионировать в Git, ревьюить и хранить рядом с кодом проекта.
Не пытайтесь скормить ИИ всего слона целиком. Действуйте поэтапно:
Сначала — текстовое описание. Заставьте модель по шагам разложить процесс, который вы хотите визуализировать.
Потом — генерация кода. Попросите модель превратить его в код на синтаксисе PlantUML или Mermaid.
В итоге ИИ берёт на себя самую нудную часть с отрисовкой, но при этом подсвечивает риски процесса. Логикой и смыслами по-прежнему управляет аналитик. За 15–20 минут и несколько итераций будет готова черновая версия диаграммы.
Пример промпта:
Ты — системный аналитик, который готовит BPMN для сложного бизнес-процесса.
Опиши процесс текстом, шаг за шагом, но с обязательным указанием:
— где возникает ожидание (таймеры, асинхронность);
— где возможен ручной ввод или человеческая ошибка;
— где процесс может застрять.После того как модель пришлёт описание, отправляем вторую часть промпта:
Предложи BPMN-структуру (пулы, дорожки, события, шлюзы).
Отметь места, где BPMN не решает проблему, а только визуализирует её.Когда модель закончит с текстовым описанием, переходим к коду — оправляем ей финальную часть промпта:
Теперь сгенерируй BPMN в формате PlantUML/Mermaid.Как видите, ИИ здесь — не творец, а исполнитель. Он экономит ваше время на рутине, но думать за вас не будет. И это хорошо.

Бонус — ещё несколько промптов для описания процессов.
Какой объект создаём | Промпт и в чём его польза |
ERD (Entity-Relationship) диаграмма | Ты — аналитик, который проектирует модель данных. ИИ перестаёт механически рисовать таблицы и начинает работать с логикой домена. |
Диаграмма классов | Ты – системный аналитик. С помощью промпта помогаем отличить модель предметки от модели реализации и вскрываем типичную ошибку ERD ≈ class diagram. |
Use Case | Опиши Use Case не с точки зрения как должно быть, а с точки зрения: Промпт помогает выйти за рамки основного сценария. ИИ начинает работать как злой ревьюер, а не как оптимистичный стажёр. |
Sequence-диаграмма | Опиши последовательность взаимодействий между системами, но: Промпт отсеивает красивые, но бессмысленные sequence-диаграммы. |
OpenAPI и прочие спецификации
Спецификации — это структурированный код. А с кодом нейросети работают неплохо. Им не нужно объяснять, что такое schema, properties или enum. Они знают синтаксис OpenAPI 3.0 и справляются с созданием Swagger-спецификаций лучше, чем с диаграммами.
В итоге задача смещается с роли писателя YAML на роль постановщика ТЗ.
Рабочий процесс выглядит так:
Опишите сущность и методы. Чётко сформулируйте, что вам нужно. Например: «Мне нужен эндпоинт/users с полным CRUD. GET-запрос должен поддерживать пагинацию (offset, limit) и фильтрацию по статусу (active, blocked). POST-запрос должен валидировать email».
Опишите модель данных. Укажите поля, их типы и ограничения. Например: id (integer, readOnly), e-mail (string, format: e-mail), status (string, enum: [active, blocked, deleted]).
Сформулируйте промпт. Соберите всё это в один запрос.
Пример промпта:
Сгенерируй спецификацию OpenAPI 3.0 в формате YAML для управления пользователями.
Эндпоинт: /users
Методы:
— GET /users: получение списка пользователей с пагинацией (offset, limit) и фильтром по status.
— POST /users: создание нового пользователя.
— GET /users/{id}: получение пользователя по ID.
— PUT /users/{id}: обновление данных пользователя.
— DELETE /users/{id}: удаление пользователя (смена статуса на deleted).
Модель User:
— id: integer, readOnly
— username: string
— e-mail: string, format: e-mail
— status: string, enum: [active, blocked, deleted], default: active
Требования:
— Все успешные ответы должны возвращать 200 OK, кроме создания (201 Created) и удаления (204 No Content).
— При ошибке валидации возвращать 400 Bad Request.
— При отсутствии пользователя возвращать 404 Not Found.
Павел Бондаренко
Системный архитектор, преподаватель на курсах «Системный и бизнес-аналитик» и «Системный аналитик PRO» в Нетологии
В результате вы получаете почти готовый файл. Да, в нём могут быть мелкие неточности. Но исправлять готовое — удобнее, чем начинать с нуля. Вы больше не тратите время на отслеживание отступов в спецификации, а проверяете, что логика методов и моделей соответствует бизнес-требованиям. Это и есть наша основная работа.
SQL-запросы: личный DBA по требованию
Многие системные аналитики не пишут SQL-запросы каждый день. А если не делать запросы часто, быстро забывается даже базовый синтаксис. В итоге задача, которая должна занимать пять минут, превращается в получасовое путешествие по Stack Overflow в попытках вспомнить, как правильно написать JOIN с тремя условиями.
SQL — это формальный язык с чёткими правилами. А нейросети справляются с переводом с естественного языка на формальный. Главное — дать им качественное ТЗ:
Опишите схему данных. Укажите, какие у вас есть таблицы и какие в них ключевые поля. Например, «Есть таблицы users(id, name, city) и orders(id, user_id, amount)».
Сформулируйте цель. Чётко опишите, какой результат вам нужен. Например, «Выведи пользователей с тремя и более заказами и посчитай общую сумму их заказов».
Добавьте детали. Укажите условия сортировки или группировки. Например, «Отсортируй по убыванию общей суммы».
Пример промпта:
Напиши SQL-запрос.
Схема:
— Таблица users с полями id, name, city.
— Таблица orders с полями id, user_id, purchase
Задача: вывести имена пользователей, у которых 3 или более заказов. Для каждого такого пользователя также вывести общую сумму всех его заказов. Отсортировать результат по убыванию общей суммы.В ответ вы, скорее всего, получите примерно такой запрос:
SELECT
u.name,
COUNT(o.id) AS order_count,
SUM(o.amount) AS total_amount
FROM
users u
JOIN
orders o ON u.id = o.user_id
GROUP BY
u.id, u.name
HAVING
COUNT(o.id) >= 3
ORDER BY
total_amount DESC;Ценность здесь не только в экономии времени на написание кода. Барьер для проверки гипотезы о данных практически исчезает. Вы можете получить ответ на свой вопрос, не отвлекая разработчиков и не погружаясь в дебри синтаксиса, который забудете через неделю.
Разбор кода, когда разработчик занят
Представьте, что вы работаете с легаси-системой, документация устарела или отсутствует, а единственный разработчик, который помнит, как это работает, — в отпуске. Перед вами — кусок кода, и он — единственный источник правды.
Раньше это означало часы медитации над чужим синтаксисом и попытки угадать, что происходит в каждой ветке if-else. Теперь у вас есть альтернатива. ИИ здесь выступает в роли переводчика с программистского на человеческий. Вы можете просто скормить ему фрагмент кода и попросить объяснить, что он делает. Ваша задача — провести полноценный допрос кода.
Пример промпта:
Ты — опытный Java-разработчик. Объясни мне, системному аналитику, что по шагам делает этот фрагмент кода:
Какова основная цель этого метода?
Какие данные он принимает на вход и что возвращает на выходе?
Опиши логику по шагам, особенно условия ветвления.
Укажи на потенциальные места, где могут возникнуть ошибки или исключения (например, NullPointerException).
[сюда вставляете ваш фрагмент кода]
Павел Бондаренко
Системный архитектор, преподаватель на курсах «Системный и бизнес-аналитик» и «Системный аналитик PRO» в Нетологии
ИИ объяснит, что делает код, но не зачем он это делает с точки зрения бизнеса. Он покажет вам механику: «Здесь мы берём пользователя из базы и проверяем его статус», — но не ответит, почему бизнес-процесс требует именно такой проверки. Это не отменяет необходимости понимать бизнес-логику, но избавляет от мучительного этапа расшифровки синтаксиса. Вы приходите к разработчику уже не с вопросом «Что тут написано?», а с вопросом «Почему мы используем именно такой алгоритм проверки статуса?
Подготовка к интервью
Представьте: в понедельник вы выходите на новый проект в сфере, скажем, лизинга сельхозтехники. А во вторник у вас первая встреча с заказчиком. Раньше это означало ночь в обнимку с Google в попытках отличить сублизинг от возвратного лизинга. ИИ здесь выступает как симулятор эксперта в предметной области. Вы описываете ему контекст проекта, и он помогает вам составить вопросы для интервью.
Пример промпта:
Ты — системный аналитик перед первой встречей с заказчиком из [добавьте название нужной сферы].
Сформулируй вопросы, которые:
— выявляют скрытые ограничения;
— показывают, где бизнес сам себе противоречит;
— вскрывают неозвученные ожидания.
Исключи вопросы вида «Что вы хотите» и «Какие требования».Примеры вопросов, которые ИИ может предложить:
В каком случае вы считаете проект проваленным, даже если он формально запущен?
Какие решения сейчас принимаются на глаз, потому что системе не доверяют?
Что нельзя автоматизировать ни при каких условиях и почему?
Работа с документацией: пересказ основных мыслей, ключевые тезисы, разработка черновиков
Есть проекты, где главная боль — не код, а документация. Это ГОСТы, отчёты по ПМИ, многостраничные ТЗ и приказы на 300 страниц, написанные языком, на котором люди не разговаривают. Здесь ИИ поможет:
1. Сгенерировать черновик. Представьте, что вам нужно написать 80-страничный отчёт по ГОСТу. Структура жёстко задана, а содержание берётся из технического задания. Это работа для ИИ. Вы даёте ему на вход шаблон документа и ваше ТЗ, а на выходе получаете готовую рыбу.

Дарья Татькова
Fullstack-аналитик со специализацией в финтехе, разрабатывала фронт-системы в СК Росгосстрах и СОГАЗ. Ex-ВТБ, Ex-Сбер, преподаватель и автор курсов по направлению системной аналитики и 1С-аналитики в Нетологии
У нас большие требования к документации — госстандарты, шаблоны, безумное количество бумажек. ИИ позволяет не писать всё это с нуля. Конечно, полученный черновик потребует вычитки и редактуры. Но редактировать готовый каркас несравнимо проще, чем создавать его с чистого листа.
Пример промпта:
Ты — технический писатель.
На основе этого ТЗ [текст или ссылка] и этого шаблона отчёта по ГОСТу [текст или ссылка], создай черновик документа, заполнив все разделы согласно ТЗ.2. Саммаризация. Обратная задача — ужать огромный документ, не потеряв сути. Например, 30 страниц с требованиями к разработке сайта превратить в одну. Здесь ИИ экономит от нескольких часов до целого рабочего дня. Вы получаете выжимку, с которой можно идти к команде или руководству.
3. Анализ и поиск. Если вам приходилось читать федеральный закон или сложный внутренний регламент, вы знаете, какое чувство вызывает эта задача. ИИ может прочитать 300 страниц текста, найти все упоминания нужной вам темы и представить их в виде краткого резюме.
Пример промпта:
Проанализируй текст ФЗ-152.
Найди все положения, которые касаются хранения и обработки биометрических данных.
Сделай краткое резюме в виде списка из 10 ключевых тезисов.Вайб-кодинг: закрыть мелкие боли команды без разработчиков
В каждой команде есть набор мелких, рутинных задач, до которых не доходят руки. Например, проверить сроки SSL-сертификатов или распарсить CSV-файл от смежников. Задачи слишком малы, чтобы ставить их в спринт разработчику, но отнимают время, если делать их вручную. Выход — описать задачу ИИ и попросить его написать код.

Дарья Татькова
Fullstack-аналитик со специализацией в финтехе, разрабатывала фронт-системы в СК Росгосстрах и СОГАЗ. Ex-ВТБ, Ex-Сбер, преподаватель и автор курсов по направлению системной аналитики и 1С-аналитики в Нетологии
Я разрабатывала только на 1С, SQL знаю, Python базово, но если нужно быстро написать скрипт, буду сидеть и плакать. С помощью ИИ за два часа решила проблему, которая мучила команду несколько месяцев — автоматизировала контроль за продлением сертификатов доступа. Описала ИИ задачу, и он сгенерировал простейший скрипт, который помогает отслеживать сроки и рассылать уведомления.
Куда ИИ пока не добрался: задачи, где всё ещё нужен человек
ИИ справляется с формализованными задачами, где есть чёткие правила и структура. Но как только мы выходим на территорию неопределённости, человеческого фактора и скрытых смыслов, его эффективность резко падает. Есть как минимум три области, где аналитик незаменим.
Перевод с языка бизнеса на язык системы
Это главная и самая ценная функция аналитика. Пока у ИИ не хватит скиллов, чтобы из неструктурированного потока сознания заказчика выделить то, что ему действительно нужно.
Если заказчик попросит добавить большую красную кнопку, ИИ, скорее всего, начнёт проектировать интерфейс с этой кнопкой. Аналитик же начнёт выяснять, какую боль эта кнопка должна лечить.

Проектирование на уровне бизнес-задач
Такие практики, как Event Storming, или проектирование архитектуры на уровне бизнес-задач — это территория, где важен контекст. Здесь нужно не просто сгенерировать схему, а в живом диалоге с командой и бизнесом определить:
границы систем и микросервисов;
ключевые события в домене;
скрытые бизнес-правила;
неизбежные архитектурные компромиссы.
Это творческий, исследовательский процесс, который требует системного мышления и умения проводить сложные обсуждения. ИИ может помочь с отдельными фрагментами, но собрать из них цельную, работающую концепцию он пока не в состоянии.
Решение нетипичных задач

Павел Бондаренко
Системный архитектор, преподаватель на курсах «Системный и бизнес-аналитик» и «Системный аналитик PRO» в Нетологии
Моя основная работа сейчас состоит из нетривиальных задач, и очень мало что можно делегировать искусственному интеллекту. Например, он точно не сможет спроектировать архитектурное решение, как архитектор или аналитик, и тем более провалидировать его. Кроме того, ИИ не разберётся в особенностях архитектурного кластера продукта, регламентов информационной безопасности, регламентов комплаенс-контроля при проектировании архитектурных решений.
Советы начинающим системным аналитикам: как подружиться с ИИ и не потерять себя
Новое поколение аналитиков столкнулось с парадоксом из «Алисы в стране чудес»: нужно бежать в два раза быстрее, чтобы оставаться на месте. Пять лет назад было достаточно осваивать базу и набивать руку. Теперь нужно делать задачи вручную и тут же учиться это автоматизировать. Так что ИИ скорее усложняет вход в профессию.
Почему не получится проскочить этап освоения базы
Во-первых, ИИ ошибается — об этом пишут разработчики моделей. Но часто ошибки или выдуманные факты видно без дисклеймера. Чтобы ИИ оставался полезным инструментом, его должны использовать люди, способные отличить хороший результат от плохого. В конечном счёте, лучший системный аналитик — это не тот, кто быстрее всех рисует диаграммы, а тот, кто понимает, какие диаграммы нужны и зачем. ИИ может стать ускорителем, но только в руках того, кто и без него знает, что делает.

Павел Бондаренко
Системный архитектор, преподаватель на курсах «Системный и бизнес-аналитик» и «Системный аналитик PRO» в Нетологии
Без прочной базы вы просто не заметите ошибки. Если вы никогда сами не строили диаграмму последовательности, то не поймёте, почему вариант, сгенерированный ИИ, — гарантированный мусор.
Во-вторых, неквалифицированные пользователи ухудшают сами модели. Если, например, писать код с помощью нейросетей будут люди, которые не умеют писать код, они обучат нейросеть плохому коду. С каждой итерацией его качество будет только снижаться. Это касается и артефактов аналитика.
Как автоматизировать работу с пользой
Вот несколько правил, которые помогут выстроить этот процесс.
Разбейте задачу на этапы. Не пытайтесь решить сложную задачу одним запросом. Сначала попросите ИИ помочь с текстовым описанием. Уточните его. Затем на основе этого описания попросите сгенерировать диаграмму.
Проверяйте генерации. Если не уверены в результате, вернитесь к основам и собственным знаниям. Рабочая стратегия выглядит так:
Делаете задачу вручную → автоматизируете эту же задачу через ИИ → сравниваете результат, смотрите, где ИИ ошибся.
Если вы не можете проверить результат ИИ, то пока не стоит делегировать ему задачи.
Сделайте ИИ частью рутины. Выработайте привычку при получении новой задачи задавать себе вопрос: «Может ли здесь помочь нейросеть?». Если да — пробуйте. Если нет или задача слишком ответственная — делайте руками.
Используйте разные модели. Например, платная версия ChatGPT кажется универсальной, но, стиль текстов модели слишком узнаваемый. Для таких задач больше подходит Gemini — его тексты человечнее. Ещё один повод использовать разные модели — отлавливать ошибки. Если стравливать модели между собой, они начинают друг друга критиковать и тем самым улучшают результат.
7 способов вычислить галлюцинации — главную проблему ИИ
Часто модели придумывать ответ вместо того, чтобы признать некомпетентность в вопросе. На первый взгляд ответ кажется правдоподобным, а по факту это ошибки в логике, которые могут дорого обойтись компании.
Просьба объяснить логику. Самый простой способ вывести модель на чистую воду — заставить объяснить собственную логику. Например, после любой генерации требований, диаграммы или архитектуры полезно спросить:
Объясни, почему ты выбрал именно такое решение, а не альтернативное?
Какие допущения ты сделал?Если в ответе появляются фразы уровня «обычно принято», «часто используется», «в большинстве систем», но нет привязки к вашему контексту, — это почти гарантированная галлюцинация.
Метод исключений. Галлюцинации почти всегда описывают идеальный мир, где всё работает как задумано. Попробуйте спросить:
В каких случаях это решение не сработает?
Где оно сломается первым?
Какие граничные условия ты не учёл?Если ИИ отвечает общими словами: «при высокой нагрузке», «при ошибках данных», — и не может назвать конкретные точки отказа, значит, он не понимает решения, а имитирует его.
Смена роли ИИ на критика самого себя. Например, попросить модель проверить результат генерации из позиции другого системного аналитика, бизнес-заказчика или системного архитектора. Результаты будут отличаться: заказчик будет придираться к недостаточно понятным формулировкам, а архитектор будет уходить глубоко в технические детали.
Пример промпта:
Представь, что ты — опытный системный аналитик, который пришёл на ревью этого решения.
Найди логические дыры, спорные допущения и потенциальные ошибки.Галлюцинации часто сыпятся именно на этом этапе. ИИ начинает противоречить сам себе или внезапно находить проблемы, которые не замечал пять секунд назад.
Альтернатива с жёсткими ограничениями. Если первоначальное решение было галлюцинацией по шаблону, ИИ либо не сможет предложить альтернативу, либо предложит ещё один шаблон, не связанный с контекстом.
Пример промпта:
А теперь предложи альтернативное решение, но:
— без микросервисов;
— без асинхронных очередей;
— без кеша.
Что ты будешь делать тогда?Метод для выявления выдуманных бизнес-правил и регуляторки. Здесь ИИ особенно опасен, потому что звучит уверенно. Проверяем вопросами:
На какие источники или нормы ты опираешься, делая этот вывод?
Это универсальное правило или предположение?Если в ответе нет ссылок, размытые формулировки («обычно», «как правило», «чаще всего»), это снова галлюцинация. В системном анализе такие ответы недопустимы без уточнений.
Вопросы про ответственность для выявления галлюцинаций в диаграммах и архитектуре. Они особенно коварны, потому что визуально всё выглядит правильно.
Пример промпта:
Если в ответе нет ссылок, размытые формулировки («обычно», «как правило», «чаще всего»), это снова галлюцинация. В системном анализе такие ответы недопустимы без уточнений.
Вопросы про ответственность для выявления галлюцинаций в диаграммах и архитектуре. Они особенно коварны, потому что визуально всё выглядит правильно.
Пример промпта:
Кто является источником истины для этих данных?
В какой момент и где принимается бизнес-решение?
Что произойдёт, если этот сервис недоступен?Если ИИ не может чётко ответить, кто отвечает и за что, то диаграмма почти наверняка декоративная.
Для требований и use case полезны вопросы:
Какое поведение системы ты считаешь недопустимым?
Где система должна явно отказать пользователю?Галлюцинации любят happy path и плохо работают с запретами и отказами. Если ответы размытые — сценарии не продуманы.
Проверка слишком красивой генерации. Здесь можно прямо спросить:
Какие части этого решения выглядят наиболее подозрительно гладкими?
Где в реальной жизни здесь обычно появляются костыли?Если ИИ не может назвать ни одного грязного места, он живёт в идеальном мире.
Что говорят исследования и как это повлияет на будущее
ИИ никуда не денется, и рынок это уже принял. Исследования и кейсы показывают: компании действительно используют ИИ, чтобы экономить на людях, но без вменяемой стратегии и человеческого контура такие эксперименты очень быстро бьют по качеству, продукту и бизнес‑показателям.
Да, бизнес правда хочет обложить людей нейросетями

Дарья Татькова
Fullstack-аналитик со специализацией в финтехе, разрабатывала фронт-системы в СК Росгосстрах и СОГАЗ. Ex-ВТБ, Ex-Сбер, преподаватель и автор курсов по направлению системной аналитики и 1С-аналитики в Нетологии
Многие хотят сэкономить и вместо двух синьоров, пятерых мидлов и пары джунов взять одного синьора, одного мидла и обложить их нейронками. Я периодически хожу на собеседования и с недавних пор всё чаще слышу о планах компаний нанимать людей, которые умеют делегировать задачи ИИ.
По данным Tech.co, 14% владельцев компаний уже признали, что ИИ существенно убрал необходимость в отдельных ролях, а 85% бизнесов так или иначе используют ИИ‑инструменты, в том числе и ради экономии на штате.
Та же логика обвязки команд ИИ проявляется в ожиданиях к сотрудникам: в опросах EY большинство работодателей говорит, что умение пользоваться ИИ становится важным критерием найма, а цифровые ассистенты встраиваются в стандартный стек аналитика и разработчика. То, о чём говорит Дарья — нанимать людей, которые умеют делегировать задачи ИИ — по сути уже быстро превращается из хотелки продвинутых компаний в рыночный стандарт требований.
Некоторые компании сокращают людей ради ИИ, но не все от этого выигрывают
Финтех‑компания Klarna сократила около четверти штата, заявив, что чат‑бот с нейросетью выполняет работу сотен сотрудников и позволяет обрабатывать миллионы обращений при меньших затратах. Такие кейсы попадают в медиа и в презентации топ‑менеджеров, укрепляя иллюзию, что [один сильный специалист + ИИ] может безболезненно заменить толстый слой операционных ролей, а дальше захватить часть аналитики и разработки.
Исследование Tech.co показывает, что бизнес видит рост продуктивности от технологий: 88% топ‑менеджеров отмечают, что за прошлый год технологии улучшили эффективность, а в ряде компаний действительно удаётся срезать расходы на персонал без немедленного коллапса процессов.
На длинной дистанции картинка становится менее глянцевой. Устаревшие роли возвращаются как критически важные, но уже с дополнительными затратами на рекрутинг и восстановление доверия. С Klarna случилось ровно это: после волны восторгов компания столкнулась с ростом жалоб, падением доверия и теперь вынуждена снова нанимать людей, чтобы вернуть клиентам человеческую эмпатию и гибкость.
Согласно исследованию Forrester, 55% работодателей, уволивших сотрудников из-за внедрения ИИ, теперь сожалеют об этом решении. Tech.co тоже фиксирует парадокс на уровне статистики: 78% компаний, сокративших людей из‑за автоматизации, планируют снова нанимать.
Проблема — в неадекватной оценке выгоды от ИИ и в целом его роли
Исследования подчёркивают: там, где ИИ пытаются рассматривать как полноценного бойца, без выделенного специалиста, который контролирует его работу, всё чаще возникают провалы в качестве, риски для данных и необходимость дорого откатываться назад.
Модель «сначала сократим людей, потом разберёмся» создаёт иллюзию высокого ROI от ИИ: в отчётах снижаются затраты на персонал, ИИ берёт на себя типовые запросы, метрики операционной эффективности растут. Но со временем падает качество решений, растут ошибки в сложных кейсах, выгорают и уходят ключевые специалисты и активные клиенты. Так что через 6–12 месяцев формальная экономия на ФОТ частично или полностью съедается провалами в выручке и незапланированными операционными расходами.

Павел Бондаренко
Системный архитектор, преподаватель на курсах «Системный и бизнес-аналитик» и «Системный аналитик PRO» в Нетологии
Я думаю, что это вопрос месяцев, а не лет, когда в требованиях к вакансиям будет уже прописано умение использовать основные нейросети. Но хотелось бы, чтобы тренд на ИИ адекватно понимали не только системные аналитики, но те, кто управляет командами. ИИ — это не полноценный боец, а дополнительная функция. Даже если вы запустили агента, который выполняет типовые задачи в Jira, нужен специалист, который будет контролировать его работу. Эту мысль важно учесть топ-менеджерам или руководителям организаций, которые сейчас согласовывают на следующий год количество штатных единиц разработчиков, тестировщиков, аналитиков.
EY оценивает, что компании недополучают до 40% потенциального прироста продуктивности от ИИ из‑за того, что не вкладываются в людей: обучение, культуру, процессы и систему вознаграждений. Лишь 12% сотрудников, по данным EY, получают достаточное обучение по ИИ. При этом те, кто проходят более 81 часа обучения в год, выигрывают до 14 часов продуктивности в неделю, но становятся на 55% более склонны уйти, так как их ИИ‑компетенции высоко востребованы на рынке.
Что всё это значит для системных аналитиков
Простая «ручная» аналитика без владения ИИ‑инструментами действительно будет дешеветь и заменяться. Но на уровне профессии аналитика — это смена профиля от исполнителя регламентных задач к владельцу контура «задача → ИИ → проверка → интеграция в систему». Здесь отговорка «Мы не успели, потому что было много рутины» перестаёт работать. Если в компании приняты ИИ‑инструменты, руководитель вправе спросить, почему они не используются для снятия части нагрузки.
Исследования и кейсы показывают, что устойчивое конкурентное преимущество появляется не у тех, кто поменял людей на ИИ, а у тех, кто умеет проектировать и управлять гибридными системами [люди + ИИ] так, чтобы выигрывали и бизнес‑метрики, и качество решений. В этом контексте бизнес- и системные аналитики — одни из тех сотрудников, которые объясняют бизнесу, где ИИ действительно можно безопасно встроить в процессы, а где попытка массово заменить людей моделями закончится тем, что через год придётся дорого откупаться от последствий и снова нанимать.
*Мнение экспертов и редакции блога может не совпадать.
Чтобы расти, нужно выйти из привычной зоны и сделать шаг к переменам. Можно изучить новое, начав с бесплатных занятий:
курса-симулятора «Системный аналитик: первые шаги к профессии»;
мастер-класса «Как нейросети помогают оптимизировать бизнес-процессы»;
воркшопа «1C-аналитик: погружение в профессию на практике»;
курса-симулятора «Бизнес-аналитик: первые шаги в профессии»;
вводного курс магистратуры «Прикладной искусственный интеллект».
Или можно стать востребованным сотрудником и открыть открыть бóльшие перспективы в карьере с профессиональным обучением:
на программе «Системный аналитик PRO»;
на курсе «Нейросети для анализа данных»;
на практическом курсе «Вайб-кодинг | AI Программирование»;
на программе профессиональной переподготовки «ИИ-разработчик: от API до агентов» совместно с МТУСИ;
на курсе «Продвинутый SQL».
