KI-Produktentwicklung für die Immobilienerfassung: Von Sprache und PDF zum Exposé
Anonymisierte Case Study: Wie aus einer Produktidee eine KI-Anwendung für Immobilienerfassung, strukturierte Projektdaten und Exposé-Erstellung wurde.
<p data speakable Eine KI Idee wird erst dann zu einem Produkt, wenn Erfassung, Datenverarbeitung, Nutzerführung und Ausgabe zusammenpassen. Diese anonymisierte Case Study zeigt, wie aus einer Produktidee eine KI Anwendung für die Immobilienerfassung, strukturierte Projekte und Exposé Erstellung entstand.</p
Ausgangslage
Für ein Immobilienprojekt begann die technische Aufgabe mit einem wiederkehrenden Problem aus dem Makleralltag: Informationen zu einem Objekt entstehen in unterschiedlichen Formen und müssen anschließend in einen nutzbaren, einheitlichen Ablauf überführt werden. Angaben können direkt vor Ort gesprochen, aus einem PDF übernommen oder Schritt für Schritt in einem Wizard erfasst werden.
Das Ziel war eine KI gestützte Anwendung, die diese Informationen nicht nur entgegennimmt, sondern daraus ein strukturiertes Immobilienprojekt und ein verwendbares Exposé vorbereitet. Damit lag die Herausforderung nicht in einer einzelnen KI Funktion. Entscheidend war die Entwicklung eines durchgängigen Produktprozesses – von der Erfassung unstrukturierter Informationen über die Verarbeitung und Strukturierung bis zur nächsten nutzbaren Ausgabe.
Der Immobilien und Maklerkontext ist dabei Teil der fachlichen Einordnung. Der konkrete Projektname, der Kunde und identifizierende Produktdetails bleiben anonymisiert.
Von der Idee zum funktionsfähigen Produkt
Meine Aufgabe umfasste die technische Umsetzung von der Produktidee bis zu einem funktionsfähigen Prototypen. Dazu gehörten die Strukturierung des Produktablaufs, die Entwicklung der mobilen Anwendung, die Anbindung der Cloud Dienste und die Umsetzung der Verarbeitungsschritte.
Die Anwendung wurde nicht um ein isoliertes Modell herum gebaut. Die KI gestützte Immobilienbewertung, die Suche und die Strukturierung mussten in einen nachvollziehbaren Fachprozess passen. Sprache, Dokumente und manuelle Eingaben sollten in einen gemeinsamen Projektkontext überführt werden. Gleichzeitig sollte der Nutzer mit dem angelegten Projekt weiterarbeiten können, während Verarbeitungsschritte im Hintergrund laufen.
Diese Perspektive ist für KI Produktentwicklung entscheidend: Der Wert entsteht nicht allein durch das verwendete Modell, sondern durch die Verbindung aus Eingabe, Datenmodell, Nutzerführung, fachlicher Logik und Ausgabe.
Die technische Herausforderung
Die zentrale Herausforderung lag in der Verbindung mehrerer Eingabe und Verarbeitungspfade. Ein Makler kann Informationen anders liefern als ein bereits vorliegendes Dokument. Trotzdem müssen beide Wege in eine konsistente Struktur münden, damit spätere Auswertung und Exposé Erstellung nicht von der ursprünglichen Eingabeform abhängen.
Dafür wurde ein Project Cockpit mit einer schrittweisen Verarbeitung aufgebaut. Die Capture Oberflächen legen ein Projekt an und übergeben die weitere Verarbeitung an einen zentralen Coordinator. Der Nutzer wird anschließend direkt in die Projektdetails geführt, während die Verarbeitung im Hintergrund weiterläuft.
Der Coordinator ist damit keine zusätzliche sichtbare Funktion um ihrer selbst willen. Er bildet die Grenze zwischen der unmittelbaren Nutzerführung und den nachgelagerten Verarbeitungsschritten. Der Produktzustand bleibt sichtbar, während neue Informationen ergänzt, strukturiert und für weitere Funktionen vorbereitet werden.
Architektur und technische Umsetzung
Das Frontend wurde mit Flutter und Dart umgesetzt. Zustände und asynchrone Aktionen werden über ViewModels und Commands organisiert. Die Geschäftslogik liegt in Use Cases; der Datenzugriff ist über Repository Schnittstellen getrennt.
Das Backend basiert auf AWS Amplify Gen 2 und angebundenen Cloud Diensten. Die Architektur wurde so angelegt, dass die mobile Oberfläche nicht direkt an einzelne Infrastrukturdetails gekoppelt ist. Stattdessen kommuniziert sie über klar definierte Anwendungsschichten mit den benötigten Daten und Verarbeitungsfunktionen.
Das grundlegende Muster lautet:
Diese Trennung erleichtert es, Eingabewege, Verarbeitungsschritte und spätere Produktfunktionen weiterzuentwickeln. Neue fachliche Abläufe müssen nicht automatisch zu einer engen Kopplung jeder Oberfläche an die Infrastruktur führen.
Wichtig ist außerdem die Unterscheidung zwischen direkter Persistenz und Verarbeitung. Nicht jeder Speichervorgang benötigt eine eigene KI oder Hintergrundfunktion. Die Architektur muss an der Stelle geprüft und weiterentwickelt werden, an der die jeweilige Verantwortung tatsächlich liegt.
Exposé und Projektzustand
Für die Exposé Erstellung wurde ein Pflichtfeld Gate vorgesehen. Bestimmte Anbieter und Kontaktdaten müssen vorhanden sein, bevor ein Entwicklungs Export als vollständig gilt. Optionale Branding Bestandteile können dagegen mit Platzhaltern dargestellt werden, wenn sie noch nicht hinterlegt sind.
Diese Regel ist ein Beispiel dafür, wie fachliche Anforderungen in Produktlogik übersetzt werden. Ein Export ist nicht nur eine technische Datei. Er muss auch erkennen lassen, ob die für den jeweiligen Zweck notwendigen Informationen vorhanden sind.
Der aktuelle Stand ist ein funktionsfähiger Prototyp beziehungsweise ein aktiv weiterentwickeltes Produkt. Offene Arbeiten betreffen unter anderem die Weiterentwicklung der Bereichserstellung, die Härtung der Vor Ort Erfassung sowie die Verifizierung des Entwicklungs Exports und der Profil Persistenz.
Was der Fall für technische Entscheider zeigt
Für CTOs, IT Leitungen und technische Verantwortliche zeigt der Fall mehrere Punkte:
1. Eine KI Idee wird erst dann zu einem Produkt, wenn Eingabe, Datenmodell, Verarbeitung, Nutzerführung und Ausgabe zusammenpassen. 2. Unterschiedliche Eingabeformen müssen früh in einen gemeinsamen Projektprozess übersetzt werden. 3. Hintergrundverarbeitung kann die Nutzerführung verbessern, wenn der Produktzustand transparent bleibt. 4. Eine saubere Trennung von Use Cases, Repositories und Infrastruktur reduziert die Abhängigkeit einzelner Oberflächen von Backend Details. 5. Pflichtfeld Gates und Persistenzregeln gehören zum Produktdesign und nicht erst in eine spätere Betriebsphase.
Genau diese Verbindung ist der Kern meiner Leistung: Ich entwickle nicht nur einen isolierten KI Demonstrator. Ich übersetze einen konkreten Arbeitsablauf in ein nutzbares Produkt, verbinde die fachlichen Eingaben mit einer erweiterbaren technischen Struktur und begleite die Umsetzung bis zu einem funktionsfähigen Stand.
Grenzen der öffentlichen Darstellung
Der Fall wird öffentlich ausschließlich anonymisiert beschrieben. Der Projektname, der Kunde, konkrete URLs, Screenshots, Nutzerzahlen, interne Ressourcen, Branches, Dateizahlen und Zugangsdaten werden nicht genannt.
Die Case Study ist ein technischer Nachweis für die Umsetzung einer KI Anwendung mit mehreren Eingabewegen und einer strukturierten Cloud Architektur. Sie ist kein Beleg für eine bestimmte Umsatzsteigerung, eine garantierte Erkennungsgenauigkeit, eine bestimmte Zeitersparnis oder einen allgemein übertragbaren ROI.
Der Wert des Beispiels liegt in der Überführung einer fachlichen Immobilienaufgabe in ein funktionsfähiges Produkt: von Sprache, PDF und manuellem Wizard über die strukturierte Verarbeitung bis zu Projekt und Exposé Daten.