Faut-il chiffrer les prompts envoyés à OpenAI ? Réponse courte : TLS 1.3 par défaut est nécessaire mais pas suffisant pour données sensibles, et le end-to-end encryption (E2EE) applicatif n'est pas possible avec API OpenAI standard car le modèle doit lire les prompts en clair pour les traiter. La vraie question 2026 n'est pas "comment chiffrer plus" mais "quelles données envoyer et où", choix entre OpenAI standard, Azure OpenAI EU, Mistral EU, ou on-premise selon classification donnée et conformité (RGPD post-Schrems II, EU AI Act, sectoriel). Cet article documente l'analyse risque/conformité complète : ce que TLS couvre / ne couvre pas, pourquoi E2EE applicatif est impossible avec LLM standard (sauf Confidential Computing, Apple PCC pattern, ou FHE recherche), alternatives concrètes (Azure OpenAI EU, Mistral, on-premise), techniques de minimisation et pseudonymisation upstream (Presidio, tokenisation HMAC, splitting), modèle de DPIA à documenter pour audit. Cible : DSI / RSSI / DPO arbitrant l'usage OpenAI, AI engineers structurant la couche privacy, équipes Legal validant choix fournisseur LLM.
Pour les risques globaux d'intégrer ChatGPT : quels sont les risques si j'intègre ChatGPT dans mon SI. Pour l'alternative on-premise : architecture sécurisée pour déployer un LLM on-premise.
Ce que TLS 1.3 couvre / ne couvre pas
TLS 1.3 par défaut
OpenAI API utilise TLS 1.3 sur toutes les connexions. Bénéfices :
- Confidentialité in-transit : un attaquant réseau (man-in-the-middle, Wi-Fi public, ISP) ne peut pas lire les prompts en clair
- Intégrité : modification en transit détectée
- Authentification serveur : certificats x509 vérifiés, vous parlez bien à
api.openai.com - Forward secrecy : compromise d'une clé n'exposera pas les sessions passées
Ce que TLS NE couvre PAS
| Aspect | TLS protège ? |
|---|---|
| Transit (réseau) | ✓ |
| Stockage côté OpenAI | ✗ |
| Insider threat OpenAI (employés) | ✗ |
| Subpoena US (FISA, CLOUD Act) | ✗ |
| Transfert UE → US (RGPD) | Partiellement |
| Compromission cloud OpenAI | ✗ |
Stockage côté OpenAI
Selon politique 2026 (à vérifier sur openai.com/policies car évolue) :
- API tier standard : prompts/réponses stockés ~30 jours pour abuse monitoring, opt-out training par défaut.
- API tier Enterprise : Zero Data Retention possible sur demande, opt-out training par défaut, audit logs Enterprise.
- ChatGPT plain (chat.openai.com) : stockage potentiellement plus long, opt-out training disponible mais variable.
→ Même en tier API standard, vos prompts sont stockés 30j en clair chez OpenAI. TLS ne change rien à ça.
Subpoena US et CLOUD Act
OpenAI étant entreprise US, soumise à :
- CLOUD Act (2018) : autorités US peuvent demander accès aux données stockées par entreprises US, même si data physiquement à l'étranger
- FISA section 702 : surveillance étrangère par autorités US sans notification possible
- National Security Letters : ordres de divulgation avec gag order
Pour data sensibles (santé, défense, IP stratégique), risque réel non couvert par TLS.
End-to-end encryption avec OpenAI : limitations fondamentales
Pourquoi E2EE applicatif n'est pas possible
Pour qu'un LLM traite un prompt, il doit le lire en clair. Si le prompt arrive chiffré et qu'OpenAI n'a pas la clé de déchiffrement, OpenAI ne peut littéralement rien en faire, pas d'inférence possible.
[Votre app]
prompt en clair
│
│ TLS 1.3
▼
[api.openai.com]
prompt déchiffré (TLS terminé)
│
▼
[OpenAI inference servers]
prompt en clair en mémoire pendant inference
← admin OpenAI peut voir si abuse review
← stocké 30j en logs (clair)
│
▼
[response generation]
response en clair
│
│ TLS 1.3
▼
[Votre app]
Aucune phase n'est E2EE au sens cryptographique strict (clé partagée uniquement entre 2 endpoints, intermédiaire ne peut pas déchiffrer).
Solutions partielles émergentes 2024-2026
1. Confidential Computing
Intel TDX / AMD SEV-SNP / NVIDIA H100 Confidential Computing permettent exécution dans Trusted Execution Environment (TEE) où :
- Mémoire chiffrée par hardware
- Admin host (incluant cloud admin) ne peut pas inspecter
- Attestation cryptographique du code en exécution
OpenAI a annoncé travail sur des features Confidential Computing 2024-2025 mais déploiement limité 2026. Pas encore standard sur API.
Modèle de référence Apple Private Cloud Compute (PCC) introduit 2024 :
- Prompts chiffrés en transit
- Déchiffrés UNIQUEMENT dans TEE attesté
- Traités, puis destruction garantie post-traitement
- Audit code public possible
- "Cloud private inference" pattern
OpenAI ne propose pas l'équivalent en 2026 (mais inspire l'industrie).
2. Homomorphic Encryption (FHE)
Permet calcul sur données chiffrées sans déchiffrement. Théoriquement E2EE compatible LLM.
Réalité performance 2026 : FHE pour LLMs ~1000-10000× plus lent que inference standard. Inutilisable production sauf cas extrême.
Recherche active (Microsoft SEAL, IBM HElib, OpenFHE) mais pas mature.
3. Confidential Inference startups
Quelques startups 2024-2026 (Confidential VM-based inference) proposent solutions hybrides :
- Instances cloud avec TEE
- Gestion clés avec KMS isolé
- Attestation
Mais latence + coût élevés, écosystème jeune.
Conclusion : pas d'E2EE applicatif avec OpenAI standard 2026
Pour zéro-trust strict :
- Soit données ne quittent pas votre infra (on-premise)
- Soit Confidential Computing si disponible (rare encore)
- Soit acceptation du risque résiduel après mitigations
Données à NE JAMAIS envoyer à OpenAI standard
Liste explicite
| Type | Pourquoi | Alternative |
|---|---|---|
| RGPD Art. 9 (santé, opinion, religion, etc.) | DPIA + base légale solide requis, transfert US risqué | Azure EU + DPIA, Mistral, on-premise |
| Secrets industriels stratégiques | Risque insider + subpoena US | On-premise |
| Code propriétaire critique | IP exposure | On-premise, Azure EU avec opt-out training |
| M&A / stratégie en cours | Confidentialité contractuelle, IP | On-premise, Azure EU |
| Passwords / API keys / certificates | Logs OpenAI peuvent les retenir 30j | Ne JAMAIS, strip avant prompt |
| PII massif (10000+ records) | Minimisation RGPD violée | Pseudonymisation + Azure EU |
| Données classifiées défense | Interdit par law | On-premise air-gap obligatoire |
| Données sous NDA strict client | Risk juridique | Vérifier termes NDA, possiblement Azure EU |
Comment décider pratiquement
# Classifier et router
def classify_data_for_llm(content: str, context: dict) -> dict:
"""Classifie la donnée pour décider quel LLM utiliser."""
findings = {
"rgpd_article_9": detect_health_political_religious(content),
"secrets": detect_secrets(content), # API keys, passwords, certs
"code_proprietary": detect_proprietary_code(content),
"pii_massive": count_pii(content) > 10,
"ndatop": context.get("under_nda_strict", False),
}
if findings["secrets"]:
return {"action": "REJECT", "reason": "secrets detected, never send to LLM"}
if findings["rgpd_article_9"] or findings["code_proprietary"]:
return {"action": "ROUTE_ONPREM", "reason": "high sensitivity"}
if findings["pii_massive"]:
return {"action": "PSEUDONYMIZE_AND_AZURE_EU", "reason": "minimization required"}
# Default : tier OpenAI Enterprise OK
return {"action": "OPENAI_ENTERPRISE", "reason": "standard"}Alternatives concrètes par ordre d'effort
Alternative 1, Azure OpenAI Service (région EU)
Setup :
from openai import AsyncAzureOpenAI
client = AsyncAzureOpenAI(
azure_endpoint="https://my-resource-france-central.openai.azure.com/",
api_version="2024-08-01-preview",
api_key=os.environ["AZURE_OPENAI_API_KEY"],
)
response = await client.chat.completions.create(
model="gpt-4o-deployment", # nom du deployment, pas du model
messages=[...],
max_tokens=1500,
)Régions EU disponibles 2026 : France Central, West Europe (Pays-Bas), Sweden Central, Switzerland North, Germany West Central, Italy North.
Bénéfices :
- Pas de transfert US (data reste dans région choisie)
- DPA Microsoft Enterprise
- Conformité héritée Azure (HDS pour santé, ISO 27001, BSI C5, EU Data Boundary)
- Intégration Entra ID, Key Vault, Sentinel
- Auditabilité complète Azure logs
Limites :
- Lag par rapport à OpenAI direct (nouveaux modèles disponibles avec quelques semaines/mois de retard)
- Quotas régionaux parfois plus stricts
- Coût similaire à OpenAI direct
Effort migration : faible si vous utilisez déjà Azure. Code quasi-identique (SDK même API).
→ Recommandation #1 pour 80% des cas entreprise EU.
Alternative 2, Mistral AI (France)
Setup :
from mistralai import Mistral
client = Mistral(api_key=os.environ["MISTRAL_API_KEY"])
response = await client.chat.complete_async(
model="mistral-large-latest",
messages=[...],
max_tokens=1500,
)Bénéfices :
- Souveraineté EU forte (entreprise française, hébergement EU obligatoire)
- DPA français, juridiction française
- Modèles compétitifs (Mistral Large 2, Mixtral 8x22B, Codestral)
- Conformité EU AI Act ready (entreprise EU)
Limites :
- Modèles légèrement en-deçà GPT-4o sur certaines tâches (gap se réduit)
- Écosystème SDK plus jeune
- Prompt format légèrement différent (à adapter)
Effort migration : moyen (prompts à re-tester, parfois ajuster).
→ Recommandation pour orgs où souveraineté FR/EU est non-négociable.
Alternative 3, Anthropic Claude via AWS Bedrock EU
Setup :
import boto3
client = boto3.client(
"bedrock-runtime",
region_name="eu-central-1", # Frankfurt
)
response = client.converse(
modelId="anthropic.claude-sonnet-4-6-20250101-v2:0",
messages=[{"role": "user", "content": [{"text": "..."}]}],
inferenceConfig={"maxTokens": 1500},
)Bénéfices :
- Modèles Claude (qualité top tier 2026)
- AWS Bedrock data not used for training (Anthropic policy)
- Régions EU disponibles (Frankfurt, Ireland)
- Intégration ecosystem AWS (IAM, KMS, CloudTrail)
Limites :
- Anthropic est entreprise US, même si AWS Bedrock EU, certaines questions juridiques peuvent rester (contractuelles)
- Lag potentiel vs Claude direct API
Alternative 4, Google Gemini via Vertex AI (EU)
Setup :
from google.cloud import aiplatform
from vertexai.generative_models import GenerativeModel
aiplatform.init(project="my-project", location="europe-west4") # Pays-Bas
model = GenerativeModel("gemini-2.0-pro-exp-2026")
response = model.generate_content(
"...",
generation_config={"max_output_tokens": 1500},
)Bénéfices : si vous êtes déjà ecosystem Google Workspace.
Alternative 5, On-premise modèle open-source
Cf article Architecture sécurisée pour déployer un LLM on-premise. Récap :
- Llama 3.3 70B / Mistral Large 2 / Qwen 2.5 / DeepSeek V3
- vLLM ou TGI sur GPU H100 / L40S / A100
- Souveraineté absolue
- CapEx 50k-2M€ + expertise
→ Recommandation pour volume très élevé ou IP critique ou secret défense.
Décision multi-critères
| Critère | OpenAI standard | Azure OpenAI EU | Mistral EU | Bedrock Claude EU | On-premise |
|---|---|---|---|---|---|
| Souveraineté EU | 3/10 | 8/10 | 10/10 | 7/10 | 10/10 |
| Qualité top modèle | 10/10 | 10/10 | 8/10 | 10/10 | 7-8/10 |
| Coût (volume modéré) | 7/10 | 7/10 | 8/10 | 7/10 | 5/10 |
| Coût (volume élevé) | 5/10 | 5/10 | 6/10 | 6/10 | 9/10 |
| Effort migration | n/a | Faible | Moyen | Moyen | Élevé |
| Conformité sectorielle (HDS, etc.) | 4/10 | 9/10 | 8/10 | 7/10 | 10/10 |
| Latency | 8/10 | 8/10 | 9/10 | 8/10 | 9/10 |
Recommandation pragmatique 2026 : Azure OpenAI EU pour 80% des cas, Mistral si souveraineté FR critique, on-premise si volume très élevé / IP stratégique. Hybride avec routing par classification donnée.
Techniques de minimisation et pseudonymisation upstream
Si vous devez envoyer à OpenAI standard malgré tout, mitiger en amont.
Technique 1, Pseudonymisation Presidio
from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine
from presidio_anonymizer.entities import OperatorConfig
analyzer = AnalyzerEngine()
anonymizer = AnonymizerEngine()
PII_ENTITIES = ["EMAIL_ADDRESS", "PHONE_NUMBER", "PERSON", "FR_NIR", "IBAN_CODE", "CREDIT_CARD"]
# Mapping local pour reverse-substitution
class PIIMapper:
def __init__(self):
self._map = {} # token → real value
self._counter = {} # entity_type → counter
def get_token(self, entity_type: str, real_value: str) -> str:
if real_value in self._map.values():
return [k for k, v in self._map.items() if v == real_value][0]
self._counter[entity_type] = self._counter.get(entity_type, 0) + 1
token = f"[{entity_type}_{self._counter[entity_type]:03d}]"
self._map[token] = real_value
return token
def reverse(self, text: str) -> str:
for token, real_value in self._map.items():
text = text.replace(token, real_value)
return text
def pseudonymize_for_llm(text: str, mapper: PIIMapper, language: str = "fr") -> str:
results = analyzer.analyze(text=text, language=language, entities=PII_ENTITIES)
# Replace from end to start to preserve indices
text_pseudo = text
for r in sorted(results, key=lambda x: x.start, reverse=True):
original = text[r.start:r.end]
token = mapper.get_token(r.entity_type, original)
text_pseudo = text_pseudo[:r.start] + token + text_pseudo[r.end:]
return text_pseudo
# Usage
mapper = PIIMapper()
prompt_user = "Bonjour, je suis Marie Dupont (marie.dupont@example.com), pour ma commande #1234..."
prompt_safe = pseudonymize_for_llm(prompt_user, mapper)
# → "Bonjour, je suis [PERSON_001] ([EMAIL_ADDRESS_001]), pour ma commande #1234..."
response = await openai_client.chat.completions.create(
messages=[{"role": "user", "content": prompt_safe}],
model="gpt-4o",
)
answer_safe = response.choices[0].message.content
# La réponse contient les tokens [PERSON_001], [EMAIL_ADDRESS_001]
# Re-substituer pour le user final
answer_real = mapper.reverse(answer_safe)
# OpenAI n'a jamais vu marie.dupont@example.com, l'utilisateur final reçoit la version normaleLimites pseudonymisation :
- Si entropy faible (peu de users), ré-identification possible
- Si plusieurs prompts liés, attaque par triangulation
- N'élimine pas le risque de data classifiée article 9
Technique 2, Tokenisation HMAC stable
Pour identifiants techniques (IDs commande, IDs client) qui ne sont pas PII directs mais permettent re-link :
import hmac
import hashlib
import os
TOKEN_KEY = os.environ["TOKEN_HMAC_KEY"].encode()
def tokenize_id(identifier: str) -> str:
h = hmac.new(TOKEN_KEY, identifier.encode(), hashlib.sha256).hexdigest()
return f"id_{h[:12]}"
def detokenize_id(token: str, mapping: dict) -> str:
return mapping.get(token, token)
# Usage : remplacer les IDs avant envoi LLM
order_id = "ORD-2026-001234"
order_token = tokenize_id(order_id) # "id_a1b2c3d4e5f6"
# Mapper local
mapping[order_token] = order_id
prompt = f"Concernant la commande {order_token}..."
# → OpenAI voit le token, pas l'ID réelTechnique 3, Minimisation explicite
def minimize_for_llm(full_context: dict, request_intent: str) -> dict:
"""N'inclure que les infos strictement nécessaires."""
if request_intent == "summarize_email":
return {"email_body": full_context["email_body"]}
# Pas d'historique, pas de métadonnées user, pas d'IDs
if request_intent == "classify_ticket":
return {"ticket_subject": full_context["ticket_subject"],
"ticket_first_message": full_context["ticket_first_message"][:500]}
# Refuse si intent inconnu
raise ValueError(f"Unknown intent: {request_intent}")Technique 4, Splitting documents
def split_and_filter_relevant(document: str, query: str) -> str:
"""Split doc en chunks, n'envoyer que les chunks pertinents pour la query."""
chunks = split_into_chunks(document, max_size=500)
# Embedding similarity locale (ne va pas chez OpenAI)
relevant = filter_by_local_embedding(chunks, query, top_k=3)
return "\n".join(relevant)Technique 5, Privacy-preserving prompt engineering
# Anti-pattern : exposer noms individuels
prompt = "Qui parmi mes clients John Doe, Jane Smith, Marie Dupont a un crédit > 10k€ ?"
# Pattern : exposer info agrégée seulement
prompt = "Classer ces 3 montants en risque/non-risque selon le seuil 10k€ : 5000, 15000, 8000."
# Résoudre le mapping clients-montants en localDécision documentée pour audit / DPIA
Template DPIA spécifique LLM
# DPIA, Usage OpenAI API pour [Application]
## 1. Description du traitement
- Application : ZerodaySupport ChatBot SAV v2.4
- Cas d'usage : Réponses automatiques niveau 1 SAV, escalation humaine si complexe
- Volume estimé : ~50 000 conversations/mois
- Données traitées :
* PII clients (nom, email, téléphone)
* Numéros commande
* Historique conversation
- Catégories acteurs :
* Utilisateurs : clients ZerodaySupport (particuliers EU)
* Personnel : équipe SAV (visualisation)
* Sous-traitants : OpenAI (API tier Enterprise)
## 2. Nécessité et proportionnalité
### Pourquoi ce traitement ?
Réduction temps réponse SAV (-60%), disponibilité 24/7, réduction coût support.
### Alternatives évaluées
- Mistral EU : qualité légèrement inférieure pour notre cas (test 2026-Q1, 8/10 vs 10/10)
- Azure OpenAI EU : équivalent qualité, choisie comme alternative en cours d'évaluation
- On-premise : non retenu (CapEx, expertise, volume insuffisant)
### Justification choix OpenAI standard (transitoire)
- Migration Azure OpenAI EU planifiée Q3 2026
- Tier API Enterprise + DPA + opt-out training
- Volume actuel ne justifie pas on-premise
## 3. Risques identifiés
### Confidentialité
- Transit UE→US (Schrems II) : risque MOYEN, atténué par DPA + SCC
- Logs OpenAI 30j : risque FAIBLE post-mitigation pseudonymisation
- Insider OpenAI : risque RÉSIDUEL après mitigations
- Subpoena US : risque RÉSIDUEL FAIBLE (données pseudonymisées)
### Intégrité
- Prompt injection : risque MOYEN, mitigation guardrails (classifier + filter)
- Hallucinations : risque MOYEN, disclaimer + escalation humaine
### Disponibilité
- Panne OpenAI : risque MOYEN, plan failover Azure OpenAI
### Conformité
- RGPD Art. 32 : OK avec mitigations
- RGPD Art. 6 : base légale = legitimate interest (intérêt légitime)
- EU AI Act : non haut risque (Annex III non applicable au SAV générique)
## 4. Mitigations implémentées
- [x] Pseudonymisation upstream (Presidio), emails, noms, téléphones, IBAN remplacés
- [x] Minimisation : context limité au strict nécessaire
- [x] DPA Enterprise OpenAI signé (réf : DPA-OAI-2025-0042)
- [x] Opt-out training par défaut
- [x] Tier API Enterprise (pas plain ChatGPT)
- [x] Audit logs structurés avec PII redaction
- [x] Disclaimer chatbot IA dans UI
- [x] Right to erasure implémenté (purge logs par user_id_hash)
- [x] Retention 1 an logs sécurité, 90j logs informationnels
- [x] Plan migration Azure OpenAI EU Q3 2026
## 5. Risque résiduel
Niveau : ACCEPTABLE TRANSITOIREMENT (jusqu'à migration Azure EU).
Justification : mitigations couvrent confidentialité courante, transit US
limité par pseudonymisation, migration imminente vers EU.
## 6. Validation
- DPO : Marie Lambert, signé 2026-04-15
- RSSI : Jean Bernard, signé 2026-04-15
- AI Officer : Claire Roux, signée 2026-04-15
- Métier : Pierre Martin (Head of Customer Support), signé 2026-04-15
## 7. Revue
- Cadence : annuelle minimum
- Déclencheurs ad hoc : changement OpenAI ToS, jurisprudence Schrems III,
changement classification donnée, incident
- Prochaine review : 2027-04-15
- Migration Azure EU prévue : Q3 2026 → DPIA refresh post-migrationAnti-patterns DPIA
- DPIA générique copié-collé sans analyse spécifique → auditeur va voir
- Pas de validation signée → impossible à défendre en audit
- Pas de versioning → évolutions invisibles
- Stocké dans email au lieu de système de gouvernance → introuvable
Règle de décision rapide
def should_use_openai_standard(data_classification: str, content: str) -> dict:
"""Aide-décision rapide."""
# Bloqueurs absolus
if data_classification == "rgpd_article_9":
return {"decision": "NO", "alternative": "Azure OpenAI EU + DPIA, ou on-premise"}
if contains_secrets(content): # API keys, passwords
return {"decision": "NO", "alternative": "Strip secrets first, never send"}
if data_classification == "secret_defense":
return {"decision": "NO", "alternative": "On-premise air-gap obligatoire"}
if data_classification == "confidential" and not has_pseudonymization(content):
return {"decision": "MAYBE", "condition": "Pseudonymize first, then OK with Enterprise tier"}
# Acceptable
if data_classification in {"public", "internal"}:
return {"decision": "YES", "tier": "OpenAI Enterprise"}
# Default : besoin DPIA
return {"decision": "DPIA_REQUIRED", "next": "Run DPIA before decision"}Erreurs récurrentes 2026
Erreur 1, "TLS suffit"
Croyance largement répandue. TLS = transit. Stockage tiers + insider + subpoena = autre histoire.
Erreur 2, Penser pouvoir E2EE applicatif
Pas possible avec API LLM standard. Confidential Computing partiel ou rien.
Erreur 3, Envoyer secrets / passwords
Souvent involontaire (logs apps mal préparés). Strip avant prompt.
Erreur 4, Pas de DPIA pour usage entreprise
Violation RGPD si données personnelles. DPIA obligatoire dès traitement de PII massif.
Erreur 5, ChatGPT plain pour usage corporate
Tier inadapté entreprise. Toujours minimum tier Enterprise.
Erreur 6, Pas de pseudonymisation
PII envoyés en clair "parce que OpenAI ne fait pas de training". OK pour training mais 30j de logs en clair restent. Pseudonymisation upstream quand possible.
Erreur 7, Pas d'alternative évaluée
"OpenAI parce que c'est connu". Évaluer Azure OpenAI EU systématiquement.
Erreur 8, DPIA générique
Copié-collé sans analyse. DPIA spécifique au cas d'usage.
Ce que vous devriez retenir
- TLS 1.3 = baseline nécessaire mais pas suffisant pour données sensibles
- E2EE applicatif = pas possible avec OpenAI API standard
- Confidential Computing = solution partielle émergente, peu mature 2026
- FHE = théoriquement possible, pratiquement inutilisable
- Données à NE JAMAIS envoyer : RGPD Art. 9, secrets, IP critique, classifié défense
- Alternatives 2026 : Azure OpenAI EU (#1 recommandé), Mistral EU, Bedrock Claude EU, on-premise
- Si OpenAI standard nécessaire : pseudonymisation Presidio + minimisation + tokenisation + tier Enterprise
- DPIA documentée signée DPO + RSSI + AI Officer + métier
- Décision multi-critères matrice pondérée
- Cadence revue annuelle + déclencheurs ad hoc
Le chiffrement seul ne résout pas le problème. La vraie question est : quelles données envoyer et où. Les choix architecturaux (Azure EU, Mistral, on-premise) ont plus d'impact que des techniques de chiffrement applicatives qui ne sont pas vraiment possibles avec l'API standard.
Pour les données sensibles, en 2026, Azure OpenAI Service en région EU est le compromis pragmatique pour la majorité des entreprises EU. Pour la souveraineté absolue, on-premise. Pour les données publiques / non sensibles, OpenAI standard reste OK avec les bonnes mitigations.
Pour aller plus loin : pour le panorama global des risques d'intégrer ChatGPT : quels sont les risques si j'intègre ChatGPT dans mon SI. Pour la couche zero-trust générale : chiffrement, isolation et zero-trust appliqués aux workloads IA.







