Дорожная карта Google по безопасному GenAI: 5 принципов, которые ваш AI governance заберёт из «детского» документа

Google опубликовала roadmap по защите молодёжи от рисков генеративного ИИ. Но если убрать слово «дети» и вставить «сотрудники» — получается готовый каркас корпоративной AI-политики. Разбираем пять принципов документа, переводим на язык enterprise и даём шаблоны, которые можно внедрить уже на этой неделе.

Почему «детский» документ Google важен вашему CISO

11 марта 2026 года Кристи Абизаид, VP Trust & Safety в Google, представила дорожную карту по безопасному GenAI для молодёжи на саммите «Growing Up in the Digital Age» в Дублине. На первый взгляд — история про детей и ответственный ИИ. Типичный CSR-ход крупной корпорации.

Но структура документа — не набор благих намерений. Это safety framework с конкретными уровнями контроля, классификаторами рисков, adversarial-тестированием и циклами ревизии. По сути — архитектура AI governance, обкатанная на самой уязвимой аудитории.

Аналогия из авиации: стандарты безопасности не пишут для «нормальных полётов». Их проектируют под экстремальные сценарии — обледенение, отказ двигателя, ошибка пилота. Потом эти же стандарты защищают каждый рейс. Google сделала то же самое: выстроила защиту для максимально уязвимой группы — и эта защита масштабируется на любой контекст.

Проблема в том, что у большинства компаний формализованного AI Usage Policy просто нет. По данным McKinsey State of AI 2025, менее 40% организаций, использующих GenAI, имеют формальную политику управления рисками. Остальные работают в серой зоне: сотрудники используют ChatGPT, Gemini, Claude — а правил игры не существует.

Мы разобрали документ Google, извлекли пять ключевых принципов и перевели каждый на язык корпоративного AI governance. Ниже — конкретика, чеклисты и шаблоны.

Что именно опубликовал Google

Дорожная карта построена на трёх столпах: защита молодёжи онлайн, уважение к семейным отношениям с технологиями, расширение возможностей молодёжи для безопасного обучения.

Ключевые факты:

• Политики безопасности встроены в весь жизненный цикл разработки — от входных данных пользователя до финального ответа модели
• Используются специализированные классификаторы для выявления опасных запросов и предотвращения вредных ответов
• В 2025 году команда Content Adversarial Red Team (CART) провела более 350 упражнений по adversarial-тестированию — текст, аудио, изображения, видео, агентный ИИ
• Gemini 3 показала конкретные улучшения в устойчивости к sycophancy, prompt injection и кибер-злоупотреблениям
• Модели имеют явные запреты: нельзя имитировать сентиентность, вступать в романтические отношения, играть роль вредных персонажей

Целевая аудитория документа — молодёжь и семьи. Но механизмы — универсальны.

Принцип 1 — Прозрачность: пользователь должен знать, что говорит с ИИ

Google вводит чёткое разграничение: ИИ не должен притворяться человеком. Модели запрещено заявлять о сентиентности, имитировать эмоциональные привязанности или маскировать свою природу. Для подростков это защита от манипулятивных отношений с чат-ботом. Для бизнеса — фундамент responsible AI.

Прозрачность в enterprise-контексте — это три вещи:

Маркировка AI-генерированного контента. Когда менеджер получает письмо от коллеги, он должен понимать: это написал человек или GPT. Когда клиент общается с поддержкой — видеть, что разговаривает с ботом. Когда юрист читает черновик договора — знать, что первую версию составила модель.

Vendor disclosure в договорах. Если ваш продукт использует GenAI — клиент имеет право об этом знать. Это уже не вопрос этики, а требование EU AI Act для систем высокого риска. И даже если ваш продукт не подпадает под регуляцию напрямую — disclosure снижает репутационные риски.

Раскрытие информации внутри команды. Сотрудники должны знать, если компания использует ИИ для мониторинга их работы, анализа коммуникаций или оценки производительности.

Чеклист: как реализовать прозрачность

1. Маркировка AI-ответов в helpdesk и внутренних чатах. Добавьте лейбл «Ответ сгенерирован с помощью ИИ» ко всем автоматическим ответам. Это 15 минут настройки и ноль негативных последствий.

2. Уведомление сотрудников о применении ИИ в HR-процессах. Если используете ИИ для скрининга резюме, анализа переписки или оценки KPI — зафиксируйте это в трудовых соглашениях или внутреннем регламенте.

3. Disclosure в клиентских соглашениях. Добавьте раздел об использовании AI-инструментов в SLA и пользовательские соглашения. Укажите, какие данные обрабатываются моделями и где.

