Публичные
Сайты, открытые тендеры, публичные реестры. Обычный рабочий режим.
Работаем с коммерчески значимой информацией компаний и определяем правила защиты до начала интеграции: какие данные нужны, где они обрабатываются, кто получает доступ и когда данные удаляются.
Первичную задачу можно обсуждать без передачи чувствительных массивов. Если для пилота нужны внутренние материалы, до получения данных определяем категории, цель, минимально необходимый объём, канал передачи, внешние сервисы, права доступа, срок хранения и порядок удаления.
Режим зависит не от названия файла, а от содержания, требований заказчика и применимых правовых условий.
Сайты, открытые тендеры, публичные реестры. Обычный рабочий режим.
Регламенты, рабочие отчёты, инструкции. Ограниченный проектный доступ.
Цены, КП, продажи, CRM, стратегия, договоры. Согласованный канал и минимальный доступ.
ФИО, контакты и иные сведения о физлицах. Отдельная правовая и техническая оценка обработки.
Конкретная схема фиксируется для каждого проекта. Если требования заказчика запрещают передачу определённых данных внешнему провайдеру, архитектура учитывает это до начала разработки.
До подключения внешнего ИИ/API проверяем условия провайдера: хранение, использование данных для обучения, retention, регион обработки и доступные корпоративные режимы. Передаём только минимально необходимый контекст.
Публичная форма сайта предназначена только для первичного контакта. После согласования используем контролируемую папку с ограниченным доступом, SFTP, защищённое корпоративное хранилище или зашифрованный архив с передачей пароля по отдельному каналу — в зависимости от проекта.
Фиксируем владельца данных, категории, источник, цель, необходимый объём, место обработки, внешние ИИ/API, роли, срок хранения, резервирование, возврат/удаление и порядок действий при инциденте.
На сайте используем формулировку «коммерчески значимая и конфиденциальная информация». Термин «коммерческая тайна» применяем только с учётом режима, установленного самим обладателем информации.
Если проект затрагивает персональные данные, до обработки определяем роли сторон, цели, основания, объём, место обработки и необходимые договорные, организационные и технические меры.
Приостанавливаем затронутую интеграцию или учётную запись.
Определяем обстоятельства и затронутые данные.
Устраняем причину и ограничиваем последствия.
Действуем в порядке договора и применимых требований.
Обновляем меры и карточку обработки данных.
Нет. Для первичной диагностики достаточно описания процесса. Передача внутренних материалов начинается только после определения необходимых данных и согласования канала.
Да. Для проектов с коммерчески значимой информацией это может быть стандартным предварительным шагом.
Это зависит от конкретного провайдера и режима использования. До подключения внешнего ИИ/API проверяем его условия и фиксируем допустимую схему в проекте. Универсального обещания без проверки провайдера не даём.
Да, если это требование проекта. Тогда архитектура должна быть спроектирована с учётом такого ограничения до начала разработки.
Срок и сценарий удаления/возврата фиксируются заранее. Учитываются рабочие копии, временные доступы и резервные копии, если они использовались.
Опишите требования без передачи конфиденциальных файлов. Сначала согласуем режим данных, NDA и безопасный канал.
Разберём задачу без длинной презентации.
Определим, нужен ли ИИ и где будет измеримый эффект.
Если нужны внутренние данные — сначала согласуем безопасный обмен.