Риски использования искусственного интеллекта: основные угрозы применения и внедрения ИИ

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

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

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

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

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

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

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

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

В документообороте неточность опаснее всего. Если ИИ готовит краткое содержание договора, одна неверная формулировка о штрафах или сроках уйдет дальше по маршруту согласования. В системе электронного документооборота (СЭД) такой пересказ выглядит как обычная справка, и мало кто захочет открывать исходный файл.

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

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

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

С расширением прав растет и опасность. Если ИИ-надстройка в СЭД видит кадровые, финансовые и клиентские документы, она может собрать из них сводку, которую потом кто-то выгрузит наружу. Сама по себе сводка безобидна, но она собирает в одном месте документы, которые раньше лежали в разных контурах доступа.

Защита начинается с классификации данных и заканчивается настройками сервиса. Список запрещенных данных, DLP-контроль и локальная (on-premise) модель для чувствительных задач работают лучше памятки «соблюдайте осторожность» и подробного инструктажа. В вопросах кибербезопасности дешевле один раз настроить доступ, чем разбирать последствия утечки.

У комплексной ИИ-системы появляется дополнительная уязвимость. Дело в том, что модель можно отравить (taint, это термин) данными. Из нее можно вытянуть сведения об обучающем наборе (jail breaking). ИИ-агента — обмануть инструкцией, спрятанной в документе или письме. Такую атаку называют prompt injection: сотрудник принимает текст за обычный договор, а для системы в нем записана команда. Через такой документ в контур может попасть и вредоносный код.

Утечки обходятся всё дороже. По данным IBM Cost of a Data Breach Report 2026, средняя глобальная стоимость утечки достигла 4,99 млн долларов, на 12% больше, чем годом ранее. Число атак, которые относят к ИИ-угрозам, выросло на 56%, а средняя стоимость атаки типа model inversion, при которой из модели извлекают данные обучения, оценивается в 6 млн долларов.

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

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

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

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

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

Чем сложнее модель, тем труднее восстановить логику решения. Сотрудник не всегда может объяснить клиенту, почему система ответила именно так, а в регулируемых сферах — в финансах, страховании, медицине, HR — такое объяснение может быть обязательным.

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

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

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

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

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

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

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

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

Почему вообще сотрудники могут быть против ИИ? Сопротивление редко бывает иррациональным. Люди видят, что новая система отнимает привычный контроль, заставляет учиться и может оценивать их работу. Если к этому добавляется отсутствие обучения, то инструмент саботируют не из вредности, а из осторожности.

Типичные возражения сотрудников:

• опасаются увольнения;
• не понимают технологию;
• не умеют пользоваться;
• считают, что ИИ бесполезен и по-старинке быстрее.

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

Слух о публичном сбое ИИ распространяется быстро. Чат-бот пообещал скидку, которой нет, генератор текста выдал оскорбительный ответ, голос руководителя подделали и попросили перевести деньги. В каждом случае достается именно бренду.

Отдельный сценарий — поддельные счета и письма от имени поставщика: их всё чаще генерируют, чтобы обойти обычную проверку контрагента.

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

Социальные угрозы кажутся далекими, пока компания не столкнется с ними в новостях, в отделе кадров или в переписке с клиентом.

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

Для компании это одновременно вопрос планирования и этики. Если автоматизация освобождает время, нужно решить, куда его направить; если часть ролей меняется, лучше заранее описать новые требования и предложить обучение. Публичное обещание «никого не сократим» звучит благородно, но реальность молжет оказаться иной.

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

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

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

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

Ответьте на такие вопросы:

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

Даже если ответа нет на половину вопросов, это еще не повод запрещать ИИ — просто не стоит сразу внедрять его на всю компанию. Пилот на ограниченном участке с ручной проверкой даст больше, чем большой проект, где никто не может объяснить, как считается результат.

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

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

В СЭД есть важная деталь: ИИ-помощник должен наследовать права доступа пользователя. Работа от имени администратора — плохая настройка по умолчанию. Если сотрудник не имеет права открыть приказ, система не должна пересказывать его содержание в ответе на запрос. Мысль очевидная, но именно из-за таких настроек экономия времени однажды приводит к утечке.

Человеческий контроль бывает разным. Для черновика достаточно выборочной проверки, а для платежа, кадрового решения или юридически значимого документа нужен второй сотрудник и явная подпись. Полезно фиксировать, кто и на каком основании утвердил результат. Проверяйте не только ответ, но и источник, на который он опирается.

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

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

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

Полезно сразу определить, кто вправе подключать новые сервисы. Если это делает любой сотрудник с корпоративной картой, политика останется текстом на стене.

Как ни странно, иногда лучший ответ — не внедрять. Это нормальное управленческое решение, если оно основано на фактах, а не на страхе перед технологией.

Отказаться имеет смысл в нескольких случаях.

• Данных недостаточно или они в таком состоянии, что модель будет учиться на мусоре.
• Нет измеримой цели, и разговор идет только о моде на технологию.
• В команде некому проверить результат.
• Закон прямо запрещает такую обработку или для нее нет правового основания.
• И наконец, сам процесс не описан: автоматизировать хаос — значит получить более быстрый хаос.

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

Начнем с истории, которая закончилась судом. В 2024 году трибунал по гражданским спорам Британской Колумбии рассматривал дело пассажира, которому бот сообщил неверные условия тарифа. Компания возражала: за ответы бота она не отвечает. Аргумент не сработал: чат-бот говорит от имени компании, значит, и отвечает компания.

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

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

Правовое регулирование ИИ пока не сложилось в единую систему. В России действует Национальная стратегия развития искусственного интеллекта до 2030 года, утвержденная указом президента № 490. Она задает приоритеты и принципы, но не заменяет отраслевые требования к ИИ-системам. В Евросоюзе профильное регулирование делит системы по уровню риска и предъявляет повышенные требования к наиболее опасным сценариям.

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

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

Какие риски использования ИИ наиболее опасны для бизнеса?

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

Можно ли полностью исключить риски при внедрении ИИ?

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

Кто несёт ответственность за ошибки искусственного интеллекта?

Компания, которая применяет систему и принимает решение. Вендор отвечает по договору за качество продукта и поддержку, но обязанности перед клиентом и регулятором остаются на компании. Поэтому внутренние правила, журналы и подпись человека под результатом — практическая защита, а не бюрократия.