Eine Treuhandfirma mit 40 Mitarbeitenden in Chicago bekam letztes Quartal eine spitze Frage vom externen Rechtsbeistand eines neuen Kunden: Können Sie bestätigen, dass keine unserer Steuerunterlagen auf einem Server ausserhalb der USA verarbeitet wird? Das KI-gestützte Dokumentenprüfungs-Tool der Firma lief über eine Public-Cloud-API, ohne vertragliche Garantie, wo die Inferenz tatsächlich stattfand. Niemand im Haus konnte die Frage mit Sicherheit beantworten, und der Kunde sprang ab.
Diese Szene spielt sich derzeit branchenübergreifend auf beiden Seiten des Atlantiks ab. Eine Gesundheitsgruppe, die einen KI-gestützten Dokumentationsassistenten evaluiert, muss über HIPAA und Business Associate Agreements nachdenken, bevor sie an Transkriptionsgenauigkeit denkt. Ein mittelgrosser Asset Manager in London muss über den EU AI Act und die DSGVO nachdenken, bevor er sich fragt, welches Modell die sauberste Zusammenfassung schreibt. Früher lautete die Frage, welches KI-Tool am besten funktioniert. Zunehmend lautet sie, wo das Tool läuft und wer sonst noch an die Daten kommt, während es das tut.
Nicht jedes KMU muss darauf reagieren, indem es einen GPU-Server in die Abstellkammer schraubt. Aber die Rechnung rund um KI auf Infrastruktur, die Sie selbst kontrollieren, statt sie tokenweise von einem Anbieter zu mieten, den Sie nicht kontrollieren, hat sich in den letzten achtzehn Monaten genug verschoben, um einen ehrlichen Blick zu verdienen: auf das, was heute möglich ist, was es braucht, um es gut zu betreiben, und wann die Public API weiterhin die klügere und günstigere Wahl ist.
Warum „Wohin gehen die Daten” zur Vertragsfrage wurde
Die Vertraulichkeit gegenüber Kunden ist der häufigste Auslöser. Anwaltskanzleien, Treuhandbüros, Boutique-Vermögensverwalter und Gesundheitsdienstleister verarbeiten allesamt Unterlagen, zu deren Schutz sie vertraglich oder standesrechtlich verpflichtet sind, und „die Daten gehen an eine Dritt-API” ist für immer mehr Kunden, Versicherer und Auditoren keine befriedigende Antwort mehr.
Die Regulierung verleiht diesem Instinkt Zähne. In Europa erfasst die DSGVO jede Verarbeitung personenbezogener Daten von EU-Ansässigen, unabhängig davon, wo das verarbeitende Unternehmen sitzt, und der EU AI Act legt Transparenz- und Risikomanagement-Pflichten obendrauf, mit Vorgaben für verschiedene Risikostufen, die bis 2026 und 2027 schrittweise greifen. In den USA deckt HIPAA geschützte Gesundheitsdaten durchgängig ab, was bedeutet, dass eine erfasste Einrichtung ein unterschriebenes Business Associate Agreement mit jedem KI-Anbieter braucht, bevor Patientendaten ihn berühren dürfen. US-Finanzinstitute tragen eine parallele Pflicht unter der Safeguards Rule des Gramm-Leach-Bliley Act, die laufende Anbieteraufsicht zu einer dauerhaften Rechtspflicht macht statt zu einem einmaligen Häkchen bei Vertragsunterzeichnung.
Die Frage der Jurisdiktion verkompliziert die Lage zusätzlich. Ein Server, der physisch in Frankfurt oder Dublin steht, entzieht Daten nicht automatisch dem Zugriff des US-Rechts, wenn das Unternehmen, das ihn betreibt, amerikanisch ist: Der CLOUD Act erlaubt es US-Behörden, die Herausgabe von Daten von jedem US-Anbieter zu verlangen, unabhängig davon, wo dessen Server stehen. Für ein europäisches Unternehmen, das Daten unter der DSGVO verarbeitet, ist das ein realer Konflikt, und Datenschutzbehörden in mehreren EU-Ländern haben das öffentlich gesagt.
Zwei weitere Druckfaktoren haben weniger mit Compliance zu tun als mit gewöhnlichem Geschäftssinn. Vendor Lock-in ist real: Preise, Rate Limits und Modellverfügbarkeit liegen ausserhalb Ihrer Kontrolle, sobald ein Workflow vollständig um die API eines einzigen Anbieters herum gebaut ist. Und Token-Kosten, die im Pilot trivial aussehen, können sich bei anhaltendem Produktionsvolumen schnell aufsummieren, eine Dynamik, die man ehrlich durchrechnen sollte, bevor man sich in eine der beiden Richtungen festlegt (die eigentliche Rechnung folgt weiter unten).
Genau diese Art von Randbedingung prägt, wie ein Embedded-AI-Engineering-Service ein Projekt vom ersten Meeting an scoped. Ob Infrastrukturkontrolle eine Präferenz oder eine harte Anforderung ist, verändert die Architektur, bevor die erste Zeile Code geschrieben wird.
Was ausserhalb einer Public API heute wirklich gut läuft
Die Technologie hat sich 2025 und 2026 schnell genug bewegt, dass Ratschläge von vor zwei Jahren heute nahezu nutzlos sind. Eine Handvoll Open-Weight-Modellfamilien ist inzwischen ernsthaft konkurrenzfähig mit proprietären Frontier-Modellen bei den Aufgaben, die den Grossteil der KMU-Workloads ausmachen: Dokument-Q&A, Klassifikation, Textentwürfe, Zusammenfassungen und strukturierte Datenextraktion.
Metas Llama-4-Familie, veröffentlicht im April 2025, umfasst Scout, ein Mixture-of-Experts-Modell mit 17 Milliarden aktiven Parametern, das quantisiert auf eine einzelne gut ausgestattete GPU passt, sowie eine grössere Maverick-Variante. Mistral veröffentlichte Large 3 im Dezember 2025, ein Mixture-of-Experts-Modell mit 675 Milliarden Parametern (41 Milliarden aktive Parameter pro Durchlauf) unter der permissiven Apache-2.0-Lizenz, derselben Lizenz, die Alibaba für Qwen 3.5 nutzte, das in Wellen durch den Februar und März 2026 ausgerollt wurde. Das Schweizer Modell Apertus, gebaut von der ETH Zürich, der EPFL und dem Swiss National Supercomputing Centre und veröffentlicht im September 2025, geht noch einen Schritt weiter: Gewichte, Trainingsdaten und Trainingscode sind vollständig öffentlich, und es wurde ausdrücklich mit Blick auf die Transparenzpflichten des EU AI Act entworfen.
| Modellfamilie | Veröffentlicht | Relevanz für KMU | Lizenz |
|---|---|---|---|
| Llama 4 (Meta) | April 2025 | Scout-Variante läuft quantisiert auf einer High-End-GPU; sehr grosses Kontextfenster | Kostenlos, mit Nutzungsbeschränkungen ab 700 Mio. monatlich aktiven Nutzern |
| Mistral Large 3 | Dezember 2025 | 41 Mrd. aktive von 675 Mrd. Parametern; starkes allgemeines Reasoning | Apache 2.0 |
| Qwen 3.5 (Alibaba) | Feb.-März 2026 | Stark bei Mehrsprachigkeit und Coding; auch kleinere dichte Varianten erschienen | Apache 2.0 |
| Apertus (ETH Zürich / EPFL / CSCS) | September 2025 | Vollständig offen inklusive Trainingsdaten; mit Blick auf EU-Transparenzregeln gebaut | Apache 2.0 |
Behandeln Sie diese Tabelle als Momentaufnahme. Neue Releases erscheinen alle paar Monate, Benchmarks verschieben sich, und Lizenzen zählen genauso viel wie rohe Fähigkeit: Llamas Community-Lizenz ist für die überwältigende Mehrheit der KMU kostenlos, bringt aber Nutzungsbeschränkungen und eine Attributionspflicht mit, die die Apache-lizenzierten Alternativen nicht kennen. Welches Modell Sie heute auch wählen, budgetieren Sie den Austausch innert zwölf bis achtzehn Monaten ein.
Vollständige On-Prem-Hardware ist nicht die einzige Option, und für die meisten KMU sollte sie nicht die erste sein, die geprüft wird. Ein Private-Cloud-Deployment, also eine dedizierte GPU-Instanz, gemietet bei einem EU- oder US-Anbieter unter einem sauberen Auftragsverarbeitungsvertrag und in einer bekannten Rechtsordnung, liefert den grössten Teil des Souveränitätsgewinns ohne die Kapitalausgabe und ohne die laufende Wartungslast eigener Server. Volles On-Prem verdient seine Kosten meist erst dann, wenn selbst ein dedizierter Cloud-Tenant inakzeptabel ist, was in der Praxis üblicherweise die am strengsten regulierten Workloads im Gesundheitswesen, im Finanzsektor oder im öffentlichen Sektor bedeutet.
Warum die Skills-Lücke KMU früher stoppt als das Hardware-Budget
Eine GPU zu kaufen ist der einfache Teil. Eine einzelne Karte, die ein gut quantisiertes Modell mit 20 bis 70 Milliarden Parametern betreiben kann, kostet je nach Konfiguration zwischen 25.000 und 70.000 Dollar, oder lässt sich bei einem Cloud-GPU-Anbieter stundenweise mieten, für grob $1 bis $4 pro Stunde je nach Karte und Anbieter. Das ist eine Budgetzeile. Der Projektplan ist alles, was danach kommt.
Ob ein Self-Hosted-Deployment funktioniert, entscheidet ein Set laufender Engineering-Disziplinen, die die meisten KMU bisher nie gebraucht haben:
- Hardware-Sizing. Modellgrösse, Quantisierungsstufe und erwartete gleichzeitige Nutzer auf eine konkrete GPU-Konfiguration abstimmen, und diese Rechnung bei jedem Modellwechsel neu prüfen.
- Modellauswahl. Ein Modell anhand Ihrer tatsächlichen Aufgabe und Sprache wählen statt anhand eines Leaderboard-Scores, gemessen auf einem Benchmark, den Ihr Geschäft nie berühren wird.
- Retrieval über Ihre eigenen Dokumente. Ein fähiges Modell dazu zu bringen, Fragen gegen unordentliche interne PDFs, Tabellen und E-Mails zu beantworten, ist ein Such- und Ranking-Problem, bevor es ein Sprachproblem ist. Naives Retrieval produziert selbstsichere, falsche Antworten öfter, als die meisten Teams erwarten.
- Evaluation. Ein Testset echter Fragen mit bekannt guten Antworten, ausgeführt vor jeder Modell- oder Prompt-Änderung, ist der einzige verlässliche Weg, eine Regression zu erwischen, bevor ein Kunde es tut.
- Monitoring. Latenz, Kosten und Antwortqualität in der Produktion verfolgen. Uptime allein sagt Ihnen nicht, ob die Antworten noch gut sind.
- Updates. Neue Modellversionen erscheinen alle paar Monate, und jede muss vor dem Produktionseinsatz gegen Ihr Testset re-evaluiert werden, typischerweise ein paar Engineer-Tage pro Update.
Eine MIT-Studie fand, dass rund 95 Prozent der generativen KI-Piloten in Unternehmen keinen messbaren Effekt auf die Erfolgsrechnung zeigten, und führte die Fehlschläge hauptsächlich auf Integrationslücken zurück statt auf Modellqualität (die Methodik der Studie ist umstritten, behandeln Sie die Zahl also als Richtwert, nicht als Präzisionsangabe). Self-Hosted-Deployments scheitern auf dieselbe Weise: Das Modell überzeugt in der Demo, degradiert dann leise gegen echte Dokumente und die Randfälle, die Nutzer tatsächlich eintippen, und niemand merkt es, bis ein Kunde es merkt.
Ein Data-Science-Team ist dafür Overkill. Eine Person, die das schon einmal gemacht hat, genügt: jemand, der die Hardware beim ersten Mal richtig dimensioniert und das Retrieval gegen Ihren tatsächlichen Dokumentenbestand zum Laufen bringt, und der die Evaluationsroutine vor dem Go-live aufbaut statt nach der ersten peinlichen Falschantwort.
Wann die API weiterhin gewinnt und wann sich lokal auszahlt
Rechnen Sie, bevor Sie irgendetwas entscheiden. Frontier-API-Preise liegen Mitte 2026 grob zwischen $0,10 und $25 pro Million Tokens, je nach Modell und Richtung (Input ist in der Regel günstiger als Output), und für die meisten KMU im Pilot- oder frühen Produktionsvolumen ist das ein Rundungsfehler neben der Lohnsumme. Ein Support-Team, das 200 Kundenfragen pro Tag über eine Retrieval-Pipeline gegen Firmendokumente beantwortet, bei rund 8.000 Tokens abgerufenem Kontext und Antwort pro Frage, verbrennt grob 1,6 Millionen Tokens pro Tag. Bei einem typischen Mischsatz von $3 pro Million Tokens sind das unter $150 im Monat, bequem innerhalb der routinemässigen Softwareausgaben.
Das Volumen muss deutlich weiter steigen, als die meisten annehmen, bevor die Arithmetik für den Hardwarekauf spricht. Nehmen Sie einen geschäftigeren, illustrativen Fall: ein Unternehmen mit 60 Mitarbeitenden, das einen kundenseitigen Support-Agenten mit 3.000 Konversationen pro Tag betreibt, jede mit rund 4.000 Tokens an abgerufenen Produktdaten, Verlaufskontext und generierter Antwort. Das ergibt grob 360 Millionen Tokens im Monat. Zum selben Mischsatz von $3 pro Million landet die jährliche API-Rechnung bei rund $13.000, eine echte Budgetzeile, aber immer noch klar unter den 40.000 bis 70.000 Dollar, die ein fähiger dedizierter GPU-Server im Direktkauf kostet. Holen Sie eine konkrete Offerte für Ihr Modell, Ihr Volumen und Ihre Hardware-Konfiguration ein, bevor Sie diese Rechnung im Ernst machen; die Zahlen hier sind illustrativ und sollen die Form des Trade-offs zeigen, nicht ein fertiger Business Case sein.
Bei dieser Lücke lohnt es sich zu verweilen. Ein reiner Token-Kosten-Breakeven rechtfertigt den Kauf dedizierter Hardware für ein typisches KMU selten. Sie bräuchten Callcenter-Volumen, anhaltend rund um die Uhr, bevor die Arithmetik allein Richtung Eigentum kippt. Was die meisten KMU zu lokaler oder Private-Cloud-Infrastruktur treibt, ist die Anforderung zu kontrollieren, wo die Daten physisch liegen und wer darauf zugreifen kann. Die Kosten werden zum sekundären Faktor, sobald diese Anforderung feststeht, und an diesem Punkt ist das Mieten einer Private-Cloud-GPU-Instanz üblicherweise der kosteneffizientere Weg, sie zu erfüllen, als ein Server im Direktkauf.
Die Entscheidung läuft meist auf zwei Variablen hinaus, die aus unterschiedlichen Gründen zählen: wie sensibel die Daten sind, was entscheidet, ob Sie Infrastrukturkontrolle überhaupt brauchen, und wie viel Sie verarbeiten, was entscheidet, ob Mieten oder Kaufen der vernünftigere Weg dorthin ist.
Die API ist weiterhin die richtige Antwort, wenn:
- das Volumen tief oder sprunghaft ist, ein paar tausend Anfragen im Monat statt Millionen
- die Daten weder reguliert noch vertraglich sensibel sind
- die Iterationsgeschwindigkeit am Produkt wichtiger ist als die Kontrolle über die Infrastruktur darunter
- noch niemand im Team Modell-Updates und Evaluation langfristig verantworten kann
Lokale oder Private-Cloud-Infrastruktur beginnt zu gewinnen, wenn:
- das Volumen anhaltend und planbar genug ist, um Hardware darauf auszulegen
- die Daten reguliert sind (Gesundheitsakten, Finanzdaten, Anwaltsgeheimnis) oder echte vertragliche Vertraulichkeitspflichten tragen
- ein Kunde, Versicherer oder Auditor Datenresidenz oder einen benannten Verarbeitungsort ausdrücklich verlangt hat
- jemand im Team, oder jemand, der gerade eingestellt wird, die laufende Engineering-Arbeit verantworten kann
Warum diese Arbeit einen Engineer in Ihren eigenen Wänden braucht
Alles, was Self-Hosted-KI zum Funktionieren bringt, passiert innerhalb Ihrer Systeme, mit Ihren Daten, und es muss von jemandem gemacht werden, der das Geschäft genauso versteht wie die Infrastruktur. Die Hardware auf den realen Workload zu dimensionieren und das Retrieval gegen Ihre tatsächlichen Dokumente zu tunen, sind Innenjobs, und die laufende Wacht über die Produktionsqualität ist es auch. Nichts davon lässt sich von einem Foliensatz aus scopen oder als einmaliges Deliverable übergeben und dann sich selbst überlassen.
Genau auf dieses Modell hat sich die KI-Branche für ihre härtesten Deployments eingeschwenkt. OpenAI, Anthropic und AWS haben in den letzten zwei Jahren alle dedizierte Implementierungsteams aufgebaut, vor allem weil sich die generische Modellfähigkeit als die einfachen 80 Prozent des Problems herausstellte. Die letzte Meile, der Teil, der im Stack eines bestimmten Unternehmens auf dessen Daten und unter dessen Randbedingungen läuft, brauchte Engineers vor Ort statt ein Support-Ticket. Dieses Muster hat inzwischen einen Namen: Forward-Deployed Engineering. Was ein Forward-Deployed Engineer wirklich ist und wie sich das mit einem Freelancer oder der Übergabe des ganzen Projekts an eine Agentur vergleicht, lohnt sich zu verstehen, bevor Sie entscheiden, wer das für Sie baut: siehe Embedded AI Engineer vs. Freelancer vs. Agentur.
Wenn Ihr Unternehmen irgendwo in der Mitte steht, jenseits des Punkts, an dem die Einfachheit der Public API das Compliance-Risiko aufwiegt, aber noch unsicher, welche Hardware, welches Modell und welches Team es bräuchte, um das selbst zu betreiben, dann ist das ein Gespräch wert, bevor eine Bestellung rausgeht. Ein 30-minütiger Call kann Ihnen ehrlich sagen, ob On-Prem- oder Private-Cloud-KI zu Ihrem Volumen und Ihrer Datensensibilität passt, ob Ihr Team sie am Laufen halten kann, oder ob ein weiteres Jahr auf der API der klügere Zug ist.
Häufige Fragen
Kann ein kleines Unternehmen wirklich eine eigene KI betreiben, oder ist On-Prem nur für Grossunternehmen realistisch?
Ein kleines Unternehmen kann fähige Open-Weight-Modelle wie Llama 4, Mistral Large 3 oder Qwen 3.5 auf einem einzelnen gut ausgestatteten GPU-Server betreiben oder äquivalente Kapazität bei einem Private-Cloud-Anbieter mieten. Das Hardware-Budget ist selten der begrenzende Faktor. Knapp ist eine Person, die das Deployment richtig dimensioniert, das Retrieval auf Ihre Dokumente abstimmt und weiter evaluiert, während sich Modelle und Daten verändern.
Macht uns das Self-Hosting eines KI-Modells automatisch DSGVO- oder HIPAA-konform?
Nein. Ein Modell auf Infrastruktur zu betreiben, die Sie kontrollieren, beseitigt ein spezifisches Risiko, nämlich den unkontrollierten Datentransfer an einen Drittverarbeiter in einer unsicheren Rechtsordnung. Sie brauchen aber weiterhin eine Rechtsgrundlage für die Verarbeitung, Zugriffskontrollen, Audit-Logging und ein unterschriebenes Business Associate Agreement oder ein Äquivalent, wo die Regulierung eines verlangt. Self-Hosting ist eine Kontrolle unter mehreren, kein Compliance-Programm für sich allein.
Welche Open-Weight-Modelle sind Mitte 2026 tatsächlich gut genug, um eine bezahlte API zu ersetzen?
Llama 4 (Meta, April 2025), Mistral Large 3 (Dezember 2025) und Qwen 3.5 (Alibaba, ausgerollt Februar bis März 2026) schneiden bei gängigen Geschäftsaufgaben wie Dokument-Q&A, Klassifikation und Textentwürfen konkurrenzfähig ab. Dieses Feld bewegt sich schnell, mit relevanten neuen Releases alle paar Monate; validieren Sie jede konkrete Wahl gegen Ihre eigenen Testfälle, bevor Sie sich festlegen.
Wann ist es finanziell sinnvoller, bei einer Pay-per-Token-API zu bleiben, statt selbst zu hosten?
Wenn das Volumen tief oder unberechenbar ist, typischerweise ein paar tausend Anfragen im Monat statt Millionen, und die Daten weder reguliert noch vertraglich sensibel sind. In dieser Grössenordnung kostet ein dedizierter GPU-Server oder eine Private-Cloud-Instanz in Anschaffung, Betrieb und Wartung meist mehr als die API-Rechnung, die er ersetzen würde.
Womit verbrennen sich KMU beim Betrieb eigener KI-Infrastruktur am häufigsten?
Indem sie sie als einmaligen Hardwarekauf behandeln statt als dauerhafte Engineering-Verantwortung. Teams dimensionieren eine GPU, deployen ein Modell und erklären den Sieg, und sehen dann zu, wie die Retrieval-Qualität gegen echte Dokumente nachlässt, oder sie überspringen die Evaluation eines Modell-Updates, das das Produktionsverhalten leise verändert. Eine wiederkehrende Skills-Lücke lässt die meisten Self-Hosted-KI-Projekte unterperformen, weit häufiger als die Kapitalkosten.