Unternehmens-Intelligence: Eine Entscheidungsarchitektur mit OSINT und Data Fusion

Wenn eine Organisation eine Entscheidung trifft, befindet sich mehr als die Hälfte der benötigten Information bereits in ihren eigenen Systemen. Die andere Hälfte liegt in offenen externen Quellen: öffentliche Register, soziale Medien, Branchennachrichten, Dark-Web-Leaks, Daten von Drittanbietern. Das Problem ist nicht der Zugriff auf Information, sondern die Fähigkeit, beide Mengen so zu kombinieren, dass sie dieselbe Frage beantworten. Was unser Cyber-Intelligence-Team in den letzten drei Jahren beobachtet hat: Unternehmensentscheidungen verzögern sich meistens nicht wegen „Datenmangel", sondern wegen „Datenfragmentierung".

Dieser Artikel erklärt, wie OSINT und Data Fusion zusammenarbeiten und die Entscheidungsschicht einer Organisation verändern. Technische Architektur, rechtliche Grenzen und operative Praxis in einem Stück. Wir teilen sieben Praktiken, die unser Engineering-Team beim Aufbau von Plattformen im Palantir-Stil gelernt hat.

1. Die Grenze zwischen den beiden Disziplinen und wo sie sich treffen

OSINT (Open Source Intelligence) bezeichnet eine Art von Datenquelle — strukturierte Information, die rechtmäßig aus öffentlich zugänglichen digitalen Spuren gesammelt wird. Der Inhalt umfasst öffentliche Register (Handelsregister, Gerichtsentscheidungen, Steuerdaten), offene Social-Media-Beiträge, Nachrichtenseiten, Dark-Web-Foren (innerhalb rechtlicher Grenzen), Unternehmenswebsites, wissenschaftliche Artikel und externe Datenanbieter.

Data Fusion hingegen ist die Disziplin, Daten aus verschiedenen Quellen in einem einzigen Verbindungsgraphen zusammenzuführen. Die Quellen können OSINT sein, Ihr Unternehmens-CRM, Ihre SOC-Logs oder externe Threat-Intelligence-Feeds. Der Wert von Data Fusion liegt nicht im Sammeln neuer Daten, sondern darin, bestehende Daten so zu modellieren, dass sie neue Fragen beantworten.

Beide Disziplinen treffen sich hier: Die roh gesammelten OSINT-Daten integrieren Sie über eine Data-Fusion-Plattform mit Ihren Unternehmensdaten. OSINT allein bleibt als PDF-Bericht; Data Fusion allein ist eingesperrt und kann nicht nach außen sehen. Kombiniert werden Fragen wie „Mit welchem Rechtsstreit war dieser neue Lead in den letzten sechs Monaten verbunden, welches Vorstandsmitglied folgte welchem Wettbewerber auf Twitter, ist die BIST-Kursbewegung mit unseren letzten Berichten konsistent?" mit einem Klick beantwortet.

2. Datenquellen-Mapping — die erste Woche

Die kritischste Aufgabe zu Beginn jedes Data-Fusion-Projekts ist die Erstellung einer Quellenkarte. Das ist keine „Wir nutzen diese Systeme"-Liste; es ist eine detaillierte Inventur, welche Entitäten jedes System hält, welche Felder matchbar sind, wie oft aktualisiert wird.

Eine typische Unternehmenskarte umfasst:

• Unternehmenssysteme: CRM (Kunde, Kontakt, Opportunity), ERP (Bestellung, Rechnung, Lager), HR-System (Mitarbeiter, Position), Helpdesk (Ticket, Lösung).
• Operative Daten: SOC-Logs, Netzwerk-Telemetrie, Applikations-Logs, Audit-Trail.
• OSINT-Feeds: Handelsregister-APIs, BIST / Finanzdatenanbieter, Dark-Web-Monitoring-Dienste, Social-Media-Monitoring (innerhalb rechtlicher Grenzen), KVKK-Meldungsseite für Datenpannen.
• Dokumentenarchiv: Verträge, juristische Korrespondenz, Audit-Berichte, Kundengesprächsnotizen.

