Проверено 4 августа 2026 года.

Как выбрать LLM-интегратора: уроки OpenAI, Claude и AWS

Для внедрения LLM берите не «человека, который умеет писать промпты», а инженера-консультанта, отвечающего за весь цикл: найти бизнес-задачу, собрать прототип, встроить его в данные и системы компании, настроить evals, обеспечить безопасность, выпустить в production и добиться использования сотрудниками. Именно такой профиль повторяется в вакансиях OpenAI, Anthropic — создателя Claude — и Amazon Web Services (AWS).

Коротко: сильный LLM-интегратор сочетает четыре роли: software engineer, solutions architect, product thinker и консультант по изменениям. Вайбкодинг полезен как способ быстро проверить гипотезу. Но скорость генерации кода не заменяет архитектуру, тестирование, наблюдаемость, безопасность и ответственность за бизнес-метрику.

Эта статья для собственников, CEO, CIO/CTO и руководителей продукта, которые выбирают консультанта, подрядчика или внутреннего лидера внедрения. Это не рейтинг агентств и не список открытых вакансий: мы используем требования самих OpenAI, Anthropic и AWS как публичную модель зрелого кандидата.

Содержание

• Кого на самом деле нанимают создатели LLM
• Рамка 6P: шесть зон ответственности
• Можно ли нанять вайбкодера
• Оценочная карта кандидата на 100 баллов
• 12 вопросов на интервью
• Какое тестовое задание дать
• Что зафиксировать в договоре
• Красные флаги
• FAQ
• Конечный профиль кандидата

Кого на самом деле нанимают создатели LLM

Мы проверили девять customer-facing ролей: три в OpenAI, три в Anthropic и три в AWS. Названия различаются — Forward Deployed Engineer, Applied AI Architect, Specialist Solutions Architect, — но рабочий контур почти одинаков.

Компания	Публичные роли	Что человек должен довести до результата
OpenAI	Forward Deployed Engineer, Forward Deployed Software Engineer, AI Deployment Engineer	discovery, scope, full-stack build, production rollout, adoption и измеримый эффект
Anthropic	Applied AI Architect для digital-native, enterprise tech и industries	business discovery, архитектура Claude, прототипы, evals, безопасность и deployment
AWS	GenAI Specialist SA, Applied AI Solutions Architect, Partner Solutions Architect	data readiness, RAG и агенты, интеграции, evals, production readiness и повторяемые шаблоны

В вакансии Forward Deployed Engineer в Лондоне OpenAI прямо объединяет discovery, технический scope, проектирование, разработку и production rollout. Успех роли измеряется не количеством прототипов, а production adoption, влиянием на рабочий процесс и обратной связью на основе evals. Требуются 5+ лет инженерного или deployment-опыта и умение писать production-код на Python, JavaScript или сопоставимом стеке.

Forward Deployed Software Engineer — ещё более инженерная версия. Кандидат встраивается в команду заказчика, делает full-stack-решения, готовит план и для PoC, и для production, пишет код рядом с инженерами клиента. OpenAI просит 7+ лет full-stack-опыта и считает плюсом опыт основателя или раннего инженера, который собирал продукт с нуля.

В AI Deployment Engineer, Large Enterprise акцент смещён к enterprise adoption: сформировать GenAI-roadmap, выбрать ценные use cases и провести их от прототипа до промышленного внедрения. Эта роль показывает, почему одного технаря без навыка разговора с руководством тоже недостаточно.

У Anthropic Applied AI Architect для digital-native-компаний ведёт клиента от technical discovery через evaluation до deployment, проектирует интеграцию Claude и помогает создать framework оценки. Формальный минимум — 5+ лет в customer-facing технических ролях. В анкете есть показательный фильтр: писал ли кандидат за последние 12 месяцев Python или TypeScript и делал ли рабочий LLM-прототип для клиента.

Applied AI Architect, Enterprise Tech и Applied AI Architect, Industries повторяют тот же профиль: enterprise architecture, Python, LLM-инструменты, evals и коммуникация от C-level до инженеров. То есть «презентатор без рук» и «кодер без бизнес-контекста» одинаково неполны.

AWS добавляет слой данных и эксплуатации. Sr. Applied AI Solutions Architect для Amazon Connect оценивает готовность CRM, базы знаний и backend-систем, строит RAG, Lambda/API-интеграции, MCP-серверы и agent-to-agent-процессы, запускает evals по accuracy, latency и customer satisfaction.

GenAI Specialist Solutions Architect для EU North должен давать рекомендации по безопасности, стоимости, производительности, надёжности и операционной эффективности. А Partner Solutions Architect превращает единичные решения в reference architectures, blueprints и повторяемые integration patterns.

