Юрий Губин, CTO в DataArt — серия интервью

Yuri Gubin, CTO в DataArt — опытный технологический руководитель и архитектор программного обеспечения, проработавший в компании более 18 лет, последовательно занимая позиции от архитектора программного обеспечения и архитектора решений до облачных технологий, инноваций и исполнительного руководства, прежде чем стать Chief Technology Officer в марте 2026 года. Его работа была сосредоточена на решении сложных технологических задач в таких отраслях, как финансовые услуги, здравоохранение, туризм и IoT, с особой экспертизой в облачных вычислениях, ИИ, платформах данных и корпоративной архитектуре программного обеспечения. До назначения CTO Губин более пяти лет занимал должность Chief Innovation Officer в DataArt и с 2021 года является членом Совета Партнёров компании. Он также является профессиональным членом Forbes Technology Council, участвует в её экспертных группах по ИИ и облачным вычислениям, и выступает в качестве технологического советника в Girls Who Code, где консультирует по архитектуре, защите данных, управлению платформой и технологической политике. DataArt в настоящее время указывает его как Chief Technology Officer, базирующегося в Нью‑Йорке.

DataArt — глобальная компания по разработке программного обеспечения и трансформации данных и ИИ, основанная в Нью‑Йорке в 1997 году. Компания выросла до более чем 6 000 технологических специалистов, работающих более чем в 20 странах, и обслуживает более 400 клиентов, предоставляя услуги в областях, включая искусственный интеллект и машинное обучение, данные и аналитику, облачную трансформацию, кастомную разработку программного обеспечения, кибербезопасность и модернизацию наследия. DataArt работает в секторах, таких как финансовые услуги, здравоохранение и науки о жизни, туризм, медиа и развлечения, а также розничная торговля, и поддерживает технологические партнёрства с платформами, включая AWS, Google Cloud, Microsoft Azure, Snowflake и Databricks. В 2025 году компания объявила о трехлетних инвестициях в размере $100 million в свои возможности в области данных и ИИ, а в 2026 году запустила Artisyn — модель работы, поддерживаемую ИИ, предназначенную для интеграции AI‑агентов, повторно используемых ускорителей, управления, безопасности и соответствия в разработку корпоративного программного обеспечения.

Вы проработали почти два десятилетия в DataArt, продвигаясь от архитектора программного обеспечения и архитектора решений до Chief Innovation Officer и сейчас CTO. Как этот путь сформировал ваш способ отличать действительно трансформирующие технологии от циклов ажиотажа, и как он влияет на ваш «скептический оптимизм» по отношению к ИИ сегодня?

Мы наблюдали множество разных волн за эти годы, включая рост облачных технологий и мобильных решений, различные поколения ИИ, автоматизацию, DevOps и SRE, и я занимался программированием, архитектурой и консультированием наших клиентов по многим из этих тем в течение всего этого времени. Я понял, что, да, с помощью технологий можно почти всё, и технологии действительно мощны, но дьявол кроется в деталях, и вам нужно знать, что вы делаете, чтобы всё имело смысл и работало.

Я видел, как облачные среды становятся всё дороже, модели ИИ, которые не работают так, как вы ожидаете, и плохо реализованные попытки автоматизировать циклы выпуска. Я наблюдал влияние как хороших, так и плохих решений, поэтому каждый раз, когда появляется что‑то новое и вы читаете все анонсы, обещания и ажиотаж, я возвращаюсь к той же предпосылке: почти всё возможно с помощью технологий, но вам нужно знать, что вы делаете.

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

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

Enterprise AI, похоже, переходит от стадии поощрения экспериментов к определению, какие эксперименты действительно заслуживают масштабирования. Какие сигналы подсказывают вам, что случай использования ИИ готов к более широкому внедрению, и какие признаки предупреждают, что компания масштабирует слишком рано?

Я использую два метода, чтобы понять, можем ли мы масштабировать что‑то или нужно заняться чем‑то другим: кривую принятия и кривую обучения.

