LATUS Fiberproof AI

Glasfaser-Qualität, vollständig geprüft. In Tagen statt Monaten.

Die KI-Plattform für die automatisierte Bild- und Dokumentenprüfung im FTTH-Ausbau. 100% Prüfung statt 20% Stichprobe. Aus einem Jahr manueller Arbeit wird eine Woche.

Live-Demo anfragen Lösung verstehen

100% Vollprüfungstatt Stichprobe

>99% Confidencebei der Bilderkennung

100k+ Dokumentein wenigen Tagen

52 zu 1 WochenZeitersparnis pro Baulos

Was ist Fiberproof AI

Eine Plattform, die jedes Foto und jedes Dokument aus dem Glasfaserausbau automatisch prüft.

Fiberproof AI kombiniert Computer-Vision, Deep-Learning und regelbasierte Validierungen, um aus Fotos, Messprotokollen und Bauakten verwertbare Qualitätsaussagen zu machen - vollständig, nachvollziehbar, DSGVO-konform.

Statt Stichproben gibt es eine durchgängige Prüfung jedes Hausanschlusses. Statt manueller Wochen-Reports erhalten Netzbetreiber, Fördermittelgeber und Generalunternehmer in Tagen klare Aussagen zur Bauqualität.

Die Lösung ist spezialisiert auf den FTTH-Ausbau: APL-Erkennung, Hauseinführungs-Klassifikation, Begehungsprotokoll-Auswertung, OTDR-Verarbeitung. Keine Generalisten-KI, sondern Domänenwissen direkt in die Modelle eingebaut.

21,8Mio

FTTH/FTTB-Haushalte in Deutschland (Ende 2024) - Tendenz: 39,3 Mio bis 2030.

~400Mio

Dokumente, die bis 2030 in Deutschland entstehen - 10 pro Hausanschluss.

125/h

Adressobjekte Verarbeitungsgeschwindigkeit, ≤ 5 Sekunden pro Einzelprüfung.

Use-Cases

Drei Szenarien, drei klare Ergebnisse.

Aus realer LATUS-Projekterfahrung. Die Zahlen stammen aus dokumentierten Pilot-Projekten, die OFFEN-Punkte aus der Solution-Description sind hier bewusst nicht als Hard-Facts dargestellt.

Carrier . Netzbetreiber

Rechnungsfreigabe in einer Woche statt einem Jahr

Mehr als 100.000 Dokumente für ein Baulos. Manuelle Stichprobenprüfung (20%) dauert üblicherweise ein Jahr - inklusive Koordination, Nachforderungen, Abstimmungen.

Ergebnis: 100% Vollprüfung in einer Woche. 98% Zeitersparnis. Audit-Spur für jede Prüfentscheidung.

Fördermittel . Compliance

Fördermittel-Nachweis statt Projekt-Showstopper

Fehlende oder unvollständige Dokumentation kann zur Nicht-Auszahlung von Fördermitteln führen - kein bloßes Risiko, sondern ein dokumentierter Projekt-Stopper.

Ergebnis: Automatisierter Vollständigkeits-Nachweis. Audit-fähige Dokumentation pro Hausanschluss.

Generalunternehmer

Fehler früh erkennen, nicht spät teuer nachbessern

Spät erkannte Mängel im Baulos bedeuten Nachbesserungen, Zahlungsverzögerungen und Streit zwischen GU und Subunternehmer. Prüfung in Echtzeit verhindert das.

Ergebnis: Früherkennung während der Bauphase. Reduzierte Nacharbeiten. Schnellere Abnahme.

Plattform-Module

Eine modulare Plattform. Preflight konfiguriert Ihren Use-Case.

Fiberproof AI ist eine konsequent modulare SaaS-Plattform. Auf der Plattform-Ebene laufen vier Kern-Module: Intake, Pre-Validation, Preflight und Reporting. Sie bilden den durchgängigen Rahmen, in dem die atomaren Erkennungs-Module ihre Arbeit verrichten. Im Preflight stellen Sie die für Ihren Use-Case passende Modul-Kombination zusammen - aus dem vollständigen Funktionsverzeichnis weiter unten.

1. Intake

Multiformat-Upload aus allen relevanten Quellen, mit automatischer Integritäts-Prüfung.

2. Pre-Validation

Vorvalidierung sortiert, klassifiziert und markiert - statt unsichtbar zu verwerfen.

3. Preflight - der Konfigurator

Hier stellen Sie aus dem Funktionsverzeichnis die für Ihren Use-Case passende Kombination zusammen.

4. Reporting und Output

Drei Standard-Reports plus Audit-Spur für Fördermittel-Nachweise.

Prüfprozess

Der vollständige 7-Schritte-Prüfprozess - vom Foto bis zum nachweisfähigen Report.

Modular aufgebaute SaaS-Plattform, AWS-Multi-Layered-Security, Infrastructure-as-Code. Jede Stufe als eigener Service. Skaliert horizontal nach Last und Use-Case.

Datei-Upload

Web-Drag-and-Drop, SharePoint, S3, API. Multiformat: JPG, PNG, PDF (digital und gescannt), Excel, OTDR-SOR.

Dokumenten-Erkennung

Klassifikation nach Dokument-Typ, PDF-Inhalts-Extraktion, Duplikat-Prüfung global und ordner-lokal.

Qualitative Prüfung

KI-Bildprüfung: APL-Erkennung (Open/Closed/Covered, Multibox), Hauseinführungs-Klassifikation, Trassenfotos, Spleißkassetten.

Messwert-Prüfung

OTDR-SOR-Verifizierung gegen Soll-Werte, automatische Dämpfungs- und Reflexions-Auswertung, Faser-Endpunkt-Prüfung.

Umbenennung und Sortierung

Inhaltsbezogene Datei-Umbenennung, automatische Neusortierung in strukturierte Ordner, Suchfunktion mit Metadaten.

Fehlertabellen

Strukturierte Fehlerlisten für GU-Nachlieferungen, Confidence-Werte pro Fund, eindeutige Verlinkung zur Original-Datei.

Report und Analyse

Processing Summary, Operations Summary, Result-CSV. Auswertung, Interpretation, Audit-Spur für Fördermittel-Nachweise.

Funktions-Demos

Was die KI konkret kann.

Vier produktive Funktions-Blöcke. Klick auf einen Tab für Details, jede Funktion mit konkreten Modell-Fähigkeiten und Quellen-Bezug.

APL-Erkennung mit Confidence-Werten

Der Abschlusspunkt Linientechnik (APL) ist der zentrale Prüf-Gegenstand jeder Bauabnahme. Das Modell unterscheidet Zustände mit dokumentierter Erkennungssicherheit pro Objekt.

APL-Status: Open / Closed / Covered
Multibox APL: Open / Closed
Green plugin: internal / external
Vertical black rectangle, APL bottom recognition
Confidence-Wert (0-100%) für jedes erkannte Objekt

Modell-Grenze: Die KI-Modelle sind hochspezialisiert auf FTTH-Komponenten und liefern in diesem Kontext sehr hohe Präzision. Neue Anwendungsfälle erfordern neues Training mit mindestens 250 hochwertigen Bildern pro Erkennungsmuster.

Hauseinführungs-Klassifikation (HZF)

Prüfung der korrekten Verlegung von Kabeln an der Hauseinführung - innen und außen, abgedeckt oder nicht abgedeckt. Direktes Mapping auf typische Bauabnahme-Kriterien der Carrier.

Inside cable: rounded covered / not covered
Outside cable: covered / not covered
Multi-Object-Detection pro Bild
Image-Cropping zu definierten Koordinaten

Datenformate: JPEG, PNG. Mindestanforderung pro neues Erkennungsmuster: 250 hochwertige Trainings-Bilder. Vergleich Branche: Orange France hat 80.000 Fotos in 3 Monaten gelabelt.

Dokumenten-Extraktion und Klassifikation

Begehungsprotokolle, Splice-Reports, Bauakten. Text-Extraktion aus digitalen und gescannten PDFs, strukturierte Daten aus Freitext mit Hilfe von LLM.

