Oracle dévoile Deep Trust AI pour encadrer les données et les applications générées

Oracle a annoncé Deep Trust AI Architecture le 26 octobre, lors d’Oracle AI World à Las Vegas, en exposant une manière de placer les contrôles sous les agents d’IA et les applications qui manipulent les données des entreprises. Ce schéma d’architecture réunit Oracle AI Database, Autonomous AI Database et APEX AI Application Generator sur quatre couches : plateforme logicielle, données, accès aux données et développement d’applications.

Le problème décrit par Oracle devient plus visible à mesure que l’IA passe des réponses aux questions à l’interaction avec les systèmes opérationnels. Une application peut comporter des vérifications détaillées de confidentialité, tandis qu’un agent directement connecté à sa base de données emprunte un autre chemin vers les mêmes informations. Les applications générées peuvent aussi omettre des règles d’accès. Oracle veut faire appliquer ces protections par une infrastructure partagée, pour réduire la dépendance envers la mise en œuvre propre à chaque application.

Au niveau de la plateforme, Oracle met en avant les mises à jour automatiques de sécurité d’Autonomous AI Database pour le moteur de base de données, le système d’exploitation, le stockage et le micrologiciel. L’application progressive des correctifs actualise successivement différentes parties de l’infrastructure pendant que les traitements continuent. Le chiffrement couvre les données stockées et les informations en transit. Ces capacités concernent la maintenance et l’exposition des systèmes sous-jacents dont dépendent les applications d’IA.

Pour les permissions, Deep Data Security applique les règles au sein d’Oracle AI Database 26ai en utilisant l’identité de l’utilisateur à l’origine de la demande et le contexte d’exécution. Les politiques peuvent distinguer des enregistrements entiers, certaines colonnes et des valeurs de cellules individuelles. Les informations d’identité sont transmises par des jetons signés provenant du système d’identité de l’organisation. La base peut ainsi évaluer l’utilisateur réel derrière la requête d’un agent. L’accès d’un responsable aux données des salariés devient une politique de base de données, au lieu d’un filtrage répété dans différentes applications.

Les restrictions métier jouent un rôle distinct. Oracle SQL Assertions exprime les conditions que la base doit faire respecter, comme le plafond de dépenses d’un salarié, afin de rejeter une dépense non autorisée dès sa soumission. Pour l’accès des agents, l’annonce décrit Deep Trust Data APIs, qui expose des objets métier contrôlés, tels que des bons de commande. Les applications disposent ainsi d’un ensemble défini d’éléments qu’elles peuvent lire ou modifier, tandis que la base applique les règles correspondantes.

Oracle Deep NL2SQL traite une autre difficulté : traduire une question métier en instructions SQL servant à interroger une base. Il associe le vocabulaire et les indicateurs de l’entreprise aux informations décrivant l’organisation des données. Continuous Feedback Learning permet aux utilisateurs de signaler les réponses incorrectes pour qu’un expert des connaissances, assisté par l’IA, les examine et les corrige. Knowledge Change Verification revérifie les réponses déjà validées avant la publication des connaissances révisées, afin de repérer une correction qui dégraderait d’autres réponses. Ces mécanismes visent une meilleure précision sans établir que les erreurs disparaissent.

Pour le développement, les agents de programmation produisent de l’APEXlang, une description structurée de ce qu’une application doit faire, puis le moteur éprouvé d’APEX exécute cette définition. Le langage est lisible par les humains : les équipes peuvent relire, valider et conserver les définitions dans un système de gestion de versions. L’approche d’Oracle concentre l’exécution et les contrôles opérationnels dans le moteur partagé, tout en laissant aux développeurs une spécification générée par l’IA à maintenir. Selon les indications du produit, APEXlang exige APEX 26.1 ou une version ultérieure.

Le 26 octobre marque l’annonce de l’architecture, dont plusieurs fonctions sous-jacentes étaient déjà disponibles. Oracle avait annoncé la disponibilité de Deep Data Security dans AI Database 26ai dans un billet daté du 1er mai. APEX 26.2 est devenu généralement disponible pour les déploiements sur site le 6 octobre, ajoutant l’intégration de Deep Data Security et des imports APEXlang plus fins. Cette annonce présentait encore comme à venir la disponibilité sur Autonomous AI Database, OCI et plusieurs clouds ; elle ne confirme donc pas un déploiement achevé dans ces environnements. L’annonce de l’architecture ne donne pas non plus de date unique de disponibilité générale pour tous les composants.