Чтобы понять, работает ли случай использования ИИ, необходимо дать ему время и оценить, какую ценность он приносит и как выглядит путь пользователя, потому что тогда можно увидеть колебания, а не только мгновенный эффект «вау» в конкретной команде или рабочем процессе. Нужно посмотреть, что происходит с теми же людьми через несколько недель. Они всё ещё используют его? Они всё ещё довольны этим случаем использования, этой автоматизацией или этим AI‑инструментом, который они создали, или это был лишь кратковременный всплеск, который действительно не стоит масштабировать?

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

Каждый крупный выпуск модели может создавать давление внутри организации, заставляя сразу предоставить сотрудникам доступ к новейшим возможностям. Как технологическим лидерам оценить, представляет ли новая модель значительное улучшение, а не просто порождает очередную волну экспериментов и расходов?

Вот моя скептически‑оптимистичная позиция снова. Предположим, что у вас уже есть модель, и несколько тысяч людей используют ИИ ежедневно, при этом доступны разные модели и инструменты. Когда выходит новая модель, из‑за ажиотажа и естественного любопытства можно ожидать, что каждый захочет поэкспериментировать с ней, что, безусловно, хорошо, но такие эксперименты могут быть не направлены ни к каким конкретным результатам, и иногда вы даже не сможете измерить разницу.

В масштабе это имеет значение. Речь идет не о одном‑двух людях, которые проверяют, как новая модель работает по сравнению со старой. Это могут быть тысячи людей, тратящие время на эксперименты, хотя для конкретного сценария результат может быть не столь значим. При этом, если что‑то действительно работает отлично, полученные знания о том, что работает в вашей организации, могут быть недостаточно ясно объяснены или видны всем.

Именно поэтому первой группой, оценивающей новую модель, не должны быть все сотрудники организации. Это должна быть группа R&D, тесно сотрудничающая с соответствующими командами, а также с юридическим отделом и службой безопасности. Мы всесторонне оцениваем модель, проводим быструю проверку и затем представляем её более широкой аудитории с комментариями и рекомендациями по вопросам безопасности, соответствия и технологий. Поскольку новые модели и крупные обновления появляются постоянно, необходимо иметь эту модель и соответствующее мышление. Это действительно не разовое или одноразовое упражнение.

DataArt создала кросс‑функциональную «AI SWAT», включающую технологический, юридический, отдел соответствия, InfoSec и другие команды. Как эта группа работает на практике и какие типы рисков или вопросов необходимо решить, прежде чем новый ИИ‑инструмент будет одобрен для более широкого использования?

С момента создания, по моему мнению, мы ставим разные цели для этой группы примерно каждые четыре‑пять месяцев. Мы меняем приоритеты, цели и иногда миссию, и многие из этих целей связаны с ИИ. Это может быть повышение квалификации сотрудников, вывод на рынок новых возможностей, партнёрства или более широкое внедрение ИИ в организации и в рамках ADLC.

Конкретные темы со временем меняются, и я считаю, что это здорово, потому что постоянно необходимо переосмысливать свою стратегию, проверять предположения и понимать, нужно ли менять курс и какая будет следующая тема для команды.

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

Именно поэтому, когда мы оцениваем новое партнёрство, инструмент или акселератор, мы обсуждаем их открыто, чтобы каждый понимал, куда движется дело, и имел возможность задавать вопросы или осуществлять надзор. Для нового ИИ‑инструмента технологический отдел не может оценивать его в изоляции. Службы безопасности, юридический отдел и отдел соответствия также должны понять, как он обрабатывает данные компании или клиентов, какие ограничения применимы и можно ли безопасно использовать его в масштабе.

Иногда команда AI SWAT также работает над конкретными программами, например повышением квалификации, где мы ставим цели, разрабатываем дорожные карты и решаем, как различные группы будут подключаться. Именно так это и работает: информировать людей, совместно работать над конкретными программами и предоставлять совету видимость того, что происходит с ИИ в компании.

Вы наблюдаете очень разные отношения к разработке программного обеспечения с поддержкой ИИ: одни организации активно масштабируют агентную разработку, в то время как другие всё ещё запрещают код, сгенерированный ИИ. Что объясняет это разделение и что должно измениться, прежде чем более осторожные к рискам компании почувствуют себя комфортно с более широким участием ИИ в инженерии программного обеспечения?

