Automatisierte Compliance-Prüfung von Dokumenten gegen Regelwerke (z. B. Baugenehmigungen)

Behörden und Compliance-Teams verbringen einen großen Teil ihrer Zeit damit zu prüfen, ob eine Einreichung vollständig ist und einem Regelwerk entspricht: Sind alle erforderlichen Unterlagen vorhanden, hält die angegebene Geschossflächenzahl den Bebauungsplan ein, enthält die Meldung die verpflichtenden Angaben? KI liest die Einreichung, ordnet jeder Regel einen Nachweis zu und liefert eine nachvollziehbare Liste von Feststellungen. Die Entscheidung bleibt beim Menschen; die KI verkürzt die Prüfung und macht sie einheitlich.

Problem & Nutzen

• Heute: Sachbearbeitende lesen Hunderte Seiten Formulare, Pläne und Erklärungen und prüfen sie gegen Bauordnungen, örtliche Bebauungspläne oder interne Richtlinien. Unvollständige Anträge gehen hin und her; Regeln werden mit unterschiedlicher Strenge angewandt; das Wissen steckt in wenigen erfahrenen Köpfen.
• KI-Nutzen: automatische Vollständigkeitsprüfungen, erste Konformitätsfeststellungen mit Nachweis, einheitliche Anwendung derselben Regelversion, Entwürfe für Mängelschreiben.
• Evidenz (vom Hersteller berichtet, als Richtwert behandeln): Archistars AI PreCheck (früher eCheck) nennt „bis zu 55 % weniger Prüfzyklen bei Genehmigungen“; Los Angeles County führt eine Verringerung der Bearbeitungszeit für Pläne um 54 % an und Austin rund 50 % Zeitersparnis bei der Zonierungsprüfung [3]. Diese Angaben stammen von der Herstellerseite; eine unabhängige Bewertung wurde nicht gefunden.
• Politischer Rückenwind: Das Horizon-Europe-Projekt ACCORD (2022–2025) hat einen semantischen Rahmen, ein Werkzeug zur Formalisierung von Regeln und Micro-Services zur Compliance-Prüfung für die digitale Baugenehmigung entwickelt und in fünf Regelungskontexten demonstriert (UK, Finnland, Estland, Deutschland, Spanien) [1]. Eine Anfrage im Bundestag vom Juli 2026 betrachtet die automatisierte Prüfung der Regelkonformität als nächsten Schritt nach dem digitalen Bauantrag „Einer-für-Alle“ [2].

Varianten

• Baugenehmigungen (Vorzeigefall): Vollständigkeitsprüfung des Antragspakets, danach Konformitätsprüfungen von Plänen oder BIM-Modellen gegen Bauordnung, Bebauungsplan, Brandschutz- und Barrierefreiheitsregeln.
• Unterstützung der Baukontrolle vor Ort: Informationen aus digitalen Bauakten extrahieren, um Kontrollen vorzubereiten und Berichte zu entwerfen (Pilot TUM / Landratsamt Ostallgäu, April 2025–März 2026) [4].
• Weitere Genehmigungen und öffentliche Einreichungen: Umweltgenehmigungen, Veranstaltungsgenehmigungen, Förderanträge (Vorprüfung von Vollständigkeit und Berechtigung; die Entscheidung selbst ist AGENT-026).
• Unternehmens- und Aufsichtsmeldungen: Prospekte, Jahresberichte, ESG-/CSRD-Angaben, Ausschreibungsantworten (DOC-015) oder Lieferantenunterlagen gegen eine Checkliste verpflichtender Inhalte prüfen.
• Richtlinien-Compliance im Unternehmen: Spesenabrechnungen, Personalunterlagen, Qualitätsdossiers, technische Dokumentation gegen interne Richtlinien oder Normen (für Nischen wie Etiketten/Zertifikate siehe DOC-019, DOC-027).
• Private Nutzung: Antragstellende führen vor der Einreichung eine Vorprüfung durch (z. B. beim Bauantrag eines Eigenheimbesitzers).

So funktioniert es