OCR für gescannte Dokumente
Text-Extraktion aus digitalen PDFs
Strukturierte Extraktion via Large Language Model
AO-Nummer und Adress-Extraktion aus Begehungsprotokollen
OTDR-SOR-Parsing für Messprotokoll-Verifizierung

Roadmap-Hinweis: Erweiterte Unterschriften-Erkennung, Handschrift-OCR und kontextbasierte PII-Anonymisierung werden modular ergänzt. Konkrete Verfügbarkeit wird projektspezifisch abgestimmt.

Reporting, Auto-Sortierung, Audit-Spur

Das eigentliche Wertversprechen: Aus Tausenden chaotischen Dateien wird eine strukturierte Liste mit klaren Aussagen - welcher Hausanschluss, welcher Prüfpunkt, welches Ergebnis, welche Quelle.

CSV-Reports und Excel-Exports
Prediction-Summaries (alle erkannten Objekte)
Processing-Summary (Success/Errors/Time)
Automatische Datei-Umbenennung mit Inhaltsbezug
Neusortierung in strukturierte Ordner
Trennung von Duplikaten und irrelevanten Bildern

Hinweis: Fehlerlisten und Rechnungsfreigabe-Empfehlungen werden aus den KI-Reports strukturiert abgeleitet. Vollautomatische Dashboards sind modular ergänzbar und werden im Onboarding projektspezifisch konfiguriert.

Pre-Validation

Der schnelle Einstieg in die automatische Dokumentenkontrolle.

Bevor eine KI-Prüfung Sinn ergibt, muss klar sein, was geliefert wurde - und ob es vollständig, konsistent und frei von Duplikaten ist. Diese Vorprüfung ist in der Praxis ein eigenständiger Arbeitsschritt mit messbarem Nutzen - und Sie können ihn bei Fiberproof AI als eigenständiges Modul nutzen.

Mengen-Audit nach Datentyp

Pro Hausanschluss und Projektordner wird gezählt, wie viele JPEG-Bilder, PDF-Dokumente und OTDR-SOR-Messdateien geliefert wurden. Die Ist-Werte werden gegen Soll-Vorgaben (z.B. Excel-Anhang) abgeglichen.

Metadaten-Präsenz-Check

Für jede Bilddatei wird geprüft, ob Geodaten (EXIF-GPS) vorhanden sind. Die Ergebnisspalte "Geodata Present" (Yes/No) zeigt sofort, welche Bilder für die spätere Adress-Zuordnung tauglich sind.

Cross-Address-Duplikat-Erkennung

Datei-Duplikate werden explizit über Adress-Grenzen hinweg erkannt. Wenn dieselbe Datei in zwei Hausanschluss-Ordnern auftaucht, weist der Report dies klar aus - mit Verweis auf alle Fundorte. Das kann ein technischer Zufall sein oder ein Fraud-Indikator. Sie sehen es und entscheiden.

Prävalidierungs-Bericht

Das Ergebnis liegt als CSV vor und ist direkt im Datasets-Bereich der Anwendung als "Download Report" verfügbar - ohne Umweg über E-Mail oder Cloud-Storage.

Pre-validate only - der Toggle

Pre-Validation lässt sich als reine Audit-Stufe nutzen. Aktivieren Sie den Schalter "Pre-validate only" beim Upload, stoppt das System nach der Vorvalidierung. Sie erhalten den Prävalidierungs-Bericht, das Dataset bleibt für spätere KI-Läufe gespeichert. Kein erneuter Upload erforderlich, wenn Sie später die volle Pipeline anwenden wollen - einfach den Toggle deaktivieren und Lauf aus dem bestehenden Dataset starten. Der Prävalidierungs-Bericht wird in beiden Fällen erzeugt.

Einsatzszenarien

Eingangskontrolle bei NetzbetreibernVollständigkeits- und Duplikatprüfung vor manueller Stichprobe oder weiterer technischer Prüfung.

Fördermittel-VorauditMengen- und Vollständigkeitsnachweis je Hausanschluss vor Antragseinreichung beim Fördergeber.

Lieferanten-Briefing bei GUKonkrete Liefer-Defizit-Liste pro Subunternehmer und Hausanschluss, ohne KI-Inhalts-Bewertung.

Fraud-IndikatorCross-Address-Duplikate sind ein konkreter, juristisch verwertbarer Audit-Befund.

Funktionsverzeichnis

Jedes Modul im Detail. Klick öffnet die Funktion in der Tiefe.

Hinter jedem Klick steht die vollständige Funktionsbeschreibung: Zweck, Eingaben, Verarbeitung, Ergebnisse und typische Einsatzszenarien. So sehen Sie auf einen Blick, was eine Funktion liefert – und wo sie in Ihrem Auftrags- und Qualitätsprozess greift.

Bewährt in Kundenprojekten: Die Erkennungs-Module sind in produktiven Kundenprojekten mit unterschiedlichen Bauteil-Varianten, Beschriftungssystemen und Protokoll-Vorlagen trainiert. Trainingsdaten decken APL-Varianten, Gebäudeverteiler-Modelle und Spleißkassetten-Bauformen mehrerer Netzbetreiber ab sowie die Laser-Warnhinweis-Variantenfamilie über alle Hardware-Komponenten hinweg.

Plattform-Module 4

Intake (Upload)

Zweck: Strukturierte Übernahme von Datenpaketen (Bilder, Protokolle, Messdaten) in die Verarbeitungspipeline. Validierung der Ordnerstruktur und SDI-/Adress-Schlüssel.
Input: ZIP-/Ordnerstruktur mit JPG/JPEG-Bildern, PDF-Protokollen, SOR-Messdateien; optional via UI-Upload oder S3-Sync.
Output: Dataset-Objekt mit Building-/Apartment-/Cellar-Hierarchie, eindeutige Dataset-ID, Asset-Inventar.
Use-Case-Beispiele: Upload eines Bauloses durch einen Tiefbau-Subunternehmer; Massenimport eines Carrier-Bestandes über S3.
Status: Produktiv

Pre-Validation

Zweck: Strukturierter Datenqualitäts-Check vor jeder KI-Verarbeitung. Erkennt Dateitypen, Duplikate (Datei-Hash, nicht Dateiname) und Geodaten-Präsenz. Verhindert Folgekosten durch unbrauchbare Datenpakete.
Input: Dataset aus Intake.
Output: PDF-Summary-Report, CSV-Reports (general, directory-duplicates, dataset-duplicates), ZIP-Paket; Spalten EXIF-Present / GPS-Present pro Bild; "Pre-validate Only"-Flag möglich (Dataset wird vom Run-Interface ausgeschlossen).
Use-Case-Beispiele: Audit eines Datensatzes vor Beauftragung; Aufspüren von Cross-Address-Duplikaten als Fraud-Indikator.
Status: Produktiv

Preflight (Konfigurator)

Zweck: Use-Case-spezifische Modul-Auswahl durch den Kunden. Bildet ab, welche atomaren Erkennungs- und Validierungs-Module für einen konkreten Auftrag aktiviert werden, welche Schwellenwerte gelten und welche CSV-Spalten im Output erscheinen. Kern der Modularität: Aus über 50 atomaren Modulen wird hier der konkrete Auftrag komponiert.
Input: Auftragstyp, Carrier-/Bauträger-Profil, gewünschte Use-Case-Komposition (z.B. NE4, GEO, LAS, BEP, Dokumenten-Pflicht), kundenspezifische Schwellen, Sprachvariante.
Output: Run-Konfiguration (Modul-Liste, Schwellen, Routing-Regeln), gespeichertes Profil für Wiederverwendung.
Use-Case-Beispiele: Carrier konfiguriert "NE4-Abnahme" mit GF-GV-, GF-TA-, Spleißkassetten-Modulen; Bauträger konfiguriert "BEP-Massenprüfung" mit BEP- und Black-Cable-Modulen; Forensik-Mandant konfiguriert "Datenintegritäts-Audit" nur mit Pre-Validation und Cross-Validation-Modulen.
Status: Produktiv

Reporting

