„Unsere Daten liegen in Frankfurt, also sind sie sicher.“ Diesen Satz hören wir in fast jedem Erstgespräch über KI mit sensiblen Daten. Er kommt von IT-Leitern, von Datenschutzbeauftragten, manchmal vom Geschäftsführer selbst. Er ist verständlich. Und er greift zu kurz. Denn die eigentliche Frage beantwortet ein deutsches Rechenzentrum nicht. Wer kann rechtlich auf unsere Daten zugreifen? Die Antwort hängt nicht an der Postleitzahl des Serverraums. Sie hängt an der Jurisdiktion, der der Betreiber unterliegt.

Wir sind BKS-Lab, eine Marke der Boiman Kupermann Solutions GmbH aus Köln. Wir machen vertrauliches Unternehmenswissen durchsuchbar, analysierbar und automatisierbar. Die Systeme dafür laufen lokal oder selbstgehostet. Daten und Infrastruktur bleiben unter der Kontrolle des Unternehmens. In diesem Beitrag legen wir ausführlich dar, warum wir dieses Problem für eines der unterschätztesten der aktuellen KI-Welle halten. Wir zeigen, was wir konkret liefern und wie ein Projekt bei uns abläuft. Der Text ist lang geworden, mit Absicht. Wer über den Umgang mit seinem wertvollsten Wissen entscheidet, hat mehr verdient als drei Bulletpoints.

Vorab eine Einordnung, die uns wichtig ist. Dieser Beitrag enthält rechtliche Fakten zum US CLOUD Act, zur DSGVO und zum EU AI Act. Wir haben sie sorgfältig recherchiert. Wir sind aber Technologen und keine Kanzlei. Für die rechtliche Bewertung im Einzelfall ziehen Sie bitte fachkundigen Rat hinzu.

Die erste Herausforderung. Ihr wertvollstes Wissen ist verteilt

Jedes Unternehmen, mit dem wir sprechen, hat denselben Befund, nur in unterschiedlicher Ausprägung. Das Wissen, das den eigentlichen Wert des Unternehmens ausmacht, liegt in Dokumenten, Datenbeständen und Prozessen. Aber es liegt dort nicht geordnet. Es verteilt sich über Netzlaufwerke, ein ungepflegtes Wiki, Postfächer einzelner Mitarbeiter, Ticketsysteme und Fachanwendungen ohne Schnittstellen. Wer eine konkrete Frage hat, sucht an fünf Stellen. Was haben wir diesem Kunden 2022 zugesagt? Welche Variante dieser Klausel haben wir schon einmal verhandelt? Gab es diesen Schadensfall schon einmal? Im Zweifel findet er die veraltete Version.

Die Kosten dieses Zustands sind gut belegt, auch wenn sie in keiner Bilanz auftauchen. Das McKinsey Global Institute hat bereits 2012 in der Studie „The Social Economy“ errechnet, dass Wissensarbeiter rund 19 Prozent ihrer Arbeitswoche mit dem Suchen und Zusammentragen von Informationen verbringen. Das ist fast ein voller Arbeitstag. Neuere Erhebungen von IDC und anderen Marktforschern kommen auf vergleichbare Größenordnungen. Für ein mittelständisches Unternehmen mit 200 Wissensarbeitern entspricht das rechnerisch etwa 35 Vollzeitkräften, die nichts anderes tun als suchen. Diese Zeit fehlt im Vertrieb, in der Projektarbeit und in der Entwicklung.

Bis vor wenigen Jahren gab es darauf nur zwei Antworten, und beide waren unbefriedigend. Die erste hieß mehr Disziplin, also Ablagerichtlinien, Dokumentationspflichten und noch ein Wiki. Das scheitert regelmäßig an der Realität des Tagesgeschäfts. Die zweite war die klassische Enterprise-Suche, ein Volltextindex über die Ablagen. Sie findet Zeichenketten, versteht aber keine Zusammenhänge. Wer nach „Gewährleistungsfrist“ sucht, findet das Dokument nicht, in dem „Mängelhaftung 24 Monate“ steht.

Erst große Sprachmodelle haben diese Lücke geschlossen. Semantische Suche findet Inhalte nach Bedeutung statt nach Wortlaut. Ein Sprachmodell zieht aus einem 80-seitigen Vertrag die drei relevanten Passagen. Es erkennt Vertragspartner, Fristen und Beträge und beantwortet Fragen in natürlicher Sprache, mit Quellenverweis auf die Fundstelle. Für das Geschäft heißt das, die verstreute Ablage ist kein Naturgesetz mehr. Und genau an diesem Punkt beginnt die zweite Herausforderung.

Verschärft wird das Problem durch zwei Entwicklungen, die selten zusammen gedacht werden. Erstens wächst der unstrukturierte Teil der Unternehmensdaten seit Jahren deutlich schneller als der strukturierte. Dazu zählen Dokumente, E-Mails, Präsentationen und Protokolle. Gängige Analysen von Marktforschern wie IDC verorten diesen Anteil bei achtzig Prozent und mehr des gesamten Bestands. Genau dieser Teil ist mit klassischen Datenbankwerkzeugen am schlechtesten erschlossen. Zweitens verlassen mit der Verrentung der geburtenstarken Jahrgänge viele Erfahrungsträger den deutschen Arbeitsmarkt. Mit ihnen geht Wissen, das nie dokumentiert wurde oder in Ablagen liegt, die nur sie noch durchschauen. Wer Wissen erst erschließt, wenn die Person weg ist, die es einordnen könnte, hat das Fenster verpasst.

Die zweite Herausforderung. Der bequeme Weg in die Cloud kostet Kontrolle

Die naheliegende Lösung liegt scheinbar auf der Hand. Die großen Cloud-Anbieter liefern KI-Dienste, die sich in wenigen Tagen anbinden lassen. Dokumente hochladen, API-Schlüssel erzeugen, fertig. Für unkritische Daten ist dagegen wenig einzuwenden. Niemand muss öffentlich verfügbare Produktbroschüren lokal verarbeiten. Das Problem beginnt dort, wo das Wissen vertraulich ist. Dazu gehören Verträge, Kalkulationen, Personalunterlagen, Konstruktionsdaten sowie Mandanten- oder Patientendaten. Wer diese Bestände in externe KI-Dienste gibt, schafft Abhängigkeiten auf drei Ebenen zugleich. Sie entstehen bei den Daten, beim Modell und bei der Infrastruktur. Jede dieser Abhängigkeiten ist für sich genommen beherrschbar. Zusammen ergeben sie einen Zustand, in dem das Unternehmen die Verfügungsgewalt über sein wertvollstes Wissen faktisch geteilt hat.

Wie ungleich diese Teilung ist, zeigt der Blick auf den europäischen Cloud-Markt. Nach Zahlen von Synergy Research erreichte er 2024 ein Volumen von rund 61 Milliarden Euro. Das ist das Sechsfache des Werts von 2017. Europäische Anbieter haben von diesem Wachstum kaum profitiert. Ihr Marktanteil fiel im selben Zeitraum von 29 auf etwa 15 Prozent und stagniert dort seit 2022. Amazon, Microsoft und Google vereinen rund 70 Prozent des europäischen Markts auf sich. Die größten europäischen Anbieter, SAP und die Deutsche Telekom, kommen auf jeweils etwa 2 Prozent. Die US-Hyperscaler investieren nach Synergy-Angaben Quartal für Quartal einen zweistelligen Milliardenbetrag in europäische Rechenzentren. Diesen Wettlauf holt auf der Infrastrukturebene niemand mehr auf. Im März 2025 forderten deshalb mehr als 100 europäische Organisationen in einem offenen Brief an die EU-Kommission mehr technologische Unabhängigkeit. Die Abhängigkeit von den Hyperscalern schaffe Sicherheits- und Verlässlichkeitsrisiken.

