Почему ИИ — не задача вашего IT-отдела

Почему ИИ — не задача вашего IT-отдела

«Это же про технологии — пусть IT занимается». Я слышу эту фразу почти на каждом первом разговоре. Логика понятна: ИИ работает на серверах, говорит на API, выглядит как софт. Куда же ещё его отдавать, если не в отдел, который про софт и отвечает.

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

Почему ИИ инстинктивно спихивают в IT-отдел

Рефлекс «отдать айтишникам» опирается на честную, но устаревшую модель: новая технология = техническая задача = технический отдел. Так было с ERP, с сайтом, с облаками, с кибербезопасностью на раннем этапе. Логика работала, потому что эти штуки действительно были про инфраструктуру, и бизнес-смысл в них был более-менее очевиден заранее.

С ИИ модель ломается по двум причинам.

Первая: ИИ — это не один инструмент, а способ перепридумать сам процесс. Установить CRM можно, не меняя того, как компания продаёт. А вот понять, где в продажах модель реально снимет рутину, а где только создаст видимость работы, — это уже не про установку. Это про то, как устроен бизнес.

Вторая: ценность ИИ заранее не очевидна даже специалисту. По исследованию MIT «The GenAI Divide: State of AI in Business 2025», подавляющее большинство корпоративных ИИ-пилотов не доводит до измеримого возврата на P&L — не из-за слабых моделей, а из-за того, что их запускали не там и не для того. Когда направление выбирает тот, чья работа — «сделать технически», приоритет почти всегда уходит туда, где интереснее код, а не туда, где больше денег для бизнеса.

Спихнуть ИИ в IT — значит молча решить, что вопрос «что нам это даст» уже закрыт. Чаще всего он даже не открывался.

Что ваш IT-отдел умеет — и где у него структурный потолок

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

IT-отдел силён там, где есть техническое «как»:

• развернуть и поддерживать инфраструктуру, доступы, безопасность контура;
• интегрировать модель с вашими системами — CRM, 1С, базами, документооборотом;
• обеспечить контроль над данными и соответствие внутренним политикам;
• держать стабильность, мониторинг, отказоустойчивость.

Это критично, и тут им нет замены. Но обратите внимание: всё это — ответы на вопрос «как сделать то, что уже решено делать». Ни один из пунктов не отвечает, что именно решено и почему.

Где структурный потолок — и это не про квалификацию, а про роль и фокус:

• IT-отдел редко видит экономику процессов целиком — он видит системы, а не маржу по функциям;
• его не нанимали приоритизировать бизнес-инициативы по ROI — это не его KPI;
• у него нет мандата спорить с собственником о стратегии — и правильно, что нет;
• он по умолчанию мыслит «есть задача — реализуем», а не «а стоит ли эту задачу вообще ставить».

Неочевидное наблюдение из практики: чем сильнее ваш IT-отдел технически, тем убедительнее он реализует не ту задачу. Сильная команда быстро и красиво строит ровно то, что ей принесли, — и если принесли неверный приоритет, вы получите безупречно сделанную бесполезную вещь. Слабая команда хотя бы спотыкается и даёт время передумать.

Таблица: внутренний IT-отдел vs внешний ИИ-стратег

Чтобы увести разговор от «кто главнее» к «кто за что», вот разделение по задачам. Это не конкуренты в одной клетке — это две колонки, которые закрывают разные вопросы об одном проекте.

Прочитайте таблицу не как «у кого больше галочек», а как карту: почти в каждой строке роли не пересекаются, а дополняют друг друга. Стратег решает, что и зачем; IT-отдел — как и на чём. Убрать любую из колонок — и проект кренится: без IT он не взлетит технически, без стратегического слоя взлетит не туда. Подробнее про выбор первой точки внедрения я разбирал отдельно — куда внедрять ИИ первым.

«Я сам айтишник» — где руководитель-технарь упирается в слепую зону

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

Но именно у сильного технаря есть характерная слепая зона, и она тем глубже, чем лучше он как инженер.

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

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

Слепая зона тут не в знаниях. Она в роли: когда ты одновременно и тот, кто ставит задачу, и тот, кто её увлечённо решает, некому задать неудобный вопрос «зачем мы вообще это делаем». Внешний стратег здесь нужен не как «более умный технарь» — он заведомо слабее вас в инженерии. Он нужен как другой угол зрения: тот, кто смотрит на инициативу глазами P&L, а не глазами архитектуры. Это и есть пара контрольных вопросов, ради которых стоит позвать кого-то со стороны, — расширенный список я собрал в 10 вопросах ИИ-консультанту.

Стратегия данных и постановка задач — это управленческая работа

Два самых недооценённых куска ИИ-проекта — это решения, что модель должна делать и на каких данных. Оба кажутся техническими. Оба — управленческие.

Постановка задачи. «Внедрить ИИ в поддержку» — это не задача, это направление рукой. Превратить его в рабочую постановку — «модель закрывает первую линию по типовым обращениям, эскалирует нетиповое оператору, граница проходит вот здесь, метрика успеха — доля закрытых без человека при сохранении NPS» — это работа того, кто понимает экономику поддержки, а не того, кто умеет подключить API. IT реализует постановку; родить её должен бизнес.

