НАЧАЛО >> Оглавление >> Общее описание >> История изменений >> Что нового в проекте I128 >> Версия 2026.3 >> [I128-2837] AITool policy и safe execution📄 Скачать в DOCX
| Тип | Версия | Статус | Приоритет | Исполнитель |
|---|---|---|---|---|
| ⚙️ Новые возможности | 2026.3 | 🔘 Завершено |
Средний | Ilya Mikhaylenko |
Компоненты: ИРБИС 128. Модуль AI - Искусственный интеллект
Завершено: 07.09.2026 08:56
Нужно расширить существующий модуль AITool так, чтобы он стал authoritative source для разрешенных AIинструментов и безопасного выполнения toolдействий в ИРБИС 128.
AIинструмент не должен быть произвольным callbackом, строкой с именем функции, неявным доступом к модулю или способом прямой записи в доменную БД. Каждый tool должен быть описан как управляемая запись или системное definition с устойчивым ключом, input/output schema, типом side effects, правами запуска, confirmation policy, лимитами, idempotency contract, dry-run режимом, audit envelope, HealthCheck/TestA/Help покрытием и безопасным execution pipeline через AI.
В системе уже должен существовать AIgovernance core: реестр AIопераций, policy runtime, preflight/governance API, explainable decision, AISuggestion, audit envelope и invariant ручного подтверждения результата. AITool не заменяет AI runtime, а предоставляет ему промышленный реестр tools и безопасный contract выполнения.
AITool нужен не только задачам. Через него смогут работать workflowпроекты, публичные формы, администраторские помощники, интеграционные сценарии и будущие AIоперации других модулей. Поэтому реализация не должна знать структуру записи Tasks, VirtualRef, RQST или другой доменной БД. Доменный модуль публикует только разрешенные операции применения результата и свои adapter bindings, а AITool контролирует, можно ли tool вызвать, какие аргументы допустимы, какие side effects заявлены и как фиксируется результат.
Основное промышленное правило: tool execution не может изменять целевую доменную запись напрямую. Writetool должен создавать draft/review/queue result или передавать результат доменному ownerу через явно разрешенный domain apply contract. Окончательное применение изменений выполняется доменным модулем по своим правам, ФЛК, workflow, истории и audit.
Нужно реализовать промышленную модель записи AITool. Tool должен иметь stable key, название, описание, owner module, tool type, execution mode, input schema, output schema, side effect class, confirmation policy, required rights, idempotency policy, timeout, retry policy, queue policy, result retention policy, Help reference, TestA reference, lifecycle, system/user origin и признаки system definition.
Нужно реализовать AIToolPolicy как декларативную политику допуска. Policy должна поддерживать allowed tools, denied tools, allowed tool types, side effect limits, required rights, confirmation policy, dryrun requirement, queue requirement, max timeout, max retries, idempotency requirement, allowed target modules, allowed data classes, forbidden data classes, emergency disable и поведение при отсутствии подходящего toolа.
Нужно реализовать единый execution pipeline через AI. Доменный модуль, prompt runtime, model runtime или automation не должны вызывать tool executor напрямую. Запрос должен проходить через AI governance: operation policy, actor/context, Security decision, tool policy, input schema validation, side effect classification, confirmation requirement, dry-run decision, idempotency check, TraceContext, audit envelope и только после этого через AITool executor.
Нужно реализовать input schema validation. Tool должен описывать обязательные и необязательные аргументы, типы данных, допустимые значения, ограничения размера, data class, allowed source kind, default policy и правила отказа. Execution должен безопасно отказать до вызова handler-а, если входные аргументы не соответствуют schema, содержат запрещенные data classes, не прошли Security или требуют отсутствующего consent.
Нужно реализовать output schema и safe result envelope. Tool result должен иметь status, structured payload, warnings, diagnostic codes, result hash, side effects summary, trace id, audit reference, expiration policy и признак возможности apply. Result не должен содержать секреты, закрытые поля, raw hidden values, private prompt text, внутренние рассуждения модели или неразрешенный raw response внешней системы.
Нужно классифицировать side effects. Минимальные классы: readonly, draftonly, queuedeffect, externalcall, notification, domainapplyrequest, destructiverequest, administrativeaction. Для каждого класса должны быть отдельные права, confirmation policy, dryrun policy, idempotency requirements, audit level и HealthCheck diagnostics. Readonly tool не должен иметь write side effect; writetool не должен маскироваться под readonly.
Нужно реализовать confirmation policy. Tool может требовать подтверждение до запуска, после dry-run, перед постановкой в Queue, перед передачей domain apply result или перед внешним вызовом. Confirmation policy должна быть машинно проверяемой и объяснимой: кто подтвердил, что подтверждалось, какие предупреждения видел пользователь, какие данные будут переданы и какие side effects ожидаются.
Нужно реализовать dryrun для tools. Dryrun должен проверять policy, schema, Security, idempotency, Queuereadiness, target availability и expected side effects без выполнения внешнего действия или записи. Dryrun result должен показывать planned action, required confirmation, missing rights, schema errors, forbidden side effects, queue requirement, idempotency key и diagnostic codes.
Нужно реализовать idempotency contract. Каждый tool с side effects должен иметь idempotency key или policy отказа. Повторный запуск с тем же ключом должен возвращать существующий result, безопасно повторять операцию или отказывать как conflict в зависимости от policy. Idempotency не должна строиться на произвольном тексте prompt-а или нестабильном raw payload; ключ должен включать operation/tool key, target reference, actor/context, normalized input hash и trace/correlation данные по принятому контракту.
Нужно интегрировать AITool с Queue. Тяжелые, долгие, retryable или внешние toolдействия должны выполняться через системный Queue по handlerу модулявладельца. AITool не должен становиться собственным runtime очередей. Tool definition должен только указывать queue policy, timeout, retry class, deadletter behavior, cancellation policy и требования к progress/status result.
Нужно реализовать безопасный handler contract. Handler toolа может принадлежать AITool или модулювладельцу конкретного tool adapter-а, но должен вызываться только после policy/preflight. Handler получает только нормализованный context, разрешенные аргументы, trace id, idempotency key и execution mode. Handler не должен получать полный доменный record, raw database object, secret value или hidden field values без отдельного owner contract.
Нужно реализовать domain apply boundary. Если tool готовит изменение доменной записи, он должен вернуть draft, patch proposal, command proposal или review result. Применение выполняет доменный модуль через свою функцию apply, с проверкой Security, workflow, ФЛК, field security, истории и конфликтов версии. AITool не должен знать, как физически сохраняется запись Tasks, VirtualRef, RQST или другой объект.
Нужно интегрировать AITool с Security. Просмотр, создание, редактирование, публикация, deprecate/archive/block toolа, запуск toolа, preview, dryrun, просмотр результатов, export, просмотр diagnostics и queue retry должны проверяться через Security. Service account или technical user не должен расширять права исходного actorа без явного contract.
Нужно интегрировать AITool с TraceContext. Trace id должен проходить через preflight, dryrun, execution, queue job, handler call, result envelope, audit, HealthCheck diagnostics и Observability signals. AITool не должен создавать собственный параллельный traceидентификатор, если общий TraceContext доступен.
Нужно публиковать safe signals в Observability: tool preflight requested, tool allowed, tool denied, schema validation failed, confirmation required, confirmation accepted, dryrun executed, tool queued, tool started, tool succeeded, tool failed, tool timed out, idempotency replay, side effect denied, domain apply proposal created и queue deadletter. Signals не должны содержать raw input, raw output, secrets, hidden fields, private prompt text или полный payload внешней системы.
Нужно подготовить HealthCheck provider для AITool. Проверки должны находить tool без input/output schema, tool без required rights, writetool без confirmation policy, externalcall tool без safe secret reference policy, side effect mismatch, missing idempotency for side-effect tools, direct domain write, handler not registered, broken handler reference, impossible queue policy, tool без TestA/Help, system/user copy conflict, disabled tool used by operation и dangerous permissive defaults.
Нужно подготовить TestAсценарии. Должны проверяться: successful readonly tool, denied tool without rights, denied invalid input schema, denied forbidden data class, confirmation required, dryrun without side effect, queued tool execution, timeout/deadletter behavior через Queue contract, idempotency replay, side effect conflict, write-tool returns proposal instead of direct save, domain apply delegated to owner, absence of secrets/hidden data in result/audit/observability, import/export system definitions и HealthCheck diagnostics.
Нужно реализовать whereused для toolа и policy. AITool должен показывать, какие AIоперации, promptы, model policies, workflow transitions, automation rules, taskspecific operations, TestAсценарии, Helpстраницы и system definitions используют tool или tool policy. Удаление, блокировка или изменение side effect class используемого toolа должны быть запрещены или требовать safe migration.
Нужно реализовать import/export и system definitions. Системные tools и policies должны поставляться через проверяемые definitions, синхронизироваться с dry-run/diff, защищаться от прямого редактирования без developer mode и позволять пользовательскую копию там, где это безопасно. Export не должен включать секреты, raw audit payload, реальные пользовательские данные, приватные endpoint credentials или полные external responses.
Нужно реализовать migration policy для старых toolPolicies/toolSchemas/agentProfiles, если live readback перед разработкой подтвердит их использование. Миграция должна иметь dry-run, отчет различий, mapping старых tool keys к новым AITool records, проверку side effects, сохранение audit explainability и запрет постоянного compatibility fallback как части нового промышленного контракта.
Нужно обновить Help модуля AITool и AIgovernance. Документация должна объяснять администратору и разработчику tool registry, tool policy, schemas, side effects, confirmation, dryrun, idempotency, Queue execution, domain apply boundary, Security, TraceContext, Observability, HealthCheck, TestA и границы с AI, AIPrompt, AIInputProfile, AIProvider/AIModel и доменными модулями.
AITool владеет tool registry, stable tool keys, input/output schema, side effect classification, confirmation policy, required rights, execution mode, idempotency policy, queue policy, safe result envelope, whereused, system definitions tools/policies, import/export tool definitions, HealthCheck providerпроверками и TestA/Help покрытием этого среза.
AI владеет governance runtime, operation registry, общей точкой запуска AI-операции, policy decision, AISuggestion, audit envelope и invariant ручного подтверждения результата. AI вызывает AITool только после preflight/governance decision; AITool не должен обходить AI runtime.
AIInputProfile и AI input/masking/consent runtime владеют сбором входного пакета, data-class policy, masking/redaction и consent. AITool получает только разрешенные normalized arguments и не читает record fields, комментарии, вложения или FT напрямую.
AIPrompt владеет prompt registry, prompt versions, variables, response format и safe render contract. AITool не рендерит prompt, не версионирует prompt-шаблоны и не превращает prompt text в executable instruction.
AIProvider и AIModel владеют provider/model capabilities, local/external/offline признаками, cost/context limits, availability и routing metadata. AITool может указывать required model/tool capabilities, но не выбирает модель и не хранит provider secrets.
Queue владеет фоновым выполнением, retries, scheduling, timeout, deadletter, cancellation и workerуправлением. AITool задает queue policy и получает job/result state, но не реализует собственный runtime очередей.
Security владеет правами, grants/denies, field/view security, service account policy, masking policy и audit доступа. AITool обязан вызывать Security для операций просмотра, редактирования, запуска, dry-run, export, diagnostics и queue retry, но не реализует собственный параллельный механизм прав.
TraceContext владеет созданием, приемом, распространением и диагностическим объединением trace id. AITool только принимает и передает trace id в preflight, execution, Queue, handler, result, audit и diagnostics.
Observability владеет routing, хранением, агрегацией, retention, dashboards и diagnostic packages. AITool публикует только safe signals по preflight, dry-run, execution, side effects, idempotency и handler outcomes.
HealthCheck владеет общим механизмом запуска и агрегации проверок. AITool поставляет provider-проверки для tool registry, policies, schema, side effects, handler references, Queue policy, Security policy, system definitions и dangerous defaults.
TestA владеет общим тестовым каркасом. AITool поставляет сценарии, fixtures и expected results для policy, schema, dry-run, side effects, idempotency, Queue execution, domain apply boundary, import/export и absence of leakage.
Secrets владеет хранением, masking, rotation, access policy и diagnostics секретов. AITool не хранит secret values; concrete tool adapter может хранить только secret reference через согласованный Secrets contract.
Tasks и другие доменные модули владеют taskspecific AI operations, пользовательским UX, доменными ограничениями, применением подтвержденного результата, ФЛК, workflow, записью истории и сохранением доменной записи. AITool не должен знать внутреннюю структуру записи Tasks и не должен применять AIрезультат к доменной БД.
Не входит реализация AI-governance core, operation registry, AISuggestion, policy runtime верхнего уровня и invariant ручного подтверждения результата.
Не входит реализация AIInputProfile, сбор входных данных, field keys, masking/redaction, consent и external transfer policy на уровне входного пакета.
Не входит реализация AIPrompt registry, prompt versioning, prompt variables, response format и safe prompt render contract.
Не входит реализация AIProvider/AIModel routing, fallback model policy, provider/model readiness и выбор конкретной модели.
Не входит реализация конкретных AI-операций Tasks: классификация задачи, поиск похожих задач, резюме истории, черновик ответа или комментария.
Не входит доменный UI Tasks для показа AI-предложения, редактирования результата, частичного применения и сохранения изменений.
Не входит реализация Queue runtime, workerов, retries, deadletter и scheduler. AITool только задает queue policy и вызывает общий Queue contract.
Не входит хранение секретов tools внутри AITool. Секреты должны оставаться в модуле Secrets; этот срез хранит только references и readiness/diagnostic state там, где это согласовано.
Не входит реализация конкретных внешних adapters, marketplace tools, browser automation, shell access, произвольный PHP eval, прямой SQL/IRBIS write executor, RAGхранилище и внешние AIинтеграции.
Не входит постоянная поддержка старого AI.ProfilesJson/toolPolicies/toolSchemas как compatibility fallback. Если перед реализацией будут подтверждены действующие toolнастройки в старых структурах, миграция должна быть оформлена отдельным этапом с dryrun и отчетом различий.
В модуле AITool есть промышленная сущность tool со stable key, названием, описанием, owner module, tool type, execution mode, input schema, output schema, side effect class, confirmation policy, required rights, idempotency policy, timeout, retry policy, queue policy, result retention policy, Help reference, TestA reference, lifecycle и признаком system definition.
AIToolPolicy поддерживает allowed/denied tools, allowed tool types, side effect limits, required rights, confirmation policy, dry-run requirement, queue requirement, timeout/retry/idempotency limits, allowed target modules, allowed/forbidden data classes, emergency disable и explainable denial.
Tool execution проходит через AI governance pipeline; прямой вызов tool executor-а из доменного модуля, prompt runtime, model runtime или automation без preflight запрещен.
Input schema validation безопасно отказывает до вызова handler-а при missing required input, invalid type, forbidden value, size limit violation, forbidden data class, missing rights или missing consent state.
Output schema и safe result envelope возвращают status, structured payload, warnings, diagnostic codes, result hash, side effects summary, trace id, audit reference, expiration policy и apply capability без секретов, скрытых полей и raw hidden values.
Side effects классифицируются минимум как readonly, draftonly, queuedeffect, externalcall, notification, domainapplyrequest, destructiverequest и administrativeaction; для каждого класса применяются отдельные права, confirmation, dry-run, idempotency, audit и HealthCheck rules.
Write-tool не изменяет доменную БД напрямую; он возвращает draft/review/queue result, patch proposal, command proposal или domain apply request, а применение выполняет доменный owner.
Confirmation policy машинно проверяема и фиксирует actor, confirmed action, warnings, expected side effects, data transfer decision, trace id и время подтверждения.
Dry-run tools работает без внешнего side effect или записи и показывает planned action, required confirmation, missing rights, schema errors, forbidden side effects, queue requirement, idempotency key и diagnostic codes.
Каждый tool с side effects имеет idempotency key или explicit conflict policy; повторный запуск не создает неконтролируемый дубль действия.
Тяжелые, долгие, retryable или внешние toolдействия выполняются через Queue по handlerу модуля-владельца; AITool не реализует собственный runtime очередей.
Handler получает только normalized context, разрешенные аргументы, trace id, idempotency key и execution mode; handler не получает полный доменный record, raw database object, secret value или hidden field values без отдельного owner contract.
Просмотр, создание, редактирование, публикация, deprecate/archive/block toolа, запуск toolа, preview, dry-run, просмотр результата, export, diagnostics и queue retry проверяются через Security.
TraceContext проходит через preflight, dry-run, execution, queue job, handler call, result envelope, audit, HealthCheck diagnostics и Observability signals.
Observability получает только safe signals по tool preflight, allow/deny, schema validation, confirmation, dryrun, queue, execution, timeout, idempotency, side effects, domain apply proposal и deadletter.
HealthCheck provider AITool находит tool без schema, tool без required rights, writetool без confirmation policy, externalcall tool без safe secret reference policy, side effect mismatch, missing idempotency, direct domain write, broken handler reference, impossible queue policy, tool без TestA/Help, disabled tool used by operation и dangerous permissive defaults.
TestA покрывает successful readonly tool, denied rights, invalid input schema, forbidden data class, confirmation required, dryrun without side effect, queued execution, timeout/deadletter через Queue contract, idempotency replay, side effect conflict, writetool proposal, delegated domain apply, absence of secrets/hidden data in result/audit/observability, import/export system definitions и HealthCheck diagnostics.
Whereused показывает AIоперации, promptы, model policies, workflow transitions, automation rules, taskspecific operations, TestAсценарии, Helpстраницы и system definitions, использующие tool или tool policy.
Удаление, блокировка или изменение side effect class используемого tool-а запрещены или требуют safe migration.
System definitions tools/policies поддерживают dry-run import, diff, conflict system/user copy, защиту системной записи и пользовательскую копию там, где это безопасно.
Export tool definitions не включает secrets, raw audit payload, реальные пользовательские данные, приватные endpoint credentials или полные external responses.
Migration policy для старых toolPolicies/toolSchemas/agentProfiles имеет dry-run, отчет различий, mapping старых keys к новым AITool records, проверку side effects и не вводит постоянный compatibility fallback.
Help содержит руководство администратора и разработчика по AITool registry, tool policy, schemas, side effects, confirmation, dry-run, idempotency, Queue execution, domain apply boundary, Security, TraceContext, Observability, HealthCheck и TestA.
-
Реализован первый срез AI-governance core в модуле AI.
Что сделано:
Проверка:
-
Реализован безопасный слой запуска AI-инструментов в модуле AITool.
Что входит:
Проверки:
[I128-2838] AI-операции задач в модуле Tasks
Статус: Завершено | Автор: Ilya Mikhaylenko
[I128-2793] Ввести TraceContext для сквозной трассировки операций
Статус: Завершено | Автор: Ilya Mikhaylenko
[I128-2795] Расширить Queue как runtime фоновых заданий, retry и расписаний
Статус: Завершено | Автор: 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-2833] AI-governance core: policy runtime и реестр AI-операций
Статус: Завершено | Автор: Ilya Mikhaylenko