LLMs im BIM: Warum Sprachmodelle belastbare Werkzeuge statt freier IFC-Magie brauchen

Praktisches Problem

In vielen BIM-Projekten liegt das praktische Problem nicht darin, dass zu wenig Daten vorhanden sind, sondern dass deren Nutzung zu langsam, zu fehleranfällig und zu stark von Spezialwissen abhängig ist. Wer etwa wissen möchte, welche Türen ohne Brandschutzklassifikation in Fluchtwegen liegen, welche Bauteile einer Kostengruppe fehlen oder welche Wand nach einer Planänderung angepasst werden muss, braucht heute oft Modellviewer, IFC-Kenntnisse, Skripte oder manuelle Prüfprozesse. Sprachmodelle versprechen hier eine natürlichere Schnittstelle: „Prüfe die Geschosshöhen“, „lege einen Raum an“, „ändere alle Fenster im Bauteiltyp X“. Genau an dieser Stelle entsteht aber ein Risiko. Wenn ein Modell nur frei formulierte Antworten erzeugt, statt kontrolliert auf definierte BIM-Funktionen zuzugreifen, bleiben Ergebnisse schwer überprüfbar und Änderungen potenziell gefährlich. Der Forschungsimpuls adressiert daher die Lücke zwischen komfortabler Spracheingabe und belastbarer Modelloperation. Für produktive BIM-Workflows muss klar sein, welche Funktion ausgeführt wurde, auf welche IFC-Objekte sie zugreift, ob Berechtigungen vorliegen, welche Regel verletzt oder erfüllt wurde und wie eine Änderung rückgängig oder auditiert werden kann. So wird aus einem Chatbot kein Ersatz für BIM-Software, sondern eine sichere Bedienebene für prüfbare Abfragen, Modelländerungen und Qualitätssicherung im Bauprozess. Was die Forschungsidee verstaendlich macht Die Grundidee ist leicht zu verstehen: Das Sprachmodell soll nicht frei in einer BIM-Datei „herumschreiben“, sondern wie ein Assistent arbeiten, der klar definierte Werkzeuge benutzt. Statt eine IFC-Datei als langen Text zu erraten, bekommt es Funktionen an die Hand: Bauteile suchen, Eigenschaften auslesen, Räume anlegen, Attribute ändern, Beziehungen prüfen oder Mengen berechnen. Jede Aktion läuft über eine Schnittstelle mit festen Eingaben und Ausgaben. So wird aus einer vagen Anweisung wie „zeige mir alle Brandschutztüren im zweiten Obergeschoss“ ein nachvollziehbarer Aufruf, der das Modell gezielt durch das Gebäudemodell führt. Für die Praxis ist das entscheidend, weil BIM-Daten keine Chat-Antworten sind, sondern Planungsgrundlagen. Wenn ein Modell etwas ändert, muss klar sein, was geändert wurde, wer es durfte, ob die Änderung gültig ist und ob sie wieder zurückgenommen werden kann. Die Forschungsidee macht deshalb sichtbar, dass LLMs im BIM-Kontext weniger als allwissende Textgeneratoren gedacht werden sollten, sondern als sprachliche Bedienebene über belastbaren Werkzeugen. Sprache wird zum Einstieg, die eigentliche Arbeit erledigen geprüfte Funktionen mit Rechten, Regeln, Protokollen und Validierung. Was heute schon als Arbeitsprinzip nuetzlich ist Nützlich ist heute vor allem das Arbeitsprinzip: Das Sprachmodell sollte nicht „frei“ am Modell operieren, sondern definierte BIM-Werkzeuge aufrufen. Für BIM-Manager heißt das, Anwendungsfälle in klare Funktionen zu übersetzen: Räume abfragen, Bauteile nach Eigenschaften filtern, Mengen berechnen, Parameter ändern, Prüfregeln ausführen. Jede Funktion braucht feste Eingaben, Rechte und eine nachvollziehbare Ausgabe. Für die Kalkulation entsteht dadurch ein belastbarer Weg von der Frage zur Menge: Nicht das Modell schätzt, sondern es stößt eine geprüfte IFC-Abfrage an, dokumentiert Filter, Annahmen und Version des Modells. AEC-Tech-Teams sollten dafür eine Zwischenschicht bauen, die Modellzugriff, Berechtigungen, Validierung und Logging kapselt. Entscheidend ist, dass Änderungen nie nur als Textvorschlag enden, sondern als überprüfbare Operation mit Vorher-Nachher-Protokoll, Konfliktprüfung und Freigabe. So wird aus dem LLM kein Ersatz für BIM-Autorensoftware, sondern ein bedienbarer Assistent für wiederholbare Workflows: schneller beim Finden, Strukturieren und Vorbereiten, aber begrenzt durch Regeln, Rollen und Datenqualität. Der produktive Einstieg liegt daher nicht im großen Autopiloten, sondern in kleinen, messbaren Prozessen mit klarer Haftungskette. Was noch riskant oder ungeloest ist Noch ist der Weg in produktive BIM-Prozesse mit LLMs nicht risikofrei. Sprachmodelle können Befehle plausibel formulieren, aber trotzdem falsche Bauteile auswählen, Mengen missverstehen oder Änderungen vorschlagen, die gegen Modellierungsrichtlinien, Fachplanungslogik oder vertragliche Zuständigkeiten verstoßen. Entscheidend ist deshalb, dass jede Aktion über klar definierte Werkzeuge läuft, mit Berechtigungen, Prüfregeln und nachvollziehbaren Änderungsprotokollen. Auch die Datenqualität bleibt ein Engpass: Uneinheitliche Property-Sets, fehlende Klassifikationen, doppelte Objekte oder projektspezifische Namenskonventionen können zu falschen Abfragen und unvollständigen Ergebnissen führen. Validierung muss daher nicht erst am Ende erfolgen, sondern vor, während und nach jeder Modelländerung, idealerweise gegen IFC-Schema, IDS, Modellierungsrichtlinien und projektspezifische Prüfsets. Offen ist zudem die Haftungsfrage: Wer verantwortet eine automatisiert erzeugte Türliste, eine geänderte Brandschutzklassifikation oder eine fehlerhafte Mengenbasis? Ohne Rollenmodell, Freigabeworkflows und Audit Trail bleibt der Einsatz heikel. Interoperabilität ist ebenfalls nicht gelöst, weil IFC zwar die gemeinsame Grundlage bildet, Autorentools, Exporteinstellungen und Fachdomänen jedoch unterschiedlich interpretieren. LLMs können hier helfen, aber sie ersetzen keine robuste Prozessarchitektur. Bezug zu Proxino, IFC, GAEB und Pruefung Für Proxino und BIMraum ist der entscheidende Punkt: Ein Sprachmodell darf im BIM-Kontext nicht „frei formulieren“, sondern muss über klar definierte Werkzeuge auf IFC-Daten, BIM-Objekte, Mengen und Kostenpositionen zugreifen. Wenn ein Nutzer fragt, welche Bauteile in einer Leistungsposition enthalten sind oder warum eine Menge von der GAEB-Ausschreibung abweicht, braucht das System nachvollziehbare Funktionen: IFC-Elemente lesen, Klassifikationen prüfen, Mengenregeln anwenden, Positionen semantisch matchen und Ergebnisse mit Belegstellen zurückgeben. So wird aus einer sprachlichen Anfrage ein prüfbarer Workflow. Proxino kann dabei die Brücke zwischen Modell, LV und Prüfung schlagen: Wand-, Decken- oder Tür-Objekte werden nicht nur benannt, sondern mit Eigenschaften, Mengen, Räumen, Kostengruppen und GAEB-Positionen verknüpft. Semantisches Matching hilft, unterschiedliche Bezeichnungen aus Planung und Ausschreibung zusammenzuführen, ersetzt aber nicht die Validierung. Gerade deshalb sind Rechte, Versionsstände und Prüfprotokolle zentral. Jede Änderung an IFC-Attributen, jede Zuordnung zu einer Kostenposition und jede Mengenübernahme muss rückverfolgbar bleiben. Nur so entsteht ein belastbarer digitaler Prüfprozess statt einer plausibel klingenden Antwort.