На слух «ИИ-инженер» — человек, который обучает нейросети, но почти всегда это неверно. Большие модели обучают исследовательские лаборатории, и с нуля туда не попасть: нужны математическая подготовка и годы научной работы по профилю.
Работа, под которую сегодня приходят заказы, устроена приземлённее: взять готовую модель и встроить её в чужой рабочий процесс так, чтобы процесс стал быстрее или дешевле. Ниже пять типов задач, из которых эта работа состоит, и то, что придётся освоить, чтобы за них браться.
Подключить модель к продукту через API
Сам вызов модели — несколько строк: отправили текст, получили текст. Этому учатся за вечер. Платят за то, что приходится строить вокруг этого вызова.
Модель отвечает свободным текстом, а продукту нужен предсказуемый формат: три поля, из которых два обязательные. Значит, надо попросить ответ структурой, проверить, что пришло именно оно, и решить, что делать, когда пришло что-то другое. Сервис модели может ответить ошибкой, подвиснуть или упереться в ограничение по частоте запросов, поэтому нужны повторы, тайм-ауты и понятное поведение продукта в тот момент, когда ИИ недоступен. Каждый вызов стоит денег и считается по объёму текста, поэтому кто-то должен следить, чтобы в модель не уезжала вся многолетняя переписка клиента.
Есть и скучная часть. Ключи не хранятся в коде, ответы пишутся в журнал, у пользователя есть кнопка «ответ неверный», а у команды есть способ найти этот ответ и посмотреть, что именно уходило в модель.
Частая поломка на первом продукте выглядит глупо: модель попросили вернуть JSON, она вернула JSON, обёрнутый в тройные кавычки с подписью «вот ваш ответ», и разбор упал. В боевом коде вокруг такого ответа обычно стоит очистка и вторая попытка с более жёсткой инструкцией.
Сделать поиск по документам компании
Ещё один частый запрос после «подключите нам чат»: чтобы система отвечала по внутренним регламентам и инструкциям, договорам, накопленной базе вопросов поддержки.
Схема почти везде одна. Документы разбирают на фрагменты, фрагменты кладут в хранилище с поиском по смыслу, на вопрос пользователя достают несколько подходящих кусков и отдают их модели вместе с вопросом. Модель отвечает по этим кускам и показывает, откуда взяла. Механику мы подробно разобрали в статье про RAG.
Инженерная часть тут почти вся в данных. У заказчика они лежат в почте, в выгрузках и в файлах, которые давно никто не открывал. Изрядная доля ответов на вопросы сотрудников вообще нигде не записана и живёт в голове у коллеги из соседнего отдела. К этому добавляются права доступа и отдельная задача: научить систему прямо говорить «в документах этого нет» вместо того, чтобы уверенно сочинять.
По нашему опыту, подготовка документов на таких задачах съедает больше времени, чем вся остальная сборка.
Разобрать входящий поток обращений
У любой компании, которая общается с людьми, есть поток текста: заявки с сайта, письма, сообщения в мессенджерах, отзывы на маркетплейсах, резюме. Раньше его сортировали правилами по ключевым словам, и правила постоянно ломались на живых формулировках: человек пишет «не пускает в личный кабинет», в правиле стоит «авторизация», и обращение уходит не туда.
С сортировкой модель справляется, и задача инженера начинается сразу после. Нужно решить, куда складывать разобранное и какие поля вытаскивать из текста. Качество придётся измерить: взять несколько сотен реальных обращений, разметить их руками, прогнать через систему и посмотреть, где она путается. Потом ставится порог уверенности — выше него обращение уходит дальше автоматически, ниже попадает к оператору, и оператор видит, почему система засомневалась. Отдельно решают, что делать с обращениями, которые не подходят ни в одну категорию, потому что такие будут всегда.
Заказчик часто начинает разговор словами «чтобы вообще без людей». Заканчивается это тем же порогом, только позже и с цифрами на руках.
Снять с людей ручную рутину
Самый недооценённый пласт задач и самый доходчивый для заказчика: он своими глазами видит, сколько часов в неделю сотрудник тратит на перекладывание данных.
Типичное: собрать еженедельный отчёт из выгрузок трёх систем; превратить часовую запись созвона в список задач с ответственными; разложить сканы документов по папкам и вытащить из них реквизиты; собрать карточки товара из фотографий и прайса; проверить сотню описаний на соответствие требованиям площадки.
Заметной части такой рутины модель вообще не нужна, там хватает обычного скрипта и расписания. Инженер, который говорит об этом заказчику вслух, теряет часть чека и получает заказчика надолго. Модель нужна там, где вход неструктурированный: живой текст, речь, разнородные документы.
Готовые конструкторы вроде n8n закрывают часть таких задач почти без кода, и знать их полезно. Упираются они одинаково: как только появляется нестандартная логика или заметная нагрузка, сценарий переписывают на обычный сервис.
Связать это с CRM и остальными сервисами
Отдельно стоящий продукт мало кому нужен. Нужно, чтобы результат приезжал туда, где люди уже работают: в CRM, в таблицу, в мессенджер, в систему учёта.
Со стороны это выглядит как «просто отправить данные». На практике интеграции — место, где живут самые неприятные баги. Внешний сервис присылает одно и то же событие дважды, и в CRM появляется дубль сделки. Поля, которые заказчик называет обязательными, во многих карточках пустые. У чужого API есть ограничение на число запросов, и при разовой загрузке истории интеграция молча отваливается на середине. Доступы выдают не сразу, и до этого приходится работать на придуманных данных.
Поэтому в такой работе быстро появляются скучные привычки: помечать каждое событие идентификатором и не обрабатывать его дважды, вести журнал всего, что ушло наружу, и следить, чтобы повторный запуск не портил данные.
Чем это отличается от промпт-инженера и ML-инженера
Промпт-инженер как отдельная должность встречается всё реже, и это нормально: формулировать задачу модели теперь умеют все, кто с ней работает. Навык остался, а отдельных ставок под него почти нет.
ML-инженер и исследователь работают с самими моделями: обучают, дообучают, собирают обучающие выборки, меряют метрики качества. Там нужна математическая база, и путь туда обычно идёт через профильное образование.
Инженер по системам с ИИ берёт готовую модель как деталь и собирает вокруг неё работающий сервис. Ближайшая родня по обязанностям — backend-разработчик, который дополнительно умеет обращаться с моделями и понимает, где они врут.
С названиями в вакансиях путаница: одну и ту же работу пишут как AI Engineer, LLM Engineer, ИИ-разработчик и просто Python-разработчик. Поэтому смотри на блок обязанностей: по заголовку вакансии работу не понять.
Что придётся освоить
Список выглядит длинным, только каждый пункт берётся на уровне рабочего минимума: ровно столько, сколько нужно, чтобы сервис работал.
- Python на уровне «читаю и правлю чужой код». Писать с нуля всё подряд уже не нужно. Разбираться в том, что написала модель, придётся каждый день.
- HTTP и API. Запрос, ответ, коды ошибок, ключи, заголовки, ограничения по частоте вызовов.
- Базы данных. SQL на уровне выборок и соединений плюс понимание, где хранить векторы для поиска по смыслу.
- Git. Ветки, история, разбор конфликтов. Без этого не пустят ни в одну команду.
- Деплой. Поднять сервис на сервере, завернуть в Docker, привязать домен, настроить журналы и уведомление о падении.
- Поведение моделей. Структурированный вывод, вызов внешних инструментов, поиск по документам, проверка качества ответов.
- Разговор с заказчиком. Умение превратить «сделайте нам ИИ» в короткий список задач, под которым обе стороны готовы подписаться.
Ни один пункт не требует многолетней подготовки. Дольше всего осваивается отладка: сервис отвечает неправильно, а в журналах всё зелёное и код формально верен.
Кому это подходит
Лучше всего заходит людям, которые до этого руками разгребали процессы: поддержка, продажи, логистика, бухгалтерия, кадры, аналитика в таблицах. У них уже есть понимание, как устроена работа внутри компании и что в ней болит. Главная ценность в этой профессии — увидеть задачу там, где заказчик её ещё не сформулировал. Это умение приходит из предыдущей работы, и курс его не заменит.
Тяжело будет тем, кто идёт за красивым словом «нейросети» и представляет себе работу как генерацию картинок и текстов. Основное время уходит на чужие данные в плохом состоянии, на выяснение требований и на отладку. Модель здесь — рабочий инструмент, к нему быстро привыкаешь и перестаёшь удивляться.
Отдельно про ожидание, что всё напишет ИИ, а человек будет нажимать кнопку. Это работает ровно до первого живого пользователя. Дальше кто-то должен понимать, что внутри, иначе продукт чинить некому.
С чего начать, если решил пробовать
Самое полезное первое действие — собрать один маленький сквозной продукт и довести его до состояния, когда им пользуется кто-то кроме тебя. Форма или телеграм-бот, вызов модели, запись результата в базу, уведомление в мессенджер, деплой на сервер с доменом.
Такой проект даёт больше, чем россыпь разрозненных экспериментов в блокноте. Ты один раз проходишь путь целиком и находишь все места, где обычно застревают: ключи, окружение, права, тайм-ауты, кодировки.
Потом стоит сделать то же самое ещё дважды, но уже под чужую задачу: своя постановка и чужая дают разный опыт.
Если выбираешь направление, сравни программы треков Quillon: в каждой расписано, что учишь и какие проекты делаешь.