Из девяти ролей следует один вывод: LLM-внедрение — это продуктовая и организационная инженерия, а не подключение API.

Рамка 6P: шесть зон ответственности

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

Зона	Что обязан сделать интегратор	Что попросить как доказательство
Problem	найти дорогой и повторяемый бизнес-процесс	карта процесса, baseline и владелец метрики
Prototype	быстро проверить техническую гипотезу	работающий прототип на реальных примерах
Platform	встроить решение в данные и системы	архитектура API, RAG, IAM, логи и отказоустойчивость
Proof	доказать качество и экономику	eval-набор, критерии приёмки, стоимость успешной задачи
Production	выпустить и эксплуатировать	rollout, observability, runbook, rollback и SLA/SLO
People	добиться использования	обучение, изменение процесса, feedback loop и adoption-метрика

1. Problem: начинает с процесса, а не с модели

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

До прототипа должны появиться минимум четыре числа: текущая длительность операции, стоимость выполнения, частота ошибок и объём кейсов. Без baseline невозможно доказать эффект. Подробнее эту последовательность мы разбирали в статье «Внедрение ИИ в бизнес-процессы: с чего начать».

2. Prototype: умеет сам собрать работающую проверку

Интегратор не обязан в одиночку написать всю enterprise-платформу. Но он должен уметь лично собрать узкий PoC на Python или TypeScript, подключить API модели, данные и один реальный инструмент, а затем объяснить каждое архитектурное решение.

В прототипе проверяют не «вау-ответ», а полный путь: входные данные → вызов модели → tool use → валидация → запись результата → обработка ошибки. Если кандидат может показать только чат в конструкторе, вы ещё не проверили интеграционную компетенцию.

3. Platform: понимает данные, безопасность и существующий IT-контур

LLM почти никогда не работает в вакууме. Ей нужны документы, CRM, ERP, права доступа, API и журнал действий. Поэтому кандидат должен обсуждать:

• качество, актуальность и владельцев данных;
• RAG, индексацию и правила обновления базы знаний;
• identity and access management, разделение арендаторов и секреты;
• защиту от prompt injection и опасных tool calls;
• таймауты, повторные попытки, idempotency и graceful degradation;
• логи, трассировку, стоимость и версии модели.

AWS особенно явно проверяет data readiness до запуска агентов. Это важный сигнал для найма: если консультант обещает качество без аудита данных, он продаёт модель, а не систему.

4. Proof: строит evals до масштабирования

Evals — это набор реальных задач с критериями правильного результата. Для поддержки это могут быть точность ответа, доля корректных ссылок на политику, успешность действия в CRM и частота эскалации человеку. Для обработки документов — полнота полей, критические ошибки и время на проверку.

Минимальный пилот должен включать 50–100 реальных кейсов из вашего процесса, в том числе редкие и небезопасные сценарии. Размер — практическая оценка AI рассвет, а не универсальный стандарт. Важно заранее зафиксировать, какой результат считается успешным, иначе команда начнёт выбирать красивые примеры после теста.

Главная экономическая метрика — стоимость успешно завершённой задачи, а не цена миллиона токенов. В неё входят токены, инфраструктура, повторы, ручная проверка, поддержка и стоимость ошибок.

5. Production: умеет выпускать, наблюдать и откатывать

Production начинается там, где есть реальные пользователи, права, инциденты и ответственность. Кандидат должен принести план поэтапного rollout: shadow mode, ограниченная группа, процент трафика, критерии остановки, fallback и rollback.

Попросите показать runbook хотя бы одного прошлого AI-сервиса: как отслеживались качество, latency, расходы, ошибки инструментов и изменение поведения модели. Если после сдачи остаётся только prompt и ссылка на API, эксплуатацию переложили на вас.

6. People: отвечает за adoption, а не только за deploy

Технически исправный агент не создаёт эффект, если сотрудники обходят его или перепроверяют всё вручную. OpenAI прямо использует production adoption и workflow impact как критерии успеха Forward Deployed Engineer.

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

Можно ли нанять вайбкодера

Да — для прототипа с ограниченным риском. Нет — как единственного владельца критичного внедрения, если он не доказал остальные пять зон 6P.

Под вайбкодером здесь понимается человек, который быстро собирает приложение с помощью AI coding tools. Это способ работы, а не профессия и не автоматический минус. OpenAI сама ценит скорость итераций и опыт раннего инженера. Anthropic прямо спрашивает кандидатов о применении AI coding assistants и agentic developer tools.

Разница проходит по ответственности:

