Déploiement de LLM dans les secteurs réglementés : Feuille de route HIPAA, SOC2 et GDPR pour 2026

Le défi technique du déploiement d'un grand modèle linguistique dans une entreprise réglementée n'est pas principalement un problème d'apprentissage automatique. Les modèles existent, ils fonctionnent et sont suffisamment performants pour des cas d'utilisation sérieux dans les domaines clinique, financier et de l'assurance. Le défi réside dans l'architecture autour du modèle : qui contrôle les données, où elles circulent, ce qui est journalisé, qui a approuvé le fournisseur, et comment l'équipe de conformité peut démontrer tout cela à un régulateur.

Medtronic, avec 90 000 employés et des portefeuilles de dispositifs réglementés par la FDA, utilise l'IA en production. Innovaccer traite des informations de santé protégées à grande échelle au sein d'une plateforme d'intelligence clinique gouvernée. Aviva, opérant sous le RGPD britannique, utilise l'IA dans l'ensemble de ses processus d'assurance. Siemens Healthineers a déployé l'IA simultanément dans plusieurs juridictions réglementaires. Il ne s'agit pas de preuves de concept. Ce sont des déploiements de production à l'échelle de l'entreprise qui ont passé les examens juridiques, de conformité et de sécurité informatique.

L'architecture qui a rendu chacun de ces déploiements possible est le sujet de ce guide. Il couvre les exigences réglementaires spécifiques aux secteurs de la santé, des services financiers et de l'assurance, les décisions techniques que ces exigences entraînent, et à quoi ressemble concrètement un déploiement isolé par VPC et gouverné pour les équipes se préparant à suivre le même processus d'approbation.

Ce qui rend le déploiement de l'IA dans les secteurs réglementés différent

Les différences entre le déploiement d'IA réglementé et non réglementé ne sont pas principalement techniques. Les modèles sous-jacents sont les mêmes. La différence réside dans l'obligation légale, la structure de responsabilité et la charge d'audit, et ces éléments modifient les décisions architecturales de fond en comble.

• Les règles de traitement des données sont définies en externe. Dans les environnements réglementés, les utilisations autorisées des données sont définies par la loi, et non par le jugement des ingénieurs. Un système d'IA qui envoie des dossiers de patients à une API externe peut être techniquement élégant et constituer simultanément une violation de la HIPAA. La sophistication technique de l'implémentation est sans rapport avec la norme légale. Ce qui compte, c'est où les données sont allées et si elles étaient autorisées à y aller.

• Les systèmes d'IA sont désormais soumis à l'audit réglementaire. Les régulateurs des secteurs de la santé, des services financiers et de l'assurance attendent de plus en plus des organisations qu'elles documentent les données auxquelles leurs systèmes d'IA ont accédé, les décisions que ces systèmes ont influencées, qui a autorisé le déploiement et à quoi ressemblait le processus de supervision humaine. La règle de sécurité HIPAA exige des garanties appropriées, y compris le chiffrement au repos et en transit, basées sur une évaluation des risques. La charge de la preuve de la conformité incombe à l'organisation à tout moment.

• Votre fournisseur d'IA relève de votre champ de conformité. Tout fournisseur qui crée, reçoit, maintient ou transmet des informations de santé protégées en votre nom est un Partenaire Commercial (Business Associate) en vertu de la HIPAA et nécessite légalement un BAA (Business Associate Agreement) signé avant que les PHI ne touchent son infrastructure. La plupart des offres d'API LLM publiques standard ne sont pas couvertes par un BAA par défaut et nécessitent des accords d'entreprise ou des modèles de déploiement alternatifs. AWS Bedrock et Azure OpenAI Service proposent des options éligibles au BAA avec des exigences de configuration spécifiques, mais l'éligibilité n'est pas synonyme de conformité.

