Offen als Standard, zuverlässig per Abonnement

Die meisten Unternehmen kennen dieses Gespräch bereits. Jemand schlägt vor, KI einzusetzen, um eine digitale Präsenz zu bauen oder zu pflegen — eine Website, ein Tool, eine Integration. Der Vorschlag klingt überzeugend: schnellere Lieferung, geringere Grenzkosten, eine Mannschaft, die außerhalb der Geschäftszeiten arbeitet. Die Arbeit beginnt. Etwas wird veröffentlicht.

Dann geht etwas schief.

Es mag eine Kleinigkeit sein: eine Aussage auf der Seite, die nicht ganz stimmt. Ein Abschnitt, der dem rechtlichen Text zwei Seiten weiter widerspricht. Eine Funktion, die in der Navigation beschrieben ist, im Produkt aber nicht existiert. Wenn jemand fragt, wie das passiert ist, lautet die Antwort meistens sinngemäß: Das Modell hat es so ausgegeben, jemand hat es geprüft, es schien in Ordnung zu sein.

Das Problem liegt nicht darin, dass das Modell einen Fehler gemacht hat. Modelle machen Fehler — Menschen auch. Das Problem ist die fehlende Nachvollziehbarkeit. Es gibt keine Aufzeichnung darüber, was das Modell gefragt wurde, was es zurückgegeben hat, wer das Ergebnis geprüft hat, was bei der Prüfung kontrolliert wurde und wer schließlich die Anweisung zur Veröffentlichung erteilt hat. Die Verantwortung verteilt sich. Der Fehler hat keine eindeutige Eigentümerin.

Das ist kein KI-Problem. Es ist ein Prozessproblem. Es tritt in nahezu identischer Form in jedem Arbeitsablauf auf, in dem Prüfungen informell und Freigaben implizit sind. KI macht es sichtbarer — und folgenreicher —, weil Volumen und Geschwindigkeit der Ausgaben das übersteigen, was informelle Kontrollen leisten können.

Es gibt eine schärfere Variante dieser Verantwortungslücke, die nun in der industriellen Debatte angekommen ist. Da die KI-Rechenkosten sinken und die Modellleistung steigt, nähern sich die Kosten für den KI-Einsatz bei einer Aufgabe den Kosten an, eine qualifizierte Fachkraft mit derselben Arbeit zu betrauen — und überschreiten sie in manchen Bereichen bereits. Ein Praktiker brachte das auf dem VDMA Praxistag KI in Frankfurt auf den Punkt: Wenn KI-Kosten die Kosten der qualifizierten Person erreichen, die vollständig für die Arbeit verantwortlich ist, ist der dauerhafte Differenzierungsfaktor nicht mehr der Preis — sondern die Verantwortlichkeit. Ein Modell kann nicht zur Verantwortung gezogen werden. Eine Person schon. Die Organisation, die Entscheidungen durch KI leitet, ohne einen sichtbaren menschlichen Kontrollpunkt, hat das Verantwortungsproblem nicht gelöst — sie hat es teurer und schwerer nachvollziehbar gemacht.

Die Lösung ist auch nicht neu: ein dokumentierter Ablauf mit einem Menschen an der tragenden Stelle. Nicht in einer zeremoniellen Funktion — einem Freigabe-Häkchen, das alle als Formalität behandeln —, sondern in einer strukturellen: ein Mensch, der die gerenderte Ausgabe sieht, sie mit dem Vereinbarten abgleicht und ausdrücklich entscheidet, dass sie veröffentlicht werden darf. Dieser Mensch ist die Person, die gefunden, befragt und für das Veröffentlichte zur Rechenschaft gezogen werden kann. Ein Mensch entscheidet — by design.

Der Rest dieses Dokuments beschreibt, wie Apuna diesen Ablauf entwickelt hat, warum er nachvollziehbar und nicht nur beschrieben ist — und was eine Auftraggeberin tatsächlich erhält, wenn sie ihn in Anspruch nimmt.

Der Build-Loop ist überschaubar, dokumentiert und reproduzierbar. Er läuft vom ersten bis zum neunzigsten Tag auf dieselbe Weise — im Aufbau wie in der Pflege —, weil die Disziplin strukturell verankert ist, nicht nur angestrebt wird.

Der Ablauf hat sechs Schritte:

1. Briefing zum Backlog. Ein kurzes Intake überführt den Auftrag in atomare Arbeitseinheiten: einen Abschnitt, eine Komponente, eine Korrektur. Nichts, das groß genug wäre, um undurchsichtig zu werden. Die Atomarität ist bewusst gewählt — eine kleine Änderung lässt sich prüfen; eine große lässt sich nur vertrauen.

2. Atomare Pull Requests. Die Mannschaft arbeitet den Backlog als Strom kleiner, in sich geschlossener Änderungen ab. Jeder Pull Request ist genau eine Sache. Das ist keine Effizienzentscheidung, sondern eine Verantwortungsentscheidung. Ein Ein-Sache-PR kann geprüft werden. Ein Viel-Sache-PR verteilt die Verantwortung über seinen Inhalt.

3. Round-Table-Review. Bevor ein PR zur Freigabe angeboten wird, bewertet das /meeting-Panel konkurrierende Ansätze. Der geeignetste Kandidat setzt sich durch. Die erste Idee ist nicht automatisch die letzte — das ist die Variations- und Selektionsdisziplin, angewandt auf Text und Code gleichermaßen.

4. Faktencheck und Verifikationsschritt. Eine Verifikation prüft jeden konkreten Anspruch im PR gegen das tatsächliche Diff und die gerenderte Seite — nicht die Beschreibung der Seite, sondern die Seite selbst. Technische Behauptungen, die sich nicht belegen lassen, werden hier erkannt. Eine Funktion, die behauptet, aber nicht gebaut wurde. Ein Abschnitt, der beschrieben, aber nicht vorhanden ist. Das Gate lässt nicht durch, was sich nicht nachweisen lässt.

5. Menschliche Freigabe. Kein PR wird ohne eine ausdrückliche menschliche Entscheidung über die gerenderte Ausgabe zusammengeführt oder veröffentlicht. Das Prinzip ist in der Verfassung als §8 verankert: Die Seite lesen, nicht das Diff. Die Rolle des Menschen ist nicht zeremoniell; sie ist die einzige Prüfung, die die KI-Mannschaft nicht für sich selbst durchführen kann. Dazu mehr im nächsten Abschnitt.

6. Zusammenführen, veröffentlichen, iterieren. Was freigegeben wurde, geht live. Der Ablauf beginnt von vorne.

Der Loop ändert sich nicht zwischen Aufbau und Pflege. Ein Patch am dreiundneunzigsten Tag durchläuft dieselben Gates wie der erste Abschnitt am ersten Tag. Die Disziplin ist dieselbe, weil die Frage der Verantwortlichkeit dieselbe ist.

Der VDMA Praxistag KI im Maschinen- und Anlagenbau — eine Konferenz, auf der rund zweihundert Praktiker aus der Industrie Erfahrungen zum produktiven KI-Einsatz verglichen — einigte sich auf sechs Erfolgsfaktoren für Agenten in jedem Bereich: Kontext und Verankerung, Zuverlässigkeit, feingranulare Berechtigungen, Mensch im Loop, Nachvollziehbarkeit und Guardrails. Das sind keine Ziele. Es sind die Bedingungen, unter denen Agenten in der Produktion scheitern oder gelingen — das Mindestmaß an Vertrauen, das jeder ernsthafte Einsatz erfüllen muss. Es ist gleichzeitig eine genaue Beschreibung dessen, wofür Apunas Loop von Anfang an gebaut wurde — nicht als nachträgliche Erweiterung. Der Loop hat einen Menschen an der tragenden Stelle (Mensch im Loop). Jeder Schritt wird protokolliert (Nachvollziehbarkeit). Ausgaben werden validiert, bevor sie ein nachgelagertes System berühren (Guardrails). Berechtigungen sind standardmäßig eng — die Mannschaft schlägt vor, ein Mensch entscheidet. Kontext ist explizit und im tatsächlichen Arbeitsgegenstand verankert. Und die Ergebnisse sind reproduzierbar by design, weil der Prozess dokumentiert und die Gates strukturell sind. Der Raum in Frankfurt hat das Rahmenwerk bestätigt. Der Loop ist älter als die Konferenz.

Es gibt einen Einwand, den eine erfahrene Auftraggeberin stellen wird, und er verdient eine direkte Antwort: Wenn die KI-Mannschaft die gesamte Arbeit geleistet hat — den PR entworfen, das Review durchgeführt, den Verifikationsschritt bestanden — und der Mensch dann eine Ausgabe freigibt, die er nicht eigenständig hätte erstellen können: Ist diese Freigabe dann real? Oder ist sie eine bloße Formsache — dem Namen nach verantwortlich, in der Sache jedoch nicht?