Die häufigste Überraschung beim Mapping: Dieselbe Entität wird mit verschiedenen IDs in verschiedenen Systemen geführt. Derselbe Kunde erscheint im CRM als „Acme A.Ş.", im ERP als „ACME ANONIM SIRKETI" und im Helpdesk als „acme". Das aufzulösen ist ein eigenes Engineering-Problem namens Entity Resolution.

Ein praktisches Beispiel aus zwei jüngeren Projekten: In der Karte, die wir für eine Finanzinstitution erstellten, waren neun verschiedene Systeme aufgeführt; nach zwei Wochen tiefem Scannen entdeckten wir vierzehn. Die fünf fehlenden Systeme waren kleine abteilungsspezifische Werkzeuge (Excel-Makro-Vorlagen, geteilte SharePoint-Ordner, eine alte Access-Datenbank, ein Lieferantenportal, eine E-Mail-Filterregel). Sie fehlten auf der externen Liste, weil die Unternehmens-IT sie als „Shadow IT" behandelte. Praktische Regel: Mapping beginnt immer unvollständig und wird abgeschlossen, indem man die täglichen Arbeitsabläufe der Teams beobachtet. Projekte, die sich nur auf das IT-Inventar des CIO-Büros stützen, stoßen in der Produktion zu 40-60% auf die Überraschung einer „uns unbekannten Datenquelle".

3. Entity Resolution — das Rückgrat des Graphmodells

Entity Resolution ist der Prozess, verschiedene Datensätze zu derselben Entität über verschiedene Systeme hinweg zusammenzuführen. Drei Techniken werden gemeinsam eingesetzt:

Deterministisches Matching: Paarung über eindeutige Identifikatoren wie Steuernummer, MERSIS-Nummer, nationale ID. Am zuverlässigsten; 99%+ Genauigkeit. Grenze: Diese Identifikatoren werden möglicherweise nicht in jedem System geführt.

Probabilistisches Matching: Namensähnlichkeit (Levenshtein-Distanz, phonetische Algorithmen), Telefon-/E-Mail-Normalisierung, Adress-Parsing. 85-95% Genauigkeit; Übereinstimmungen über einem Schwellwert werden automatisch zusammengeführt, darunter fallen sie an einen menschlichen Analysten.

Kontextuelles Matching: Zwei Personen, die an derselben Besprechung teilnahmen, zwei Konten, die von derselben IP-Adresse handeln, zwei Firmen, die dasselbe Dokument unterzeichneten. Wird aus der Nachbarschaft im Graph abgeleitet; durch die KI-Agenten von AIGENCY V4 automatisiert.

Der vereinheitlichte Entitätsgraph, der aus der Kombination dieser drei entsteht, ist die Grundlage jeder späteren Abfrage. Wir reservieren die ersten zwei Wochen jedes Projekts dafür, diesen Graphen korrekt aufzubauen; ist er falsch, arbeitet jede nachfolgende Analyse auf fehlerhaften Daten.

4. KVKK-Konformität — Architekturentscheidung, kein Aufsatz

OSINT- und Data-Fusion-Projekte können KVKK-Konformität nicht als letzte Schicht hinzufügen. Drei Schichten müssen vom ersten Tag an gemeinsam entworfen werden:

Rechtsgrundlagen-Schicht: Welche Datenkategorie (personenbezogen, sensibel, anonym) wird auf welcher Rechtsgrundlage verarbeitet? Jeder Datenfluss wird im Rahmen von KVKK Artikel 5 (ausdrückliche Einwilligung), Artikel 6 (zusätzliche Bedingungen für besondere Kategorien) und Artikel 9 (grenzüberschreitende Übertragung) dokumentiert. Die Sicht „Wir können es verarbeiten, weil es öffentlich ist" ist falsch — KVKK kennt diese Ausnahme nicht; eine Abwägung des berechtigten Interesses ist erforderlich.