• La résidence des données peut éliminer entièrement les options SaaS. Une compagnie d'assurance européenne traitant des données personnelles couvertes par le RGPD ne peut légalement acheminer ces données via une infrastructure basée aux États-Unis sans un accord de Clauses Contractuelles Types ou un autre mécanisme de transfert RGPD approuvé. De nombreux produits de passerelle IA SaaS sont basés aux États-Unis, ce qui signifie que la documentation de transfert de données UE-États-Unis doit être complétée avant tout déploiement technique. Pour certaines organisations et certains types de données, cela élimine entièrement l'option SaaS.

• Les pistes d'audit ne sont pas facultatives, et les pistes structurées sont préférables. Chaque accès aux données réglementées, y compris l'accès assisté par l'IA, doit générer un enregistrement d'audit. Pour la HIPAA, cet enregistrement doit inclure l'horodatage, l'identité de l'accédant, l'action effectuée et une référence aux PHI consultées. Les systèmes d'IA qui génèrent automatiquement ces enregistrements au format JSON structuré sont déployables. Les systèmes qui nécessitent une corrélation manuelle des journaux après coup créent des lacunes de conformité que les régulateurs n'acceptent pas comme équivalentes.

Santé : Exigences HIPAA pour les déploiements de LLM

La HIPAA couvre tout système qui gère des Informations de Santé Protégées (PHI). Un déploiement de LLM est concerné si le modèle peut recevoir des PHI dans les invites, si des PHI apparaissent dans le contexte de génération augmentée par récupération transmis au modèle, ou si les sorties du modèle alimentent des décisions concernant des patients individuels. La synthèse de notes cliniques, l'analyse de dossiers patients, les outils d'aide au diagnostic et le support à l'autorisation préalable entrent tous dans ce cadre.

Trois règles HIPAA façonnent directement l'architecture de déploiement des LLM. La Règle de Confidentialité régit l'utilisation des PHI et l'accès à celles-ci, y compris la norme du "minimum nécessaire" qui limite l'exposition des données à ce qui est requis pour la tâche spécifique. La Règle de Sécurité exige des garanties administratives, physiques et techniques pour les PHI électroniques, y compris les contrôles d'accès, la journalisation d'audit et la sécurité de la transmission. La Règle de Notification des Violations définit ce qui se passe en cas de défaillance des contrôles. Toutes trois ont des exigences de mise en œuvre technique qui se manifestent dans la conception de l'infrastructure d'IA, et pas seulement dans les documents de politique.

Isolation des PHI : Pourquoi la plupart des API LLM cloud ne conviennent pas aux cas d'utilisation clinique

• Les offres d'API grand public standard d'OpenAI, Anthropic et Google ne sont généralement pas conçues pour les charges de travail réglementées par la HIPAA et ne proposent généralement pas d'accords de partenariat commercial (BAA) pour leurs points d'accès publics. Lorsque des PHI sont transmises à un service tiers agissant en tant que partenaire commercial sans BAA en place, cela constitue une violation de la conformité HIPAA. C'est l'un des modes de défaillance les plus courants dans les déploiements d'IA d'entreprise précoces qui progressent plus rapidement que leurs processus de gouvernance des fournisseurs.

• AWS et Microsoft proposent tous deux des accords de partenariat commercial HIPAA qui couvrent des services éligibles spécifiques au sein de leurs plateformes. AWS inclut les services éligibles dans son BAA standard, tandis que Microsoft offre une couverture via son Addendum sur la protection des données des services en ligne. Cependant, la conformité dépend de l'utilisation de services uniquement dans le périmètre et de leur configuration correcte. Le chiffrement au repos et en transit, la journalisation d'audit et les contrôles IAM du moindre privilège sont requis. La signature d'un BAA est un prérequis, pas l'état final de la conformité.

• Pour les cas d'utilisation clinique impliquant des PHI, le déploiement de modèles isolés par VPC ou auto-hébergés offre la limite architecturale la plus nette. Lorsque les modèles s'exécutent au sein du propre compte cloud de l'organisation, les PHI restent dans le périmètre de l'entreprise et ne sont pas exposées aux fournisseurs de modèles externes. Cela élimine le besoin d'un BAA distinct avec un fournisseur d'API de modèle tiers, bien qu'un BAA avec le fournisseur de cloud sous-jacent (par exemple AWS ou Azure) reste requis dans le cadre de la posture de conformité globale.

