ИИ в корпоративной системе: почему доверие начинается не с модели
Главная перемена в корпоративном ИИ может оказаться не в очередной модели, а в том, где именно система останавливает её. 26 октября Oracle представила Deep Trust AI Architecture — схему, в которой защитные правила распределены по четырём уровням: программная платформа, данные, доступ к данным и создание приложений. Это не независимая нейросеть и не готовая сертификация безопасности. Скорее, это описание того, как связать уже существующие корпоративные средства контроля, чтобы каждое новое приложение или агент не начинали с пустого листа.
Четыре слоя вместо одного фильтра
Условный чат-бот обычно защищают на входе и выходе: проверяют запрос, ограничивают ответ и надеются, что этого достаточно. В реальной компании модель может обращаться к CRM, читать договоры, собирать отчёты и запускать действия. Поэтому риск не заканчивается на тексте ответа. В новой схеме платформенный слой отвечает за эксплуатацию и изоляцию, слой данных — за сохранность и политику доступа, слой запросов — за то, какие сведения модель может увидеть, а слой приложения — за то, каким образом результат превращается в работающий интерфейс или операцию.
У такого разнесения есть практический смысл: если сотрудник меняет модель, правила доступа к зарплатным данным не должны исчезнуть вместе с настройкой конкретного промпта. Для отдельного сценария можно сначала описать защищённую границу, затем проверить права, и лишь потом решать, какой модели поручить задачу. Это продолжает разговор о том, как проверять ответы по исходным доказательствам, но фокус здесь шире — не только достоверность, но и весь путь данных.
Что именно объявлено
Архитектура объединяет Oracle AI Database, Autonomous AI Database и APEX AI Application Generator. В описании компании есть примеры контроля доступа на уровне базы и генерации определения приложения вместо большого объёма автоматически созданного исполняемого кода. Это важное различие: декларативное описание проще проверять и поддерживать, чем непрозрачный фрагмент, который модель сгенерировала и сразу запустила. Но наличие таких компонентов ещё не доказывает, что любую корпоративную систему можно безопасно перенести на эту схему без проектирования.
Команде полезно читать заявление как архитектурное направление, а не как независимую оценку эффективности. Вендор описывает собственную платформу и её преимущества; реальный эффект зависит от имеющихся систем, настроек ролей, качества каталога данных и дисциплины изменений. Если у компании смешаны права в базе, приложении и облачной панели, единая диаграмма не сведёт их автоматически.
Как проверить идею на небольшом процессе
Выберите один процесс с понятными входами и без критичных автоматических действий — например, поиск пункта договора с выдачей ссылки на оригинал. Составьте таблицу из четырёх колонок: слой, правило, способ проверки и владелец. Для данных зафиксируйте, какие документы закрыты; для доступа — какую роль получает тестовый сотрудник; для приложения — что пользователь может выполнить после ответа; для платформы — где хранятся журналы и как отзывать доступ.
Затем заведите три тестовые учётные записи с разными правами и подготовьте одинаковый набор вопросов. Включите в него корректный запрос, попытку получить чужие сведения и запрос, в котором не хватает контекста. Система должна не просто отказать в запрещённом случае, но и объяснить, что она не располагает нужным доступом. Сравните результаты с контрольной ручной выборкой и сохраните доказательства: идентификатор записи, применённую роль, время и версию приложения. Методика негативных тестов для агента, отправляющего письма пригодится для проверки запретов, но здесь тестируем не отправку, а прохождение границ между слоями.
Где остаются вопросы
Архитектурный подход не заменяет инвентаризацию данных, правила хранения и процедуру реагирования на инцидент. Нужно узнать, какие журналы доступны, можно ли вынести логи в независимое хранилище, как фиксируются изменения прав и что увидит администратор при ошибке. Важно отдельно проверить задержку и стоимость: дополнительный контроль может увеличить время ответа, а подготовка корпоративного слоя потребует людей и сопровождения.
Для проекта, уже работающего на нескольких облаках, полезно сравнить схему с текущим стеком, а не оценивать её в вакууме. Запишите, какие контроли у вас уже есть в IAM, API-шлюзе, базе и приложении; найдите дубли и места без владельца. Если ограничение реализовано только в подсказке модели, оно особенно хрупкое: промпт помогает управлять поведением, но не является границей доступа.
Итог
Главная ценность Deep Trust AI Architecture — напоминание, что безопасность ИИ должна продолжаться ниже уровня модели. Решение стоит оценивать по конкретным проверяемым механизмам: где хранится правило, кто может его изменить, каким тестом подтверждена работа и что происходит при отказе. Перед пилотом сравните границы доступа и подготовьте небольшой набор негативных сценариев. Сводный подход к поиску в документах — точному, векторному или гибридному поможет также проверить, какие документы агент вообще получает на вход.
FAQ
Это новая модель? Нет, объявлена архитектура корпоративного развёртывания и набор связанных возможностей.
Означает ли название «Deep Trust», что систему можно считать безопасной по умолчанию? Нет. Правила и права нужно проверить на собственных данных и ролях.
Можно применить идею вне Oracle? Да: разделение контроля по платформе, данным, доступу и приложению полезно как проверочный список для любого стека, но реализация будет различаться.