Vitalij Bojatschkin

KI lokal hosten im Unternehmen: Self-Hosting vs. AWS Bedrock

Q: Ist selbst gehostete KI automatisch DSGVO-konform?

Nein. Der Speicherort ist nur ein Baustein. Auch bei lokalem Betrieb brauchen Sie Zugriffskontrollen, Löschkonzepte, Protokollierung und eine saubere Rechtsgrundlage für die Verarbeitung. Umgekehrt kann ein Managed-Service wie AWS Bedrock in eu-central-1 mit Auftragsverarbeitungsvertrag DSGVO-konform betrieben werden. Entscheidend ist die Gesamtarchitektur, nicht das Etikett 'lokal'.

Q: Welche Hardware brauche ich, um ein LLM selbst zu hosten?

Für Modelle der kleineren Klasse (7–14B Parameter, quantisiert) reicht eine einzelne GPU mit 24 GB VRAM. Für größere Modelle, die qualitativ mit Cloud-Angeboten mithalten, sind mehrere professionelle GPUs nötig — inklusive Server, Kühlung, USV und Wartungsvertrag. Die Hardware ist dabei nicht der größte Posten: Der laufende Betrieb kostet erfahrungsgemäß mehr als die Anschaffung.

Q: Was kostet Self-Hosting im Vergleich zu AWS Bedrock?

Pauschal nicht seriös zu beantworten — es hängt von Last und Modellklasse ab (prozessabhängig). Als Faustregel aus Projekten: Bei sporadischer Nutzung (Pilotphase, wenige tausend Anfragen pro Monat) ist Bedrock fast immer günstiger, weil Sie nur pro Token zahlen. Self-Hosting rechnet sich erst bei konstanter, hoher Last — und nur, wenn Sie die Ops-Zeit ehrlich einpreisen.

Q: Kann ich mit Ollama produktiv arbeiten oder ist das nur für den Heimserver?

Ollama ist ein hervorragender Einstieg für Experimente und interne Prototypen. Für den produktiven Unternehmenseinsatz mit mehreren gleichzeitigen Nutzern stoßen Sie an Grenzen (Durchsatz, Warteschlangen, Multi-GPU). Dort ist vLLM der übliche nächste Schritt — mit deutlich mehr Konfigurationsaufwand. Beides ersetzt kein Monitoring, keine Zugriffskontrolle und kein Backup-Konzept.

Q: Welche offenen Modelle sind 2026 für den Unternehmenseinsatz brauchbar?

Die offenen Modellfamilien (Llama, Mistral, Qwen, DeepSeek) haben 2026 ein Niveau erreicht, das für klar umrissene Aufgaben wie Klassifikation, Extraktion und interne Assistenten gut ausreicht. Für komplexe mehrstufige Aufgaben liegen die großen API-Modelle weiterhin vorn. Mein Rat: Aufgabe definieren, dann mit einem kleinen offenen Modell testen — nicht umgekehrt das größte Modell beschaffen und Anwendungsfälle suchen.

Q: Wie starte ich, ohne mich falsch festzulegen?

Bauen Sie Ihre Anwendung gegen eine austauschbare Schnittstelle (z. B. ein internes API-Gateway vor dem Modell). Dann können Sie mit Bedrock starten, Lastdaten sammeln und später auf Self-Hosting wechseln — oder umgekehrt — ohne die Anwendung umzubauen. Der teuerste Fehler ist, die Modellwahl fest in die Anwendung zu verdrahten.

LLM selbst hosten oder AWS Bedrock nutzen? Ehrlicher Vergleich für Unternehmen: echte Kosten, DSGVO-Realität, Hardware-Anforderungen und eine Entscheidungsmatrix — von jemandem, der beides betreibt.

import BlogFAQ from '../../src/components/BlogFAQ'; import KeyTakeaways from '../../src/components/KeyTakeaways';

<KeyTakeaways items= /

<p data speakable KI lokal hosten oder als Managed Service beziehen? Die kurze Antwort: Self Hosting lohnt sich bei konstanter Last, strikten Datenanforderungen und vorhandener Betriebskompetenz — für die meisten Unternehmen ist AWS Bedrock in eu central 1 der wirtschaftlichere und schneller produktive Weg. Dieser Artikel vergleicht beide Wege ehrlich: Kosten, DSGVO, Hardware, Betrieb. Ich betreibe beides — ein Homelab mit selbst gehosteten Agenten und Kundensysteme auf Bedrock — und kenne die Bruchstellen auf beiden Seiten. </p