Zur wirtschaftlichen Abhängigkeit kommt die rechtliche. Ihre Geschichte beginnt 2013. Damals verlangten US-Ermittler von Microsoft die Herausgabe von E-Mails, die auf einem Server in Irland lagen. Microsoft weigerte sich. Ein US-Durchsuchungsbeschluss, so das Argument, reiche nicht über die Landesgrenze. Der Streit ging durch die Instanzen bis vor den Supreme Court und wurde dort nie entschieden. Im März 2018 verabschiedete der US-Kongress den Clarifying Lawful Overseas Use of Data Act, kurz CLOUD Act. Das Gesetz beantwortete die offene Frage. US-Anbieter müssen Daten auf behördliche Anordnung herausgeben, unabhängig davon, wo diese Daten physisch gespeichert sind (18 U.S.C. § 2713). Das Verfahren gegen Microsoft war damit gegenstandslos. Die Rechtslage ist seither eindeutig. Entscheidend ist nicht der Standort des Rechenzentrums, sondern die Jurisdiktion, der das Unternehmen unterliegt. Ein Server in Frankfurt, Magdeburg oder Mailand ändert daran nichts, wenn der Betreiber oder dessen Konzernmutter US-amerikanischem Recht untersteht.

Zwei Jahre später verschärfte der Europäische Gerichtshof die Lage aus der anderen Richtung. Im Schrems-II-Urteil vom Juli 2020 (C-311/18) erklärte er das Privacy-Shield-Abkommen für ungültig, weil US-Überwachungsgesetze kein gleichwertiges Schutzniveau gewährleisten. Das 2023 nachgeschobene EU-U.S. Data Privacy Framework hat den Datentransfer auf neue Füße gestellt. Es wird aber bereits juristisch angegriffen, und am CLOUD Act selbst ändert es nichts. Wie real der Konflikt ist, zeigte sich im Juni 2025 im französischen Senat. Dort räumte der Rechtsdirektor von Microsoft France unter Eid ein, das Unternehmen könne nicht garantieren, dass Daten französischer Bürger niemals ohne ausdrückliche französische Genehmigung an US-Behörden übermittelt werden. Ehrlicher lässt sich die Grenze vertraglicher Zusicherungen kaum benennen.

Für Entscheider in Compliance, Datenschutz und IT-Sicherheit ist das in unserer Erfahrung das präziseste Argument der gesamten Debatte. Es braucht keine Verschwörungstheorien und keine Anti-Amerika-Rhetorik. Es braucht nur eine nüchterne Feststellung. Die Postleitzahl des Rechenzentrums beantwortet die eigentliche Frage nicht. Wer vertrauliches Wissen in die Systeme eines US-Anbieters gibt, akzeptiert eine fremde Jurisdiktion über diese Daten. Daran ändern weder ein europäisches Rechenzentrum noch ein Zertifikat etwas.

Die Debatte hat inzwischen auch die europäische Politik erreicht. Der Draghi-Bericht zur Wettbewerbsfähigkeit Europas vom September 2024 benannte die technologische Abhängigkeit des Kontinents als strategisches Problem. Initiativen wie Gaia-X oder die 2025 formierte EuroStack-Bewegung arbeiten an europäischen Alternativen auf Infrastrukturebene. Wir beobachten das mit Sympathie und mit Nüchternheit. Bis solche Vorhaben Hyperscaler-Angebote ersetzen können, vergehen Jahre. Ein Unternehmen, das heute über KI für seine vertraulichen Daten entscheidet, kann darauf nicht warten. Es braucht einen Weg, der jetzt funktioniert und die eigene Handlungsfähigkeit sichert, unabhängig davon, wie die Infrastrukturdebatte ausgeht. Dieser Weg steht heute offen. Er führt über souveräne KI-Workloads in der eigenen Infrastruktur.

Warum eine C5-Zertifizierung nicht davor schützt

An dieser Stelle des Gesprächs fällt regelmäßig ein Einwand. „Aber der Anbieter ist doch C5-zertifiziert.“ Der Einwand verdient eine genaue Antwort. Er beruht auf einer Verwechslung, und das Marketing der großen Anbieter pflegt diese Verwechslung nach Kräften.

Der Cloud Computing Compliance Criteria Catalogue, kurz C5, ist ein Kriterienkatalog des Bundesamts für Sicherheit in der Informationstechnik. Das BSI hat ihn 2016 eingeführt und 2020 überarbeitet. Die aktuelle Fassung umfasst 121 Grundkriterien in 17 Bereichen. Sie reichen von der Organisation der Informationssicherheit über physische Sicherheit bis zum Umgang mit behördlichen Auskunftsersuchen. Ein C5-Testat bescheinigt, dass ein Wirtschaftsprüfer die Einhaltung dieser Kriterien geprüft hat. Das ist wertvoll. Wer einen Cloud-Dienst betreibt, sollte ein solches Testat vorweisen können. Für viele öffentliche Auftraggeber in Deutschland ist es faktisch eine Einkaufsvoraussetzung.

Nur beantwortet das Testat eine andere Frage als die, um die es hier geht. C5 prüft die Betriebssicherheit. Ist das Rechenzentrum ordentlich gesichert? Sind Zugriffe protokolliert? Funktioniert das Patch-Management? Welchem Recht der Betreiber unterliegt, prüft C5 nicht und kann es auch nicht prüfen. Ein US-Anbieter mit tadellosem C5-Testat bleibt ein US-Anbieter. Er unterliegt weiterhin dem CLOUD Act. Tatsächlich sind auch die ausdrücklich als „souverän“ vermarkteten Cloud-Angebote US-amerikanischer Hersteller C5-testiert. Das Testat trifft eine Aussage über Schlösser und Prozesse. Über staatliche Zugriffsrechte sagt es nichts.

In Gesprächen formulieren wir das zugespitzt. Ein Zertifikat über Betriebssicherheit schützt vor Einbrechern, nicht vor Gerichtsbeschlüssen. Wer beides verwechselt, wiegt sich in einer Sicherheit, die auf dem Papier gut aussieht und im Ernstfall nicht trägt. Für die Anbieterauswahl heißt das nicht, C5 zu ignorieren. Es heißt, C5 als notwendige, aber nicht hinreichende Bedingung zu lesen, sobald die Jurisdiktionsfrage im Raum steht.

Was souveräne KI bedeutet und was sie nicht bedeutet

Souveräne KI heißt für uns, dass KI-Systeme vollständig in der Infrastruktur des Kunden laufen. Das kann auf eigenen Servern sein, in einem eigenen Rechenzentrum oder in einer abgeschotteten Umgebung ohne Internetzugang. Wo es passt, kommt auch ein europäischer Cloud-Anbieter in Frage, der keiner Drittstaaten-Jurisdiktion unterliegt. Die Daten verlassen den Kontrollbereich des Unternehmens nicht. Die Modelle laufen dort, wo die Daten liegen, und nicht umgekehrt. Zudem bleibt jede Komponente der Architektur austauschbar, das Sprachmodell eingeschlossen. Kein Anbieter kann das Unternehmen festhalten. Das ist eine strategische Eigenschaft, keine technische Fußnote.

Ebenso wichtig ist uns die Abgrenzung, denn um den Begriff der Souveränität hat sich ein Markt gebildet, in dem sehr Verschiedenes unter demselben Etikett verkauft wird. Unser Liefergegenstand sind neue KI-Workloads. Sie entstehen bei unseren Kunden von vornherein dort, wo die Daten bleiben dürfen. Bestehende Cloud-Landschaften reißen wir dafür nicht ein. Das hält den Einstieg klein, das Risiko begrenzt und den Nutzen konkret. Zugleich lassen wir unsere Kunden mit der größeren Frage nicht allein. Wer über souveräne KI nachdenkt, denkt meist auch über souveräne IT insgesamt nach. Es geht dann um das ERP, um die Office-Umgebung und um den Schritt von der Public Cloud in eine private Cloud. In diesen Fragen beraten wir. Was das umfasst, beschreiben wir weiter unten in einem eigenen Abschnitt.

Diese Fokussierung hat einen zweiten Grund, über den wir offen sprechen. Das Jurisdiktions-Argument ist in vielen Organisationen der Türöffner. Mit ihm stimmen Datenschutzbeauftragte, CISO oder Betriebsrat einem KI-Vorhaben überhaupt erst zu. Aber ein Motiv ist keine Lösung. Niemand führt ein KI-System ein, um ein Compliance-Problem zu vermeiden. Man führt es ein, weil es Arbeit abnimmt. Die eigentliche Antwort auf die Souveränitätsfrage ist deshalb ein Nutzenversprechen und kein Infrastrukturprojekt. Vertrauliches Unternehmenswissen wird lokal durchsuchbar, analysierbar und automatisierbar. Die Souveränität ist die Bedingung, unter der das geschieht. Der Grund für das Projekt ist der Nutzen.

