Wenn KI politisch wird:
Warum Unternehmen eigene KI-Systeme benötigen

Anthropic hat Fable 5 als Modell für anspruchsvolle, langläufige, agentische Aufgaben positioniert. Das ist genau die Arbeit, die KI im Produktionsbetrieb wertvoll macht. Code-Analyse, komplexe Engineering-Unterstützung, Prozessautomatisierung, Recherche, Knowledge Work.

Wenige Tage nach der Veröffentlichung wurde der Zugriff gesperrt. Anthropic verwies auf eine US-Export-Control-Directive im Zusammenhang mit nationaler Sicherheit. Diese verlangte, den Zugriff für ausländische Staatsangehörige zu beschränken. Da die Anweisung sofort wirksam wurde und Nationalität nicht zuverlässig in Echtzeit geprüft werden konnte, sperrte Anthropic Fable 5 und Mythos 5 für alle Nutzer.

Später wurden die Modelle wieder freigegeben, nachdem die Export Controls aufgehoben und zusätzliche Safeguards umgesetzt wurden. Diese Aktualisierung ist wichtig. Sie zeigt, dass das Problem nicht dauerhafte Nichtverfügbarkeit war, sondern Abhängigkeit von Entscheidungen außerhalb des eigenen Unternehmens.

Für Unternehmen, die bereits begonnen hatten, auf dem Modell aufzubauen, war die Konsequenz während der Unterbrechung trotzdem dieselbe. Das Modell war weg. Nicht wegen eines Bugs. Nicht wegen des Preises. Sondern wegen Geopolitik, Sicherheitsbedenken und regulatorischer Intervention.

So sieht es aus, wenn KI als strategische Infrastruktur behandelt wird. Politische Entscheidungen, Sicherheitsbewertungen und Exportregeln können heute direkt auf Software zugreifen, auf die Teams angewiesen sind. Ein Modell kann montags technisch verfügbar, wirtschaftlich attraktiv und operativ nutzbar sein und freitags vorübergehend nicht mehr erreichbar.

Viele Unternehmen behandeln Zugang und Kontrolle gleich. Sind sie aber nicht.

Zugang bedeutet, dass das Team das Modell über eine API, eine Web-Oberfläche oder eine Cloud-Plattform erreichen kann.

Kontrolle bedeutet, dass das Unternehmen weiß, wohin Daten fließen, welche Modelle welche Aufgaben verarbeiten, was geloggt wird, wie Ergebnisse validiert werden und was passiert, wenn ein Anbieter eine Änderung vornimmt, die niemand intern angefordert hat.

Wenn diese Prozesse auf externen Systemen laufen, die sich nicht prüfen lassen, entsteht eine zusätzliche Risikoschicht, die nicht sichtbar ist.

Das eigentliche Problem ist, dass Unternehmen die Fähigkeit verlieren zu reagieren. Wenn ein Anbieter eine Funktion abschaltet, eine Data-Retention-Policy ändert, ein Modell ersetzt oder von Mitarbeitenden neue Identitätsverifizierung verlangt, erfährt man es erst, nachdem es bereits gilt.

Anthropics jüngste Einführung von Identitätsverifizierung zeigt, wie schnell sich Plattformbedingungen verschieben können. In bestimmten Situationen können Nutzer aufgefordert werden, ihre Identität mit einem amtlichen Ausweis und in manchen Fällen mit einem Live-Selfie zu bestätigen, bevor sie bestimmte Funktionen nutzen können.

Anthropic gibt an, dass diese Verifizierungsdaten zur Identitätsbestätigung verwendet werden und nicht für Modelltraining. Diese Trennung ist wichtig. Sie löst das Governance-Problem für Unternehmen aber nicht. Denn sie zeigt, dass sich Zugangsvoraussetzungen, Datenflüsse, Drittanbieter-Prozesse und Safety Controls auf Plattformebene ändern können. Das passiert oft schneller, als interne Richtlinien, Beschaffung oder Security Reviews reagieren.

