Ты наверняка видел эти бодрые отчёты в духе «мы внедрили ИИ». А потом проходит пару месяцев — и выясняется, что ИИ живёт в красивой презентации, а в реальной работе его обходят стороной, как сломанный принтер в офисе.
Обычно всё сводится к двум вечным темам: «модель не такая умная» и «данные плохие». Это бывает, да. Но если смотреть на реальные запуски внутри компаний, самый жирный источник проблем — не технологии. Он в людях и в том, как они между собой договариваются.
Инженеры сделали. Остальные не поняли зачем
Типичная картина: инженеры собрали умную штуку, а продакт не понимает куда её пристроить. Дата-сайентисты сделали прототип, а эксплуатация потом страдает — потому что это невозможно нормально поддерживать. Приложение стоит без дела, потому что тех, кому оно должно помогать, никто не спросил что вообще значит «полезно».
Корень проблемы простой: когда ИИ понимают только разработчики, остальным остаётся две роли — верить на слово или мешать. Иногда это одно и то же.
Продакт не может обсуждать компромиссы, которые не понимает. Дизайнер рисует интерфейс для возможностей, которые не может объяснить. Аналитик смотрит на ответы и не знает — это уже можно нести начальству или надо перепроверять руками.
Решение не в том, чтобы срочно сделать всех немного аналитиками данных — пожалей людей. Достаточно дать каждому свой минимум. Продакту — понимание, что реально можно получить из данных. Дизайнеру — где ИИ работает стабильно, а где начинается «творческий порыв». Аналитику — какие ответы требуют проверки, а каким можно доверять почти автоматически.
Когда у команды появляется общий словарь, ИИ перестаёт быть «тем, что делают в разработке».
Либо всё согласуют вручную, либо никто не знает что происходит
Вторая проблема — автономность. Компании кидает в две крайности.
Первая: каждое решение ИИ проходит через ручное согласование. Скорость падает, смысл автоматизации исчезает. Вторая: ИИ отпускают без правил — и он начинает принимать решения, которые потом никто не может объяснить, а уж тем более быстро остановить.
Нужна понятная рамка. Может ли он одобрять рутинные изменения сам? Может ли рекомендовать правки, но не применять? Может ли выкатывать изменения на тест, но не в рабочую систему?
И три вещи, которые при этом должны быть: можно ли понять почему он так решил, можно ли повторить это решение и получить тот же результат, можно ли следить за его поведением прямо в процессе — а не постфактум по руинам.
Без этого получается либо тормозной талончик «подождите согласования», либо чёрный ящик, который делает что-то важное — но непонятно что.
Каждый отдел придумал свои правила. И никто друг друга не понимает
Третья штука приземлённая. Когда каждый отдел выстраивает работу с ИИ по-своему — начинается бардак: разные стандарты, дублирование усилий, вечные споры «а у нас принято иначе».
Нужны общие короткие договорённости: как тестируем рекомендации ИИ перед тем как пускать в работу, что делаем если автоматическая выкладка упала, кто участвует когда отменяем решение ИИ, как собираем обратную связь чтобы он ошибался реже.
Лучше когда это пишут вместе — а не когда сверху спускают документ на сорок страниц «для исполнения с понедельника». Такой документ обычно сразу отправляется туда же, куда и сам ИИ-проект.
Цель в другом: чтобы у всех было одинаковое понимание, где ИИ помогает, где может ошибиться и что делать когда он внезапно решил проявить инициативу.
Точность модели — не главное
Компании, которые фанатично гонятся за точностью модели и игнорируют готовность организации, часто сами себе подставляют ножку.
Проблема обычно не в том, что ИИ недостаточно умный. Проблема в том, что его пытаются встроить в компанию, где люди между отделами общаются как разные мессенджеры: вроде все про сообщения, но совместимости ноль.
ИИ в таком месте не проваливается громко. Он просто тихо уходит в папку «интересные инициативы», где уже лежат CRM которую никто не заполняет и регламент который никто не читал.