Крупные клиенты SK hynix, по данным Reuters и 3DNews, готовы финансировать новые линии по выпуску памяти, чтобы быстрее получать нужные объёмы микросхем. На первый взгляд это история про заводы и цены, но для компаний, которые внедряют ИИ, она напрямую связана с защитой данных.

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

Что произошло у SK hynix

Южнокорейская SK hynix столкнулась с необычным спросом: заказчики предлагают оплатить строительство новых производственных линий и закупку оборудования. Взамен они хотят получить приоритетный доступ к памяти, выпущенной на этих мощностях.

Речь идёт о микросхемах для инфраструктуры ИИ и DRAM (от англ. dynamic random-access memory — динамическая память с произвольным доступом). По данным источников Reuters, свободных мощностей у SK hynix сейчас нет, поэтому компания не может просто выделить отдельную линию под одного клиента.

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

Почему дефицит железа бьёт по данным

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

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

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

Длинные контракты требуют проверки безопасности

По данным источников, производители памяти, включая SK hynix, Samsung Electronics и Micron, пытаются заключать долгосрочные соглашения с клиентами. В таких договорах обычно заранее фиксируют диапазон цен, потому что рынок памяти исторически сильно колеблется. Производители также могут брать от 30 до 40 % предоплаты.

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

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

ИИ-сервисы расширяют круг тех, кто видит информацию

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

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

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

Где бизнес чаще ошибается

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

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

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

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

Практический вывод: что проверить уже сейчас

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