Unser Team Business Innovation & Entrepreneurship konnte in der vergangenen Woche das erste Modul unserer Plattform ausliefern: Ein Metallbaubetrieb aus Erlenbach stellt es seitdem in der Praxis auf die Probe. Aus einer Preisanfrage im PDF wird ein geprüftes Angebot — und die ersten Tests sehen sehr vielversprechend aus.
Wie das Modul arbeitet
Preisanfragen kommen als Leistungsverzeichnis herein: jeder Auftraggeber in einem anderen Vordruck, oft eingescannt, gelegentlich handschriftlich ergänzt. Bisher hieß das Positionen heraussuchen, Mengen abtippen, in der eigenen Kalkulationstabelle rechnen, Preise von Hand ins PDF eintragen. Pro Anfrage ein halber Arbeitstag. Bei Submissionen wiederholt sich der Vorgang für jeden Bieter, obwohl das Bauvorhaben dasselbe bleibt.
Der Aufwand steckt dabei weniger im Rechnen als im Lesen, Zuordnen und Übertragen. Dort entstehen auch die typischen Fehler: eine überlesene Angabe, eine falsch zugeordnete Position, ein Zahlendreher beim Abtippen. Genau an dieser Stelle setzt das Modul an.
Der Assistent übernimmt diesen Weg — ohne die gewachsene Kalkulation zu ersetzen. Er rechnet mit den echten Formeln aus den Preistabellen des Betriebs, nicht mit einer Nachbildung. Am Ende steht der komplette Satz Unterlagen je Vorgang, bis hin zum Original-Leistungsverzeichnis mit eingetragenen Preisen.
Der Ablauf ist in sieben Schritte gegliedert, vom Upload bis zum freigegebenen Angebot. Die Aufgabenteilung dahinter ist bewusst gewählt: Sprachmodelle erkennen und interpretieren, gerechnet wird deterministisch, freigegeben wird von einem Menschen.
Leistungsverzeichnis einlesen. Das LV-PDF wird hochgeladen; digitale PDFs werden direkt gelesen, Scans über die Texterkennung. Die Leiste darüber zeigt, dass Sprachmodell, Rechen-Engine, Texterkennung und Vektorsuche lokal angebunden sind.
Vier Punkte machen den Unterschied zwischen einem Vorschlag und einem prüfbaren Ergebnis:
Nachvollziehbarkeit
Jede erkannte Angabe bekommt einen Sicherheitswert. Unsichere Stellen werden markiert und bei Bedarf von einem zweiten Modell gegengeprüft, das seine abweichende Einschätzung daneben stellt. Zu jedem Wert lässt sich aufklappen, aus welcher Formulierung im Rohtext er stammt — der Bearbeiter sieht nicht nur das Ergebnis, sondern den Weg dorthin. Jede Korrektur fließt in die Erkennungsregeln zurück.
Positionen prüfen und bestätigen. Je Posten stehen Menge, Geländertyp, Höhe, Befestigung und Beschichtung mit einem Sicherheitswert. Aufgeklappt zeigt das Modul, welche Formulierung im Rohtext zu welchem Wert geführt hat; unsichere Angaben gehen an die KI-Zweitmeinung.
Entscheidungen mit Vorbehalt
Wo das Leistungsverzeichnis keine eindeutige Angabe hergibt — etwa bei der Frage, ob ein Geländer geradlinig oder im Radius verläuft — greift eine hinterlegte Standardregel mit der sicheren Annahme. Der Bearbeiter bestätigt oder überschreibt sie, und die Entscheidung wird am Posten dokumentiert.
Beschichtungspartner und Transport
Für jeden hinterlegten Partnerbetrieb wird die tatsächliche Route zur Baustelle berechnet und daraus der Transportanteil abgeleitet. Beide Varianten werden vollständig durchgerechnet, statt sie zu schätzen; vorgeschlagen wird der günstigere Weg.
Freigabe als Pflichtschritt
Ohne fachliche Freigabe gibt es keinen Export. Erst danach entstehen die interne Fassung, eine gesperrte Fassung für den Auftraggeber, das Protokoll und der Entwurf der Antwort-Mail.
Angebot prüfen und freigeben. Die Ampel steht hier auf Gelb und nennt den Grund gleich mit. Einzelpreise sind direkt editierbar, Korrekturen wirken sofort auf Summe und Dokument. Ohne gesetztes Häkchen gibt es keinen Export.
Alle Abbildungen zeigen einen Demo-Datensatz. Bauvorhaben, Auftraggeber, Partnerbetriebe und Preise sind frei erfunden.
Was sich auf andere Betriebe übertragen lässt
Das Modul ist kein Einzelstück für einen einzigen Betrieb. Der Ablauf dahinter ist generisch: Dokument einlesen, Positionen erkennen, Ergebnis prüfen, Angebot erzeugen. Diese Kette funktioniert überall dort gleich, wo aus Ausschreibungsunterlagen ein kalkuliertes Angebot werden muss.
Unternehmensspezifisch ist das, was fachlich ohnehin individuell ist: die Kalkulationslogik mit ihren Formeln und Zuschlägen, die hinterlegten Preisgrundlagen, die Standardannahmen bei unklaren Angaben und einzelne Schritte im Workflow. Genau diese Punkte werden bei einer Übertragung angepasst und implementiert. Alles andere läuft unverändert weiter. Der Weg zum eigenen Modul führt also nicht über eine Neuentwicklung, sondern über das Einpflegen der eigenen Regeln.
Und weil die Berechnung ohnehin deterministisch abläuft, bleibt die Kalkulationshoheit dort, wo sie hingehört: im Betrieb. Für andere Gewerke mit vergleichbaren Ausschreibungsprozessen gilt dasselbe Prinzip, nur mit anderen Positionstypen und anderen Regeln.
Ein Modul, keine Insellösung
Der Angebots-Assistent ist bewusst kein eigenständiges Programm, sondern ein Modul auf unserer Plattform. Das ist kein technisches Detail, sondern der eigentliche Hebel: Dokumente einlesen, in den eigenen Unterlagen nachschlagen, Sprachmodelle vor Ort betreiben, Rechte vergeben, jeden Schritt protokollieren — das alles steckt in der Plattform und nicht im Modul. Ein neues Modul beginnt deshalb nicht bei null. Es erbt diese Grundlage und muss nur noch mitbringen, was fachlich wirklich eigen ist: die Regeln des jeweiligen Gewerks.
Für den Betrieb heißt das: eine Installation, ein Zugang, eine Stelle für Rechte und Protokoll — auch dann, wenn später ein zweites oder drittes Modul dazukommt. Auf derselben Grundlage entstehen bereits Assistenten für andere Gewerke; was einer von ihnen an Erkennung, Wissensverwaltung oder Prüfmechanik gewinnt, steht den übrigen offen. Und weil die Plattform im Haus des Betriebs läuft, gilt die Datensouveränität nicht je Werkzeug, sondern für alles, was darauf aufsetzt.
Drei Ziele, die die Bauweise bestimmt haben
Die KI erkennt, die Maschine rechnet
Ein Sprachmodell liest den Vordruck und ordnet Positionen zu. Einen Preis erfindet es nie — der kommt aus der hinterlegten Kalkulation und ist jederzeit nachrechenbar.
Nichts verlässt das Haus
Die Plattform läuft vor Ort auf eigener Hardware, mit lokalen Modellen. Preise, Margen und Daten der Auftraggeber gehen an keinen Cloud-Anbieter. Das ist keine Einstellung, sondern die Architektur.
Unsicherheit wird sichtbar
Wo die Erkennung unsicher ist, sagt sie das — statt zu raten. Eine Ampel je Position zeigt dem Betrieb, wo genau hingeschaut werden muss.
Die ersten Ergebnisse
Gemessen wird nicht am Wunsch, sondern an fertig ausgefüllten Angeboten aus dem Archiv des Betriebs: Der Prüfstand rechnet echte Altaufträge komplett neu und vergleicht dort, wo ein belastbarer Sollwert vorliegt, Position für Position mit dem, was damals beim Auftraggeber lag.
Warum uns die rote Lampe am wichtigsten ist
Ein Angebot ist eine verbindliche Erklärung gegenüber einem Auftraggeber. Ein Werkzeug, das immer selbstbewusst antwortet, ist deshalb gefährlicher als eines, das zugibt, wo es unsicher ist. Jede Position bekommt eine Farbe:
Dass es Rot überhaupt gibt, ist kein Eingeständnis, sondern das Versprechen: lieber eine Position ehrlich offen lassen, als eine plausibel aussehende Zahl beim Auftraggeber landen zu lassen.
Was das Modul nicht tut
Das Modul ersetzt weder die Kalkulation noch die fachliche Einschätzung. Es entscheidet nicht, ob ein Angebot abgegeben wird, es setzt keine Preise fest und es verändert die Regeln nicht selbstständig. Sonderfälle, die im Leistungsverzeichnis nicht sauber beschrieben sind, bleiben Sache des Bearbeiters. Der Anspruch ist ein anderer: die immer gleiche Vorarbeit abnehmen und dabei jeden Schritt prüfbar halten.
Und jetzt: die Testphase
Grün im Prüfstand heißt: Was wir prüfen konnten, stimmt. Es heißt nicht, dass wir alles geprüft hätten. Der Alltag bringt, was wir noch nicht kennen — Vordrucke, die wir nie gesehen haben, Sonderpositionen, Formulierungen, auf die niemand kommt, der die Software baut. Genau darauf sind wir gespannt.
In der Testphase arbeitet das Team des Betriebs mit echten Anfragen aus dem Tagesgeschäft und vergleicht das Ergebnis mit der gewohnten Vorgehensweise. Im Fokus stehen die Erkennungsqualität bei unterschiedlich formulierten Leistungsverzeichnissen, die Verständlichkeit der Prüfschritte und die Frage, an welchen Stellen die Vorschläge regelmäßig korrigiert werden müssen. Der Test läuft über mehrere Wochen im laufenden Betrieb; danach entscheiden wir gemeinsam über den nächsten Schritt — weitere Positionstypen, die Übertragung auf andere Betriebe oder den Produktivbetrieb.
Ernste Fehler haben wir in der letzten Runde noch selbst gefunden und behoben, bevor jemand damit arbeiten musste. Wir gehen fest davon aus, dass der Praxisbetrieb weitere Dinge zutage fördert — jede davon wird zu einer neuen Prüfung, die von da an dauerhaft mitläuft.
Was uns dabei am meisten freut, ist ohnehin keine Kennzahl. Es sind die Rückmeldungen nach den ersten Durchläufen im Betrieb: alle konkret, alle aus dem echten Arbeiten heraus, von abgeschnittenen Ortsnamen bis zu Anmerkungen an der einzelnen Position. Sie sind umgesetzt. So sieht es aus, wenn ein Werkzeug ankommt.
Wie der Anwendungsfall entstanden ist
Der Anwendungsfall stammt nicht vom Reißbrett. Er ist in der Zusammenarbeit mit einem mittelständischen Betrieb aus der Region entstanden, der seinen Angebotsprozess offengelegt, seine Kalkulationslogik erklärt und über Monate hinweg Rückmeldung gegeben hat. Genau so verstehen wir unseren Auftrag: KI-Anwendungsfälle nicht beschreiben, sondern gemeinsam mit den Unternehmen bauen und in der Praxis erproben.
Unser Fazit
Der spannendste Teil beginnt jetzt, wo das Modul auf echte Ausschreibungen trifft statt auf ausgewählte Testfälle. Was wir bis hierhin gelernt haben: Ein KI-System wird im Handwerk nicht dadurch nützlich, dass es möglichst viel selbst entscheidet, sondern dadurch, dass jeder Schritt prüfbar bleibt und der Betrieb die Kontrolle behält. Wir bedanken uns bei unserem Praxispartner für die Offenheit, ein solches System im laufenden Geschäft zu erproben, und berichten über die Ergebnisse.
Autor: Yannick Kreppein