• Pour les organisations qui doivent utiliser des API de modèles externes dans des scénarios limités, le masquage ou la désidentification des données peut être un modèle viable. Les champs sensibles sont supprimés ou tokenisés avant l'envoi de la requête, et reconstruits uniquement dans l'environnement contrôlé après le retour de la réponse. Pour que cela soit conforme, la transformation doit garantir qu'aucune PHI identifiable n'est exposée au service externe, et le processus doit être documenté, validé et démontrable aux auditeurs dans le cadre des contrôles de conformité de l'organisation.

Exigences de journalisation d'audit HIPAA pour les systèmes d'IA

• La règle de sécurité HIPAA exige que les entités couvertes et les partenaires commerciaux mettent en œuvre des contrôles d'audit qui enregistrent et examinent l'activité dans les systèmes traitant des PHI électroniques. En pratique, cela signifie que les systèmes doivent générer des journaux qui capturent les événements d'accès d'une manière qui soutient l'enquête et la responsabilisation. Bien que la réglementation ne prescrive pas de champs exacts, les implémentations standard de l'industrie incluent les horodatages, l'identité de l'utilisateur ou du système, l'action effectuée et les données ou le système accédés. Pour les déploiements de LLM, cela s'étend à la capture de l'utilisateur ou de l'agent qui a initié une requête, du modèle qui l'a traitée, et d'un contexte suffisant pour reconstituer ce qui s'est passé. Les métriques d'utilisation agrégées seules ne sont pas suffisantes pour soutenir un audit ou une enquête sur un incident.

• La HIPAA exige que la documentation relative aux contrôles de sécurité, y compris les enregistrements d'audit le cas échéant, soit conservée pendant un minimum de six ans. De plus, les systèmes doivent mettre en œuvre des contrôles d'intégrité pour protéger les journaux contre toute altération ou suppression non autorisée. En pratique, cela est souvent réalisé grâce à des mécanismes de stockage inviolables tels que les configurations WORM (write-once-read-many), des contrôles d'accès stricts et des systèmes centralisés de gestion des journaux qui empêchent toute modification par les équipes opérationnelles.

• La HIPAA exige des mécanismes pour identifier et authentifier de manière unique les utilisateurs accédant aux systèmes contenant des PHI électroniques. Par conséquent, les journaux d'audit doivent pouvoir attribuer les événements d'accès à un individu ou à une identité de système spécifique. Les implémentations qui reposent uniquement sur des comptes de service partagés ou des clés API sans attribution au niveau de l'utilisateur créent des lacunes en matière de responsabilisation et rendent difficile le respect des exigences d'audit et d'enquête. Dans les systèmes d'IA modernes, cela nécessite généralement l'intégration de contrôles d'accès sensibles à l'identité afin que les actions effectuées via des agents ou des passerelles puissent être retracées jusqu'à l'utilisateur d'origine.

Exigences de contrôle d'accès

• La HIPAA exige que l'accès aux PHI soit contrôlé par des mesures de protection techniques et administratives, y compris l'identification unique des utilisateurs, l'authentification et les contrôles d'accès basés sur les rôles. De plus, la règle de confidentialité applique la norme du « minimum nécessaire » pour l'utilisation et la divulgation des PHI. En pratique, cela signifie que l'accès doit être provisionné et géré via un processus documenté, avec des autorisations alignées sur le rôle de l'utilisateur. Pour les systèmes d'IA, cela a deux implications. Premièrement, l'accès doit être lié aux identités individuelles via le fournisseur d'identité de l'organisation, et non à des clés API partagées qui ne peuvent pas être attribuées à des utilisateurs spécifiques. Deuxièmement, les contrôles basés sur les rôles doivent garantir que les utilisateurs ne peuvent accéder qu'aux capacités d'IA appropriées à leur fonction, par exemple, en séparant les flux de travail de facturation des flux de travail cliniques avec une exposition différente aux PHI.

