AI Rulebook: Обзор
Правила использования ИИ в организации — role-based подход
Зачем нужен Rulebook?
Проблема: Компании либо запрещают ИИ полностью (из-за рисков), либо разрешают всё (и получают утечки данных).
Решение: Набор правил для разных ролей — от простых запретов для пользователей до детальных требований для разработчиков.
Три уровня правил
🙋 Для пользователей
- Что можно, что нельзя — простые правила
- Какие данные передавать нельзя — ПДн, коммерческая тайна
- Как проверять результаты — критическое мышление
- Кому сообщать о проблемах — эскалация
💻 Для разработчиков
- Выбор LLM — on-premise vs API, российские vs зарубежные
- Агенты и права — контроль действий, аудит, мониторинг
- RAG и данные — подготовка корпуса, чанкинг, OCR
- Масштабирование — от 20 до 500+ пользователей
👔 Для руководителей
- Риски и их митигация — что может пойти не так
- ROI и метрики — как измерять эффект
- Комплаенс — что требуют юристы и ИБ
- Масштабирование — от пилота до production
Принципы создания правил
1. Разумный баланс
❌ Плохо: "Запретить всё" → никто не использует ИИ ❌ Плохо: "Разрешить всё" → утечки данных, репутационные риски ✅ Хорошо: Контролируемая среда с ролевым доступом
2. Адаптация под контекст
- Банк: строгие требования, on-premise, полный аудит
- Стартап: гибкость, API решения, быстрые итерации
- Средняя компания: гибрид — API для экспериментов, on-premise для production
3. Итеративность
- Выпускаем быстро (MVP правил)
- Собираем обратную связь на практике
- Обновляем раз в ~3 месяца (темп изменений высокий)
Ключевые темы Rulebook
📜 Юридические ограничения
Критичное для России:
- ПДн нельзя обрабатывать зарубежными LLM без согласия субъекта
- Коммерческая тайна не должна покидать контролируемую среду
- Авторские права на сгенерированный контент (серая зона)
→ Подробнее: ПДн и зарубежные LLM
🛡️ Информационная безопасность
Три уровня защиты:
- On-premise — для критичных данных (ПДн, коммерческая тайна)
- API с контролем — для внутренних данных (логирование, DLP)
- Публичные API — только для открытых данных
→ Подробнее: Compliance Pack
🤖 Агенты и права на действия
Риск: Модель может сгенерировать SQL DELETE FROM users по запросу
Контроль:
- Явные разрешения на каждое действие
- Dry-run режим для проверки
- Human-in-the-loop для критичных операций
- Полный аудит всех действий
→ Подробнее: Агенты и права
📊 Мониторинг и логирование
Что логировать:
- Все промпты пользователей (для аудита)
- Все ответы модели (для quality control)
- Метрики использования (cost tracking)
- Ошибки и edge cases
Retention policy:
- Минимум: 30 дней (для troubleshooting)
- Рекомендуется: 90 дней (для анализа паттернов)
- Compliance: до 3 лет (если требуют регуляторы)
🔄 Масштабирование доступов
| Пользователей | Подход | Контроль |
|---|---|---|
| < 20 | Shared API key | Basic logging |
| 20-60 | User auth + API | Role-based access |
| 60-200 | Gateway + rate limiting | Full audit |
| 200+ | Own infrastructure | Enterprise controls |
→ Подробнее: Масштабирование
Процесс внедрения Rulebook
Шаг 1: Выбор базовой версии (1-2 дня)
- Скачайте шаблон Rulebook
- Адаптируйте под ваш контекст:
- Размер компании - Индустрия (регулируемая / нерегулируемая) - Цели использования ИИ
Шаг 2: Согласование с stakeholders (1-2 недели)
- ИБ: проверка защиты данных
- Юристы: compliance с законами
- IT: техническая реализуемость
- HR: обучение сотрудников
Шаг 3: Пилот на малой группе (2-4 недели)
- Выберите 10-20 early adopters
- Соберите обратную связь
- Доработайте правила
Шаг 4: Раскатка на всю компанию
- Обучение (см. AI Literacy)
- Техническая реализация контролей
- Постоянный мониторинг и обновление
Типовые сценарии
Сценарий 1: "Запрос с ПДн"
Пользователь: "ChatGPT, напиши письмо клиенту Иванову (ivan@mail.ru, тел. +7...)"
Правило: ❌ Запрещено — передача ПДн в зарубежный сервис
Альтернатива: Использовать внутренний инструмент с российской моделью
Сценарий 2: "Агент с доступом к базе"
Разработчик: "Сделай агента, который отвечает на вопросы по клиентской базе"
Правило: ⚠️ Требуется:
- Явные разрешения на SELECT запросы
- Запрет на DELETE/UPDATE
- Логирование всех запросов
- Human review для нестандартных ответов
Сценарий 3: "Генерация кода"
Пользователь: "GitHub Copilot предложил код с API ключом в репозитории"
Правило: ⚠️ Требуется:
- Pre-commit hook для проверки секретов
- Code review всех AI-generated изменений
- Обучение безопасной работе с AI coding tools
Частые вопросы
❓ Нужно ли обновлять Rulebook каждый раз при появлении новой модели?
Ответ: Нет, если правила формулированы абстрактно (не "запрещён GPT-4", а "запрещены зарубежные API для ПДн"). Пересмотр — раз в 3 месяца.
❓ Как донести правила до сотрудников, чтобы их не игнорировали?
Ответ:
- Делайте правила простыми и понятными
- Объясняйте "почему" (риски), а не только "что нельзя"
- Давайте альтернативы ("нельзя это → можно вот так")
- Встраивайте контроль в инструменты (техническое enforcement)
❓ Что делать, если ИБ хочет запретить всё?
Ответ: Покажите им:
- Примеры контролируемого использования
- Шаблоны политик от других компаний
- ROI успешных внедрений (есть что терять, если не использовать ИИ)
Следующие шаги
- Выберите ваш трек:
- Пользователь — правила использования - Разработчик — технические требования - Руководитель — риски и governance
- Скачайте шаблоны:
- Шаблон политики для пользователей - Шаблон для разработчиков
- Изучите кейсы применения:
Вопросы? Спросите в Telegram-сообществе