4. Внутренний реестр AI-инструментов. Составьте список всех GenAI-сервисов, используемых в компании, с указанием: кто использует, для каких задач, какие данные передаются.

5. Регулярный аудит «теневого ИИ». Проверяйте, какие AI-инструменты сотрудники используют неофициально. Shadow AI — это shadow IT нового поколения, и он уже в вашей компании.

Принцип 2 — Контроль контекста: ограничение данных, которые видит модель

Google описывает контекстуальные ограничения: модель получает доступ только к тому объёму информации, который необходим для конкретной задачи. Для молодёжных продуктов это означает фильтрацию возрастного контента. Для корпорации — принцип минимальных привилегий, применённый к LLM.

Типичный сценарий: компания подключает ChatGPT или внутренний LLM к базе знаний через RAG. Загружает туда всё — документацию, переписку, CRM-данные, финансовые отчёты. Менеджер по продажам спрашивает модель про клиента — и получает ответ, включающий данные из финансового отдела, к которым у него нет доступа. Контроль контекста нарушен.

Другой сценарий: сотрудник копирует фрагмент внутреннего документа в ChatGPT, чтобы «улучшить формулировку». Данные ушли на внешние серверы. Именно так произошла утечка в Samsung в 2023 году, когда инженеры загрузили проприетарный код в ChatGPT.

Контроль контекста в enterprise AI governance строится на трёх уровнях:

• Уровень доступа к данным. LLM должна видеть только те документы, которые доступны конкретному пользователю. Если у вас RAG-архитектура — реализуйте permission-aware retrieval. Это не «было бы неплохо», а необходимость.

• Уровень передачи данных. Определите, какие категории данных запрещено отправлять во внешние AI-сервисы. Персональные данные клиентов, финансовая отчётность, исходный код, стратегические документы — минимальный список для запрета.

• Уровень хранения. Убедитесь, что AI-провайдер не использует ваши данные для обучения моделей. Проверьте условия data retention. У OpenAI, Anthropic и Google есть enterprise-тарифы с гарантией неиспользования данных для тренировки — но на бесплатных планах такой гарантии нет.

Принцип 3 — Ограничение рисков: что ИИ не должен делать

Google прямо перечисляет запрещённые сценарии для своих моделей. Для молодёжного контекста список очевиден. Для корпоративного — его нужно составить самим.

Принцип harm reduction в enterprise — это формализованный список prohibited use cases. Не рекомендации, а явные запреты с последствиями за нарушение.

Регуляторная среда уже формирует требования. EU AI Act классифицирует AI-системы по уровням риска и прямо запрещает определённые применения: социальный скоринг, биометрическая идентификация в реальном времени в публичных пространствах, манипулятивные техники.

Шаблон prohibited use cases для AI Usage Policy

#	Запрещённый сценарий	Обоснование	Уровень риска
1	Генерация юридических заключений без проверки юристом	Галлюцинации модели — юридическая ответственность компании	Критический
2	Автономные финансовые решения на основе AI-рекомендаций	Отсутствие аудируемого human approval — регуляторные риски	Критический
3	Передача персональных данных клиентов во внешние AI-сервисы	Нарушение 152-ФЗ, GDPR, условий NDA	Критический
4	Использование AI для окончательного решения по найму/увольнению	Bias в моделях — дискриминационные решения, судебные иски	Высокий
5	Генерация публичных коммуникаций от имени компании без ревью	Репутационные риски, фактологические ошибки	Высокий
6	Автоматическая обработка обращений клиентов без эскалации на человека	Потеря клиентов, нарушение стандартов обслуживания	Средний
7	Использование AI-генерированного кода в production без code review	Уязвимости безопасности, лицензионные риски	Высокий

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

Принцип 4 — Human oversight: «человек в петле» — это защита, а не замедление

Google описывает многоуровневую систему надзора: внутренние специалисты по безопасности, внешние эксперты, adversarial red team из 350+ тестовых упражнений в год. Модель не выпускается в продакшн без прохождения этих проверок.

В корпоративном контексте human-in-the-loop — один из самых недооценённых принципов. Компании часто воспринимают его как бюрократический тормоз. Ответ простой: без человека стоимость ошибки растёт экспоненциально.

Публичные примеры:

• Samsung, 2023: инженеры загрузили проприетарный код в ChatGPT. Без механизма контроля утечка произошла трижды за месяц, прежде чем руководство узнало.
• Air Canada, 2024: чат-бот выдумал политику возврата средств и пообещал клиенту несуществующую скидку. Суд обязал авиакомпанию выполнить обещание бота.
• Юридические фирмы, 2023–2024: адвокаты подавали в суд документы с вымышленными прецедентами, сгенерированными ChatGPT. Штрафы, дисциплинарные взыскания, потеря лицензии.