Anonymisierungs-Schicht: Wo volle Identität für die Entscheidung nicht erforderlich ist, werden Entity-IDs gehasht; Rohdaten bleiben nur autorisierten Analysten sichtbar, Dashboards zeigen aggregierte / anonymisierte Daten. Die verschlüsselte Speicherschicht von AIGENCY V4 wird genutzt, um die Verarbeitung innerhalb der Türkei zu halten.

Audit-Trail-Schicht: Jede Abfrage erzeugt einen Logeintrag, der zeigt, welche Rolle aus welchem Grund auf welche Entität zugegriffen hat. Das Log wird append-only und unveränderbar geführt. Ein Dump muss auf Anfrage der KVKK-Aufsicht innerhalb von 24 Stunden lieferbar sein.

Werden diese drei Schichten gemeinsam entworfen, hält sich der Compliance-Aufwand auf 5-10% des Gesamtprojektaufwands. Werden sie später hinzugefügt, bedeutet dasselbe Konformitätsniveau 30-50% zusätzliche Entwicklungszeit; unser Enterprise-KI-Plattform-Bereitstellungs-Service enthält diese Architektur als Standard.

5. Berechtigung — wer sieht welchen Knoten

Das am häufigsten vernachlässigte, aber kritischste Merkmal einer Data-Fusion-Plattform ist die rollenbasierte Berechtigung. Eine einzige Datenbank + ein einziges Dashboard funktioniert für kleine Teams; in mittleren bis großen Organisationen entsteht daraus ein Kernsicherheitsproblem.

In einer permissioned Graph-Architektur trägt jeder Knoten (Entität) und jede Kante (Beziehung) eigene Berechtigungsmetadaten. Beispielszenarien:

• Marketing-Analyst: sieht Kundenname + Branche + Verkaufshistorie; finanzielle Solidität ist verborgen.
• Rechtsabteilung: sieht vollen Vertragstext + Risikohinweise; CRM-Kommunikationsnotizen sind verborgen.
• Top-Management: sieht synthetisierte Berichte + Trend-Analysen; KEIN Zugriff auf Rohdaten.
• SOC-Team: sieht alle System-Logs + Threat Intelligence; KEIN Zugriff auf personenbezogene Kundendaten.

Welche Rolle welchen Bereich sieht, wird mit dem Business Owner entschieden, nicht einseitig von Engineering. Unsere Praxis: Beim Projekt-Kickoff wird eine „Rollenmatrix" erstellt; für jede Spalte (Rolle) × Zeile (Entitätstyp) wird eine Zugriffsstufe (keine / aggregiert / Detail) festgelegt. Vor dieser Matrix wird kein Code geschrieben.

6. AIGENCY-V4-Integration — natürlichsprachliche Abfrage

Der wahre Wert eines Data-Fusion-Graphen hängt davon ab, dass Nicht-Analysten Fragen stellen und Antworten erhalten können. Im klassischen Ansatz braucht jede Abfrage einen Datenanalysten, der SQL/Cypher kann; das ist sowohl Engpass als auch hohe Betriebskosten.

Die 8-Agenten-Architektur von AIGENCY V4 beseitigt diesen Engpass. Der Nutzer fragt in natürlicher Sprache: „Welche unserer Fälle betrafen Acme A.Ş. in den letzten sechs Monaten, und welche Vorstandsmitglieder sind mit den in diesen Prozessen genannten Personen verbunden?"

Was das System tut:

1. Koordinator-Agent zerlegt die Frage in Teilaufgaben.
2. Researcher-Agent schreibt Cypher-Abfragen gegen die Graphdatenbank (auf Neo4j) oder ruft die GraphQL-API auf.
3. Reviewer-Agent prüft, dass die Ergebnisse die Berechtigungsschicht passieren; falls nicht, gibt eine Teilantwort zurück.
4. Coder-Agent wandelt Ergebnisse in das vom Nutzer gewünschte Format (Tabelle, Diagramm, Synthese) um.
5. Synthesis-Agent schreibt die Antwort in natürlicher Sprache, mit Quellknotenreferenzen (Beweiskette).

