Главная
→
Блог
→
Гид для директора по развитию: с чего начать разговор про ИИ

Гид для директора по развитию: с чего начать разговор про ИИ

“

Саммари: Разговор про ИИ в компании часто начинается неправильно — с вопроса «какую модель нам взять». Это ошибка номер один. Разбираем простыми словами, с чего начать на самом деле, если вы отвечаете за развитие компании, а не сами пишете код.

Главное правило: не начинайте с технологии

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

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

Почему 90% руководителей не видят результата

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

Как выстроить первые 90 дней

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

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

Именно такой порядок — сначала понятная задача и роли, потом код — лежит в основе того, как мы в AllSee начинаем любой проект. Сначала аудит конкретного процесса заказчика и подготовка плана, затем запуск MVP (минимально жизнеспособного продукта) на одном ограниченном участке — обычно в пределах двух месяцев, — и только после проверки результата разговор идёт о масштабировании на всю компанию. Подробнее — на allsee.team.

Почему прототип убеждает лучше презентации

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

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

Что изменилось в 2026 году и почему это важно директору

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

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

Что делать, если вы не технический специалист

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

Итог: с чего начать разговор завтра

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