KI und Sprache
- Vertex AI mit Gemini für Dialog, Klassifikation und Extraktion
- Document AI für OCR auf Mietverträgen und Rechnungen
- Cloud Translation v3 für Ticket-Übersetzungen am EU-Endpunkt
Architektur
Wie VerwaltKlar technisch gebaut ist.
Diese Seite richtet sich an technische Prüfer, Partner und Investoren. Sie beschreibt die eingesetzten Dienste, den Weg einer Meldung durch das System und die Grenzen, die wir uns gesetzt haben. Der Stand ist ein durchgängig lauffähiges Produkt in Pilotvorbereitung.
Durchgängig lauffähig.
Jede hier beschriebene Funktion läuft heute im Produkt – auf Google Cloud in der Region europe-west1.
Plattform
Vollständig auf Google Cloud, als Code bereitgestellt.
Alle Umgebungen entstehen aus Terraform. Es gibt keine manuell angelegten Produktionsressourcen, und jede Änderung ist versioniert nachvollziehbar.
Laufzeit
- Cloud Run für den Chatbot-Dienst (FastAPI, Python)
- Cloud Functions für privilegierte Abläufe und Trigger
- Cloud Scheduler für Fristen, Eskalationen und Wiedervorlagen
Daten und Identität
- Firestore als primärer Datenspeicher mit serverseitigen Regeln
- Cloud Storage für Fotos und Dokumente, Zugriff nur über signierte URLs
- Firebase Authentication für Identität, Rollen als eigene Datenhoheit
Betrieb
- Terraform als alleinige Quelle der Infrastruktur
- Artifact Registry und Cloud Build für Container und Auslieferung
- Secret Manager für alle Laufzeitgeheimnisse, nichts im Repository
Der Weg einer Meldung
Von der Chat-Nachricht zum zugewiesenen Auftrag.
Jeder Schritt ist ein eigener, prüfbarer Übergang. Nichts davon läuft im Browser des Nutzers.
- 01
Eingang
Der Messenger-Webhook trifft auf Cloud Run. Authentifizierung über geteiltes Geheimnis und IP-Prüfung, bevor irgendetwas verarbeitet wird.
- 02
Geführter Dialog
Ein Zustandsautomat führt durch die Aufnahme, Gemini übernimmt Absichtserkennung und die Prüfung, ob die Beschreibung ausreicht.
- 03
Ticket entsteht
Der Vorgang wird in Firestore geschrieben. Fotos landen in Cloud Storage, erreichbar ausschließlich über signierte, rollengeprüfte URLs.
- 04
Automatische Triage
Ein Firestore-Trigger startet Haftungsklassifikation, Fristenberechnung, Übersetzung und die Bewertung passender Betriebe.
- 05
Zuordnung und Freigabe
Die Verwaltung entscheidet. Betriebe antworten über einen sicheren Einmal-Link, ohne Konto, mit atomarer Konfliktauflösung beim Zuschlag.
- 06
Fristen und Abschluss
Geplante Jobs eskalieren überfällige Vorgänge. Abgeschlossene Tickets wandern samt Verlauf in ein Archiv.
Entwurfsentscheidungen
Was wir bewusst so und nicht anders gebaut haben.
- 01
Regeln schlagen Modell bei Sicherheit
Gas, Strom, Wasseraustritt und Einbruchgefahr eskalieren über eine feste Regel. Ein Modell darf diese Einstufung nach oben ergänzen, aber nie aufheben.
- 02
Zuordnung ist deterministisch
Die Rangfolge der Betriebe entsteht aus einer offengelegten Formel – Nähe, Bewertung und abgeschlossene Vorgänge – und nicht aus einem Modell. Vertrauensbetriebe der Verwaltung stehen immer vor dem Netzwerk.
- 03
Datensparsamkeit vor Zuschlag
Vor der Annahme sieht ein Betrieb nur Kategorie, Dringlichkeit, groben Bereich und Zeitfenster. Vollständige Adresse und Kontakte werden erst nach der Annahme freigegeben.
- 04
Keine privilegierten Schreibzugriffe im Client
Rolle, Aktivstatus und Verknüpfungen sind für Clients gesperrt. Jeder sensible Ablauf läuft über eine serverseitige Funktion.
- 05
Token nur als Hash
Einladungs- und Auftrags-Links werden ausschließlich als SHA-256-Hash gespeichert und nie im Klartext protokolliert.
- 06
KI-Verbrauch wird gemessen
Jeder Modellaufruf schreibt seinen Token-Verbrauch mit. Kosten pro Ticket und pro Vertrag sind dadurch bekannte Größen, keine Schätzungen.
Skalierung
Wie der Verbrauch mit dem Bestand wächst.
Der Ressourcenbedarf hängt fast vollständig an der Zahl der verwalteten Einheiten. Diese Größen bestimmen den Cloud-Verbrauch:
- Gemini-Aufrufe je Meldung: geführter Dialog, Einordnung und Haftungsprüfung
- Document-AI-Seiten je übernommenem Mietvertrag und je Rechnung
- Übersetzte Zeichen je Ticket und Zielsprache, serverseitig zwischengespeichert
- Cloud-Run-Instanzen, die zwischen den Meldungen auf null skalieren
- Geplante Jobs im festen Takt, unabhängig von der Bestandsgröße
Weil jeder Modellaufruf seinen Verbrauch protokolliert, lässt sich der Bedarf je zusätzlicher Einheit hochrechnen, statt ihn zu schätzen.
Stand
Wo das Produkt heute steht.
- Durchgängig lauffähig: Vertragsübernahme, Meldung, Triage, Zuordnung, Abschluss
- Vier Rollen mit getrennten Oberflächen: Verwaltung, Eigentümer, Mieter, Betrieb
- Telegram im Einsatz, WhatsApp als zweiter Kanal angebunden
- Zugriffsregeln und Abläufe durch automatisierte Tests abgesichert
- Pilotvorbereitung mit Hausverwaltungen läuft
Einen Blick unter die Haube?
Partnern und technischen Prüfern zeigen wir das System gern im Detail.