Diese Architektur kommt mit unserem Enterprise-KI-Plattform-Bereitstellungs-Service. Ein geschulter Analyst beantwortet 3-5 Anfragen pro Stunde; ein AIGENCY-V4-unterstütztes System beantwortet 30-50 — der Analyst wird nur in Unsicherheits-Fällen konsultiert.

Natürlichsprachliche Abfragen haben zwei zusätzliche Vorteile. Erstens verlangt die Formulierung einer Frage nicht, dass der Nutzer das Datenmodell lernt; ein Analyst kann „Kundensegment" sagen, während Marketing „Kundenkohorte" sagt, und die Architektur löst beide auf dieselbe Entität auf. Zweitens werden Nutzeranfragen im Laufe der Zeit als Nutzungsmuster erfasst; für die 50 häufigsten Anfragen können materialisierte Sichten erzeugt werden, sodass das System lernt, dort performant zu sein, wo es tatsächlich genutzt wird. Das ist der fundamentale Unterschied zum statischen Dashboard-Ansatz klassischer BI-Werkzeuge.

Die Grenze der natürlichsprachlichen Abfrage lautet: Bei mehrdeutigen oder widersprüchlichen Fragen wendet das Modell seine eigene Interpretation an. Deshalb ist der Reviewer-Agent kritisch — der Parse-Tree der Abfrage wird dem Nutzer mit einer „Wollten Sie das fragen?"-Bestätigung gezeigt. Systeme, die diesen Schritt überspringen, riskieren, eine falsche Antwort als richtig zu präsentieren; in AIGENCY V4 ist dieser Schritt verpflichtend.

7. Typische Setup-Fehler und was wir gelernt haben

Die wiederkehrenden Fehler aus den 12 Data-Fusion-Projekten, die wir in den letzten drei Jahren ausgeliefert haben (und die Prozessänderungen, die wir daraufhin eingeführt haben):

Fehler 1: Datenmodell-Entscheidung zu spät treffen. In unseren ersten beiden Projekten verfeinerten wir das Graphschema nach dem ETL; Resultat: Wir schrieben Pipelines zweimal. Fix: Das Graphschema muss am Ende von Phase 1 (1-2 Wochen) eingefroren sein; alle nachfolgenden Pipelines schreiben auf dieses Schema.

Fehler 2: Einzelner Schwellwert für Entity Resolution. Ein einzelner 0.85-Ähnlichkeitsschwellwert führt entweder zu Überlagerung (Falschpositive) oder zu Unterlagerung (Falschnegative). Fix: Wir nutzen zwei Schwellwerte — über 0.95 Auto-Merge, 0.75-0.95 fällt an einen menschlichen Analysten, darunter wird abgelehnt.

Fehler 3: KVKK-Audit-Fragen ans Ende verlagern. In einem Projekt verpassten wir die Audit-Log-Dump-Anforderung aus dem KVKK-Datenverantwortlichen-Leitfaden am Ende, was drei Wochen Refactor kostete. Fix: Audit-Logging wird jetzt im Sprint 0 gebaut; es ist die erste Implementierung, nicht die letzte.

Fehler 4: Zu viele Nutzeroptionen anbieten. In einem frühen Projekt gaben wir dem Analysten 20+ Filter + 15+ Visualisierungen; niemand nutzte sie alle, und die Dokumentation wucherte. Fix: Drei bis fünf „goldene Szenarien" werden zuerst definiert; alle UI wird darauf optimiert.

Fehler 5: Backup- + Disaster-Recovery-Plan nicht schreiben. Wir erkannten erst nach einem Festplattenausfall zwei Jahre später, wie kritisch die wachsende Graphdatenbank geworden war. Fix: Jedes Projekt enthält jetzt tägliche Snapshots + Cross-Geographie-Replikation (Şanlıurfa + Düsseldorf) + eine 4-Stunden-RPO/RTO-Garantie.