1. Einreichung (PDF-Satz / Formulare / IFC-Modell)
2. Dokumentklassifikation & Vollständigkeit (was ist für dieses Verfahren erforderlich?)
3. Parsing: OCR + Layout, Extraktion von Tabellen und Zeichnungsbeschriftungen; IFC-Lesen über Geometrie-/Eigenschafts-API
4. Regelbasis: Regeln als (a) deterministischer Code/Abfragen (b) abgerufene Textklauseln mit Version + Rechtsraum
5. Auswertung je Regel: numerische/geometrische Regel
6. deterministische Prüfung auf extrahierten Werten oder dem BIM-Modell auslegungsbedürftige Regel
7. LLM mit abgerufener Klausel + Belegstellen, begründetes Urteil mit Quellen
8. Befund = {Regel-ID & Version, Urteil, Beleg Seite/Bereich, Konfidenz, Begründung}
9. menschliche Prüfung (Sachbearbeitung bestätigt, übersteuert oder fragt Antragsteller nach)
10. Bericht / Mängelschreiben, Audit-Log, Archiv

• Zwei Arten von Regeln. Quantitative Regeln (Abstände, Flächen, Höhen) sollten formalisiert und deterministisch ausgeführt werden, entweder am BIM-Modell mit IDS-/Model-Checker-Regeln oder in einer Regel-Engine (z. B. Rego/OPA [8]). Interpretative Regeln („angemessen“, „fügt sich in den Charakter der Umgebung ein“) behandelt ein LLM, das die Klausel und den Nachweis zitieren muss und „unklar“ ausgibt, statt zu raten.
• Die Formalisierung der Regeln ist der eigentliche Engpass: Das Werkzeug zur Regelformalisierung und die Regelsatz-Datenbank von ACCORD adressieren genau das [1]. Die buildingSMART Information Delivery Specification (IDS) ist ein XML-Standard, um IFC-basierte Informationsanforderungen maschinenlesbar zu formulieren [6].
• Mensch-in-der-Schleife (Human-in-the-Loop): Jede negative Feststellung und jedes „unklar“ geht an eine Person; positive Feststellungen werden stichprobenartig geprüft. Entscheidungen (Genehmigung, Ablehnung) werden nie vom System erlassen.

Datenaufbereitung

Zwei Datenbestände müssen aufbereitet werden: die Einreichungen und das Regelwerk. Einreichungen kommen als PDF-Pläne, Formulare, Berechnungen und teils IFC-Modelle über Portale, E-Mail oder Papier; sie liegen im DMS, im Fachverfahren oder auf Dateiablagen. Das Regelwerk ist verstreut über Gesetze, Bebauungspläne, Normen, interne Richtlinien und die Köpfe erfahrener Prüfer. Typische Lücken: Regeln in Prosa mit Ausnahmen, mehrere gültige Fassungen je nach Stichtag, gescannte Pläne, uneinheitliche Benennung von Anlagen und keine maschinenlesbare Erfassung früherer Entscheidungen.

Schritte: (1) das Regelwerk in atomare, nummerierte Regeln mit Quellenzitat und Gültigkeitsdatum überführen, siehe PREP-014 und PREP-012; (2) die Vollständigkeits-Checkliste je Verfahrensart festlegen, siehe PREP-019; (3) Einreichungen mit einem Layout-Parser verarbeiten, siehe DOC-014; (4) frühere Fälle mit Ergebnissen als Labels sammeln, siehe PREP-020; (5) erfahrene Prüfer ein Testset aufbauen lassen, siehe PREP-018; (6) Daten der Antragstellenden im Testmaterial pseudonymisieren, siehe PREP-022. Werkzeuge: Docling oder eine OCR-API, eine Regeltabelle, ein Vektorspeicher. Rechnen Sie mit 40-50 % des Aufwands für die Strukturierung der Regeln und die Testsets.

Umsetzungswege

Welcher Weg für wen

