request = {
"agent": "support-summary-agent",
"task": "summarize",
"dataset": "customer_support_logs",
"model": "external_llm_api",
"delegated_by": "user_4821"
}
policy = evaluate_policy(request)
if policy.allowed:
route_to_execution(policy.execution_environment)
else:
raise AuthorizationError(policy.reason)
Le moteur de stratégie évalue ici la classification des ensembles de données, le statut d’approbation du modèle, les règles de traitement géographique et la chaîne de délégation qui a initié la demande. Cela peut impliquer de rediriger la tâche vers un cluster d’inférence interne au lieu d’un point de terminaison d’API publique, ou de bloquer la requête s’il n’existe aucun environnement d’exécution conforme. Du point de vue de l’agent, la tâche s’exécute toujours. La couche d’orchestration garantit qu’elle s’exécute dans un environnement qui satisfait à la politique de l’entreprise.
Pourquoi les ontologies sont une infrastructure porteuse
Pour que la couche d’orchestration puisse prendre de bonnes décisions, elle doit faire plus que simplement étiqueter les données. Il doit comprendre les relations entre les entités impliquées dans une demande et raisonner sur ces relations pour déterminer ce qui est autorisé.
Prenons à nouveau l’exemple de transcription du support client. Les métadonnées vous indiquent que l’ensemble de données contient des PII (informations personnellement identifiables). Une ontologie permet au système de raisonner à travers une chaîne connectée : la tâche opère sur un ensemble de données contenant des données personnelles ; ces données sont régies par le RGPD ; la politique de l’organisation exige le traitement dans un environnement approuvé par l’UE ; le modèle sélectionné s’étend en dehors de cette limite. À partir de ces quatre faits connectés, la couche d’orchestration peut déduire que la demande doit être redirigée ou bloquée. Le système a raisonné sur les relations plutôt que de les comparer à une règle codée en dur liée à un ensemble de données spécifique.
