ИИ-подсистема с явным согласием пользователя: архитектура и темы ВКР
В Ubuntu Linux 26.04 компания Canonical поступила неожиданно для рынка: ИИ-функции не включаются «по умолчанию», а отдаются пользователю как набор опций — локальная модель, облачный провайдер или полный отказ. ZDNet называет такой подход освежающим на фоне стратегии Microsoft, где ассистент встраивается в систему всё глубже. Для выпускника ИТ-направления это не просто новость, а готовый каркас дипломной работы: вместо банального «прикрутить LLM к чату» появляется задача спроектировать подсистему с политикой согласия, маршрутизацией запросов, журналом аудита и измеримыми метриками. Ниже — как превратить этот тренд в защищаемую ВКР.
Темы ВКР, которые вырастают из этой новости
Тема 1. Подсистема локального ИИ-ассистента в ОС с политикой явного согласия
Актуальность. Релиз Ubuntu 26.04 фиксирует смену парадигмы: рынок идёт от «ИИ везде по умолчанию» к управляемому ИИ. Одновременно требования 152-ФЗ и GDPR заставляют минимизировать передачу персональных данных внешним провайдерам. Ваша работа попадает ровно в этот разрыв между удобством и комплаенсом.
Цель. Разработать архитектуру и прототип подсистемы, в которой каждая ИИ-функция активируется пользователем отдельно и исполняется по выбранному маршруту — локально или в облаке.
Задачи:
- проанализировать подходы Canonical и Microsoft, выделить точку контроля над ИИ в каждом;
- построить модель угроз и матрицу согласий (какая функция — какие данные — какой маршрут);
- спроектировать шлюз маршрутизации запросов и журнал аудита;
- реализовать прототип на локальном рантайме и снять метрики задержки, потребления памяти и доли облачных запросов.
Структура. Глава 1 — анализ решений и стандартов (ISO/IEC 25010 как рамка качества, ГОСТ 34.602-89 для ТЗ). Глава 2 — проектирование: контекстная диаграмма, диаграмма компонентов, схема потоков данных, обоснование стека. Глава 3 — прототип, нагрузочное тестирование, расчёт стоимости владения.
Тема 2. Сравнительная оценка локального инференса и облачных API для корпоративного ассистента
Актуальность. Статья прямо подталкивает к вопросу: а сколько стоит «свобода выбора»? Canonical даёт опцию, но экономику маршрута должен считать инженер.
Цель. Построить методику выбора между локальной моделью и облачным API по совокупности критериев: приватность, задержка, стоимость, качество ответа.
Задачи: сформировать тестовый набор запросов; замерить p50/p95 задержки и пропускную способность на локальном рантайме; посчитать стоимость 1000 запросов у двух-трёх провайдеров; оценить качество ответов по единой шкале; свести результаты в матрицу решений.
Структура. Глава 1 — обзор рынка локальных моделей и облачных API. Глава 2 — методика эксперимента и стенд. Глава 3 — результаты, чувствительность выводов к нагрузке, экономическое обоснование.
Тема 3. Шлюз ИИ-запросов с фильтрацией данных и журналированием для защиты персональных данных
Актуальность. Как только ИИ-функция становится опциональной, исчезает единая точка контроля — и её нужно строить самому. Это ровно та инженерная задача, которую в статье решили на уровне дистрибутива.
Цель. Спроектировать промежуточный слой, который проверяет согласие, фильтрует чувствительные данные и пишет неизменяемый журнал обращений.
Задачи: описать модель данных, попадающих в промпт; реализовать правила DLP (регулярные выражения, словари, детекторы); обеспечить целостность журнала; провести пентест собственного прототипа на утечку.
Структура. Глава 1 — правовые требования и модели угроз. Глава 2 — архитектура шлюза, схемы обработки запроса. Глава 3 — тестирование на наборе «рискованных» промптов, оценка ложных срабатываний.
Смежные формулировки, если хочется уйти в инфраструктуру: «Мониторинг ИИ-подсистемы на OpenTelemetry: метрики качества и стоимости» и «Развёртывание локального инференса в Kubernetes: планирование ресурсов GPU».
Аналитическая глава: как превратить новость в обоснование выбора
Первая глава большинства ВКР тонет в пересказе учебников. Здесь есть шанс сделать её живой: сравнить три реальные стратегии интеграции ИИ в операционную систему и показать, почему вы выбрали четвёртую — свою.
| Критерий | Opt-in (Ubuntu 26.04) | ИИ по умолчанию | Полное отключение |
|---|---|---|---|
| Точка контроля | Пользователь и администратор | Вендор | Пользователь |
| Маршрут запроса | Локальная модель или облако по выбору | Как правило, облако | Запросов нет |
| Приватность | Высокая при локальном маршруте | Зависит от политики провайдера | Максимальная |
| Стоимость владения | Железо и электроэнергия | Подписка | Нулевая |
| Что анализировать в ВКР | Политика согласия, шлюз | Риски и комплаенс | Базовая линия для сравнения |
Обоснование стека без вкусовщины
Любой выбор технологии в дипломе должен опираться на критерий, а не на «мне нравится». Для маршрутизации ИИ-запросов рабочий набор критериев — приватность, задержка, качество ответа, требования к железу и предсказуемость затрат.
| Критерий | Локальный инференс (Ollama, llama.cpp) | Облачный API |
|---|---|---|
| Данные покидают устройство | Нет | Да |
| Задержка первого токена | Зависит от GPU/CPU, стабильна | Зависит от сети, плавает |
| Качество на сложных задачах | Среднее для компактных моделей | Как правило, выше |
| Ресурсы | 8–16 ГБ ОЗУ или VRAM | Только сеть |
| Стоимость | Постоянная (железо, энергия) | Переменная, растёт с нагрузкой |
| Точка отказа | Локальный рантайм | Провайдер и сеть |
Ссылку на статью ZDNet корректно ставить в подраздел «Современное состояние вопроса» — с датой публикации (28.04.2026) и указанием, что речь идёт о дистрибутиве Ubuntu Linux 26.04. Не забывайте: новость 2026 года усиливает актуальность только тогда, когда вы показываете, что из неё следует техническое требование, а не просто «есть такой тренд».
Проектная часть: что рисовать и как описывать
Минимальный набор артефактов, который ждут от архитектурной главы:
- Контекстная диаграмма. Акторы: пользователь, администратор, локальный рантайм, облачный провайдер, журнал аудита, служба политик.
- Диаграмма компонентов. Модуль согласия, маршрутизатор, DLP-фильтр, клиент инференса, телеметрия.
- Схема последовательности. Один запрос в двух вариантах: локально и в облако — с указанием точек проверки согласия.
- Модель данных. Таблица согласий, таблица провайдеров, журнал событий.
Рабочий прототип политики удобно держать в конфигурационном файле — это и код показать, и требования зафиксировать:
ai:
default_route: local
consent:
required: true
scopes: [text_assist, file_summary, code_explain]
providers:
local:
runtime: ollama
model: qwen3:8b
max_ram_gb: 12
cloud:
enabled: false
dlp_filter: strict
audit:
log: /var/log/ai-policy.jsonl
retention_days: 180
Алгоритм маршрутизации опишите словами до кода: проверить наличие согласия для запрошенной области → определить чувствительность данных → если данные помечены как конфиденциальные, разрешить только локальный маршрут → иначе применить политику администратора → записать событие в журнал → выполнить запрос. Такая последовательность отлично ложится на схему по ГОСТ 19.701-90.
Тестирование и метрики: чем доказать, что решение работает
Самый частый провал на защите — красивая архитектура без чисел. Ниже набор метрик, которые реально снять на студенческом стенде.
| Метрика | Как измерять | Инструмент |
|---|---|---|
| Задержка p50 / p95 | Серия из 200–500 запросов, фиксация времени до последнего токена | Скрипт-обвязка, OpenTelemetry |
| Пропускная способность | Токенов в секунду при параллелизме 1, 4, 8 | Локальный рантайм, логи |
| Доля запросов в облако | Счётчик маршрутизатора / общий объём | Метрики шлюза |
| Стоимость 1000 запросов | Тариф провайдера × токены; для локального — энергия × тариф | Расчётная таблица |
| Качество ответа | Фиксированный набор из 50 вопросов с эталонными ответами | Ручная или автоматическая оценка |
| RTO / RPO журнала | Имитация сбоя узла, замер восстановления | Резервное копирование, логи |
| Срабатывания DLP | Доля ложноположительных и ложноотрицательных | Тестовый набор промптов |
Нагрузочное тестирование описывайте честно: сколько параллельных клиентов, какие ограничения стенда, где упёрлись в железо. Студенческий ноутбук — валидная платформа, если вы указали конфигурацию и не экстраполируете результаты на продакшен без оговорок. Итоговую оценку качества решения удобно свести к восьми характеристикам ISO/IEC 25010 — функциональная полнота, производительность, безопасность, удобство использования, надёжность, сопровождаемость, переносимость, совместимость.
Чему вы научитесь, пока это делаете
- Обосновывать выбор стека через измеримые критерии, а не через популярность технологии.
- Строить модель угроз для системы, которая обрабатывает пользовательские данные.
- Проектировать шлюзы и промежуточные слои — навык, который пригодится в любой интеграционной задаче.
- Снимать метрики производительности и оформлять их в таблицы, пригодные для защиты.
- Готовить техническую документацию в соответствии с ГОСТ 34.602-89 и ГОСТ 19.701-90.
- Аргументировать экономику внедрения: стоимость железа против подписки.
Типичные ошибки студентов
1. Подмена понятий без обоснования. В тексте смешиваются «локальная модель», «приватный инстанс» и «on-premise», хотя это разные вещи. Читайте определение каждому термину в глоссарии и придерживайтесь его до конца работы.
2. Отсутствие метрик эффективности. Фраза «система работает быстрее» без чисел не защищается. Минимум — задержка и потребление памяти, зафиксированные в таблице с конфигурацией стенда.
3. Игнорирование требований ГОСТ при оформлении ТЗ. Техническое задание пишут «для галочки», а потом не могут связать с ним задачи и выводы. Составляйте ТЗ на первом курсе магистратуры, а не за неделю до защиты — оно станет скелетом всей работы.
Чек-лист перед сдачей
- Ссылка на источник оформлена с датой публикации и указана в списке литературы.
- Каждая задача из введения дословно повторяется в заключении с результатом.
- Есть минимум одна диаграмма компонентов и одна схема последовательности.
- Таблица метрик содержит конфигурацию стенда и число испытаний.
- Термины определены один раз и используются единообразно.
- ТЗ и структурная схема оформлены по ГОСТ 34.602-89 и ГОСТ 19.701-90.
- Проверено, что выводы не противоречат результатам экспериментов.
Вопросы, которые задают чаще всего
Обязательно ли писать код в ВКР по ИТ-направлению?
Формально не всегда, практически — почти всегда. Если тема заявлена как проектная, комиссия ждёт артефакт: прототип, конфигурацию, скрипт или развёрнутый стенд. Без кода защищаемы только чисто аналитические темы — например, сравнительная оценка подходов с корректно поставленным экспериментом.
Как обосновать выбор между локальной моделью и облачным API?
Через матрицу критериев с весами. Зафиксируйте четыре-пять критериев (приватность, задержка, качество, стоимость, требования к железу), проставьте веса, оцените варианты по шкале и покажите, при каком изменении весов решение меняется. Такой анализ выглядит убедительнее любого «я выбрал, потому что удобно».
Где брать тестовые данные, если реальных нет?
Синтетические наборы плюс открытые датасеты. Для проверки DLP подойдут сгенерированные строки, похожие на номера карт и телефонов, — специально размеченные как тестовые. Опишите методику генерации: это самостоятельный результат работы.
Как оформлять UML-диаграммы по ГОСТ?
ГОСТ не запрещает UML, но требует наличия схем, оформленных по правилам ЕСПД. Практика: основные диаграммы (компоненты, последовательность) делаете в нотации UML, а структурную схему системы и схему алгоритма — по ГОСТ 19.701-90. Главное — единый стиль и наличие подписей и ссылок в тексте на каждую диаграмму.
Не хватает времени на эксперименты? Мы берём на себя до 120 часов работы по теме: от анализа источников и проектирования до расчётов и оформления. Первая консультация — бесплатно, независимо от вашей темы и вуза. Помощь с дипломом не означает готовый текст «под копирку» — вы получаете разбор каждого раздела и понимаете, что именно защищаете.
Источник: Canonical's approach to AI is refreshingly thoughtful - Microsoft should take note (опубликовано 2026-04-28)
```