• La norme du minimum nécessaire s'applique à la manière dont les PHI sont utilisées au sein d'un système, et pas seulement à l'utilisateur qui initie l'accès. Dans les systèmes d'IA, cela s'étend aux données incluses dans les invites et le contexte du modèle. Transmettre des dossiers patients complets alors qu'un sous-ensemble de champs structurés est suffisant peut ne pas être conforme au principe du minimum nécessaire. Bien que la HIPAA ne définisse pas explicitement comment cela s'applique aux invites d'IA, les organisations sont censées limiter l'exposition aux PHI à ce qui est requis pour la tâche. Appliquer cela au niveau de l'infrastructure, par exemple via une passerelle d'IA qui applique des politiques de données sensibles au contexte basées sur le rôle de l'utilisateur et le cas d'utilisation, est une approche pour garantir une adhésion cohérente plutôt que de s'appuyer sur une implémentation au niveau de l'application.

Services financiers : SOC2 et exigences réglementaires pour les déploiements de LLM

Les entreprises de services financiers qui déploient des LLM sont confrontées à un environnement réglementaire à plusieurs niveaux. Les exigences SOC2 Type II s'appliquent à l'infrastructure technologique. Les directives de l'OCC, de la Réserve fédérale et de la FINRA sur l'IA et le risque de modèle s'appliquent aux modèles utilisés dans les décisions financières. Et les dispositions de la loi européenne sur l'IA pour les systèmes d'IA à haut risque, applicables aux opérations de l'UE à partir d'août 2026, ajoutent une couche supplémentaire pour les organisations internationales. Ces cadres se chevauchent de manière à créer des exigences architecturales spécifiques pour l'infrastructure de passerelle d'IA et de déploiement de modèles.

Contrôles SOC2 Type II pour l'infrastructure d'IA

• Les passerelles d'IA et les plateformes de déploiement de modèles qui traitent des données financières sont incluses dans le périmètre des évaluations SOC2 Type II lorsqu'elles touchent des données ou des systèmes couverts par l'audit. Les critères de service de confiance pertinents sont CC6 (contrôles d'accès logiques et physiques), CC7 (surveillance des opérations système), CC8 (gestion des changements) et CC9 (atténuation des risques). Chaque critère exige des contrôles techniques spécifiques qui doivent être présents dans ou à côté de la passerelle d'IA.

• La constatation SOC2 la plus courante dans les déploiements de passerelles d'IA est un contrôle d'accès inadéquat au niveau de l'API : des comptes de service partagés qui ne peuvent pas attribuer l'accès à des individus, des clés API stockées dans le code source, ou des plateformes d'IA qui ne prennent pas en charge les contrôles d'accès granulaires requis par CC6. Choisir une plateforme qui s'intègre au fournisseur d'identité de l'entreprise et applique le RBAC au niveau du modèle et de l'équipe élimine ces constatations avant le début de la période d'audit.

• Le SOC2 Type II exige une preuve continue du fonctionnement des contrôles sur la période d'audit, généralement de six à douze mois. Cela signifie que les journaux d'audit doivent être générés en continu et conservés tout au long de la période, et non capturés à la demande lorsque les auditeurs les demandent. Les plateformes de passerelle d'IA qui produisent des journaux structurés et continus dès le premier jour de déploiement sont beaucoup plus faciles à auditer que les systèmes où la journalisation a été ajoutée après coup. Les preuves d'audit doivent montrer que les contrôles fonctionnaient de manière cohérente tout au long de la période, et pas seulement au moment de l'audit.

Gestion des risques de modèle (SR 11-7) pour les LLM

