Guide de confiance
La confidentialité sur Deepinfra commence par ce que vous envoyez
La confidentialité sur Deepinfra ne dépend pas uniquement du nom d’un modèle. Avant d’envoyer des instructions, des fichiers ou des informations personnelles à Deepinfra, vérifiez les conditions actuelles du fournisseur et déterminez quelles données votre tâche nécessite réellement.
Définition en une phrase
Dans un processus d’inférence, la confidentialité consiste à comprendre ce qui entre dans un service, ce qui en ressort et quelles affirmations sur le traitement des données vous pouvez vérifier.
- EntréeUne requête envoyée à Deepinfra peut contenir des informations sensibles dans ses instructions, même si le modèle choisi est accessible au public.
- SortieUne réponse de Deepinfra peut reprendre des détails de la requête : les résultats doivent donc être examinés avant d’être partagés.
- Éléments de preuveCe sont les conditions et la documentation actuelles de Deepinfra, et non ce guide, qui font foi pour les engagements relatifs à la conservation et au traitement des données.
Fonctionnement : à quelles étapes effectuer les vérifications
Un examen utile suit les données tout au long de leur préparation, de leur envoi et de la production du résultat. Cette page ne peut pas inspecter les systèmes de Deepinfra ni établir ce qu’il advient d’une requête donnée.
Impossible de garantir une absence totale de conservation
Ce guide n’a pas accès aux paramètres actuels de journalisation, aux conditions contractuelles ni aux registres opérationnels de Deepinfra. Toute promesse de suppression devrait être étayée par des preuves fournies par le prestataire.
Que faire à la place
Lisez la documentation actuelle sur le traitement des données et interrogez le prestataire au sujet du point de terminaison et du déploiement que vous comptez utiliser.
Impossible de rendre anonyme une instruction sensible
Supprimer le nom d’une personne peut laisser dans une requête envoyée à Deepinfra des éléments de contexte identifiants, des extraits de documents ou des événements particuliers.
Que faire à la place
Remplacez les données réelles par des exemples fictifs et examinez l’ensemble des instructions pour repérer les identifiants indirects.
Impossible de certifier une application
Les contrôles publiés par un fournisseur ne couvrent pas automatiquement votre propre stockage, vos règles d’accès, vos journaux ni le partage ultérieur des résultats de Deepinfra.
Que faire à la place
Examinez l’ensemble des flux de données de l’application et obtenez les autorisations requises par votre organisation.
Ce qu’il faut faire et éviter : liste de vérification préalable
Utilisez cette liste avant de tester un flux de travail Deepinfra. Elle aide à limiter la divulgation inutile de données, mais ne remplace pas un examen juridique, de sécurité ou de conformité.
-
Recensez chaque champ, fichier et fragment de prompt que vous prévoyez de soumettre à Deepinfra. — Incluez les éléments ajoutés par votre application, pas seulement le texte saisi par un utilisateur.
-
Consultez la documentation actuelle du fournisseur concernant les conditions de conservation, d’accès et d’utilisation des données applicables à votre requête. — Notez la date de votre vérification ; les conditions peuvent changer.
-
Supprimez les secrets, les identifiants directs et les éléments de contexte inutiles avant de tester. — Utilisez un prompt synthétique lorsque la tâche le permet.
-
Vérifiez que la réponse ne contient pas de détails qui ne devraient pas être stockés ou transmis. — Le traitement des résultats est aussi important que celui des données d’entrée.
-
Consignez l’autorisation interne obtenue pour tout flux de travail impliquant des données réglementées ou confidentielles.facultatif — L’examen nécessaire dépend de votre organisation et de votre cas d’usage.
À qui cela s’adresse : flux de travail à vérifier
Les développeurs qui comparent des modèles, les équipes qui préparent une recherche documentaire et les évaluateurs qui exécutent des prompts de test sont chacun confrontés à des risques d’exposition différents. Ces guides connexes aident à situer l’examen de confidentialité dans son contexte.
- modèles deepinfra Comparez les catégories de modèles afin d’adapter votre examen des données au type d’entrée envoyé par votre application.
- embeddings deepinfra Examinez le flux de travail qui transforme les documents en vecteurs avant de soumettre le texte source d’une collection privée.
- deepinfra vs openrouter Voyez comment la comparaison des fournisseurs fait évoluer vos questions sur l’acheminement des requêtes et le traitement des données.
Un périmètre que vous pouvez expliquer
- VÉRIFIER LES CONDITIONS
- EXAMINER LES DONNÉES ENTRANTES
- SUIVRE LES RÉSULTATS
N’envoyez que ce qui est nécessaire à la tâche
Pour un premier test de Deepinfra, le plus sûr est d’utiliser un contenu inventé et non sensible. Vous pouvez ainsi examiner la structure de la requête et la réponse sans considérer une hypothèse non vérifiée sur la conservation des données comme une mesure de protection de la vie privée.
Pour les données réelles, consignez leur origine, les personnes autorisées à les soumettre, le contenu de la requête envoyée à Deepinfra et la destination de la réponse. Vérifiez les affirmations du fournisseur dans sa documentation actuelle avant de décider si ce parcours est acceptable.
Un calendrier de vérification, pas un historique
Ces dates décrivent un cycle de vérification suggéré pour votre processus, et non des étapes de l’histoire du produit Deepinfra.
-
Décrire la requête
Listez les champs que votre application envoie à Deepinfra et signalez ceux qui sont confidentiels, permettent une identification ou sont inutiles.
-
Vérifier les conditions publiées
Lisez la documentation actuelle du service et du déploiement que vous utiliserez ; notez la date et les questions auxquelles elle ne répond pas.
-
Tester avec des données synthétiques
Soumettez un exemple sans risque à Deepinfra et examinez à la fois les données envoyées et le texte renvoyé.
-
Revérifier le parcours des données
Examinez les journaux de l’application, les résultats stockés et toute modification de la documentation de Deepinfra avant d’étendre le processus.
Commencez par un exemple sans risque
Utilisez une requête inventée pour voir si le modèle convient à votre tâche. N’incluez ni données personnelles ni fichiers confidentiels dans le test, et terminez votre vérification du traitement des données par Deepinfra avant de passer à des données réelles.
Testez le processus sans exposer de données réelles
- Utilisez une entrée synthétique
- Examinez le texte renvoyé
- Vérifiez les conditions actuelles de traitement
FAQ sur la confidentialité de Deepinfra
Examinez l'intégralité des données envoyées pour repérer les secrets, les données personnelles et les éléments de contexte permettant une identification. Consultez ensuite la documentation actuelle de Deepinfra pour connaître les conditions applicables au service que vous comptez utiliser et demandez-vous si un prompt synthétique permettrait de répondre à la même question.
Non. Ce guide ne permet pas de vérifier les pratiques actuelles de conservation ni les paramètres d'un déploiement particulier. Consultez la documentation actuelle du fournisseur et demandez-lui une réponse directe pour toute exigence dont dépend votre décision.
Cela dépend du document, des règles de votre organisation et des conditions applicables du fournisseur. Ne soumettez pas de documents confidentiels simplement parce qu'un essai avec un texte public a fonctionné ; obtenez les validations requises et réduisez au minimum les données envoyées.
Oui. Une réponse de Deepinfra peut contenir des informations fournies dans le prompt, ce qui peut entraîner une exposition si elle est enregistrée ou partagée. Examinez les modalités de stockage et d'accès aux réponses ainsi qu'à la requête initiale.