• KMU: Weg B — eigene Regelwerke und Checklisten müssen eingebunden werden, und kein ausgereiftes KMU-Produkt passt; beginnen Sie mit einem schmalen Regelsatz auf in der EU gehosteten APIs.
• Großunternehmen: Weg B — Regel-Engines, Workflow und Prüfprotokoll lassen sich in bestehende Compliance-Systeme integrieren; Weg C, sobald Menge oder Sensibilität wachsen.
• Öffentliche Hand: Weg C — Behörden verarbeiten Bürgerdaten und treffen Entscheidungen mit Rechtswirkung, daher wiegen souveränes Hosting, Vergaberegeln und volle Kontrolle über das Prüfprotokoll schwer; eine souveräne Cloud (Weg B) ist die Übergangslösung.
• Entwickler: Weg B — Pipelines von Regel zu Nachweis auf API-Modellen aufbauen und sensible Teile später auf Weg C verlagern.

Weg A — Kaufen (Standardsoftware)

• BIM-Regelprüfung: Solibri (Helsinki, Nemetschek; regelbasierte BIM-Qualitätssicherung mit Stufen, darunter eine Air-Gap-Ausgabe „Security+“ und ein KI-Assistent) [5]. Aus der EU, bei Planenden weit verbreitet; wird eher auf Seiten der Antragstellenden/Planenden genutzt als als Behörden-Workflow.
• Prüfung von Genehmigungsplänen: Archistar AI PreCheck (Australien/Kanada/USA; Upload von PDF, CAD oder BIM, Berichte mit erfüllt/nicht erfüllt) [3]; die deutschen Anbieter BIM.permit und Baumind (BIM-Modellprüfungen gegen Bauvorschriften; Herstellerangaben hier nicht verifiziert).
• Fachverfahren für Genehmigungen in deutschen Verwaltungen (digitaler Bauantrag über den EfA-Dienst, kommunale Fachsoftware) ergänzen Vollständigkeitsprüfungen; fragen Sie Ihren Softwarelieferanten.
• Unternehmensnutzung: GRC- und Regulatory-Intelligence-Suiten mit Dokument-Checklisten; Vertrags-/Klauselwerkzeuge wie die Anbieter aus DOC-009 für Richtlinienprüfungen.
• A wählen, wenn: das Gebiet von einem Produkt abgedeckt ist, in dem die Regeln Ihrer Rechtsordnung bereits hinterlegt sind. Die Regeln der deutschen Landesbauordnungen (16 Landesbauordnungen) unterscheiden sich, prüfen Sie also die Abdeckung je Bundesland.

Weg B — Auf Cloud-KI-Diensten aufbauen (empfohlene Standardwahl für Piloten)

• Parsing: Azure AI Document Intelligence (Layout, EU-Regionen), Mistral OCR / Document AI (EU-Anbieter), Google Document AI; oder ein VLM, das Planblätter direkt liest.
• Schlussfolgerung: ein Reasoning-Spitzenmodell mit langem Kontext (Claude, Gemini, GPT, Mistral Large) über Endpunkte in EU-Regionen; schemabeschränkte Ausgabe der Feststellungen; Retrieval über Regelwerke (Embeddings + Reranker + Vektordatenbank).
• Orchestrierung: ein Agent, der plant, welche Regeln gelten, deterministische Prüfwerkzeuge (Geometrie, Arithmetik, Nachschlagen) aufruft und das LLM nur für interpretative Regeln einsetzt; Workflow-Engine (n8n, Camunda, Power Automate).
• B wählen, wenn: Sie eigene Regelwerke und schnelle Iteration brauchen und Daten rechtlich in eine EU-Cloud gehen dürfen. Öffentliche Stellen brauchen oft zuerst einen Auftragsverarbeitungsvertrag und ein freigegebenes Hosting.

Weg C — Selbst betreiben (Open Source)