Der Einwand ist berechtigt gegenüber einer Freigabe, die nur nominell existiert. Der Loop ist darauf ausgelegt, genau das zu verhindern. Der Grund liegt in §8 der Verfassung, klar formuliert: Die Seite lesen, nicht das Diff.

Die technische Bedeutung lautet: Die Freigabe des Menschen bezieht sich auf die gerenderte Ausgabe, so wie eine außenstehende Person sie vorfindet — nicht auf die geänderten Zeilen in einer Code-Review-Oberfläche. Eine Prüferin, die nur das Diff liest, prüft interne Konsistenz: ob die Änderung wie beabsichtigt umgesetzt wurde. Eine Prüferin, die die Seite liest, prüft etwas anderes: ob das Ergebnis das ist, was eine tatsächliche Person, die unvorbereitet ankommt, vorfinden und nutzen kann.

Das sind zwei verschiedene Dinge. Das Diff erfordert, dass Sie rekonstruieren, wie die Seite aussehen wird. Die gerenderte Seite ist, wie sie aussieht. Der Mensch ist die einzige Partei in diesem Prozess, die dort stehen kann, wo die außenstehende Person steht — ohne ein Modell der Seite, das selbst eine Repräsentation ist, ohne einen früheren Durchlauf, der formt, was sie zu sehen erwartet. Das ist kein kleiner Unterschied. Es ist der Unterschied zwischen der Prüfung einer Absicht und der Prüfung eines Ergebnisses.

Das ist der nicht ersetzbare Beitrag. Die KI-Mannschaft kann prüfen, ob der Code die Spezifikation umsetzt. Sie kann nicht prüfen, ob die Spezifikation etwas erzeugt, das eine reale Person navigieren, lesen und nutzen kann — denn das zu prüfen erfordert, diese reale Person zu sein. Die menschliche Freigabe ist der Moment, in dem diese Verifikation in die Aufzeichnung eingeht.

Es gibt eine zweite Dimension des Einwands, die weniger technisch, aber wichtiger ist. Wenn eine Entscheidung durch ein System — eine KI, einen Prozess, eine Regel — geleitet wird und keine namentlich genannte Person dahintersteht, hat die verantwortliche Partei eine Wahl getroffen: zu erscheinen, als würde sie entscheiden, ohne es tatsächlich zu tun. Eine Freigabe zu unterzeichnen für etwas, das generiert wurde, ohne dafür einzustehen. Das ist kein technologisches Problem — es ist ein ethisches. Eine Organisation, die bindende Entscheidungen durch KI leitet, ohne einen sichtbaren, funktionalen menschlichen Kontrollpunkt, hat keinen vertrauenswürdigen Prozess aufgebaut. Sie hat einen gut getarnten aufgebaut.

Genau diese Governance-Frage beschäftigt Industriepraktiker nun ernsthaft — und gelangt im Maschinenbau auf die Vorstandsebene. Der VDMA Praxistag KI in Frankfurt hat gezeigt: Der Begriff Chief AI Officer ist in einem Raum voller Ingenieure als akzeptiertes Vokabular angekommen. Das ist eine bedeutsame Verschiebung. Ob die Antwort ein eigener CAIO, ein verteiltes Governance-Modell über bestehende Rollen oder etwas anderes ist, muss jede Organisation selbst entscheiden. Aber die zugrunde liegende Frage gehört in den Vorstand, nicht in eine einzelne Funktion. KI-Strategie — wohin soll uns das führen, und welche Entscheidungen müssen menschlich bleiben — ist keine Beschaffungsfrage und keine Werkzeugfrage. Es ist eine Frage über die Zukunft des Unternehmens, und sie erfordert benannte Verantwortlichkeit an oberster Stelle.

Der Fehlermodus, den es klar zu benennen gilt: einen CAIO oder eine neue KI-Governance-Rolle schaffen und dann jeder anderen Funktion erlauben, das als Erlaubnis zur Enthaltung zu verstehen. Die Rolle, die Ernsthaftigkeit signalisieren sollte, wird zum Silo. Der CTO betreibt weiter den Legacy Stack, weil KI jetzt das Problem einer anderen Person ist. Der COO führt Operations unverändert fort. Der Vorstand bittet vierteljährlich um eine Aktualisierung und behandelt das als Governance. Die KI-Funktion akkumuliert Verantwortlichkeit ohne die Autorität zur Umsetzung. Das ist die falsche Struktur.