Ein dritter Punkt gehört zur Ehrlichkeit dazu. Lokale Modelle sind in den letzten zwei Jahren dramatisch besser geworden. Offene Modellfamilien wie Llama, Mistral oder Qwen erreichen heute bei vielen Aufgaben eine Qualität, die für den produktiven Einsatz in klar umrissenen Prozessen ausreicht. Den größten Cloud-Modellen sind sie aber nicht in jeder Disziplin ebenbürtig. Wer das behauptet, verkauft unseriös. Unsere Antwort darauf ist ein hybrides Vorgehen in der Aufbauphase. Wir beschreiben es weiter unten im Abschnitt zum Vorgehen. Solange keine sensiblen Daten im Spiel sind, misst ein Cloud-Modell die Qualität des lokalen Systems und hilft bei der Kalibrierung. Im Produktivbetrieb mit echten Daten arbeitet das System rein lokal.

Der Regulierungsrahmen 2026. DSGVO und AI Act

Neben dem CLOUD Act prägen zwei europäische Rechtsakte die Rahmenbedingungen für KI-Projekte mit sensiblen Daten. Beide sprechen aus unterschiedlichen Gründen für lokale Architekturen. Und beide lassen sich mit der richtigen Architektur von der Risikoliste streichen, statt sie jahrelang zu verwalten.

Der erste ist die DSGVO. Sobald personenbezogene Daten verarbeitet werden, greifen die Regeln zum Drittlandtransfer nach Art. 44 ff. Genau hier wird jede US-Cloud-Anbindung zur Dauerbaustelle. Angemessenheitsbeschlüsse können fallen, wie Schrems II gezeigt hat. Standardvertragsklauseln verlangen Transfer-Folgenabschätzungen. Die Aufsichtsbehörden prüfen zunehmend genau. Eine Architektur, in der personenbezogene Daten die eigene Infrastruktur gar nicht erst verlassen, macht diesen gesamten Problemkomplex gegenstandslos. Es gibt keinen Drittlandtransfer, den man rechtfertigen müsste. Bei Bußgeldern von bis zu 20 Millionen Euro oder 4 Prozent des weltweiten Jahresumsatzes ist das kein akademischer Vorteil. Es ist Risikovorsorge mit unmittelbarem Geschäftswert.

Der zweite ist der EU AI Act, die Verordnung (EU) 2024/1689. Sie ist seit dem 1. August 2024 in Kraft und das weltweit erste umfassende KI-Gesetz. Sie gilt gestaffelt, und der Zeitplan hat sich 2026 noch einmal verschoben. In vielen Unterlagen ist das noch nicht angekommen. Der Stand bei Veröffentlichung dieses Textes sieht so aus. Die Verbote inakzeptabler Praktiken und die KI-Kompetenzpflicht nach Artikel 4 gelten seit Februar 2025. Am 2. August 2026 werden die Transparenzpflichten nach Artikel 50 anwendbar. Wer Chatbots mit Kundenkontakt einsetzt oder KI-generierte Inhalte veröffentlicht, muss das offenlegen. Die umfangreichen Pflichten für eigenständige Hochrisiko-Systeme nach Anhang III wurden dagegen verschoben. Das Digital-Omnibus-Paket, im Mai 2026 politisch vereinbart und Ende Juni 2026 vom Rat bestätigt, verlegt sie vom August 2026 auf den 2. Dezember 2027. Für Hochrisiko-KI, die in Produkte eingebettet ist, gilt nun der 2. August 2028. Die Bußgeldrahmen bleiben erheblich. Bei verbotenen Praktiken drohen bis zu 35 Millionen Euro oder 7 Prozent des weltweiten Umsatzes.

Wichtig ist uns dabei eine Klarstellung. Der AI Act unterscheidet nicht danach, ob ein System lokal oder in der Cloud läuft. Wer ein Hochrisiko-System betreibt, trägt die Pflichten in beiden Fällen. Die Erfüllbarkeit der Pflichten unterscheidet sich aber deutlich. Risikomanagement, Daten-Governance, technische Dokumentation, Protokollierung und menschliche Aufsicht lassen sich in einer selbst betriebenen Umgebung vollständig nachweisen, weil jede Komponente unter eigener Kontrolle steht. Wer auf einen externen Dienst aufsetzt, dokumentiert dagegen eine Blackbox und haftet trotzdem. In unseren Assessments gehört ein DSGVO- und AI-Act-Readiness-Check deshalb von Anfang an zum Lieferumfang. Er ist keine Rechtsberatung, sondern eine technische Bestandsaufnahme. Sie zeigt, welche Pflichten das geplante System auslöst und wie die Architektur sie erfüllbar macht.

Unser Ansatz. Eine integrierte Lösung statt einzelner Werkzeuge

BKS-Lab ist kein allgemeiner KI-Dienstleister. Wir bauen keine Websites mit Chatbot, wir schulen keine Prompt-Techniken, und wir implementieren nicht das zwanzigste Copilot-Rollout. Wir sind ein spezialisiertes Team für lokale und selbstgehostete KI-Systeme. Alles, was wir tun, zahlt auf einen Kern ein. Vertrauliches Unternehmenswissen wird in der Infrastruktur des Kunden nutzbar. Unsere Kunden kaufen damit keine Technologieliste, sondern ein Ergebnis.

Technisch verbinden wir dafür Bausteine, die es einzeln längst gibt. Erst im Zusammenspiel ergeben sie eine brauchbare Lösung.

  • Volltext- und semantische Suche. Die klassische Stichwortsuche und die bedeutungsbasierte Suche über lokale Embeddings arbeiten in einem gemeinsamen Index.
  • Fuzzy Search. Fehlertolerantes Finden sorgt dafür, dass Tippfehler und abweichende Schreibweisen nicht ins Leere laufen.
  • Wissensmodellierung und Knowledge Graph. Dokumente werden nicht nur indexiert, sondern in ihren Beziehungen erfasst. Welcher Vertrag gehört zu welchem Kunden, welche Anlage zu welchem Vertrag?
  • Named Entity Recognition. Personen, Firmen, Beträge, Fristen und Fachbegriffe werden im Bestand automatisch erkannt.
  • Retrieval-Augmented Generation mit lokalen LLMs. Das Sprachmodell antwortet auf Grundlage der gefundenen Dokumente und belegt jede Antwort mit Quellenverweisen.
  • Kontrolliertes Staging. Inhalte durchlaufen einen geprüften Aufnahmeprozess, bevor sie für Suche und KI freigegeben werden.
  • Prozessautomatisierung. Aus Wissen wird Handlung, etwa durch Klassifizierung, Weiterleitung, Extraktion und Antwortentwürfe.

Der entscheidende Punkt ist das Wort „integriert“. Jede dieser Fähigkeiten gibt es als Einzelwerkzeug zu kaufen. Aber sieben Einzelwerkzeuge ergeben kein System. Sie ergeben sieben neue Silos mit sieben Administrationsoberflächen. Wir liefern die Bausteine als eine Engine mit einem gemeinsamen Datenmodell und einem gemeinsamen Berechtigungskonzept. Jeder Inhalt nimmt denselben Weg von der Rohdatei bis zur freigegebenen, durchsuchbaren Wissenseinheit. Am Ende steht eine Auskunft aus einem System mit einem Verantwortlichen.

Über allem stehen drei Prinzipien, an die wir uns in jedem Projekt halten. Erstens die Modell- und Infrastruktur-Agnostik. Das Sprachmodell ist bei uns eine austauschbare Komponente, die Umsetzung nicht. Der KI-Markt sortiert sich derzeit im Monatsrhythmus neu. Anbieter können vom Markt verschwinden, Lizenzmodelle können kippen. Die Architektur unserer Kunden darf davon nicht abhängen. Zweitens die hybride Validierung in der Aufbauphase bei rein lokalem Produktivbetrieb. Drittens das automatisierte Staging mit gezielter menschlicher Kontrolle statt manueller Prüfung jedes einzelnen Dokuments. Die beiden letzten Prinzipien beschreiben wir im Abschnitt zum Vorgehen genauer. Sie machen den Unterschied zwischen einem Demo-Piloten und einem belastbaren System aus.

Drei Kompetenzbereiche, ein Produktkern

Der Kern unserer Strategie ist nicht, möglichst viele KI-Themen gleichzeitig zu bedienen. Wir haben uns bewusst gegen das Bauchladen-Modell entschieden, mit dem viele Beratungen auf die KI-Welle reagiert haben. Stattdessen bündeln wir die Stärken des Teams in drei abgegrenzten Bereichen. Sie zahlen aufeinander ein, und einer von ihnen ist klar der Kern.

