# Грантовый GPU: что включить в описание удалённого доступа для согласования

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

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/gpu-grant-remote-access-appendix/
Language: ru

В описание удалённого доступа к грантовому GPU стоит включить участников, разрешённые действия, срок, затрагиваемые данные и порядок отзыва прав. Такой технический документ помогает согласованию быть предметным. Он не заменяет решение владельца и проверку условий конкретного гранта.

Не начинайте с передачи пароля или полного внутреннего договора. Сначала достаточно общего паспорта конфигурации и проекта границ доступа. Если предполагаемый сценарий не допускается программой или организацией, техническая возможность подключения не устраняет это ограничение.

## Назовите цель доступа

Опишите конкретную задачу: сбор характеристик, настройка тестовой среды или согласованный запуск. Формулировка «обслуживание AI» слишком широка, если за ней могут скрываться изменение драйверов, работа с файлами и перезапуск машины.

[Европейская комиссия](https://commission.europa.eu/funding-and-tenders/managing-your-project/managing-your-project-under-grant-agreement_en) рассматривает права и обязанности проекта в контексте грантового соглашения. Это пример необходимости проверять документы своей программы, а не универсальное разрешение на внешнюю нагрузку. Техническое приложение лишь помогает описать, что именно предлагается согласовать.

## Сделайте матрицу действий

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

| Действие | Ресурс | Граница |
| --- | --- | --- |
| Чтение характеристик | Согласованный узел | Без исследовательских файлов |
| Тестовая задача | Выделенное окружение | Синтетические данные |
| Изменение среды | Названный компонент | Отдельное согласование |
| Завершение | Выданные разрешения | Проверяемый отзыв |

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

## Отделите данные исследования

Назовите каталоги, сервисы и проекты, которые не относятся к пилоту. Если отделить их технически пока нельзя, это важный вопрос до выдачи доступа. Не считайте обещание «не открывать файлы» достаточным описанием архитектуры границы.

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

## Определите срок и отзыв

[OpenSSH sshd](https://man.openbsd.org/sshd) описывает механизм ключевой аутентификации и ограничения разрешённых ключей. Конкретная конфигурация должна соответствовать правилам администратора. Приватный ключ не является частью технического приложения и не должен попадать в общую переписку с описанием проекта.

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

## Сохраните решение отдельно

В финальном комплекте полезно иметь версию технического описания, статус согласования и ответственного. Если меняется задача или ресурс, нужно понимать, относится ли прежнее решение к новому сценарию. Нельзя молча расширять перечень действий после одобрения узкого теста.

Полезны [чек-лист грантового оборудования](/ru/journal/grant-checklist/) и [границы исследовательских данных](/ru/journal/research-data-boundaries-gpu/). Конкретный пилот возможен только в согласованном допустимом формате.