Warum wollen Unternehmen KI überhaupt selbst hosten?

Drei Motive höre ich in fast jedem Gespräch: Die Daten sollen das Haus nicht verlassen, die laufenden API Kosten machen nervös, und niemand will von einem einzelnen Anbieter abhängen. Alle drei Motive sind berechtigt. Aber sie führen nur dann zu Self Hosting, wenn man sie zu Ende denkt — und genau da wird es interessant.

Der Datenschutz Reflex („lokal = sicher") greift zu kurz, dazu unten mehr. Die Kostenrechnung kippt je nach Lastprofil in beide Richtungen. Und die Anbieterabhängigkeit lässt sich auch architektonisch lösen, ohne einen einzigen Server zu kaufen.

Was heißt „lokal hosten" konkret?

Der übliche Weg 2026: ein offenes Modell (Llama, Mistral, Qwen oder DeepSeek) auf eigener Hardware, gestartet mit Ollama für Experimente oder vLLM für den Mehrbenutzerbetrieb. Das kann ein einzelner GPU Server im Serverraum sein, eine VM auf einem Proxmox Host oder gemietete dedizierte Hardware im deutschen Rechenzentrum.

Wichtig für die Einordnung: Ein Modell zum Laufen zu bringen ist 2026 keine Kunst mehr — ein Nachmittag reicht. Die Arbeit beginnt danach: Zugriffskontrolle, Monitoring, Updates, Ausfallsicherheit, Kapazitätsplanung. Wer schon einmal einen KI Agenten mit Shell Zugriff sicher betrieben hat, weiß: Der Betrieb ist das Produkt, nicht die Installation.

Was kostet Self Hosting wirklich?

Die Hardware Rechnung ist der kleinste Teil. Ehrlich kalkuliert besteht Self Hosting aus vier Posten:

| Kostenblock | Was oft vergessen wird | | | | | Hardware | GPUs mit ausreichend VRAM, Server, USV, Ersatzteile — plus Abschreibung über 3–4 Jahre | | Strom & Stellplatz | Eine GPU unter Dauerlast ist ein spürbarer Posten auf der Stromrechnung | | Betrieb (der große Block) | Updates, Security Patches, Monitoring, Störungsbeseitigung — reale Personenstunden, jeden Monat | | Opportunitätskosten | Die Zeit, die Ihr Team am Modellbetrieb arbeitet, fehlt am eigentlichen Anwendungsfall |

Bei Bedrock zahlen Sie pro Token und für nichts davon. Bei sporadischer Nutzung — und jede Pilotphase ist sporadische Nutzung — ist der Managed Service deshalb fast immer günstiger. Self Hosting rechnet sich erst, wenn eine konstante, planbare Last die Fixkosten trägt. Konkrete Zahlen sind prozessabhängig; einen Rechenrahmen für typische Mittelstandsprojekte finden Sie in Was kostet KI im Mittelstand?.

Ist lokal gehostete KI automatisch DSGVO konform?

Nein — und dieser Irrtum ist teuer. Der Speicherort ist ein Baustein der Konformität, nicht die Konformität selbst. Auch ein lokales System braucht Zugriffskontrollen, Löschkonzepte, Protokollierung und eine Rechtsgrundlage für die Verarbeitung. Ein offener Ollama Port im Firmennetz, auf den jeder Mitarbeiter Kundendaten schicken kann, ist lokal — und trotzdem ein Datenschutzproblem.

Umgekehrt lässt sich AWS Bedrock in der Region eu central 1 (Frankfurt) mit Auftragsverarbeitungsvertrag sauber DSGVO konform betreiben: Die Daten verlassen die Region nicht, und Bedrock verwendet Kundendaten nicht zum Modelltraining. Wie eine solche Architektur aussieht, habe ich im DSGVO Leitfaden für KI Projekte beschrieben.

Die ehrliche Formel: Lokal gewinnt bei der Datenkontrolle nur dann, wenn der Betrieb professionell ist. Sonst tauschen Sie ein beherrschbares Vertragsrisiko gegen ein unbeherrschtes Betriebsrisiko.

Wann ist AWS Bedrock die bessere Wahl?

In vier Situationen ist die Antwort klar:

1. Sie starten gerade erst. Ein Pilot auf Bedrock steht in Tagen, nicht Wochen — ohne Hardware Beschaffung. Ob Ihr Use Case trägt, wissen Sie so deutlich schneller. Ein typisches Beispiel ist der interne Wissensassistent, der als Bedrock Pilot mit begrenztem Scope beginnt. 2. Ihre Last schwankt. Saisonale Spitzen, Bürozeiten Muster, unklares Wachstum — pro Token zahlen schlägt vorgehaltene GPUs. 3. Sie brauchen Spitzenqualität. Für komplexe, mehrstufige Aufgaben liegen die großen API Modelle (Claude, GPT) 2026 weiterhin vor den offenen Modellen, die realistisch selbst zu betreiben sind. 4. Niemand im Haus will den Betrieb verantworten. Das ist keine Schwäche, sondern eine ehrliche Ressourcenfrage.

Wie ein produktives Bedrock Setup aussieht, zeigt der Praxisartikel RAG Chatbot mit AWS Bedrock.

Wann lohnt sich Self Hosting tatsächlich?

Es gibt legitime Self Hosting Fälle, und die sollte man genauso klar benennen:

Harte Datenanforderungen: Branchen oder Verträge, die eine Verarbeitung außerhalb der eigenen Infrastruktur ausschließen — nicht als Bauchgefühl, sondern schriftlich. Konstante Dauerlast: Ein Klassifikations oder Extraktionsprozess, der rund um die Uhr mit planbarem Volumen läuft, kann die Fixkosten eines eigenen Servers tragen. Vorhandene Ops Kompetenz: Ein Team, das ohnehin Server, Monitoring und Patch Zyklen betreibt, integriert ein Modell mit vertretbarem Zusatzaufwand. Klar umrissene Aufgaben: Für Klassifikation, Extraktion und interne Assistenten reichen offene Modelle der mittleren Klasse 2026 gut aus — hier verschenkt man mit API Spitzenmodellen Geld.

Treffen mindestens zwei dieser Punkte zu, ist Self Hosting eine ernsthafte Option. Trifft keiner zu, ist es ein Hobby — als solches völlig legitim, aber kein Geschäftsmodell.

Die Entscheidungsmatrix

Der Hybrid Ansatz: nicht entweder oder

Die Architektur, die ich in Projekten am häufigsten empfehle, kombiniert beides: Die Anwendung spricht mit einem internen Gateway, nicht direkt mit einem Modell. Dahinter kann pro Aufgabe das passende Backend stehen — ein lokales Modell für die sensible Vorverarbeitung, Bedrock für die anspruchsvolle Analyse, jederzeit austauschbar.

Der Nebeneffekt ist strategisch: Sie legen sich nicht fest. Startet der Pilot auf Bedrock und zeigt die Lastkurve nach sechs Monaten konstantes Volumen, wechseln Sie den Backend Eintrag — nicht die Anwendung. Der teuerste Fehler in KI Projekten ist nicht die falsche Anfangsentscheidung, sondern die fest verdrahtete.

Mein Fazit

Self Hosting ist 2026 technisch so zugänglich wie nie — und wird trotzdem regelmäßig aus den falschen Gründen gewählt. Wer aus Kostenangst lokal hostet, zahlt am Ende meist drauf. Wer aus Datenschutz Reflex lokal hostet, ohne den Betrieb zu professionalisieren, verschlechtert seine Lage. Die richtige Reihenfolge: Use Case validieren (auf Bedrock, schnell und günstig), Lastdaten sammeln, dann mit echten Zahlen über Self Hosting entscheiden — hinter einer Architektur, die den Wechsel erlaubt.

Wenn Sie gerade vor genau dieser Entscheidung stehen: Im Erstgespräch klären wir, welcher Weg zu Ihrer Datenlage, Ihrem Lastprofil und Ihrem Team passt — auch wenn die Antwort „noch gar keiner" lautet.

<BlogFAQ items= /