Fehler 6: Performance-Tests nicht im realen Datenmaßstab durchführen. Eine Abfrage, die im Pilot mit 10.000 Knoten perfekt funktionierte, fiel in Produktion mit 5 Millionen Knoten auf 90 Sekunden. Fix: Selbst in der Pilotphase sind Stresstests mit einem synthetischen Datengenerator im Produktionsmaßstab Pflicht. Wir gehen nicht live, bis die p95-Abfragezeit unter 2 Sekunden liegt.

Fehler 7: Nutzerschulung in die letzte Woche legen. Technische Exzellenz allein treibt keine Akzeptanz. In einem früheren Projekt wurde das System ausgeliefert, die Nutzung blieb sechs Wochen später bei 15%, und die Nutzer kehrten zu ihren alten Excel-Berichten zurück. Fix: Ab der Pilotphase werden Endnutzer in wöchentliche Workshops eingebunden; Schulung beginnt am ersten Tag, nicht am Übergabetag. Diese Praxis hat die Akzeptanz auf 85%+ angehoben.

Die Behebung dieser sieben Fehler ist jetzt Teil unseres Standardprozesses; sie gilt von Anfang an für neue Projekte. In der letzten Projektwoche führt ein Ingenieur eine „Was könnte schiefgehen"-Checkliste anhand dieser sieben Überschriften aus — eine letzte Verteidigungsschicht vor der Übergabe.

Entscheidungsmatrix: passt es zu Ihrer Organisation, wann nicht

Data Fusion ist nicht für jede Organisation die richtige Lösung. Drei Fragen geben Ihnen einen schnellen Eindruck:

Drei oder mehr „Ja"-Antworten bedeuten, dass Data Fusion sinnvoll ist. Bei zweien oder weniger evaluieren Sie zuerst einfachere Data-Warehouse- / BI-Optionen; mit wachsendem Maßstab kann man auf Fusion umsteigen.

Unsere Open-Source-Intelligence-Leistung und unsere Data-Fusion-Architektur-Leistung sind als zwei separate Pakete oder kombiniert verfügbar. Unsere typischen Unternehmenskunden wählen beide — weil der Wert von OSINT sich vervielfacht, wenn er mit Unternehmensdaten kombiniert wird.

Unser Pilot-Projekt-Ansatz

Für eine Organisation, die gerade beginnt, empfehlen wir, mit einem 3-Wochen-Pilot zu starten. Der Pilot-Umfang lautet:

• Ein einzelnes Entscheidungsszenario wird ausgewählt (z. B. „Die Risikobewertung eines neuen Leads muss von 1 Stunde auf 5 Minuten sinken").
• Zwei OSINT-Quellen + zwei interne Systeme werden integriert.
• Ein Mini-Graph (5-10 Entitätstypen) + eine Analystenoberfläche wird ausgeliefert.
• Eine Demo + ROI-Bewertung erfolgt am Ende der drei Wochen.

Es folgen zwei Wege: entweder Ausbau (zusätzliche Quellen, Szenarien, Unternehmensmaßstab) oder Umschwenken zu einer einfacheren BI-Lösung. Beide Richtungen werden auf Basis von Belegen gewählt; unser Beratungsprozess trifft diese Entscheidung mit Ihnen, nicht für Sie.

Wenn Sie Ihren eigenen OSINT- + Data-Fusion-Bedarf bewerten möchten, können Sie über unsere Kontaktseite ein Vorgespräch anfragen. In einem kostenlosen 60-Minuten-Gespräch gehen wir durch, wie die sieben Punkte auf Ihr spezifisches Szenario zutreffen, und schlagen einen Pilotumfang vor.

Teilen Sie diesen Artikel gern mit Fachkolleginnen und -kollegen in Ihrer Branche, die einen ähnlichen Aufbau erwägen; konkrete praktische Inhalte zu diesem Thema sind weiterhin rar und wertvoll. Unser Team wird neue Beiträge in unserem Blog ankündigen — als Nächstes geplant: „Entity Resolution mit Permissioned Blockchain" und „Multi-Agent-Analystenarbeitsabläufe mit AIGENCY V4". Sind diese Themen für Sie wichtig, lassen Sie es in der Anfrage wissen, dann teilen wir vor dem Gespräch das relevante technische Material.