# KI-BauIN – Projekt- und Zeitplan (Phase 1) Stand: 2. Oktober 2026 (KW 40), nach der ersten Besprechung mit BauIN und der API-Dokumentation von ITM. Sobald die Antworten auf den Fragenkatalog vorliegen (Ziel: Termin am 16.10.), wird daraus der Detailplan mit Teilplänen je Arbeitspaket. ## Beteiligte - **ITM:** Anbieter der KI-API (über API-Werk: Dokumentdienst mit OCR, Embeddings, Reranker, Sprachmodell), Projektleitung und abrechnende Firma. Stellt auch die Server (Staging, Produktion) und den Gitea, auf den das Repository gespiegelt wird. - **BauIn:** Endkunde. Prüft als Bauüberwachung im Auftrag der DB die Nachträge der Auftragnehmer dem Grunde nach. Liefert Fachdaten (LVs, Nachträge, Bewertungsmatrizen), stellt den fachlichen Ansprechpartner (Nachtragsbearbeitung) und eine Ansprechpartnerin für IT. - „Kunde“ meint in diesem Dokument BauIn; wo ITM gemeint ist, steht ITM. ## Ergebnis der Besprechung vom 02.10.2026 Was sich gegenüber dem Stand vom 01.10. ändert: - **Geprüft werden Nachträge, nicht MKAs.** Aus einer MKA entsteht (oder auch nicht) nach einigen Wochen ein Nachtrag; das ist nicht 1:1. Der Nachtrag enthält ein Nachtrags-LV mit Positionen (GAEB und PDF), ein Anschreiben, die Kalkulation und Anlagen. Die MKA-Nummer ist nur noch ein Bezug am Nachtrag. - **Die KI beantwortet je Nachtragsposition eine Frage:** Ist die Leistung schon im Vertrag enthalten, also in den LVs einschließlich Vorbemerkungen? Wenn ja, ist der Nachtrag dem Grunde nach nicht berechtigt. Schwerpunkt sind geänderte Leistungen (§ 2 Abs. 5 VOB/B, mit Rückgriff auf eine Hauptvertragsposition) und zusätzliche Leistungen (§ 2 Abs. 6 VOB/B). Mengenänderungen (§ 2 Abs. 3) kommen selten vor und bekommen keine eigene Logik. - **Nicht Aufgabe der KI:** die rechtliche Einordnung (richtiger Paragraf), Fristen und Vollständigkeit der Anzeige, Leistungen ohne Auftrag (§ 2 Abs. 8), Behinderungen (§ 6 Abs. 6), Anordnungen des Auftraggebers. Das prüft BauIn selbst. - **Gliederung:** Projekt → PFA (Planfeststellungsabschnitt, im Pilot PFA 1–4) → Vertrag mit einem Auftragnehmer (je PFA mehrere, z. B. Gleisbau, Tunnelbau, Oberleitung) → mehrere LVs (im PFA 4 z. B. 28). Ein „Los“ im bisherigen Plan entspricht einem Vertrag. - **Suchreihenfolge:** zuerst die LVs des betroffenen Vertrags, dann als Hinweis die anderen PFAs desselben Projekts (Fall: Leistung im PFA 3 beauftragt, im PFA 4 vergessen und dort per Nachtrag zum doppelten Preis angeboten). Nie projektübergreifend. Ob auch die übrigen Verträge im selben PFA durchsucht werden, ist offen. - **Daten:** Jedes LV liegt als GAEB (X86 und D86) und als PDF vor, erzeugt aus dem Kalkulationsprogramm. Grundlage ist die X86-Datei (strukturiert, ohne Texterkennung); das PDF dient der Anzeige mit Sprung zur Fundstelle. OCR über die KI-API braucht es nur noch für PDFs ohne GAEB-Datei (Anschreiben, Scans). - **Sprachmodell ist vorhanden** (`chat`, `chat-noreasoning`, Kontext laut ITM 128K). Damit ist die KI-Beurteilung (Stufe 2) fest eingeplant. - **Bewertungsmatrix (Excel der DB) und Stellungnahme (Word) sind Optionen**, nicht Kern von Phase 1. Vorlagen kommen von BauIn. - **Die Prüfung der Höhe nach ist Phase 2**, das Regelwerk mit Chat Phase 3 (siehe unten). - **Zusammenarbeit:** Termine freitags über Teams; nächster Termin am **16.10.2026** mit Statusbericht und Kostenrahmen für Phase 1. ## Rahmen und Annahmen - **Ziel von Phase 1:** Positionsanalyse dem Grunde nach am Pilotprojekt. Vom hochgeladenen Nachtrag bis zur Ergebnisliste je Position mit Fundstellen, Begründung und Entscheidung des Bearbeiters, mit Rollen und Rechten, Protokoll und Betrieb auf den Servern von ITM. - **Grundhaltung:** Die KI schlägt vor und belegt mit Fundstellen, der Mensch entscheidet. Rückmeldungen fließen in ein Confidence-System mit Referenzfällen und Regeln. - **Aufwand:** Kern rund 24 Personenwochen (PW), mit Risikopuffer 27–28 PW. Optionen zusätzlich (siehe Arbeitspakete). - **Team (Annahme):** zwei Entwickler mit KI-Unterstützung. - **A** (du): Backend, KI-Anbindung, Suche, Prüflogik - **B** (noch zu klären): Oberfläche mit TallStackUI, GAEB-Import, Betrieb - Mit nur einem Entwickler verdoppelt sich die Dauer ab KW 44 (siehe Variante unten). - **Pause:** KW 52–53 (21.12.2026 – 03.01.2027). - **Echte Daten:** Entwickelt wird mit öffentlichen GAEB-Beispieldateien und einem anonymisierten Beispielablauf von BauIn. Echte Pilotdaten nur auf den Servern von ITM und erst nach Klärung des Datenschutzes. - **Abhängigkeit:** Viele Pakete brauchen Zulieferungen von ITM und BauIn. Kommen sie später als unten geplant, verschiebt sich der Plan entsprechend. ## Meilensteine | | Termin | Ergebnis | Termin mit dem Kunden | |---|---|---|---| | – | Fr 16.10. | Statusbericht mit Screenshots, Plan, Kostenrahmen, offene Fragen | Termin BauIn | | **M1** | Fr 30.10. (KW 44) | Grundgerüst: Login/2FA, Benutzer und Rollen, Projekte mit PFA und Verträgen, Upload, Protokoll; Detailplan steht | Demo (30 min) | | **M2** | Fr 20.11. (KW 47) | LVs des Pilot-PFA importiert; **LV-Suche** über alle LVs eines Vertrags, PFA oder Projekts mit Sprung ins PDF nutzbar; Staging bei ITM läuft | Prüftermin (60 min) | | **M3** | Fr 18.12. (KW 51) | Erster Nachtrag durchgängig: Vorprüfung aller Positionen, Prüfmaske, Feedback, Regeln, Ergebnisliste | Präsentation (60–90 min) | | **M4** | Fr 29.01.2027 (KW 4) | Alle Nachträge des Pilot-PFA durchlaufen, Trefferquote und Zeitersparnis gemessen; Produktion abgesichert | Abschluss, Entscheidung über Optionen und Phase 2 | | Puffer | KW 5–6/2027 | für Verzögerungen bei Zulieferungen oder Import | – | Die LV-Suche (M2) nützt BauIn schon vor der KI-Beurteilung: Heute werden bis zu 28 LVs einzeln nach Stichworten durchsucht. **Laufend:** Termine mit BauIn freitags, etwa alle zwei Wochen, vorher ein kurzer Statusbericht mit Screenshots. ## Arbeitspakete und Aufwand | AP | Inhalt | PW | Wer | Wann | Hängt ab von | |---|---|---|---|---|---| | AP0 | Klärung, Kundentermine, Statusberichte, Dokumentation | 1,0 | A+B | laufend | – | | AP1 | Fundament: Umgebung ✓, Laravel/TallStackUI ✓, Mehrsprachigkeit ✓, CI, Datenmodell (Mandant, Land, Projekt, PFA, Vertrag, LV, Dokument, Nachtrag, Nachtragsposition), Rollen/Rechte mit Benutzerverwaltung, privater Upload und Download inkl. Massen-Upload, Protokoll, Länderstruktur | 4,0 (1,0 erledigt) | A+B | KW 40–44 | Rollenmodell (Kunde) | | AP2 | Meilisearch-Test: Teil 1 mit erzeugten Vektoren, Teil 2 mit echten Vektoren und Referenzfällen | 0,5 | A | KW 41 / KW 46–47 | Teil 2: API-Schlüssel (ITM), Referenzfälle (BauIn) | | AP3 | Anbindung KI-API ITM (API-Werk): Dokumentdienst mit Polling, `embed`, `rerank`, `chat` mit Streaming; Ratenbegrenzung (120/min je Schlüssel), begrenzte Wiederholung ohne Doppel-Einreichung, Verbrauchsprotokoll, Überwachung | 1,5 | A | KW 41 (Test), KW 44 | API-Schlüssel (ITM) | | AP4 | Indexierung und Suche: LV-Positionen und Vorbemerkungen aus GAEB, Texte aus PDFs ohne GAEB → Embeddings → MySQL + Meilisearch; hybride LV-Suche mit Pflichtfilter für Rechte und Suchreihenfolge (Vertrag → PFA → Projekt); Neuaufbau des Index | 2,0 | A | KW 45–47 | AP3, AP5 | | AP5 | GAEB-Import (X86): Parser, LV-Baum, Vorbemerkungen, LV-Ansicht; PDF-Anzeige (pdf.js lokal) mit Sprung zur Position; Nachtrags-Import (Nachtrags-LV als X86, sonst PDF über OCR) | 2,5 | B | KW 41 (Test), KW 44–46 | Beispieldateien | | AP6 | Vorprüfung Stufe 1 (ohne Sprachmodell): je Nachtragsposition Fundstellen mit Reranker, Nachtragsübersicht, Prüfmaske, Feedback je Aspekt, Confidence | 2,5 | A+B | KW 48–49 | AP4, AP5 | | AP7 | Vorprüfung Stufe 2 (mit Sprachmodell): „im Vertrag enthalten?“, Bezugsposition und Unterschied bei geänderter Leistung, Begründung mit Quellen, Prüfung der Antwort | 2,0 | A | KW 50–51 | AP6 | | AP8 | Regeln, Referenzfälle, einstellbare Freigaben, Versionen | 2,0 | B | KW 50–51 | Freigabe-Variante (Kunde) | | AP9 | Nachtragsstatus, Ergebnisliste je Nachtrag, einfacher Excel-Export | 0,5 | B | KW 51 | – | | AP10 | Dashboard, Benachrichtigungen, Auswertungen, allgemeine Dokumente (Einstellungen) | 0,75 | B | KW 47, KW 2 | – | | AP11 | Betrieb: Staging und Produktion (Nginx, PHP-FPM, systemd, Cron, Meilisearch), Deployment, verschlüsselte Backups, Alarmierung, Restore-Test | 1,5 | B | KW 46–47, KW 3 | Server (ITM), Backup-Ziel | | AP12 | Pilot: alle Nachträge des Pilot-PFA durchlaufen, messen, nachschärfen (Prompts, Gewichtung, Quantisierung) | 2,0 | A+B | KW 1–3/2027 | Referenzfälle, Fachexperte | | AP13 | Design aus Claude Design als TallStackUI-Designsystem übernehmen | 1,0 | B | KW 42–43 | Designentwurf | | | **Summe Kern** | **≈ 23,75** | | | | | OP1 | Option: Bewertungsmatrix in der Excel-Vorlage der DB füllen | 1,0 | B | KW 2–3 | Vorlage (BauIn) | | OP2 | Option: Stellungnahme BÜW als Word-Datei aus Vorlage | 1,0 | B | nach M4 oder Puffer | Vorlage (BauIn) | Gegenüber dem Stand vom 01.10. entfallen der GAEB-90-Import (D86), der Webhook-Eingang, der Vorschlag einer Anspruchsgrundlage und die kuratierte Wissensbasis (wird Phase 3). Dazu kommen PDF-Anzeige mit Sprung zur Position, Massen-Upload, Suchreihenfolge über PFAs und die Bezugsposition. ## Zeitplan nach Kalenderwochen (2 Entwickler) | KW | Datum | A (Backend, KI, Suche) | B (Oberfläche, Import, Betrieb) | Kunde / gemeinsam | |---|---|---|---|---| | 40 | 28.09.–04.10. | ✓ Umgebung, Grundgerüst, TallStackUI, Mehrsprachigkeit, Doku | – | ✓ Besprechung BauIn (02.10.) | | 41 | 05.–11.10. | Meilisearch-Test Teil 1; Datenmodell Kern; API-Schnelltest, sobald Schlüssel da | CI in Gitea Actions; Benutzerverwaltung beginnen; GAEB-X86-Test mit öffentlichen Beispieldateien | Fragenkatalog raus; Übergabe an Claude Design | | 42 | 12.–18.10. | Upload, privater Speicher, Download mit Rechteprüfung, Massen-Upload | Rollen und Rechte, Projekt-Mitglieder; Design-Feedback | Aufwand an ITM (bis 14.10.); **Termin BauIn 16.10.** | | 43 | 19.–25.10. | Detailplan und Teilpläne nach den Antworten; Protokoll; Länderstruktur | Designsystem übernehmen (AP13) | – | | 44 | 26.10.–01.11. | Client KI-API ITM, Jobs, Ratenbegrenzung | GAEB-Parser: LV-Baum, Vorbemerkungen | **M1 Demo 30.10.** | | 45 | 02.–08.11. | Indexierung: Positionen und Vorbemerkungen → Embeddings | LV-Ansicht, PDF-Anzeige mit Sprung zur Position | – | | 46 | 09.–15.11. | Hybride LV-Suche mit Rechtefilter und Suchreihenfolge; Meilisearch-Test Teil 2 | Nachtrags-Import; Staging einrichten | – | | 47 | 16.–22.11. | Neuaufbau des Index; OCR für PDFs ohne GAEB | Suchoberfläche; Staging fertig, Pilot-PFA importiert | **M2 Prüftermin 20.11.** | | 48 | 23.–29.11. | Vorprüfung: Fundstellen + Reranker, Confidence | Nachtragsübersicht, Prüfmaske | – | | 49 | 30.11.–06.12. | Feedback-Speicherung, Referenzfälle | Prüfmaske fertig, Feedback-Oberfläche | Demo 04.12. | | 50 | 07.–13.12. | Sprachmodell: „enthalten?“, Bezugsposition, strukturierte Antwort | Regeln: Dialog, Freigaben, Einstellungen | – | | 51 | 14.–20.12. | Begründung mit Quellen, Prüfung der Antwort | Ergebnisliste, Excel-Export | **M3 Präsentation 18.12.** | | 52–53 | 21.12.–03.01. | Pause | Pause | – | | 1 | 04.–10.01. | Pilot: alle Nachträge des Pilot-PFA durchlaufen, messen | Pilot begleiten, Fehler beheben | Fachexperte bewertet | | 2 | 11.–17.01. | Nachschärfen (Prompts, Gewichtung, Quantisierung) | Dashboard, Auswertungen; Option OP1, falls beauftragt | Demo 15.01. | | 3 | 18.–24.01. | Feinschliff, Fehler | Produktion: Backups, Alarmierung, Restore-Test | – | | 4 | 25.–31.01. | Auswertung, Übergabe | Doku Betrieb | **M4 Abschluss 29.01.** | | 5–6 | 01.–14.02. | Puffer | Puffer | – | **Variante mit einem Entwickler:** M1 Ende KW 45, M2 Ende KW 51, M3 Ende KW 8/2027, M4 Ende KW 13/2027 (Anfang April). ## Zulieferungen von ITM und BauIn (Soll-Termine) | Bis | Von | Was | Gebraucht für | |---|---|---|---| | ✓ 02.10. | ITM | API-Dokumentation (API-Werk: Dokumentdienst, `chat`, `chat-noreasoning`, `embed`, `rerank`) | AP3 | | KW 41 | ITM | API-Schlüssel für die Entwicklung; Antworten auf die ITM-Fragen; Preise der API für den Kostenrahmen | AP3, Kostenrahmen | | KW 41 | BauIn | Antworten auf die ★-Fragen | Detailplan | | 16.10. | BauIn | Matrix-Vorlage (leer + 2–3 ausgefüllt), Word-Vorlage Stellungnahme, anonymisierter Beispielablauf (LVs als X86 + PDF, Nachträge mit Nachtrags-LV und Anschreiben) | AP5, AP9, OP1, OP2 | | KW 43 | BauIn | Entscheidung Rollenmodell, Freigabe-Variante, Anmeldung (2FA oder Microsoft-Konto) | AP1, AP8 | | KW 43 | BauIn, ITM | Freigabe Datenschutz für echte Pilotdaten auf den Servern von ITM und über die KI-API | AP11, M2 | | KW 46 | ITM | Staging-Server mit Zugang, Domain und Zertifikat | AP11, M2 | | KW 46 | BauIn | Pilotdaten: alle LVs eines PFA als X86 + PDF (nur auf Staging) | M2 | | KW 47 | BauIn | 10–20 abgeschlossene Nachträge mit Ergebnis (Referenzfälle) | AP2 Teil 2, AP12 | | KW 51 | ITM | Produktions-Server mit Zugang, Domain und Zertifikat | AP11 | | KW 51 | offen | Backups: Speicherort, Aufbewahrungsdauer, Zuständigkeit | AP11 | ## Risiken | Risiko | Auswirkung | Gegenmaßnahme | |---|---|---| | Zulieferungen kommen spät | Pakete verschieben sich | Soll-Termine am 16.10. vereinbaren; vorziehen, was unabhängig ist | | Kein anonymisierter Beispielablauf, Datenschutz für echte Daten ungeklärt | Kein realistischer Test vor M2 | Öffentliche GAEB-Beispiele; früh anfragen; echte Daten nur auf Staging | | X86-Dateien weichen vom Standard ab (Version, Erweiterungen des Kalkulationsprogramms) | GAEB-Import aufwendiger | Beispieldatei früh anfordern; fertige Bibliothek prüfen; D86 als Rückfall | | Sprachmodell liefert keine verlässliche strukturierte Antwort | Stufe 2 schwächer | Antwort im Code prüfen; Stufe 1 (Suche + Reranker) ist allein schon nützlich | | Meilisearch mit 4.096 Dimensionen zu langsam | Suche muss umgebaut werden | Test in KW 41; Plan B Qdrant | | KI-API ausgelastet (120 Anfragen/min je Schlüssel, für alle Nutzer gemeinsam) | Lange Wartezeiten bei Erstindexierung und Suche | Alles asynchron; Stapel-Embeddings; Suchanfragen bevorzugen; ggf. getrennte Schlüssel | | Excel-Vorlage der DB enthält Makros | Export kann Makros verlieren (OP1) | Vorlage früh testen; notfalls Werte zum Einfügen exportieren | | Fachexperte wenig verfügbar | Kein Feedback, keine Messung | Feste Freitagstermine; Referenzfälle früh anfordern | ## Aufgabenliste (nächste zwei Wochen) **Erledigt** - [x] Entwicklungsumgebung (WSL2, Docker, Sail), Repo mit gitleaks-Hook - [x] Laravel 13, Livewire 4, TallStackUI 4, Fortify (2FA, Passkeys), Spatie - [x] Mehrsprachigkeit (Deutsch Standard, Englisch) - [x] CLAUDE.md, Tech-Stack-Doku, Projektplan - [x] Besprechung mit BauIn (02.10.), API-Dokumentation von ITM erhalten **KW 41** - [ ] Fragenkatalog an BauIn (fachlich, IT) und ITM schicken - [ ] Übergabe an Claude Design: Prototyp an den neuen Umfang anpassen - [ ] API-Schlüssel für die Entwicklung bei ITM anfordern; Schnelltest (Modellverzeichnis, Dimension von `embed`, `rerank`, `chat` mit Streaming) - [ ] **Meilisearch-Test Teil 1** (erzeugte 4.096-dim. Vektoren, z. B. 50.000 Stück): Indexierungszeit, Antwortzeit mit Filtern, RAM und Platte; jeweils ohne und mit binärer Quantisierung - [ ] Datenmodell Kern: Mandant, Land, Projekt, PFA, Vertrag, LV, Dokument (Kategorie, Vertraulichkeit), Nachtrag, Nachtragsposition, Mitgliedschaften - [ ] GAEB-X86-Test mit öffentlichen Beispieldateien, Bibliothek auswählen - [ ] CI in Gitea Actions: Tests, Pint, PHPStan - [ ] Commits nach Gitea pushen **KW 42** - [ ] Aufwand für den Kostenrahmen an ITM (bis 14.10.) - [ ] Statusbericht mit Screenshots für den 16.10. - [ ] **Termin BauIn 16.10.:** Antworten in Plan und Doku übernehmen, Soll-Termine vereinbaren - [ ] Rollen und Rechte (Spatie, ggf. Teams je Projekt), Benutzerverwaltung im Admin-Bereich - [ ] Upload, privater Speicher, Download mit Rechteprüfung, Massen-Upload - [ ] Design-Feedback an Claude Design **Später im Plan (bereits vorgemerkt)** - [ ] Detailplan mit Teilplänen je Arbeitspaket (KW 43) - [ ] **Meilisearch-Test Teil 2** (KW 46–47): Trefferquote mit echten API-Vektoren und Referenzfällen, ohne/mit binärer Quantisierung, vor und nach dem Reranker - [ ] Push-Mirror zum Gitea von ITM einrichten, sobald die Adresse vorliegt - [ ] 2FA-Pflicht oder Microsoft-Anmeldung umsetzen, je nach Entscheidung des Kunden ## Ausbaustufen nach Phase 1 - **Phase 2 – Prüfung der Höhe nach:** Preis der Nachtragsposition gegen Bezugsposition und gleiche Leistung in anderen PFAs, Auszüge aus der Urkalkulation, Nachtragskalkulation. Die vollständige Urkalkulation liegt versiegelt bei der DB; dort prüft der Einkauf die Höhe. - **Phase 3 – Regelwerk:** Richtlinien der DB (Auszug, mit dem BauIn zu rund 80 % arbeitet: 263 PDF-Dateien, 743 MB, z. B. Ril 821, 824, 836) in die Suche aufnehmen, dazu ein interner Chat, der mit PDF, Seite und Stelle zitiert. Phase 1 legt die Grundlagen: Dokumentspeicher, Abschnitte mit Seitenbezug, Quellenanzeige im PDF. - **Weitere Ideen:** Dokumentenmanagement, E-Mail-Anbindung, Anbindung an das Dokumentensystem der DB, Österreich (ÖNORM B 2110/B 2118, ÖNORM A 2063), Bauzeitenplan-Analyse, weitere Sprachen. ## Nebenprojekt außerhalb des Budgets - **datenschleuse** (lokaler Scanner/Bereiniger, Prompt in `Prompt_Datenschleuse.md`): mindestens Phase 1–2 fertig, bevor echte Kundendateien mit Claude bearbeitet werden. Bis dahin gehen echte Kundendateien nicht an Claude. Hilft auch beim anonymisierten Beispielablauf.