Перейти к содержимому
PraktickAI
КурсыДля командУслугиДокументацияБлог
КурсыДля командУслугиДокументацияБлог
ГлавнаяКурсыОграничения для ИИКлассификация данных: решение по цели и подтверждениям
Предыдущий урокСледующий урок
Урок 2 из 625 мин

Классификация данных: решение по цели и подтверждениям

Перейти к разделу
  • Четыре задачи: три приостановить, одну разрешить в заданных пределах
  • Класс определяет организация; разрешение зависит от всего контекста
  • Четыре случая и две карточки подтверждений
  • Что делать, когда подтверждений не хватает

Четыре задачи: три приостановить, одну разрешить в заданных пределах

Вам нужно подготовить краткое резюме с помощью ИИ. Достаточно ли того, что текст открыт для всех или из него удалено имя? Сотруднику или руководителю команды нужно оценить конкретную задачу: какие данные, для какой цели, в какой среде и для кого. Эти четыре случая помогут составить решение, которое можно объяснить и передать ответственному за внутреннее согласование. Три задачи остаются приостановленными; для одной есть подтверждения разрешения в строго заданных пределах.

Организация Javor, её политика J-1, инструмент Lupa, все записи, разрешения и подтверждения в уроке — ВЫМЫШЛЕННЫЕ. Это не рекомендация поставщика и не настоящее согласование. Работайте только с текстом урока и собственными локальными заметками: не запускайте ИИ, другие инструменты, браузер или внешний сервис. Ничего не загружайте. Не ищите реальные документы, персональные данные или учётные данные. Образец ниже — рабочий лист для чтения и заполнения вручную.

Класс определяет организация; разрешение зависит от всего контекста

Каждая организация определяет собственные классы, их значение и ответственные роли. Четыре обозначения здесь — учебный пример, а не универсальный стандарт или юридический тест. Вымышленная политика J-1 использует V — публичные, I — внутренние, D — конфиденциальные и P — строго защищённые данные. V означает материал, предназначенный для публикации; сам этот класс не разрешает любую цель или среду ИИ. Проверьте также контекст, права на использование и аудиторию результата.

Рабочий лист — только ручная симуляция; не отправляйте в ИИ.
Javor, политика J-1, Lupa, подтверждения и данные A–D — ВЫМЫШЛЕННЫЕ.
Используйте только сведения ниже. Ничего не ищите, не выдумывайте согласования и не
  выполняйте задачу в инструменте.

J-1: V = публичные, I = внутренние, D = конфиденциальные, P = строго защищённые.
Запись, которую можно связать с человеком, здесь относится к D даже после замены имени.
Шесть обязательных условий: класс в этой среде; цель и аудитория; права на
  использование; действующий применимый договор; хранение и удаление; доступ и
  настройки.
Для каждого укажите YES / NO / UNKNOWN (нет подтверждения). Любое NO или UNKNOWN =>
  HOLD. ALLOW (только заданная задача) требует шести YES. Не заменяйте UNKNOWN догадкой
  или документацией поставщика.

Вымышленная карточка подтверждений Lupa F1, редакция 1, действительна только в этой
  симуляции:
Подтверждение O-F1/1: внутреннее согласование владельцем данных и службой безопасности
  только для V, резюме из одного предложения для внутреннего использования, аудитория:
  команда Javor. Учётная запись с ролью аналитика в рабочем пространстве Javor, без
  дополнительных интеграций.
Подтверждение S-F1/1: ответственный за договоры подтвердил действующий договор для F1,
  этой цели и класса V, включая все дополнения, требуемые J-1.
Подтверждение R-F1/1: проверенные настройки и договорное обязательство — входные данные,
  результаты и рабочие журналы с содержимым хранятся не более 24 часов, затем удаляются;
  резервных копий с содержимым нет. Лимит J-1 — 24 часа.
Подтверждение P-F1/1: проверенный доступ ограничен ролью аналитика и получателями из
  команды Javor; поставщик не имеет доступа к содержимому, обучение на нём отключено,
  дальнейшей передачи нет. J-1 требует соблюдения этих условий.
Вымышленная карточка Lupa F2, редакция 1: O-F2/1 охватывает I и ту же цель/аудиторию при
  соблюдении всех условий; P-F2/1 подтверждает те же условия доступа, что и F1.
  Подтверждение договора = UNKNOWN; хранения и удаления = UNKNOWN. F1 не подтверждает
  условия F2.