Подходит	Опасно
внутренний прототип без чувствительных данных	автономный доступ к платежам, персональным данным или production-изменениям
лендинг, mockup, demo интерфейса	код без review, тестов, логирования и владельца
проверка одного workflow на копии данных	обещание заменить процесс после трёх удачных демо
работа под руководством сильного архитектора	зависимость от одной модели, одного аккаунта и скрытых промптов

Нанимайте не по признаку «пишет код руками или с AI», а по способности объяснить систему, проверить её и нести ответственность после запуска.

Оценочная карта кандидата на 100 баллов

Дайте каждому участнику интервью одну таблицу. Оценивайте только доказательства: артефакт, код, метрику, схему или разбор реального инцидента.

Компетенция	Баллы	Что считается сильным доказательством
Business discovery и приоритизация	20	baseline, unit economics, выбор use case по эффекту и риску
Hands-on engineering	20	production-код, API, Python/TypeScript, базы, тесты
Architecture, data и security	20	RAG/data pipelines, IAM, threat model, интеграции и отказоустойчивость
Evals и измерение результата	15	набор реальных кейсов, автоматическая и экспертная оценка, regression gate
Production delivery	15	CI/CD, observability, rollout, rollback, runbook и оптимизация стоимости
Коммуникация и adoption	10	работа с C-level, инженерами и владельцем процесса, обучение пользователей
Итого	100	рекомендуемый проходной уровень — 75 при отсутствии нуля в любой строке

Порог 75 — Estimated рекомендация AI рассвет, а не отраслевой норматив. Для высокорисковых процессов поднимите порог по architecture/security и production delivery. Кандидат с 95 баллами за продажи и демо, но нулём за evals, не проходит.

12 вопросов на интервью

1. Как вы выберете первый use case? Сильный ответ начинается с объёма, цены ошибки, baseline, доступности данных и владельца процесса.
2. Покажите систему, которую вы довели от PoC до production. Нужны код или схема, сроки, провалы, метрики и текущий статус.
3. Как вы строили eval-набор? Ищите реальные кейсы, edge cases, критерии до теста и регрессионный запуск.
4. Как считали экономический эффект? Ответ должен включать ручной труд, инфраструктуру, проверку и ошибки.
5. Когда RAG не нужен? Зрелый кандидат не добавляет векторную базу автоматически и умеет выбрать поиск, SQL, tools или обычный контекст.
6. Как защищаете агента с доступом к действиям? Ищите least privilege, allowlist, подтверждение опасных операций, аудит и изоляцию.
7. Что произойдёт при недоступности модели или CRM? Нужны timeout, retry policy, очередь, fallback и понятное состояние для пользователя.
8. Как обнаружите ухудшение после смены модели? Версионность, frozen eval set, canary и сравнение метрик.
9. Как ограничите стоимость? Маршрутизация моделей, кэш, компактный контекст, бюджеты, алерты и стоимость успешной задачи.
10. Как передадите решение нашей команде? Репозиторий, документация, IaC, runbook, обучение и отсутствие секретов подрядчика.
11. Расскажите о провальном AI-проекте. Сильный кандидат называет собственные ошибки и изменения процесса.
12. Как измерите adoption через месяц? Нужны активные пользователи, доля целевого потока, время операции, override rate и причины отказа.

Не принимайте общие ответы. После каждого спросите: «Покажите артефакт» или «Какое число изменилось?»

Какое тестовое задание дать

Лучше оплачиваемый короткий пилот, чем бесплатная презентация. Дайте кандидату один узкий процесс, обезличенные данные и 5–10 рабочих дней.

Входные условия

• 20–30 примеров для discovery и ещё закрытый набор для проверки;
• один API или тестовый контур CRM/ERP;
• ограничения по данным, стоимости и времени ответа;
• сотрудник — владелец процесса — для двух рабочих сессий.

Обязательные результаты

1. Одностраничная карта проблемы: baseline, пользователь, риск и целевая метрика.
2. Работающий end-to-end прототип, а не серия скриншотов.
3. Схема архитектуры, поток данных и модель прав доступа.
4. Eval-набор и таблица результатов на закрытых примерах.
5. Оценка полной стоимости и список неизвестных.
6. План production rollout, мониторинга, rollback и передачи команде.
7. Короткий разбор: что не сработало и почему.

Не требуйте бесплатно создавать готовый продукт. Цель теста — проверить способ мышления, инженерную глубину и честность перед неизвестностью.

Что зафиксировать в договоре

Договор должен покупать не «бота», а проверяемые результаты этапов.