Bereich 01 · Knowledge Automation als Produktkern

Hier liegt das Zentrum unserer Arbeit. Vertrauliches Wissen wird lokal oder selbstgehostet erschlossen. Aus Dokumenten und Datenbeständen wird durchsuchbares, analysierbares und automatisierbares Wissen. Die Grundlage dafür ist die im vorigen Abschnitt beschriebene integrierte Engine. Alles andere, was wir tun, dient letztlich diesem Bereich. Er ist der Grund, warum es BKS-Lab gibt. Er ist auch die Basis des Produkts, das wir weiter unten vorstellen.

Bereich 02 · Self-Hosted LLM Enablement als Differenzierung

Der zweite Bereich beantwortet die Frage, die am häufigsten unterschätzt wird. Wie betreibt man ein Sprachmodell sinnvoll, sicher und wirtschaftlich selbst? Die Modellwahl ist dabei der kleinste Teil. Wir dimensionieren die Hardware so, dass sie zum tatsächlichen Bedarf passt und nicht zum Wunschdenken. Wir gestalten die Inferenz-Architektur und klären die Betriebsfragen danach, also Updates, Monitoring und Modellwechsel. Für jeden Use Case bewerten wir den richtigen Betriebsort. Das kann im eigenen Unternehmen sein, in einer abgeschotteten Air-Gap-Umgebung oder in einer souveränen EU-Cloud. Dieser Bereich ist keine eigene Produktlinie. Er ist die technologische Grundlage, auf der Bereich 01 überhaupt funktioniert. Für den Kunden bedeutet er vor allem Investitionssicherheit, weil Hardware, Modell und Architektur zum Geschäftszweck passen.

Bereich 03 · Quality & Automation als Delivery-Stärke

Der dritte Bereich ist der älteste. Test- und Prozessautomatisierung, CI/CD-Pipelines, Quality Gates und dokumentengetriebene Prozesse sind die Arbeit, aus der das Team kommt. Diese Stärke ist durch gelieferte Projekte belegt, etwa durch durchgängig automatisierte Peppol-Rechnungsflüsse. Im KI-Kontext bekommt sie neues Gewicht. Ein KI-System ohne systematische Qualitätssicherung ist ein Demo und kein Werkzeug. Die Disziplin, Qualität messbar zu machen und Prozesse ohne Medienbrüche zu automatisieren, macht aus einem Piloten ein produktives System.

Hinter den drei Bereichen steht die gebündelte Erfahrung eines kleinen, tiefen Teams. Dazu gehören lokale und selbstgehostete LLMs, KI-gestützte Software- und Produktentwicklung, Testautomatisierung, Prozessautomatisierung, Data Analytics, Requirements Engineering, Produktmanagement, Consulting, Projektmanagement, Wissensmanagement, Enterprise-Integration und Digitalisierung. Das klingt nach viel für vier Leute. Der Abschnitt zum Team erklärt, warum genau diese Breite bei genau dieser Größe funktioniert.

Souveräne IT über die KI hinaus

Die Souveränitätsfrage endet nicht bei der KI. Wer einmal angefangen hat, seine Abhängigkeiten zu sortieren, schaut schnell auf die gesamte IT-Landschaft. Auf das ERP-System, dessen Hersteller in die Cloud drängt. Auf die Office- und Collaboration-Umgebung, deren Daten längst außerhalb des Unternehmens liegen. Auf Workloads, die in den vergangenen Jahren in die Public Cloud gewandert sind und dort Jahr für Jahr teurer werden. Aus diesen Gesprächen ist ein eigenes Beratungsfeld entstanden. Wir begleiten Unternehmen strategisch auf dem Weg zu einer souveränen IT, über den einzelnen KI-Anwendungsfall hinaus.

Drei Themen kehren dabei regelmäßig wieder. Erstens das ERP. Viele Hersteller drängen ihre Kunden in Cloud-Abonnements, mit Lizenzdruck und auslaufendem Support für Versionen im eigenen Betrieb. Wir helfen bei der nüchternen Bewertung. Welche Daten dürfen in welche Betriebsform? Welche Alternativen gibt es, und wie sieht ein realistischer Fahrplan aus? Zweitens die Office- und Zusammenarbeitsumgebung. Hier prüfen wir, welche vertraulichen Inhalte in welchen Diensten liegen und wo europäische oder selbst betriebene Alternativen wirtschaftlich tragfähig sind. Drittens der Shift von der Public Cloud in die private Cloud. Für Workloads mit stabiler Last und sensiblen Daten rechnet sich der eigene Betrieb oft schon nach wenigen Jahren. Die gewonnene Kontrolle kommt hinzu.

Unsere Rolle ist dabei die des Beraters, nicht die des Generalunternehmers für Großmigrationen. Wir analysieren, bewerten und priorisieren, erstellen Zielbilder und begleiten die Umsetzung dort, wo unsere technische Tiefe den Unterschied macht. Der Nutzen liegt in einer Strategie aus einem Guss. KI-Vorhaben, ERP-Entscheidung und Cloud-Strategie folgen denselben Souveränitätskriterien, statt sich zu widersprechen. Unsere Erfahrung aus Enterprise-Integration, Prozessautomatisierung und Selbstbetrieb liefert dafür die Grundlage.

Ein Blick in die Werkstatt. Was lokale KI heute kann

Wer vor zwei oder drei Jahren zuletzt auf lokale Sprachmodelle geschaut hat, unterschätzt fast zwangsläufig, was heute möglich ist. Seit Meta 2023 mit der Llama-Familie begonnen hat, leistungsfähige Modelle mit offenen Gewichten zu veröffentlichen, hat sich ein breites Feld entwickelt. Das Pariser Unternehmen Mistral AI, ebenfalls 2023 gegründet, liefert offene Modelle aus Europa. Alibabas Qwen-Familie gehört in vielen unabhängigen Vergleichen zu den stärksten offenen Modellen überhaupt. Offene Gewichte bedeuten, dass das Modell als Datei geliefert wird und vollständig auf eigener Hardware läuft. Es gibt keinen API-Aufruf, keinen Datenabfluss und keine Abhängigkeit von der Preispolitik eines Anbieters. Strategisch ist das der entscheidende Punkt. Das Unternehmen besitzt seine KI-Fähigkeit, statt sie zu mieten.

Auch wirtschaftlich hat sich die Lage zugunsten des Selbstbetriebs entwickelt. Moderne Verfahren senken den Rechenbedarf der Modelle bei geringem Qualitätsverlust. Mittelgroße Modelle laufen dadurch heute auf einer einzelnen Workstation mit leistungsfähiger Grafikkarte. Für viele Unternehmens-Use-Cases genügt Hardware im Wert eines fünfstelligen Betrags. Sie wird einmal angeschafft, während Cloud-Kosten mit der Nutzung immer weiter wachsen. Wo höhere Last oder größere Modelle gebraucht werden, wächst das Setup auf dedizierte Server mit. Welche Konfiguration wirtschaftlich ist, hängt vom Prozess ab. Genau deshalb gehört die Modell- und Hardwarebewertung bei uns zu jedem Pilotprojekt.

Ein weit verbreitetes Missverständnis wollen wir dabei ausräumen. Ein lokales System muss das große Cloud-Modell nicht schlagen, um nützlich zu sein. Es muss die konkrete Aufgabe zuverlässig erfüllen. Für die Klassifikation eingehender Post, die Extraktion von Rechnungsfeldern oder die Beantwortung von Fragen zu einem definierten Dokumentenbestand braucht es kein Modell, das auch Gedichte schreiben kann. Es braucht ein Modell, das die eine Aufgabe messbar gut erledigt. Dazu gehört ein System, das Suche, Kontext und Quellenverweise beisteuert. Die Architektur macht hier mehr Unterschied als die reine Modellgröße. Ein mittleres Modell mit sauberem Zugriff auf die relevanten Dokumente schlägt in umgrenzten Aufgaben regelmäßig ein großes Modell ohne diesen Zugriff.