• Parsing: Docling (MIT, LF AI & Data; PDF-Layout, Tabellen, lokale/Air-Gap-Nutzung) [7], PaddleOCR-VL, MinerU.
• BIM: IfcOpenShell (LGPL; enthält ifctester für IDS-basierte Modellprüfung) [6]; Bonsai (Blender) zur Ansicht.
• Schlussfolgerung: Open-Weight-Modelle mit 30–120B (z. B. Qwen3, gpt-oss, offene Gewichte der Klasse Mistral Medium/Large, Llama-Familie) über vLLM; Embeddings + Reranker (BGE, Qwen3-Embedding) mit pgvector/Qdrant; Regeln als Code oder Rego [8].
• Hardware: HW3 (eine GPU mit 48–141 GB) für ein Modell mit ~70–120B und langem Kontext plus ein VLM; HW2 genügt für Vollständigkeitsprüfungen und kleinere Modelle. Warum C: Kommunen und Ministerien mit Souveränitätsanforderungen. Der Betriebsaufwand ist erheblich, weil die Regelbasis dauerhaft gepflegt werden muss.

Weg D — Eigenes Training

Lohnt sich vor allem für (1) einen feingetunten kleinen VLM/Klassifikator zur Klassifikation von Dokumenttypen und Planblättern anhand tausender gelabelter früherer Anträge, (2) das Training eines Extraktors für Symbole und Maßangaben in Plänen oder (3) einen Retrieval-Reranker auf dem eigenen Regelwerk. Frühere Akten mit bekanntem Ergebnis sind die Datenquelle – beachten Sie aber die DSGVO unten. Trainieren Sie kein Modell, das Genehmigungsentscheidungen aus früheren Akten vorhersagt; das wirft Fragen zu Verzerrung und Recht auf (siehe Risiken).

Stand der Technik (2026)

• Hybrid neuro-symbolisch ist der Konsens: Regeln formalisieren, wo es möglich ist (IDS, Regel-Engines, Ontologien wie in ACCORD [1]), und LLMs für Parsing, Retrieval, Auslegung unscharfer Klauseln und Entwürfe nutzen. Das reine „Frage das LLM, ob der Plan konform ist“ ist für rechtliche Prüfungen nicht zuverlässig genug.
• Vorsicht der Regulierer selbst: Eine Expertenbefragung von Regulierern aus 2025 nennt mehrdeutige Begriffe, uneinheitliche Regeln und die Frage, wie viel menschliche Aufsicht bleiben soll, als Haupthürden der automatisierten Compliance-Prüfung (Zusammenfassung über EC3 [9]). Digitale Regelwerke sind die Voraussetzung, nicht das Modell.
• BIM-basierte Prüfung ist der reife, deterministische Weg, wenn Antragstellende IFC-Modelle liefern; 2D-PDF-Pläne erfordern weiterhin eine bildbasierte Auswertung der Zeichnungen, die bei Maßen, Maßstäben und Symbolen fehleranfällig ist (siehe DOC-013).
• Grenzen und Fehlerbilder: halluzinierte Regelzitate; veraltete oder falsche Rechtsordnung/Version einer Regel; falsch gelesene Maße; fehlende Nachweise, die als Konformität gedeutet werden; Übervertrauen bei unscharfen Klauseln; Automatisierungsverzerrung (Automation Bias) bei Prüfenden. Gegenmaßnahmen: versioniertes Abrufen von Regeln, verpflichtende Nachweisverweise, „unklar“ als zulässiges Ergebnis, Regressionstestsets aus realen früheren Fällen und Stichproben durch Prüfende.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack (ocr-docparse + vlm + llm-reasoning + Retrieval): DOC-009 Extraktion von Vertragsklauseln, DOC-010 Prüfung und Redlining, DOC-014 PDF-zu-strukturierte-Daten-Parsing für RAG, DOC-015 Extraktion von Ausschreibungsanforderungen, DOC-013 Verstehen technischer Zeichnungen, DOC-027 Etikettenprüfung. Ein HW3-Server mit einem VLM, einem LLM und einem Vektorspeicher kann sie alle bedienen.
• Vorgelagert: DOC-003 (Formular- und Antragsverarbeitung) für die Aufnahme; DOC-008 Klassifikation der eingereichten Dateien.
• Nachgelagert: AGENT-026 (Sachbearbeitungs-Agent, der Entscheidungen entwirft und fehlende Unterlagen anfordert) nutzt die Feststellungen; Bürger-Assistenten nach Art von CONV können Mängelschreiben erklären; LANG-024 übernimmt die analoge Prüfung für Werbeaussagen.
• Gemeinsame Bausteine: versioniertes Regel-Repository (Rechtstext + formalisierte Regeln), Viewer mit Nachweisverknüpfung, Prüfprotokoll, Workflow-Engine.

