Тендеры и лиды
Информация
Сотрудники используют нейросети для текстов, документов, кода, изображений и анализа данных, поэтому бизнесу важно знать, какие ИИ-сервисы уже вошли в рабочие процессы и какая информация туда попадает. Проверка фактического использования помогает определить разрешённые сценарии, ограничения по данным и порядок контроля результата.
Эти требования закрепляют в корпоративном регламенте и распределяют ответственность между IT/ИБ, руководителями подразделений, HR и специалистами, которые работают с ИИ. Актуальную редакцию хранят в корпоративной базе знаний или таск-менеджере и пересматривают при появлении новых инструментов и способов работы с ними.
Корпоративный регламент устанавливает границы работы с нейросетями, чтобы сотрудники не определяли самостоятельно, какими сервисами пользоваться, какие рабочие данные туда передавать и как применять полученный результат. Документ также фиксирует, кто проверяет ответы ИИ, какие действия требуют участия человека и куда сообщать об ошибке или утечке данных.
Один и тот же сервис может использоваться в разных рабочих ситуациях. Подготовка заголовков по опубликованным материалам требует одних ограничений, а анализ клиентского договора или внутреннего кода — других. Правила лучше привязывать к конкретному сценарию: сервису, рабочей задаче, передаваемым данным, результату и способу его проверки.
Регламент также должен учитывать работу с чужими текстами, фотографиями, иллюстрациями, дизайном и программным кодом. Сотрудник может загрузить такой материал в нейросеть и получить на его основе новый результат, поэтому перед публикацией проверяют права на исходник, условия его использования и правила самого ИИ-сервиса. Российское авторское право распространяется, в частности, на произведения и программы для ЭВМ, включая исходный код.
Проверку начинают с инвентаризации сервисов, аккаунтов, рабочих задач и данных, которые команда уже передаёт нейросетям. Информацию можно собрать через опрос сотрудников и сведения IT/ИБ о корпоративных инструментах и подключённых интеграциях.
В список заносят название сервиса, тип аккаунта, подразделение, рабочую задачу, входные данные и получаемый результат. Реестр должен учитывать и внешние платформы, и внутренние корпоративные ИИ-инструменты, которые уже участвуют в рабочих процессах.
Начальную информацию удобно собрать в таблице:
Тип аккаунта фиксируют отдельно, потому что личная и корпоративная версии одной платформы могут иметь разные настройки доступа, хранения истории и обработки информации.
Рабочий сценарий описывают через сотрудника, задачу, сервис, входные данные и дальнейшее использование результата. Маркетолог готовит варианты рекламного текста, разработчик работает с кодом, HR редактирует вакансию, а специалист поддержки составляет черновик ответа клиенту.
Одна модель может участвовать в процессах с разным уровнем риска. Генерация заголовков по открытым материалам отличается от анализа договора с персональными данными, хотя специалист использует один инструмент.
Для каждого сценария фиксируют:
кто использует ИИ;
какую задачу решает;
какой сервис и тип аккаунта использует;
какую информацию передаёт;
какой результат получает;
кто проверяет ответ;
как результат используется дальше.
Такая карта показывает весь путь от исходной рабочей задачи до применения ответа нейросети и помогает устанавливать правила не для технологии в целом, а для конкретного процесса.
В каждом сценарии нужно определить содержание запросов, документов, изображений, таблиц, кода и других материалов, которые попадают в ИИ. Среди них могут быть открытые публикации, внутренние инструкции, сведения о клиентах, договоры, финансовые данные, исходный код, пароли или API-ключи.
Персональные данные требуют отдельного контроля. Статья 6 № 152-ФЗ устанавливает условия их обработки и предусматривает отдельные требования к передаче обработки другому лицу. Доступ сотрудника к информации внутри CRM или кадровой системы сам по себе не даёт оснований отправлять эти сведения внешнему сервису.
ИИ-сервис для рабочих задач выбирают по условиям обработки данных, уровню безопасности и соответствию конкретному сценарию. Качество генерации тоже проверяют, но хороший ответ модели сам по себе не показывает, насколько безопасно передавать платформе корпоративную информацию.
Компания изучает политику конфиденциальности, пользовательское соглашение, условия корпоративного тарифа и документы по безопасности. Проверка должна показать, как поставщик хранит запросы, использует загруженную информацию и управляет доступом к ней.
Для каждого сервиса проверяют:
использование запросов и файлов для обучения моделей;
возможность отключить такое использование;
место и срок хранения информации;
порядок удаления истории, запросов и файлов;
передачу сведений третьим сторонам;
правила обработки персональных данных;
условия для личных и корпоративных аккаунтов;
шифрование данных при передаче и хранении;
разграничение пользовательских прав;
двухфакторную аутентификацию;
журналирование действий и доступа;
условия технической поддержки и доступности сервиса.
Последний пункт особенно важен для процессов, которые зависят от постоянной работы ИИ. Компания может проверить SLA — закреплённый поставщиком уровень доступности и поддержки, например гарантии по времени работы сервиса и срокам реакции на сбои.
В перечне разрешённых сервисов фиксируют инструмент, тип аккаунта, допустимые задачи и условия использования. Простая запись «сервис X разрешён» не показывает сотруднику, с какой информацией и для каких действий он может использовать платформу.
Рабочая формулировка может выглядеть так:
Сервис X используется через корпоративный аккаунт для подготовки черновиков по открытым материалам. Персональные данные, клиентские документы и сведения с режимом коммерческой тайны не передаются без отдельно согласованного сценария.
Реальные условия зависят от платформы, тарифа, договора и внутренней классификации информации. У реестра назначают владельца, который обновляет перечень после подключения нового инструмента, изменения условий поставщика или запрета ранее разрешённого сервиса.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13691 тендер
проведено за восемь лет работы нашего сайта.
В корпоративном регламенте фиксируют область действия, разрешённые сервисы и сценарии, правила работы с данными, проверку результата, ограничения на автоматические решения, действия при нарушениях и зоны ответственности. В начале документа также указывают владельца, дату утверждения, текущую редакцию и срок следующего пересмотра.
Регламент должен прямо определять сотрудников и рабочие процессы, для которых действуют требования. Общие положения можно установить для всей организации, а дополнительные инструкции — для конкретного отдела, подрядчиков, стажёров или участников отдельного проекта.
Отдельное правило нужно установить для личных аккаунтов. Компания фиксирует, допускаются такие учётные записи в рабочих целях или нет, а также определяет категории информации, доступные для такого режима.
В регламенте указывают утверждённые сервисы или дают ссылку на актуальный корпоративный реестр. Для каждого решения фиксируют аккаунт, допустимые задачи и условия использования.
Список разрешённых сервисов компания составляет после проверки каждого инструмента и сценариев его использования.
В разрешённые ИИ-сервисы можно загружать открытые материалы и те внутренние данные, для которых компания заранее утвердила такой сценарий использования. Персональные данные, коммерческая тайна и другая защищённая информация требуют отдельных правил и не должны автоматически считаться разрешёнными.
Базовый перечень данных, которые нельзя передавать ИИ-сервисам без отдельного согласования, включает:
персональные данные без установленного основания и порядка обработки;
специальные и биометрические персональные данные;
клиентские документы с закрытой информацией;
пароли и одноразовые коды;
токены и API-ключи;
платёжные сведения;
коммерческую тайну;
конфиденциальные материалы, передачу которых ограничивает договор или внутренний порядок.
Коммерческая тайна имеет отдельный правовой режим. Статья 10 № 98-ФЗ предусматривает перечень мер: компания определяет охраняемые сведения, ограничивает доступ, учитывает лиц с доступом и регулирует использование такой информации сотрудниками и контрагентами.
Перед отправкой данных в ИИ нужно удалить или заменить сведения, по которым можно определить конкретного человека. В первую очередь убирают ФИО, контакты, адрес, номер заказа или договора, реквизиты, точную должность и другие идентификаторы, которые не нужны для выполнения задачи.
Компании с регулярной обработкой персональных данных могут закрепить единый порядок обезличивания, чтобы сотрудники не выбирали способ самостоятельно.
Результат нейросети проверяют по исходным данным, первичным источникам и правилам конкретной рабочей задачи. Текст сверяют с фактами и документами, расчёты — с исходными значениями, код — через ревью и тестирование, а ответ клиенту — с информацией из основной рабочей системы.
Тексты, изображения и код перед внешней публикацией дополнительно проверяют на права использования. Например, сотрудник может загрузить в сервис чужую фотографию, фрагмент статьи или исходный код и получить результат на их основе; перед публикацией нужно проверить допустимость использования исходника, полученного материала и условия конкретной платформы.
Регламент также должен назначать проверяющего. Конкретный сотрудник или роль отвечает за финальную проверку перед публикацией, отправкой клиенту, использованием кода или внесением результата в рабочую систему.
ИИ нельзя полностью передавать решения о найме, увольнении, оценке кандидатов и сотрудников, а также другие действия, которые могут повлиять на права клиентов или работников. В таких сценариях нейросеть может подготовить анализ, справку или рекомендации, но окончательное решение принимает человек.
Регламент должен фиксировать, на каком этапе требуется обязательная проверка человеком и кто принимает итоговое решение.
Сотрудник должен сразу сообщить о нарушении ответственному специалисту или в установленный канал для инцидентов. При случайной загрузке персональных данных, использовании запрещённого сервиса или передаче ключа доступа не нужно пытаться самостоятельно оценивать серьёзность ситуации.
Ответственная команда выясняет:
какие сведения были переданы;
какой сервис и аккаунт использовались;
кто мог получить доступ к информации;
можно ли удалить данные или остановить дальнейшую обработку;
нужно ли заменить пароль, токен или другой секрет доступа;
какие технические и юридические действия нужны дальше.
Зоны ответственности за выбор и использование ИИ-сервисов, работу с данными, проверку результатов и соблюдение корпоративного регламента компания распределяет между IT/ИБ, ответственным за персональные данные или юристом, руководителями подразделений, HR и сотрудниками. Отдельный владелец регламента отвечает за актуальность документа и запускает его пересмотр.
IT/ИБ отвечает за техническую безопасность ИИ-сервисов, корпоративные аккаунты, права доступа и интеграции. Специалисты настраивают двухфакторную аутентификацию, шифрование данных, журналирование действий и разграничение доступа по ролям.
Подключение нейросети к CRM, внутренней базе или другой корпоративной системе требует отдельной проверки. IT/ИБ определяет, какие данные видит сервис, какие действия ему доступны и как ограничить его права.
В корпоративной инфраструктуре для защиты также используют системы обнаружения и предотвращения вторжений IDS/IPS и другие средства информационной безопасности. Требования к работе с ИИ-сервисами можно дополнительно сверять с действующей в компании системой управления информационной безопасностью и стандартом ISO/IEC 27001.
Компании с повышенными требованиями к хранению внутренних данных могут использовать решения, которые разворачиваются в собственной инфраструктуре. Например, Strive Box, коробочная версия Strive, размещается на серверах компании.
Сервис, который работает только с отдельной выгрузкой, и инструмент с доступом к внутренним системам требуют разного уровня контроля. Чем шире доступ, тем строже должны быть настройки и проверка перед подключением.
Юрист или ответственный за организацию обработки персональных данных проверяет правовые основания, условия договора с поставщиком и передачу регулируемой информации. Эта роль особенно важна для процессов с данными клиентов, сотрудников и кандидатов.
Специалист также проверяет требования к трансграничной передаче персональных данных и условия, на которых поставщик ИИ-сервиса может обрабатывать их от имени компании.
Руководитель подразделения определяет рабочий сценарий: цель использования ИИ, входные данные, ожидаемый результат и способ проверки. Владелец процесса также оценивает последствия ошибки и назначает конкретного проверяющего.
HR организует ознакомление с регламентом и включает правила работы с ИИ в адаптацию сотрудников. Обучение также должно охватывать базовые требования информационной безопасности и порядок сообщения об инцидентах.
Сотрудник использует разрешённый сервис по утверждённому сценарию, соблюдает ограничения по данным и проверяет полученный результат. Новый или непонятный способ применения инструмента передаётся на согласование.
Ошибочную передачу данных, нарушение доступа или другой инцидент сотрудник сообщает по установленному внутреннему каналу. Ответ модели не заменяет профессиональную проверку и не снимает ответственность за последующее рабочее действие.
Сотрудников знакомят с новым регламентом через публикацию актуальной версии, обязательное ознакомление в установленном порядке и обучение по рабочим ситуациям. Существенные изменения в документе повторно доводят до тех сотрудников и подразделений, которых они затрагивают.
Регламент в таск-менеджере или базе знаний в первую очередь помогает хранить и объяснять правила. Если компания хочет закрепить эти требования как обязательный локальный нормативный акт, документ нужно оформить по правилам трудового законодательства и ознакомить с ним сотрудников под роспись. Само размещение регламента в системе или прохождение теста такой порядок не заменяет.
Тестирование можно использовать отдельно для проверки понимания. Вопросы лучше строить вокруг реальных ситуаций: можно ли загрузить клиентский договор в ИИ, какие сведения нужно обезличить, как проверить ответ и куда сообщить о нарушении.
Регламент по использованию ИИ удобно хранить в одной системе с рабочими инструкциями и задачами сотрудников. Например, в корпоративном таск-менеджере Strive регламенты и инструкции можно распределять по пространствам и проектам, связывать с задачами на ознакомление и дополнять тестами для проверки знаний.
На примере Страйв рассмотрим, как подготовить регламент по использованию ИИ, открыть его нужным сотрудникам, связать с рабочими задачами и проверить, насколько команда усвоила правила.
Собрать и согласовать черновик регламента
Черновик собирают из действующих правил информационной безопасности, должностных и рабочих инструкций, требований к персональным данным и реальных сценариев использования ИИ.
Регламент задаёт общий порядок, должностная инструкция закрепляет обязанности конкретной роли, а рабочая инструкция описывает действия в отдельной ситуации.
В Strive первоначальный текст регламента можно подготовить через ИИ-ассистента, который работает с внутренней документацией. Ответственные специалисты затем проверяют содержание и согласовывают рабочую редакцию.
Сотрудникам открывают уже согласованный вариант документа. Черновые формулировки не должны восприниматься как действующее разрешение или запрет.
Определить, для кого действует документ
Регламент размещают в рабочих областях подразделений или групп, которым нужны эти правила. Пространства в Strive используются для отделов и направлений, а один регламент можно добавить в несколько пространств.
Общие требования можно открыть всей организации, а узкие инструкции — разработке, HR, маркетингу или другой рабочей группе. Компания с проектной структурой может привязать документ к области, где работает нужная команда.
Разделить регламент по рабочим вопросам
Регламент лучше разделить по вопросам, которые возникают у сотрудника во время использования ИИ:
область действия;
разрешённые сервисы и аккаунты;
разрешённые сценарии;
допустимые данные;
запрещённые сведения;
обезличивание;
проверка результата;
согласование нового сервиса или сценария;
действия при инциденте;
ответственные и контакты.
Более узкие должностные и рабочие инструкции можно хранить рядом с основным документом. Такая структура сохраняет общий регламент компактным и не смешивает правила всей компании с частными процессами отдельных отделов.
Следить за изменениями в регламенте
В Strive можно посмотреть историю изменений регламента и информацию о редакторе. Эта история помогает установить контекст правок, когда меняется список сервисов, порядок обработки данных или требования к проверке результата.
Самому документу также стоит присваивать понятную редакцию и дату изменения. Сотрудники в таком случае видят, какие правила действуют сейчас, а владелец регламента понимает, когда документ нужно пересмотреть.
Поставить задачу на ознакомление
Руководитель ставит сотруднику отдельную задачу изучить регламент до начала работы по новым правилам. В карточке указывают срок, добавляют ссылку на документ и конкретное действие: ознакомиться с требованиями и пройти проверку знаний.
Такой сценарий подходит для онбординга, подключения нового ИИ-сервиса и изменения действующих правил. В Strive задачи можно вести вместе с документацией и добавлять ссылки на регламенты и инструкции из базы знаний.
Проверить знание правил
Знание регламента проверяют на ситуациях, которые встречаются в работе. Тест может содержать вопросы о загрузке договора клиента, обезличивании обращения, проверке ответа модели и действиях после случайной передачи персональных данных.
К регламентам в Strive можно добавлять встроенные тесты и отслеживать их прохождение.
Тест показывает понимание требований, но сам по себе не является локальным нормативным актом. Юридическое ознакомление компания оформляет отдельно, когда этого требует статус документа.
Для согласования нового ИИ-сервиса или сценария сотрудник описывает рабочую задачу, инструмент, тип аккаунта, входные данные, требуемый результат и способ его дальнейшего использования. Ответственные специалисты на основе этой информации принимают одно из решений: разрешают сценарий, устанавливают ограничения или отказывают в использовании.
Проверку распределяют по зонам ответственности:
IT/ИБ оценивает доступы, интеграции и техническую безопасность;
руководитель процесса определяет рабочую необходимость, последствия ошибки и способ проверки результата;
юрист или ответственный за персональные данные проверяет договорные и законодательные ограничения;
владелец регламента фиксирует принятое решение.
Сложный сценарий с чувствительными данными или широкими правами доступа можно сначала запустить в ограниченном пилоте. Тестовый запуск позволяет проверить качество результата, набор доступов, возможные ошибки и влияние на рабочий процесс до массового использования.
Итоговое решение вносят в реестр разрешённых сервисов и сценариев.
Регламент пересматривают по установленному графику и после значимых изменений сервиса, данных или рабочего процесса. Владелец документа отвечает за новую редакцию, обновление связанных инструкций и повторное ознакомление нужных сотрудников.
Внеплановый пересмотр нужен в нескольких ситуациях:
появился новый ИИ-сервис;
изменился тариф или тип аккаунта;
поставщик обновил политику конфиденциальности или условия обработки данных;
команда начала использовать новый рабочий сценарий;
изменились категории передаваемой информации;
нейросеть получила доступ к внутренней системе;
произошёл инцидент;
сотрудники регулярно задают один и тот же вопрос о непонятном правиле;
изменились внутренние требования или законодательство.
Плановый срок пересмотра организация устанавливает самостоятельно. Инциденты, обращения сотрудников и заявки на новые инструменты тоже стоит учитывать при ревизии, потому что повторяющиеся ситуации показывают устаревшие или недостаточно конкретные пункты.
Новая редакция должна менять и связанные рабочие процессы. Запрещённый сервис убирают из реестра, изменившиеся ограничения переносят в инструкции, а существенные правки доводят до сотрудников.
