BauIN/docs/projektplan.md

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

• Entwicklungsumgebung (WSL2, Docker, Sail), Repo mit gitleaks-Hook
• Laravel 13, Livewire 4, TallStackUI 4, Fortify (2FA, Passkeys), Spatie
• Mehrsprachigkeit (Deutsch Standard, Englisch)
• CLAUDE.md, Tech-Stack-Doku, Projektplan
• 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.