ИИ-риски в дипломе: проектирование систем с учётом требований безопасности
В марте 2026 года Министерство обороны США официально назвало Anthropic «неприемлемым риском для национальной безопасности» из-за «красных линий» — возможностей компании отключать свою технологию во время боевых операций. Для студентов ИТ-направлений это не просто новость из мира корпоративной этики, а маркер смены парадигмы: заказчики всё чаще требуют, чтобы система не только корректно работала, но и гарантированно подчинялась владельцу инфраструктуры в критических сценариях. В дипломной работе это превращается в конкретные требования к архитектуре, тестированию и документации. Ниже — как превратить этот кейс в сильный раздел ВКР и защитить проект с минимумом вопросов.
Типичные ошибки, которые ставят под угрозу защиту
2. Игнорирование требований ГОСТ 34.602-89. Если в проектной части не оформлено техническое задание по ГОСТу, а только «примерное ТЗ» в произвольной форме, комиссия справедливо занижает оценку. Особенно когда речь идёт о государственных или оборонных заказчиках — это как раз кейс из статьи.
3. Отсутствие метрик эффективности. «Повысили безопасность» — на сколько? Без чисел в виде RTO, RPO, процента перехваченных атак или времени реакции (RRT) результат не защитим. Нужны измеримые показатели до и после внедрения.
Три актуальные темы ВКР на основе кейса
Тема 1: Разработка модуля контроля «красных линий» для ИИ-сервиса
Актуальность: статья показывает, что крупные заказчики готовы отказаться от ИИ, если он сохраняет автономию в критических процессах. Ваш модуль может обеспечивать локальный «стоп-кран» без доступа к вендору.
Цель: спроектировать и реализовать программный модуль, который блокирует действие ИИ-системы при нарушении заранее заданных политик.
Задачи:
- Проанализировать архитектуру ИИ-системы и выделить точки управления.
- Определить политики «красных линий» в терминах бизнес-правил.
- Разработать алгоритм мониторинга и принудительного отключения (fail-safe и fail-secure).
- Провести нагрузочное тестирование и измерить задержку срабатывания.
Структура: Глава 1 — обзор ИИ-рисков и нормативки (ISO/IEC 25010, ГОСТ Р 59202-2020). Глава 2 — проектирование модуля: схемы компонентов, UML-диаграммы, описание интеграции через Kubernetes. Глава 3 — тестирование, оценка производительности, экономическое обоснование.
Тема 2: Оценка безопасности ИИ-системы по стандарту ISO/IEC 25010
Актуальность: отказ DoD от Anthropic показывает, что оценка безопасности до внедрения — ключевой этап. Ваша работа может стать методикой такой оценки.
Цель: разработать методику проверки ИИ-системы на соответствие характеристикам безопасности ISO/IEC 25010 с учётом специфики автономных решений.
Задачи: выделить показатели безопасности для ИИ, разработать чек-лист и процедуру испытаний, применить к прототипу, сформировать отчёт.
Структура: Глава 1 — анализ стандарта и его применение к ИИ. Глава 2 — разработка методики и прототипа тестового стенда. Глава 3 — результаты испытаний, метрики, рекомендации.
Тема 3: Проектирование отказоустойчивой инфраструктуры для ИИ-сервиса с обеспечением RTO/RPO
Актуальность: «красные линии» в статье касаются не только программной логики, но и непрерывности операций. Если ИИ может быть отключён, нужно резервирование и быстрая активация альтернатив.
Цель: разработать архитектуру, которая обеспечивает заданные RTO (время восстановления) и RPO (допустимая потеря данных) при срабатывании ограничений.
Задачи: определить требования к доступности, выбрать стратегию резервирования (active-passive Kubernetes-кластеры, мультиоблако), настроить мониторинг OpenTelemetry, провести аварийные учения.
Структура: Глава 1 — анализ рисков, расчёт целевых RTO/RPO. Глава 2 — проектирование инфраструктуры, CI/CD-пайплайны для быстрого развертывания. Глава 3 — тестирование отказоустойчивости, замеры метрик.
Аналитическая глава: как обосновать архитектуру с учётом ограничений
В аналитической части диплома обычно сравнивают существующие решения. Новость о Anthropic позволяет построить сравнение по двум осям: уровень автономии и возможность внешнего управления. В таблице ниже — пример сравнения подходов, который можно перенести в ВКР с ссылкой на статью.
| Подход | Автономия ИИ | Управление оператором | Соответствие риску (кейс DoD) |
|---|---|---|---|
| Полное доверие вендору | Высокая (вплоть до отказа в работе) | Нет | Неприемлемо |
| Вендор + «красные линии» | Ограничена политикой вендора | Частичное | Рискованно |
| Локальный «стоп-кран» | Средняя | Полное при срабатывании | Приемлемо при тестах |
| Локальная модель без внешних зависимостей | Полная автономность | Полное | Оптимально |
Эту таблицу легко превратить в часть обоснования выбора стека. Например, если вы разрабатываете модуль, интегрируемый в Kubernetes, вы можете аргументировать выбор подхода «локальный стоп-кран» тем, что он позволяет сохранить совместимость с внешними сервисами, но передаёт контроль над критическими операциями оператору. Не забудьте сослаться на инцидент из TechCrunch — это показывает, что вы учитываете реальную практику.
Проектная часть: схемы, алгоритмы, интеграция
В проектной главе должны быть диаграммы и описание архитектуры. На примере модуля «красных линий» можно использовать:
- UML-диаграмму вариантов использования (актёры: оператор, ИИ-сервис, модуль контроля).
- Диаграмму последовательности для сценария срабатывания ограничения.
- Схему развертывания на Kubernetes: поды сервиса, модуль контроля, кластер с OpenTelemetry для сбора метрик.
- Алгоритм проверки условий перед каждым действием ИИ (псевдокод).
if not violates_red_line(action, policy_table):
execute(action)
else:
stop_service()
notify_operator()
log_event_with_timestamp()Такая структура сразу показывает архитектурное мышление и умение декомпозировать задачу. Комиссия видит, что вы не просто кодили, а проектировали систему.
Тестирование, метрики и экономика внедрения
Раздел тестирования — самое слабое место большинства ВКР. В вашем случае нужно обязательно измерить:
- Время реакции модуля на нарушение (латентность остановки). Для критической инфраструктуры целевое значение — менее 100 мс.
- Нагрузочное тестирование: сколько одновременных запросов обрабатывает система до срабатывания «красной линии».
- Показатели RTO и RPO после принудительного отключения: как быстро можно восстановить работу и какие данные будут потеряны.
- Метрики наблюдаемости через OpenTelemetry: собирайте трассировки и метрики, чтобы связать задержки с конкретными компонентами.
Экономическую часть легко обосновать: сравните стоимость простоя (revenue loss + штрафы) с затратами на реализацию модуля и резервирование. Используйте данные из аналитики рынка или отчётов компаний — это добавит веса работе.
Практические выводы: чему вы научитесь
Вы прокачаете навыки, которые напрямую влияют на оффер после вуза:
- Проектирование отказоустойчивых систем с учётом человеческого контроля.
- Работа с требованиями ГОСТ 34.602-89 и ISO/IEC 25010 при оформлении документации.
- Построение CI/CD-пайплайнов в Kubernetes для автоматического развертывания.
- Настройка наблюдаемости через OpenTelemetry и интерпретация метрик.
- Умение превращать новостной кейс в техническое задание и архитектурное решение.
FAQ: частые вопросы студентов
Обязательно ли писать код в ВКР?
Для большинства направлений «Информационные системы» и «Программная инженерия» — да, нужен работающий прототип или его фрагменты. Но если ваша тема — анализ, проектирование или оценка, достаточно формальных моделей и диаграмм. Главное, чтобы выводы опирались на измеримые результаты, а не только на слова.
Где брать метрики для расчётов, если нет реальных данных?
Используйте открытые бенчмарки, датасеты (например, MLPerf), публичные отчёты вендоров. Или организуйте эксперимент в лабораторной среде: создайте тестовый стенд, снимите метрики самостоятельно. Это плюс к диплому.
Как оформить UML-диаграммы, если в вузе не требуют?
Даже если не требуют, добавьте 2–3 диаграммы — они показывают зрелость. Используйте PlantUML или draw.io, подпишите их в соответствии с ГОСТ 2.105-2019 (ЕСКД). Не перегружайте: достаточно диаграммы вариантов использования и последовательности.
Сложно ли интегрировать OpenTelemetry в учебный проект?
Нет, для Python/Go/Node.js есть готовые SDK. Поднимите docker-compose с Jaeger или Prometheus, подключите библиотеку — и у вас появятся реальные трейсы. Для ВКР это сильный «референс».
Чек-лист: что проверить перед сдачей
- В тексте есть ссылка на источник TechCrunch и он корректно оформлен.
- Каждая задача в работе соотносится с выводами и результатами.
- Есть минимум 2 структурные схемы (архитектурная и UML).
- Для всех метрик указаны единицы измерения и методика получения.
- Техническое задание оформлено по ГОСТ 34.602-89 и включает раздел «Требования к безопасности».
- В обосновании выбора упомянуты стандарты ISO/IEC 25010.
- Текст проверен на антиплагиат и не содержит «воды».
Источник: DOD says Anthropic’s ‘red lines’ make it an ‘unacceptable risk to national security’ (опубликовано 2026-03-18)