8 Min. Temps de lecture
Google Gemini est arrivé dans le cloud d’entreprise, et l’AI Act est devenu applicable en même temps. Quiconque construit des pipelines d’inférence sans prendre en compte les obligations pour les modèles d’IA à usage général construit une architecture qui sera rejetée au plus tard lors de l’audit.
Les points clés en bref
- Les obligations de l’AI Act ne sont pas une extension du RGPD. Les modèles GPAI ont leurs propres obligations de transparence, de documentation et de gestion des risques. Un DPA avec Google ne les couvre pas.
- Vertex AI n’est pas automatiquement conforme. Le service géré facilite la journalisation et l’épinglage de région, mais laisse la responsabilité de la cartographie des modèles, de l’évaluation des cas d’utilisation et de la FRIA à l’égard du client.
- Gemma auto-hébergé coûte des heures de GPU plus le surcoût de cluster. Quiconque déplace Gemini vers ses propres GPU via le jardin de modèles assume la charge de conformité et les dépenses courantes de GPU. Cela ne vaut la peine que pour un volume clair.
Lié :Android 17 pousse Gemini sous le système d’exploitation / EKS 1.36 devient cher sans discipline FinOps
Ce que Google Gemini change dans le cloud d’entreprise sur le plan réglementaire
Qu’est-ce qu’une architecture d’inférence conforme à l’AI Act ? Une architecture d’inférence est conforme à l’AI Act si elle reflète techniquement les obligations de l’AI Act de l’UE pour les modèles d’IA à usage général et les applications à haut risque. Cela comprend la transparence des modèles, la journalisation des entrées et des sorties dans les cas d’utilisation réglementés, l’évaluation des risques par cas d’utilisation, l’évaluation de l’impact sur les droits fondamentaux dans les lieux publics et une séparation claire entre les données de formation et d’inférence.
L’AI Act s’adresse à Google Gemini non pas en tant que produit, mais en tant que modèle d’IA à usage général. Les obligations concernent le fournisseur et le déployeur. Le fournisseur est Google. Le déployeur est chaque entreprise qui utilise Gemini dans un cas d’utilisation spécifique. Cela déplace une partie de la responsabilité vers les équipes de cloud DACH qui consomment le modèle. Lors de l’audit, il ne suffit pas de dire « Google est responsable ». Quiconque appelle le modèle doit classer l’appel, le documenter et le classer dans une classe de risque.
Ce n’est pas de la théorie. Les premières procédures de sanction sont en cours, les publications de l’Office de l’IA de l’UE sont explicites. Quiconque planifie une architecture d’inférence sans dimension AI Act planifie des dettes.
Où Vertex AI facilite la conformité et où elle ne le fait pas
Vertex AI est la plate-forme d’inférence gérée par Google avec des modèles Gemini. Elle résout automatiquement trois problèmes : l’épinglage de région sur les sites de l’UE, la journalisation avec les journaux d’audit cloud et les clauses contractuelles standard dans l’avenant de traitement des données. Ce que Vertex AI ne résout pas : la transparence des modèles pour le cas d’utilisation spécifique, la classification des risques contre l’AI Act, l’évaluation de l’impact sur les droits fondamentaux dans les applications à haut risque.
Cela signifie concrètement : Une application RH avec Gemini pour examiner les candidatures est une application à haut risque selon l’annexe III de l’AI Act. Vertex AI ne fournit pas cette classification. Le déployeur doit la réaliser lui-même, assurer la journalisation des décisions du modèle pour chaque candidature et documenter l’aperçu des taux de faux positifs et de faux négatifs. Si la surveillance pose des questions, la réponse « Vertex AI enregistre tout cela » est insuffisante.
Vertex AI fournit l’infrastructure, l’AI Act exige la classification. La lacune entre les deux ne peut être comblée que par le déployeur.
Endpoints Gemini auto-hébergés : quand ils sont rentables
Google propose des modèles Gemini dans plusieurs variantes, notamment des familles de modèles ouverts tels que Gemma 2 et 3, ainsi que des endpoints propriétaires qui ne fonctionnent que dans Vertex AI. L’auto-hébergement n’est donc pas un choix évident. Pour les variantes Gemma, il existe de véritables chemins On-Premise via Triton Inference Server ou vLLM sur vos propres GPU. Pour les classes Gemini Pro propriétaires, ce n’est pas le cas, elles restent liées à Vertex.
La question « auto-hébergé ou géré » se réduit ainsi pour la plupart des charges de travail à Gemma. Pour les modèles propriétaires, seul Vertex est disponible, et la question de la conformité se déplace vers la configuration de l’endpoint dans le projet : région, journalisation, liaisons IAM, piste d’audit.
| Dimension | Vertex AI géré | Gemma auto-hébergé sur GKE |
|---|---|---|
| Modèle de coût | Par token, environ 0,3 centime par 1 000 tokens de sortie pour Gemini Flash, nettement plus élevé pour Gemini Pro | Tarif horaire GPU plus frais généraux de cluster, environ 3 euros par heure H100 à la demande |
| Effort de conformité | Région et journalisation prêts à l’emploi, classification AI-Act chez le client | Pipeline de conformité complet chez le client, pas de journalisation par le fournisseur |
| Carte de modèle | Publié par Google, à classer par le déployeur | Carte de modèle Gemma plus documentation de réglage personnalisé |
| Souveraineté des données | Épinglage de région sur l’UE, accès des autorités selon le droit américain possible | Contrôle total, à condition que le fournisseur de GPU ne soit pas accessible selon le droit américain |
| Pertinent à partir de | Immédiatement, pour la plupart des cas d’utilisation | Environ 10 millions de tokens par jour ou avec exigence de souveraineté des données claire |
Source : pages de tarification Google Cloud et évaluation propre des prix GPU hyperscaler en date de mai 2026.
En pratique, le chemin de l’auto-hébergement est rarement rentable en dessous de 10 millions de tokens par jour. En dessous de ce seuil, la surcharge de travail pour DevOps, MLOps et la conformité est plus coûteuse que les coûts supplémentaires de tokens chez Vertex. Au-dessus de ce seuil, les choses changent, surtout si la souveraineté des données est exigée ou si des chemins de réglage spécifiques sont nécessaires, ce que Vertex ne permet pas.
Les cinq obligations de l’AI-Act qui doivent être intégrées dans chaque architecture Gemini
Ces cinq obligations peuvent être mises en œuvre techniquement, mais pas sans frais. La journalisation est la discipline la moins chère, tandis que la FRIA et la classification des risques sont les plus coûteuses, car elles nécessitent une collaboration juridique. Une architecture d’inférence qui ne prend pas en compte ces obligations dans sa configuration initiale devra les ajouter sous pression plus tard.
Pourquoi les coûts de GPU influencent la décision d’architecture
Lorsqu’on héberge Gemma en propre, on achète une capacité de GPU qui ne doit pas tomber en panne. Un H100 en tant que nœud unique n’est pas une architecture productive. La haute disponibilité nécessite au moins trois nœuds dans deux zones, une capacité de sauvegarde pour les exécutions de formation et de réglage, un équilibreur de charge avec affinité. Les 3,80 euros de l’heure nominal deviennent 6 à 8 euros effectifs dans une production réelle, selon le taux d’utilisation.
Ce n’est pas faux, c’est juste cher. Lorsqu’on a un volume d’inférence clair avec des nombres de jetons à six ou sept chiffres par jour, on peut calculer le chemin de l’hébergement personnel. Lorsqu’on démarre de manière expérimentale, on utilise Vertex plus rapidement et à moindre coût, et on gagne du temps pour établir les bases de conformité avant de prendre une décision sur les GPU.
Ce que les équipes cloud DACH doivent intégrer dans les six prochains mois
Trois éléments déterminent si l’intégration de Gemini par une entreprise est conforme à l’AI Act. Premièrement : inventaire des cas d’utilisation avec une classe de risque par application, documenté et accessible lors d’un audit. Deuxièmement : décision de plateforme, pour savoir si Vertex AI est utilisé par défaut ou si certains cas d’utilisation sont délocalisés sur Gemma auto-hébergé. Troisièmement : matrice de responsabilité qui définit explicitement ce que Google fournit et ce que le déployeur assume.
Sans ces trois éléments, une architecture se développe en réaction à chaque nouveau besoin, sans que la substance de conformité ne croisse avec elle. C’est la source d’erreur la plus fréquente. Celui qui prend ces décisions avant le deuxième cas d’utilisation construit une base solide. Celui qui attend construit après coup.
Foire aux questions
L’emplacement de données européen de Vertex AI suffit-il pour la conformité au RGPD ?
L’emplacement de données européen est une condition nécessaire mais pas suffisante. Google, en tant qu’entreprise américaine, reste soumis au CLOUD Act, ce qui nécessite des mesures de protection contractuelles et techniques supplémentaires. Les clauses contractuelles standard associées à un cryptage avec des clés gérées par le client via Cloud KMS ou External Key Manager constituent le chemin le plus courant. Sans ce complément, la conformité au RGPD pour les données sensibles est vulnérable.
Quels cas d’utilisation de Gemini sont considérés comme à haut risque selon l’AI Act ?
L’annexe III de l’AI Act liste des domaines spécifiques : infrastructure critique, éducation et formation professionnelle, emploi et décisions en matière de personnel, accès aux services publics et aux prestations sociales, répression pénale, contrôle des frontières, administration de la justice. Celui qui utilise Gemini dans l’un de ces domaines construit une application à haut risque avec obligation de FRIA, de journalisation renforcée et de notification aux autorités.
Les entreprises de moins de 250 employés doivent-elles se conformer à l’AI Act ?
Oui, l’AI Act ne différencie pas principalement en fonction de la taille de l’entreprise, mais en fonction de la classe de risque du cas d’utilisation. Les PME bénéficient de certaines facilitations en matière de documentation, mais les obligations fondamentales s’appliquent. Un start-up de trois personnes qui utilise Gemini pour la présélection des candidatures construit une application à haut risque avec toutes les obligations.
En quoi l’AI Act diffère-t-il du RGPD en matière d’exigences de journalisation ?
Le RGPD exige un registre des activités de traitement et des journaux d’audit pour les données sensibles. L’AI Act exige en outre une journalisation de l’activité du modèle avec les entrées, les sorties, les valeurs de confiance et les indications de version, qui vise spécifiquement à garantir la traçabilité de la décision de l’IA. Les obligations se chevauchent, mais ne sont pas identiques. Celui qui ne se conforme qu’à la journalisation du RGPD n’a pas automatiquement une journalisation conforme à l’AI Act.
Conseils de lecture de la rédaction
Plus de contenu du réseau MBF Media
Image de titre : générée par IA (mai 2026)
Source de l’image : générée par IA (mai 2026), certificat C2PA intégré à l’image
