Политика управления данными, рисками и соответствием
IuVeAI / iuve.eu
Версия: 1.0
Дата вступления в силу: 26 августа 2026
Сервис: https://www.iuve.eu/
Оператор
Разработчик проекта: Iurie Verejan
Юридическое лицо / Оператор: RECLAMA-VEREJAN I.I.
DNO / Cod: 1003600053323
Адрес: MD-2042, Moldova, CHISINAU CIOCANA, mun. Chisinau, Alecu Russo, 24/2
Поддержка: hello@iuve.eu
Настоящая Политика управления данными, рисками и соответствием («Политика DGRC») дополняет Политику конфиденциальности, Условия использования, Политику cookie, Политику допустимого использования и Политику ИИ и обучения моделей. Если более специальная политика устанавливает более строгую защиту, применяется более строгое требование, если иное не запрещено законом. Настоящая Политика не заменяет Политику конфиденциальности в части процедур реализации прав субъектов данных.
1. Цель
Политика DGRC устанавливает рамки управления, используемые IuVeAI для управления данными пользователей и рабочих пространств; системами и моделями искусственного интеллекта; провайдерами моделей ИИ; локальным и облачным выводом; API-интеграциями; автономными и полуавтономными агентами; подключёнными устройствами; правами доступа; рисками безопасности; модельными и операционными рисками; аудитируемостью; а также правовым и регуляторным соответствием.
Цель Политики — обеспечить работу IuVeAI в соответствии с принципами конфиденциальности, безопасности, подотчётности, прозрачности, минимизации данных, человеческого контроля и пропорционального рискам управления ИИ.
2. Область применения
Настоящая Политика применяется к сервисам и компонентам IuVeAI, эксплуатируемым через iuve.eu или подключённым к нему, включая IuVeAI Chat; ассистента Iulia AI; маршрутизацию и вывод моделей ИИ; локальные модели ИИ; внешних провайдеров ИИ; доступ к API; обработку файлов и документов; голосовой ввод и вывод; STT и TTS; интеграции с GitHub; репозитории и инструменты кодирования; IuVe Connect; Desktop Agent; Avatar и локальную автоматизацию; pairing устройств; Semantic Marketing; Website Agent; интеграции Marketplace; интеграции Genesis CMS AI; командные рабочие пространства; административные системы; а также системы мониторинга и безопасности.
Политика распространяется на администраторов, разработчиков, сотрудников, подрядчиков, поставщиков услуг, ИИ-агентов и автоматизированные процессы, получающие доступ к системам или данным, контролируемым IuVeAI.
3. Принципы управления
3.1 Конфиденциальность по умолчанию
Частная информация рабочего пространства должна оставаться частной по умолчанию. Доступ допускается только там, где это необходимо для предоставления запрошенной пользователем функции, обеспечения безопасности системы, соблюдения закона или выполнения явно уполномоченного административного действия.
3.2 Минимизация данных
Могут собираться, передаваться или храниться только сведения, разумно необходимые для запрошенной операции.
3.3 Ограничение цели
Информация, собранная для одной цели, не должна автоматически использоваться для несвязанной цели.
3.4 Наименьшие привилегии
Пользователи, сервисы, API-ключи, агенты и администраторы должны получать только те права, которые необходимы для выполнения их задачи.
3.5 Явные полномочия
ИИ-агент не получает полномочий лишь потому, что технически способен выполнить действие. Полномочия должны следовать из разрешения пользователя, конфигурации рабочего пространства, политики администратора, утверждённого предоставления capability либо иного задокументированного источника полномочий.
3.6 Человеческий контроль
Действия, способные повлечь существенные финансовые, правовые, связанные с безопасностью или конфиденциальностью либо операционные последствия, должны оставаться под надлежащим человеческим контролем.
3.7 Прослеживаемость
Операции, чувствительные с точки зрения безопасности, и операции, выполняемые агентами, должны быть атрибутируемы пользователю, сервису, API-ключу, модели, агенту или системному процессу.
3.8 Отказ в безопасное состояние (Fail Secure)
Если идентичность, полномочия, политика или статус исполнения не могут быть надёжно определены, система должна по умолчанию выбирать более безопасное состояние.
4. Классификация данных
IuVeAI использует четыре основных класса данных.
PUBLIC
Информация, предназначенная для публичного раскрытия (например, публичное содержимое сайта, публичная документация, публичные листинги Marketplace и публичные статьи). Публичная информация может обрабатываться уполномоченными системами IuVeAI без дополнительных ограничений конфиденциальности.
INTERNAL
Операционная информация, не предназначенная для неограниченного публичного раскрытия (например, внутренние метрики, конфигурация системы, нечувствительные операционные журналы и внутренняя документация). Доступ должен ограничиваться уполномоченными системами и персоналом.
CONFIDENTIAL
Информация, связанная с пользователем, рабочим пространством, организацией или частной деятельностью (например, беседы, загруженные файлы, содержимое репозиториев, исходный код, личные заметки, сведения о проектах, голосовые транскрипты, контекст исполнения агента и информация о клиентах). Конфиденциальные данные не должны раскрываться несвязанным пользователям или сервисам.
RESTRICTED
Информация, требующая наивысшей защиты (например, пароли, закрытые ключи, секреты аутентификации, токены доступа, секреты API, учётные данные сессий, учётные данные восстановления, сведения платёжной аутентификации и особо чувствительные персональные данные). Информация класса Restricted не должна намеренно использоваться как данные для обучения ИИ. Там, где это технически возможно, такая информация должна выявляться, редактироваться, маскироваться или блокироваться до передачи модели ИИ или внешнему провайдеру.
5. Управление жизненным циклом данных
IuVeAI управляет данными на протяжении всего цикла: Сбор → Классификация → Обработка → Хранение → Доступ → Передача → Хранение по срокам → Удаление.
Для каждой существенной категории данных IuVeAI должен быть способен определить: зачем информация обрабатывается; какой сервис её обрабатывает; её класс; где она хранится; кто или что может получить к ней доступ; передаётся ли она третьей стороне; применимые правила хранения; механизмы удаления.
6. Управление моделями ИИ
Каждая модель, интегрированная в IuVeAI, должна иметь идентифицируемую запись управления. Запись может включать имя модели, версию, провайдера, место развёртывания, предполагаемое использование, возможности, известные ограничения, лимиты контекста, применимые ограничения безопасности, характеристики обработки данных, результаты оценки, приоритет маршрутизации и условия fallback. Существенные изменения моделей должны версионироваться и быть аудитируемыми.
7. Локальная и облачная обработка ИИ
IuVeAI может использовать локальные модели, собственную инфраструктуру и внешних провайдеров ИИ. Решения о маршрутизации могут учитывать конфигурацию пользователя, тип задачи, возможности модели, требования к конфиденциальности, задержку, доступность, стоимость, безопасность, требования к контексту, доступность ресурсов и пороги качества.
Если локальная обработка настроена или требуется, IuVeAI должен предпочитать одобренное локальное исполнение до передачи частной информации вовне. Облачный fallback не должен молча обходить явное ограничение конфиденциальности или режим «только локально».
8. Внешние провайдеры ИИ
Внешние провайдеры ИИ должны рассматриваться как сторонние сервисы обработки. Перед промышленным использованием IuVeAI должен, где применимо, оценивать условия обработки данных, практики хранения, политики обучения, меры безопасности, географию обработки, доступность, возможности модели, регуляторные последствия и историю инцидентов.
Чувствительная информация не должна передаваться внешнему провайдеру ИИ лишь потому, что этот провайдер даёт более качественный ответ. Требования конфиденциальности и полномочий имеют приоритет над качеством модели.
9. Обучение моделей и непрерывное обучение
Частная информация рабочего пространства не должна автоматически становиться данными для обучения. IuVeAI различает данные вывода (inference), операционную телеметрию, данные оценки, одобренные примеры обучения и обучающие наборы. Перенос информации из одной категории в другую требует определённого правового и технического основания.
Community- или product-improvement обучение на основе частных пользовательских бесед остаётся добровольным (opt-in), как указано в Политике ИИ и обучения моделей. Отказ от обучения не должен препятствовать обычному выводу, необходимому для предоставления запрошенной ИИ-услуги. Информация класса Restricted не должна включаться в обучающие наборы.
10. Управление непрерывным обучением
Автоматизированные или непрерывные системы обучения не должны напрямую изменять производственное поведение без контролируемой валидации. Жизненный цикл обучения должен следовать схеме: Capture → Sanitise → Evaluate → Train → Test → Canary → Verify → Approve → Deploy.
Успех обучения сам по себе недостаточен для производственного развёртывания. Новая модель, адаптер, правило или выученное поведение должны пройти применимые проверки качества, безопасности и регрессии до активации в production. Должна сохраняться возможность производственного отката (rollback).
11. Управление ИИ-агентами
IuVe Connect, Desktop Agent, Avatar и другие агенты работают в рамках явных capability. Агенты не должны предполагать неограниченный контроль над устройством или учётной записью. Категории capability могут включать доступ к файлам, управление приложениями, взаимодействие с браузером, исполнение в терминале, доступ к репозиториям, сетевые действия, конфигурацию системы, доступ к буферу обмена и внешнюю коммуникацию. Capability должны ограничиваться грантами пользователя или администратора. Высокоimpact capability должны поддерживать отзыв и журналирование аудита.
12. Классификация действий агента
Уровень 0 — Только чтение (просмотр, поиск, анализ, суммирование): обычно исполняется без дополнительного подтверждения при уже имеющихся полномочиях.
Уровень 1 — Обратимые (создание черновика, создание временного файла, изменение обратимого состояния приложения): могут исполняться при утверждённом grant capability.
Уровень 2 — Существенное изменение (изменение файлов проекта, развёртывание ПО, изменение конфигурации, обновление production-ресурсов): требует более строгой проверки полномочий и надлежащих мер защиты.
Уровень 3 — Высокий impact (удаление важных данных, финансовые транзакции, раскрытие учётных данных, изменение политики безопасности, предоставление административных привилегий, необратимые операции): не должно исполняться только потому, что модель ИИ рекомендует действие. Требуется дополнительная человеческая авторизация или явно заранее утверждённая политика.
13. Разделение рассуждения и полномочий
Сгенерированные ИИ рассуждения носят рекомендательный характер. Ответ модели сам по себе не является разрешением. Слой исполнения должен независимо проверять идентичность субъекта, grant capability, политику, область исполнения, среду и применимые ограничения безопасности.
14. Человеческий надзор
IuVeAI должен сохранять meaningful human oversight в отношении существенных автоматизированных решений. Пользователи должны иметь возможность, где это технически применимо, просматривать предлагаемые действия, отклонять действия, отзывать разрешения, останавливать агента, проверять результаты исполнения и сообщать о некорректном поведении.
15. Прозрачность ИИ
Пользователи должны понимать, когда они взаимодействуют с системой ИИ, а не с человеком. Там, где это требуется применимым правом и технически уместно, контент, сгенерированный или изменённый ИИ, должен поддерживать надлежащее раскрытие либо машиночитаемую идентификацию. IuVeAI не должен намеренно представлять искусственную систему как человека в обстоятельствах, где это существенно вводило бы пользователя в заблуждение.
16. Высокорисковые и запрещённые применения
IuVeAI должен применять дополнительные меры контроля к применениям ИИ, способным существенно влиять на трудоустройство, кредит, страхование, здравоохранение, правовые права, биометрическую идентификацию, государственные услуги, критическую инфраструктуру, правоохранительную деятельность или финансовые активы. Функциональность, попадающая в регулируемые или запрещённые категории, должна проходить специальную правовую и risk-оценку до развёртывания. Наличие способной модели само по себе не санкционирует такое использование.
17. Автоматизированное принятие решений
Если система ИИ помогает в принятии решений с существенными последствиями, система должна ясно различать: извлечение информации; рекомендацию; скоринг; автоматизированное решение; исполнение. Там, где это требуется законом, пользователи должны иметь доступ к человеческому обзору или иному надлежащему механизму оспаривания.
18. Управление безопасностью
IuVeAI применяет risk-based меры безопасности, включая, где уместно: шифрование при передаче; безопасное хеширование паролей; защиту API-ключей; разделение секретов; аутентификацию; ролевой контроль доступа; ограничение частоты запросов; защиту сессий; журналирование аудита; управление зависимостями; устранение уязвимостей; резервное копирование; меры восстановления; мониторинг сервиса. Меры безопасности должны периодически пересматриваться с учётом изменений архитектуры и моделей угроз.
19. Управление секретами
Секреты не должны храниться напрямую в публичных репозиториях, frontend JavaScript, публичных журналах, обучающих наборах, аналитических payload или обычной истории чата. API-ключи и учётные данные должны быть ограниченными по области, отзывными и разделёнными по назначению. Лицензионные ключи IuVe Marketplace (mp_live_*) и учётные данные IuVeAI API (kai_live_*) должны оставаться логически разделёнными.
20. Управление доступом
Решения о доступе должны основываться на аутентифицированной идентичности и роли. Привилегированный доступ должен следовать схеме: Identity → Authentication → Role → Scope → Policy → Action. Административный доступ не должен предоставляться только на основании обладания публичным идентификатором. Привилегированные действия должны быть аудитируемыми.
21. Сторонние интеграции
Подключённые сервисы, такие как GitHub и внешние API, должны работать только с правами, необходимыми для запрошенной функциональности. Учётные данные интеграций должны быть отзывными. Удаление интеграции должно прекращать дальнейший доступ, где это технически возможно. Сторонние интеграции не дают IuVeAI права собственности на сторонний контент.
22. Передача данных
При передаче персональных или конфиденциальных сведений третьей стороне или в другую юрисдикцию IuVeAI должен оценивать применимые требования конфиденциальности и договорные обязательства. Там, где это требуется, до передачи должны быть установлены надлежащие гарантии (safeguards).
23. Журналирование и аудит
IuVeAI может вести записи безопасности и операционного аудита, необходимые для установления: кто выполнил действие; какой сервис или агент его исполнил; когда это произошло; какая capability использовалась; успешно ли действие; требовалось ли одобрение; а также соответствующих событий безопасности. Сами журналы аудита должны быть защищены от несанкционированного изменения и раскрытия. Журналы не должны без необходимости содержать полные секреты или конфиденциальные payload.
24. Управление рисками
IuVeAI использует risk-based подход. Риски могут включать риск конфиденциальности, кибербезопасности, галлюцинаций модели, prompt injection, утечки данных, эскалации привилегий, злонамеренного использования инструментов, компрометации цепочки поставок, отказа провайдера, деградации модели, некорректного автономного действия, регуляторный и репутационный риск. Риск оценивается как Likelihood × Impact × Exposure. Меры контроля должны быть пропорциональны результирующему риску.
25. Реестр рисков ИИ
Существенные компоненты ИИ должны быть представлены во внутреннем AI Risk Register. Каждая запись может содержать систему, владельца, модель, назначение, затронутых пользователей, категории данных, классификацию риска, известные риски, меры снижения, статус оценки, статус развёртывания и дату пересмотра.
26. Оценка влияния на конфиденциальность
Оценка влияния на конфиденциальность или рисков ИИ должна проводиться до развёртывания функциональности, способной существенно повысить риск для физических лиц, включая крупномасштабное профилирование, биометрическую обработку, чувствительные персональные данные, автоматизированные решения с существенными последствиями, непрерывный мониторинг или значимые новые передачи данных третьим сторонам.
27. Управление инцидентами безопасности
Подозреваемый инцидент безопасности или конфиденциальности должен проходить: Detected → Contained → Investigated → Assessed → Remediated → Documented. Там, где это требуется законом, затронутые лица или компетентные органы должны быть уведомлены в применимые сроки. Доказательства инцидента должны сохраняться в объёме, достаточном для расследования.
28. Управление инцидентами ИИ
К инцидентам ИИ относятся существенные события, связанные с небезопасным автономным исполнением, значимым раскрытием конфиденциальных данных, систематически вредоносным выводом, обходом мер безопасности, существенным сбоем модели или несанкционированным действием агента. Инциденты ИИ должны оцениваться отдельно от обычных ошибок приложения, если поведение ИИ существенно способствовало событию.
29. Права пользователей и контроль
IuVeAI должен предоставлять механизмы, требуемые применимым законодательством о защите данных, чтобы пользователи могли осуществлять соответствующие права в отношении своей персональной информации, которые могут включать доступ, исправление, удаление, ограничение, возражение, портативность и отзыв согласия. Перед выполнением запроса, затрагивающего частную информацию аккаунта, может потребоваться проверка личности. Процедурные детали изложены в Политике конфиденциальности.
30. Хранение данных
Информация не должна храниться бессрочно без определённой цели. Сроки хранения могут различаться в зависимости от функциональности сервиса, конфигурации аккаунта, требований безопасности, договорных требований, правовых обязательств и запросов пользователя на удаление. Удаление из активных систем может немедленно не удалять информацию из защищённых резервных копий, если временное хранение технически необходимо для аварийного восстановления.
31. Удаление данных
Процедуры удаления должны охватывать применимые копии в основных базах данных, файловом хранилище, хранилище бесед, векторных или поисковых индексах, кэшах, производных наборах данных, кандидатных наборах для обучения и резервных копиях, где это технически и юридически уместно. Удаление видимого пользователю объекта не должно оставлять нераскрытую активную копию, используемую для несвязанной обработки.
32. Рамки соответствия
IuVeAI стремится действовать в соответствии с применимыми требованиями и признанными принципами, включая, где уместно: Общий регламент ЕС по защите данных (GDPR); Регламент ЕС об искусственном интеллекте (EU AI Act); применимые требования Молдовы к защите данных; договорные обязательства по обработке данных; принципы privacy-by-design и security-by-design; а также применимые нормы интеллектуальной собственности и авторского права. Применимость отдельных требований зависит от соответствующего сервиса, деятельности по обработке, юрисдикции и роли IuVeAI.
33. Связь с другими политиками IuVe
Настоящая Политика DGRC должна толковаться совместно с Политикой конфиденциальности, Условиями использования, Политикой cookie, Политикой допустимого использования, Политикой ИИ и обучения моделей, применимыми лицензионными условиями Marketplace и продуктовыми политиками.
34. Ответственность за управление
Оператор IuVeAI отвечает за установление рамок управления DGRC. Технические компоненты могут автоматически обеспечивать соблюдение этих рамок, однако ответственность за управление не может быть полностью делегирована модели ИИ. Провайдеры моделей, инфраструктуры и сторонние сервисы остаются ответственными по своим обязательствам в соответствии с применимыми соглашениями и законом.
35. Применение Политики
Нарушение настоящей Политики может повлечь блокировку запроса, отказ в действии агента, отзыв capability, отзыв API-ключа, ограничение аккаунта, административное расследование, приостановку сервиса или эскалацию инцидента. Применение мер должно быть пропорционально тяжести, умыслу и риску.
36. Пересмотр Политики
Настоящая Политика должна пересматриваться при существенных изменениях архитектуры IuVeAI, провайдеров ИИ, возможностей моделей, разрешений агентов, обработки персональных данных, применимого права или угроз безопасности. Формальный пересмотр также должен проводиться периодически, даже если существенных изменений не выявлено.
37. Основное правило DGRC
IuVeAI следует одному главному принципу управления: Возможность не равна полномочию.
Система ИИ может получать доступ к данным, использовать инструменты или выполнять действия только тогда, когда выполнены необходимые условия идентичности, разрешения, политики и риска.
Data → Authority → Policy → AI → Action → Verification → Audit
Эта цепочка контроля составляет основу подотчётного исполнения ИИ в IuVeAI.
Контакты
По вопросам настоящей Политики обращайтесь к оператору по реквизитам выше или по адресу hello@iuve.eu.