Zweck: Konsolidierte Ausgabe der atomaren Modul-Ergebnisse in CSV/Excel. Strukturiert nach Building/Apartment/Adresse. Optional als ZIP-Paket inklusive PDF-Summary.
Input: Modul-Outputs (Boolean-Felder, Confidence-Scores, OCR-Strings, Geo-Adressen).
Output: CSV/Excel mit Spalten je Modul, Mehrwert-Spalten (Cross-Address-Duplikate, Uniqueness-Flags), PDF-Summary, optionale GIS-Anbindung.
Use-Case-Beispiele: Excel-Report für Auftraggeber-Freigabe; CSV-Import in downstream RIMO-System.
Status: Produktiv

APL-Familie (Abschlusspunkt Linientechnik) 11

APL geschlossen

Zweck: Erkennt das Vorhandensein eines APL in geschlossenem Zustand auf einem Installationsbild.
Input: JPG/JPEG-Bild.
Output: Boolean (APL geschlossen erkannt: ja/nein), Confidence-Score, Bounding-Box-Koordinaten.
Use-Case-Beispiele: Abnahme einer regulär verschlossenen Hausanschluss-Installation; Prüfung der Verschluss-Disziplin am Ende einer Bauphase.
Status: Produktiv

APL offen

Zweck: Erkennt einen geöffneten APL, bei dem die innere Verkabelung sichtbar ist.
Input: JPG/JPEG-Bild.
Output: Boolean (APL offen erkannt: ja/nein), Confidence-Score, Bounding-Box.
Use-Case-Beispiele: Spleiß-Dokumentations-Audit; Voraussetzung für nachgelagerte Open-Pattern-Module.
Status: Produktiv

APL covered

Zweck: Erkennt einen abgedeckten/verkleideten APL (z.B. mit Schutzkappe oder eingebauter Front).
Input: JPG/JPEG-Bild.
Output: Boolean (APL covered: ja/nein), Confidence-Score.
Use-Case-Beispiele: Dokumentation kundengerechter Endmontage; Differenzierung zwischen montiertem und werkseitig verschlossenem Zustand.
Status: Produktiv

APL Multibox geschlossen

Zweck: Erkennt einen Mehrfach-APL (Multibox / GF-GV) in geschlossenem Zustand.
Input: JPG/JPEG-Bild.
Output: Boolean (Multibox geschlossen: ja/nein), Confidence-Score.
Use-Case-Beispiele: Abnahme einer Etagen-Mehrfachversorgung im Mehrfamilienhaus.
Status: Produktiv

APL Multibox offen

Zweck: Erkennt einen Mehrfach-APL (Multibox / GF-GV) in geöffnetem Zustand.
Input: JPG/JPEG-Bild.
Output: Boolean (Multibox offen: ja/nein), Confidence-Score.
Use-Case-Beispiele: Spleiß- und Verteiler-Dokumentation; Voraussetzung für Connector-Counting und Faserfarben-Module.
Status: Produktiv

APL-Open-Pattern: Vertical black rectangle

Zweck: Erkennt das vertikale schwarze Rechteck (eingebauter Spleißbereich) im geöffneten APL als Indikator für eine korrekt eingebaute Spleißkomponente.
Input: JPG/JPEG-Bild eines geöffneten APL.
Output: Boolean, Confidence-Score.
Use-Case-Beispiele: Detaillierte Spleiß-Bauausführungs-Prüfung.
Status: Produktiv

APL-Open-Pattern: Green plugin internal

Zweck: Erkennt einen grünen Steckverbinder im Inneren des geöffneten APL.
Input: JPG/JPEG-Bild eines geöffneten APL.
Output: Boolean, Confidence-Score.
Use-Case-Beispiele: Verifikation, dass die werkseitig vorgesehene Anschlussvariante gewählt wurde.
Status: Produktiv

APL-Open-Pattern: Green plugin external upper

Zweck: Erkennt einen grünen Steckverbinder an der oberen Außenseite des geöffneten APL.
Input: JPG/JPEG-Bild.
Output: Boolean, Confidence-Score.
Use-Case-Beispiele: Differenzierung zwischen verschiedenen Carrier-Varianten der APL-Bestückung.
Status: Produktiv

APL-Open-Pattern: Green plugin external bottom

Zweck: Erkennt einen grünen Steckverbinder an der unteren Außenseite des geöffneten APL.
Input: JPG/JPEG-Bild.
Output: Boolean, Confidence-Score.
Use-Case-Beispiele: Differenzierung zwischen verschiedenen Carrier-Varianten der APL-Bestückung.
Status: Produktiv

APL-Open-Pattern: Pigtail

Zweck: Erkennt einen Pigtail (vorkonfektioniertes Faser-Ende mit Stecker) im geöffneten APL.
Input: JPG/JPEG-Bild.
Output: Boolean, Confidence-Score.
Use-Case-Beispiele: Nachweis korrekt vorbereiteter Anschlussfasern in der Endmontage.
Status: Produktiv

APL-Open-Pattern: Horizontal black rectangle

Zweck: Erkennt das horizontale schwarze Rechteck (alternative Spleiß-Einbaurichtung) im geöffneten APL.
Input: JPG/JPEG-Bild.
Output: Boolean, Confidence-Score.
Use-Case-Beispiele: Detail-Audit für Spleißlagen-Konformität bei verschiedenen APL-Herstellern.
Status: Produktiv

Hauseinführungs-Familie (HZF) 6

Inside entry covered

Zweck: Erkennt eine abgedeckte innere Hauseinführung (Wandseite Innenraum) auf einem Bild.
Input: JPG/JPEG-Bild.
Output: Boolean (Inside entry covered: ja/nein), Confidence-Score.
Use-Case-Beispiele: Abnahme der Bauleistung an der Übergabe Außen/Innen; Prüfung der baulichen Endabnahme.
Status: Produktiv

Inside entry connection cable

Zweck: Erkennt das Vorhandensein eines Anschlusskabels an der inneren Hauseinführung.
Input: JPG/JPEG-Bild.
Output: Boolean, Confidence-Score.
Use-Case-Beispiele: Nachweis, dass die innere Hauseinführung tatsächlich kabelgebunden weitergeführt ist.
Status: Produktiv

Outside entry covered

Zweck: Erkennt eine abgedeckte äußere Hauseinführung (Wandseite Außen) auf einem Bild.
Input: JPG/JPEG-Bild.
Output: Boolean, Confidence-Score.
Use-Case-Beispiele: Wetterfestigkeits-Audit; Baufortschritts-Nachweis.
Status: Produktiv

Outside entry connection cable

Zweck: Erkennt das Vorhandensein eines Anschlusskabels an der äußeren Hauseinführung.
Input: JPG/JPEG-Bild.
Output: Boolean, Confidence-Score.
Use-Case-Beispiele: Nachweis, dass die äußere Einführung Kabel führt und nicht leer endet.
Status: Produktiv

Other outside entry

Zweck: Erkennt alternative oder atypische äußere Hauseinführungen, die nicht zu den Standardmustern passen (z.B. Schornstein-, Garage-, Nebengebäudeeinführungen).
Input: JPG/JPEG-Bild.
Output: Boolean, Confidence-Score, Variantenklasse.
Use-Case-Beispiele: Sonderfall-Erkennung in heterogenen Baubeständen.
Status: Produktiv

In-house installation

Zweck: Erkennt eine Inhouse-Installation als Gesamtkontext (Treppenhaus, Keller, Übergang vom Hausanschluss zur Wohnung).
Input: JPG/JPEG-Bild.
Output: Boolean, Confidence-Score, Kontextklasse.
Use-Case-Beispiele: Routing der Bilder in den NE4-Pipeline-Zweig; Differenzierung von Außenaufnahmen.
Status: Produktiv

Use-Case-Kompositionen 5

LAS – Laser-Sicherheits-Validierung

