GenAI im Unternehmen: Das bestehende .NET-Fundament verwenden

Echten Nutzen bringt generative KI nicht bei individuellen Experimenten und Prototyping, sondern dann, wenn bestehende Softwareprodukte, Plattformen und Geschäftsprozesse gezielt durch GenAI erweitert werden.

Oft bilden hier C# und .NET das Fundament zahlreicher ERP-naher Systeme, Individualanwendungen und Standardprodukte. Rund um diese Plattform existieren umfangreiches Know-how, stabile Build- und Deployment-Pipelines sowie erprobte Betriebs- und Sicherheitskonzepte. Diese Investitionen sind langfristig angelegt und lassen sich nicht ohne Weiteres ersetzen.

Statt also komplette Systeme für GenAI neu zu entwickeln, sollen bestehende Anwendungen durch Assistenzfunktionen, kontextbezogene Unterstützung, teilautomatisierte Workflows oder Copilot-ähnliche Erweiterungen intelligenter werden. Dafür müssen Large Language Models (LLMs) nahtlos in bestehende Architekturen integrierbar sein.

Der Kontext zählt: GenAI als Experiment oder im Produktiveinsatz

Hier zeigt sich der Unterschied zwischen Experiment und Produktivsystem. Ein Proof of Concept lässt sich schnell in Python umsetzen. Für produktive Systeme zählen jedoch andere Kriterien: Integration in bestehende Authentifizierungsmechanismen, Zugriff auf interne Services und Datenbanken, Wiederverwendung bestehender Bibliotheken, sauberes Logging, reproduzierbare Builds und klar geregelter Betrieb. Jede zusätzliche Sprache und jede neue Toolchain erhöhen die Komplexität und damit Aufwand und Risiko.

Aus dieser Perspektive ist .NET für GenAI-Anwendungen hochrelevant. Nicht, weil .NET grundsätzlich besser für KI geeignet wäre, sondern weil es den Übergang vom Experiment zur produktiven Anwendung deutlich vereinfacht. Bestehende Teams können mit bekannten Werkzeugen arbeiten, vorhandene Infrastruktur bleibt nutzbar, Governance- und Sicherheitsanforderungen lassen sich leichter einhalten.

Gleichzeitig gilt: .NET ist selten die erste Wahl für KI-nahe Forschung, Modelltraining oder frühe Exploration. In diesen Bereichen dominieren Python und zunehmend auch TypeScript. Neue Frameworks und APIs erscheinen dafür meist zuerst.

Für produktive GenAI-Systeme in Unternehmen hingegen ist .NET häufig die naheliegende Plattform, vorausgesetzt, geeignete SDKs stehen zur Verfügung. Niemand möchte auf Protokollebene mit HTTP-Requests, JSON-Parsing und asynchronen Event-Streams arbeiten, nur um ein LLM anzubinden.

Gut gepflegte .NET-SDKs sind deshalb kein Luxus, sondern ein Enablement-Faktor. Sie bestimmen, ob bestehende Entwicklungsteams GenAI schnell, sicher und wartbar integrieren können oder ob unnötige Reibungsverluste entstehen. Wie gut die aktuelle SDK-Landschaft diesen Anspruch heute erfüllt, zeigt der Blick auf die verfügbaren Anbieter und Abstraktionen.

Die SDK-Landschaft für Large Language Models aus .NET-Sicht

Wer ein LLM mit .NET nutzen möchte, trifft heute auf eine deutlich vielfältigere SDK-Landschaft als noch vor einem Jahr. Doch nicht alle verfügbaren SDKs sind gleichwertig und nicht jedes eignet sich für produktive Anwendungen.

Die folgende Abbildung stellt den Zusammenhang zwischen Basis-SDKs, LLM-Proxies, Agenten-Schicht, Präsentationsschicht und MCP dar. Auf diese Punkte gehen die folgenden Kapitel genauer ein. Dabei beschäftigt sich der Artikel insbesondere damit, wie gut die SDK-Landschaft aus .NET-Sicht aufgestellt ist.

Lange Zeit waren offizielle SDKs für Large Language Models fast ausschließlich für Python und TypeScript verfügbar. Das beginnt sich zu ändern. Inzwischen stellen mehrere große Modellanbieter .NET-SDKs bereit, die sich für produktive Anwendungen eignen.

