Durch KI
KI als Werkzeug.
Die Plattformen und der Code darunter — der Grund, warum ich in Wochen liefere, nicht in Quartalen.
Bauen. Messen. Veröffentlichen.
KI in der Praxis ist schwerer als KI im Labor. Ich dokumentiere den Unterschied.
Apuna. Feldnotizen.
Ich arbeite an KI im industriellen Service — Voice-Agenten, LLM-Evaluation, EU-KI-Verordnung im mitbestimmten Betrieb. Dr.-Ing. in Planung. Hier landen die Methoden und die Misserfolge.
Auf GitHub ansehen →Feldthese
Die meisten KI-Projekte, die ich im industriellen Service gesehen habe, bleiben im Proof-of-Concept stecken. Das habe ich bei denen herausgefunden, die es nicht tun.
Der Pilot lief. Der Produktivbetrieb nie. Die Lücke ist fast immer dieselbe — und liegt nicht am Algorithmus.
Das Muster
Was ich sehe, bevor ein Projekt ins Stocken gerät
- —KI-Projekte, die im Proof-of-Concept steckenbleiben — und nie produktiv gehen.
- —Teuer eingekaufte Plattformen — beim ersten echten Problem kein Support, kein SLA.
- —Maschinendaten über OPC-UA, Modbus, MQTT, die niemand in Entscheidungen übersetzt.
- —Große Beratungshäuser, die ein Account-Team schicken — aber niemanden mit Gespür für den Hallenboden.
- —Kein eigenes KI-Team aufbaubar — und keine Lust auf den nächsten Vendor-Lock-in.
- —Werkzeuge, die in der Demo glänzen und beim ersten Schichtbetrieb auseinanderfallen.
Die Methode
Was tatsächlich funktioniert
Wer plant, baut auch.
Der Ansatz
Von den Sensoren bis zu Entscheidungen — in Produktion
Ich beginne bei den Sensordaten. Verbinde, übersetze, mache sie handlungsfähig. Baue Systeme, die echte Betriebsarbeit übernehmen — auf dem Hallenboden, nicht nur im Pilot.
Das Commitment
Dabei bleiben nach der Übergabe
Ich bleibe nach der Übergabe dabei. Nicht als Managed Service — als dokumentiertes, quelloffenes System, das du selbst besitzt und betreiben kannst. Ich bin erreichbar, wenn der Randfall auftaucht.
Warum das zählt
Was das Muster lehrt
- ›Wer plant, baut auch. Kein Übergabe-Moment zwischen der Person, die das System versteht, und der Person, die es wartet.
- ›Maschinenbau, nicht nur Python. Ich übersetze zwischen Modell und Hallenboden — in beide Richtungen.
- ›Deine Infrastruktur, kein Lock-in. Herstellerneutral, läuft bei dir. Keine Black Box — die Daten und die IP bleiben deine.Jede Änderung nachvollziehbar und von einem Menschen freigegeben.
- ›Feldbefund vor Architekturentscheidung. Ich lasse die erste Integration gegen echte Produktionsdaten laufen, bevor ich mich auf ein Design festlege. Die Randbedingungen zeigen sich erst, wenn das echte System im Raum ist.
Ein Gespräch. Ein konkretes Problem. Eine ehrliche Einschätzung.
apuna.dev · Deutschland
Whitepaper
Whitepaper lesen / als PDFKI, die du prüfen und betreiben kannst — wie ich baue.
01 — Wie ich arbeite
Wie ich arbeite — und wo ich die Grenze ziehe.
KI ist kein Versprechen. Sie ist mein tägliches Werkzeug — Infrastruktur, Denkpartner, Beschleuniger — und ich weiß genau, wo sie aufhört.
Mit KI
KI als Partner.
Mensch und KI denken gemeinsam auf ein Ergebnis hin, das keiner allein erreicht. Ich bleibe eingebunden. Keine Übergabe.
Weil KI's möglich macht
KI als Türöffner.
Arbeit, die es vor zwei Jahren noch nicht gab — neue Fragen, neue Rollen, neues Tempo. Ich beobachte genau, wann genau das eintritt.
Trotz KI
KI als Limit.
Manches bleibt menschlich. Nicht aus Regulierungsgründen, sondern weil ich es jedes Mal neu entscheide. Ich entscheide bewusst, wo KI nichts verloren hat.
Ich dokumentiere, was das Feld lehrt — Scheitern inklusive.
07 — Die Crew
Wie ich arbeite
Ich arbeite allein — mit einer KI-Crew fürs Denken, Gestalten und Hinterfragen. Kein Freelance-Netzwerk, kein Account-Team, kein Investor. Was hier erscheint, kommt von einem Praktiker — geprüft und freigegeben, bevor es erscheint.
MEINE KI-AGENTEN
Die KI-Crew, mit der ich arbeite
Das sind KI-Personas — keine menschlichen Teammitglieder. Jedes Ergebnis, das sie produzieren, wird von mir geprüft und freigegeben, bevor es veröffentlicht wird.
Die Vorsitzende ist die Konstante — Kontinuität und der lange Blick; die Arbeitscrew entwirft, gestaltet, baut und hinterfragt, mit einem Berater, der den Blick weitet. Jede Entscheidung treffe ich.
Kernteam
Berater
02 — Die Methode
Vier Schritte. Immer in der Reihenfolge. Die Reihenfolge trägt das Gewicht.
Prozessanalyse
Kein KI-Eingriff, der etwas taugt, ohne vorher zu verstehen, wo die Arbeit wirklich stattfindet — nicht in der Dokumentation, nicht im Organigramm, sondern bei den Menschen, die sie tragen. Erst Reibung kartieren, dann Werkzeug wählen. Jedes Mal.
Mehr lesen
Wissenssicherung
Die gefährlichste Lücke im Betrieb ist die zwischen dem, was erfahrene Leute wissen, und dem, was irgendwo steht. Wenn sie gehen, geht das Wissen mit. Rausbringen, strukturieren, abrufbar machen — bevor es zur Tür rausgeht.
Mehr lesen
Automatisierung
Die Frage ist nicht: Was kann ich automatisieren? Sondern: Was kostet menschliches Urteil, braucht es aber gar nicht? Dort anfangen. Alles, was wirklich Urteil braucht, bleibt wo es hingehört.
Mehr lesen
KI-Integration
KI kommt zuletzt, nicht zuerst. Funktioniert nur, wenn der Prozess schon sauber ist und das Wissen schon strukturiert. In dieser Reihenfolge. Andersrum automatisiert man das Chaos.
Mehr lesen
Devlog
Jede Entscheidung, jeder Misserfolg — dokumentiert, während es passiert.
Keine Projektzusammenfassung. Arbeitsnotizen von jemandem, der das im laufenden Betrieb macht: was ich versucht habe, was nicht funktioniert hat, warum ich die Richtung gewechselt habe. Zu lesen, bevor dieselben Fehler gemacht werden.
Devlog lesenWird laufend aktualisiert
03 — Open by Default
Alles, was ich baue, ist offen. Alles, was ich lerne, wird veröffentlicht.
Code ist Apache-2.0. Methoden sind dokumentiert. Misserfolge stehen neben Ergebnissen. Keine andere Verpflichtung — so bleibt Forschung ehrlich.
Apache-2.0
Alles, was ich für diese Arbeit baue, steht unter Apache-2.0. Lesen, forken, betreiben, weiterbauen — ohne Strings, ohne schleichendes Lock-in, ohne Hidden Core.
Methoden, nicht nur Ergebnisse
Ich veröffentliche nicht nur das Ergebnis, sondern den Weg dahin. Ein Befund ohne Methode ist nur Anekdote. Devlog und Forschungsergebnisse zeigen beides: den Weg und das Ziel.
Misserfolge dokumentiert
Was nicht funktioniert, ist mindestens so wichtig wie das, was funktioniert — manchmal mehr. Ich halte die Misserfolge fest, damit jemand, der das in einem Jahr liest, nicht denselben Umweg gehen muss.
Wissen bleibt offen
Nichts, was ich bei der Arbeit lerne, verschwindet hinter einer Bezahlschranke oder einem Beratervertrag. Was für andere nützlich ist, gehört in die Öffentlichkeit. Deshalb halte ich es offen.
05 — Wie ich Responsibility denke
Die Grundsätze, nach denen ich arbeite. Keine Unklarheit darüber, wer entscheidet.
Ich habe genau darüber nachgedacht, wo KI-Ausgaben aufhören und menschliches Urteil anfängt. Das sind keine rechtlichen Haftungsausschlüsse. Es sind Grundsätze, nach denen ich tatsächlich entwerfe.
Mensch entscheidet — immer
Jedes Ergebnis, mit dem ich arbeite, landet irgendwann an einem menschlichen Entscheidungspunkt. Ich entwerfe dafür. KI hilft; sie entscheidet nicht. Das ist ein Grundsatz, den ich einhalte, bevor er zur Anforderung wird.
Accountability follows Design
Der EU AI Act zieht eine klare Grenze zwischen Entwickler und Betreiber eines KI-Systems. Diese nehme ich ernst — nicht als Compliance-Last, sondern als Gestaltungsaufgabe. Das ist die Forschungsfrage meines Promotionsvorhabens.
“Ich trage die Gestaltung. Sie tragen die Entscheidung.”
06 — Über mich
Wer ich bin.
Ingenieurstudium, Feldpraxis
M.Sc. Wirtschaftsingenieurwesen, TH Mannheim, 2015. Ich führe KI-Einführungen in einer Organisation im industriellen Service — sprachbasierte Trainingsagenten, LLM-Evaluierung, EU-KI-Verordnung im mitbestimmten Betrieb. Die Randbedingungen dieses Sektors sind mein täglicher Kontext, nicht ein Briefing, das ich am Vorabend gelesen habe.
Research in Planung
Ich arbeite auf einen Dr.-Ing. an der Hochschule Heilbronn und der TH Mannheim hin — voraussichtlicher Start Q3 2026. Forschungsfrage: Wie werden LLM-basierte Trainingssysteme konzipiert, und wie vollzieht sich Technologieadoption im industriellen Service tatsächlich? Design-Science-Forschung, kombiniert mit einem Mixed-Methods-Ansatz.
Warum ich veröffentliche
Die Fragen, die mir wöchentlich begegnen, sind nicht nur meine. Fachleute in ähnlichen Positionen tragen dieselben Probleme — und brauchbare Antworten finden sich selten schriftlich. Diese Seite ist mein Versuch, das zu ändern. Code ist Apache-2.0. Nutzen Sie ihn.
Was ich gerade baueIn Development
Kleine Tools. Echte Entscheidungen. Hier dokumentiert.
Laufendes Log der kleinen, fokussierten Tools, die ich bau, um Ideas zu testen und öffentlich zu dokumentieren. Keine Client-Arbeit — meine eigene R&D. Zur Case Study.
- 01
Die Decision finden
Ich start mit der einen Frage, die actually beantwortet werden muss. Nicht das breiteste Problem — die schärfste Decision darin.
- 02
Die Data besorgen
Ich hol die Data, die für diese Decision zählen — Public Sources, eigene Measurements, was das System hergibt. Keine Assumptions ohne Beleg.
- 03
Klein bauen
Ein fokussiertes Tool, das genau diese Decision supported — nichts, was nicht gebraucht wird. Klein genug, um in einem Sprint zu shipp'n.
- 04
Dokumentieren
Method, Result und was nicht funktioniert hat — alles landet im Devlog. Die Arbeit zählt nur, wenn jemand anderes davon lernen kann.
First Tool
Commodity Intelligence
Identifiziert automatisch die fünf Rohstoffe, die im Direkteinkauf am meisten zählen, gewichtet nach Wertbeitrag, und tracked Spot- und Futures-Märkte — damit Buy- und Hedge-Decisions mit Evidence gemacht werden, nicht aus dem Bauch. Ein Tool für eine einzelne Decision — die Art, die ich für jedes Problem bau, das es wert ist.
Decision Support für Procurement Teams — keine Financial Advice.
Werkzeug ausprobierenSecond Tool
Component Setup Guide
Component nennen, optional Product-Page-URL droppen. Tool fetcht die Docs, resolved die exakte Variant, und backed jede Wiring-, Config- und Code-Claim mit dem, was actually gefunden wurde — mit explicit Refusals, wo Doku fehlt.
Experimental · Free Models · vor'm Verdrahten gegen Manufacturer-Datasheet checken.
Werkzeug ausprobierenThird Tool
Office Plant Care
Weather- und Season-aware Watering-Log für die Büro-Pflanzen — kleine, fokussierte Live-App auf dem Open Core, public readable. Ein Tool für eine einzelne Decision — dieselbe Art, die ich für jedes Problem bau, das es wert ist.
Live Demo · Public Read; Write nur fürs Team.
App ansehenFourth Tool
Plant Sandbox
Consequence-free Virtual Plant zum Pflegen. Gießen, Light anpassen, Overwatering, Recovery beobachten — aller State ist ephemeral. Gebaut, um das Sandbox-Prinzip zu demo: Ein falscher Click kostet nichts.
Public · No Auth · Reset on Reload — Safe Space zum Exploren.
Werkzeug ausprobierenWie du mit dem Open Code arbeiten kannst
Drei Wege, mit dem Open Code umzugehen.
Kein Tier-Model, das sich öffnet, wenn das Team wächst — der Code ist jetzt offen. Hier sind die drei sinnvollen Wege damit.
- Zuerst01
Community
Self-hosted — Open-Source-Core, eigene Keys, eigene Domain. Alles steht im Repo.
- Dann02
Devlog
Den Builds folgen — ich dokumentiere, was ich bau, warum und was nicht funktioniert hat. Laufend aktualisiert.
- Zuletzt03
Direkt
Direkt melden — für Questions, Context und Einschätzungen jenseits des Codes. Ich bin erreichbar.
08 — Kontakt
Melden Sie sich.
Wenn Sie an ähnlichem arbeiten — KI in der Produktion, LLM-Evaluierung, die KI-Verordnung in einer echten Organisation — höre ich gern zu. Ich antworte.
Ich erforsche für meine Promotion, wie KI-Integration in Industrieteams tatsächlich läuft — schreiben Sie es unten dazu, dann antworte ich bevorzugt.hello@apuna.dev
Antwort üblicherweise innerhalb eines Werktags