Komposition: Pre-Classifier + APL-Familie (APL geschlossen / APL offen / Multibox geschlossen / Multibox offen) + Gf-TA-Familie + Laser-Warnhinweis Sticker + Laser-Warnhinweis eingeprägte Markierung + Reporting.
Zweck: Pflicht-Audit der Laser-Warnkennzeichnung auf allen sichtbaren Geräten gegenüber Arbeitsschutz-/Carrier-Standards.
Status: Produktiv

GEO – Geo-Anreicherung

Komposition: EXIF-GPS-Präsenz-Check + Geokodierung Provider-agnostisch + Adress-Strukturierung + Georeferenzierung der Prüfergebnisse + optional GIS-Anbindung.
Zweck: Anreicherung jedes Bild- und Modul-Outputs um eine kanonische Postadresse und kartenfähige Koordinate.
Status: Produktiv

NE4 – Netzebene-4-Inhouse-Audit

Komposition: Pre-Classifier + APL-Familie (geschlossen/offen) + Multibox-Familie + Hauseinführungs-Familie + Gf-GV-Familie + Gf-TA-Familie + Spleißkassetten-Familie + ONT-Familie + Kabel-/Komponenten-Familie + Messprotokoll-Erkennung + Abnahmeprotokoll-Erkennung + Apartment-Nummer-Extraktion + Home-ID-Extraktion + Gf-TA Wohnungsnummer-Eindeutigkeit + Gf-TA HomeID-Eindeutigkeit + Reporting.
Zweck: Vollständige Abnahme-Prüfung einer Inhouse-Glasfaserinstallation vom Hausanschluss bis zum aktiven ONT.
Status: Produktiv

Dokumenten-Pflicht – Bauakten-Vollständigkeit

Komposition: Pre-Validation + Abnahmeprotokoll-Erkennung + Messprotokoll-Erkennung + AO-Nummer-Extraktion + Adress-Extraktion aus Protokoll + Unterschriften-Präsenz-Erkennung + Unterschriften-Inhalts-OCR + Handschrift-OCR + Reporting.
Zweck: Audit der dokumentarischen Vollständigkeit einer Bauakte; Schwelle für Auszahlungsfreigabe.
Status: Produktiv

Forensische Massenprüfung

Komposition: Intake + Pre-Validation + EXIF-GPS-Präsenz-Check + Geokodierung Provider-agnostisch + Bild-Protokoll-Konsistenz + Predictive Analytics Fehlerhäufung + Reporting.
Zweck: Aufdeckung systematischer Fehler, Cross-Address-Duplikate, Fraud-Indikatoren und Bauausführungs-Auffälligkeiten in großen Baulos-Beständen.
Status: Produktiv

Gf-GV-Familie (Gebäudeverteiler) 5

Gf-GV offen – Verkabelung

Zweck: Erkennt die sichtbare Verkabelung im geöffneten Gebäudeverteiler.
Input: JPG/JPEG-Bild des geöffneten Gf-GV.
Output: Boolean (Verkabelung erkennbar: ja/nein), Confidence-Score.
Use-Case-Beispiele: Abnahme der Etageninstallation in Mehrfamilienhäusern.
Status: Produktiv

Gf-GV offen – Faserfarben

Zweck: Erkennt definierte Faserfarben (Rot/Grün als Primärpaar) im geöffneten Gf-GV und validiert deren Vorhandensein.
Input: JPG/JPEG-Bild des geöffneten Gf-GV.
Output: Boolean (Rot UND Grün erkannt → TRUE), Confidence-Score, erkannte Farbliste.
Use-Case-Beispiele: Farbcode-Konformitätsprüfung gegenüber Herstellervorgabe.
Status: Produktiv

Gf-GV geschlossen – Schloss

Zweck: Erkennt das Vorhandensein eines Schlosses am geschlossenen Gf-GV.
Input: JPG/JPEG-Bild.
Output: Boolean (Schloss vorhanden: ja/nein), Confidence-Score.
Use-Case-Beispiele: Diebstahl-/Manipulationsschutz-Audit; Compliance gegenüber Sicherheitsstandards.
Status: Produktiv

Gf-GV geschlossen – Warnhinweis

Zweck: Erkennt das Vorhandensein eines Warnhinweisaufklebers oder Schildes am geschlossenen Gf-GV.
Input: JPG/JPEG-Bild.
Output: Boolean (Warnhinweis vorhanden: ja/nein), Confidence-Score.
Use-Case-Beispiele: Pflichtkennzeichnung nach Carrier-/Netzbetreiber-Standard.
Status: Produktiv

Gf-GV geschlossen – Schutzrohr

Zweck: Erkennt das Vorhandensein eines Schutzrohrs am Übergang zum geschlossenen Gf-GV.
Input: JPG/JPEG-Bild.
Output: Boolean, Confidence-Score.
Use-Case-Beispiele: Bauphysik-Audit; Zugentlastungs-Konformität.
Status: Produktiv

Gf-TA-Familie (Teilnehmeranschluss) 3

Gf-TA Logo-Eindeutigkeit

Zweck: Erkennt das Hersteller-Logo (z.B. Genexis) auf dem Gf-TA-Gerät und validiert die geforderte Herstellervariante.
Input: JPG/JPEG-Bild des Gf-TA.
Output: Boolean (Logo erkannt: ja/nein), Confidence-Score, ggf. erkannter Hersteller.
Use-Case-Beispiele: Wareneingangskontrolle des verbauten Teilnehmeranschlusses; Vendor-Compliance.
Status: Produktiv

Gf-TA Wohnungsnummer-Eindeutigkeit

Zweck: Validiert, dass die per OCR extrahierte Apartment-Nummer (App. No.) pro Gebäude/Adresse nur einmal vergeben ist.
Input: OCR-Ergebnis der Apartment-Nummer aus Gf-TA-Bild + Adress-Kontext.
Output: Boolean (Duplikat: ja/nein), Liste der betroffenen Wohnungen bei Duplikat.
Use-Case-Beispiele: Bestandsbereinigung; Frühwarnsystem für Doppel-Aufschaltungen.
Status: Produktiv

Gf-TA HomeID-Eindeutigkeit

Zweck: Validiert, dass die per OCR extrahierte Home-ID projektweit (Dataset-übergreifend) eindeutig ist.
Input: OCR-Ergebnis der Home-ID + Dataset-Kontext.
Output: Boolean (Duplikat: ja/nein), Liste der Konfliktfälle.
Use-Case-Beispiele: Carrier-weite Bestandsdaten-Hygiene; Vermeidung von Abrechnungs-Konflikten.
Status: Produktiv

Spleißkassetten-Familie 4

Spleißkassette vorhanden

Zweck: Erkennt das Vorhandensein einer Spleißkassette auf einem Installationsbild.
Input: JPG/JPEG-Bild.
Output: Boolean (Spleißkassette vorhanden: ja/nein), Confidence-Score, Bounding-Box.
Use-Case-Beispiele: Nachweis fachgerechter Faser-Endmontage; Routing zu den abhängigen Crimp- und Farb-Modulen.
Status: Produktiv

Spleißkassette Crimpschutz

Zweck: Erkennt das Vorhandensein eines Crimpschutzes an einer detektierten Spleißkassette.
Input: JPG/JPEG-Bild mit vorab erkannter Spleißkassette.
Output: Boolean, Confidence-Score.
Use-Case-Beispiele: Konformitätsnachweis mechanischer Faser-Sicherung gegen Zug-/Knickbruch.
Status: Produktiv

Spleißkassette Faserfarben

Zweck: Erkennt definierte Faserfarben (Rot/Grün als Primärpaar) auf beiden Seiten des Crimpschutzes und validiert paarweise Übereinstimmung.
Input: JPG/JPEG-Bild der Spleißkassette mit Crimpschutz.
Output: Boolean (matching: correct/incorrect), Liste der erkannten Farben pro Seite.
Use-Case-Beispiele: Spleiß-Korrektheits-Audit auf Faserebene; Vermeidung von Cross-Connect-Fehlern.
Status: Produktiv

Spleißkassette Handschrift-Etikett

