Провалы проектов в сфере ИИ часто связаны с культурой, а не с технологиями

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

Внутренние проекты, которые сталкиваются с трудностями, как правило, имеют общие проблемы. Например, инженерные команды создают модели, которыми продакт-менеджеры не умеют пользоваться. Дата-сайентисты создают прототипы, которые операционным командам трудно поддерживать. А приложения на базе ИИ остаются неиспользованными, потому что люди, для которых они создавались, не участвовали в определении того, что на самом деле означает «полезный».

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

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

Расширение грамотности в сфере ИИ за пределы инженерии

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

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

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

Установление чётких правил автономности ИИ

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

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

Эти правила должны включать три элемента: проверяемость (можете ли вы проследить, как ИИ пришел к своему решению?), воспроизводимость (можете ли вы воссоздать путь принятия решения?) и наблюдаемость (могут ли команды следить за поведением ИИ в режиме реального времени?). Без такой структуры вы либо замедлите работу до такой степени, что ИИ перестанет давать преимущества, либо создадите системы, принимающие решения, которые никто не может объяснить или контролировать.

Создание межфункциональных руководств (плейбуков)

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

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

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

Движение вперед

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

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

Ади Полак — директор по продвижению технологий и проектированию опыта разработчиков в Confluent.

Добро пожаловать в сообщество VentureBeat!

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

Читайте далее в рамках нашей программы гостевых постов и ознакомьтесь с нашими руководствами, если вы хотите написать собственную статью!