Риски ИИ и безопасность: что учитывать бизнесу

ИИ в бизнесе: риски, которые недооценивают

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

Ключевая мысль: ИИ ошибается иначе, чем человек. Человек ошибается точечно и устаёт, модель ошибается массово и уверенно — сотни документов за секунды. Поэтому для бизнеса важна не «умность» модели, а контур безопасности вокруг неё: кто имеет доступ, какие данные уходят наружу, что происходит при ошибке и как откатить решение. Разберём риски по порядку — без паники, но с конкретикой.

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

Утечка данных: самый дорогой сценарий

Первый и самый очевидный риск — конфиденциальные данные уходят за пределы компании. Сценарий из практики: сотрудник вставляет в публичный чат-бот договор с клиентом, чтобы «сократить» текст, а сервис использует этот текст для дообучения. Формально данные уже не контролируются компанией. Второй сценарий: отдел продаж подключает к CRM сторонний ИИ-плагин без согласования с ИТ — и вся клиентская база, включая телефоны и суммы сделок, начинает передаваться третьей стороне.

Какие данные утекают чаще всего:

• персональные данные клиентов — имя, телефон, email, паспортные данные;
• коммерческая тайна — прайсы, условия договоров, маржа, планы;
• внутренняя переписка и документы — протоколы, отчёты, черновики;
• исходный код и техническая документация.

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

Отдельный канал — «теневой ИИ»: сотрудник обрабатывает рабочие документы через личный аккаунт в публичном сервисе. Компания не видит эти запросы, а при увольнении сотрудника данные остаются в чужом аккаунте. Поэтому запрет личных аккаунтов для рабочих данных — не бюрократия, а способ вернуть контроль.

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

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

Ошибки моделей и галлюцинации

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

Типичные сценарии, которые мы видим у клиентов:

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

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

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

Снизить частоту ошибок помогают три приёма. Первый — ограничить модель её областью: давать только те данные, которые нужны для задачи, и явно запрещать выход за рамки. Второй — retrieval-augmented generation (RAG): модель отвечает по вашему корпусу документов, а не «по памяти», что резко сокращает выдумывание. Третий — настроить порог уверенности: если модель не уверена, она должна переадресовать вопрос человеку, а не додумывать. Эти механики — часть стандартного контура, который мы закладываем при проектировании ИИ-решений под бизнес.

Зависимость от одного сервиса

Третий риск — vendor lock-in, или «привязка к вендору». Компания встраивает конкретный ИИ-сервис глубоко в процессы: в CRM, в документооборот, в поддержку. Через год вендор меняет тарифы, уходит с рынка, меняет условия обработки данных или блокирует аккаунт — и бизнес остаётся без ключевой функции.

Зависимость проявляется на нескольких уровнях:

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

Снизить зависимость можно ещё на этапе выбора. Предпочтите сервисы с открытым или стандартным API и возможностью экспорта данных в распространённом формате. Держите «план Б»: заранее продумайте, на что переключитесь, если вендор исчезнет. Для критичных задач рассмотрите self-hosted модели — они требуют компетенций, но данные и доступ остаются у вас. Если своих специалистов не хватает, задача отлично решается через ИТ-аутсорсинг: поддержку и развёртывание моделей берёт на себя подрядчик, а контроль над данными и контрактом остаётся у вас.

Договор с вендором: что зафиксировать

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

На что обратить внимание:

• где хранятся и обрабатываются данные — юрисдикция серверов и их расположение;
• используются ли ваши данные для дообучения модели — должно быть явное «нет» или явное «да» с вашим согласием;
• что происходит с данными после расторжения — срок и подтверждение удаления;
• кто отвечает за результат модели — есть ли гарантии точности или хотя бы SLA на доступность;
• порядок уведомления об инцидентах — за сколько вендор сообщает об утечке;
• совместимость с 152-ФЗ и другими применимыми требованиями по персональным данным.

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

Пять вопросов, которые стоит задать вендору до подписания:

• Где физически находятся серверы и куда передаются данные при обработке?
• Используются ли наши запросы для обучения модели — сейчас и в будущем?
• Кто внутри вашей компании и на каких условиях может получить доступ к нашим данным?
• Как быстро вы сообщите об инциденте и что предпримете?
• В каком формате и за какой срок мы сможем выгрузить все данные при уходе?

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

