Ce que le passage en production change pour les startups IA

Un seuil de montée en charge dangereux peut être atteint avant même qu’une startup IA n’ait un trafic important. Un prototype peut fonctionner avec une clé API et une capacité partagée. Avec de vrais utilisateurs, les identifiants, la disponibilité du service et des dépenses significatives se retrouvent dans le même système.

Les raccourcis du prototype ont des conséquences bien réelles

De vrais utilisateurs font monter les enjeux. Les limites de quota peuvent perturber les requêtes. La supervision aide les équipes à distinguer les défaillances de l’application des problèmes de trafic ou de capacité.

Dépasser le stade du prototype peut nécessiter des projets cloud, des comptes de service, la gestion des identités et des accès (IAM), la facturation et la journalisation. L’IAM définit quels utilisateurs et quelles identités logicielles peuvent accéder à des ressources particulières.

La production change l’environnement autour du modèle

Le passage en production concerne à la fois le modèle et son environnement d’exploitation. Une équipe doit décider quelles identités peuvent accéder au modèle, comment les requêtes sont observées, où les charges de travail s’exécutent et comment les dépenses sont maîtrisées.

Les identifiants du prototype peuvent devenir des risques de sécurité et de coût

Les clés API brutes réduisent les frictions de mise en place pendant les expérimentations. Dès qu’un produit sert de vrais utilisateurs, une fuite d’identifiants peut exposer des ressources payantes à une utilisation non autorisée.

La sécurité des identifiants est donc aussi un contrôle financier.

Secret Manager est le service de Google Cloud destiné à stocker des valeurs sensibles telles que des identifiants.

Google décrit également des contrôles permettant de limiter les dépenses.

Un 429 peut avoir plusieurs causes

Une réponse HTTP 429 signifie qu’un service limite les requêtes. Dynamic Shared Quota est le mécanisme de Google pour allouer une capacité de modèle partagée entre différentes charges de travail.

Retry and backoff consiste à réessayer une requête ayant échoué après des délais progressivement plus longs.

Certaines charges de travail peuvent tolérer une exécution différée, notamment la synthèse de documents, la traduction en masse, les backfills d’embeddings et les travaux d’évaluation. Un backfill d’embeddings génère des représentations vectorielles pour une collection de données existante. Le traitement par lots regroupe ce travail pour une exécution asynchrone.

Les contrôles peuvent gagner en maturité à mesure que l’exposition augmente

Différentes formes d’exposition créent des exigences d’exploitation différentes. Les identifiants créent un risque de sécurité, tandis que la facturation crée un risque financier. Les requêtes orientées utilisateur ajoutent des exigences de disponibilité du service.

Le même enjeu s’étend aux agents IA qui naviguent sur le web, appellent des outils ou exécutent du code. Le prompt injection est une tentative de manipuler un système d’IA au moyen d’instructions malveillantes dans son entrée. Une identité strictement limitée ne peut accéder qu’aux ressources nécessaires à sa tâche.

Les agents peuvent entreprendre des actions au-delà de la génération de texte, ce qui fait des frontières d’autorisation des décisions d’ingénierie très concrètes. Les équipes doivent décider quelles ressources un agent peut lire, quels outils il peut appeler et quelles opérations il peut exécuter.

Principaux points à retenir pour les dirigeants

Le risque de production commence avant le passage à une échelle massive : De vrais utilisateurs transforment les raccourcis du prototype en risques de sécurité, de coût et de disponibilité. Les dirigeants doivent mettre en place la supervision, l’IAM et des contrôles de facturation à mesure que l’exposition augmente.
La préparation à la production va au-delà du modèle : L’identité, l’observabilité, l’emplacement des charges de travail et les contrôles des dépenses font partie de l’architecture de production. Traitez ces décisions comme des exigences d’infrastructure fondamentales.
Les identifiants sont aussi des contrôles financiers : Des clés API divulguées peuvent exposer des ressources payantes à une utilisation non autorisée. Déplacez les identifiants de production vers des secrets gérés et limitez strictement les accès.
Concevez pour la limitation des requêtes et la variabilité de capacité : Les réponses HTTP 429 peuvent refléter des contraintes de capacité partagée. Utilisez la supervision, retry and backoff, et basculez les charges de travail tolérantes au délai vers le traitement par lots lorsque c’est pertinent.
Faites évoluer les contrôles avec les capacités des agents : Les exigences de sécurité augmentent lorsque des agents IA peuvent naviguer, appeler des outils ou exécuter du code. Donnez à chaque agent uniquement les identités, ressources et autorisations nécessaires à sa tâche.