Перейти до основного вмісту
Основний•6–10 годин

Analytics Privacy & Lineage Gate

Побудуйте privacy-aware AI analytics pipeline: мінімізація даних, permission checks, lineage, egress controls, retention і negative tests до передачі чутливого контексту моделі.

data minimizationPII classificationaccess controllineageegress governanceprivacy testing

Сценарій

Задача

Аналітик має дослідити поведінку клієнтів, але source dataset містить identifiers, contact data, internal notes і поля, які не потрібні для задачі. AI-інструмент може прискорити analysis, однак “ми не просили модель показувати PII” не є контролем. Потрібно довести, що sensitive fields не потрапляють у model/tool context без потреби, доступи відповідають задачі, а кожен published insight має lineage до дозволеного source slice.

Покрокове виконання

1. Класифікуйте дані за purpose, а не за зручністю

Результат: У pipeline потрапляють лише поля, необхідні для конкретного analytical job.

Завдання

  • →Інвентаризуйте columns і derived fields
  • →Позначте direct/indirect identifiers і sensitive categories
  • →Прив’яжіть кожне поле до explicit purpose
  • →Видаліть або aggregate поля без task necessity

Перевірки

  • ✓“Може знадобитися” не є purpose
  • ✓Derived field успадковує privacy classification від source inputs
  • ✓Minimized view відтворюється з version-controlled transformation

2. Відокремте identity/permission plane від model reasoning

Результат: LLM не вирішує, які дані користувач має право бачити.

Завдання

  • →Перевіряйте user/service identity до retrieval/query
  • →Застосуйте row/column/tenant filters до model context
  • →Позначте external processors/tools як окремі egress boundaries
  • →Встановіть read-only default для analytics tools

Перевірки

  • ✓Unauthorized data не може з’явитися у prompt навіть при direct request
  • ✓Tool schema не розширює business authority
  • ✓Cross-tenant negative test завершується deterministic deny

3. Побудуйте end-to-end lineage

Результат: Кожний claim і artifact можна відтворити до конкретної версії дозволених даних.

Завдання

  • →Запишіть source snapshot/version
  • →Збережіть transformations і query hash
  • →Зв’яжіть output claims із source slices
  • →Зафіксуйте model/tool configuration та timestamp

Перевірки

  • ✓Lineage не обривається на “AI generated”
  • ✓Stale source або permission version видно в trace
  • ✓Published artifact має reproducible evidence path

4. Проведіть privacy failure injection

Результат: Захист підтверджений negative tests, а не презентацією політики.

Завдання

  • →Спробуйте запросити excluded PII через prompt
  • →Симулюйте stale group membership
  • →Перевірте tool/result leakage та logs
  • →Перевірте deletion/retention propagation

Перевірки

  • ✓Critical leakage блокує rollout
  • ✓Logs не зберігають raw sensitive payload без explicit policy
  • ✓Deletion або access revocation доходить до analytical cache/index/context path

Критерії приймання

  • Кожне поле в AI-visible dataset має explicit purpose і classification
  • Permission filtering відбувається до model/tool context і має negative tests
  • Є end-to-end lineage від source snapshot до published claim/artifact
  • External egress, logs, retention і deletion propagation описані та перевірені
  • Cross-tenant або unauthorized-field leakage є hard blocker незалежно від aggregate quality score

Матеріали перед виконанням

Privacy і PII в AI

Практичний підхід до приватності в AI-системах: інвентаризація персональних даних, мінімізація, правові підстави, захист під час retrieval та inference, контроль журналів, retention і перевірюване видалення.

Data governance для AI

Як керувати даними для AI від власника й контракту до lineage, якості, доступу, retention та схвалення датасетів, щоб моделі навчалися й відповідали на перевірених, дозволених і відтворюваних даних.

Структуровані відповіді LLM

Як перетворити довільний текст моделі на версіонований контракт даних із валідацією, retry, семантичною перевіркою та безпечним fallback.