A: «Человек A, единственный реставратор ночной смены в деревне Hvozdná Lhota, смена 17».
  Всё выдумано, но сочетание роли, места и смены в сценарии позволяет связать запись с
  человеком. Запрос: внутреннее резюме из одного предложения для команды Javor в F1.
  Подтверждение владельца U-A/1 устанавливает права на это внутреннее резюме; оно не
  разрешает изменение класса. Остальные подтверждения F1 применяются только в
  собственных пределах.
B: публичное приглашение «День мастерской Javor». Вымышленные условия U-B/1 разрешают
  только чтение; использование для профилирования не разрешено. Запрос: создать профиль
  посетителя в F1 и действительно передать его публичной аудитории вместо внутреннего
  резюме. Текст не подтверждает ни дополнительные права, ни внутреннее согласование этой
  цели.
C: «Испытание бумажной модели: три шага». Внутренняя инструкция, класс I, без сведений о
  людях. Запрос: внутреннее резюме из одного предложения для команды Javor в F2. U-C/1
  подтверждает права на это использование. Договор и хранение остаются UNKNOWN.
D: «Бумажная модель состоит из трёх деталей». Публичный текст каталога, класс V, без
  сведений о людях. Запрос: внутреннее резюме из одного предложения для команды Javor в
  F1. U-D/1 подтверждает права на это использование, а O-D/1 подтверждает, что этот
  текст, цель, аудитория и среда входят в область O-F1/1. Все подтверждения F1
  применимы.

Для КАЖДОГО случая A, B, C, D заполните:
Случай | класс и причина | цель, среда и аудитория | шесть условий со ссылками на
  подтверждения | ALLOW/HOLD | обоснование | недостающие подтверждения (или «нет») |
  следующий шаг внутреннего согласования.
Отличайте известное несоответствие, NO, от неподтверждённого условия, UNKNOWN. Для ALLOW
  укажите пределы разрешения и кто оценивает изменения. Результат — проект записи о
  решении; сам по себе он не даёт разрешения.

I — внутренние: по J-1 это, например, неопубликованные рабочие инструкции без сведений о людях. D — конфиденциальные: сюда также относится запись, позволяющая идентифицировать человека по контексту, а не только по имени. P — строго защищённые: J-1 использует этот класс, например, для секретных учётных данных и особо чувствительных записей. Не добавляйте реальные примеры таких записей в упражнение. Другая организация может использовать иные обозначения, границы и разрешённые процессы; её владелец данных подтверждает классификацию по собственной политике.

Класс — первое условие, а не всё решение. Спросите: разрешён ли этот класс в конкретной среде? Согласованы ли цель и аудитория? Есть ли права на это использование? Подтверждён ли действующий договор для соответствующего варианта сервиса и необходимые дополнения? Известны ли сроки хранения и порядок удаления входных данных, результатов, журналов и резервных копий? Проверены ли доступ и обязательные настройки? Подтверждение вне своей области действия не устанавливает условие; если другого применимого подтверждения нет, укажите UNKNOWN.

Корпоративный тариф, заявление «без обучения на ваших данных» или самостоятельное размещение не заменяют эти условия. Документация поставщика описывает сервис; она не устанавливает внутреннее согласование вашей организации, ваши права на использование или действительность конкретного договора. Не выводите и запрет из одного названия класса: политика и применимые подтверждения определяют, разрешена ли задача. При самостоятельном размещении также нужны решения о доступе, хранении и ответственности. Урок не оценивает конкретный продукт или соответствие реальной организации законодательству.

Правило J-1: шесть YES, подкреплённых подтверждениями, => ALLOW только для описанной задачи. Любое NO или UNKNOWN при отсутствии обязательного подтверждения => HOLD. HOLD означает приостановить предполагаемое использование и передать вопрос ответственной внутренней роли; это не автоматический запрет всего ИИ. Польза инструмента или высокая оценка не компенсируют отсутствующее условие.

Четыре случая и две карточки подтверждений

Рабочий лист содержит полный вымышленный набор A–D и карточки F1/F2. O фиксирует согласованное внутри организации использование, U — права на данные, S — договор, R — хранение и удаление, P — доступ и настройки. Редакция и область действия входят в каждое подтверждение. F1 содержит полные подтверждения для класса V и внутреннего резюме из одного предложения для команды Javor. F2 подтверждает область для I и доступ, но не договор и хранение. Не переносите их из F1. Условное согласование класса и цели в F2 ещё не разрешает выполнение задачи.

