Паспорт ИИ-системы — в этой статье так называется внутренняя карточка одного уже используемого применения ИИ. Она связывает назначение, состав решения, известные версии и ответственных с подтверждающими материалами. По карточке коллега должен понять, какой именно помощник работает в процессе и какие сведения о нём ещё предстоит уточнить.
Ниже — редакционный шаблон для руководителя, ИТ и L&D. Это способ описания, а не официальный документ о соответствии или разрешение на запуск. Название «паспорт» не означает, что существует единая обязательная форма. Состав полей и доступ к ним организация определяет сама.
Чем паспорт отличается от реестра задач и политики?
Реестр задач помогает выбрать, какую работу имеет смысл изменить. Политика устанавливает общие условия использования ИИ. Паспорт отвечает на другой вопрос: что представляет собой конкретное действующее решение на дату описания. Даже одинаковое название приложения не делает два рабочих подключения одной системой для целей учёта.
Представьте условную ситуацию: в отделе есть помощник для черновиков внутренних памяток. Один сотрудник имеет в виду общий веб-интерфейс, другой — подключение к внутренним документам. В разговоре оба говорят «наш помощник». Карточка должна развести эти объекты, а не объявить их одинаковыми по имени поставщика.
Для выбора будущих применений используйте реестр задач для ИИ. Здесь исходная задача уже определена: собрать описание существующего применения и передать его человеку, который не участвовал в настройке. Решение о пригодности или расширении доступа остаётся за уполномоченными участниками.
NIST в разделе GOVERN 1.6 Playbook описывает учёт ИИ-систем как организованную базу связанных с системой или моделью материалов. Среди возможных сведений названы документация, планы реагирования на инциденты, словари данных, ссылки на реализацию и контакты участников. Там же предлагается определить ответственного за поддержание учёта. Наш шаблон — редакционный вариант небольшой карточки внутри такого учёта, а не перевод установленной NIST формы.
Факт. AI RMF и Playbook предназначены для добровольного применения. NIST позволяет организациям выбирать подходящие рекомендации; наличие заполненной карточки не подтверждает соответствие закону или безопасность решения.
Расскажите, чему хотите научить команду. Обсудим задачи и формат обучения.
Сначала назовите объект и его границу
Дайте записи устойчивый внутренний идентификатор. Например, «Памятки отдела / веб-помощник / запись А-01» — условное обозначение для упражнения. Идентификатор нужен, чтобы ссылки из инструкции, протокола проверки и сообщения об ошибке указывали на одну запись. Не включайте в открытое название секреты или сведения, доступные только узкому кругу сотрудников.
Рядом укажите отображаемое название, подразделение и назначение. Поле назначения заполните предложением: кто получает какой материал и для какого следующего действия. В нашем вымышленном примере: «Редактор получает черновик памятки по утверждённому учебному тексту и передаёт его на ручную сверку». Из этой записи нельзя вывести разрешение отвечать клиентам или менять документы автоматически.
Затем опишите исключения. Вместо общего «для документов» запишите границу: только учебные памятки, без клиентских файлов, без отправки адресатам. Это условия вымышленной ситуации, не универсальное правило для всех систем. В реальной карточке ограничения переносят из доступных решений организации с указанием основания.
Неизвестное оставляйте неизвестным.
Если участники не могут подтвердить, подключены ли внутренние документы, не ставьте «нет». Запишите вопрос, источник ожидаемого ответа и ответственного за уточнение. Пустое поле и подтверждённое отсутствие подключения означают разные вещи. Такая разница особенно важна при передаче карточки новому сотруднику.
Схема показывает три части редакционной карточки. Она не изображает инфраструктуру конкретной компании.
Как описать состав и версии без догадок?
Для нашего шаблона разделите сведения о приложении, способе доступа, подключённых материалах и настройках. Не нужно превращать сотрудника в исследователя внутреннего устройства модели. Записывайте только то, что подтверждается доступной документацией, настройкой или ответом ответственного специалиста.
Версия карточки и версия модели — разные поля. «Карточка 2» означает изменение описания; она ничего не говорит о модели. Название в интерфейсе тоже не доказывает точную техническую сборку. Если поставщик её не раскрывает или составитель не имеет нужного доступа, сохраните это ограничение и дату наблюдения.
Вместо «последняя версия» полезнее указать наблюдаемое значение и его основание. В условном упражнении: «В интерфейсе отображается обозначение X; проверено участником ИТ по снимку настроек из учебного комплекта; номер сборки неизвестен». Буква X здесь вымышлена. Она не описывает реальный продукт и не подтверждает его возможности.
Составьте строки для компонентов, которые действительно есть в вашем объекте. Для каждого — обозначение, назначение, известная редакция, источник и дата проверки. Если запрос к внешнему сервису проходит через внутреннее приложение, не подменяйте описание всей цепочки только названием сервиса. Попросите ИТ обозначить границу, которую можно документировать для данной аудитории.
В паспорт можно включить ссылку на утверждённый набор инструкций или список источников знаний. Сами документы не копируйте автоматически: сначала уточните доступ и допустимый состав записи. Подготовка корпуса описана отдельно в материале о базе знаний для ИИ. Здесь достаточно связи с конкретной редакцией и её владельцем.
Свяжите каждое поле с основанием
В предлагаемой карточке у значимого сведения есть четыре части: значение, откуда оно взято, кто подтвердил и когда. Так составитель отделяет собственное наблюдение от чужого решения. Ссылка на протокол может подтверждать условия применения, но не фактическое состояние настройки сегодня.
Например, запись «подключение к каталогу отключено» требует основания о состоянии подключения. Утверждённый список разрешённых источников отвечает на другой вопрос — что разрешено. Если эти документы расходятся, сохраните обе записи и передайте расхождение ответственному. Не исправляйте содержание протокола догадкой о том, что, вероятно, хотел сказать его автор.
Для учебного паспорта предлагаем следующие поля:
| Поле | Что записать | Что не считать подтверждением |
|---|---|---|
| Объект | Идентификатор и способ использования | Одно название поставщика |
| Назначение | Материал, получатель, граница применения | Общее «работа с текстом» |
| Состав | Известные компоненты и связи | Предположение об архитектуре |
| Редакции | Наблюдаемые обозначения и даты | Слово «актуальная» без основания |
| Ответственность | Владелец записи и источники уточнений | Имя последнего загрузившего файл |
| Основания | Ссылки на доступные подтверждения | Непроверенная устная догадка |
| Пробелы | Неизвестное и следующий запрос | Пустая строка, прочитанная как «нет» |
Это список для упражнения. Организация может объединить поля или добавить необходимые сведения. Не объявляйте карточку полной только потому, что все ячейки заполнены: проверьте, что значения относятся к одному объекту и одной границе описания.
Секреты доступа в паспорт не включайте. Вместо пароля или ключа укажите ответственного за доступ и принятый организацией маршрут запроса. Если сама схема компонентов ограничена в распространении, карточке для обучения достаточно согласованного описания и ссылки на владельца закрытой части.
Условный пример: передача помощника новому куратору
На занятии участники получают вымышленный комплект: описание помощника для памяток, учебный снимок настроек, решение о допустимых материалах и старую карточку. В старой карточке указано «все внутренние инструкции», а в решении — только согласованный учебный текст. Отдельно известно, что интерфейс показывает обозначение X. Номер технической сборки во вводных отсутствует.
Группа не должна придумывать недостающие данные. Её результат — карточка А-01 с границей применения, наблюдаемым обозначением X и открытым вопросом о технической версии. Широкую фразу из старой карточки отмечают как расхождение с данным в упражнении решением. Статус уточнения сохраняют до ответа роли владельца процесса.
Теперь выдайте второй учебный материал: сообщение ИТ, что появился другой способ подключения. Этого недостаточно, чтобы тихо заменить адрес в прежней карточке. Сначала нужно выяснить, относится ли сообщение к объекту А-01 или к отдельному применению. В нашем упражнении составитель записывает вопрос о границе объекта, а не принимает решение о доступе за ИТ.
Три статуса в примере относятся к разным сведениям. Наблюдение интерфейса не выдаётся за подтверждение внутренней конфигурации.
Передайте результат участнику, который не видел исходные обсуждения. Попросите его найти объект А-01, объяснить разрешённую в учебных вводных задачу и назвать два вопроса, которые нельзя решить по карточке. Если он решает, что помощнику разрешена работа со всеми документами, вернитесь к формулировке ограничения и её основанию.
Цель задания — точное чтение и передача описания. Не нужно подключать настоящий сервис, открывать доступ к рабочим данным или проверять производственную систему ради упражнения. Синтетический комплект позволяет оценить именно согласованность записей.
Как поддерживать карточку при изменениях?
Предлагаем отделить исправление описания от изменения самого решения. Опечатка в имени владельца и новый источник знаний — разные события. В журнале карточки запишите, что именно изменилось: текст записи, наблюдаемая конфигурация или подтверждённые условия применения. Если основания пока нет, отметьте запрос на уточнение.
Сохраните предыдущую редакцию и связь с новой. Укажите дату, составителя и причину изменения. В нашем шаблоне это позволяет коллеге понять, почему старое описание больше не используется. Сроки хранения и доступ к редакциям организация определяет по собственным правилам; статья не устанавливает их за неё.
При обновлении модели не переносите автоматически старое описание возможностей на новую конфигурацию. Карточка фиксирует наблюдаемые сведения и ссылки на проверки. Решение о необходимости новых испытаний принимают ответственные за этот процесс. Само исправление строки «версия» не подтверждает, что испытания проведены или применение разрешено.
Мнение. Для передачи работы полезнее короткая карточка с проверяемыми ссылками и явным пробелом, чем подробный текст, в котором невозможно отличить факт от предположения. Объём записи сам по себе не показывает качество учёта.
Назначьте владельца карточки и маршрут сообщений об устаревших сведениях. NIST GOVERN 1.6 предлагает определить человека или команду, отвечающих за поддержание учёта систем. Конкретное распределение обязанностей ниже уровня этой рекомендации — решение организации. L&D может организовать учебный разбор карточки, но это не делает его владельцем технических настроек.
Как понять, что описание можно передавать коллеге?
Проверьте карточку с двумя разрешёнными материалами: основанием назначения и доступным описанием состава. Они должны относиться к одному объекту. Затем откройте ссылки от имени предполагаемого получателя, если такая проверка согласована. Существующий файл, на который у коллеги нет доступа, не выполняет роль доступного ему подтверждения.
Попросите получателя ответить: что это за применение, где его граница, какое обозначение версии известно и кому задать вопрос об оставшемся пробеле. Не подсказывайте ответ из устного контекста. Если без подсказки человек объединяет два разных подключения, уточните идентификатор и способ использования.
Следующий шаг — выбрать одно существующее применение и собрать его карточку из разрешённых сведений. Перед передачей покажите владельцу процесса спорные поля. Если команде нужен общий навык описания и проверки таких материалов, опишите задачу корпоративного обучения AURMIND: кто будет вести карточки, какие сведения сотрудникам доступны и что они должны уметь объяснить по готовой записи.
Частые вопросы
Нужно ли заводить паспорт на каждый аккаунт?
В этом шаблоне единица учёта — согласованное применение и его конфигурация. Как соотносятся аккаунты, приложения и рабочие сценарии, определяет организация. Составитель не должен объединять их только по одинаковому логотипу или названию.
Что писать, если точная версия модели неизвестна?
Укажите доступное наблюдаемое обозначение, дату и источник. Точный номер оставьте неизвестным с пояснением границы доступа или раскрытия. Не заменяйте пробел словом «последняя» и не выводите техническую версию из качества ответа.
Может ли нейросеть заполнить карточку за сотрудника?
Для учебного разбора можно дать ей разрешённые вводные и попросить разложить сведения по полям, сохраняя ссылки и неизвестное. Такой черновик участник сверяет с вводными. Текст, который выдала модель, сам по себе не служит подтверждением настроек, разрешений или выполненных проверок.
Достаточно ли карточки для допуска системы к работе?
Нет. Карточка описывает объект и основания сведений. Она не заменяет решения уполномоченных участников, технические проверки и применимые требования. В нашем упражнении заполнение карточки вообще не предполагает реального запуска.
Источники
- NIST AI RMF Playbook — добровольный характер рекомендаций.
- NIST AI RMF: ответы на вопросы — назначение рамки и контекст её применения; не источник обязательной формы паспорта.
- NIST Playbook: GOVERN — раздел 1.6: учёт систем, возможные материалы и ответственность за поддержание записей.