Zweck: Erkennt das Vorhandensein einer handschriftlichen Beschriftung an der Spleißkassette (keine inhaltliche Extraktion erforderlich).
Input: JPG/JPEG-Bild.
Output: Boolean, Confidence-Score.
Use-Case-Beispiele: Nachweis dokumentierter Spleißzuordnung; Vorbereitung für nachgelagerte Handschrift-OCR.
Status: Produktiv

ONT-Familie 2

ONT-Erkennung

Zweck: Erkennt das Vorhandensein eines Optical Network Terminal (ONT) auf einem Installationsbild.
Input: JPG/JPEG-Bild.
Output: Boolean (ONT erkannt: ja/nein), Confidence-Score, Bounding-Box.
Use-Case-Beispiele: Inhouse-Abnahme; Übergabe des aktiven Endgeräts an den Kunden.
Status: Produktiv

ONT-Status

Zweck: Erkennt den Betriebszustand des ONT anhand sichtbarer LED-Indikatoren oder Display-Inhalte (vereinfacht: aktiv/inaktiv).
Input: JPG/JPEG-Bild des ONT.
Output: Statusklasse (aktiv/inaktiv/unklar), Confidence-Score.
Use-Case-Beispiele: Funktionsnachweis bei Abnahme; First-Light-Check.
Status: Produktiv

Kabel- und Komponenten-Familie 11

Microduct branch

Zweck: Erkennt eine Microduct-Verzweigung (Erdkabel-Aufteilung) auf einem Bild.
Input: JPG/JPEG-Bild.
Output: Boolean (Microduct-Branch erkannt: ja/nein), Confidence-Score.
Use-Case-Beispiele: Tiefbau-Dokumentation; Bestands-GIS-Anreicherung.
Status: Produktiv

Kink protection (Knickschutz)

Zweck: Erkennt einen Knickschutz an Kabelübergängen.
Input: JPG/JPEG-Bild.
Output: Boolean, Confidence-Score.
Use-Case-Beispiele: Mechanische Bauqualitätsprüfung.
Status: Produktiv

Corrugated pipe (Wellrohr)

Zweck: Erkennt ein Wellrohr (Cable Protection Variante) als Kabelschutz.
Input: JPG/JPEG-Bild.
Output: Boolean (Wellrohr erkannt: ja/nein), Confidence-Score.
Use-Case-Beispiele: Auswahl zwischen Schutzvarianten (PG-Pipe / Wellrohr / Kabelkanal) je nach Carrier-Vorgabe.
Status: Produktiv

Rectangular cable duct (Rechteck-Kabelkanal)

Zweck: Erkennt einen rechteckigen Kabelkanal als Schutzvariante.
Input: JPG/JPEG-Bild.
Output: Boolean, Confidence-Score.
Use-Case-Beispiele: Inhouse-Installations-Konformität gegenüber Carrier-Vorgaben.
Status: Produktiv

PG pipe (PG-Rohr)

Zweck: Erkennt ein PG-Rohr als Kabelschutzvariante am Kabelschutzanschluss zur Multibox.
Input: JPG/JPEG-Bild.
Output: Boolean, Confidence-Score.
Use-Case-Beispiele: Standardvariante in vielen NE4-Installationen.
Status: Produktiv

Kabelschutz-Multibox-Anbindung

Zweck: Validiert per räumlicher Schnittmenge der Objekt-Koordinaten, ob mindestens ein detektierter Kabelschutz tatsächlich an die Multibox angebunden ist.
Input: Detektierte Multibox-Koordinaten + Detektierte Kabelschutz-Koordinaten.
Output: Boolean (Anbindung vorhanden: ja/nein).
Use-Case-Beispiele: Konsistenzprüfung gegen "nur abgelegte" Schutzrohre ohne tatsächliche Anbindung.
Status: Produktiv

BEP-Erkennung (Building Entry Point)

Zweck: Erkennt das Vorhandensein eines BEP (Building Entry Point, grau-rechteckiges Gehäuse) auf einem Installationsbild.
Input: JPG/JPEG-Bild.
Output: Boolean, Confidence-Score, Bounding-Box.
Use-Case-Beispiele: Hausanschluss-Abnahme; primärer Aggregationsschlüssel SDI Building.
Status: Produktiv

Black cable ellipse

Zweck: Erkennt ein elliptisch verlegtes schwarzes Kabel als geometrisches Verlege-Muster.
Input: JPG/JPEG-Bild.
Output: Boolean, Confidence-Score.
Use-Case-Beispiele: Erkennung dokumentierter Kabelreserve; Bauqualitäts-Nachweis.
Status: Produktiv

Black cable rolled (gewickeltes Schwarzkabel)

Zweck: Erkennt ein sichtbar aufgewickeltes schwarzes Kabel ("schwarzer Kreis") unabhängig vom Verlegungsort (innerhalb BEP, in Schacht, an Wand).
Input: JPG/JPEG-Bild.
Output: Boolean, Confidence-Score.
Use-Case-Beispiele: Nachweis ordnungsgemäßer Kabelreserve am Hausanschluss.
Status: Produktiv

Fiber spliced (Faser gespleißt)

Zweck: Erkennt einen ausgeführten Spleiß, bei dem eingehende Faser und Kundenfaser sichtbar verbunden sind.
Input: JPG/JPEG-Bild der Spleißstelle/Spleißkassette.
Output: Boolean (Spleiß ausgeführt: ja/nein), Confidence-Score.
Use-Case-Beispiele: Kunden-Aufschalt-Nachweis; Abrechnungsfreigabe nach Spleiß-Ausführung.
Status: Produktiv

Multibox-Cable-Labeling

Zweck: Erkennt das Vorhandensein einer Beschriftung an weißen NE4-Kabeln in der geöffneten Multibox (Beschriftung vorhanden: ja/nein; ohne inhaltliche OCR).
Input: JPG/JPEG-Bild der geöffneten Multibox.
Output: Boolean (Labeling vorhanden: ja/nein), Confidence-Score.
Use-Case-Beispiele: Nachweis nachvollziehbarer Kabelzuordnung; Vorbereitung für nachgelagerte OCR.
Status: Produktiv

Laser-Warnhinweis-Familie (cross-cutting) 2

Laser-Warnhinweis Sticker

Zweck: Erkennt einen klassischen Laser-Warnaufkleber (gelbes Dreieck mit schwarzem Lasersymbol) auf einem Installationsbild. Cross-cutting Modul, anwendbar auf APL, GF-GV (Multibox), GF-TA.
Input: JPG/JPEG-Bild.
Output: Boolean (Laser Warning Presence: present / not present), Confidence-Score.
Use-Case-Beispiele: Pflicht-Kennzeichnung gegenüber Arbeitsschutz-Standards; Compliance-Audit Lasersicherheit.
Status: Produktiv

Laser-Warnhinweis eingeprägte Markierung

Zweck: Erkennt eine eingeprägte (geprägte/embossed) Laser-Warnmarkierung auf der Hardware-Oberfläche, alternativ zum Sticker.
Input: JPG/JPEG-Bild des Gerätes.
Output: Boolean, Confidence-Score.
Use-Case-Beispiele: Erfassung herstellerabhängiger Markierungsvarianten; Doppel-Pflichtkennzeichnung-Audit.
Status: Produktiv

OCR-Module (Dokumenten- und Geräte-Texterkennung) 6

Abnahmeprotokoll-Erkennung

Zweck: Erkennt das Vorhandensein eines Abnahmeprotokolls als Dokumententyp (Klassifikation, ohne Inhaltsextraktion).
Input: PDF oder JPG.
Output: Boolean (Acceptance Protocol erkannt: ja/nein).
Use-Case-Beispiele: Dokumentenpflicht-Audit; Vollständigkeitskontrolle der Bauakte.
Status: Produktiv

Messprotokoll-Erkennung ("dB"-Trigger)

Zweck: Erkennt das Vorhandensein eines Messprotokolls auf einem Geräte-Display und validiert die Präsenz des Zeichens "dB" auf dem Bildschirm.
Input: JPG/JPEG-Bild eines Messgeräte-Displays.
Output: Boolean (Measurement Protocol erkannt: ja/nein), Boolean ("dB"-Präsenz: ja/nein).
Use-Case-Beispiele: Erstabnahme nach Spleiß; Bauausführungs-Nachweis der Dämpfungsmessung.
Status: Produktiv