Aufwand, Kosten & Kennzahlen

• Weg A: Wochen bis Monate (Regelabdeckung und Integration in das Genehmigungssystem dominieren).
• Weg B: 3–6 Monate für eine Verfahrensart; die Hauptkosten sind Regelformalisierung und Aufbau des Testsets, nicht Tokens.
• Weg C: 6–12 Monate einschließlich Infrastruktur; ein HW3-Server plus Betriebspersonal.
• Weg D: erst, wenn die Pipeline läuft; zusätzlicher Annotationsaufwand.
• Kennzahlen: Präzision/Recall der Vollständigkeitsprüfung gegenüber Expertenurteilen; Anteil der von Prüfenden akzeptierten Feststellungen; Prüfzeit je Fall; Zahl der Korrekturschleifen je Antrag; Quote vollständiger Erst-Einreichungen; Regelabdeckung in Prozent; Uneinigkeitsquote zwischen Prüfenden vorher/nachher.

Menschen & Veränderung

Früh einbinden: Geschäftsführung bzw. Behördenleitung, die Abteilungsleitung (Prozessverantwortung), Sachbearbeitende und erfahrene Prüfer als Regelautoren und Tester, Recht für Haftungs- und verwaltungsrechtliche Fragen, die IT und der/die Datenschutzbeauftragte. Antragstellende oder Kunden sollten transparent darüber informiert werden, dass automatisierte Vorprüfungen eingesetzt werden.

Betriebsrat / Personalrat: hängt vom Einzelfall ab. Die Regelprüfung allein überwacht keine Beschäftigten, wohl aber Protokolle des Fachverfahrens und Prüfstatistiken, daher greift voraussichtlich §87 Abs. 1 Nr. 6 BetrVG (in Behörden der Personalrat nach BPersVG/Landesrecht); §90 Abs. 1 Nr. 3 gilt in jedem Fall, und ein Sachverständiger nach §80 Abs. 3 kann hinzugezogen werden. Datenschutz: Daten der Antragstellenden sind personenbezogen; AVV, Rechtsgrundlage und Datenschutzbeauftragte(r) sind nötig; für die systematische Auswertung ist voraussichtlich eine DSFA erforderlich, siehe GUIDE-005. KI-Verordnung (AI Act): Die Einstufung hängt von der Nutzung ab, siehe GUIDE-014.