Die richtige Struktur — ob sie einen Titel trägt oder nicht — verteilt Verantwortlichkeit klar: Wer besitzt das Datenfundament, wer setzt die Berechtigungsschwellen, wer prüft den Audit-Trail, wer genehmigt die Kriterien, nach denen KI-Empfehlungen umgesetzt werden? Diese Fragen brauchen benannte Verantwortliche. Sie brauchen keinen neuen C-Suite-Titel — aber sie brauchen Vorstandsvisibilität und explizite Prüfung. Die menschliche Freigabe im Loop von Apuna ist dasselbe Prinzip auf der Ebene eines einzelnen PR. Ein Mensch entscheidet — und dieser Mensch kann gefunden werden.

Die Freigabe im Loop von Apuna ist keine Formsache, weil der Akt des Seitenlesens — des Stehens dort, wo keine KI stehen kann — eine Verifikation ist, die die KI nicht für sich selbst durchführen kann. Und weil der Mensch, der freigibt, die Person ist, die gefunden, zur Rechenschaft gezogen und an dem gemessen wird, was veröffentlicht wurde. Diese Beziehung ist das, was das Wort Verlässlichkeit tatsächlich bedeutet.

Eine Auftraggeberin muss der Präsentation nicht vertrauen. Sie kann den Quellcode lesen. Drei Eigenschaften machen die Methode nachvollziehbar — nicht nur beschreibbar.

Open-Source-Pipeline. Die Build-Pipeline — apuna/core — steht unter der Apache-2.0-Lizenz. Jede Zeile, die einen Build ausführt, ist lesbar. Es gibt keinen proprietären Prozess, dem auf Treu und Glauben vertraut werden müsste; eine Auftraggeberin oder ihr technisches Team kann inspizieren, was läuft. Die Open-Source-Lizenz beseitigt auch die Abhängigkeit: Am Ende jedes Auftrags hält die Auftraggeberin jede Zeile Code unter einer Lizenz, die es ihr erlaubt, diesen zu behalten, zu forken und auf der eigenen Infrastruktur zu betreiben. Der Code ist ein öffentliches Gut. Das Abonnement ist etwas ganz anderes.

KI offengelegt, niemals verborgen. Jedes von KI verfasste oder unterstützte Artefakt trägt eine sichtbare Zuweisung — Agentenname, KI-Status, Rolle im Prozess. Dieses Dokument trägt sie in seiner Autorenzeile. Die Methode verbirgt nicht, was das Modell beigetragen hat, und präsentiert es nicht als ungestützte menschliche Urteilsfindung. Das ist §4 der Verfassung, im Repository nachprüfbar. Es ist keine Höflichkeit; es ist eine Bedingung.

Genauigkeit vor Vollständigkeit. Jede Aussage in Apunas öffentlicher Arbeit muss auf eine primäre Quelle im Repository zurückgeführt werden können. Nicht belegbare Aussagen werden entfernt, nicht abgemildert. Das ist §6 der Verfassung. Die Stichprobe der Auftraggeberin ist einfach: Lässt sich die Quelle für diese Aussage finden? Wenn nicht, sollte die Aussage nicht dort stehen. Eine kürzere, verifizierte Aussage ist immer einer ausführlicheren, spekulativen vorzuziehen — weil einer kürzeren verifizierten Aussage vertraut werden kann, Spekulation hingegen nicht handlungsanleitend ist.

Diese drei Eigenschaften sind nicht unabhängig voneinander. Sie bilden ein einziges Argument: Die Auftraggeberin kann den Prozess inspizieren, sehen, wer was beigetragen hat, und prüfen, dass die Aussagen auf der Seite auf etwas Reales zurückführbar sind. Das ist Nachvollziehbarkeit. Das unterscheidet sich davon, dass ihr gesagt wird, der Prozess sei gut.

