Конфиденциальность и безопасность

Почему это важно

Для QA утечка через публичный чат — управляемый, но реальный риск: требования, логи, SQL-схемы и тест-данные обрабатываются вне вашего периметра. Три типовых последствия: ПДн (GDPR, 152‑ФЗ), коммерческая тайна и код, компрометация ключей и учётных записей.

Установка локальной среды: пошаговая инструкция Ollama + Open Web UI — в Предисловии, «Настройка окружения». Справочник моделей и RAM — Приложение: локальная среда.

Единая классификация данных

Если в компании нет политики LLM: три шага

Шаг 1: уточнить у непосредственного руководителя
Спросите: «Есть ли одобренные инструменты для использования ИИ в рабочих задачах?» Если однозначного ответа нет — переходите к шагу 2.

Шаг 2: запросить информацию у Information Security / IT
Кратко опишите цель: «Хочу использовать LLM для [конкретная задача]. Данные — [категория: открытые / внутренние / ПДн — без деталей]. Какой канал или инструмент вы рекомендуете?» Если полного ответа ещё нет, хотя бы уточните: «Есть ли явно запрещённые сервисы?»

Шаг 3: по умолчанию — локальная модель
Пока политика не формализована: Ollama + Open Web UI — см. настройку в предисловии. Реальные production-данные — только после явного разрешения.

Когда без реального лога «не разобраться»

1. Запросить обезличенную выборку у DevOps / InfoSec.
2. Если нельзя — описать структуру лога + несколько синтетических строк.
3. По возможности использовать только локальную модель и канал, разрешённый политикой.
4. По завершении — удалить историю чата / артефакты, если того требует регламент.

Анонимизация, синтетические данные и безопасный контекст

Полная таблица категорий данных и каналов — в разделе «Единая классификация данных». Приёмы подготовки — в шпаргалке приёмов.

Почему одного запрета недостаточно

На практике QA редко работает с «идеально чистыми» примерами.
В логах, требованиях, письмах, API-запросах и дампах часто встречаются:

• email-адреса;
• телефоны;
• имена клиентов;
• внутренние URL;
• токены и ключи;
• идентификаторы заказов и аккаунтов;
• IP-адреса;
• фрагменты production-данных.

Поэтому надёжный процесс выглядит так:

1. Выявить чувствительные элементы.
2. Замаскировать или заменить их.
3. Проверить, что структура данных осталась полезной для анализа.
4. Только после этого передавать контекст в модель.

Что считать чувствительными данными

Категории и каналы — в таблице классификации. Перед отправкой в модель проверьте: есть ли ПДн, секреты (ключи, токены, пароли), production-контекст (реальные ID, дампы, внутренние URL) — для публичного чата всё это только после обезличивания или в разрешённом локальном/корпоративном канале.

Три способа подготовки данных

1. Удаление
Просто убрать чувствительный фрагмент.

Подходит, если:

• удаляемая часть не влияет на смысл;
• связи между сущностями не важны.

Минус: можно сделать контекст слишком «дырявым», и модель начнёт додумывать.

2. Маскирование
Заменить чувствительную сущность на нейтральный маркер.

Примеры:

• ivan.petrov@company.ru → <EMAIL_1>
• +79991234567 → <PHONE_1>
• 98453321 → <ORDER_ID_1>
• 10.14.6.21 → <IP_1>
• sk_live_abc... → <API_KEY_1>

Это самый полезный подход для QA, потому что сохраняет структуру данных и причинно-следственные связи.

3. Синтетическая замена
Не просто скрыть значение, а заменить его на безопасный реалистичный аналог.

Пример:

• реальный клиент → «Иван Тестов»
• реальный email → test.user@example.com
• реальный заказ → ORDER-TEST-001

Подходит для демо, учебных материалов, тестовых наборов и шаблонов.

Главное правило консистентности

Если одна и та же сущность встречается в тексте несколько раз, её нужно заменять одинаково во всех местах.
Если в первом абзаце пользователь стал <USER_1>, а в третьем — уже <ACCOUNT_7>, модель может потерять связи между событиями и сделать неправильные выводы.

Пример для QA

User ivan.petrov@company.ru from 10.14.6.21 failed payment for order 98453321 using token sk_live_abc...

Безопасно:

User <EMAIL_1> from <IP_1> failed payment for order <ORDER_ID_1> using token <API_KEY_1>

Во втором варианте сохраняется структура инцидента, но исчезают реальные чувствительные данные.

Практические рекомендации для QA

• Для публичных LLM используйте только очищенные данные.
• Для локальных или корпоративных LLM всё равно соблюдайте принцип минимально необходимого контекста.
• Никогда не вставляйте токены, ключи, cookies и внутренние URL «временно, только чтобы быстрее разобраться».
• Если можно заменить реальные данные синтетическими без потери смысла — заменяйте.
• Если задача высокорисковая, добавляйте ручную приёмку результата человеком.

Приложение: настройка локальной среды

Пошаговая установка Ollama + Open Web UI — в Предисловии. Ниже — справочник по моделям (май 2026; теги на ollama.com/library уточняйте перед pull).

Groq Console (облако, синтетические данные): см. каталог моделей. Для QA-упражнений курса:

OWASP LLM Top 10: ключевые риски

Шаблон политики для команды QA

## Политика использования LLM командой QA [НАЗВАНИЕ КОМАНДЫ]
#### Разрешено без ограничений:
- Генерация тест-кейсов по обезличенным требованиям
- Создание чек-листов
- Формулировка вопросов к заказчику
- Обучающие материалы (без примеров из production)
#### Разрешено только в локальных LLM (Open Web UI + Ollama):
- Анализ логов любого окружения
- Работа с исходным кодом тестов
- Обработка данных пользователей (даже анонимизированных)
- Работа с API-спецификациями внутренних сервисов
#### Запрещено:
- Отправка в публичные LLM: персональных данных, паролей, токенов, ключей API
- Генерация кода для production без code review
- Автоматическая отправка баг-репортов без проверки человеком
#### Ответственность:
- [Роль] отвечает за соблюдение политики
- Нарушение = [последствия]
- Вопросы → [контакт]

Чек-лист безопасности для QA

Упражнение: аудит промпта на безопасность

Ты — специалист по информационной безопасности. Проанализируй следующий промпт на наличие утечек конфиденциальных данных.

Промпт: [вставить]

Выведи:
1. Найденные чувствительные данные (тип и место)
2. Уровень риска
3. Рекомендации по анонимизации

Приёмы подготовки данных