ИИ в ИТ-департаменте – практический взгляд ИТ-директора
ИИ в ИТ-департаменте – где он реально полезен, а где мы просто играем в инновации? Своим мнением делится ИТ-директор «Системного софта» Сергей Кравчинский.
Про искусственный интеллект сейчас принято говорить примерно так, как лет пятнадцать назад говорили про облака: надо внедрять, а зачем — разберемся потом. У компании должна быть ИИ-стратегия, ИИ-платформа, ИИ-комитет и, желательно, красивая презентация с дорожной картой до 2030 года.
У меня к этому подходу есть простой вопрос: что конкретно мы собираемся улучшить?
Потому что искусственный интеллект сам по себе никакой бизнес-задачи не решает. Это инструмент. Иногда очень хороший, иногда — дорогая игрушка. Отличить одно от другого обычно можно только после того, как перестать обсуждать технологию и посмотреть на работу, которую люди делают каждый день.
ИТ-департамент для этого подходит почти идеально. У нас огромное количество текста, документации, заявок, логов, исходного кода, требований, протоколов и прочей информации, которую кто-то должен читать, понимать, классифицировать, сравнивать и пересказывать другому человеку. Раньше компьютер с такой работой справлялся плохо. Теперь — заметно лучше. И вот здесь начинается практический смысл ИИ.
Давайте сначала определимся, что именно мы экономим
Когда говорят об автоматизации, обычно считают серверы, лицензии, рабочие места и иногда деньги. Я бы добавил еще один ресурс: внимание квалифицированного сотрудника. На мой взгляд, сегодня это один из самых дорогих ресурсов внутри ИТ. Хороший разработчик стоит дорого. Хороший системный инженер стоит дорого. Хороший аналитик стоит дорого.
И при этом значительную часть рабочего дня эти люди занимаются вовсе не тем, за что мы им столько платим. Они ищут информацию, читают документы, разбирают чужой код, просматривают логи, переносят данные из одного текста в другой. Пишут резюме встречи, на которой сами только что сидели. То есть используют дорогой человеческий мозг в качестве довольно посредственного текстового процессора.
Вот это, на мой взгляд, и является одним из главных полей применения ИИ.
И при этом значительную часть рабочего дня эти люди занимаются вовсе не тем, за что мы им столько платим. Они ищут информацию, читают документы, разбирают чужой код, просматривают логи, переносят данные из одного текста в другой. Пишут резюме встречи, на которой сами только что сидели. То есть используют дорогой человеческий мозг в качестве довольно посредственного текстового процессора.
Вот это, на мой взгляд, и является одним из главных полей применения ИИ.
Service Desk: человек не обязан быть маршрутизатором
Типичная заявка пользователя может выглядеть примерно так: «После обновления опять не работает отчет». Отлично. Какой отчет? После какого обновления? Что значит «не работает»? И кто вообще должен этим заниматься? Дальше сотрудник Service Desk начинает заниматься лингвистической археологией: определяет систему, категорию, приоритет, ищет похожие обращения, иногда задает уточняющие вопросы, потом направляет заявку дальше.
Значительную часть этой работы языковая модель уже умеет делать вполне прилично. Она может разобрать текст, определить тему обращения, извлечь ключевые данные, предложить классификацию, найти похожие инциденты и подготовить первоначальный ответ. Нужно ли после этого увольнять первую линию поддержки? Нет. Это все равно что увольнять бухгалтера после покупки Excel.
Ценность в другом: специалист перестает тратить время на механическую работу и занимается теми случаями, где действительно требуется человек. Если за счет этого обработка каждой заявки сокращается хотя бы на несколько минут, дальше начинается скучная арифметика: несколько минут умножаем на несколько десятков тысяч заявок в год — и внезапно получаем вполне реальные деньги.
Мне вообще нравится считать эффект от ИИ именно так. Без магии.
Значительную часть этой работы языковая модель уже умеет делать вполне прилично. Она может разобрать текст, определить тему обращения, извлечь ключевые данные, предложить классификацию, найти похожие инциденты и подготовить первоначальный ответ. Нужно ли после этого увольнять первую линию поддержки? Нет. Это все равно что увольнять бухгалтера после покупки Excel.
Ценность в другом: специалист перестает тратить время на механическую работу и занимается теми случаями, где действительно требуется человек. Если за счет этого обработка каждой заявки сокращается хотя бы на несколько минут, дальше начинается скучная арифметика: несколько минут умножаем на несколько десятков тысяч заявок в год — и внезапно получаем вполне реальные деньги.
Мне вообще нравится считать эффект от ИИ именно так. Без магии.
Корпоративная база знаний: все уже написано, найти невозможно
Большинство компаний испытывают удивительный дефицит информации при огромном количестве документов. Инструкция существует, но никто не знает где. Регламент написан, но есть четыре версии. Архитектура описана — человеком, который три года назад уволился. Ответ на нужный вопрос точно где-то есть: в Confluence, в Service Desk, на сетевом диске или, что особенно удобно, в переписке сотрудника, который сейчас в отпуске.
Традиционный поиск работает хорошо только при одном условии: пользователь примерно знает, что ищет и как это называл автор документа. Это довольно смелое предположение.
LLM вместе с поиском по корпоративным источникам меняет сам способ работы со знаниями. Теперь можно задать нормальный человеческий вопрос. Система найдет релевантные документы, соберет необходимый контекст и подготовит ответ. При этом желательно показать источники, потому что способность языковых моделей уверенно нести чушь никуда не исчезла. Но принципиальное изменение уже произошло: раньше мы искали документ, теперь можем искать ответ.
Для крупного ИТ-департамента это, на мой взгляд, потенциально значительно важнее способности нейросети написать письмо начальнику или поздравление коллеге. Хотя именно с последнего почему-то началось массовое знакомство человечества с генеративным ИИ. Видимо, цивилизация расставила приоритеты.
Традиционный поиск работает хорошо только при одном условии: пользователь примерно знает, что ищет и как это называл автор документа. Это довольно смелое предположение.
LLM вместе с поиском по корпоративным источникам меняет сам способ работы со знаниями. Теперь можно задать нормальный человеческий вопрос. Система найдет релевантные документы, соберет необходимый контекст и подготовит ответ. При этом желательно показать источники, потому что способность языковых моделей уверенно нести чушь никуда не исчезла. Но принципиальное изменение уже произошло: раньше мы искали документ, теперь можем искать ответ.
Для крупного ИТ-департамента это, на мой взгляд, потенциально значительно важнее способности нейросети написать письмо начальнику или поздравление коллеге. Хотя именно с последнего почему-то началось массовое знакомство человечества с генеративным ИИ. Видимо, цивилизация расставила приоритеты.
Разработка: писать новый код — далеко не самая большая проблема
Самый очевидный сценарий применения ИИ в разработке — генерация кода. Это полезно. Но я бы не переоценивал именно этот эффект. В зрелой корпоративной системе разработчик очень много времени не пишет код. Он его читает. Почему этот метод существует? Кто его вызывает? Почему здесь три почти одинаковые функции? Что произойдет, если поменять эту таблицу? И какая прекрасная человеческая история привела к тому, что бизнес-логика расчета скидки находится именно здесь? На последний вопрос иногда не способен ответить вообще никто.
Особенно хорошо это ощущается в legacy-системах, которые разрабатывались десять лет, пережили несколько команд и теперь представляют собой цифровую археологию. Вот тут LLM действительно интересны: они умеют объяснять код, искать зависимости, помогать с документацией, генерировать тесты, проводить первичный code review, находить подозрительные конструкции.
Поэтому я бы сформулировал так: ИИ особенно полезен не тогда, когда надо написать еще 50 строк кода. Он полезен тогда, когда надо понять чужие 50 тысяч. И чем старше система, тем иногда выше ценность такого помощника.
Особенно хорошо это ощущается в legacy-системах, которые разрабатывались десять лет, пережили несколько команд и теперь представляют собой цифровую археологию. Вот тут LLM действительно интересны: они умеют объяснять код, искать зависимости, помогать с документацией, генерировать тесты, проводить первичный code review, находить подозрительные конструкции.
Поэтому я бы сформулировал так: ИИ особенно полезен не тогда, когда надо написать еще 50 строк кода. Он полезен тогда, когда надо понять чужие 50 тысяч. И чем старше система, тем иногда выше ценность такого помощника.
Аналитика и требования: прочитать всё и ничего не забыть
Практически любой ИТ-проект производит огромное количество текста еще до появления первой строчки кода: интервью, протоколы, требования, технические задания, комментарии, изменения требований, изменения изменений требований. И наконец — документ, который все согласовали, но каждый понял по-своему.
Здесь ИИ тоже довольно полезен. Он может сопоставить разные версии требований, найти противоречия, показать, какие вопросы остались без ответа, сформировать первоначальные тестовые сценарии, проверить, есть ли у требований измеримые критерии приемки. Последний пункт мне особенно нравится. Потому что, если критериев приемки нет, вопрос об использовании ИИ уже вторичен. Для начала неплохо бы понять, что именно мы собираемся сделать и как узнаем, что сделали.
ИИ здесь не заменяет хорошего аналитика. Он просто позволяет хорошему аналитику не тратить часы на работу, которую машина способна выполнить за минуты.
Здесь ИИ тоже довольно полезен. Он может сопоставить разные версии требований, найти противоречия, показать, какие вопросы остались без ответа, сформировать первоначальные тестовые сценарии, проверить, есть ли у требований измеримые критерии приемки. Последний пункт мне особенно нравится. Потому что, если критериев приемки нет, вопрос об использовании ИИ уже вторичен. Для начала неплохо бы понять, что именно мы собираемся сделать и как узнаем, что сделали.
ИИ здесь не заменяет хорошего аналитика. Он просто позволяет хорошему аналитику не тратить часы на работу, которую машина способна выполнить за минуты.
Эксплуатация: логи должен читать компьютер
Современная ИТ-инфраструктура генерирует огромное количество событий: системные журналы, мониторинг, сетевые события, логи приложений, события информационной безопасности. Машины прекрасно умеют всё это генерировать. Люди потом зачем-то должны это читать.
Классические средства мониторинга достаточно хорошо отвечают на вопрос: что произошло? ИИ может помочь со следующим вопросом: что все это вместе может означать? Например, собрать несколько событий в один контекст, найти похожий прошлый инцидент, подготовить первоначальную гипотезу и предложить последовательность диагностики.
Должен ли ИИ после этого самостоятельно чинить production? Я бы пока не торопился. Когда цена ошибки велика, пять минут инженера обычно стоят дешевле пяти часов аварии.
Поэтому разумная схема сегодня выглядит не как «автономный цифровой администратор», а как очень быстрый помощник живого администратора. И это уже достаточно ценно. Не обязательно сразу отдавать машине ключи от ЦОД, чтобы получить пользу от технологии.
Классические средства мониторинга достаточно хорошо отвечают на вопрос: что произошло? ИИ может помочь со следующим вопросом: что все это вместе может означать? Например, собрать несколько событий в один контекст, найти похожий прошлый инцидент, подготовить первоначальную гипотезу и предложить последовательность диагностики.
Должен ли ИИ после этого самостоятельно чинить production? Я бы пока не торопился. Когда цена ошибки велика, пять минут инженера обычно стоят дешевле пяти часов аварии.
Поэтому разумная схема сегодня выглядит не как «автономный цифровой администратор», а как очень быстрый помощник живого администратора. И это уже достаточно ценно. Не обязательно сразу отдавать машине ключи от ЦОД, чтобы получить пользу от технологии.
А потом выясняется, что CIO тоже можно автоматизировать
Это несколько обидный момент. ИТ-руководители любят обсуждать, чью работу автоматизируют следующей. Потом ИИ добирается до нас. Договоры, коммерческие предложения, бюджеты, протоколы, проектные отчеты, результаты аудитов, технические документы — все это приходится читать, сравнивать и сводить к нескольким выводам.
Языковые модели справляются с подобной работой прекрасно. Не принимают решение, но очень сильно сокращают расстояние от ста страниц информации до пяти фактов, на основании которых решение принимается.
И здесь мы снова возвращаемся к главному ресурсу: ИИ экономит не текст. Он экономит человеческое внимание. На мой взгляд, именно так и стоит считать его ценность.
Языковые модели справляются с подобной работой прекрасно. Не принимают решение, но очень сильно сокращают расстояние от ста страниц информации до пяти фактов, на основании которых решение принимается.
И здесь мы снова возвращаемся к главному ресурсу: ИИ экономит не текст. Он экономит человеческое внимание. На мой взгляд, именно так и стоит считать его ценность.
А теперь плохая новость: купить модель недостаточно
Первые эксперименты с ИИ создают опасную иллюзию простоты. Открыл чат, загрузил документ, получил ответ. Прекрасно.
Теперь попробуем сделать то же самое внутри компании — и сразу появляются вопросы. Какие документы этот сотрудник имеет право видеть? Где актуальная версия? Можно ли вообще передавать данные этой модели? Кто увидит историю запросов? Как подключить Service Desk? Как подключить CRM? Как подключить Git? Как ограничить расходы? Что делать, если завтра мы захотим использовать другую модель?
И вот здесь веселая демонстрация заканчивается и начинается нормальная корпоративная ИТ. Рабочая формула выглядит примерно так:
Теперь попробуем сделать то же самое внутри компании — и сразу появляются вопросы. Какие документы этот сотрудник имеет право видеть? Где актуальная версия? Можно ли вообще передавать данные этой модели? Кто увидит историю запросов? Как подключить Service Desk? Как подключить CRM? Как подключить Git? Как ограничить расходы? Что делать, если завтра мы захотим использовать другую модель?
И вот здесь веселая демонстрация заканчивается и начинается нормальная корпоративная ИТ. Рабочая формула выглядит примерно так:
ИИ = модель + корпоративные данные + интеграции + права доступа + аудит + контроль качества.
Модель здесь всего один элемент. Причем довольно легко заменяемый.
По мере роста количества ИИ-сценариев компания почти неизбежно приходит к необходимости общего инфраструктурного слоя: корпоративного LLM-шлюза, централизованного доступа к моделям, механизмов работы с внутренними данными, разграничения прав и интеграций с существующими системами. Вот тогда это становится не игрушкой отдельного энтузиаста, а частью корпоративной архитектуры.
По мере роста количества ИИ-сценариев компания почти неизбежно приходит к необходимости общего инфраструктурного слоя: корпоративного LLM-шлюза, централизованного доступа к моделям, механизмов работы с внутренними данными, разграничения прав и интеграций с существующими системами. Вот тогда это становится не игрушкой отдельного энтузиаста, а частью корпоративной архитектуры.
Есть три вещи, которые ИИ пока не отменил
Первая — ответственность. Модель может ошибаться. Иногда очень убедительно. Поэтому для критичных решений требуется либо проверка человеком, либо система, в которой ответ жестко привязан к контролируемым источникам.
Вторая — информационная безопасность. Если удобный публичный сервис позволяет сотруднику за две минуты решить задачу, на которую раньше уходил час, он, скорее всего, будет им пользоваться. Даже если политика ИБ говорит обратное. Запретить можно. Проконтролировать значительно сложнее. Поэтому нормальный ответ компании — не только запреты, а создание удобного корпоративного инструмента, которым можно пользоваться безопасно.
И третья проблема, пожалуй, самая неприятная: ИИ не исправляет плохие процессы. Если заявка путешествует между подразделениями две недели из-за отсутствия владельца процесса, автоматическая классификация заявки этого не исправит. Если проект не имеет понятных критериев приемки, модель не создаст их магическим образом. Если отчет никому не нужен, ИИ действительно сможет делать его быстрее. Но отчет от этого нужнее не станет. В худшем случае искусственный интеллект просто позволит выполнять плохой процесс быстрее и в большем масштабе.
Вторая — информационная безопасность. Если удобный публичный сервис позволяет сотруднику за две минуты решить задачу, на которую раньше уходил час, он, скорее всего, будет им пользоваться. Даже если политика ИБ говорит обратное. Запретить можно. Проконтролировать значительно сложнее. Поэтому нормальный ответ компании — не только запреты, а создание удобного корпоративного инструмента, которым можно пользоваться безопасно.
И третья проблема, пожалуй, самая неприятная: ИИ не исправляет плохие процессы. Если заявка путешествует между подразделениями две недели из-за отсутствия владельца процесса, автоматическая классификация заявки этого не исправит. Если проект не имеет понятных критериев приемки, модель не создаст их магическим образом. Если отчет никому не нужен, ИИ действительно сможет делать его быстрее. Но отчет от этого нужнее не станет. В худшем случае искусственный интеллект просто позволит выполнять плохой процесс быстрее и в большем масштабе.
Поэтому начинать нужно не с ИИ
Я бы вообще не начинал с вопроса: «Где мы можем использовать искусственный интеллект?» Он слишком широкий и почти гарантированно приводит к презентации. Лучший вопрос звучит так: на что мои сотрудники тратят много квалифицированного времени, хотя большая часть этой работы состоит из поиска, чтения, классификации, сравнения или преобразования информации?
Дальше берем несколько таких процессов, считаем текущее время, автоматизируем часть работы и снова считаем. Если стало быстрее, дешевле или качественнее — оставляем. Если нет — закрываем эксперимент. Без необходимости срочно объявлять его стратегической инициативой.
Когда-то компании обсуждали, где им применять базы данных. Сегодня такой вопрос звучит довольно странно. Возможно, с ИИ будет то же самое: он просто станет еще одним слоем корпоративной автоматизации.
Поэтому для ИТ-директора сейчас важнее не угадать победителя гонки языковых моделей. Они еще много раз поменяются. Гораздо важнее научиться замечать работу, которую наши дорогие специалисты до сих пор делают вручную только потому, что несколько лет назад компьютер еще не умел ее делать.
Теперь умеет. И вот это уже повод что-то менять.
Дальше берем несколько таких процессов, считаем текущее время, автоматизируем часть работы и снова считаем. Если стало быстрее, дешевле или качественнее — оставляем. Если нет — закрываем эксперимент. Без необходимости срочно объявлять его стратегической инициативой.
Когда-то компании обсуждали, где им применять базы данных. Сегодня такой вопрос звучит довольно странно. Возможно, с ИИ будет то же самое: он просто станет еще одним слоем корпоративной автоматизации.
Поэтому для ИТ-директора сейчас важнее не угадать победителя гонки языковых моделей. Они еще много раз поменяются. Гораздо важнее научиться замечать работу, которую наши дорогие специалисты до сих пор делают вручную только потому, что несколько лет назад компьютер еще не умел ее делать.
Теперь умеет. И вот это уже повод что-то менять.
Источник РБК Компании