Dasselbe Prinzip der Nachvollziehbarkeit gilt für den Produktpfad, den Apuna Industriekunden empfiehlt — und er beginnt mit genau derselben Frage, zu der der VDMA-Raum immer wieder zurückkehrte: Welche Daten haben wir eigentlich — und woher kommen sie? Bevor ein KI-System irgendetwas Nützliches tun kann, muss jemand im Unternehmen diese Frage beantworten können, ohne zu raten. Das ist die Transparenz-zuerst-Haltung — sie ist keine Option, sie ist das Fundament, auf dem alles andere aufbaut.

Der gestufte Pfad läuft wie folgt. Erstens: ein Datentransparenz-Dashboard. Kein Data Lake, keine BI-Plattform — eine klare Bestandsaufnahme, welche Systeme Daten produzieren, in welchem Format, mit welcher Qualität, wie oft aktualisiert, von wem verantwortet. Die meisten Unternehmen stellen fest, dass allein diese Stufe Lücken und Inkonsistenzen zutage fördert, von denen sie nichts wussten. Zweitens: ein API-Fundament — die Daten über stabile Schnittstellen zuverlässig abfragbar, auf die nachgelagerte Systeme und Agenten sich verlassen können. Das ist der Plattformschritt. Er ist unspektakulär. Er ist der Schritt, den die meisten Projekte überspringen — und deshalb stocken die meisten Projekte. Drittens: ein lesender Empfehlungsagent. Der Agent hat Zugang zum Datenfundament und kann Empfehlungen formulieren, begründen und protokollieren — Wartungshinweise, Beschaffungsvorschläge, Anomaliemeldungen. Er kann nicht handeln. Diese Einschränkung ist bewusst: Nur-Lesen zuerst verdient das Vertrauen, das die nächste Stufe erst möglich macht. Bei jeder Empfehlung entscheidet ein Mensch. Viertens: prädiktive Wartung und agentischer Einkauf, mit einem Mensch-im-Loop (HITL)-Gate. In dieser Stufe kann der Agent Aktionen einleiten — aber die Architektur stellt menschliche Freigabe bei jedem Schritt mit realen Konsequenzen sicher. Der HITL-Loop für den Einkauf läuft: Lagerbestand niedrig erkannt → Agent holt Angebote → Agent synchronisiert Liefertermine → menschliche Freigabe → Bestellung ausgelöst. Der Agent erledigt die Recherche und die Vorarbeit; der Mensch trifft die Entscheidung.

Drei Datenpfeiler verbinden die Stufen: IoT-Telemetrie (das Live-Signal der Maschine), ERP-Daten (Bestand, Lieferfristen, Produktionsfenster) und Dokumentation und Wissen (Handbücher, Service-Bulletins, historische Aufzeichnungen — zur Inferenzzeit abgerufen, damit der Agent gegen die tatsächliche Dokumentation schlussfolgert, nicht gegen seine Trainingsdaten). Diese drei Pfeiler sind über klare APIs verbunden, versionskontrolliert, mit expliziten Berechtigungsvergaben auf jeder Ebene. Die Nachvollziehbarkeit des Systems ist ein direktes Produkt der Nachvollziehbarkeit der Dateneingaben. Auf einer undurchsichtigen Datengeschichte lässt sich keine nachvollziehbare KI-Empfehlung aufbauen.

Riesenrutschbahn.de demonstriert den gestuften Bogen der Methode im Produktivbetrieb. Die Stufe des Datentransparenz-Dashboards ist live: ein Grafana-Dashboard, mobil optimiert und über Cloudflare Access gesichert, macht die Sensor-Flotte lesbar — jeden Bob (jeden Wagen), auf einen Blick, auf jedem Smartphone. Das API-Fundament ist vorhanden: Cloudflare Workers, Queues und D1 bilden die Datenschicht, aus der das Dashboard liest. Die Stufe des lesenden Empfehlungsagenten läuft als prädiktive Wartung: ISO-10816-Vibrationsanalyse in einem Cloudflare Worker (kein LLM — das richtige Werkzeug für Vibrations-Zeitreihen) erkennt Auffälligkeiten, bevor sie zu Ausfällen werden; ein Mensch entscheidet, ob er auf jeden Hinweis reagiert. Die Kundschaft besitzt die Daten. Die Kundschaft besitzt das Deployment. Die agentische Beschaffungsstufe des Bogens wurde nicht ausgeliefert — sie war nicht im Umfang. Die Fallstudie unter `/[lang]/case-studies/riesenrutschbahn` dokumentiert die Architektur vollständig.

Die Methode ist keine Absichtserklärung. Sie hat ein Artefakt.