A: замена имени на «Человек A» — переименование, а не подтверждение анонимности. По J-1 вымышленная запись остаётся D: контекст позволяет связать её с человеком. F1 разрешает только V: условие класса = NO; A = HOLD. U-A/1 подтверждает права, и цель совпадает, но договор F1 охватывает только V, поэтому подтверждение договора для D = UNKNOWN. Подтверждения хранения и доступа F1 имеются. Чего не хватает: подтверждения договора для D и внутреннего разрешения D в F1; замена имени не даёт ни того, ни другого. Следующий шаг: владелец данных и служба безопасности оценивают возможность идентификации и разрешённый путь; ответственный за договоры оценивает применимую область договора. Пока вопрос не решён, ничего не обрабатывайте.

B: публичное приглашение, класс V. B = HOLD. Класс YES: O-F1/1 охватывает V. Цель NO: публичное профилирование и передача выходят за пределы внутреннего резюме. Права NO: U-B/1 не разрешает профилирование. Договор UNKNOWN: S-F1/1 подтверждает только внутреннюю задачу, не новое использование. Хранение YES: обработка и удаление в F1 не меняются. Доступ NO: фактические публичные получатели и дальнейшая передача противоречат ограничению P-F1/1 на команду Javor. Следующий шаг: владелец данных оценивает цель, ответственный за права — права, ответственный за договоры — применимый договор, ответственный за безопасность/доступ — ограничения получателей и передачи. Запрос не предоставляет публичных прав и не меняет HOLD.

Что делать, когда подтверждений не хватает

C: внутренняя инструкция относится к I; цель, права U-C/1 и доступ P-F2/1 подтверждены, а область F2 охватывает I. Договор = UNKNOWN и хранение = UNKNOWN, поэтому C = HOLD. Чего не хватает: подтверждения действующего применимого договора, включая дополнения, требуемые J-1, и подтверждения сроков хранения и удаления входных данных, результатов, журналов с содержимым и резервных копий. Следующий шаг: ответственный за договоры и служба безопасности проверяют эти сведения, а ответственный за внутреннее согласование завершает условное разрешение F2. Отсутствие подтверждения не доказывает, что поставщик нарушает требование; оно означает, что задача пока не разрешена.

D: публичный текст каталога относится к V, и все подтверждения применимы именно к этому случаю. D = ALLOW: O-D/1 и O-F1/1 устанавливают класс, цель и аудиторию; U-D/1 — права; S-F1/1 — договор; R-F1/1 — хранение; P-F1/1 — доступ. Недостающих подтверждений нет. Следующий внутренний шаг: записать ссылки и область действующего разрешения; J-1 не требует нового согласования для этой заданной задачи. Если меняются данные, цель, аудитория, среда или условия, сначала запросите новую оценку у владельца данных и службы безопасности. ALLOW здесь — результат симуляции, а не указание что-либо запускать.

Составьте запись о решении для A–D

Используйте только вымышленные сведения из рабочего листа. Вручную заполните четыре строки A–D: класс и причина, цель/среда/аудитория, все шесть условий YES/NO/UNKNOWN с подтверждениями, ALLOW/HOLD, обоснование, недостающие подтверждения и следующий шаг внутреннего согласования. В каждом случае отличайте отсутствие подтверждения от известного несоответствия. Ничего не отправляйте в ИИ и не открывайте настоящий почтовый ящик, общий диск или командный чат. Результат — заполненная запись о решении, а не обработанный документ.

Подсказка

Порядок условий: класс, цель, права, договор, хранение, доступ. A: D; NO/YES/YES/UNKNOWN/YES/YES => HOLD. B: V; YES/NO/NO/UNKNOWN/YES/NO => HOLD. C: I; YES/YES/YES/UNKNOWN/UNKNOWN/YES => HOLD. D: V; YES/YES/YES/YES/YES/YES => ALLOW. Для A нужны оценка идентифицируемости, разрешение класса и область договора; для B — согласование цели, права и область договора; для C — подтверждения договора и хранения; для D — запись действующей области, повторная оценка нужна только при изменениях. Проверьте, что в каждой строке есть следующий внутренний шаг. Для B доступ также NO: фактическая публичная передача противоречит P-F1/1. Ответственный за безопасность/доступ должен оценить ограничения получателей и передачи.

Защитите каждое решение от упрощения

Используйте четыре строки из первого упражнения; добавляйте заметки вместо повторного переписывания. Затем ответьте на четыре возражения: A — «Но мы заменили имя». B — «Текст в открытом доступе». C — «У F1 есть договор, а сервис якобы не обучается на наших данных». D — «Значит, теперь можно обрабатывать всё?» Используйте только вымышленный сценарий, не добавляйте подтверждений. Объясните, почему каждое возражение не меняет ни исходное решение, ни его область.