Apartment-Nummer-Extraktion (App. No.)

Zweck: Extrahiert die Wohnungsnummer von einem erkannten Gf-TA per OCR (ohne Pattern-Validierung, nur Längenbegrenzung).
Input: JPG/JPEG-Bild des Gf-TA.
Output: String (extrahierte App. No.) + Confidence-Score.
Use-Case-Beispiele: Eingabe für das Wohnungsnummer-Eindeutigkeits-Modul.
Status: Produktiv

Home-ID-Extraktion

Zweck: Extrahiert die Home-ID von einem erkannten Gf-TA per OCR.
Input: JPG/JPEG-Bild des Gf-TA.
Output: String (extrahierte Home-ID) + Confidence-Score.
Use-Case-Beispiele: Eingabe für das HomeID-Eindeutigkeits-Modul; Verknüpfung mit Auftragsbestand.
Status: Produktiv

AO-Nummer-Extraktion

Zweck: Extrahiert die Auftrags-/Ordernummer aus Protokoll-Dokumenten oder aus dem Dateipfad.
Input: PDF-Protokoll oder Dateipfad-String.
Output: String (AO-Nummer) + Quelle (Pfad/Inhalt).
Use-Case-Beispiele: Verknüpfung von Bildmaterial mit Auftragsdaten ohne Datei-Umbenennung.
Status: Produktiv

Adress-Extraktion aus Protokoll

Zweck: Extrahiert die Liegenschafts-Adresse aus dem Inhalt eines Abnahmeprotokolls oder aus dem Dateipfad.
Input: PDF-Protokoll oder Dateipfad-String.
Output: Strukturierter Adress-String (Strasse, Hausnummer, PLZ, Stadt).
Use-Case-Beispiele: Konsistenzabgleich gegen GPS-/EXIF-Adresse; GIS-Anreicherung.
Status: Produktiv

OTDR-Module (Messdaten-Auswertung) 4

SOR-Datei-Parsing

Zweck: Parst SOR-Dateien als autoritative Quelle der OTDR-Messdaten (PDF-OTDR-Protokolle werden nicht mehr als Quelle verwendet).
Input: .sor-Datei.
Output: Strukturierte Felder: wavelength, range_value, refl_thr, total_loss.
Use-Case-Beispiele: Maschinelle OTDR-Bestandsauswertung; Vermeidung manueller PDF-Auslese.
Status: Produktiv

OTDR-Dämpfungs-Auswertung

Zweck: Validiert die extrahierten Dämpfungswerte (total_loss in dB) gegen vorgegebene Schwellen.
Input: total_loss aus SOR-Parsing.
Output: Boolean (Schwelle eingehalten: ja/nein) + Wert + Schwelle.
Use-Case-Beispiele: Abnahmeprüfung gegen Carrier-Schwellwerte.
Status: Produktiv

OTDR-Reflexions-Auswertung

Zweck: Validiert den Reflexionsschwellwert (refl_thr) gegen die Vorgabe < −55.000 dB.
Input: refl_thr aus SOR-Parsing.
Output: Boolean (refl_thr < −55.000 dB: true/false).
Use-Case-Beispiele: Steckverbinder- und Spleißqualitätsprüfung.
Status: Produktiv

OTDR-Wellenlängen-Plausibilität

Zweck: Prüft, ob die extrahierte Wellenlänge in der erlaubten Liste liegt (1310 / 1490 / 1550 / 1610 / 1625 nm).
Input: wavelength aus SOR-Parsing.
Output: Boolean (gültige Wellenlänge: ja/nein).
Use-Case-Beispiele: Mess-Setup-Qualitätskontrolle.
Status: Produktiv

Geo-Module 3

EXIF-GPS-Präsenz-Check

Zweck: Prüft, ob ein Bild EXIF-Metadaten und GPS-Koordinaten enthält, ohne Reverse-Geocoding auszulösen. Kostenarmer Vor-Check.
Input: JPG/JPEG-Bild.
Output: Zwei Boolean-Spalten: EXIF Data Present (Yes/No), GPS Coordinates Present (Yes/No).
Use-Case-Beispiele: Pre-Validation; Audit, ob die feldarbeitende Mannschaft GPS aktiviert hat.
Status: Produktiv

Geokodierung – vorwärts und rückwärts

Zweck: Wandelt GPS-Koordinaten in strukturierte Postadressen (Reverse-Geocoding) und Postadressen in GPS-Koordinaten (Forward-Geocoding). In beide Richtungen ein einziger Dienst – die Quelle der Geodaten wird hinter der Plattform gekapselt.
Input: Latitude/Longitude aus EXIF oder eine freie/strukturierte Postadresse.
Output: Strukturierte Adressfelder (PLZ, Land, Stadt, Straße, Hausnummer) bzw. Latitude/Longitude; Fail-Flag bei nicht auflösbarer Anfrage.
Use-Case-Beispiele: Vor-Befüllung des Adressfelds für die Auftragsanlage; Geo-Konsistenz-Audit; Anreicherung von Adresslisten mit Koordinaten für GIS- oder Planungssysteme.
Status: Produktiv

Adress-Strukturierung (PLZ/Stadt/Strasse/Hausnummer/Zusatz)

Zweck: Normalisiert die aus Geokodierung gelieferten Felder in eine kanonische Form für CSV/Excel-Ausgabe.
Input: Roh-Adresse aus Geokodierung.
Output: Felder PLZ, Stadt, Strasse, Hausnummer, Zusatz; Mehrfach-Adressen pro Objekt werden durch Semikolon getrennt ausgegeben.
Use-Case-Beispiele: Sauber importierbare Excel-Daten für RIMO/SAP/GIS.
Status: Produktiv

Unterschriften- und Handschrift-Module 3

Unterschriften-Präsenz-Erkennung

Zweck: Erkennt das Vorhandensein einer Unterschrift in einem Protokoll-Dokument.
Input: PDF oder JPG eines Abnahmeprotokolls.
Output: Boolean (Unterschrift vorhanden: ja/nein), Confidence-Score, Bounding-Box.
Use-Case-Beispiele: Vollständigkeits-Audit Abnahmeprotokolle; Schwellenwert für Auszahlungsfreigabe.
Status: Produktiv

Unterschriften-Inhalts-OCR

Zweck: OCR-Versuch auf der Unterschriftenzeile zur Extraktion eines lesbaren Klartext-Namens (Fallback: leerer String).
Input: Bounding-Box-Auszug aus Protokoll.
Output: String (Klartext-Name oder leer), Confidence-Score.
Use-Case-Beispiele: Plausibilitätscheck gegen Auftragnehmer-Stammdaten.
Status: Produktiv

Handschrift-OCR

Zweck: Liest handschriftliche Notizen auf Spleißkassetten, Etiketten oder Protokollen aus.
Input: JPG/JPEG-Bild oder PDF-Ausschnitt.
Output: String, Confidence-Score.
Use-Case-Beispiele: Spleiß-Zuordnungsnotizen digitalisieren; Bauakten-Volltextindex.
Status: Produktiv

PII-Anonymisierungs-Module 3

Personen-Anonymisierung

Zweck: Erkennt sichtbare Personen auf Bildmaterial und überzeichnet sie irreversibel.
Input: JPG/JPEG-Bild.
Output: Anonymisiertes JPG/JPEG, Maske, Boolean (Personen erkannt: ja/nein).
Use-Case-Beispiele: DSGVO-konforme Übergabe an Auftraggeber; Veröffentlichungsfreigabe.
Status: Produktiv

KFZ-Kennzeichen-Anonymisierung

Zweck: Erkennt und überzeichnet KFZ-Kennzeichen auf Bildmaterial irreversibel.
Input: JPG/JPEG-Bild.
Output: Anonymisiertes JPG/JPEG, Maske, Boolean.
Use-Case-Beispiele: Außenaufnahmen mit parkenden Fahrzeugen vor Hauseinführungen.
Status: Produktiv