Die ersten ernstzunehmenden C#-SDKs für die OpenAI-API entstanden nicht direkt bei OpenAI selbst, sondern bei Microsoft als Teil der engen strategischen Partnerschaft zwischen beiden Unternehmen. Sie wiesen jedoch noch Schwächen auf. Nach einer Übergangsphase übernahm OpenAI selbst die Verantwortung. Heute wird das offizielle C#-SDK direkt von OpenAI gepflegt und als reguläres NuGet-Paket veröffentlicht. Microsoft stellt ergänzend ein begleitendes Paket bereit. Es erleichtert unter anderem Authentifizierung, Konfiguration und Integration mit OpenAI in Azure Foundry, ist jedoch optional. Die Kernfunktionalität für den Zugriff auf OpenAI-Modelle liegt heute eindeutig im offiziellen OpenAI-SDK selbst.

Anthropic stellt ein offizielles C#-SDK bereit, das aktuell noch als Beta gekennzeichnet ist, jedoch bereits gut nutzbar ist. Google bietet mit seinem GenAI-SDK eine offizielle .NET-Anbindung für Gemini-Modelle, sowohl für Google AI als auch für Vertex AI. Auch für andere LLM-Anbieter existieren heute offizielle, vom Hersteller gepflegte .NET-SDKs.

Die größte Reife und Verbreitung besitzt aber das OpenAI-SDK. Das zugehörige GitHub-Repository verzeichnet mehrere Tausend Sterne und das NuGet-Paket kommt auf fast 35 Millionen Downloads.

Neben den offiziellen SDKs existiert eine Vielzahl an Community- und Open-Source-SDKs. Eine besondere Rolle spielt hier das Projekt tryAGI, das auf Basis von OpenAI-Spezifikationen systematisch C#-SDKs für eine Vielzahl von LLM-Anbietern generiert.

Auf diese Weise stehen für viele Modelle SDKs zur Verfügung, für die es keine offiziellen .NET-Bibliotheken gibt, darunter auch Anbieter wie Mistral und Plattformen wie Ollama. Der Ansatz ist pragmatisch: Die SDKs sind konsistent aufgebaut, schnell verfügbar und decken in der Regel die grundlegenden API-Funktionen zuverlässig ab. Allerdings haben sie Grenzen: Generierte SDKs folgen relativ streng der jeweiligen API-Spezifikation mit keinen oder begrenzten manuellen Anpassungen, weshalb fortgeschrittene API-Funktionen manchmal nur holprig oder gar nicht verfügbar sind. Auch die langfristige Wartung hängt nicht vom Modellanbieter selbst ab, sondern vom Engagement der Community.

Für einfache Anwendungsfälle sind solche SDKs oft vollkommen ausreichend. Für komplexere, interaktive oder langfristig betriebene Systeme sollte man jedoch genau prüfen, ob ein Community-SDK den eigenen Anforderungen genügt.

Proxies und Kompatibilitätsschichten: Abstraktion statt Anbieterbindung

Eine weitere Kategorie bilden Proxies und Kompatibilitätsschichten, die versuchen, unterschiedliche Modellanbieter hinter einer einheitlichen API zu bündeln. Ein prominentes Beispiel dafür ist LiteLLM, das eine OpenAI-kompatible API bereitstellt und Anfragen an eine Vielzahl von Modellen weiterleitet.

Für .NET-Entwicklerinnen und -Entwickler kann dieser Ansatz attraktiv sein, da sie OpenAI-SDKs verwenden können. Oft genügt es, die Base-URL zu ändern und andere Modellnamen zu konfigurieren. Ähnlich verhält es sich bei lokal betriebenen Modellen über Ollama, das ebenfalls OpenAI-kompatible Endpoints bereitstellt.

Diese Abstraktion erleichtert den Wechsel zwischen Modellen und Anbietern, hat jedoch ihren Preis. Kompatibilitätsschichten orientieren sich in der Regel am kleinsten gemeinsamen Nenner der unterstützten APIs. Neuere oder anbieterspezifische Features werden häufig nur eingeschränkt unterstützt oder fehlen ganz. Besonders bei neueren API-Varianten oder fortgeschrittenen Funktionen kann es hier zu spürbaren Einschränkungen kommen.