Beim Deployment kennen wir drei Grundmuster. On-Premise auf Servern im eigenen Unternehmen ist der Normalfall. Abgeschottete Umgebungen ganz ohne Internetverbindung setzen wir dort um, wo die Schutzanforderungen es verlangen. Das System wird dann samt Modellen und Updates über kontrollierte Wege versorgt. Wo eigene Hardware nicht infrage kommt, bleibt der Betrieb bei einem europäischen Anbieter, der ausschließlich europäischem Recht unterliegt, eine tragfähige Lösung. Alle drei Varianten folgen derselben Architektur. Der Wechsel zwischen ihnen ist eine Betriebsentscheidung und kein Neubau.

Unsere Leistungen. Ein modularer Pfad, kein Katalog

Viele Beratungshäuser führen ein Dutzend unabhängiger KI-Angebote im Portfolio. Wir haben uns bewusst dagegen entschieden. Was wir anbieten, ist ein Kundenpfad mit aufeinander aufbauenden Stufen. Am Anfang steht die Orientierung, dann folgt die fokussierte Validierung, am Ende die Produktivsetzung. Kein Kunde muss alle Stufen durchlaufen, und niemand muss in einer festen Reihenfolge einsteigen. Aber jede Stufe erzeugt genau die Entscheidungsgrundlage, die die nächste braucht. Das unterscheidet einen Pfad von einem Katalog. Am Ende jeder Stufe wissen Sie, ob und wie es weitergeht.

Der Einstieg. Sovereign AI Starter

Der einfachste Einstieg in die Zusammenarbeit ist der Sovereign AI Starter. Nach außen ist er ein Angebot. Intern besteht er aus zwei Teilen, und genau darin liegt sein Nutzen für Sie. Teil eins ist ein Readiness-Check von rund zwei Wochen. Wir nehmen Ihren Use Case auf, sichten die Daten- und Systemlandschaft und prüfen, was wirklich geht. Teil zwei ist eine klar abgegrenzte Umsetzung von rund vier bis sechs Wochen. Den Festpreis dafür legen wir erst nach dem Readiness-Check fest. Zwischen beiden Teilen liegt ein vertraglicher Ausstiegspunkt. So bleibt Ihr Risiko von Anfang an überschaubar.

Warum dieser Aufbau? Weil das größte Risiko in frühen KI-Projekten das Scope-Risiko ist, und zwar auf beiden Seiten. Ein Anbieter, der Ihnen vor jeder Analyse einen Festpreis nennt, hat entweder viel Puffer eingepreist oder verhandelt später nach. Wir haben beides erlebt und wollten beides nicht. Der Ausstiegspunkt schützt Sie. Trägt Ihr Use Case nicht, reicht die Datenlage nicht oder liegen die Erwartungen auseinander, endet das Engagement an dieser Stelle. Sie behalten einen verwertbaren Ergebnisbericht statt eines halbfertigen Projekts.

Stufe 01. Sovereign AI Assessment

Das Assessment richtet sich an Unternehmen, die KI nutzen wollen, aber zuerst Datenkontrolle, Datenschutz, Cloud-Abhängigkeit oder die technische Umsetzbarkeit klären müssen. Es ist ein Beratungsprodukt mit Festpreis. Es liefert eine Entscheidungsgrundlage, keine Software. Wir erarbeiten die Use-Case-Aufnahme, eine Übersicht der Daten- und Systemlandschaft und eine Bewertung der Souveränitätsrisiken. Dazu kommt ein strukturierter Vergleich zwischen Cloud- und Self-Hosted-Varianten, eine technische Zielarchitektur sowie ein Pilotvorschlag mit Roadmap. Seit 2025 gehört ein DSGVO- und AI-Act-Readiness-Check dazu. Er bricht die genannten Fristen auf Ihren konkreten Anwendungsfall herunter.

Das Assessment beantwortet die Frage, an der die meisten KI-Vorhaben scheitern, bevor sie beginnen. Lohnt sich das überhaupt, und wenn ja, wo genau? Nicht jeder Use Case rechtfertigt ein lokales LLM. Manche Prozesse sind mit klassischer Volltextsuche besser bedient. Manche Datenbestände sind schlicht nicht souveränitätskritisch. Auch das ist ein Ergebnis, und wir sprechen es offen aus.

Stufe 02·A. Sovereign Knowledge Base Pilot

Der Knowledge Base Pilot ist unser wichtigstes Pilotangebot und der bevorzugte Weg zu unserem Produktkern. Ein begrenzter, gemeinsam ausgewählter Dokumentenbestand wird lokal oder selbstgehostet nutzbar gemacht. Das können die Verträge einer Abteilung sein, ein technisches Archiv oder ein Bestand an Prüfberichten. Zum Lieferumfang gehören der Volltextindex, semantische Suche und Fuzzy Search, lokal berechnete Embeddings, eine erste Entity-Erkennung, durchgängige Quellenverweise sowie eine Chat- und Analysefunktion über den Bestand.

Zwei Dinge sind uns dabei wichtig. Das Erste sind die Quellenverweise. Jede Antwort des Systems verweist auf die Dokumente und Passagen, aus denen sie stammt. Ein System, dessen Antworten man nicht nachprüfen kann, ist für den Unternehmenseinsatz wertlos, egal wie flüssig die Antworten klingen. Das Zweite ist die Messbarkeit. Wir legen vor dem Piloten fest, woran Such- und Antwortqualität gemessen werden. Am Ende liefern wir Zahlen statt Eindrücke.

Stufe 02·B. Local LLM und Automation Pilot

Nicht jeder Anwendungsfall ist eine Wissensdatenbank. Im zweiten Pilotformat übernimmt ein lokales oder selbstgehostetes LLM einen konkreten Prozess. Das reicht von der Dokumentenanalyse über Support-Szenarien bis zur Vertragsprüfung. Wir wählen Modell und Hardware passend zum Prozess aus, übernehmen das Deployment und integrieren das System in einen Beispielprozess. Test- und Ausgabequalität bewerten wir systematisch. Dazu kommen ein Sicherheits- und Betriebskonzept sowie eine Entscheidungsvorlage. Mit ihr können Sie intern begründen, ob und wie der Prozess produktiv gehen soll.

Stufe 03. Produktivsetzung und Betrieb

Ein erfolgreich validierter Pilot ist noch kein System für den Alltag. In der dritten Stufe härten wir ihn zu einer belastbaren, integrierten und betreibbaren Lösung. Dazu gehören die technische Härtung und Integration in Ihre Systemlandschaft, ein Rollen-, Sicherheits- und Betriebskonzept, dokumentierte Qualitäts- und Akzeptanznachweise sowie ein Update-, Monitoring- und Supportmodell. Auf Wunsch übernehmen wir den Übergang in Wartung oder Managed Service. Diese Stufe ist bewusst als Verstetigung angelegt. Hier entsteht die langfristige Zusammenarbeit, und hier zeigt sich, ob eine Lösung im echten Betrieb hält, was der Pilot versprochen hat.

Aufwände und Angebote stimmen wir individuell auf Ihren Use Case ab. Die genannten Zeiträume sind Erfahrungswerte aus bisherigen Projekten, keine Pauschalen. Wer einen konkreten Rahmen braucht, bekommt ihn im Gespräch und nicht aus einer Preisliste, die Ihren Fall nicht kennt.

Wie wir liefern. Vorgehen und Qualitätssicherung

Ein Team unserer Größe kann sich weder lange Irrwege noch späte Überraschungen leisten. Unser Vorgehen ist deshalb auf zwei Dinge ausgelegt. Wir machen Fehlannahmen so früh wie möglich sichtbar. Und wir prüfen jedes Projektergebnis darauf, ob es wiederverwendbar ist. Beides klingt selbstverständlich. In der Praxis der Branche wird beides erstaunlich selten diszipliniert betrieben. Für Sie bedeutet dieser Ansatz vor allem Planbarkeit.

Agile Validierungszyklen statt Projektende-Überraschung

Wir lernen nicht erst am Projektende, ob eine Lösung trägt. Jeder abgegrenzte Delivery-Zyklus folgt demselben kurzen Muster.

  1. Kundenproblem und Lernziel präzisieren
  2. Requirements und Lösungshypothese festlegen
  3. Kleinstmöglichen Prototyp oder nutzbaren Inkrementstand erstellen
  4. Nutzen, Qualität, Machbarkeit und Souveränität validieren
  5. Kunden- und Nutzungsfeedback auswerten
  6. Über Fortführung, Anpassung, Skalierung oder Stopp entscheiden
  7. Wiederverwendbare Ergebnisse durch das Productization (Production-Ready) Gate führen

