НАЧАЛО >> Оглавление >> Общее описание >> История изменений >> Что нового в проекте I128 >> Версия 2026.3 >> [I128-2834] AI input profiles, masking и consent📄 Скачать в DOCX
| Тип | Версия | Статус | Приоритет | Исполнитель |
|---|---|---|---|---|
| ⚙️ Новые возможности | 2026.3 | 🔘 Завершено |
Средний | Ilya Mikhaylenko |
Компоненты: ИРБИС 128. Модуль AI - Искусственный интеллект
Завершено: 07.09.2026 08:42
Нужно расширить существующий модуль AI так, чтобы он стал владельцем общего контракта AIInputProfile, dataclass policy, masking/redaction и consent перед передачей данных в AIоперацию.
Доменный модуль должен иметь возможность описать, какие данные конкретная AI-операция вправе использовать, а AI должен собрать безопасный входной пакет только из разрешенных источников, проверить права чтения, применить маскирование, запретить скрытые данные и объяснимо определить, требуется ли consent на внешнюю передачу.
В системе уже должен существовать AIgovernance core: реестр AIопераций, policy runtime, preflight/governance API, explainable decision, AISuggestion, audit envelope и invariant ручного подтверждения. Этот срез не заменяет core, а дополняет его уровнем безопасной подготовки входных данных.
AIоперация не должна получать произвольный record, полный текст комментариев, закрытые вложения, историю, FTтекст или пользовательский ввод без декларативного профиля и проверки прав. Набор входных данных должен быть описан явно, воспроизводимо и диагностируемо.
Задача должна обеспечить промышленное правило: если источник данных не разрешен профилем, не найден в FieldConfiguration, не доступен пользователю через Security, относится к запрещенному классу данных или требует отсутствующий consent, он не попадает в prompt payload, audit, cache, RAG, diagnostic package или external transfer.
Нужно реализовать в модуле AI сущность AIInputProfile. Профиль должен иметь устойчивый ключ, название, описание, owner module, статус публикации, системный или пользовательский признак происхождения, область применимости, версию или revision, список разрешенных источников, правила data-class, правила masking/redaction и policy внешней передачи.
AIInputProfile должен использоваться AI-операцией через ссылку из AIOperationDefinition. Одна операция может ссылаться на один основной профиль входных данных или на явно описанную композицию профилей, если это предусмотрено контрактом. Отсутствующий, отключенный или битый профиль должен давать безопасный отказ до вызова prompt renderer, model provider или tool executor.
Профиль должен описывать разрешенные источники данных: поля записи, связанные записи, комментарии, историю, вложения, FTтекст, Helpматериалы, пользовательский ввод, системный контекст и заранее подготовленные safe snapshots. Каждый источник должен иметь key, тип, допустимый объем, правила сортировки или отбора, ограничение по размеру, data class, required permissions и поведение при недоступности.
Для record-based данных профиль должен ссылаться на field keys из FieldConfiguration, а не на физические номера полей и подполей. FieldConfiguration остается владельцем описания field key, типа данных, подписи, назначения, правил отображения, ввода, поиска и metadata конфиденциальности. AI использует эти metadata для сборки входного пакета и диагностики, но не становится владельцем полевой модели доменного модуля.
Перед включением любого источника в prompt payload AI должен проверить право чтения через Security. Проверка должна выполняться с учетом actor/principal, source object, field key, view/security context, project/workflow context, attachment reference, comment visibility и data class. AI не должен использовать service account как способ расширить доступ исходного пользователя.
Нужно реализовать data-class policy для входных данных. Минимальный набор классов должен различать публичные, внутренние, служебные, персональные, секретные, закрытые и запрещенные данные. Политика должна определять, какие классы можно использовать для локальной модели, внешней модели, audit summary, diagnostic package, RAG/cache и пользовательского preview.
Нужно реализовать masking/redaction pipeline до формирования prompt payload. Маскирование должно применяться к значениям полей, тексту комментариев, extracted text вложений, FT-тексту, истории, связанным записям и пользовательскому вводу. Pipeline должен уметь удалять значение полностью, заменять его безопасным маркером, обобщать значение, хешировать идентификатор или оставлять значение без изменения только при явном разрешении policy.
Hidden fields, private comments, закрытые вложения, записи без права просмотра, запрещенные data classes, секреты, технические токены, персональные данные без разрешения и данные, скрытые view/field security, не должны попадать в prompt payload, raw audit, Observability signals, TestA expected results, cache, RAG или diagnostic package.
Нужно реализовать policy внешней передачи данных. Внешней передачей считается передача в external provider, external model, external tool, external memory, внешний RAG или другой runtime за пределами локального доверенного контура. По умолчанию внешняя передача запрещена и может быть разрешена только явной policy с учетом data class, operation key, actor, project, source object, provider/model class и consent.
Нужно реализовать AIConsentPolicy для случаев, когда внешняя передача или использование чувствительных данных требует явного consent. Consent должен быть отделен от обычного подтверждения применения AIрезультата. Пользователь может разрешить передачу входных данных во внешний AIruntime, но это не означает согласие применить результат к записи.
Consent decision должен фиксировать actor, operation key, source object, input profile key, data classes, external transfer target class, срок действия, scope, trace id и безопасное описание того, что разрешено. Consent не должен сохранять полный payload, закрытый текст, секреты или запрещенные данные.
Нужно реализовать explainable input decision. Перед вызовом модели AI должен уметь показать, какие источники включены, какие исключены, какие замаскированы, почему требуется consent, почему внешняя передача запрещена или почему операция может идти только в local/offline режиме. Пользовательские сообщения должны быть безопасными, а административная диагностика должна ссылаться на настройки без раскрытия скрытых данных.
Нужно реализовать dryrun сборки входного пакета. Dryrun должен проверять профиль, права, data classes, masking, consent и ограничения размера без вызова модели. Результат dry-run должен быть пригоден для администратора и TestA: список включенных источников, исключенных источников, примененных masking rules, required consent, blockers, warnings и diagnostic codes.
Нужно обеспечить ограничение объема входных данных. Профиль должен задавать лимиты по количеству полей, связанных записей, комментариев, вложений, extracted text, истории, символов и токенов. При превышении лимитов AI должен применять явные правила отбора или безопасно отказывать, а не случайно усекать данные без объяснения.
Нужно обеспечить безопасную работу с вложениями и FT-текстом. AI не должен читать физический файл напрямую в обход FT, Security и attachment metadata. Для вложений должен использоваться безопасный file reference или extracted text, прошедший права, quarantine/availability policy, data class и masking. Закрытое, quarantined или недоступное вложение должно исключаться из входного пакета.
Нужно обеспечить защиту от prompt injection и data injection на уровне входного профиля. Пользовательский текст, содержимое вложений, FTтекст, Helpфрагменты и связанные записи должны считаться недоверенными данными. Профиль должен позволять помечать источники как untrusted и передавать downstream prompt renderer-у безопасные markers/metadata без превращения пользовательского текста в system instructions.
Нужно интегрировать input profile runtime с AIgovernance core. Preflight должен учитывать наличие профиля, доступность источников, dataclass policy, masking readiness, external-transfer policy и consent. Если входные данные не могут быть собраны безопасно, операция должна завершиться denied, requiresConsent, dryRunOnly или another safe decision до вызова модели.
Нужно интегрировать runtime с TraceContext. Trace id должен попадать в input decision, masking decision, consent decision, audit envelope, Observability signals и HealthCheck/TestA diagnostics. Если trace id отсутствует и общий contract допускает его создание, AI должен использовать общий механизм TraceContext, а не собственный частный идентификатор.
Нужно публиковать safe signals в Observability: input profile used, input dryrun completed, source included/excluded count, masking applied count, consent required, consent granted/denied, external transfer denied, dataclass blocker и failure class. Signals не должны содержать raw values, raw prompt, скрытые поля, персональные данные без прав, секреты или полный текст вложений.
Нужно подготовить HealthCheck provider для input profiles. Проверки должны находить битые field keys, отсутствующие FieldConfiguration metadata, неизвестные Security permissions, permissive external transfer policy, отсутствующее masking для чувствительных data classes, профили без TestA/Help, недоступные Secrets для external provider profiles, ссылки на удаленные источники и опасные default-разрешения.
Нужно подготовить TestAсценарии: успешный сбор безопасного входного пакета, отказ при hidden field, отказ при private comment, исключение закрытого вложения, masking персонального поля, запрет secret field, requiresConsent для external transfer, отказ при отсутствии consent, localonly режим без external transfer, dry-run без вызова модели, trace propagation, audit без raw payload и HealthCheck для битой настройки.
Нужно обновить Help модуля AI. Документация должна объяснять администратору и разработчику назначение AIInputProfile, связь с AIоперацией, field keys, data classes, Security checks, masking rules, consent, external transfer policy, dryrun, diagnostics, TestA и типичные ошибки настройки.
AI владеет AIInputProfile, dataclass policy для AIвходов, masking/redaction pipeline перед AIвызовом, consent policy на внешнюю передачу, dryrun входного пакета, explainable input decision, audit envelope этого среза, provider-проверками HealthCheck и TestA/Help покрытием.
Security владеет правами, grants/denies, field/view security, masking policy как общесистемным permission contract, audit доступа и решением, может ли actor видеть конкретный источник. AI обязан вызывать Security, но не реализует собственный параллельный механизм прав.
FieldConfiguration владеет field keys, типами полей, подписями, назначением, metadata конфиденциальности, правилами отображения, ввода, поиска и API. AI использует эти metadata для input profiles, но не хранит физическую модель полей доменного модуля как собственную.
FT владеет постоянным файловым хранилищем, staging, preview, extracted text, quarantine, retention и safe file references. AI потребляет только безопасные ссылки или extracted text после проверок, но не становится владельцем файлового storage.
Secrets владеет безопасным хранением секретов providerов, masking секретов, rotation и whereused. AI не должен сохранять секреты в input profile, consent, audit, diagnostics или TestA expected results.
TraceContext владеет созданием, приемом, распространением и диагностическим объединением trace id. AI только принимает и передает trace id в input decision, consent, audit и diagnostics.
Observability владеет routing, хранением, агрегацией, retention, dashboards и diagnostic packages. AI публикует только safe signals по input-profile runtime и masking/consent decisions.
HealthCheck владеет общим механизмом запуска и агрегации проверок. AI поставляет providerпроверки для input profiles, dataclass policy, masking и consent.
TestA владеет общим тестовым каркасом. AI поставляет сценарии, fixtures и expected results для input profiles, masking, consent, external transfer denial и absence of leakage.
Tasks и другие доменные модули владеют своими taskspecific AI operations, наборами task fields, доменными ограничениями, пользовательским UX и применением подтвержденного результата. AI не должен знать внутреннюю структуру записи Tasks сверх field keys, object references и опубликованного inputprofile contract.
Не входит реализация AIPrompt registry, prompt versioning, редактора promptшаблонов, prompt variable catalog и migration promptов.
Не входит реализация AITool policy, allowlist инструментов, tool execution pipeline и write-tool side effects.
Не входит реализация AIProvider/AIModel routing, fallback model policy, стоимость моделей, local runtime readiness и выбор конкретной модели.
Не входит реализация конкретных AI-операций Tasks: классификация задачи, поиск похожих задач, резюме истории, черновик ответа или комментария.
Не входит доменный UI Tasks для выбора полей, показа AI-предложения и применения результата.
Не входит прямое изменение доменных записей, автоматическое выполнение workflow-переходов, публикация ответов заявителю, назначение ответственного или создание внешних отправок по результату AI.
Не входит lifecycle delivery через EventBus, фоновое выполнение через Queue, retry/deadletter, batch processing и longrunning AI jobs.
Не входит хранение файлов, OCR, preview, quarantine или FT indexing. AI использует только безопасный контракт FT.
Не входит постоянная поддержка старого AI.ProfilesJson как compatibility fallback. Если перед реализацией будут подтверждены действующие установки AI.ProfilesJson для data policy/input profiles, миграция должна быть оформлена отдельным срезом с dry-run и отчетом различий.
В модуле AI есть сущность AIInputProfile со стабильным ключом, названием, описанием, owner module, статусом публикации, областью применимости, версией или revision, списком источников, dataclass rules, masking rules, externaltransfer policy и Help/TestA references.
AIOperationDefinition может ссылаться на AIInputProfile, а governance preflight учитывает доступность профиля до вызова prompt renderer, provider adapter, tool executor или модели.
Отсутствующий, отключенный, битый или небезопасный AIInputProfile приводит к explainable safe denial, requiresConsent или dryRunOnly, а не к permissive запуску.
Record-based источники описываются через field keys из FieldConfiguration, а не через физические номера полей и подполей.
Перед включением каждого источника AI вызывает Security и проверяет право чтения actor-а с учетом source object, field key, view/security context, project/workflow context, attachment reference, comment visibility и data class.
AI не повышает права пользователя и не использует service account для расширения доступа исходного actor без явного системного contract.
Hidden fields, private comments, закрытые вложения, запрещенные data classes, секреты, технические токены и данные без права просмотра не попадают в prompt payload, audit, Observability signals, diagnostic packages, cache, RAG или TestA expected results.
Masking/redaction выполняется до формирования prompt payload и применяется к полям, комментариям, истории, FT-тексту, extracted text вложений, связанным записям и пользовательскому вводу.
Data-class policy различает как минимум публичные, внутренние, служебные, персональные, секретные, закрытые и запрещенные данные и задает правила использования для local/offline/external runtime, audit, diagnostics, cache и RAG.
External transfer запрещен по умолчанию и разрешается только явной policy с учетом data class, operation key, actor, project, source object, provider/model class и consent.
AIConsentPolicy отделяет consent на внешнюю передачу входных данных от подтверждения применения AI-результата.
Consent decision фиксирует actor, operation key, source object, input profile key, data classes, external target class, срок действия, scope и trace id, но не сохраняет raw payload, секреты или скрытые данные.
Dry-run сборки входного пакета проверяет профиль, права, data classes, masking, consent и лимиты без вызова модели и возвращает объяснимый результат.
Профиль задает лимиты объема данных; превышение лимитов обрабатывается явным правилом отбора или безопасным отказом, а не неявным усечением.
Вложения и FT-текст используются только через безопасные ссылки или extracted text после проверки FT metadata, Security, quarantine/availability policy, data class и masking.
Prompt injection и data injection из пользовательского текста, вложений, FT-текста, Help и связанных записей учитываются как риск недоверенного источника и не превращают пользовательские данные в system instructions.
Explainable input decision показывает включенные источники, исключенные источники, примененные masking rules, required consent, blockers, warnings и diagnostic codes без раскрытия скрытых данных.
TraceContext проходит через input decision, masking decision, consent decision, audit, Observability signals и diagnostics.
Observability получает только safe signals по использованию input profile, dryrun, counts включенных/исключенных источников, masking, consent, externaltransfer denial и failure classes.
HealthCheck provider AI находит битые field keys, отсутствующие FieldConfiguration metadata, неизвестные Security permissions, permissive external transfer policy, отсутствующее masking для чувствительных классов, профили без TestA/Help, недоступные Secrets для external provider profiles и опасные default-разрешения.
TestA покрывает успешный сбор безопасного входного пакета, отказ hidden field, отказ private comment, исключение закрытого вложения, masking персонального поля, запрет secret field, requiresConsent для external transfer, отказ при отсутствии consent, localonly режим, dryrun без вызова модели, trace propagation, audit без raw payload и HealthCheck provider.
Help содержит руководство администратора и разработчика по AIInputProfile, data classes, field keys, Security checks, masking/redaction, consent, external transfer policy, dry-run, diagnostics, HealthCheck и TestA.
-
Реализован первый срез AI-governance core в модуле AI.
Что сделано:
Проверка:
-
Реализован второй срез AIgovernance в модуле AI: AIInputProfile, dataclass policy, masking/redaction и consent.
Что сделано:
Проверка:
[I128-2835] AIPrompt registry и versioning
Статус: Завершено | Автор: Ilya Mikhaylenko
[I128-2838] AI-операции задач в модуле Tasks
Статус: Завершено | Автор: Ilya Mikhaylenko
[I128-2793] Ввести TraceContext для сквозной трассировки операций
Статус: Завершено | Автор: Ilya Mikhaylenko
[I128-2797] Расширить Security для проектных прав, полей, действий и аудита доступа
Статус: Завершено | Автор: Ilya Mikhaylenko
[I128-2798] Реализовать HealthCheck для workflow-проектов и задач
Статус: Завершено | Автор: Ilya Mikhaylenko
[I128-2799] Подготовить TestA-контракты системных JSON и end-to-end сценариев
Статус: Завершено | Автор: Ilya Mikhaylenko
[I128-2818] Реализовать наблюдаемость Observability для промышленных модулей
Статус: Завершено | Автор: Ilya Mikhaylenko
[I128-2825] Расширить FieldConfiguration как реестр полей workflow-проектов
Статус: Завершено | Автор: Ilya Mikhaylenko
[I128-2829] Расширить Security для системного хранения и ротации секретов интеграций
Статус: Завершено | Автор: Ilya Mikhaylenko
[I128-2833] AI-governance core: policy runtime и реестр AI-операций
Статус: Завершено | Автор: Ilya Mikhaylenko