Oracle представила архитектуру Deep Trust AI
26 октября 2026 года Oracle объявила Deep Trust AI Architecture - архитектурный план для корпоративных систем с ИИ. Компания описывает четыре слоя: программную платформу, данные, доступ к данным и разработку приложений. Идея состоит в том, чтобы часть правил безопасности и бизнес-ограничений применялась в инфраструктуре и базе данных, а не зависела только от инструкций отдельному агенту. Это описание стратегии и набора связанных возможностей Oracle, а не независимое подтверждение эффективности всей архитектуры.
Что изменилось
Контроли предлагается распределить по четырем слоям
Oracle объединяет обновления платформы и защиту данных с ограничениями доступа и доверенной разработкой приложений. В аргументации компании слои дополняют друг друга: обновленный сервер снижает техническую уязвимость, политика данных ограничивает раскрытие записей, контролируемые интерфейсы ограничивают действия агента, а среда разработки задает исполняемые правила. Такой взгляд важен для архитектурного обсуждения, но не означает, что установка продукта автоматически устраняет ошибки модели или неверную настройку ролей.
Политики предлагается применять у источника данных
В качестве примера Oracle приводит механизмы, которые связывают права пользователя с доступом к данным и бизнес-правилами непосредственно в базе. Потенциальное преимущество такого решения - правило может применяться независимо от того, пришел запрос из приложения или от агента. Команде все равно нужно проверить идентификацию конечного пользователя, делегирование прав, журналы запросов и отказоустойчивость. Необходимо также оценить, какие данные остаются доступными через иные интеграции и административные роли.
Вместо произвольного SQL описаны доверенные объекты
Oracle предлагает предоставлять агенту интерфейсы для работы с бизнес-объектами, например заказом, вместо неограниченного доступа к таблицам. Такой слой может сделать допустимые операции понятнее и упростить контроль схемы. Но проектирование API остается отдельной работой: надо определить минимальные поля, проверки состояния, транзакционность и процедуру отмены. Слишком широкая операция может сохранять риск, даже если агенту запрещен прямой SQL. Доступ должен соответствовать задаче и конкретной роли пользователя.
Для вопросов на естественном языке важен бизнес-контекст
В Deep NL2SQL Oracle описывает использование терминов, метаданных и определений показателей, чтобы точнее интерпретировать вопрос и подготовить запрос. Компания также говорит о цикле обратной связи: пользователь сообщает об ошибке, знания корректируются, а ранее проверенные ответы повторно валидируются. Это полезный принцип для систем аналитики, поскольку исправление одной формулировки может повлиять на соседние запросы. На практике качество зависит от полноты словаря метрик и набора контрольных ответов, который подготовила сама организация.
Генерация приложений должна оставлять исполнение проверенной среде
Отдельная часть анонса касается APEX AI App Generator: по описанию Oracle, агент формирует декларативное определение приложения, а исполняет его центральная среда APEX. Такой подход пытается уменьшить объем самостоятельно сгенерированного кода, который нужно сопровождать и защищать. Для оценки заказчику потребуется проверить границы декларативного языка, доступ к данным, возможность ревью изменений, управление версиями и переносимость решения. Архитектурная идея не отменяет тестирования конкретного приложения и его бизнес-логики.
Объявление задает проверяемые вопросы для ИТ-команд
Практическая ценность новости не сводится к списку названий функций. Архитекторам стоит составить карту, где сейчас находятся права на запись, проверки бизнес-инвариантов, пользовательские идентификаторы и журналы действий. Затем можно сравнить ее с предлагаемой моделью и определить, какие контроли действительно перемещаются ближе к данным. Отдельно следует запросить условия лицензирования, версии продуктов и доступность функций в конкретных регионах и облачных средах. В публикации описана рамка, а не развернутый план миграции для любого клиента.
Что это дает пользователю
Разделяет проблему доверия к ИИ на платформенные, дата- и прикладные контроли.
Подчеркивает необходимость проверять идентичность и полномочия агента на уровне источника.
Предлагает обратную проверку знаний после исправления ошибок NL2SQL.
Что нужно учитывать
Это архитектурное предложение Oracle, а не независимый сравнительный тест.
Контроль зависит от корректной модели ролей, словаря метрик и настроек клиента.
Фактическая доступность возможностей зависит от версии продукта и условий поставки.
Коротко
Анонс Oracle показывает перенос акцента с одних только инструкций модели на системные ограничения вокруг данных и исполнения. Для организаций это повод проверить, где реально применяются политики и можно ли проследить действия агента. Оценивать следует раздельно функции базы, доступа, генерации приложений и процессы управления. Заявленная архитектура сама по себе не доказывает, что любой агент станет безопасным: результат зависит от настройки и регулярной проверки.