Все три случая объединяет одно: отсутствие approval workflow между AI-генерацией и действием.

Как выстроить human oversight

• Эскалационная матрица. Определите категории решений и уровень контроля. Черновик email — автор проверяет перед отправкой. Юридический документ — обязательная проверка юристом. Финансовый расчёт — валидация аналитиком.

• Роль AI-офицера. Назначьте ответственного за AI governance. Это может быть CISO, отдельная роль или рабочая группа — но кто-то должен отвечать за политику, инциденты и обучение.

• Логирование и аудит. Каждое значимое взаимодействие с AI-системой должно логироваться. Не для тотальной слежки, а для разбора инцидентов. Без логов расследование утечки превращается в гадание.

• Adversarial-тестирование. Раз в квартал проводите внутренний red teaming: попросите сотрудников попытаться извлечь из корпоративного ИИ данные, к которым у них нет доступа.

Принцип 5 — Итеративное улучшение: governance — это процесс, а не документ

Проблема большинства корпоративных AI-политик — они статичны. Документ написали в 2023 году под GPT-3.5 — а с тех пор вышли GPT-4o, Claude 3.5, Gemini 3, появились мультимодальные модели, агентный ИИ, MCP-протоколы. Политика, которая не обновляется с каждым значимым релизом, — это фикция.

Google указывает: Gemini 3 показала конкретные улучшения по сравнению с предыдущими версиями — меньше sycophancy, выше устойчивость к prompt injection. Это значит, что и guardrails нужно адаптировать.

Внедрите quarterly AI policy review:

• Триггеры ревизии: выход новой major-версии модели, AI-инцидент в компании или индустрии, изменение регуляторных требований, запуск нового AI-продукта или интеграции.

• Формат: рабочая встреча на 60–90 минут с участием IT, безопасности, юридического отдела и бизнеса. Фиксированная повестка: новые риски, статус guardrails, обновления prohibited use cases.

• Выход: обновлённая версия AI Usage Policy с changelog. Доведение изменений до сотрудников через внутренние коммуникации.

Статичный документ даёт ложное чувство безопасности. Живой процесс — реальную защиту.

Экспресс-аудит: оцените зрелость вашей AI-политики

По каждому принципу поставьте от 0 до 2 баллов.

Принцип	0 баллов	1 балл	2 балла
Прозрачность	Нет маркировки AI-контента, нет реестра инструментов	Есть неформальные правила, реестр частичный	Обязательная маркировка, полный реестр, disclosure в договорах
Контроль контекста	Сотрудники свободно передают данные во внешние AI	Есть запрет на отдельные категории данных	Permission-aware RAG, DLP для AI, формализованная классификация
Ограничение рисков	Нет списка prohibited use cases	Список есть, но неформальный	Формализованный список в AI Usage Policy, привязан к compliance
Human oversight	AI-решения не контролируются	Контроль для отдельных процессов	Эскалационная матрица, AI-офицер, логирование, red teaming
Итеративное улучшение	Политика написана один раз и забыта	Обновляется при инцидентах	Quarterly review, триггеры ревизии, changelog

Интерпретация:

• 8–10 баллов: зрелая AI-политика. Вы в меньшинстве — таких компаний менее 15%.
• 5–7 баллов: фундамент есть, но с пробелами. Приоритет — формализовать то, что существует «на словах».
• 0–4 балла: критический уровень. Каждый день без политики — это принятый, но неосознанный риск.

Что делать прямо сейчас: 3 шага

Шаг 1. Проведите аудит по таблице выше. Потратьте 30 минут с командой безопасности. Честно оцените каждый принцип.

Шаг 2. Соберите рабочую группу по AI policy. Минимальный состав: IT/DevOps, информационная безопасность, юрист, представитель бизнеса. Первая задача — реестр всех AI-инструментов и prohibited use cases. На это уйдёт 2–3 недели.

Шаг 3. Используйте шаблоны из этой статьи. Чеклист прозрачности, таблица prohibited use cases, скоринг зрелости — всё можно адаптировать за один рабочий день. Рабочий документ на 3 страницы лучше, чем отсутствие документа.

---

Google выстроила safety framework для самой уязвимой аудитории — и в этом его сила как шаблона. Принципы, которые защищают подростков от манипулятивного ИИ, точно так же защищают бизнес от утечек данных, регуляторных штрафов и репутационных кризисов. Разница — только в терминологии.

---

Поделимся опытом

hello@vibelab.ru

8 800 201 85 68

Написать в Telegram