KI-Kompetenz: Unterstützen Sie Prüfende mit Schulungen, Feststellungen zu lesen und unzuverlässige zu erkennen. Pilot: eine Fallart im Parallelbetrieb, mit gemessener Übereinstimmung. Bedenken: Verlust von Ermessen und Haftung – die KI schlägt nur vor; der Mensch entscheidet, und Abweichungen werden als Rückmeldung protokolliert. Siehe GUIDE-004 und GUIDE-008.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act) (depends): Anhang III nennt Baugenehmigungen als solche nicht. Nr. 5 Buchst. a erfasst Systeme zur Bewertung der Anspruchsberechtigung für wesentliche öffentliche Unterstützungsleistungen und Dienste [10]; eine Prüfung der Berechtigung für Leistungen/Förderungen ist daher Hochrisiko, während eine reine Vollständigkeits- oder technische Konformitäts-Vorprüfung zur Unterstützung einer menschlichen Prüfung in der Regel kein Hochrisiko ist (Ausnahme nach Art. 6 Abs. 3 für eng begrenzte Verfahrens- oder Vorbereitungsaufgaben, die der Anbieter dokumentieren muss). Die Einstufung erfordert eine rechtliche Prüfung im Einzelfall; dies ist keine Rechtsberatung. In allen Fällen gilt die KI-Kompetenz nach Art. 4; bei Hochrisiko gelten Art. 9–15 (Risikomanagement, Daten-Governance, Protokollierung, menschliche Aufsicht). In der typischen Form keine verbotene Praxis.
• Verwaltungsrecht (Deutschland): §35a VwVfG erlaubt vollständig automatisierte Verwaltungsakte nur, wenn weder Ermessen noch Beurteilungsspielraum besteht; belassen Sie Entscheidungen bei der Sachbearbeitung und geben Sie Gründe an (§39 VwVfG). Andere EU-Staaten haben gleichwertige Regeln.
• DSGVO: Anträge enthalten personenbezogene Daten von Antragstellenden, Nachbarn und Planenden; nötig sind eine Rechtsgrundlage (öffentliche Aufgabe), ein Auftragsverarbeitungsvertrag und keine Weiterverwendung von Akten zum Training ohne Rechtsgrundlage. Art. 22 DSGVO beschränkt ausschließlich automatisierte Entscheidungen mit Rechtswirkung.
• Haftung und Vertrauen: Wenn Antragstellende sich auf ein privates Vorprüfungswerkzeug verlassen, stellen Sie klar, dass nur die Entscheidung der Behörde zählt. Versionieren und veröffentlichen Sie die angewandten Regeln; führen Sie ein Prüfprotokoll über Werkzeugausgabe im Vergleich zur endgültigen Entscheidung.
• Weitere Branchenregeln: DORA/MiFID/CSRD usw. für Finanz- oder Nachhaltigkeitsmeldungen; das Regelwerk definiert die Pflichten, das KI-Werkzeug tut es nicht.
• Gegenmaßnahmen: menschliche Entscheidung, Regelversionierung, Nachweisverweise, Testsets, Verzerrungsprüfung über Antragstellergruppen hinweg.

Erste Schritte

1. Ein enges Verfahren wählen (z. B. Vollständigkeitsprüfung für eine einzelne Genehmigungsart) und die Regel-Checkliste aufschreiben.
2. 100–200 historische anonymisierte Einreichungen mit den Feststellungen der Prüfenden als Referenz-Testset sammeln.
3. Mit Weg B oder dem Docling-Stack prototypisch arbeiten: parsen, die Regel abrufen, Feststellung + Nachweis + „unklar“ ausgeben.
4. Die numerischen Regeln als Code formalisieren (oder als IDS, wenn BIM-Modelle geliefert werden) und das LLM für die Auslegung behalten.
5. Im Schattenbetrieb neben den Sachbearbeitenden laufen lassen, die Übereinstimmung messen, die Einstufung nach KI-Verordnung und eine DSFA durchführen, dann mit menschlicher Freigabe live gehen.

Quellen

1. ACCORD (Horizon Europe) — Automated Compliance Checking and building permitting — https://accordproject.eu/
2. Deutscher Bundestag, Drucksache 21/6854 (Kleine Anfrage, July 2026) — https://dserver.bundestag.de/btd/21/068/2106854.pdf
3. Archistar — AI PreCheck (formerly eCheck), vendor page with reported results — https://www.archistar.ai/
4. TUM CCBE — AI-based support for on-site inspections in building permit processes — https://www.cee.ed.tum.de/ccbe/research/research-groups/information-management/ai-based-support-for-on-site-inspections-in-building-permit-process
5. Solibri — BIM quality assurance — https://www.solibri.com/
6. buildingSMART Information Delivery Specification (IDS) repository — https://github.com/buildingSMART/IDS ; IfcOpenShell / ifctester — https://github.com/IfcOpenShell/IfcOpenShell
7. Docling project — https://github.com/docling-project/docling
8. Open Policy Agent — Rego policy language — https://www.openpolicyagent.org/docs/latest/policy-language/
9. EC3 — The Challenge of Automated Compliance Checking: a Regulatory View — https://ec-3.org/?p=10393
10. EU AI Act Annex III (artificialintelligenceact.eu) — https://artificialintelligenceact.eu/annex/3/ ; Regulation (EU) 2024/1689 — https://eur-lex.europa.eu/eli/reg/2024/1689/oj