Ob im Büro, in der Redaktion oder im Kundenservice – Sprachmodelle wie ChatGPT, Llama oder Mistral sind längst Teil des Arbeitsalltags. Sie fassen Texte zusammen, übersetzen Inhalte oder erstellen Transkripte in Sekunden. Das spart Zeit. Doch die neuen Werkzeuge werfen auch Fragen auf: Wie zuverlässig sind ihre Ergebnisse? Welches Modell eignet sich für welchen Zweck? Und was gilt es rechtlich zu beachten?

Wer die Grenzen und typischen Schwächen der Systeme nicht kennt, läuft Gefahr, weckt schnell überzogene Erwartungen – mit problematischen Folgen: frustrierte Mitarbeiter, höherer Aufwand und im schlimmsten Fall sogar hohe Kosten. Die vermeintliche Wunderwaffe KI wird dann schnell zum Problem.

Systematischer Einstieg

Das Webinar bietet eine kompakte, praxisnahe Einführung in den produktiven Einsatz von Sprach-KI. Die c’t-Redakteure Hartmut Gieselmann und Jo Bager erläutern, wie große Sprachmodelle funktionieren, welche Aufgaben sie übernehmen können und wo ihre Grenzen liegen. Dabei gehen sie auch auf alternative Modelle zu ChatGPT ein, etwa Llama oder Mistral. Die Referenten erklären nicht nur die technischen Grundlagen, sondern beleuchten auch den Ressourcenbedarf sowie die Kosten solcher Systeme.

Anhand konkreter Szenarien zeigen sie, wie sich Sprach-KI in verschiedenen Branchen sinnvoll einsetzen lässt.

Rechtliche Aspekte im Überblick

c’t-Redakteur Holger Bleich erläutert zudem rechtliche Rahmenbedingungen, die beim Einsatz von Sprach-KI beachtet werden müssen. Er informiert über datenschutzrechtliche Fragen, urheberrechtliche Fallstricke und die Anforderungen aus der EU-KI-Verordnung, die seit August 2025 unter anderem mehr Transparenz beim Einsatz solcher Systeme vorschreibt.

Teilnahme und Termin

Das Webinar richtet sich an alle, die KI-Anwendungen bereits in ihren Arbeitsprozessen nutzen oder dies planen. Auch wer Sprachmodelle im Alltag jenseits der Arbeitswelt nutzt und bereits erste Erfahrungen mitbringt, ist herzlich willkommen. Ziel ist es, ein realistisches Verständnis der Möglichkeiten und Grenzen aktueller Sprachmodelle zu vermitteln und Sicherheit im produktiven Umgang mit den Systemen zu schaffen.

Das Webinar findet am 6. November 2025 von 10 bis 13 Uhr statt und kostet 69,00 Euro. Weitere Informationen und die Anmeldung finden Sie auf der Seite zum c’t-Webinar von heise academy.

(abr)

Erik Wilde hat jahrelange Erfahrung im API-Bereich. Als Botschafter bei der OpenAPI-Initiative setzt er sich für den Einsatz offener Standards und Best Practices in API-Design und -Management ein. Auf YouTube betreibt er den Channel Getting APIs to Work, der sich an IT-Experten, Entwicklerinnen und Produktmanager richtet. Außerdem hat Wilde zahlreiche Artikel und Bücher geschrieben, und er spricht regelmäßig auf Fachkonferenzen.

iX: Schnittstellen sind ein absolutes Grundkonzept der Softwarearchitektur; man entwirft, implementiert und überarbeitet sie ständig für die Anwendungsprogrammierung. Wann beginnt man, eine Schnittstelle als API zu bezeichnen? Die Semantik dieses Wortes geht über die reine Abkürzung hinaus.

Erik Wilde: Man bezeichnet eine Schnittstelle als API, sobald sie über ihren unmittelbaren Implementierungskontext hinaus von anderen genutzt werden soll. Eine Schnittstelle ist nur eine technische Grenze, eine API hingegen ein veröffentlichter Vertrag. Das bedeutet, dass sie absichtlich offengelegt, dokumentiert und stabil genug ist, damit andere – innerhalb oder außerhalb des Entwicklerteams oder Systems – sich darauf verlassen können. Es ist vor allem der Aspekt der Absicht und des breiteren Publikums, der eine API auszeichnet.

iX: Sind die Ansätze, die eine API für Menschen nützlich und zugänglich machen, nicht dieselben wie diejenigen, die sie für KI, also LLM-basierte Automatisierung, zugänglich machen?

Wilde: Sowohl Menschen als auch Maschinen benötigen zugängliche APIs, jedoch auf unterschiedliche Weise. Für Menschen funktioniert die Dokumentation am besten, wenn APIs einheitliche Muster aufweisen, da das nicht nur das Verständnis erleichtert, sondern auch die Wiederverwendung von Tools und Verfahren für verschiedene APIs ermöglicht. Menschen können auch einen breiteren Kontext heranziehen, ohne verwirrt zu werden. Maschinen hingegen benötigen eine klare, in sich geschlossene Beschreibung jeder API. Selbst wenn die Kontextfenster größer werden, ist mehr Kontext nicht immer hilfreich – KI hat oft Schwierigkeiten, größere Kontexte effektiv zu nutzen.

