Corey sécurité et confidentialité

Corey n’est pas entraîné sur les données client.

Il utilise des modèles de base Azure OpenAI fournis via Microsoft Azure AI Foundry. Au moment de l’exécution, Corey utilise des prompts développés par CoreView, une logique d’orchestration et des compétences de plateforme pour répondre aux demandes des utilisateurs.

Pour générer des réponses, Corey peut utiliser les données de tenant disponibles dans la plateforme CoreView, mais uniquement au moment de l’exécution, dans la session de l’utilisateur authentifié, et conformément aux permissions et politiques appliquées à cet utilisateur. Ces données sont utilisées pour répondre à la demande, et non pour entraîner ou affiner le modèle.

Corey s’exécute dans une infrastructure Azure contrôlée utilisant Azure AI Foundry. Les données sont traitées uniquement dans le contexte d’exécution de votre session authentifiée et de votre organisation.

CoreView utilise Azure OpenAI Zero Data Retention (ZDR) pour tous les déploiements d’IA de Corey. Cela signifie que les prompts et les réponses ne sont pas stockés par le fournisseur d’IA et sont utilisés uniquement pendant le temps nécessaire au traitement de la demande.

Un concept distinct est Data Zone Standard (DZS), qui fait référence à la zone géographique où le traitement d’inférence a lieu. À ce jour, DZS n’est disponible que dans certaines régions Azure, actuellement l’UE et les États-Unis. Pour les clients qui utilisent Corey dans des régions où Azure ne fournit pas encore DZS, CoreView peut utiliser des déploiements Azure qui traitent l’inférence dans une autre région prise en charge, conformément à la configuration du service et aux conditions contractuelles convenues avec le client.

Dans la documentation Azure AI Foundry, cette capacité est appelée déploiement Global Standard. Avec ce modèle de déploiement, le modèle peut toujours être configuré dans une Azure Data Zone du client tandis qu’Azure achemine les demandes d’inférence à travers son infrastructure mondiale vers la région la plus appropriée pour le traitement, tout en restant soumis aux contrôles de sécurité et de conformité d’entreprise de Microsoft.

Référence à la documentation Microsoft :
Microsoft Learn – Types de déploiement pour Microsoft Foundry Models

CoreView applique une isolation stricte au niveau du tenant et de la session. Les interactions avec l’IA ont lieu dans le contexte de votre organisation et de la session de l’utilisateur authentifié, de sorte que les demandes et les réponses sont toujours limitées à votre environnement.

Corey utilise la même couche d’authentification et de sécurité utilisée dans toute la plateforme CoreView, ce qui signifie que les contrôles de sécurité et d’accès intégrés à la plateforme s’appliquent également aux interactions avec l’IA. Grâce à cette architecture, la séparation des tenants et les contrôles d’accès empêchent un autre client ou tenant d’accéder à votre environnement ou à ses données par le biais de prompts.

CoreView utilise Azure OpenAI Zero Data Retention (ZDR), ce qui signifie que les prompts et les réponses ne sont pas stockés par le fournisseur d’IA et sont utilisés uniquement pendant le temps nécessaire au traitement de la demande.

Du côté de CoreView, les interactions et les requêtes peuvent être journalisées et stockées dans la plateforme CoreView à des fins de sécurité, d’Audit, de Governance et de fonctionnalité du service, y compris pour rendre les conversations disponibles dans le produit. Cela permet aux administrateurs du tenant CoreView de consulter les interactions avec l’IA si nécessaire.

À ce stade, un accès limité peut être accordé au personnel CoreView autorisé à des fins de surveillance du système et de dépannage. Cet accès est limité à CoreView uniquement et ne s’étend pas aux fournisseurs d’IA tels qu’Azure AI Foundry ou Azure OpenAI.

L’accès est strictement contrôlé et utilisé uniquement pour garantir la fiabilité du système, améliorer le service et résoudre les problèmes pendant la période bêta.

CoreView suit des pratiques de sécurité de niveau entreprise et des normes de conformité alignées sur le programme de sécurité plus large de la plateforme CoreView. L’infrastructure fonctionne sur Microsoft Azure et suit le modèle de sécurité de Microsoft, tandis que CoreView maintient des certifications et des pratiques de sécurité reconnues par le secteur.

Plus d’informations sont disponibles ici :
https://www.coreview.com/security

CoreView applique des processus de validation et des contrôles rigoureux pour maintenir la qualité des réponses et aligner les résultats sur le contexte de l’utilisateur authentifié, les données disponibles de la plateforme et le modèle de permissions de CoreView.

Nous appliquons plusieurs couches de protection :

1. des protections Azure AI Content Safety intégrées à la plateforme Azure OpenAI.
   https://azure.microsoft.c…
2. les capacités Azure Prompt Shield et de détection de jailbreak sont utilisées dans le cadre du modèle de protection.
   https://learn.microsoft.com/en-us/azure/ai-services/content-safety/concepts/jailbreak-detection

L’accès aux données via Corey est limité au contexte organisationnel de l’utilisateur authentifié et au modèle de permissions de CoreView. La couche d’IA ne contourne pas les permissions de la plateforme, ce qui signifie que Corey ne peut accéder et renvoyer que les informations auxquelles l’utilisateur est déjà autorisé à accéder dans CoreView.

En outre, nous utilisons des contrôles de permissions au niveau de l’outil pour permettre aux administrateurs du tenant de définir quels outils de Corey sont accessibles à des utilisateurs spécifiques, offrant une Governance plus granulaire sur les actions que les utilisateurs peuvent effectuer.

Oui. Les communications avec les services Azure sont chiffrées en transit à l’aide de TLS, et l’infrastructure Azure fournit des contrôles de chiffrement et de sécurité. Zero Data Retention et l’architecture de service d’Azure signifient que les prompts sont traités sans stockage persistant par le fournisseur d’IA.

Corey peut exécuter certaines actions de gestion dans la plateforme CoreView, mais ces actions ne sont jamais exécutées silencieusement ; elles nécessitent toujours une confirmation explicite de l’utilisateur.

Dans de nombreux cas, les actions prises en charge ont des actions inverses correspondantes dans la plateforme. Si une telle action existe, elle peut être utilisée pour annuler la modification, là encore avec confirmation de l’utilisateur.