Der wichtigste Punkt in dieser Liste ist der sechste. Ein Zyklus darf mit der Entscheidung enden, ein Vorhaben zu stoppen. Das ist kein Scheitern, sondern der Zweck der Übung. Ein nach vier Wochen gestoppter Pilot kostet einen Bruchteil eines nach vierzehn Monaten gescheiterten Projekts. Diese Ehrlichkeit spart Ihnen Geld und schützt Ihre interne Glaubwürdigkeit.

Automatisiertes Staging mit Human-in-the-loop

Bevor ein Dokument in einem produktiven Index landet, durchläuft es bei uns eine kontrollierte Aufbereitungsstrecke. Erkennung, Extraktion, Klassifikation und Entity-Erkennung laufen automatisch. Dasselbe gilt für Qualitäts-, Plausibilitäts- und Confidence-Prüfungen. Nur Ergebnisse mit geringer Konfidenz, Widersprüchen oder besonderer Kritikalität gehen an einen Menschen. Alles andere läuft durch. Wir nennen das automatisiert-first. Das ist weder die manuelle Prüfung jedes Dokuments noch blindes Vertrauen in die Maschine. Am Ende steht ein auditierbarer Weg von den Rohdaten bis zur produktiven Nutzung. Für jedes Dokument lässt sich nachvollziehen, wann es aufbereitet, geprüft und freigegeben wurde. Genau diese Nachvollziehbarkeit brauchen Sie, wenn eine Aufsichtsbehörde oder ein wichtiger Kunde nachfragt.

Hybride LLM-Systeme als Qualitätsstandard

Am häufigsten hören wir eine Frage. Ist ein lokales Modell gut genug? Unsere Antwort ist ein Messverfahren, keine Meinung. In der Aufbauphase einer Lösung verarbeiten wir noch keine sensiblen Daten. In dieser Phase setzen wir ein cloudbasiertes Frontier-Modell als Schiedsrichter ein. Es bewertet die Ausgaben des lokalen Modells, deckt systematische Schwächen auf und kalibriert die Qualitätsmetriken. So entsteht ein belastbares Bild davon, wo das lokale System steht und wo nachgesteuert werden muss. Im Produktivbetrieb mit sensiblen Daten arbeitet das System dann rein lokal oder selbstgehostet. Das Cloud-Modell hat seine Aufgabe dann erfüllt und verschwindet aus der Architektur. Sensible Daten haben die Infrastruktur des Kunden zu keinem Zeitpunkt verlassen.

Standardisierte Artefakte in jedem Projekt

Jedes unserer Projekte arbeitet mit denselben standardisierten Artefakten. Dazu gehören Discovery-Fragebogen und Use-Case-Canvas, Datenklassifikationsbogen, Architekturtemplate und ein Security-und-Sovereignty-Check. Dazu kommen Scope-Dokument, Akzeptanzkriterien, Testplan, Risiko- und Entscheidungslog und Abschlussbericht. Das klingt nach Bürokratie und ist das Gegenteil davon. Weil die Struktur steht, verhandeln wir nicht in jedem Projekt neu, wie ein Statusbericht aussieht. Die Zeit fließt in Inhalte statt in Form. Für Sie hat das einen handfesten Nebeneffekt. Ergebnisse aus verschiedenen Projektphasen bleiben vergleichbar. Und Entscheidungen sind Monate später noch nachvollziehbar.

AI-native. Wir arbeiten selbst so, wie wir bauen

Unsere interne Arbeit ist gelebte Anwendung der eigenen Strategie. Meeting-Zusammenfassungen, Requirements-Extraktion, Testfallgenerierung, Code-Reviews, Dokumentations- und Angebotsentwürfe, Recherche, Wissensindexierung und Projektstatus-Analysen laufen bei uns KI-gestützt. Wir nutzen dieselben Werkzeugklassen, die wir Kunden empfehlen. Das hat zwei Effekte. Der offensichtliche ist Effizienz. Ein Vier-Personen-Team liefert damit ein Volumen, für das klassisch ein Vielfaches an Personal nötig wäre. Der wichtigere Effekt ist der Praxistest. Wir spüren die Schwächen unserer eigenen Werkzeuge vor unseren Kunden, weil wir täglich damit arbeiten.

Das Productization Gate

Kundenprojekte werden bei uns nicht automatisch zu Produkten. Aber auch nicht zufällig. Am Ende jedes relevanten Meilensteins entscheidet ein formales Gate über den weiteren Weg eines Ergebnisses. Es kann in den Produktkern übergehen, als wiederverwendbarer Baustein abgelegt werden, ein kundenspezifisches Artefakt bleiben oder bewusst nicht weitergeführt werden. Dahinter steht eine klare Kette. Aus einem validierten Kundenproblem wird ein generalisierbares Lösungsmuster. Daraus wird ein qualifizierter Produktbaustein. Und daraus wird über mehrere Projekte hinweg echte Produktfunktionalität. Diese Disziplin ist der Grund, warum unser Produkt aus gelieferten Projekten entstanden ist und nicht aus einem Pitch-Deck.

Aus der Praxis. Drei gelieferte Projekte

Versprechen kann jeder. Deshalb an dieser Stelle drei Projekte, die wir tatsächlich geliefert haben. Sie sind anonymisiert, weil unsere Kunden das so wünschen. Konkret genug sind sie trotzdem, um den Zuschnitt unserer Arbeit zu zeigen.

Für ein führendes Job-Portal haben wir den Rechnungsprozess durchgängig automatisiert. Peppol-Eingang und -Ausgang, ERP-Integration und Archivierung laufen end-to-end und ohne Medienbrüche. Das Projekt zeigt unsere Delivery-Stärke jenseits der reinen KI-Themen. Elektronische Rechnungsflüsse sind ein dokumentengetriebener Prozess wie aus dem Lehrbuch. Genau auf solchen Strecken übersetzt sich Automatisierung unmittelbar in eingesparte Arbeitsstunden. Seit der E-Rechnungspflicht für inländische B2B-Umsätze, die in Deutschland ab Januar 2025 stufenweise greift, ist das zudem kein freiwilliges Modernisierungsthema mehr.

Für ein europäisches Verkehrsunternehmen haben wir CI/CD-Pipelines mit Testautomatisierung und Quality Gates aufgebaut und integriert. Der Fokus lag auf hoher Codequalität in einer gewachsenen Systemlandschaft. Solche Projekte sind die Schule, aus der unsere Qualitätsdisziplin stammt. Wer Quality Gates für fremde Entwicklungsteams baut, lernt Qualität messbar zu machen statt sie zu behaupten. Diese Haltung übertragen wir eins zu eins auf die Bewertung von LLM-Ausgaben.

Für ein führendes Verlagshaus haben wir einen MVP zur KI-gestützten Klassifizierung eingehender Post entwickelt. Eingehende E-Mails werden mit NLP und lokalen Modellen klassifiziert und der Bearbeitung zugeführt. Das Projekt zeigt den Kern unseres Ansatzes im Kleinen. Ein begrenzter, klar messbarer Prozess. Lokale Modelle statt Cloud-Abfluss. Und ein MVP-Zuschnitt, der eine Entscheidungsgrundlage liefert, bevor größer investiert wird.

Was diese Projekte verbindet, ist kein gemeinsames Werkzeug, sondern ein gemeinsames Muster. In allen drei Fällen ging es um dokumentengetriebene Prozesse. Bisher trugen dort Menschen Informationen von einem System ins nächste. In allen drei Fällen war der Zuschnitt eng genug, um das Ergebnis zu messen. Durchlaufzeit, Fehlerquote, Klassifikationsgüte. Und in allen drei Fällen entstanden Bausteine, die wir über unser Production-Ready Gate weiterverwendet haben. Der Peppol-Baustein aus dem Rechnungsprojekt, die Pipeline-Muster aus dem Verkehrsprojekt und die Klassifikationslogik aus dem Verlagsprojekt fließen heute in die Sovereign Knowledge Engine ein.

Fünf Einwände, die wir ernst nehmen

In fast jedem Entscheidungsprozess begegnen uns dieselben Einwände. Wir halten sie für berechtigt. An ihnen entscheidet sich, ob ein souveränes KI-Projekt trägt. Deshalb beantworten wir sie hier so, wie wir sie auch im Gespräch beantworten.

