Роб Колли, генеральный директор и основатель P3 Adaptive, автор книги Fair Game — серия интервью

Rob Collie является основателем и генеральным директором P3 Adaptive, партнёра Microsoft Solutions Partner по данным и ИИ, обслуживающего сотни средних компаний и клиентов из Fortune 1000. Ранее он был руководителем инженерных команд Microsoft в проектах Excel, Bing и Power BI; после ухода из Microsoft возглавил развитие Power BI и написал три предыдущих книги о бизнес‑технологиях (более 92 000 проданных копий). Он также ведёт подкаст Raw Data with Rob Collie. Его четвёртая книга, Fair Game: Customizing AI to Your Business Is Easier Than You Think (август 2026), переносит его практический авторитет в эпоху ИИ.

Вы проработали более десяти лет в Microsoft, помогая разрабатывать функции бизнес‑аналитики в Excel и Power BI, прежде чем в 2013 году основали P3 Adaptive. Как переход от создания программного обеспечения внутри Microsoft к решению проблем с данными для клиентов сформировал ваш текущий взгляд на корпоративный ИИ?

Когда я руководил продуктовыми командами в Microsoft, мы создавали программное обеспечение, которое должно было работать для всего мира и не могло быть адаптировано под нужды конкретного клиента. Мы называли это «заказать пиццу, начинка которой устраивала бы 300 миллионов людей». Такая работа неизбежно имеет «наименьший общий знаменатель», а также определённую дистанцию от отдельных заказчиков.

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

Но появляется и большая ответственность. В Microsoft один недовольный клиент был лишь статистикой, и я ежедневно отмахивался от жалоб как от части своей работы. В P3 Adaptive один недовольный клиент означает, что мы провалились. Статистики нет. Мы отвечаем перед каждой отдельной связью.

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

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

В Fair Game вы утверждаете, что многие компании подходят к искусственному интеллекту наоборот, распределяя лицензии на универсальные чат‑боты вместо построения систем, понимающих их операции. Где заканчиваются возможности готовых ИИ‑ассистентов и какие сигналы указывают, что бизнесу нужен кастомный подход?

Готовый ИИ имеет степень доктора наук во всём, кроме вашего бизнеса. Он «прочитал» весь интернет, но в интернете отсутствует ваше определение «активного клиента», ваша ценовая логика, ваши операционные процессы и то, какой из двух ваших систем доверять при расхождении. Эти знания никогда не станут публичными. Поэтому универсальный ИИ, который превосходит всех в личном использовании, не справляется с реальными бизнес‑задачами, а разрыв между этими двумя опытами одновременно отталкивает и путает.

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

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

Вы используете термин «Crafters» (Создатели), чтобы описать бизнес‑профессионалов, разбирающихся в данных, способных построить ценные кастомные ИИ‑системы без традиционных навыков разработки. Какие характеристики отличают Создателя и как лидеры могут определить таких людей в своей текущей команде?

Создатель — это человек, у которого с рождения зуд решать задачи с помощью инструментов. По моему опыту примерно один из шестнадцати работников знаний обладает этим. Они были продвинутыми пользователями Excel, затем поколением Power BI, затем теми, кого ИТ называл «теневым ИТ». Это ваши аналитики, финансовые моделисты, руководители операций — люди, выросшие в бизнесе и обнаружившие талант к инструментарию.

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

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

Почему вы считаете, что Создатели, а не только разработчики, лучше всего подходят для ведения многих внутренних ИИ‑проектов, и как следует распределять ответственности между бизнес‑экспертами, командами данных, разработчиками, ИТ‑отделами и командами безопасности?

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

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

Есть также недооценённый средний путь: Создатель строит, разработчик проверяет. ИТ и безопасность не должны быть вратарями, одобряющими проекты — они должны владеть «проложенной дорогой». Предоставьте одобренные платформы, правила доступа к данным, контрольные точки проверки, и позвольте людям, ближайшим к проблеме, заниматься построением. Рассматривайте всё как модель зрелости, а не как забор.

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

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

Хорошая новость, скрытая на виду: если вы инвестировали в эпоху BI (особенно в Power BI), у вас уже может быть стартовое преимущество. Хорошо построенная семантическая модель — это именно машинно‑читаемая фиксация бизнес‑значения, необходимая агентам. Компании, отнесшие свой семантический слой к послепродажному, обнаруживают, что «скучная» работа по определению, которую они пропустили, теперь является пунктом оплаты на пути к ИИ. И, что критично, эта работа глубоко специфична для вашего бизнеса — именно поэтому она является прочным преимуществом. Любой поставщик может продать вам одну и ту же модель. Никто не может продать вам ваши собственные определения.

