Дилемма ИТ-команд: действительно ли домен .ai означает AI-трафик?

Дилемма ИТ-команд: действительно ли домен .ai означает AI-трафик?

Наличие .ai в адресе пакета не доказывает, что пакет отправляет запросы к модели искусственного интеллекта в сети; это могут подтвердить только журнал запросов, целевая конечная точка и передаваемые данные.

Это различие может казаться небольшим, но для корпоративного ИТ оно имеет весьма серьёзные последствия. В доменном имени учебной платформы может присутствовать «ai», в её описании может упоминаться искусственный интеллект, а сама платформа может использовать искусственный интеллект в отдельных рабочих процессах. Ничто из этого не означает, что рассматриваемое SCORM-обучение взаимодействует с AI-сервисом.

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

Главный вопрос для ИТ-команд должен быть таким:

Не «Как называется этот контент?», а «На какой адрес браузер отправляет какие данные и с какой целью?»

Такой подход иногда кажется более трудоёмким. Но безопасность в этом и состоит: изучать не ярлыки, а поведение. По надписи «набор для химии» на коробке нельзя узнать, что находится внутри. Люди любят доверять этикеткам коробок; сетевые пакеты к этой привычке относятся без особого уважения.

Доменное имя — не классификация технологии

Суффикс в доменном имени не является техническим заявлением. .ai, .com, .org или любой другой суффикс не объясняет, с какими сервисами взаимодействует приложение, где обрабатываются данные и какую информацию оно получает от клиента.

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

В Nextrain искусственный интеллект может использоваться для создания обучения, структурирования контента, генерации вопросов, проектирования учебных траекторий и подготовки отчётов. Кроме того, можно импортировать пакеты SCORM 1.2 и SCORM 2004; то есть контент, ранее созданный организацией или полученный из другого источника, можно управлять в единой среде.

Это разные ситуации:

Рассматриваемая ситуация Вопрос ИТ-команды Ожидаемое доказательство
Статическое SCORM-обучение Выполняет ли пакет вызов сервиса за пределами LMS? Сетевые журналы браузера, записи DNS, журналы proxy
Взаимодействие SCORM-LMS Какие учебные данные пакет записывает в LMS? Вызовы SCORM API, записи о завершении и баллах
Взаимодействие с поддержкой AI Действительно ли вызывается AI-функция? URL запроса, тело запроса, поток ответа
Использование внешнего контента Откуда загружаются видео, шрифты, аналитика или медиа? Сторонние домены, CDN и медиавызовы
Проверка защиты данных Есть ли в запросе персональные данные или конфиденциальный контент? Анализ payload, маскирование и журналы доступа

Возможно, важнейшая строка таблицы — третья: Действительно ли вызывается AI-функция? Наличие AI-возможности в продукте не означает, что её использует каждый курс, каждый пользователь и каждый сеанс.

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

Что на самом деле делает SCORM-пакет?

SCORM — это стандарт, позволяющий обучению взаимодействовать с LMS. Внутри пакета обычно есть файлы контента, манифест контента и JavaScript, управляющий ходом обучения. Когда пакет открывается в LMS, контент может через браузер обращаться к стандартному SCORM API и передавать такие сведения:

Различия между SCORM 1.2 и SCORM 2004 могут быть важны, однако основной вопрос при проверке AI-трафика не меняется: Куда пакет взаимодействует помимо стандартных учебных записей LMS?

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

Но между «может» и «делает» разница величиной с сетевой шлюз.

Сам стандарт SCORM не требует вызовов искусственного интеллекта. Стандарт касается сохранения статуса обучения [SCORM 1.2, 2001; SCORM 2004, 2004]. Поэтому автоматически наклеивать на любой SCORM-пакет ярлык «AI-риск» — это не техническая классификация, а поспешный родственник осторожности.

Куда ИТ-команде следует смотреть в первую очередь?

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

1. Распакуйте содержимое и прочитайте манифест

SCORM-пакет обычно представляет собой сжатый архив. Проверку можно начать со следующих файлов:

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

В JavaScript-файлах следует особенно искать следующие выражения:

fetch(
XMLHttpRequest
WebSocket
EventSource
sendBeacon
axios
https://
wss://

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

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

2. Наблюдайте реальные сетевые записи в браузере

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

Затем в сетевых записях браузера следует задать такие вопросы:

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

3. Читайте вместе записи DNS, proxy и межсетевого экрана

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

Доступ контента только к одобренным доменам — это объяснимое и ограниченное сетевое поведение. Вызовы новых или неизвестных конечных точек необходимо исследовать. Критерием здесь не должен быть вопрос «Похоже ли название на AI?». Некоторые AI-сервисы могут использовать обычные на вид домены, а некоторые полностью не связанные с AI платформы могут иметь суффикс .ai.

С точки зрения сети суффиксы — это декорация, а записи маршрутизации — доказательство.

Какие признаки важны для отличия AI-трафика?

AI-трафик не имеет единой технической сигнатуры. Однако некоторые признаки могут направить проверку в нужное место.

Во взаимодействии с генеративным AI часто наблюдается следующее:

Напротив, следующие действия сами по себе не являются AI-вызовом:

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

Здесь мне вспоминается настойчивое различие, которое Kalde проводит при написании сценариев: в истории результат меняет не то, перед какой дверью стоит персонаж, а какой выбор он делает. В сетевой проверке доменное имя — это дверь, а запрос — выбор. Решение по безопасности должно основываться на втором.

Почему политика «заблокировать всё» недостаточна?

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

Однако блокировка всего в одной категории может сделать незаметными две разные издержки:

  1. Реальные риски могут остаться незамеченными.
    Сервис без суффикса .ai также может выводить данные за пределы организации. Фильтрация доменных имён не заменяет контроль потоков данных.

  2. Безвредные или необходимые учебные процессы могут быть прерваны.
    Если SCORM-контент, не выполняющий AI-вызовов, блокируется только из-за ассоциации с доменным именем, сотрудники не смогут получить доступ к обучению, а ИТ не сможет ясно объяснить, какое техническое поведение было заблокировано.

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

Лучшая политика до категорического запрета проводит следующие различия:

Это не ослабление безопасности. Напротив, это делает контроль более точным.

Практический контрольный список для проверки SCORM и AI

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

Следующий контрольный список можно использовать для первичной оценки:

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

Вывод: брошюра описывает намерение, сетевое поведение доказывает

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

Проверка ИТ-команды должна проходить на трёх уровнях:

  1. Что содержит пакет?
    Манифест, JavaScript, внешние ресурсы и конфигурации.

  2. Что делает браузер?
    Сетевые запросы, цели и тела данных в реальном пользовательском сценарии.

  3. Что это означает для организации?
    GDPR, классификация данных, разрешённые конечные точки, контроль доступа и операционное влияние.

Система с AI-функцией и система, генерирующая AI-трафик в каждом сеансе, — не одно и то же. Домен .ai также не является доказательством AI-вызова. Доказательство — это запрос, существующий в сети, имеющий временную метку, видимую цель и полезную нагрузку.

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

Примечания

  1. SCORM 1.2, 2001. Стандартная техническая модель взаимодействия учебного контента с LMS.
  2. SCORM 2004, 2004. Расширенный стандарт SCORM, включающий правила последовательности и навигации.