• La directive SR 11-7 de l'OCC et de la Réserve fédérale sur la gestion des risques de modèle s'applique aux modèles d'IA et de LLM utilisés dans les décisions de crédit, l'évaluation des risques et d'autres processus pertinents sur le plan réglementaire. La directive exige trois éléments pour chaque modèle concerné : la documentation de l'objectif, des données d'entraînement et de la méthodologie de test ; une validation indépendante par rapport à des normes de performance définies ; et une surveillance continue avec suivi des performances et détection de la dérive.

• Pour les LLM dans les services financiers, la charge de documentation SR 11-7 s'étend à l'infrastructure sur laquelle le modèle s'exécute. Quel LLM est utilisé, par quelles équipes, pour quelles décisions, à quel coût, avec quelle latence, et avec quel comportement de sortie observé, tout cela doit être documenté et disponible pour examen réglementaire. Une passerelle IA qui capture automatiquement ces données dans le cadre de sa journalisation standard produit les preuves de documentation du modèle comme un sous-produit des opérations normales. Cela réduit ce qui serait autrement un effort de documentation manuel considérable pour chaque modèle concerné.

Assurance : Résidence des données et exigences du RGPD

Les compagnies d'assurance opérant dans plusieurs juridictions sont confrontées à des restrictions de résidence des données et de transfert transfrontalier qui limitent directement les choix d'architecture IA. Le RGPD, le RGPD britannique et les lois sur la confidentialité des données des États américains contiennent tous des dispositions concernant l'endroit et la manière dont les données clients peuvent être traitées, y compris la possibilité de les envoyer à une API de modèle IA pour inférence.

• Base juridique du traitement des données RGPD : Les systèmes d'IA traitant des données personnelles doivent avoir une base juridique documentée en vertu de l'article 6 du RGPD. Pour la plupart des cas d'utilisation de l'IA dans l'assurance, la base est soit l'intérêt légitime, soit la nécessité contractuelle. Les deux exigent que le traitement soit documenté, proportionné à la finalité et divulgué dans la politique de confidentialité de l'organisation. Les systèmes d'IA traitant des données personnelles sans base juridique documentée créent une exposition réglementaire directe dans un cadre où les amendes peuvent atteindre 4 % du chiffre d'affaires annuel mondial.

• Restrictions de transfert transfrontalier : L'envoi de données personnelles de résidents de l'UE vers une infrastructure IA non-UE nécessite soit un accord de Clauses Contractuelles Types, soit un autre mécanisme de transfert RGPD approuvé. De nombreux fournisseurs de SaaS IA sont basés aux États-Unis. La documentation de conformité pour le transfert de données UE-États-Unis doit être complétée avec l'implication juridique avant le début du déploiement technique. Pour certains types de données et certaines tolérances au risque organisationnel, cette exigence nécessite effectivement un déploiement européen ou entièrement isolé en VPC, sans que les données ne franchissent les frontières juridictionnelles.

• Registres des activités de traitement en vertu de l'article 30 : Le RGPD exige des organisations qu'elles tiennent des registres des activités de traitement couvrant les systèmes d'IA, décrivant la finalité du traitement, les catégories de données, les transferts internationaux le cas échéant, et les mesures de sécurité appliquées. Les journaux d'audit de la passerelle IA fournissent les données brutes pour ces registres, mais doivent être configurés pour capturer les champs requis, y compris la catégorie de données, la finalité du traitement et la destination du transfert, dans un format que l'équipe de conformité peut présenter à un régulateur sur demande.

• Droit à l'explication pour les décisions automatisées : L'article 22 du RGPD restreint les décisions entièrement automatisées qui affectent de manière significative les individus et accorde aux individus le droit à une explication significative de la manière dont la décision a été prise. Les systèmes d'IA d'assurance qui aident à la souscription ou à la gestion des sinistres doivent être conçus avec une capacité de révision humaine et de génération d'explications intégrées au flux de travail, et non ajoutées après coup. La décision architecturale concernant la manière dont les recommandations de l'IA parviennent aux décideurs humains est une décision de conformité, et pas seulement un choix de conception de produit.