Klingelschilder-Anonymisierung

Zweck: Erkennt und überzeichnet Namen auf Klingelschildern, Briefkästen und ähnlichen Hinweisschildern.
Input: JPG/JPEG-Bild.
Output: Anonymisiertes JPG/JPEG, Maske, Boolean.
Use-Case-Beispiele: Hauseingangs-Aufnahmen; Schutz Drittbetroffener.
Status: Produktiv

Integrations-Module 2

GIS-Anbindung

Zweck: Stellt eine konfigurierbare Schnittstelle zu Kunden-GIS-Systemen bereit (Bestandsdokumentation, GeoJSON/Shapefile-Export, Web-Map-Service).
Input: Modul-Outputs mit Geo-Bezug (Adresse, Lat/Lon, Asset-IDs).
Output: Geokodierte Datensätze im Zielformat des GIS; optional Live-Sync.
Use-Case-Beispiele: Anreicherung Carrier-Bestandsdatenbank; Tiefbau-Asset-Pflege.
Status: Produktiv

Georeferenzierung der Prüfergebnisse

Zweck: Verknüpft Modul-Outputs (Bool-Felder, Defekt-Flags) mit präziser räumlicher Koordinate, sodass Prüfergebnisse kartenbasiert auswertbar sind.
Input: Modul-Outputs + GPS-Koordinaten.
Output: GeoJSON-Feature-Collection mit Asset-Properties.
Use-Case-Beispiele: Hotspot-Analyse von Bauausführungs-Mängeln; Bauleitungs-Heatmap.
Status: Produktiv

Cross-Validation-Module 2

Bild-Protokoll-Konsistenz

Zweck: Vergleicht Bild-erkannte Sachverhalte (z.B. APL erkannt) mit den im zugehörigen Abnahmeprotokoll dokumentierten Feldern und meldet Abweichungen.
Input: Modul-Outputs Bild + OCR-Outputs Protokoll.
Output: Konsistenz-Boolean pro Prüfdimension, Detail-Spalten mit erkannten Abweichungen.
Use-Case-Beispiele: Aufdeckung von "Protokoll grün, Bild rot"-Diskrepanzen; Fraud-Detection.
Status: Produktiv

Predictive Analytics Fehlerhäufung

Zweck: Statistische Analyse der Modul-Outputs über ein Baulos oder eine Carrier-Region, um auffällige Fehlerhäufungen (nach Subunternehmer, Region, Zeitraum) zu identifizieren.
Input: Aggregierte Modul-Outputs über mehrere Datasets.
Output: Auffälligkeits-Score, Top-N-Listen, Drill-Down-Tabellen.
Use-Case-Beispiele: Subunternehmer-Steuerung; Qualitäts-Frühwarnsystem.
Status: Produktiv

Pre-Classifier-Modul (Routing) 1

Pre-Classifier

Zweck: Leichtgewichtige Bildklassifikation, die vor jedem Object-Detection-Modul läuft und entscheidet, welche atomaren Module für ein konkretes Bild überhaupt aufgerufen werden. Filtert irrelevante Bilder (Privatfotos, unverwandte Objekte) aus der Pipeline aus. Spart Rechenzeit und vermeidet Fehlalarme.
Input: JPG/JPEG-Bild.
Output: Routing-Entscheidung (Liste der nachgelagert auszuführenden Modul-IDs); Filter-Boolean (Bild relevant: ja/nein).
Use-Case-Beispiele: Massendatenverarbeitung mit gemischten Bildinhalten; Kostenoptimierung in der Cloud-Verarbeitung.
Status: Produktiv

Integration und Plattform

Fiberproof AI als Funktionsblock für Carrier, Dienstleister und Managed Service Provider.

Sie betreiben eigene Bautagebücher, Abnahme-Tools oder Workflow-Plattformen für FTTH-Projekte? Fiberproof AI ist nicht nur als komplette Lösung nutzbar, sondern auch als modulare API-Plattform. Einzelne Erkennungs-Module integrieren Sie direkt in Ihre bestehenden Tools - mandantenfähig, audit-konform, headless betreibbar.

REST-API mit Token-Authentifizierung

Token-basierte Authentifizierung als Standard (Bearer-Token statt HTTP Basic Auth). Sicherer, rotierbar, audit-fähig.
Jedes Erkennungs-Modul als API-Endpoint: APL-Erkennung, OTDR-Auswertung, Geo-Adress-Strukturierung, Spleißkassetten-Prüfung. Einzeln aufrufbar.
Rollenbasierte Sichten: Admin sieht vollständige Verwaltungs-UI, Service-User nur den Upload-Endpoint. Klare Trennung von Konfiguration und Nutzung.

One-Click-Upload + Instant Processing

Headless-Workflow: Upload eines Datenpakets triggert sofortige Verarbeitung. Keine manuelle UI-Bedienung erforderlich.
Pre-konfigurierte Verarbeitungsketten pro Mandant (Customer, Projekt, Processing-Config). Der Endnutzer wählt nur sein Daten-Verzeichnis und klickt einmal.
Statusrückmeldung in Echtzeit: Die API liefert sofort eine Prozess-ID; der finale Status wird per Email zurückgemeldet oder über Polling-Endpoint abgerufen.

Mandantenfähig - Eine Plattform, viele Tenants

Pro-Mandant-isolierte Pre-Konfigurationen in der Datenbank: jeder Tenant hat eigene Customer/Projekt/Module-Kombinationen.
Einheitliche Codebase, instance-spezifische Konfiguration. Updates erreichen alle Mandanten konsistent, ohne Code-Forks.
Daten-Isolation auf S3- und Datenbank-Ebene. Keine Vermischung zwischen Mandanten, keine Quersicht.

Enterprise-Email-Layer (verifizierte AWS SES)

Async-Notifications für jeden Verarbeitungslauf: Pre-Validation-Completion, Processing-Completion, Failure-Alert.
Verifizierte Absender via AWS SES: hohe Zustellqualität, Multi-Tenant-tauglich, keine manuelle Empfänger-Verifikation pro Adresse.
Empfänger-Logik konfigurierbar: Notifications gehen wahlweise an den auslösenden Nutzer, eine zentrale Service-Mailbox oder beide.

Beispiel: Ein Managed Service Provider integriert das APL-Erkennungs-Modul in sein eigenes Bautagebuch. Sein Endnutzer lädt Fotos im Bautagebuch hoch; im Hintergrund ruft das Bautagebuch unsere REST-API mit Bearer-Token auf, erhält die strukturierten Erkennungs-Ergebnisse zurück und schreibt sie in die eigene Datenbank. Der Endnutzer merkt von Fiberproof AI nichts - er bekommt nur das Ergebnis in seinem gewohnten Tool.

Alle Module aus dem Modul-Marktplatz sind REST-API-fähig. Sprechen Sie uns an, wenn Sie ein Modul in Ihre Plattform integrieren möchten - wir richten den Mandanten-Slot, die Token und die Pre-Konfiguration gemeinsam mit Ihnen ein.

Vertrauen und Compliance

KRITIS und NIS-2 sind für Sie kein Thema - so funktioniert die Entkopplung.

Die häufigsten Bedenken bei KI-Plattformen kommen aus den Bereichen KRITIS, NIS-2 und DSGVO. Wir beantworten sie strukturell - nicht durch Versprechen, sondern durch die Architektur unserer Zusammenarbeit.

KRITIS und NIS-2 fallen für Sie strukturell weg

Unsere Infrastruktur gehört nicht zu Ihrer Infrastruktur. Fiberproof AI läuft als eigenständige SaaS-Plattform in EU-Hosting. Kein Mischbetrieb mit Ihren produktiven Systemen.
Sie haben keine Steuerungsfunktion auf unseren Betrieb. Sie nutzen die Lösung als Dienstleistung, ohne in unseren technischen Betrieb einzugreifen. Damit fällt unser System nicht in den Geltungsbereich Ihres KRITIS- oder NIS-2-Scopes.
LATUS Consulting AG ist selbst nicht NIS-2-pflichtig (Beratungsunternehmen außerhalb der genannten Sektoren).

