Tech-Stack
KODAX School steuert zentral, welche KI-Modelle verwendet werden dürfen, wo deren Inferenz stattfindet und welche Informationen das eigene System verlassen. Europäische beziehungsweise schweizerische Inferenz ist dabei durch die Plattform-Policy vorgegeben.
Sieben Ebenen, von der Lernoberfläche bis zum Betrieb — aufgebaut aus erprobten KODAX-Bausteinen, die eine Schule, ein Verbund oder ein Kanton nutzen kann.
EU-/CH-Inferenz durch Policy
Nur freigegebene Endpoints in der Schweiz oder Europa
Providerunabhängiges AI Gateway
Modelle austauschbar ohne Umbau
Keine globalen Fallbacks
Kein freigegebener Endpoint — kontrollierter Abbruch
KODAX AI Governance Architecture
Zwischen Nutzenden und KI-Modellen liegt eine eigene Kontrollschicht. Sie entscheidet zentral, welches Modell über welchen freigegebenen europäischen oder schweizerischen Endpoint angesprochen werden darf.
Grundregel
Nicht «EU preferred», sondern «EU/CH enforced».
Ist kein freigegebener EU-/CH-Endpoint verfügbar, wird nie automatisch auf einen globalen Endpoint ausgewichen. Die Anfrage schlägt kontrolliert fehl.
Beispielhafte freigegebene Deployments
✓ Approved EU / CH Inference
Freigaben gelten jeweils für konkrete Provider-, Modell- und Deployment-Konfigurationen.
Ausgeschlossen
Der Weg eines Prompts
Für Lernende fühlt es sich an wie ein modernes KI-Werkzeug. Dahinter liegt ein klar definierter Pfad, an dem Regeln, Filter und Isolation greifen.
Schritt 1
«Erstelle mir eine Website für mein Schulprojekt.»
Schritt 2
KODAX prüft, wer fragt und welche Regeln gelten.
Schritt 3
Je nach Schulpolicy werden personenbezogene Daten erkannt, entfernt oder pseudonymisiert und ungeeignete Inhalte blockiert.
Schritt 4
Es wird ausschliesslich ein freigegebenes Deployment gewählt.
Schritt 5
Zum Beispiel OpenAI oder Claude über europäische Endpunkte, Mistral oder das Schweizer Open-Source-Modell Apertus — jeweils über ein freigegebenes EU-/CH-Deployment.
Schritt 6
Der generierte Code läuft zuerst in einer isolierten Entwicklungsumgebung.
Schritt 7
Technisch relevante Metadaten wie Modell, Provider, Zeitpunkt, Tokens, Kosten und Policy-Entscheide können protokolliert werden. Inhaltsdaten werden nur gespeichert, wenn dies für den definierten Betriebs- oder Sicherheitszweck erforderlich und zulässig ist.
Die sieben Ebenen
Von oben nach unten gelesen: was die Lernenden sehen, wie die Schule steuert und wo KODAX die Regeln technisch durchsetzt.
01
Erlebnisebene
Die Oberfläche, die im Studio sichtbar ist: Prompt, Vorschau, Code, Versionen. Schülerinnen und Schüler wählen kein Modell und keinen Anbieter aus — sie arbeiten mit logischen KODAX-Modellen, hinter denen die Schule die Regeln festlegt.
KODAX School · Frontend
Technik
02
Identitätsebene
Anmeldung über die Konten, die Schulen bereits nutzen. Jede KI-Anfrage ist damit einer Rolle, Klasse und Schule zugeordnet — die Grundlage, damit Richtlinien überhaupt durchgesetzt werden können.
KODAX Identity Layer
Technik
03
Policy-Ebene
Die KODAX School Policy Engine: Jede Schule definiert zentrale KI-Regeln, die automatisch für Lernende, Lehrpersonen, Klassen und Projekte durchgesetzt werden. Regeln werden von oben nach unten vererbt und können pro Ebene verschärft werden.
KODAX School Policy Engine
Technik
04
KI-Ebene
Alle KI-Anfragen der Plattform laufen über einen zentral von KODAX kontrollierten Gateway. Er abstrahiert die Modellanbieter und erzwingt verbindliche Regeln für Region, Datenschutz, Nutzung und Kosten. Anwendungen und Nutzende verbinden sich nicht direkt oder unkontrolliert mit öffentlichen LLM-Endpunkten. Der Gateway wird durch KODAX betrieben oder innerhalb einer kontrollierten Kunden-/Schulumgebung bereitgestellt.
KODAX Secure AI Gateway
Technik
05
Ausführungsebene
Generierter Code wird nicht direkt produktiv ausgeführt. Jede App läuft getrennt vom Schulnetz und von anderen Projekten, mit nur den Rechten, die sie tatsächlich benötigt. Der Internetzugriff ist in drei Stufen regelbar.
KODAX Secure Cloud
Technik
06
Datenebene
Datenbank, Dateien, Projekte und Protokolle liegen in Schweizer oder europäischen Rechenzentren — verschlüsselt und gesichert. Geloggt wird, was für Betrieb und Nachvollziehbarkeit nötig ist, nicht mehr.
KODAX Secure Cloud · Compliance
Technik
07
Betrieb & Governance
KODAX betreibt und aktualisiert die Umgebung, wertet Nutzung und Kosten aus und bildet Lehrpersonen aus. Protokolliert werden technisch relevante Ereignisse; personenbezogene Inhalte nur, wenn dies für den definierten Zweck erforderlich und zulässig ist.
KODAX AI Transformation · Academy
Technik
Policy Engine
Was der Kanton oder die Schule festlegt, gilt automatisch darunter. Eine Klasse oder Lehrperson kann Regeln verschärfen, aber nicht aufweichen.
Technisch lassen sich diese Regeln zum Beispiel auf Virtual Keys, Budgets, Rate Limits und Routing-Regeln des Gateways abbilden.
KODAX Secure AI Gateway
Eine einheitliche Schnittstelle zu OpenAI, Anthropic, Mistral, Google sowie Open-Source-Modellen wie dem Schweizer Apertus. Ein Wechsel erfordert keinen grundlegenden Umbau der Anwendung.
Nicht jedes Modell oder Deployment eines Providers ist automatisch zugelassen. Eine Freigabe erfolgt nur für konkret geprüfte Konfigurationen mit geklärter Inferenzregion, Retention, Trainingsausschluss, AVV/DPA, Sicherheitsanforderungen und technischer Stabilität.
Logische Modelle wie KODAX Coding, KODAX General, KODAX Fast und KODAX Private werden auf passende, freigegebene Deployments abgebildet.
Primäres freigegebenes Deployment → sekundäres freigegebenes Deployment → Anfrage abgelehnt. Niemals EU → USA → Global.
Privacy Layer
Anfragen können vor der Weiterleitung analysiert werden. Je nach Policy werden Namen, Adressen, Telefonnummern, E-Mail-Adressen, Geburtsdaten oder Schülernummern erkannt, entfernt oder pseudonymisiert.
Original
«Ich bin Anna Müller aus Zürich und brauche Hilfe bei meinem Projekt.»
Das Modell erhält
«Ich bin [PERSON] aus [LOCATION] und brauche Hilfe bei meinem Projekt.»
Die genaue Konfiguration hängt vom schulischen Einsatzfall und den definierten Policies ab. Eine automatische Erkennung erfasst nicht in jedem Fall jede Information.
Residency
Europäische oder schweizerische Datenspeicherung allein sagt noch nicht aus, wo eine KI-Anfrage tatsächlich verarbeitet wird. Deshalb kontrolliert KODAX zusätzlich den konkreten Inferenz-Endpunkt.
Data Residency
Gespeichert in Schweizer oder europäischen Rechenzentren.
Inference Residency
Nur über freigegebene Endpoints in der Schweiz oder Europa.
Privacy & Security by Default
Die Plattform setzt die Sicherheitsregeln zentral und technisch durch.
Standardmässig durch die Plattform-Policy vorgegeben.
Nicht freigegebene Endpunkte werden nicht automatisch verwendet.
Nur freigegebene Provider-, Vertrags- und Deployment-Varianten dürfen verwendet werden.
Es werden nur Daten gespeichert, die für den jeweiligen Betriebs-, Sicherheits- oder Nachweiszweck erforderlich sind.
Regeln werden durch Schule, Betreiber oder Kanton definiert und technisch durchgesetzt.
Modelle und Anbieter können ersetzt werden, ohne die Anwendungsarchitektur grundlegend zu verändern.
Kostenkontrolle
Die KI-Nutzung lässt sich pro Schule, Klasse, Nutzer, Projekt und Modell limitieren und auswerten: Budgets, Tokens, Kosten pro Modell und Klasse, Restbudget und Rate Limits.
Kein Lock-in
Dank der abstrahierten KI-Schicht können Modelle oder Provider gewechselt werden, wenn sich Qualität, Kosten, Datenschutzanforderungen, Verfügbarkeit, regulatorische Vorgaben oder die Technologie verändern.
Mögliche Gateway-Funktionen: Provider-Abstraktion, Routing, kontrollierter Fallback, Load Balancing, Virtual Keys, Budgets, Spend Tracking, Rate Limits, Request Logging, Guardrails, OpenAI-kompatible API.
Die Gateway-Technologie ist eine austauschbare Infrastrukturkomponente — nicht das KODAX-Produkt. Die konkrete Zusammensetzung kann sich weiterentwickeln; entscheidend sind die verbindlichen KODAX Policies.
Betrieb
Die Architektur bleibt identisch; nur der Ort der Ausführung ändert sich. Die Wahl hängt von Datenlage, Budget und vorhandener Infrastruktur ab.
Betriebsmodell A
KODAX betreibt die Umgebung in Schweizer Rechenzentren. Die Schule startet ohne eigene Infrastruktur.
Für Schulen ohne Serverbetrieb
Betriebsmodell B
Gateway und gegebenenfalls Modelle laufen lokal oder in der Infrastruktur der Schule. Bei vollständig lokalem Betrieb verlassen Prompts und Projektdaten das Schulnetz nicht.
Für maximale Datenhoheit
Betriebsmodell C
Lokale und freigegebene EU-/CH-Inferenz kombiniert: sensible Klassen lokal, rechenintensive Aufgaben über freigegebene EU-/CH-Endpunkte — mit denselben Policies auf beiden Seiten.
Für Verbünde und Kantone