Оптимизация без оптимизации: как сливаются данные в ИИ
Расскажу историю из своей практики. В прошлом году я работала продактом в российской компании, где руководитель решил оптимизировать рутину через ИИ.
Объёмы данных были совсем небольшие и на отдельного аналитика их явно не хватало, поэтому он просто брал куски клиентских баз и заливал их в обычные публичные модели. Задачи были стандартные: очисти, убери дубли, структурируй.
Модели почти никогда не отказывались обрабатывать данные, но результаты приходили кривые: пропадали столбцы, появлялись выдуманные значения, часть запроса просто игнорировалась. Руководитель часами переписывал промпты, злился, но качество оставалось так себе.
Он искренне считал, что это и есть оптимизация процессов. Мол, это же быстрее ручной правки, время экономим. Я с самого начала была против и несколько раз говорила об этом прямо.
Во-первых, современные модели даже без прямого отказа могут частично игнорировать инструкции или искажать результат, если чувствуют чувствительные данные. Это встроенный фильтр, который с каждым обновлением становится только жестче.
Во-вторых, каждый такой запрос означал, что клиентские данные уходили в чужую инфраструктуру. В России это особенно болезненно для бизнеса: по 152-ФЗ даже утечка нескольких тысяч записей легко тянет на штраф от 3 до 5 миллионов рублей для юрлица. А если данные чувствительные, то суммы еще выше (плюс возможные иски от клиентов и репутационные потери).
А многие до сих пор думают «а чё такого, нас не коснётся».
Даже если провайдер пишет, что не использует ваши чаты для обучения, полной гарантии нет. Информация остаётся в логах, кэшах и может потом всплыть где угодно.
Особенно раздражало, что это вообще не было оптимизацией процессов. Настоящая оптимизация должна убирать рутину, а не создавать новую.
А получалось так: выгрузить базу – написать длинный промпт – получить полуправильный результат – вручную всё проверить и допилить – повторить. Времени уходило больше, чем при обычной обработке, только добавлялся реальный риск утечки + ачивка, что компания стала технологичной.
Настоящая оптимизация через AI выглядит по-другому. Это закрытый контур: приватные модели внутри компании, автоматические пайплайны, маскирование данных и RAG на своих датасетах. Тогда нейросети реально ускоряют работу, а не превращает ее в условно полезную игрушку для собственной отчетности о причастности к современным достижениям.
Публичные модели — это отличный инструмент для открытых задач. Но когда речь идет о клиентских данных, лучше сто раз подумать.
А в ваших компаниях был (не)успешный опыт такой оптимизации процессов? :)
#Кибербезопасность #ИИ #LLM #152ФЗ #УтечкаДанных #Продакт #ОптимизацияПроцессов #кейс #опыт
· 20.04
у меня клиент недавно именно так и делал - гпт таблицы с именами и суммами. когда объяснил про 152-фз и логи - дошло. проблема что ллмки отвечают "обработано" и никакой ошибки не видно. внутренний контур с локальной моделью это правильная история, но у малого бизнеса нет ресурса это поднять
ответить
коммент удалён
· 21.04
малому бизнесу чаще всего это и не нужно, достаточно джиры и срм для прозрачности и автоматизации, но этот повальный дроч на ии повсюду (с незнанием и нежеланием лезть в нюансы и узкие места) меня просто убивает
ответить
ответ удалён