DSGVO-konform - mit nachweisbaren Belegen

EU-Data-Residency. Verarbeitung und Speicherung ausschließlich in der EU. Auftragsverarbeitungsvertrag gemäß Art. 28 DSGVO ist Standard-Bestandteil.
Mandantenfähige Isolation. Ihre Daten sind technisch von Daten anderer Kunden getrennt. Keine Vermischung, keine Quersicht.
Klar abgegrenzte Verarbeitungszwecke. Wir verarbeiten Ihre Daten ausschließlich für die im AVV definierten Zwecke - keine Anonymisierung für KI-Training Dritter, kein Re-Use.
Verschlüsselung Ende-zu-Ende. TLS 1.3 in Transit, AES-256 at Rest. Multi-Faktor-Authentifizierung für alle Zugriffe.

Audit-Daten und Löschvorgänge - dokumentiert auf Anforderung

Lückenlose Verarbeitungsspur pro Datei. Wir liefern auf Anforderung Audit-Berichte: welche Datei wurde wann von welchem Modul verarbeitet, mit welchem Ergebnis, durch welchen Nutzer.
Löschkonzept nach Ihren Vorgaben. Aufbewahrungsfristen werden projektspezifisch konfiguriert. Löschvorgänge sind protokolliert und auf Anfrage als signiertes Löschprotokoll verfügbar.
Recht auf Vergessen. Auf Verlangen der betroffenen Person löschen wir personenbezogene Daten innerhalb der gesetzlichen Frist und liefern den Nachweis.
72-Stunden-Meldepflicht. Bei Sicherheitsvorfällen informieren wir Sie als Verantwortlichen gemäß Art. 33 DSGVO innerhalb von 72 Stunden, mit definierten Meldewegen.

Konkrete Anforderungen aus Ihrem internen Compliance-Konzept (spezifische Meldepflichten, ergänzende Audit-Anforderungen, ISO-27001-Anlagen) arbeiten wir im Onboarding ein.

Häufige Fragen

Antworten auf die typischen Fragen.

Was Neukunden in den ersten Gesprächen am häufigsten fragen - kompakt beantwortet.

Wie schnell kann ein Onboarding starten?

Ein typisches Onboarding mit Customizing dauert 4 bis 6 Wochen. Das umfasst Kick-off-Workshop, Datenanalyse, Spezifikation der Prüfkriterien, Anlernen der Modelle mit Ihren Daten und Bereitstellung der Test-Umgebung. Danach folgt eine Pilot-Phase mit einem repräsentativen Datensatz (5.000 bis 10.000 Dokumente).

Wie gut ist die Erkennungsqualität wirklich?

In den dokumentierten Pilot-Projekten erreichen wir >99% Confidence bei der APL-Erkennung. Wichtig: Confidence ist die Erkennungssicherheit pro Objekt, nicht die absolute Trefferquote über alle Bildtypen. Die Modelle sind spezialisiert auf FTTH-Komponenten - in diesem Kontext sehr hoch, außerhalb (z.B. komplett anderer Bauteil-Typ) muss neu trainiert werden.

Wo liegen die Daten und ist das DSGVO-konform?

Hosting in AWS Frankfurt (EU-Data-Residency), End-to-End-Verschlüsselung (TLS 1.3 in Transit, AES-256 at Rest), VPC-Isolation, rollenbasierte Zugriffskontrolle (RBAC), Multi-Faktor-Authentifizierung. Auftragsverarbeitungsvertrag (AVV) gemäß Art. 28 DSGVO ist Standard-Bestandteil jedes Engagements. Löschkonzept und Aufbewahrungsfristen werden projektspezifisch nach Ihren Vorgaben konfiguriert. Eine On-Premises-Variante ist optional möglich, falls Datenklasse oder interne Policy das fordert.

Wie steht es mit KRITIS und der NIS-2-Richtlinie?

Unsere Architektur entkoppelt Sie strukturell von beiden Themen:

Unsere Infrastruktur gehört nicht zu Ihrer Infrastruktur. Fiberproof AI läuft als eigenständige SaaS-Plattform in EU-Hosting. Es gibt keinen Mischbetrieb mit Ihren produktiven Systemen.
Sie haben keine Steuerungsfunktion auf unseren Betrieb. Sie nutzen die Lösung als Dienstleistung, ohne in unseren technischen Betrieb einzugreifen. Damit fällt unser System nicht in den Geltungsbereich Ihres KRITIS- oder NIS-2-Scopes.
LATUS Consulting AG selbst ist nicht NIS-2-pflichtig (Beratungsunternehmen, außerhalb der genannten Sektoren).
Vertraglich regeln wir die Zusammenarbeit über einen Auftragsverarbeitungsvertrag gemäß Art. 28 DSGVO mit den üblichen Anlagen zu technisch-organisatorischen Maßnahmen, Audit-Recht und Meldewegen bei Sicherheitsvorfällen.

Konkrete Anforderungen aus Ihrem internen Compliance-Konzept (z.B. spezifische Meldepflichten, Aufbewahrungsfristen, ergänzende Audit-Anforderungen) arbeiten wir im Onboarding ein.

Wie werden Sicherheitsvorfälle behandelt?

AWS-Multi-Layered-Security (VPC-Isolation, IAM-RBAC, KMS-Encryption, GuardDuty-Monitoring). Datenflüsse sind ausschließlich verschlüsselt. Bei Vorfallserkennung greifen die Standard-AWS-Incident-Response-Prozesse plus unsere vertragliche 72-Stunden-Meldepflicht an Sie als Verantwortlichen (Art. 33 DSGVO). Penetrationstests werden projektspezifisch eingeplant. Audit-Spuren über jede Datei und jeden Verarbeitungsschritt sind Standard-Output der Plattform.

Welche Datenformate verarbeitet die Plattform?

Bilder: JPEG, PNG. Dokumente: PDF (digital und gescannt). Messdaten: SOR-Dateien (OTDR), XLSX. Upload über Web-Drag-and-Drop, SharePoint, AWS S3 oder API. Multi-Objekt-Erkennung pro Bild ist Standard.

Wie integriert sich Fiberproof AI in bestehende Systeme?

REST-API-First-Ansatz. Jeder Kunde bekommt eine eigene API-Key-Konfiguration. Output ist CSV/Excel oder direkter API-Response. SharePoint-Integration vorhanden, weitere Connectoren (z.B. zu GIS-Systemen) sind in der Roadmap. White-Label-Fähigkeit für System-Integratoren ist gegeben.

Was unterscheidet Fiberproof AI vom Wettbewerb?

Drei Punkte: End-to-End-Lösung (Bildanalyse + Dokumentenprüfung + OTDR-Validierung kombiniert, andere Anbieter decken meist nur einen Teilbereich ab). Forensische Massenprüfung auf Bestandsdaten (>100.000 Dokumente nachträglich strukturieren). FTTH-Spezialisierung mit vorkonfigurierten Modellen statt Generalisten-KI.

Welche Daten braucht die KI für Modell-Training?

Mindestens 250 hochwertige Bilder pro Erkennungsmuster. Qualität ist entscheidend - schlechte oder leere Dateien sind ungeeignet. Zum Vergleich aus der Branche: Orange France hat 80.000 Fotos in 3 Monaten Entwicklung gelabelt. Wir können auf bereits trainierten FTTH-Modellen aufsetzen - es muss also nicht jeder Kunde bei null beginnen.

Nächster Schritt

Sehen Sie Fiberproof AI an Ihren eigene Daten.

Eine Live-Demo zeigt die Lösung in 30 Minuten am Beispiel realer FTTH-Daten. Optional anschließend: Pilot mit einem Baulos Ihrer Wahl, klare Aussage zu Zeit- und Qualitätseffekten in 4 bis 6 Wochen.

Live-Demo direkt öffnen Demo-Termin vereinbaren

LATUS Consulting AG·Entwicklung mit vertrauenswürdigem Software-Partner in der EU·Hosting in der EU (AWS Frankfurt)·latus-consulting.de