• Артефакты принадлежат заказчику: код, prompts, evals, схемы, документация, IaC и логи конфигурации.
• Критерии приёмки определены заранее: качество, latency, стоимость, безопасность и доля успешных задач.
• Есть stop/go gates: discovery, PoC, pilot, production; каждый этап можно остановить без оплаты выдуманного масштаба.
• Нет скрытой зависимости: ключи, аккаунты и инфраструктура оформлены на заказчика; перенос между моделями оценён.
• Определена эксплуатация: поддержка, инциденты, обновление evals, change management и передача знаний.
• Риски данных описаны: классы данных, регионы хранения, retention, subprocessors и порядок удаления.

Если у компании пока нет собственного технического владельца, добавьте независимый architecture review перед production. Сам подрядчик не должен быть единственным человеком, который подтверждает качество своей работы.

Красные флаги

• начинает встречу с выбора модели, не разобрав процесс и baseline;
• обещает процент экономии до доступа к данным;
• показывает только идеально подобранные демо и отказывается от закрытого теста;
• считает prompt engineering достаточной архитектурой;
• не умеет объяснить evals, regression testing и human escalation;
• просит production-доступ до threat model и списка разрешённых действий;
• не обсуждает latency, стоимость повторов, логи и отказ внешнего API;
• хранит код, prompts или ключи только в своих аккаунтах;
• обещает полностью автономного агента там, где ошибка юридически или финансово значима;
• не может назвать ни одного провала и ни одного решения, которое пришлось откатить.

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

FAQ

Как называется специалист по внедрению LLM?

На рынке используются названия LLM-интегратор, AI solutions architect, applied AI architect, AI deployment engineer и forward deployed engineer. Название вторично: проверяйте, отвечает ли человек за discovery, код, архитектуру, evals, production и adoption.

Чем LLM-интегратор отличается от обычного консультанта?

Обычный консультант может закончить работу рекомендациями. LLM-интегратор должен уметь сам собрать техническую проверку, встроить её в IT-контур, задать критерии качества и довести решение до эксплуатации вместе с командой клиента.

Нужен ли кандидату опыт машинного обучения?

Глубокий опыт обучения foundation models нужен не всегда. Нужны понимание поведения LLM, evals, данных, RAG и agentic workflows, а также сильная software/cloud engineering база. Anthropic допускает знакомство с LLM-фреймворками либо background в ML/data science; OpenAI сильнее подчёркивает production engineering.

Сколько лет опыта искать?

В рассмотренных ролях OpenAI и Anthropic встречается минимум 5+ лет, у более инженерной роли OpenAI — 7+, у AWS Partner Solutions Architect — 8+ лет в технических доменах. Для бизнеса важнее не число само по себе, а доказанный цикл от discovery до production.

Должен ли интегратор знать конкретно GPT, Claude или AWS Bedrock?

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

Как понять, что пилот успешен?

До запуска зафиксируйте baseline и критерии: долю успешно выполненных задач, критические ошибки, время, стоимость, человеческие проверки и adoption. Успех — улучшение рабочего процесса на закрытом наборе и у реальных пользователей, а не положительная реакция на демо.

Конечный профиль кандидата

Ищите senior LLM-интегратора уровня Forward Deployed Engineer / Applied AI Architect со следующим профилем:

• 5–10 лет в software engineering, solutions architecture, ML/data engineering или техническом консалтинге; для самостоятельного владельца enterprise-внедрения предпочтительны 7+ лет;
• лично пишет и рецензирует production-код на Python или TypeScript, работает с API, SQL, очередями, cloud и CI/CD;
• умеет провести business discovery, зафиксировать baseline, выбрать use case по эффекту, риску и доступности данных;
• проектирует RAG, agentic workflows, tool use, MCP/A2A и enterprise-интеграции только там, где они оправданы;
• понимает data readiness, IAM, privacy, prompt injection, guardrails, audit logs и human approval для опасных действий;
• строит evals на реальных кейсах, включая edge cases, и связывает качество модели с бизнес-метрикой;
• доводил хотя бы одно решение от PoC до production, может показать rollout, observability, incident response, rollback и оптимизацию стоимости;
• одинаково ясно разговаривает с C-level, владельцем процесса, security и инженерами, не скрывая trade-offs и неизвестные;
• отвечает за production adoption и передачу знаний, а не исчезает после демонстрации;
• может назвать свои провалы, показать артефакты прошлой работы и пройти оплачиваемый тест на вашем закрытом кейсе.

Формула найма: сильный инженер + solutions architect + product thinker + консультант по изменениям. Вайбкодинг может ускорять его работу, но не является заменой ни одной из этих четырёх частей. Главный KPI — не количество AI-демо, а доля стабильно выполняемых задач, измеримый эффект и скорость безопасного перехода от прототипа к работающему процессу.