Gleichzeitig bleiben Modellverbesserung und Datenspeicherung eigene, aber relevante Fragen. Bei Consumer-Produkten können Chats und Coding-Sessions zur Modellverbesserung genutzt werden, wenn Nutzer dies erlauben. Diese Daten können dann bis zu fünf Jahre in Modelltraining-Pipelines gespeichert werden. Bei bestimmten besonders leistungsfähigen "Covered Models" können selbst manche kommerziellen oder Zero-Data-Retention-Konfigurationen eine begrenzte Speicherung und Review-Möglichkeit aus Safety-Gründen erfordern.

Aus Sicht eines Konsumentenprodukts wirken solche Änderungen wie Account-Einstellungen. Aus Unternehmenssicht sind es Governance-Fragen.

• Welche Daten dürfen durch externe KI-Systeme laufen?

• Welche Prompts enthalten vertrauliche technische Spezifikationen?

• Welcher Code ist geschäftskritisch?

• Wer im Unternehmen ist für welche Modelle autorisiert?

• Wie bleibt sensibles Material aus Training-, Feedback- und Safety-Review-Pipelines heraus?

Nutzungsrichtlinien beantworten diese Fragen nicht. Architektur schon.

Eigene KI-Systeme aufzubauen bedeutet nicht, dass jedes Unternehmen ein Frontier-Modell selbst trainieren muss. Für die meisten Organisationen wäre das weder notwendig noch wirtschaftlich sinnvoll.

Es bedeutet, eine kontrollierte Schicht zwischen Geschäftsprozessen, Daten und den genutzten Modellen aufzubauen.

Diese Schicht definiert, was in das System gelangt, was intern bleibt, was an externe Services gesendet wird, welches Modell für welche Aufgabe eingesetzt wird, wie Ergebnisse geprüft werden, wie Entscheidungen protokolliert werden und wie das Unternehmen bei Bedarf den Anbieter wechseln kann.

In der Praxis kann das je nach Use Case sehr unterschiedlich aussehen.

• Ein Produktionsunternehmen kann ein privates KI-System betreiben, das Produktionsdaten und Maschinenverhalten analysiert, ohne sensible operative Daten in Consumer-Tools zu übertragen.

• Ein Engineering-Team kann KI-Unterstützung für Dokumentation und Code Review nutzen, während kritische Repositories in kontrollierten Umgebungen bleiben.

• Ein Qualitätsteam kann KI-Modelle für Anomalieerkennung oder visuelle Inspektion direkt im Produktionskontext einsetzen. Mit klarem Logging, Modellmonitoring und Retraining-Prozessen.

• Ein Operations-Team kann agentische Workflows nutzen, die mit ERP-, MES- oder Wartungssystemen interagieren. Aber nur über definierte Schnittstellen und Freigabelogiken.

Das Ziel ist nicht Isolation um der Isolation willen. Das Ziel ist Kontrolle, Resilienz und Nachvollziehbarkeit.

Viele Unternehmen betrachten KI noch immer als Tool-Frage:

• Welches Modell ist das beste?

• Welchen Assistenten sollen wir nutzen?

• Welche Subscription sollen wir kaufen?

Diese Fragen sind relevant, reichen aber nicht aus. Sobald KI Teil produktiver Workflows wird, sind die wichtigeren Fragen architektonisch.

• Wohin fließen Daten?

• Welche Informationen dürfen das Unternehmen nie verlassen?

• Welche KI-Fähigkeiten sind geschäftskritisch?

• Was passiert, wenn ein Modell verändert, eingeschränkt oder regulatorisch blockiert wird?

• Kann das Unternehmen Modelle austauschen, ohne den gesamten Prozess neu aufzubauen?

• Wie werden Ergebnisse bewertet?

• Wer trägt Verantwortung, wenn KI-gestützte Entscheidungen operative Auswirkungen haben?

Das ist der Unterschied zwischen KI-Nutzung und AI Readiness.