Apunas öffentliche Website wurde nach demselben Ablauf gebaut, der im vorigen Abschnitt beschrieben wird — dieselben atomaren Pull Requests, dasselbe /meeting-Round-Table-Review, derselbe Faktencheck und Verifikationsschritt, dieselbe menschliche Freigabe auf der gerenderten Ausgabe. Das Repository ist öffentlich. Die Commit-Historie ist lesbar. Die Verfassung, die die Mannschaft bindet, ist im Repository festgehalten und datiert: verabschiedet am 16. Juni 2026.

Dieses Dokument wurde nach derselben Methode erstellt: von einem Menschen und einem KI-Agenten, in dokumentierter Zusammenarbeit, mit offen ausgewiesenem Beitrag der KI in der Autorenzeile. Die Methode ist das Produkt ist der Beweis.

Die Auftraggeberin liest nicht über einen zukünftigen Prozess. Sie liest eine Ausgabe des aktuellen. Die Seite, die sie liest, wurde vom selben Panel geprüft, hat dasselbe Gate durchlaufen und wurde von demselben Menschen freigegeben, der auch die Arbeit freigeben wird, die sie in Erwägung zieht zu beauftragen.

Das ist es, was es bedeutet, wenn ein Beweis reflexiv statt testimonial ist. Ein testimoniales Argument sagt: Ein Auftraggeber hat dieses Ergebnis erzielt. Das kann stimmen — es kann aber auch selektiert, geglättet und im Nachhinein bereinigt worden sein. Ein reflexiver Beweis sagt: Hier ist die Ausgabe der Methode, vor Ihnen, nachprüfbar. Das Repository ist die primäre Quelle. Die Commit-Historie ist die Aufzeichnung. Der Beweis steht auf dem Artefakt selbst — er ist nicht auf Fallstudien oder Kundennamen angewiesen. Aber der Nachweis enthält jetzt mehr als das Artefakt. Riesenrutschbahn.de (Poppeltal) — Apunas erster Auftrag und erste veröffentlichte Fallstudie — bestätigt die Methode in einem produktiven System. Der reflexive Beweis braucht diese Bestätigung nicht. Er bestand vor ihr. Was die Fallstudie hinzufügt, ist Korroboration, kein Fundament.

Es gibt eine Frage, die in industriellen Gesprächen immer wieder auftaucht — manchmal offen ausgesprochen, häufiger nur angedeutet: Bedeutet das Hinzuziehen eines externen KI-Partners Kontrollverlust? Es ist fast immer die falsche Frage — nicht weil das Anliegen illegitim wäre, sondern weil der deutsche Maschinenbau sie seit einem Jahrhundert richtig beantwortet, ohne sie je so zu formulieren.

Schauen Sie sich an, wie Maschinenbau tatsächlich funktioniert. Sie entwerfen die Maschine, aber die Hydraulik kommt von einem Spezialisten. Der Schaltschrank wird von einem Schaltschrankbauer gebaut, mit dem Sie seit zwanzig Jahren zusammenarbeiten. Die Werkzeuge liefert ein Zulieferer zwei Ortschaften weiter. Die Softwareintegration übernimmt ein Systemhaus. Wenn eine neue Dichtungstechnologie auftaucht, die in Ihrem Haus niemand beherrscht, rufen Sie ein Ingenieurbüro an. Das ist keine Schwäche. So produziert der Mittelstand Qualität, die der Rest der Welt nicht nachbilden kann: Sie beziehen die Kompetenz, die Sie nicht intern haben, und Sie behalten die Richtung.

Bei KI und Digitalisierung funktioniert es genauso. Einen externen Partner hinzuzuziehen ist derselbe Schritt wie das Anrufen des Systemhauses — Sie beziehen die Spezialisten-Kompetenz, die Sie intern nicht haben, Sie bleiben im Sattel, Sie treffen die Entscheidungen darüber, was für Ihr Geschäft zählt. Ein guter Partner ersetzt Ihre Ingenieure nicht; er arbeitet neben ihnen — und gibt genug weiter, um sich selbst mit der Zeit weniger unentbehrlich zu machen, nicht unentbehrlicher. Die Frage, die es zu stellen lohnt, ist nicht: Können wir KI allein stemmen? Die Frage ist: Welche Kompetenz bauen wir intern auf, welche beziehen wir, und wer ist der richtige Partner für das, was wir beziehen? Das ist dieselbe Frage, die Sie beantworten, jedes Mal wenn Sie einen Zulieferer-Vertrag abschließen. Sie haben sie lange Zeit gut beantwortet.

