В найме AI-лидеров часто путают опыт внедрения с умением говорить об AI: часть кандидатов показывает презентации и стратегию, но не показывает работающие системы, код или продовые внедрения. Нанимающий менеджер это понимает и проверяет артефакты: работающие сервисы, репозитории, продовые метрики, ownership — по ссылкам на системы, коду, метрикам и описанным решениям. Ниже — прямые ответы на восемь групп вопросов, которые HR и hiring manager задают профилю AI-Driven Head of Engineering. По каждой теме: что сделано, чем подтверждается, где есть ограничения.
Руки: что собрано и где это работает
Первый вопрос к AI-лидеру — не тайтл и не количество managed engineers, а ответ на вопрос: есть ли у тебя работающие системы, код и продовые внедрения, или только презентации?
За последний год — две рабочие AI-системы, собранные единолично: система delivery-intelligence на живых проектах (ai-delivery.dobryakov.net) и система market-intelligence и контент-операций (nextmoveengine.com). Публичный MCP-сервер профиля (dobryakov.net/mcp.html), открытый код на github.com/dobryakov. Система delivery-intelligence используется на двух живых проектах около двух месяцев — ловит расхождения смет, пропущенные ответы, противоречия в документах.
В Askona — AI-assisted разработка в живом enterprise-контуре: next best offer (ML), трекер таймстампов, geo-resolver proxy, AI-бот к data lake (NL→SQL). В открытой howto-серии — воспроизводимые артефакты с кодом, сценариями запуска и воспроизводимыми примерами: jira-clarify-bot, bots-discuss-spec, eval-harness, enterprise-code-bastion, egress-redaction-gate, ai-n8n-workflow-builder, git-evolution-audit.
Принцип: использую те же подходы в собственных продовых системах. То, что рекомендуется командам (RAG, event-driven агенты, eval-гейты, knowledge architecture), — реализовано в перечисленных системах и используется в production. За 20+ лет пройден путь CTO и enterprise-архитектора, при этом с сохранением личного участия в проектировании и разработке: проектирование и сборка систем руками продолжаются.
Отличие от консультанта: консультант обычно отвечает за рекомендации, а не за операционный результат после внедрения — здесь речь о владении функцией и ответственности перед советом директоров или CEO за результат. Формат — fulltime, не fractional. Не краткосрочный аудит с последующей продажей внедрения, а перестройка инженерной/delivery-функции в AI-native и владение результатом.
Команда: как перенести AI-практики из личного уровня в командный
Вопрос «а что останется, когда вы уйдёте?» — правильный. Ответ: практики, которые команда продолжает применять без меня, а не зависимость от одного специалиста.
В Askona: десятки обучающих мероприятий на аудитории по 100–200 человек — инженерные практики, управленческие подходы и прикладное применение AI. На тех же сессиях собирались реальные сервисы. К 3–4 году новые принципы и архитектуру команды защищали сами — включая тех, кто поначалу скептически относился к изменениям. После внедрения этих практик в компании появилось отдельное AI-направление.
В UMI внедрённые методики команда продолжила применять и после завершения турнараунда — в том числе на других проектах.
Со скептиками работаю через конкретные задачи и передачу владения новыми компонентами: переход на AI/новую архитектуру подаётся как апгрейд навыков с реальным владением новыми компонентами. Legacy-инженеру показываю, какие новые зоны ответственности появляются у него после изменений. Движение поэтапное, а не «большим взрывом»: скептик, убедившийся, что его экспертиза становится ценнее, часто начинает сам поддерживать внедрение.
Governance: как AI-контур проектируется с учётом безопасности
Безопасность AI встраивается в проект, а не добавляется после проектирования как отдельный слой. Базовый контур: data isolation (данные остаются в авторизованной границе), разметка источников по уровню доверия, prompt-injection defense, audit trail на каждом факте и human-in-the-loop checkpoints на всех автономных шагах. Для сред, где LLM нельзя давать доступ к файлам или шеллу, — паттерн enterprise-бастиона: --tools "", MCP-only, фильтрация команд, исполнение в изолированном контейнере (enterprise-code-bastion, репозиторий).
Для снижения риска галлюцинаций использую три механизма. Первый: provenance на каждом факте — каждое значимое утверждение должно иметь ссылку на источник с таймстампом, система не путает «сказали на звонке» с «подписанным обязательством». Второй: детектор противоречий — при расхождении источников система помечает конфликт источников и требует проверки. Третий: eval как release-gate — AI-функция не выпускается в production без прохождения регресс-набора из реальных инцидентов и human spot-check (eval-harness).
По compliance (GDPR, EU AI Act, data residency): проектирую AI-контур с governance, заложенным на этапе проектирования — human-in-the-loop, изоляция и минимизация данных, audit trail, размещение данных в нужной юрисдикции. Для каждого AI-сценария заранее фиксируется, какие данные пересекают границу доверия и на каком основании. Классификация риска по логике EU AI Act фиксируется на этапе проектирования AI-сценария.
Честная оговорка. Формального аудита на соответствие конкретному регламенту в публичном контуре нет; предъявляются инженерные механики (изоляция, egress-редакция PII и секретов, human-in-the-loop), на которые такой комплаенс опирается. Демо egress-редакции: dobryakov.com/howto/egress-redaction-gate.
ROI: бизнес-метрики, а не velocity
ROI от AI меряется не в «количестве сгенерированных строк кода», а в бизнес-метриках.
Конкретные данные:
UMI (CTO, SaaS-turnaround): выручка +50% г/г; поток новых дефектов снижен с 5–10 в день до ≤5 в неделю; релизы из «раз в несколько месяцев» в «практически еженедельно».
Askona (enterprise): AI-бот к data lake — Time-to-Insight с нескольких дней (очередь в Jira) до секунд.
Управленческие KPI delivery-системы: scope compliance, commitment tracking, возраст открытых вопросов — то, что напрямую влияет на маржу и удовлетворённость клиента.
Где числовых KPI в публичном контуре нет — так и указываю: эффект описан качественно, без числовой атрибуции. Например, в Askona метрик по циклам согласования не снималось, но постановка задач и согласование ускорились за счёт AI-валидации и сокращения ручных итераций. Такие наблюдения не оформляются как измеренные KPI.
Честная оговорка об ограничениях AI. Clarify-гейт без project context задаёт generic-вопросы, которые заказчик игнорирует, — без контекста инструмент не внедряется. Cross-org negotiation без явной trust-модели — сырой инструмент, не боевой продукт. «Demo-grade ≠ production-grade»: AI-функция без eval-харнеса в production не выходит. Умение сказать «в этом сценарии AI не улучшает метрику достаточно, чтобы оправдать внедрение» — часть компетенции, а не слабость.
Честная оговорка об атрибуции. Публичные бизнес-показатели — это показатели организаций в целом, а не прямое измерение вклада одной программы.
Org-design и первые 90 дней
AI-native означает, что AI встроен в разработку, продукт и операционные процессы, а не выделен только в отдельную команду. Команды сами используют AI в разработке, тестировании и ревью; продукт включает AI-функциональность, спроектированную для надёжной работы в production; операционные контуры получают сигналы из данных.
Там, где компании нанимают VP Engineering и Head of AI по отдельности, профиль закрывает оба уровня с единой ответственностью: и люди/delivery, и системное встраивание AI, и то, что вся агентская система работает как operating model, а не набор пилотов. Типичный разрыв на рынке кандидатов — VP без AI, Head of AI без delivery, консультант без ответственности за операционный результат: у каждого из них явная слабость.
Каркас первых 90 дней, подтверждённый на четырёх турнараундах в компаниях разного масштаба и сложности:
Дни 0–30 — диагностика без резкой реорганизации. Снять реальное состояние: где delivery буксует, где AI уже пробовали и почему не дошло до production, где данные и governance. Инструмент — архитектурный ретроанализ по git-истории (детерминированные метрики + интерпретация), а не только интервью. Не менять организационную структуру до завершения диагностики.
Дни 30–60 — первые изменения с владельцем, метрикой и ограниченным scope. Один-два узких, но заметных контура: clarify-гейт требований, eval-гейт релиза, AI над одним delivery-процессом с измеримыми потерями: задержками, переделками или открытыми вопросами. Результат должен иметь владельца, baseline и целевую метрику, а не «пилот без критерия перехода в production или закрытия».
Дни 60–90 — закрепление практик в командах. Обучение и менторинг лидов, чтобы AI-практики стали командным активом. Зафиксировать роли, зоны ответственности и критерии успеха AI-направления.
В Askona эффект проявился в первые два года; культура закрепилась к 3–4 году. Поэтапность вместо одномоментной реорганизации — подход, который уже применялся в Askona и UMI.
По build vs buy vs partner: решение принимается регулярно и по TCO, а не по популярности инструмента на рынке. Строить — там, где это core-дифференциатор и нужна внутренняя ответственность за результат и дальнейшее развитие; покупать — там, где commodity с хорошим SLA. В крупном enterprise каждые 1–2 месяца проходил через make-or-build-or-partner для новых сервисов: техническая валидация подрядчиков до входа, противостояние преждевременному аутсорсингу, фиксация провалов вендоров и использование этих результатов в будущих решениях.
Технический стек и устойчивость к скорости изменений
Подтверждённый стек: Anthropic Claude (API, MCP, tool use), OpenAI-совместимые интерфейсы, Gemini (Python/n8n); event-driven слой (Kafka, RabbitMQ, webhooks), vector stores, ElasticSearch/ClickHouse; cloud/IaC (AWS, Docker, Ansible).
Выбор модели — по задаче и границе доверия, не по бренду: где нужен tool-use и управляемость — Claude/MCP; где дешёвый массовый инференс — то, что даёт цену за токен при приемлемом качестве.
Ответ на вопрос «как успеваете за скоростью изменений» — через архитектуру, устойчивую к смене модели. Контракты, eval-гейты и провенанс не зависят от того, какая модель под капотом сегодня. Модель можно заменить при сохранении контрактов, eval-наборов, provenance и процессов эксплуатации. Актуальность стека проверяю на собственных production-сценариях: я веду блог, howto-серию и собственные системы.
Для работы с legacy без поломки business continuity: AI-функции добавляются поэтапно в существующий production-контур с учётом архитектурных и security-ограничений. Askona — AI-практики в живом enterprise-контуре ($680M+, 40+ сервисов); PersonaClick — модернизация legacy-платформы персонализации под 199M+ профилей, миграция ML с пакетного на потоковое переобучение.
People management: найм, перформанс, расставание с сотрудниками
Использую матрицы компетенций и грейды для найма, оценки и планов роста. На их основе — индивидуальные планы роста и, где нужно, формальные PIP, привязанные к названным пробелам. Регулярная ранняя обратная связь, включая тяжёлую корректирующую; при недоборе — диагностика корня (навык / мотивация / не та роль) до решения об уходе.
В UMI в ходе SaaS-турнараунда выведена консервативная часть команды включая архитектора, набрано более половины новых людей. Решения о расставании принимались после диагностики роли, мотивации и навыков.
Удержание — через реальное владение результатом и менторинг через вопросы, разбор решений и передачу ответственности. Конфликты — медиация и деэскалация без разрушения рабочих отношений. В распределённых командах масштаб достигается через локальных старших лидов в каждом офисе, чтобы решения принимались без централизации всего авторитета. Психологическая безопасность: риски и ошибки можно поднимать без санкций за сам факт эскалации.
Обоснование инвестиций перед CEO, CIO или бордом: аргументация через архитектурные риски, TCO и стоимость отложенной модернизации против краткосрочной экономии; аргумент «модернизировать сейчас против тушить пожары инкрементально». Онбординг входящих топов (включая нового CIO). Умение отстаивать отказ от преждевременного архитектурного решения при давлении стейкхолдеров, когда архитектурная ставка преждевременна, — цена такого просчёта в масштабе измеряется годами долга.
Логистика: формат, локация, компенсация
Fulltime, fully remote. База — Сербия/Черногория, CET/CEST — полное перекрытие рабочих часов ЕС. Разрешение на работу в Черногории (продлеваемое); возможна работа через EOR или как contractor. Горизонт — от года. Ищу реальный мандат, а не роль только для поддержания текущего состояния.
Английский — рабочий, публичный экспертный контент и профиль ведутся на английском (LinkedIn, dobryakov.net). Русский — родной. Распределённые мультиязычные команды — комфортная среда.
По «прыжкам»: профиль — turnaround-специалист. Меня зовут починить сломанное или собрать порядок из хаоса, а не поддерживать стабильное операционное состояние без мандата на изменения. Это по определению мандат с интенсивными изменениями в первые месяцы. При этом enterprise-трек — многолетний: Askona — годы, культура закреплялась к 3–4 году. Четыре турнараунда в компаниях разного масштаба и сложности — это последовательность с логикой, а не разброс.
Компенсационная вилка — ориентир: уровень senior engineering leadership (Head of Engineering / Head of AI) в fully-remote EU-контуре; конкретная вилка от формы сотрудничества (штат через EOR vs contractor), объёма мандата и композиции (equity/бонус). Обсуждается по деталям роли.
Где этот профиль работает
У меня совмещены два опыта: управление инженерной организацией и практическая AI-инженерия, поэтому профиль подходит ролям, где один лидер отвечает и за engineering, и за AI-внедрение. VP Engineering без AI-опыта может наладить delivery, но часто передаёт AI-внедрение отдельной функции. Head of AI без engineering-management опыта может построить модельный контур, но не всегда владеет delivery и оргизменениями. Консультант обычно не несёт долгосрочную ответственность за эксплуатацию и метрики после внедрения.
Этот профиль — для компаний, которым нужен один человек с ответственностью за всю систему: люди, delivery и то, что AI в ней работает не только в пилотах, а в регулярной разработке, delivery и операционных процессах. Подтверждение: ссылки на работающие системы, репозитории, howto-материалы и описанные внедрения.