Вероятно, различие между теми, кто говорит «нет», и теми, кто говорит «да», определяется их готовностью к риску и отношением к неоднозначности и неопределённости. Что помогает обеим типам организаций, так это непрерывное обучение, эксперименты и оценка. Даже среди множества организаций, с которыми мы работаем и которые принимают ИИ и внедряют его повсеместно, остаются проблемы с измерением результатов и воздействия. Честно говоря, вопрос о том, как измерять влияние ИИ и как оценивать эффективность команды, иногда возникает как бы из ниоткуда, словно никто ранее об этом не задумывался.

Как только вы начнёте более всесторонне оценивать инициативу в области ИИ, вы начнёте понимать её влияние и реальную ценность, что приводит к более обоснованным решениям о том, где технология имеет смысл. Для компаний, которые отказываются от ИИ, всё равно необходим непрерывный процесс пересмотра того, что технология может сделать и где она сейчас находится. Вы не хотите, чтобы решение, принятое три года назад, оставалось политикой компании просто потому, что никто не пересмотрел исходные предположения.

Agentic AI делает всё проще для отдельных команд создавать собственных агентов, что может привести к появлению множества агентов, выполняющих почти одинаковые задачи. В какой момент экспериментирование превращается в разрастание агентов, и какой уровень управления необходим для контроля владения, прав доступа, дублирования и управления жизненным циклом?

Когда мы наблюдаем типичный сценарий, при котором лицензия на ИИ предоставляется каждому разработчику, а экспериментирование становится бесконтрольным, каждый начинает создавать свои собственные решения и работать по‑своему. Как правило, это приводит к слабо работающим командам, несбывшимся ожиданиям, отстающей качеству и росту расходов. В итоге система не делает того, что ожидают, её качество плохое, и она становится дорогой. Чтобы смягчить это, необходимо командное взаимодействие в рамках более широкой департаментской или организационной инициативы, и здесь на помощь приходит управление.

На уровне проекта можно согласовать базу знаний и контекст, а также случаи использования, где вы начинаете применять ИИ. Затем создаются навыки и агенты, которые входят в рабочий процесс разработки и могут быть использованы всеми, что позволяет накапливать знания и лучшие практики, а не воссоздавать их каждый раз. Такой проектный усилий следует координировать, например, советом по корпоративной архитектуре, технологической группой, CTO или командой, отвечающей за внедрение ИИ. Нужно повторно использовать хорошо работающих агентов, обеспечить надёжность процесса и обеспечить его работу по всей организации, а не превратить его в хаос и шум.

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

Потребление токенов и затраты на вывод могут казаться относительно небольшими во время пилотного проекта, но становятся значительными, когда ИИ‑системы развертываются среди тысяч сотрудников или автономных агентов. Как предприятия должны подходить к управлению затратами на ИИ, и ожидаете ли вы появления чего‑то похожего на FinOps, специально для нагрузок ИИ?

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

Итак, FinOps существует, и AI FinOps тоже существует. Некоторые методы очень технические, другие — довольно простые. Всё может сводиться к выбору предпочтительной модели, чтобы не полагаться постоянно на самую дорогую, и постепенно такие решения начинают экономить деньги. В то же время умение экономить и контролировать расходы — лишь половина уравнения. FinOps, как я его вижу, — это дисциплина и методология, которая также привлекает руководителей продуктов и бизнеса, поскольку необходимо определить, что именно измерять при оценке усилий в области ИИ.

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

Многие компании просят продемонстрировать ROI от ИИ, хотя они никогда не устанавливали надёжную базовую линию продуктивности своих команд до внедрения ИИ. Что именно должны измерять организации, если они хотят определить, создаёт ли ИИ значимую бизнес‑ценность?

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

Существует несколько классов метрик. Некоторые субъективные и могут представлять собой просто обратную связь от ваших разработчиков или сотрудников, поскольку вы работаете с людьми, и важно понять, как они воспринимают ценность ИИ. Более объективные измерения могут начинаться с механических или синтетических метрик, хотя я бы советовал не привязываться к ним слишком тесно. Я имею в виду такие показатели, как коммиты кода или story points. Эти метрики показывают, что работа происходила, но они не отражают реальную ценность или влияние.