Регуляторные риски: 152-ФЗ и персональные данные

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

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

Отдельная зона — обезличенные данные. Если перед отправкой в модель убрать имя, телефон и email, требования к защите снижаются. Но обезличивание должно быть необратимым: «заменили имя на ID» не всегда достаточно. Это ориентир, а не консультация — состав документов подскажет юрист.

Меры защиты: чек-лист внедрения

Соберём разрозненные меры в рабочий чек-лист. Он делится на четыре блока: политика, доступ, данные и контроль. Каждая мера ниже отвечает на конкретный риск из предыдущих разделов.

Пять правил, которые закрывают большинство инцидентов ещё до их появления:

1. Никакие персональные данные и коммерческая тайна не попадают в публичные ИИ-сервисы — только в согласованные корпоративные.
2. Каждый ИИ-инструмент в компании зарегистрирован: кто подключил, какие данные передаёт, на каком основании.
3. Любой ответ модели, влияющий на клиента или документ, подтверждается человеком.
4. Есть резервный план на случай отключения сервиса: данные экспортируются, альтернатива известна.
5. Раз в квартал проводится ревизия: какие сервисы ещё используются, какие данные куда уходят.

Для компаний без собственного ИТ-отдела реализовать такой контур сложно — и здесь работает ИТ-аутсорсинг: подрядчик настраивает доступы, ведёт реестр и следит за обновлениями политик вендоров, пока команда занимается бизнесом.

Чек-лист безопасности перед запуском

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

1. Составлен реестр данных, которые попадут в модель, и для каждой категории определена допустимость передачи.
2. Опубликован список разрешённых ИИ-инструментов, остальные запрещены внутренней политикой.
3. В договоре зафиксированы запрет дообучения и порядок удаления данных после расторжения.
4. Настроен ролевой доступ: отдельные ключи API, минимум прав, журналирование запросов.
5. Модель ограничена своей областью, для фактов подключён RAG по вашим документам.
6. Определено правило человеческого контроля для ответов, влияющих на клиента или документ.
7. Протестирован аварийный выход: данные выгружаются, запасной сервис готов.
8. Сотрудники обучены: что можно и нельзя загружать, куда сообщать о сбое.
9. Назначен ответственный за инциденты и порядок быстрого отключения сервиса.
10. Поставлена в календарь ежеквартальная ревизия подключений и данных.

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

Типичные ошибки и оценка рисков до старта

Риски редко реализуются «вдруг» — обычно им предшествуют типовые ошибки на старте. Вот самые частые, которые мы встречаем при аудите чужих внедрений:

• «Попробуем на боевых данных сразу». Пилот запускают на реальной клиентской базе без обезличивания — и любая ошибка модели бьёт по живым клиентам.
• Один суперпользователь без контроля. Вся компания зависит от человека, который настроил ИИ и ушёл в отпуск или уволился — знания и доступы не задокументированы.
• Подключение «теневого» ИИ. Отделы ставят плагины и сервисы мимо ИТ — реестра нет, договора нет, утечка обнаруживается случайно.
• Вера в автономность. Модель пускают в процесс без человеческого контроля, потому что «она же умная» — и получают массовую ошибку.
• Экономия на договоре. Подписывают бесплатную оферту публичного сервиса для корпоративных данных, чтобы не платить за корпоративный тариф.
• Игнорирование выхода. Не продумывают, как отключить сервис и куда перенести данные, — в итоге платят за неиспользуемое и боятся уйти.

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

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

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

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

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

Шаг 3. Выбор конфигурации. По результатам первых двух шагов выбирайте инструмент. Публичный сервис годится для нечувствительных задач без влияния на клиента. Корпоративный тариф с договором — для персональных данных и процессов с клиентами. Self-hosted модель — для коммерческой тайны и критичных процессов, где данные не должны покидать контур компании. Такая привязка конфигурации к уровню риска — самый дешёвый способ избежать и утечек, и переплат.

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

Частые вопросы

Полезно на сайте: внедрение ИИ в бизнес, ИТ-аутсорсинг, цены, отзывы клиентов.