Подсказка

Ответы: A = HOLD, потому что D не входит в разрешение F1, а договор для него UNKNOWN; не хватает разрешения D и подтверждения договора для D — вопрос к владельцу данных, службе безопасности и ответственному за договоры. B = HOLD: цель и права NO, договор UNKNOWN; не хватает согласования цели, прав и применимого подтверждения договора — вопрос к владельцу данных, ответственному за права, службе безопасности и ответственному за договоры. C = HOLD: договор и хранение UNKNOWN; оба подтверждения отсутствуют — вопрос к ответственному за договоры, службе безопасности и внутреннему согласующему. D = ALLOW только для описанного резюме; ничего не отсутствует, запишите действующую область и передайте изменения владельцу данных и службе безопасности. Замена имени, открытый доступ и заявления поставщика не заменяют подтверждения. Для B доступ также NO: фактическая публичная передача противоречит P-F1/1. Ответственный за безопасность/доступ должен оценить ограничения получателей и передачи.

Предложите следующий безопасный шаг без выполнения задачи

Добавьте предложения следующих шагов в те же четыре строки. Для A предложите, какие признаки контекста владельцу данных нужно оценить при изменении записи; не утверждайте, что изменение автоматически даёт анонимность или разрешение. Для B предложите запрос об определении разрешённой цели и прав на использование. Для C составьте запрос подтверждений договора и хранения для F2. Для D запишите пределы подтверждённого разрешения. Это только предложения в вымышленном сценарии: не отправляйте сообщения, не создавайте подтверждения как будто они согласованы и не запускайте инструмент.

Подсказка

Исходные результаты остаются A = HOLD, B = HOLD, C = HOLD, D = ALLOW. A: роль, место и смена могут идентифицировать человека; не хватает разрешения D и подтверждения договора для D; следующий шаг: владелец данных + служба безопасности + ответственный за договоры. B: не хватает согласования цели, прав и применимого подтверждения договора; следующий шаг: владелец данных + ответственный за права + служба безопасности + ответственный за договоры. C: не хватает подтверждений договора и хранения; следующий шаг: ответственный за договоры + служба безопасности + внутренний согласующий. D: ничего не отсутствует; запишите область и передайте изменения владельцу данных + службе безопасности. Предложенное изменение или запрос сами по себе не меняют решение. Новый результат требует повторной оценки всех условий и настоящего внутреннего подтверждения вне этой симуляции. Для B доступ также NO: фактическая публичная передача противоречит P-F1/1. Ответственный за безопасность/доступ должен оценить ограничения получателей и передачи.

Ключевые выводы
  • Организация определяет классы и разрешённые процессы. V, I, D и P здесь — только вымышленная учебная политика J-1.
  • Разрешение охватывает конкретные данные, цель, права, среду и аудиторию. Открытый доступ, корпоративный тариф, отключённое обучение или самостоятельное размещение сами по себе не устанавливают разрешение.
  • Проверяйте все шесть условий: класс, цель, права, договор, хранение и доступ. Нет обязательного подтверждения = UNKNOWN => HOLD; известное несоответствие, NO, также означает HOLD.
  • Замена имени не подтверждает анонимность. Контекст A сохраняет идентифицируемость и ограничения класса D.
  • Ответы: A = HOLD, B = HOLD, C = HOLD, D = ALLOW только для заданного внутреннего резюме. Для каждого запишите причину, пробелы в подтверждениях и следующий внутренний шаг.
  • HOLD передаёт вопрос ответственной роли; ALLOW имеет подтверждённые пределы. Всё упражнение вымышленное: ничего в действительности не обрабатывается и не загружается.

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

Предыдущий урок
LinkedInX / Twitter

2/6 завершено — продолжайте!

  • Четыре задачи: три приостановить, одну разрешить в заданных пределах
  • Класс определяет организация; разрешение зависит от всего контекста
  • Четыре случая и две карточки подтверждений
  • Что делать, когда подтверждений не хватает

PraktickAI

AI-обучение и консалтинг для технических команд

КурсыДля командУслугиДокументацияБлог
karel@praktickai.appLinkedIn

© 2026 PraktickAI — SkyVisual s.r.o. Все права защищены. Политика конфиденциальности · Условия использования · Порядок рассмотрения жалоб