Вы создали кастомный ИИ‑редактор под названием Eddie, чтобы помочь в разработке Fair Game. Что именно делала система в процессе написания и чему её успехи и неудачи научили вас о проектировании ИИ вокруг очень личного рабочего процесса?

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

Он отслеживал обещания, данные мной в Третьей главе, и указывал на их отсутствие в Двенадцатой. Он выучил мой стиль письма и затем принудительно поддерживал его — держал меня за лучшую версию моего собственного голоса, вместо того чтобы позволить мне скатиться в режим «Беспристрастный бизнес‑автор». Он говорил мне, когда я был ленив и когда я бил мёртвую лошадь. У нас были реальные разногласия, и иногда он выигрывал.

Самый большой урок дизайна: «мозг» Eddie написан на английском и живёт в папке. Каждый раз, когда он давал обратную связь, которая промахивалась — слишком общая, неверный регистр, забытое правило, которое я уже сформулировал — решение заключалось в том, чтобы записать исправление и сделать его частью его постоянного контекста. Ошибки были не ошибками ИИ; это были пробелы в том, чему я его обучил. Этот цикл — заметить промах, закодировать урок, увидеть, как он закрепляется — и есть вся ремесленная суть кастомного ИИ в миниатюре. И именно поэтому я построил специализированные версии Eddie для публичных выступлений, конкурентных исследований и сообщений на сайте. Под ним один и тот же LLM, но разные специалисты.

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

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

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

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

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

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

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

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

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

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

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

Затем применяйте модель эскалации: эксперименты свободны, но когда что‑то становится критически важным — больше пользователей, больше чувствительности, больше автономии — оно получает всё более строгий инженерный обзор. Создатель сохраняет владение бизнес‑логикой; разработчик укрепляет то, что нуждается в укреплении. Цель — модель зрелости, а не процесс разрешения. Компании уже проходили такой же сценарий со spreadsheet‑ами, и победителями не были те, кто запретил Excel.

Для компании, начинающей свой первый кастомный ИИ‑проект, как выбрать начальный кейс, измерить, приносит ли проект реальную бизнес‑ценность, и решить, расширять, переосмысливать или отказываться от него?

Мы используем два подхода при работе с клиентами.

Вариант первый — ищите задачи, которые никто не выполняет, а не те, которые вы хотели бы устранить. Есть вопрос, который я люблю задавать менеджерам: «Где вы думали: «Если бы у меня был один человек, постоянно наблюдающий за этим и думающий об этом, всё стало бы значительно лучше, но я никогда не смог бы обосновать полную штатную позицию»?». Такие задачи часто становятся лучшими отправными точками. Они безопасны, повышают уверенность, никто не чувствует себя мишенью, а контрфакт честен: альтернатива — не человек, а отсутствие выполнения (как мой редактор‑друг Eddie).

Вариант второй — рассматривайте замену дашбордов на data‑агентов. Как бы простыми ни казались дашборды, они сильно отстают от обещаний на практике. Когда у кого‑то появляется бизнес‑вопрос, ему приходится тратить много усилий, чтобы перевести его в язык дашбордов. Где находится дашборд, отвечающий на вопрос? Как он назван? Существует ли такой дашборд? И если вы находите «правильный», удобен ли он? Нужно ли постоянно манипулировать им, записывая или скриншотируя несколько версий, чтобы собрать общую картину?

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

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

Что касается расширения, переосмысления или отказа — будьте добры к себе, потому что исследования в этом направлении действительно утешительны: большинство успешных внедрений ИИ имели неудачи до успеха. Первый проект, который даёт урок вместо прибыли, — это обучение, а не доказательство, что ИИ не работает. Мой практический совет: если люди используют систему, расширяйте её. Если не используют, выясняйте почему — ответы могут быть от «потому что она плохо работает» до «потому что я её не понимаю» и до «это меня пугает». Ответ подскажет, улучшать, переосмысливать или бросать. Не нужно предсказывать, куда всё это приведёт. Нужно лишь честно начать.

Спасибо за отличное интервью, читатели также должны ознакомиться с Fair Game: Customizing AI to Your Business Is Easier Than You Think.