Künstliche Intelligenz in Webprojekten war bisher fast immer eine Frage der Anbindung: Ein Dienst wird per Schnittstelle aufgerufen, die Anfrage verlässt den Rechner, die Antwort kommt zurück. Genau dieses Muster gerät in Bewegung. Lokale Sprachmodelle – also Modelle, die im Browser der Nutzerinnen und Nutzer selbst ausgeführt werden – rücken die Verarbeitung dorthin, wo die Daten ohnehin entstehen: ins Frontend.

Der Browser wird damit zu einer Art Laufzeitumgebung für KI-Funktionen. Kontextnahe Unterstützung, also Hilfe direkt an der Stelle, an der jemand gerade arbeitet, entsteht ohne Umweg über einen externen Dienst. Das funktioniert grundsätzlich auch offline, und es fallen keine Inferenzkosten an – also keine Gebühren pro Modellanfrage.

Warum das für Entscheiderinnen und Entscheider relevant ist

Drei Punkte machen den Unterschied zum bisherigen Vorgehen aus, und alle drei betreffen weniger die Technik als die Rahmenbedingungen eines Projekts.

  • Datenschutz: Inhalte, die im Browser verarbeitet werden, müssen den Rechner nicht verlassen. Für Formulare, interne Werkzeuge oder Redaktionsoberflächen mit sensiblen Inhalten verändert das die Ausgangslage einer Datenschutzfolgenabschätzung deutlich.
  • Kostenstruktur: Ohne Anfragen an einen externen Dienst entfallen die laufenden, mit der Nutzung wachsenden Kosten. Der Aufwand verlagert sich in die Entwicklung und in die Auslieferung der Modelle.
  • Verfügbarkeit: Eine Funktion, die lokal rechnet, ist nicht von der Erreichbarkeit eines Anbieters abhängig. Das reduziert eine Abhängigkeit, die in vielen KI-Projekten der vergangenen Jahre stillschweigend akzeptiert wurde.

Was lokale Modelle sinnvoll leisten können

Die realistische Erwartung ist nicht, ein großes Cloud-Modell eins zu eins zu ersetzen. Modelle, die auf Endgeräten laufen, sind kleiner, und ihre Stärke liegt in klar umrissenen Aufgaben nahe am Kontext der Oberfläche. Typische Kandidaten in Webprojekten sind:

  • Formulierungshilfen und Umformulierungen in Redaktions- und Eingabemasken
  • Zusammenfassungen oder Gliederungsvorschläge für Texte, die gerade bearbeitet werden
  • Klassifizierung und Verschlagwortung von Inhalten als Vorschlag für die Redaktion
  • Suchfunktionen, die eine Eingabe inhaltlich statt nur wörtlich interpretieren
  • Assistenzfunktionen in Web-Apps, die Nutzereingaben strukturieren, bevor sie gespeichert werden

Gemeinsam ist diesen Fällen, dass sie kurz sind, im Zweifel auch ohne KI funktionieren und dass eine Fehlleistung des Modells keinen Schaden anrichtet, weil ein Mensch den Vorschlag ohnehin prüft.

Die Grenzen offen benennen

Ein Modell, das im Browser läuft, muss dorthin gelangen. Das bedeutet Datenmengen, die geladen und sinnvollerweise zwischengespeichert werden müssen, und es bedeutet eine Abhängigkeit von der Rechenleistung des Endgeräts. Ein aktueller Arbeitsplatzrechner verhält sich anders als ein älteres Tablet. Wer lokale KI-Funktionen einplant, plant deshalb zwangsläufig auch einen Fall mit ein, in dem die Funktion nicht zur Verfügung steht.

Daraus folgt eine Gestaltungsregel, die aus der Webentwicklung ohnehin bekannt ist: KI-Funktionen im Frontend gehören als Ergänzung konzipiert, nicht als Fundament. Die Seite, das Formular, der Redaktionsprozess müssen ohne das Modell vollständig bedienbar bleiben. Alles andere führt zu einer Anwendung, deren Nutzbarkeit von der Hardware der Besucherinnen und Besucher abhängt.

Konsequenzen für CMS- und TYPO3-Projekte

Für Content-Management-Systeme ist die Entwicklung besonders interessant, weil dort zwei Welten aufeinandertreffen. Im Backend arbeiten Redakteurinnen und Redakteure mit Inhalten, die häufig noch unveröffentlicht und mitunter vertraulich sind. Gerade hier war die Frage, welche Daten ein externer Dienst sehen darf, oft der Grund, warum KI-Unterstützung nicht über den Prototypen hinauskam.

Eine lokale Ausführung verschiebt diese Diskussion. Statt einer Freigabeentscheidung über Datenabflüsse geht es um technische Fragen: Wie werden Modelle ausgeliefert und versioniert? Wie sind die Anforderungen an die Arbeitsplatzrechner der Redaktion? Wo genau in der Oberfläche entsteht echter Nutzen, und wo wäre eine Vorschlagsfunktion nur ein zusätzlicher Klick?

Im Frontend, also auf der ausgelieferten Website, ist der Maßstab strenger. Ladezeit und Barrierefreiheit haben Vorrang, und der Nutzen einer KI-Funktion muss den zusätzlichen Ressourcenbedarf rechtfertigen. Bei einer internen Web-App mit bekannter Nutzergruppe fällt diese Abwägung anders aus als bei einer öffentlichen Kampagnenseite.

Wie ein pragmatischer Einstieg aussieht

  1. Einen konkreten Arbeitsschritt auswählen, der heute Zeit kostet und bei dem ein Vorschlag genügt – nicht eine allgemeine Assistenzfunktion.
  2. Prüfen, welche Daten dabei verarbeitet werden. Je sensibler, desto stärker spricht es für lokale Ausführung.
  3. Die Zielgeräte klären. Interne Nutzung mit bekannter Ausstattung ist der leichtere Anfang.
  4. Den Ablauf ohne KI vollständig definieren, bevor die Funktion ergänzt wird.
  5. Klein ausrollen, messen, ob der Schritt tatsächlich schneller wird, und erst dann ausweiten.

Für Web- und Softwareprojekte bedeutet die Verlagerung ins Frontend vor allem eine neue Option in der Architektur: KI-Funktionen lassen sich künftig auch dort umsetzen, wo eine Übertragung von Daten an externe Dienste nicht in Frage kommt. Das macht Projekte nicht automatisch einfacher, aber es entkoppelt sie von laufenden Nutzungskosten und von der Verfügbarkeit einzelner Anbieter. Sinnvoll ist der Weg dort, wo die Aufgabe klar umrissen ist und das Ergebnis ohnehin von einem Menschen geprüft wird.

Quellen