L'architecture isolée en VPC : Ce à quoi elle ressemble en pratique

Le déploiement de LLM isolé en VPC est le modèle d'architecture qui satisfait simultanément le plus large éventail d'exigences de l'industrie réglementée. L'isolation des PHI pour HIPAA, la résidence des données pour le RGPD, les contrôles de sécurité réseau pour SOC2, et la responsabilité opérationnelle pour les régulateurs des services financiers découlent tous d'un déploiement VPC correctement mis en œuvre. Comprendre ce que cela implique réellement est ce dont les équipes de conformité, d'infrastructure et de sécurité ont besoin avant une discussion d'approbation.

• Passerelle IA à l'intérieur du périmètre : La passerelle s'exécute comme un service conteneurisé au sein du VPC de l'organisation. Tous les appels d'API LLM sont acheminés via cette passerelle interne. Aucune application ne communique directement avec un fournisseur de modèle externe. La passerelle est le seul composant ayant une capacité de sortie vers des API externes, et uniquement lorsque l'architecture déployée permet l'accès à des modèles externes pour des cas d'utilisation spécifiques n'impliquant pas de données réglementées. Pour les déploiements entièrement isolés, même cette sortie est absente.

• Service de modèles à l'intérieur du périmètre : Pour les exigences HIPAA et de résidence stricte des données, le LLM lui-même s'exécute à l'intérieur du VPC. AWS Bedrock accessible au sein du même compte AWS, Azure OpenAI Service au sein d'un abonnement Azure avec une couverture BAA appropriée, ou des modèles open-source auto-hébergés sur une infrastructure GPU à l'intérieur du compte cloud satisfont tous à cette exigence. Dans les déploiements entièrement isolés, aucune donnée d'inférence de modèle ne quitte la limite du compte cloud de l'organisation à aucun moment du cycle de vie de la requête.

• Journaux d'audit dans le stockage appartenant au client : Tous les journaux d'audit sont écrits dans l'infrastructure de journalisation propre à l'organisation : CloudWatch, Azure Monitor, Splunk, ou un SIEM spécifié par le client. Les données de journalisation, qui peuvent elles-mêmes contenir des informations réglementées, ne transitent jamais vers le service de journalisation SaaS d'un fournisseur. Les politiques de rétention, les contrôles d'accès et la configuration du stockage infalsifiable sont gérés par l'équipe de conformité de l'organisation sans dépendre des paramètres de rétention d'un fournisseur.

• Aucun accès fournisseur au trafic de production : Dans un déploiement isolé par VPC correctement mis en œuvre, le trafic d'inférence de production, le contenu des invites et les réponses des modèles restent au sein de l'environnement cloud du client plutôt que d'être acheminés via une infrastructure gérée par le fournisseur. Cela réduit considérablement la visibilité externe sur les flux de données sensibles et s'aligne sur les exigences en matière de résidence des données et de confidentialité. L'accès au support, si nécessaire, est régi par des procédures d'accès d'urgence contrôlées et limitées dans le temps, avec l'approbation explicite du client, plutôt que par un accès persistant. Cette architecture minimise l'exposition du fournisseur aux données réglementées dans le chemin de production, bien que la relation avec le fournisseur pour les logiciels de plateforme et le support reste dans le cadre de la conformité globale de l'organisation.

Comment TrueFoundry résout le déploiement de LLM dans les secteurs réglementés

TrueFoundry se déploie entièrement au sein du compte cloud du client sur AWS, Azure ou GCP. Aucune donnée de production, y compris le contenu des invites, les réponses des modèles, les paramètres d'invocation des outils MCP ou les données de journaux d'audit, ne quitte le périmètre de l'entreprise pour atteindre l'infrastructure de TrueFoundry. Il ne s'agit pas d'une option de déploiement. C'est l'architecture par défaut pour les déploiements d'entreprise, et non un niveau premium.