Der Wettbewerbsvorteil des Mittelstands lag immer in der Tiefe des Handwerks: der dreißigjährigen Beziehung zum Kunden, der Maschine, die zwanzig Jahre läuft, weil sie dafür gebaut wurde. KI ersetzt diesen Vorteil nicht. Die Datenplattform, die ihn lesbar macht — überwachbar, nachvollziehbar, skalierbar — ist keine Optimierungsarbeit. Es ist Fundamentarbeit. Und wie jede Fundamentarbeit in der Geschichte des Maschinenbaus ist sie am besten in Kooperation zu bauen.

Es gibt eine Frage, die eine technisch versierte Einkäuferin vor dem zweiten Gespräch stellt, selten laut: Wenn der Code unter Apache-2.0 steht und ich jede Zeile lesen kann, wofür zahle ich dann genau? Es ist die richtige Frage, und die ehrliche Antwort entscheidet, ob diese Praxis den Auftrag verdient.

Der Code ist kostenlos. Die Build-Pipeline steht unter der Apache-2.0-Lizenz. Die Auftraggeberin kann am Ende eines Auftrags jede Zeile mitnehmen und gehen. Es gibt keinen proprietären Käfig, keine Abhängigkeit, kein absichtlich zurückgehaltenes Wissen, das Abhängigkeit erzeugen soll. Das ist kein vertriebliches Zugeständnis; es ist die Prämisse des Geschäftsmodells.

Das Abonnement — Apuna Care — liefert etwas, das der Code nicht liefern kann. Infrastruktur: die Cloudflare-Workers-Umgebung, den Zugang zu den Modell-APIs, die Automatisierung, die den täglichen Loop betreibt. Zeit mit dem Menschen im Loop: die Fachstunden, die prüfen, freigeben und die Entscheidungen treffen, die ein Modell nicht allein treffen sollte. Und Verlässlichkeit: eine namentlich genannte Ansprechperson, die das System kennt, die noch da ist, wenn etwas kaputtgeht, und die für das verantwortlich ist, was veröffentlicht wird. Die Marge liegt in Zeit und Skalierung, nicht in einem Aufschlag auf Token. Variable Kosten — API-Nutzung der Modelle, Infrastruktur — werden zum Selbstkostenpreis ohne Aufschlag in Rechnung gestellt. Das ist in der Produktspezifikation klar formuliert und von der Auftraggeberin nachprüfbar.

Apuna Care gibt es in drei Editionen.

Community ist für Teams, die die Open-Source-Pipeline selbst betreiben möchten: Sie bringen ihre eigene Domain und ihre eigenen API-Schlüssel mit; Apuna nimmt nichts und betreibt keine Infrastruktur.

Standard ist für Teams, die Apuna mit dem Betrieb beauftragen möchten: Apuna stellt die Infrastruktur und die Schlüssel bereit, stellt variable Kosten zum Selbstkostenpreis ohne Aufschlag weiter und rechnet Fachstunden zum vereinbarten Satz separat ab. Das Abonnement liefert verwaltete Wartung mit definierten Reaktionszeiten.

Premium ergänzt individuelle Integrationen über das hinaus, was die Cloudflare-Plattform standardmäßig bietet, priorisierte Störungsbehebung in den erweiterten europäischen Geschäftszeiten (derzeit etwa GMT+1), proaktives Monitoring und eine namentlich genannte Ansprechperson, die das System kennt.

Preise werden hier nicht genannt. Die Verfassung verbietet erfundene Zahlen, und diese Disziplin gilt auch für dieses Dokument. Der richtige nächste Schritt ist ein Gespräch.

Die Frage, die eine Mittelstandsentscheiderin tatsächlich stellt — kann ich mich auf diese Menschen verlassen, wenn etwas schiefgeht? — wird nicht durch die Preistabelle beantwortet, sondern durch die Verantwortungsstruktur: ein Mensch, der freigibt; ein Prozess, der dokumentiert ist; ein Code, der offen ist; und eine Verfassung, die öffentlich und datiert ist. Sie zahlen für Verlässlichkeit, nicht für Code. Der Unterschied ist präzise und beabsichtigt.