Menschen schätzen APIs, die offen, wiederverwendbar und flexibel anpassbar sind, während Maschinen mehr von einer geführten Abstraktionsebene profitieren, die den Schwerpunkt darauf legt, was erreicht werden kann und wie dies zu tun ist, anstatt jede mögliche Operation offenzulegen.

iX: Sie haben sich in der Vergangenheit in Ihrem YouTube-Channel „Getting APIs to Work“ mit dem ökologischen Fußabdruck von APIs befasst. Wenn man über Softwareeffizienz und CO₂-Bewusstsein nachdenkt, passt das dann gut zu dem, was derzeit als Agentic AI beworben wird?

Wilde: Der ökologische Fußabdruck von Agentic AI ist erheblich, da die explorative Nutzung durch Agenten oft zu mehr Orchestrierung, mehr Rechenzyklen und einem höheren Energieverbrauch führt. Das scheint im Widerspruch zu den Bestrebungen nach Effizienz und CO₂-Bewusstsein bei Software und APIs zu stehen.

Der Weg nach vorne besteht darin, sie als komplementär zu betrachten: Agenten können kreative Lösungen erforschen und neue Vorgehensweisen aufdecken, aber sobald ein vielversprechender Ansatz gefunden ist, sollte er in einen deterministischen, wiederholbaren Workflow kodifiziert werden, der energieeffizient, skalierbar und überprüfbar ist. Das bringt die Vorteile der Kreativität der KI mit der Notwendigkeit eines nachhaltigen und konformen Betriebs in Einklang, wobei so viel KI wie nötig, aber so wenig wie möglich eingesetzt wird.

Durch das Entwickeln von Architekturen, die einen reibungslosen und bewussten Übergang vom Experimentieren zur effizienten Ausführung ermöglichen, können wir sowohl die Unsicherheit hinsichtlich der Unvorhersehbarkeit der KI als auch die Notwendigkeit angehen, ihren erheblichen Energieverbrauch zu kontrollieren.

iX: In welcher Beziehung steht MCP zu OpenAPI? Verfolgen beide nicht dasselbe Ziel: die Standardisierung der Beschreibung von APIs und deren einfache Zugänglichkeit? Oder ähnelt es eher JSON:API, also der Standardisierung der APIs selbst?

Wilde: Bei MCP, OpenAPI und JSON:API geht es darum, Funktionen verfügbar zu machen, aber sie richten sich an unterschiedliche Nutzer. MCP wurde speziell für LLMs entwickelt und stellt ihnen Tools und Ressourcen zur Verfügung, die auf ihre Arbeitsweise zugeschnitten sind. OpenAPI hingegen richtet sich an Entwickler, die HTTP-APIs nutzen möchten, und konzentriert sich hauptsächlich darauf, Endpunkte zu strukturieren und diesen Schemata hinzuzufügen.

JSON:API fügt eine weitere Ebene hinzu, indem es standardisiert, wie die Schemata strukturiert sind und welche gemeinsamen Konzepte eine API offenlegen sollte, sodass Entwickler von bereits bekannten Konventionen profitieren und Tools wiederverwenden können, die diese unterstützen.

Es ist zwar möglich, MCP-Server automatisch aus OpenAPI zu generieren, aber das führt in der Regel nicht zu den besten Ergebnissen: Bei komplexeren APIs reicht eine Liste von Endpunkten nicht aus, da LLMs das implizite Verständnis fehlt, das Menschen beim Schreiben von Code mitbringen. Das ist der grundlegende Unterschied: OpenAPI und JSON:API gehen davon aus, dass ein menschlicher Developer die Lücken füllen kann, während MCP eine ausreichend aufgabenorientierte Struktur bereitstellen muss, damit ein LLM ohne diese menschliche Intelligenz erfolgreich sein kann.

iX: Machen LLMs bestimmte Ansätze zur Automatisierung überflüssig? Oder sind sie nur ein weiterer Anwendungsfall? Aufgrund der Nicht-Determiniertheit können sie eine zuverlässige Systemintegration vermutlich nicht wirklich ersetzen.

Wilde: Bei der Automatisierung geht es in der Regel um Zuverlässigkeit, Wiederholbarkeit und Effizienz, was LLMs nicht bieten. Sie sind nicht deterministisch, nicht zuverlässig reproduzierbar und nicht besonders effizient. Was sie jedoch bieten, ist eine neue Art von Kreativität: die Fähigkeit, Lücken zu schließen, Lösungen auszuprobieren und chaotischere Teile der Automatisierung zu bewältigen, die mit traditionellen Ansätzen nicht möglich sind.