„Das ist doch teurer als ein Cloud-Abo.“ In der Anschaffung stimmt das. Ein Cloud-Dienst kostet am ersten Tag ein paar hundert Euro im Monat, ein eigener Inferenz-Server einen fünfstelligen Betrag. Über die Laufzeit dreht sich die Rechnung. Cloud-KI wird pro Nutzung abgerechnet. Wer einen Dokumentenprozess mit zehntausenden Vorgängen im Monat automatisiert, zahlt dauerhaft und volumenabhängig. Eigene Hardware ist gekauft und rechnet sich über Jahre. Die laufenden Kosten bestehen im Wesentlichen aus Strom und Wartung. Dazu kommt ein Posten, der in keinem Preisvergleich auftaucht. Was kostet es, wenn vertrauliche Daten in einer fremden Jurisdiktion liegen und Sie das eines Tages erklären müssen? Ihrem Aufsichtsrat, Ihrer Aufsichtsbehörde oder Ihrem wichtigsten Kunden.

„Lokale Modelle sind schlechter als GPT und Co.“ In der Breite stimmt das, und wir sagen das auch so. Nur ist die Breite nicht der Maßstab. Ein Unternehmensprozess braucht kein Modell, das Gedichte schreibt und Physikaufgaben löst. Er braucht ein Modell, das die immer gleiche, klar umrissene Aufgabe zuverlässig erledigt. Genau dafür messen wir in jedem Piloten die Qualität am konkreten Korpus, mit dem hybriden Verfahren von oben. Wenn die Qualität nicht reicht, sagen wir das. Und zwar vor der Produktivsetzung, nicht danach.

„Unsere IT hat dafür keine Kapazität.“ Das hören wir oft. Es ist der Grund, warum die Stufe der Produktivsetzung ein eigenes Update-, Monitoring- und Supportmodell enthält. Ein souveränes System, das nach dem Projektende niemand betreibt, ist keine Souveränität, sondern ein Risiko. Deshalb übernehmen wir auf Wunsch den Betrieb als Managed Service. Die Daten bleiben dabei in Ihrer Infrastruktur. Wir kümmern uns um Updates, Modellpflege und Überwachung. Ihre IT muss das System nicht bauen und nicht allein tragen.

„Was ist, wenn der Modellanbieter morgen verschwindet?“ Diese Frage ist berechtigter, als viele denken. Der KI-Markt konsolidiert sich. Einzelne Anbieter werden verschwinden oder ihre Lizenzbedingungen ändern. Unsere Antwort ist architektonisch. Ein einmal heruntergeladenes offenes Modell läuft weiter, egal was mit seinem Hersteller geschieht. Weil unsere Systeme modell-agnostisch geschnitten sind, ist der Wechsel auf ein anderes Modell ein Austausch, kein Neubau. Das unterscheidet die Lage grundlegend von der Abhängigkeit von einem API-Anbieter, dessen Abschaltung ein System sofort stilllegt.

„Wir wissen gar nicht, wo wir anfangen sollen.“ Das ist der häufigste Einwand und der am leichtesten auflösbare. Niemand muss mit einer Unternehmensstrategie beginnen. Der Einstieg, den wir empfehlen, ist ein einzelner, klar abgegrenzter Use Case. Ein begrenzter Dokumentenkorpus und ein erreichbarer Entscheider genügen. Genau dafür haben wir den Sovereign AI Starter gebaut. Zwei Wochen Readiness-Check, dann eine überschaubare Umsetzung. Mehr braucht es nicht, um belastbar zu wissen, ob der Weg für Ihr Unternehmen trägt.

Das Produkt. BKS Sovereign Knowledge Engine

Aus den validierten Bausteinen unserer Projekte produktisieren wir schrittweise eine eigene Engine, die BKS Sovereign Knowledge Engine. Sie ist installierbar und läuft lokal oder auf Ihren Unternehmensservern. Sie indexiert Dokumente und Datenbestände out-of-the-box, durchsucht und erschließt sie semantisch und macht sie mit lokalen LLMs nutzbar.

Ein Missverständnis wollen wir gleich ausräumen. Die Engine ist kein weiteres Wiki, kein Chatbot und kein Dokumentenmanagementsystem. Sie ist eine Wissens- und Automatisierungsschicht über den Informationen, die Sie bereits haben. Ihre Dokumente bleiben, wo sie sind. Die Engine erschließt sie, statt ein weiteres Silo zu schaffen. Dieser Charakter bleibt in allen Ausbaustufen gleich. Souverän betreibbar, herstellerunabhängig auf Modell- und Infrastrukturebene, aus wiederverwendbaren Bausteinen gebaut.

Der MVP-Zuschnitt. Bewusst klein, sofort nützlich

Der erste nutzbare Stand der Engine umfasst folgende Funktionen.

  • Import lokaler Ordner mit Unterstützung für PDF, Office-Formate, Markdown und Text
  • Volltextsuche, semantische Suche und Fuzzy Search über den gesamten Bestand
  • Lokal berechnete Embeddings und Named Entity Recognition
  • Quellenanzeige für jede Antwort und jeden Treffer
  • Lokaler Chat über die eigenen Dokumente, per Web- oder Desktop-Oberfläche
  • API für Integrationen sowie Export- und Backup-Funktion

Genauso bewusst ist die Liste dessen, was der MVP nicht enthält. Dazu zählen vollständige Mandantenfähigkeit, ein Enterprise-Rollenmodell, tiefe SharePoint- oder Confluence-Integration, komplexe Knowledge-Graph-Visualisierung, eine umfangreiche Workflow-Engine, ein App-Marketplace oder gar eine allgemeine No-Code-Plattform. All das gehört in spätere Versionen. Fokus heißt Weglassen. Wir schreiben lieber auf, was fehlt, als es in einer Demo zu verstecken. Wer je ein Produkt gekauft hat, dessen Roadmap-Folien mehr konnten als die Software, weiß, warum uns das wichtig ist.

Der Wissenslebenszyklus. Auditierbar von Rohdaten bis zur Nutzung

Was die Engine von Ansätzen unterscheidet, die Dokumente ohne kontrollierten Lebenszyklus unmittelbar in einen Index kippen, ist der Weg, den jedes Dokument nimmt. Erkennung, Klassifikation und Entity-Extraktion laufen automatisch. Unsichere Ergebnisse werden markiert und gezielt menschlich geprüft. Erst freigegebene Inhalte stehen für Suche, RAG und Automatisierung bereit. Für regulierte Branchen ist dieser auditierbare Lebenszyklus kein Nice-to-have, sondern die Voraussetzung, um ein solches System überhaupt einführen zu dürfen. Für alle anderen ist er der Unterschied zwischen einem Index, dem man vertraut, und einem, den man nach dem dritten falschen Treffer nicht mehr benutzt.

Reifegrad. Aus Piloten zu Version 1.0

Wir vermarkten die Engine nicht als fertiges Enterprise-Produkt, denn das wäre gelogen. Der Reifegradpfad ist öffentlich Teil unserer Strategie. Er führt von der MVP-Demo über erste echte Piloten und daraus extrahierte wiederverwendbare Komponenten bis zum Kandidaten für Version 1.0. Jeder Pilot im Rahmen unserer Leistungsstufe 02·A zahlt auf diesen Pfad ein. Die Kunden der frühen Phasen bekommen dafür überproportional viel Gestaltungseinfluss und Konditionen, die es später nicht mehr geben wird. Wer die Engine am eigenen Korpus sehen will, startet genau dort. Wir indexieren einen begrenzten Dokumentenbestand und messen gemeinsam Such- und Antwortqualität.

Woran wir gerade schreiben

Ein Teil unserer Arbeit ist das Aufschreiben. Nicht aus Marketinggründen, sondern weil das Formulieren die Gedanken schärft. Und weil die Fragen, die uns Kunden stellen, oft bessere Artikel ergeben als jede Redaktionsplanung. Auf unserer Website erscheint dazu die Insights-Reihe mit kurzen, sachlichen Beiträgen aus der Projektpraxis. Den Anfang hat im Juli 2026 ein Beitrag gemacht, dessen Kernargument auch diesen Text trägt. Die Jurisdiktion zählt, nicht die Postleitzahl.