Более значимыми являются метрики, которые показывают, насколько быстро и насколько качественно была выполнена работа. Подумайте о метриках DORA, таких как lead time или MTTR, насколько быстро вы можете восстановиться после сбоя, насколько быстро исправить ошибку в продакшене, или как эти показатели меняются со временем. Одна цифра в конкретный момент не раскрывает траекторию. Один из наших архитекторов недавно отметил, что в разработке программного обеспечения хорошей метрикой может также быть надежность оценок по мере роста внедрения ИИ, поскольку это говорит о устойчивости этих усилий и о реальной продуктивности команд. Вам также необходимо отслеживать затраты, потому что если вы говорите только о выгодах, не понимая, сколько стоит их достижение, у вас нет полной картины.

За пределами разработки программного обеспечения я думаю об этом аналогично. В каждом рабочем процессе или процедуре существует некоторый единица работы и определение готовности. Независимо от того, обрабатываете ли вы заявки, проверяете документы или обслуживаете запросы клиентов, определите, что вы доставляете, а затем измерьте, сколько это заняло до внедрения ИИ, насколько быстро и насколько качественно вы можете сделать это сейчас, и какие затраты это влечёт. Это дает хорошую отправную точку как для базовой линии, так и для структуры метрик.

DataArt внедряет ИИ на протяжении всего жизненного цикла поставки программного обеспечения через такие инициативы, как Artisyn. По мере того как ИИ берёт на себя всё больше задач по реализации, тестированию и рабочим процессам, какие части инженерии программного обеспечения становятся более ценными для людей, а какие навыки рискуют стать менее важными?

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

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

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

Какие навыки становятся менее важными? Мне действительно сложно это определить, хотя, возможно, насколько быстро вы можете писать код. Шучу, но код теперь можно создавать гораздо, гораздо быстрее, а специфические знания конкретной библиотеки или языка также можно освоить намного быстрее с помощью ИИ.

Я видел, как .NET‑разработчики быстро переобучаются на Java, и пять‑десять лет назад я бы сказал, что делать это в масштабах почти невозможно. Сейчас это возможно. Опытный старший разработчик всё чаще может переключаться между языками, потому что действительно важно их понимание технологий, архитектуры, лучших практик решений, SDLC и ADLC.

По мере того как предприятия переходят от десятков пилотных проектов с ИИ к производственным системам, способным самостоятельно принимать решения, где в конечном итоге должна находиться ответственность, когда агент ИИ совершает дорогостоящую ошибку: у разработчика, у владельца бизнеса, у поставщика модели, у команды управления или у их комбинации?

Мне нравится идея безвиновного сотрудничества и совместной ответственности, потому что каждый в организации вносит вклад в лучшие практики, архитектурные рамки и решения. Даже если один разработчик пишет код с ИИ или без него, другой разработчик его проверяет, руководители команд дают рекомендации, архитекторы предоставляют архитектуру и ограничения, а команда управления участвует в решениях по бюджету, срокам и выпуску. Каждый участвует в этом по‑своему.

Очень часто, когда что‑то идёт не так, проблема кроется в процессе, поэтому в этом смысле ответственность распределяется между различными ролями. Но если просто сказать, что ответственность совместна и, следовательно, безвиновна, этого недостаточно. Её всё равно нужно разбить на конкретные обязанности.

Разработчики отвечают за код, который они отправляют в виде pull‑request, и им необходимо понимать, что происходит. Архитекторы отвечают за принимаемые ими решения и за архитектурные решения, предоставляемые агентам и разработчикам. Команда платформы отвечает за надёжность решения, независимо от того, кто или что создало конкретную строку кода.

Таким образом, ответственность присутствует, но её необходимо определять детально по командам, ролям и отделам. Нельзя просто остановиться на выводе «ИИ сделал это». Нужно спросить, какие контрольные меры, тесты или надзор позволили этой ошибке попасть в продакшн.

Если отсутствие модульных тестов позволило плохому коду попасть в продакшн, или отсутствие надзора и ревью привело к этому, вы не можете переложить эту ответственность на ИИ. Также нельзя просто винить поставщика модели или облачного провайдера за каждую ошибку или сбой.

Спасибо за отличное интервью, читатели, желающие узнать больше, могут посетить DataArt.