Am besten betrachtet man sie als ein weiteres Werkzeug im Werkzeugkasten – eines, das wir selektiv einsetzen können, zum Erkunden oder für bestimmte Teile eines Prozesses, aber nicht für die Teile, die strenge Garantien erfordern. Architekturen, die LLM-gesteuerte Erkundung mit kodifizierten, deterministischen Workflows kombinieren, können das Beste aus beiden Welten vereinen: KI, wo Kreativität einen Mehrwert schafft, und traditionelle Automatisierung, wo Zuverlässigkeit unerlässlich ist.

Das Interview führte Richard Wallintin von WPS – Workplace Solutions.

(rme)

Mit smolBSD, einer liebevollen Verniedlichung von smallBSD, hat der spanische NetBSD-Entwickler Emile „iMil“ Heitor eine Umgebung geschaffen, um winzige NetBSD-Installationen zu erzeugen. Das schlanke Design soll die Grundlage für ein stabiles System mit möglichst geringem Ressourcenbedarf sein, das auf Sicherheit und Performance optimiert ist. Damit ist es für den Einsatz in eingebetteten Systemen, Containern, virtuellen Maschinen oder auf verschiedenen auch betagten Architekturen geeignet – ausdrücklich auch mit einem 32-Bit-Kernel für die x86-Plattform.

Mini-Systeme, Appliances und vor allem MicroVMs

Vor allem ist das minimalistische smolBSD aber dafür gedacht, als MicroVM (Micro Virtual Machine) in kurzlebigen, isolierten und sicheren Ausführungsumgebungen zu laufen. MicroVMs stellen beispielsweise QEMU, Cloud Hypervisor und Amazon mit Firecracker bereit. Auf der smolBSD-Projektseite werden QEMU und Firecracker als explizit funktionierende Plattformen genannt.

Details zu seiner Motivation, smolBSD zu entwickeln, und Informationen zum internen Aufbau präsentierte Heitor auf der BSDcon 2024 an der Universität in Ottawa in seinem Vortrag Making NetBSD a fast(er) booting microvm. Sein Projekt zieht bereits weitere Entwickler wie Leah Neukirchen an, der mit nitro ein kleines, flexibles und vor allem portables init-Framework samt Prozess-Supervisor (PID 1) geschaffen hat, das auch unter smolBSD läuft.

Erstaunlich einfach, schnell und problemlos

Um einen Blick auf smolBSD-MicroVMs zu werfen, benötigt man ein System mit Intel VT-x oder AMD-V, auf dem NetBSD, GNU/Linux oder macOS laufen. Ein Test mit dem systemd-losen Devuan GNU/Linux verlief problemlos, nachdem ein paar Pakete (qemu-system-x86, curl, git, bmake, uuid-runtime, bsdtar) installiert wurden. In der per git geklonten Kopie von smolBSD können Funktion und Konfiguration der MicroVMs im etc- und dem service-Verzeichnis angepasst werden. Vorgefertigte Beispiele wie ein simpler SSH-Zugang, ein SSH-Bouncer und ein Webserver sind im etc-Verzeichnis vorhanden. Das Image der MicroVM wird anschließend über bmake erzeugt und kann dann verteilt oder direkt über das startnb.sh-Skript gestartet werden.

Bei Microservices zählen Millisekunden

Im Zeitalter von Cloud-Architekturen, Serverless-Computing und Microservices werden immer fetter werdende Betriebssysteme mehr und mehr unattraktiv. Gewünscht sind extrem schlanke Systeme, die nur das enthalten, was wirklich gebraucht wird, und idealerweise quasi in Echtzeit starten. Ein Beispiel ist Amazons Firecracker, ein leichtgewichtiger Virtual Machine Monitor (VMM) via KVM, der speziell für das schnelle und sichere Starten isolierter MicroVMs in Cloud- und Serverless-Umgebungen entwickelt wurde. AWS Lambda (FaaS) und AWS Fargate (CaaS) führen Funktionen beziehungsweise Dienste oder Container ohne eigene Server-Basis aus. Auch QEMU bietet seit einiger Zeit „microvm“ als „machine type“ an.

Normalerweise werkelt in den Firecracker-MicroVMs Linux, in den letzten Jahren hat jedoch der FreeBSD-Entwickler Colin Percival FreeBSD für die Ausführung unter Firecracker tauglich gemacht. Das Projekt gilt noch als experimentell, aber die Startzeiten in seinen Tests von 25ms oder sogar unter 20ms im Vergleich zu Linux mit 75ms oder mehr zeigen, dass einiges an Potenzial in BSD-basierten MicroVMs steckt – und das nicht nur, weil AWS die Firecracker-Kosten in Millisekunden abrechnet. Laut dem Entwickler von smolBSD soll sein NetBSD-MicroVM-Kernel unter QEMU – also auf einer nicht wirklich vergleichbaren Umgebung – in 10 bis 14ms starten. Hier müssen konkrete Praxistests die echte Performance der drei Lösungen zeigen.

Fazit

Sicherlich ist es ein sicherheitstechnischer Vorteil, wenn MicroVMs nicht nur auf eine Linux-Monokultur setzen, sondern auch in Richtung FreeBSD und bald vielleicht NetBSD diversifiziert werden können. Mit smolBSD entsteht eine zusätzliche, sympathische Alternative.

(fo)