• Déploiement isolé par VPC par défaut : TrueFoundry se déploie dans le propre compte cloud du client en utilisant l'infrastructure-as-code. La passerelle IA, la passerelle MCP, l'interface utilisateur de gestion et le stockage des journaux d'audit s'exécutent tous au sein du périmètre du client. Quatre options de déploiement couvrent tout le spectre, du SaaS entièrement géré sans coût d'infrastructure au Control Plane complet plus le Gateway Plane à l'intérieur du compte client, pour un coût d'infrastructure d'environ 800 à 1 000 $ par mois. Pour les charges de travail réglementées, les options 3 et 4 garantissent qu'aucune donnée ne transite par l'infrastructure de TrueFoundry. L'accès au support de TrueFoundry utilise des procédures d'accès d'urgence documentées avec l'approbation du client.

• Journaux d'audit structurés conformes à HIPAA, SOC2 et GDPR : Chaque appel LLM génère une entrée de journal d'audit JSON structurée via l'en-tête X-TFY-LOGGING-CONFIG. Au niveau de la passerelle, REQUEST_LOGGING_MODE: ALWAYS sur les déploiements auto-hébergés garantit que chaque requête est capturée sans dérive de configuration. Les champs de journal couvrent l'identité de l'utilisateur, le modèle, le nombre de jetons, la latence, le coût, la décision de politique et la sortie. Les journaux sont exportés via OpenTelemetry vers Grafana, Datadog, Splunk ou tout SIEM compatible OTLP. Sur les déploiements auto-hébergés, les données de journal sont écrites dans le propre stockage AWS S3, GCS ou Azure Blob du client au format Parquet avec une rétention configurable. S3 Object Lock en mode WORM satisfait l'exigence de rétention infalsifiable de HIPAA pour un minimum de six ans.

• Intégration SSO avec les systèmes d'identité cliniques et d'entreprise : TrueFoundry s'intègre à Okta, Azure Active Directory, PingFederate et tout fournisseur d'identité compatible SAML 2.0 ou JWKS. Le provisionnement des accès suit le processus standard de gestion du cycle de vie des identités de l'organisation. Les développeurs rejoignant une équipe obtiennent l'accès à la passerelle IA via le même flux de travail IdP qui provisionne leurs autres systèmes. Les développeurs quittant l'entreprise voient leur accès révoqué via le même flux de travail de départ. Il n'y a pas de système d'accréditation de passerelle IA distinct à maintenir ou à auditer indépendamment.

• Catalogue de modèles approuvés pour les charges de travail réglementées : Les administrateurs de plateforme définissent quels modèles sont approuvés pour quels types de données et cas d'utilisation. Une équipe clinique ne peut pas acheminer des invites contenant des PHI (informations de santé protégées) vers un modèle non éligible BAA, car la passerelle applique des politiques de modèle-à-cas d'utilisation au niveau de la couche de routage avant que la requête ne quitte le périmètre. Cette application des politiques se produit au niveau de la passerelle IA, et non au niveau de la couche d'application, ce qui signifie qu'elle s'applique de manière cohérente, quelle que soit l'application ou l'agent qui initie la requête.

• Déploiements de production vérifiés dans les secteurs réglementés : Medtronic, avec ses portefeuilles de dispositifs médicaux réglementés par la FDA, utilise TrueFoundry en production. Siemens Healthineers l'utilise dans ses opérations mondiales de technologie médicale avec une exposition réglementaire multi-juridictionnelle. Innovaccer traite environ 17 millions de requêtes d'inférence IA cliniques par mois au sein d'AWS GovCloud sous HIPAA, sans qu'aucune donnée ne quitte les limites de leur cloud, en utilisant la passerelle de TrueFoundry avec OpenTelemetry alimentant les tableaux de bord Grafana. Aviva utilise TrueFoundry pour ses opérations d'assurance au Royaume-Uni sous GDPR. ResMed l'utilise pour ses applications de santé numérique. Il s'agit de déploiements de production à l'échelle de l'entreprise avec une approbation de conformité réglementaire, et non de projets pilotes.