AI Readiness bedeutet, KI in reale Prozesse integrieren zu können, ohne unkontrollierte Abhängigkeiten zu schaffen. Es bedeutet, von externer Innovation zu profitieren, ohne die eigene Handlungsfähigkeit abzugeben. Es bedeutet, Modelle, Anbieter und Deployment-Patterns anhand des konkreten Risikoprofils eines Use Cases auszuwählen.

Kontrollierte KI-Systeme brauchen mehr als Prompts und Interfaces. Sie brauchen dieselbe operative Disziplin, die Unternehmen bereits auf andere kritische Systeme anwenden.

Datenpipelines müssen verlässlich sein. Zugriffsrechte müssen klar sein. Modelle müssen versioniert, überwacht und evaluiert werden. Outputs müssen protokolliert werden. Performance muss über die Zeit gemessen werden. Retraining muss geplant sein. Security- und Compliance-Anforderungen müssen in das System eingebaut werden und dürfen nicht erst nachträglich ergänzt werden.

Genau hier wird MLOps entscheidend.

MLOps schafft die Struktur, um KI-Modelle produktiv zu deployen, zu überwachen und kontinuierlich zu verbessern. Es hilft Teams, von isolierten Experimenten zu wiederholbaren, auditierbaren und skalierbaren Systemen zu kommen. In industriellen Umgebungen ist das besonders wichtig, weil KI dort nicht nur mit Dokumenten oder Chat-Interfaces interagiert. Sie ist oft mit Maschinen, Sensoren, Kameras, Produktionslinien, Planungssystemen und Qualitätsprozessen verbunden.

Ohne Architektur bleibt KI ein Tool. Mit Architektur wird KI zur Infrastruktur.

craftworks unterstützt Unternehmen dabei, KI-Systeme aufzubauen, die nicht nur leistungsfähig, sondern auch operativ zuverlässig, sicher und auf reale Geschäftsprozesse abgestimmt sind.

Wir bringen langjährige Erfahrung in Data Engineering, Machine Learning, Industrial Software, MLOps, u.v.m. mit. Unser Fokus liegt darauf, KI von isolierten Experimenten in produktive Systeme zu überführen, die sich in bestehende IT-, OT- und Prozesslandschaften integrieren lassen.

Mit navio bieten wir eine Plattform, um Machine-Learning-Modelle in Produktionsumgebungen zu verwalten, zu deployen und zu überwachen. Mit navio VISION bringen wir KI-basierte visuelle Qualitätskontrolle in industrielle Use Cases. Unternehmen können dadurch Defekte erkennen, strukturierte Inspektionsdaten erzeugen und Produktionsqualität in einem kontrollierten Setting verbessern.

Darüber hinaus unterstützt craftworks Unternehmen bei der Identifikation passender KI-Use-Cases, beim Design von Daten- und Modellarchitekturen, beim Aufbau sicherer Schnittstellen, bei der Implementierung von Monitoring und bei der Vorbereitung von KI-Systemen für den langfristigen Betrieb.

Das Ziel ist, dass das Unternehmen entscheidet, wie KI eingesetzt wird und nicht umgekehrt.

KI-Systeme werden leistungsfähiger, stärker reguliert und enger mit Fragen von nationaler Sicherheit, Data Governance und digitaler Souveränität verknüpft. Gleichzeitig integrieren Unternehmen KI immer tiefer in ihre Workflows und das oft schneller, als ihre Governance-Strukturen mithalten können.

Diese Lücke erzeugt Risiko.

Unternehmen, die nur auf externen Zugriff setzen, bleiben externen Entscheidungen ausgesetzt. Unternehmen, die kontrollierte KI-Architekturen aufbauen, gewinnen Optionen. Sie können sensible Daten schützen, Modellrisiken managen, Anbieter wechseln, eigene Governance definieren und geschäftskritische Prozesse unter eigener Kontrolle halten.

Digitale Souveränität beginnt damit, die Architektur für KI-Readiness zu besitzen.