La plupart des universités n’ont pas décidé d’adopter l’IA ; elle est arrivée. Les enseignants rédigent avec, les étudiants programment avec, les groupes de recherche raccordent des agents à des comptes de laboratoire partagés et à des données départementales, et la DSI centrale l’apprend après coup. Les travaux d’EDUCAUSE (2025) décrivent l’écart sans détour : l’usage de l’IA est désormais répandu parmi le personnel enseignant et administratif de l’enseignement supérieur, tandis que la gouvernance formelle de l’IA et la couverture par une charte d’usage acceptable accusent un retard. Une charte que personne ne peut voir, et que rien n’applique, n’est pas un contrôle — c’est un PDF.
Cet écart n’est pas propre au campus, mais le campus l’accentue. Les comptes sont partagés par conception. L’intégrité de la recherche repose sur le fait de savoir ce qui a touché quoi. Et les personnes que vous voulez le plus habiliter — les chercheurs — sont précisément celles qu’un contrôle trop rigide pousserait vers des outils clandestins.
Le problème, concrètement
Trois choses tendent à être vraies en même temps sur un réseau de campus :
- La charte d’usage acceptable existe mais n’est pas appliquée. Il y a une règle sur les systèmes que l’IA peut toucher et ce qu’elle peut faire. Rien ne transforme cette règle en décision au moment où un agent tente d’agir.
- Les comptes partagés effacent l’attribution. Les agents d’un laboratoire s’exécutent sous un seul compte de service derrière un pool de connexions. L’audit natif attribue l’accès à cet identifiant — et non à la personne ou à l’agent qui l’a réellement effectué.
- Les chercheurs ont besoin d’aller vite. Ils veulent tester un nouvel agent contre des données quasi réelles dès aujourd’hui, et non remplir un ticket et attendre. Si la gouvernance est une barrière qu’ils doivent supplier de franchir, ils la contournent.
C’est la même configuration que rencontre le marché au sens large. Parmi les organisations ayant subi une violation liée à l’IA, environ 97 % manquaient de contrôles d’accès à l’IA appropriés (IBM Cost of a Data Breach 2025, Ponemon), et Gartner s’attend à ce que plus de 40 % des projets d’IA agentique soient abandonnés d’ici fin 2027 — la dette de gouvernance en est une cause majeure. La version campus est moins coûteuse à corriger tôt, tant que les agents sont peu nombreux et le rayon d’impact réduit.
Comment Olivares AI vous aide
Olivares AI est une plateforme ouverte et auto-hébergeable qui découvre les agents d’IA sur votre infrastructure, cartographie ce que chacun peut lire et écrire, et vous permet de gouverner et d’auditer ces accès. Elle fonctionne en lecture d’abord : elle observe et enregistre hors bande avant de bloquer quoi que ce soit, et elle est fermée par défaut (deny-closed) là où elle bloque. Pour un campus, cela signifie que vous pouvez commencer par voir la vérité — et seulement ensuite décider de ce que vous appliquerez.
Appliquer la charte d’usage acceptable, fermée par défaut
La couche de gouvernance transforme la charte d’usage acceptable en une politique qui produit une décision. Son moteur ABAC s’exécute après le contrôle d’accès basé sur les rôles et ne peut que restreindre davantage : il refuse lorsqu’une règle de refus correspond, sinon la décision existante demeure, et une politique mal formée échoue de manière fermée plutôt qu’ouverte. Ainsi, une règle « aucun agent d’IA ne peut écrire dans le système de notes » ou « les agents de bac à sable ne peuvent pas atteindre le SIS » devient un refus appliqué, et non une note de service.
Soyez précis sur ce que la v1 prend en charge. Les règles de refus s’appuient aujourd’hui sur le principal, la permission/le verbe et la ressource — les attributs qui parviennent réellement à l’évaluateur. Les règles qui s’embranchent sur la sensibilité de la ressource (par exemple « tout ce qui est étiqueté FERPA ») nécessitent une couture d’attribut de ressource qui est une suite documentée à venir, pas encore livrée. Là où vous avez besoin d’une intervention humaine dans la boucle, la plateforme enregistre une demande d’approbation ainsi qu’une piste de décision en ajout seul (append-only), de sorte que la question « qui a approuvé que cet agent atteigne ce jeu de données » trouve réponse plus tard.
Consultez /docs/concepts/governance pour le modèle lecture d’abord et fermé par défaut, et pour savoir où l’actionnement est actif (live) par rapport à sur demande (on-demand).
Attribuer qui a fait quoi sur les comptes partagés
C’est la capacité porteuse pour le campus. La carte des accès enregistre, avec des niveaux de confiance honnêtes, quel agent lit ou écrit quelle ressource et si cet accès est autorisé ou simplement observé. La gouvernance des identités (/product/identity) lie un agent à l’identité canonique que présente son identifiant, afin qu’un accès puisse être attribué de manière ferme.
La règle d’honnêteté compte ici plus que partout ailleurs : l’attribution n’est ferme que lorsqu’une identité par agent ou par session est propagée dans l’accès. Quand plusieurs agents s’exécutent sous un seul compte de laboratoire partagé derrière un pool, l’attribution se réduit à cette unique identité — et le produit le dit, en faisant remonter la liaison partagée comme un constat de gouvernance plutôt qu’en devinant une personne. Une identité liée à plus d’un agent est signalée, et non dissimulée. Le remède est opérationnel : propagez une identité par agent (par exemple dans le nom d’application de la connexion) et l’attribution s’affine. Nous n’afficherons pas un nom que les signaux ne peuvent pas étayer.
Des bacs à sable encadrés pour les chercheurs
Les chercheurs bénéficient d’une exécution isolée et éphémère de scénarios d’agents contre des ressources simulées (mocked) — et non la production. L’exécuteur de bac à sable par défaut est isolé par construction : il ne détient aucun accès à votre magasin de données, à votre réseau ou à vos secrets, et une étape qui demande une ressource que le scénario n’a pas simulée renvoie un marqueur déterministe d’absence de simulation (mock-miss) plutôt que d’atteindre quoi que ce soit de réel. Les exécutions sont éphémères ; chacune enregistre l’exécuteur réel et s’il était isolé, de sorte qu’un back-end dégradé est visible, jamais caché. Un isolement plus fort au niveau du système d’exploitation (un conteneur durci ou une microVM) est un back-end enfichable que l’opérateur en auto-hébergement raccorde.
Cela donne à un laboratoire un endroit sûr pour tester un nouvel agent avant qu’il ne touche jamais des données réelles — c’est ainsi que vous maintenez des chercheurs en mouvement rapide à l’intérieur de la gouvernance au lieu de la contourner. Pour les agents qui gouvernent effectivement des systèmes réels, une batterie défensive d’équipe rouge (red-team) sous réserve de consentement (injection de prompt, jailbreak, exfiltration) peut sonder la résistance d’un agent, évaluée selon l’OWASP Top 10 for Agentic Applications. Elle ne s’exécute que contre les agents que vous possédez et avez autorisés — c’est une suite de tests, pas un outil offensif.
Des preuves pour l’intégrité de la recherche et les audits
Les évaluations notent les sorties candidates d’un agent par rapport à des suites de référence (golden suites) versionnées — utile quand un groupe de recherche a besoin d’un relevé reproductible attestant qu’un agent a satisfait un critère, d’une exécution à l’autre. Le juge est honnête : si aucun back-end de notation n’est raccordé, une exécution est enregistrée comme ignorée (skipped), jamais comme un succès silencieux, et les sorties brutes ne sont jamais conservées — seulement un hachage à sens unique et une étiquette expurgée. Consultez /product/evals.
Pour l’établissement, la couche de conformité (/product/compliance) agrège ce que la plateforme observe et audite déjà au sein d’un dossier de preuves scellé et en ajout seul (append-only), ancré à un registre chaîné par hachage. Un contrôle assorti de preuves justificatives est marqué satisfait ; un contrôle sans preuve est marqué comme une lacune (gap), jamais comme un faux succès. Il s’agit d’une correspondance technique avec des cadres tels que l’EU AI Act et l’ISO/IEC 42001 — ce n’est pas un conseil juridique et le produit ne prétend pas à une certification.
Ce que c’est — et ce que ce n’est pas
- C’est une couche ouverte et auto-hébergeable de gouvernance et d’observation pour l’IA sur votre infrastructure. Le plan de contrôle peut s’exécuter hors ligne / en isolement complet (air-gapped) sur votre propre matériel, de sorte que les données d’attribution et de politique ne quittent jamais le campus.
- C’est en lecture d’abord et fermé par défaut. Il observe et gouverne largement ; il n’actionne pas largement. Là où il peut entreprendre une action, cette surface est active (live), sur demande (on-demand) ou une couture déclarée — et le catalogue des modules indique laquelle.
- C’est antérieur à la 1.0. Le catalogue compte 23 modules dont une vingtaine sont raccordés ; certaines des capacités ci-dessus sont présentes, certaines sont sur demande, certaines sont des suites documentées à venir. Nous étiquetons lesquelles.
- Il n’exécute pas vos modèles, et ce n’est pas de l’inférence en isolement complet. L’isolement complet (air gap) concerne le plan de contrôle. Seuls les modèles auto-hébergés (vLLM, Ollama) s’exécutent hors ligne ; les modèles hébergés comme Claude, non.
- Ce n’est pas une certification. Aucune certification SOC 2 / ISO / EU AI Act — la correspondance de conformité est « conçue en vue de » ces cadres et produit des preuves, pas un sceau. Consultez /security pour la posture et /docs/concepts/governance pour le modèle de gouvernance.
L’adoption est répandue ; c’est la supervision qui est en retard (EDUCAUSE, 2025). Le point de départ honnête est de voir ce que votre IA touche déjà, de décider de ce qu’elle peut faire, et de le prouver — dans cet ordre.