Стратегия данных. Какие данные у вас есть, какие из них можно использовать, где проходит граница по 152-ФЗ, что отдавать внешней модели, а что не выпускать из контура, — это управленческие развилки с долгими последствиями. Технически контур закроет IT. Но решение «эти данные мы в принципе не отдаём наружу, даже если так проще» — это про риск-аппетит компании и зону ответственности руководителя, а не сисадмина. Юридическую глубину тут лучше отдать профильным юристам — я держусь управленческого угла: чьё это решение и какой ценой ошибка.

Закономерность простая: чем выше ставка решения, тем меньше оно про технологию и тем больше про бизнес. А значит — тем меньше у него общего с зоной IT-отдела.

Как разделить роли: кто внедряет, кто владеет направлением

Практический фреймворк. Развести две роли, которые в голове собственника обычно слиплись в одну.

Владелец направления (business owner ИИ). Один человек уровня C — не обязательно технарь. Отвечает на вопросы: куда идём первыми, зачем, как это связано со стратегией, окупается ли, какие данные в игре, где границы риска. Это не должность в штатном расписании, это мандат. Может опираться на внешнего стратега как на усилитель — но решение и ответственность остаются внутри.

Исполнитель внедрения (IT-отдел / интегратор). Берёт постановку от владельца направления и делает: разворачивает, интегрирует, держит в проде, обеспечивает безопасность. Отвечает за «как», за стабильность и сроки.

Внешний ИИ-стратег. Не вместо первого и не вместо второго. Помогает владельцу направления увидеть систему, отличить приоритет по ROI от технически красивой задачи, прочитать предложения подрядчиков, не зашить чужие допущения в архитектуру на годы. Уходит, когда роль владельца направления внутри окрепла.

Чек-лист, что роли разведены правильно:

• [ ] есть один человек, который отвечает на вопрос «зачем эта ИИ-инициатива», и это не глава IT;
• [ ] приоритет внедрения выбран по экономике, а не по технической притягательности;
• [ ] постановка задачи модели сформулирована на языке бизнеса с метрикой успеха;
• [ ] решение по данным принято на уровне риск-аппетита компании, а не «как технически удобнее»;
• [ ] IT-отдел получил ясное «что и зачем», а не «разберитесь там с ИИ».

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

Прогноз на 12 месяцев: запрос на роль «владельца ИИ-направления», отдельного от IT, станет нормой для среднего и крупного бизнеса. По данным Gartner, 80% CEO ожидают, что ИИ заставит переосмыслить операционные возможности компании, — а переосмысление операционной модели не делегируется в технический отдел по определению. Компании, которые разведут «кто внедряет» и «кто владеет» осознанно, оказываются в более выгодном положении, чем те, у кого ИИ висит тикетом в IT-бэклоге.

FAQ

ИИ — это управленческая или айтишная задача?

И та, и другая — но на разных уровнях. Айтишная часть: развернуть, интегрировать, обеспечить безопасность и стабильность. Управленческая часть: решить, куда внедрять, зачем, окупится ли, какие данные в игре. Беда начинается, когда управленческий слой молча отдают в IT вместе с техническим. Технический отдел реализует решения — но не его роль эти решения принимать.

Нужен ли ИИ-специалист в штат?

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

Можно ли внедрить ИИ своими силами, без внешних людей?

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

Кто должен отвечать за ИИ в компании — CIO, CTO или кто-то ещё?

Технический владелец (CIO/CTO) отвечает за «как»: инфраструктуру, интеграцию, безопасность. Но владельцем направления — тем, кто отвечает на «что и зачем», — должен быть человек, держащий бизнес-картину целиком: собственник, CEO или профильный C-level. Часто это разные люди, и это нормально. Опасно, когда обе роли по инерции сливаются в одну техническую.

Внешний ИИ-стратег и IT-отдел — это конкуренты?

Нет, и я специально не строю работу как замену вашим инженерам. Это два параллельных слоя: стратег отвечает на «что и зачем», IT — на «как и на чём». Хороший внешний стратег усиливает IT-отдел, давая ему ясную постановку вместо размытого «сделайте что-нибудь с ИИ», и уходит, когда внутренняя роль владельца направления окрепла.

Информация в материале: не является публичной офертой (ст. 437 ГК РФ) · носит общий ознакомительный характер, не является индивидуальной консультацией (юридической, финансовой, налоговой или иной) · отражает мнение автора и личный опыт на дату публикации · не гарантирует конкретные результаты, доход или сроки. Цены, условия и функциональность сторонних инструментов могут измениться без уведомления. Кейсы и наблюдения из практики, упомянутые в материале, отражают конкретные ситуации и не являются обещанием аналогичного результата: эффективность ИИ-внедрения зависит от исходного состояния компании, готовности команды и масштаба проекта.

Об авторе Егор Борисенко

AI-консультант для крупного бизнеса. Помогаю руководителям выстроить AI-слой поверх существующих процессов: стратегия, обучение команды, прототипирование инструментов, личное партнёрство с C-suite. Работал с Минцифры РФ, телекомами, девелоперами, юридическими фирмами, университетами и под мандатом ЮНЕСКО.

Telegram Связаться