Drei weitere Beiträge sind in Vorbereitung. Ihre Themen zeigen ganz gut, womit wir uns täglich beschäftigen. Der erste erklärt, warum lokale Knowledge Automation kein besseres Wiki ist. Kontrolliertes Staging, Entity-Erkennung und RAG unterscheiden eine Wissens-Engine von einer Volltextsuche mit Chat-Fenster. Der zweite beschreibt die Architektur hybrider LLM-Systeme. Wie kalibriert ein Cloud-Frontier-Modell die Qualität eines lokalen Modells, ohne dass sensible Daten je die eigene Infrastruktur verlassen? Der dritte handelt von uns selbst. Warum ein sehr kleines, hoch automatisiertes Team im KI-Zeitalter einen Struktur- und Kostenvorteil hat. Zu diesem letzten Punkt gleich mehr.

Das Team. Klein bleiben als Strategie

BKS-Lab ist bewusst kein großes Beratungs- oder Softwarehaus. Wir sind ein sehr kleines, hoch spezialisiertes Technologieunternehmen mit vier Köpfen. Das ist keine Verlegenheit, aus der wir herauswachsen wollen, sondern eine strategische Festlegung. Wir halten die geringe Größe im KI-Zeitalter für einen Struktur- und Kostenvorteil. Intern haben wir sie als Prinzip festgeschrieben. BKS bleibt klein.

Michael Boiman verantwortet als CTO und Principal Engineer die technische Gesamtarchitektur, lokale LLMs und Self-Hosted-Setups sowie die Kernentwicklung. Er übersetzt Kundenanforderungen in wiederverwendbare Architektur- und Code-Bausteine. Aus diesen Bausteinen wächst über das Productization Gate unser Produkt.

Axel von Dielingen ist die Brücke zwischen Markt, Kunden, Produkt und Umsetzung. Als Product und Delivery Lead verantwortet er Produktmanagement, Angebotsstrukturierung, Consulting und Projektmanagement. Seine Aufgabe lässt sich in einem Satz fassen. Aus Kundenproblemen macht er wiederverwendbare Produktmodule.

Michael Kupermann führt Marktentwicklung, Vertrieb und Positionierung. Er fokussiert die Vertriebsarbeit auf Kunden, deren Problem tatsächlich zu unserem Kern passt, also vertrauliches Wissen, lokale KI und Datenkontrolle. Interessenten mit anderen Problemen sagt er lieber früh ab, als Projekte anzunehmen, die nicht zu uns gehören. Als TÜV-Nord-zertifizierter Datenschutzbeauftragter bringt er zudem die Datenschutzperspektive von innen mit.

Lior Boiman führt als Geschäftsführer die kaufmännische Seite und verantwortet Requirements Engineering und fachliches Solution Design. Er verbindet Kundenproblem, Produktanforderung und Wirtschaftlichkeit. Er ist die Instanz, die dafür sorgt, dass technisch Elegantes auch ökonomisch trägt.

Warum wir das Kleinbleiben für einen Vorteil halten, lässt sich an unserer Arbeitsweise ablesen. Wir wachsen nicht über Headcount, sondern über KI-Unterstützung in der eigenen Arbeit, über wiederverwendbare Bausteine und über einen fokussierten Produktkern. Kurze Entscheidungswege, geringe Fixkosten, hohe technische Tiefe, direkte Kundennähe und schnelle Prototypen sind die Folge dieser Struktur, nicht ihr Marketingversprechen. Für Kunden heißt das etwas sehr Konkretes. Die Person, die im Erstgespräch sitzt, ist dieselbe, die später die Architektur verantwortet. Eine Übergabe vom Vertrieb an ein Delivery-Team, das den Fall zum ersten Mal sieht, gibt es bei uns nicht.

Fazit. Souveränität ist machbar, wenn man klein anfängt

Fassen wir zusammen. Das wertvollste Wissen der meisten Unternehmen liegt verstreut in Dokumenten, Postfächern und Fachanwendungen. Dort ist es weder auffindbar noch automatisiert nutzbar. Der bequemste Ausweg ist externe Cloud-KI. Er schafft neue Abhängigkeiten und wirft eine Jurisdiktionsfrage auf, die weder ein deutsches Rechenzentrum noch ein C5-Testat beantwortet. US-Anbieter unterliegen dem CLOUD Act, unabhängig davon, wo ihre Server stehen. Gleichzeitig sind lokale Modelle so gut geworden, dass souveräne KI für klar umrissene Prozesse keine Kompromisslösung mehr ist. Sie ist eine belastbare Architekturentscheidung.

Unsere Antwort darauf ist kein Großprojekt. Es ist ein Pfad aus kleinen, einzeln absicherbaren Schritten. Ein Readiness-Check von rund zwei Wochen, eine abgegrenzte Umsetzung von vier bis sechs Wochen, mit vertraglichem Ausstiegspunkt dazwischen. Wer danach weitergehen will, dem stehen die Pilotformate und die Produktivsetzung offen. Wer nicht, hat für überschaubares Geld Klarheit gewonnen. Auch das ist ein Ergebnis.

Wenn Sie aus diesem langen Text nur drei Dinge mitnehmen, dann diese. Erstens, stellen Sie bei jedem KI-Angebot die Jurisdiktionsfrage, nicht die Standortfrage. Fragen Sie nicht, wo die Server stehen, sondern welchem Recht der Betreiber unterliegt und wer ihn zur Herausgabe verpflichten kann. Die Antwort auf diese eine Frage sortiert den Anbietermarkt schneller als jeder Kriterienkatalog. Zweitens, unterschätzen Sie lokale Modelle nicht anhand von Schlagzeilen über die jeweils neuesten Cloud-Modelle. Für den klar umrissenen Unternehmensprozess, also Dokumente finden, klassifizieren, extrahieren und zusammenfassen, ist die Qualität offener Modelle heute messbar ausreichend. Messen lässt sie sich vor jeder Investitionsentscheidung. Drittens, fangen Sie klein an, aber fangen Sie mit einem echten Korpus an. Ein Pilot mit zwanzig Testdokumenten beweist nichts. Ein abgegrenzter, aber realer Dokumentenbestand mit gemessener Such- und Antwortqualität beweist alles, was Sie für die nächste Entscheidung brauchen. Diese drei Punkte kosten nichts. Und sie funktionieren unabhängig davon, ob Sie am Ende mit uns arbeiten oder mit jemand anderem.

Für wen passt dieser Weg? Nach unserer Erfahrung vor allem für Organisationen, deren Wissen zugleich wertvoll und schutzbedürftig ist. Dazu zählen mittelständische Unternehmen mit gewachsenen Dokumentenbeständen aus Jahrzehnten. Ebenso Unternehmen aus regulierten Branchen wie dem Finanz- und Gesundheitswesen. Dazu Kanzleien und Beratungen mit mandantenbezogenen Unterlagen. Und Ingenieur- und Technologieunternehmen, deren Konstruktions- und Entwicklungswissen die eigentliche Substanz der Firma ausmacht. Schließlich öffentliche Stellen, für die die Jurisdiktionsfrage keine Abwägung ist, sondern eine Vorgabe. Gemeinsam ist ihnen, dass ein Datenabfluss nicht nur ärgerlich wäre, sondern existenziell oder rechtlich untragbar. Wer dagegen unkritische Daten verarbeitet und vor allem schnell skalieren will, fährt mit Cloud-KI möglicherweise besser. Auch das sagen wir im Erstgespräch offen.

Ein Gespräch mit uns beginnt am besten konkret. Ein klar umrissenes Problem, ein erreichbarer Entscheider, ein begrenzter Dokumentenkorpus. Typische Einstiege aus den letzten Monaten sehen so aus. Die Prüfung, ob vertrauliche Dokumente lokal KI-gestützt durchsuchbar gemacht werden können. Ein begrenzter Pilot, der zeigt, wie lokale LLMs ohne Cloud-Abfluss in einem konkreten Prozess arbeiten. Oder eine lokale Knowledge Base für einen abgegrenzten Korpus mit gemessener Such- und Antwortqualität.

Sie erreichen uns per E-Mail an [email protected]. Die Postadresse lautet Boiman Kupermann Solutions GmbH, Im Zollhafen 12, 50678 Köln. Wir antworten selbst. Das ist ein Vorteil kleiner Teams.

BKS-Lab ist eine Marke der Boiman Kupermann Solutions GmbH, Köln. Dieser Beitrag gibt den Stand von Juli 2026 wieder. Insbesondere die regulatorischen Fristen des EU AI Act können sich durch weitere Gesetzgebungsverfahren ändern. Der Text dient der Einordnung und ist keine Rechtsberatung.