Palantir-Dossier: IT der Sicherheitsbehörden – US-Anbieter auf dem Vormarsch – Teil 6

Das Portal Police-IT widmet sich ausführlich dem Themenkomplex Polizei und Informationssysteme, der für jede und jeden relevant ist, da es uns alle jederzeit und unmittelbar betreffen kann. Mit freundlicher Genehmigung der Herausgeberin und langjährigen Expertin für polizeiliche Informationssysteme, Annette Brückner, veröffentlicht RT Deutsch Teile des auf Police-IT erschienenen Dossiers zu Palantir.

Alle auf RT Deutsch erschienenen Teile des Palantir-Dossiers finden Sie hier.

Vorbemerkung der Redaktion: Dieser Teil des Palantir-Dossiers behandelt mit der Funktionsweise die technische Seite der polizeilichen Analyseplattform "Hessendata". Diese Beschreibung technischer Details bietet dafür einen konkreten Einblick in grundlegende Probleme und Gefahren beim praktischen Einsatz und Betrieb eines solchen datenbasierten Analysesystems.

Teil VI – Palantir Gotham alias Hessendata: Dammbruch in der polizeilichen IT

Mit der Analyseplattform Palantir-Gotham alias Hessendata erhält die hessische Polizei erstmals die Möglichkeit, Informationen aus sozialen Medien AUTOMATISIERT abzurufen und mit Daten aus polizeilichen Informationssystemen zusammenzuführen. Das bedeutet nichts weniger als einen Dammbruch in der polizeilichen Arbeit. Richter, Staatsanwälte, Strafverteidiger und Betroffene werden sich wappnen müssen, wenn nicht mehr der "Beweis", sondern Analyseergebnisse aus zusammengemischten Datensammlungen die Maßnahmen der Polizei – auch gegen Unschuldige und Unbeteiligte – bestimmen.

Das gesamte Ermittlungserfahren, das tatrichterliche Verfahren und z.T. auch das Revisionsverfahren bestehen aus dem Suchen nach Beweisen, der Erhebung der Beweise, ihrer Würdigung und aus dem Ziehen von Konsequenzen aus den Beweisergebnissen in der Form von Entscheidungen. (Meyer-Goßner/Schmitt, Kommentar zur Strafprozessordnung, 60. Auflage, 2017, Einl. Rn. 47)

Fragen zu den Datenquellen von Hessendata

Netzwerke von Personen, die in der Nähe einer beobachteten Wohnung leben …

Am 02.07.2018, einen Tag vor der ersten Sitzung des Untersuchungsausschusses im hessischen Landtag, waren Pressevertreter ins Polizeipräsidium Frankfurt eingeladen zu einer Demonstration von Hessendata. Im Bericht der Frankfurter Rundschau hieß es dazu:

Staatsschützer [David] Frank und Projektleiter Bodo Koch (…) demonstrierten, wie die Software den Ermittlern Netzwerke von Personen anzeigt, die etwa vom Handy eines Verdächtigen angerufen wurden oder in der Nähe einer beobachteten Wohnung leben.

Die Frage: Woher stammen Informationen über "Netzwerke von Personen, (…) die in der Nähe einer beobachteten Wohnung leben"?

Da die Polizei vermutlich keine Mitarbeiter hinschickt zum "Klingelputzen" – so der Ausdruck für das Abklappern von Klingelschildern an Wohnungstüren z.B. im Umfeld eines Tatorts –, ist anzunehmen, dass es sich um Datensätze aus dem Melderegister handelt. Dann wäre das Melderegister eine weitere Datenquelle für Hessendata. Polizeibeamte haben über das Vorgangsbearbeitungssystem (in Hessen: ComVor) die Möglichkeit, im Melderegister nach einer bestimmten Person oder Adresse zu suchen. NEU wären automatisierte Abfragen aus Hessendata beim Melderegister UND die Übernahme dieser Daten in das System …

Bewertung: Das "Wohnen in der Nähe einer verdächtigen Person" hat für die polizeiliche Ermittlung und Auswertung keine Relevanz. Für jede einzelne Person musste ermittelt werden, in welcher Beziehung sie zum eigentlichen Subjekt der Analyse steht: Handelt es sich um eine Kontakt- oder Begleitperson, einen Kollegen, Lebens- oder Ehepartner oder Verwandten? Das kostet viel Zeit, führt aber zu belastbaren Ergebnissen. Wieder mal bestätigt sich, dass Erfolg zu 95 Prozent Transpiration und nur zu 5 Prozent Inspiration ist.

Mit der oben beschriebenen Vorgehensweise werden Daten von solchen Personen in das System aufgenommen, von denen überhaupt keine Aussage über die Art der Beziehung zum Subjekt der Analyse gemacht werden kann. Auf diese Weise entsteht FAKE INTELLIGENCE, in der kontextuelle ZUFÄLLE eine vermeintlich polizeiliche Relevanz erhalten, welche in der realen Welt gar nicht existiert. Völlig unverdächtige Personen können dadurch in ein Analyse-Netzwerk von Staatsschützern oder OK-Analytikern geraten und werden selbst zum Subjekt von Hypothesenbildungen oder gar Verdächtigungen – ohne davon auch nur die geringste Ahnung zu haben!

Was sind "Polizeifotos", und wie kommen die ins System Hessendata?

Im erwähnten Bericht der Frankfurter Rundschau über die Präsentation am 02.07.2018 heißt es weiter:

Auch Polizeifotos der Menschen aus dem Umfeld sind abrufbar.

Die Fragen:

1. Was ist hier mit "Polizeifotos" gemeint?
   Unter dem Begriff "Polizeifoto" versteht man im engeren Sinne die fotografischen Aufnahmen, die im Zuge einer erkennungsdienstlichen (= ED) Behandlung einer Person von der Polizei angefertigt werden. Solche ED-Informationen bilden eine eigene Datengruppe im polizeilichen Verbundsystem INPOL. Die Aussage könnte also bedeuten, dass solche, vom polizeilichen Erkennungsdienst angefertigten Fotos ebenfalls aus INPOL ausgelesen und in Hessendata eingefügt werden. Allerdings trifft das ja nur für einen kleinen Bruchteil von Personen überhaupt zu, nämlich nur für diejenigen, die tatsächlich auch einmal erkennungsdienstlich behandelt worden sind.
2. Oder sind vielmehr die Fotos im Personalausweis gemeint? Die Zahl dieser Personen ist ungleich höher als die Zahl der Personen, die erkennungsdienstlich behandelt wurden! Und dazu passt ja auch, dass das Personalausweisgesetz (PAuswG) erst im Sommer 2017 verändert wurde. Im §25, Abs. 2 des PAuswG heißt es dazu: "Die Polizeibehörden des Bundes und der Länder, der Militärische Abschirmdienst, der Bundesnachrichtendienst, die Verfassungsschutzbehörden des Bundes und der Länder, Steuerfahndungsdienststellen der Länder, der Zollfahndungsdienst und die Hauptzollämter dürfen das Lichtbild zur Erfüllung ihrer Aufgaben im automatisierten Verfahren abrufen."
3. Ist in Hessendata also die Möglichkeit des automatischen Abrufs von Personalausweisfotos nach §25, Abs. 2 PAuswG bereits realisiert oder zur Realisierung vorgesehen?
4. Und, wenn ja: Ist dann auch die in §25 PAusWG weiter vorgesehene PROTOKOLLIERUNG DER ABRUFE schon realisiert?
   Denn im Gesetz steht: "Alle Abrufe sind von den beteiligten Behörden so zu protokollieren, dass eine Kontrolle der Zulässigkeit der Abrufe möglich ist. Abrufe nach Satz 4 werden nur von der abrufenden Behörde protokolliert. Die Protokolle enthalten:
   
   1. Familienname, Vornamen sowie Tag und Ort der Geburt der Person, deren Lichtbild abgerufen wurde,
   2. Tag und Uhrzeit des Abrufs,
   3. die Bezeichnung der am Abruf beteiligten Stellen,
   4. die Angabe der abrufenden und der den Abruf anordnenden Person sowie
   5. Das Aktenzeichen."

Werden in Hessendata auch Daten von Facebook & Co automatisiert abgerufen und ausgewertet?

Ausgangspunkt für die Frage: Die Beschreibung des Programms "Raptor" (siehe Teil V) legt nahe, dass Abfragen "on-the-fly" in externen Datenquellen durchgeführt werden. Eine solche Datenquelle könnte Facebook sein. "Raptor" kann also bei Bedarf Informationen über die Person(en) in Facebook abrufen, mit denen sich der Analytiker gerade beschäftigt. Werden dort Treffer gefunden, so können diese permanent in die Revisioning DB von Gotham/Hessendata eingespeichert werden. Et voilá: Schon hat Polizei ein umfassendes Bild (Personagramm) über eine Person, das sich auf dreierlei Datenquellen stützt:

• Fahndungsdatenbanken und andere polizeilichen Informationssysteme
• Informationssysteme anderer Behörden (wie z.B. Ausländerzentralregister, Kraftfahrtbundesamt, Melderegister, u.v.m.
• soziale Medien, wie Facebook, Twitter, Youtube & Co.

Die Fragen:

1. Wurde der Dienst "Raptor" oder eine funktionell vergleichbare Komponente für Hessendata erworben?
2. Wann ist bzw. wird dieser Dienst in Betrieb genommen?
3. Welche "externen" Datenquellen werden aktuell bzw. in Zukunft damit abgefragt?

Bewertung: Im August 2018 wurde das Hessische Gesetz über die öffentliche Sicherheit und Ordnung (HSOG) geändert. In der aktuellen Fassung des §13 dieses Gesetzes – Erhebung personenbezogener Daten – ist vorgesehen:
"Die (…) Polizeibehörden können personenbezogene Daten zur Erfüllung ihrer Aufgaben ERHEBEN, wenn

1. …
2. die Daten allgemein zugänglichen Quellen entnommen werden können oder die betroffene Person die Daten offensichtlich öffentlich zugänglich gemacht hat,
3. …"

In §25 – Datenabgleich – geht es dann um den ABGLEICH von solchen Daten mit Daten aus anderen Systemen. Ohne hier allzu tief in die Einzelheiten einzusteigen, sei gesagt, dass Daten von sämtlichen Personen abgeglichen werden dürfen, wenn dies "zur Erfüllung einer bestimmten polizeilichen Aufgabe erforderlich erscheint". Diese Klausel stellt also nicht wirklich eine Einschränkung der Befugnis zur Datenerhebung dar.

WER DIESE FOLGEN FÜR SICH SELBST VERMEIDEN MÖCHTE, DEM KANN EIGENTLICH NUR GERATEN WERDEN, DATEN ÜBER DIE EIGENE PERSON WEDER IN SOZIALEN MEDIEN NOCH SONSTWO VON SICH AUS ÖFFENTLICH ZUGÄNGLICH ZU MACHEN!

Fragen zur juristischen Relevanz und zur Transparenz der Daten im Analysesystem

Welche Informationen sind eigentlich in einem Strafverfahren relevant: die im Quellsystem oder die im Analysesystem?

Palantir schreibt:

Sobald das Datenmodell und die Integration und Zuweisungsinformationen erst einmal erstellt worden sind, fließen die Daten kontinuierlich aus ihren jeweiligen Quellsystemen in die Palantir-Gotham-Plattform.

Informationen aus unterschiedlichen Quellsysteme werden also in die Revisioning DB des Gotham/Hessendata-Systems übertragen und dort ein weiteres Mal gespeichert. Nur am Rande sei übrigens bemerkt, dass Palantir ja mit dem BETRIEB der Analyseplattform FÜR die hessische Polizei beauftragt ist. Ein externer Dritter betreibt also die Analyseplattform, auf der Daten aus polizeilichen und nicht polizeilichen Quellen über Personen FÜR die hessische Polizei gespeichert und verarbeitet werden!

Bewertung: Ein Forking, eine Gabelung der an sich gleichen Information und Speicherung/Verarbeitung in unterschiedlichen Systemen, bringt das erhebliche Risiko mit sich, dass die Daten auseinanderlaufen, das heißt, dass sie im Quellsystem und im Analysesystem NICHT mehr übereinstimmen. Der Fall um die Journalistenakkreditierung beim G20-Gipfel in Hamburg hatte u.a. diese Ursache. Doch Palantir sagt dazu: "Alle Aktualisierungen an den Quelldaten werden an die Analyseplattform GELIEFERT" ["are pushed to the platform", heißt es im Originaltext"].

Das ist ein sehr umfassendes Versprechen und nur schwer zu glauben:

1. Dazu müsste das Quellsystem ja AKTIV werden und jegliche Änderung vermerken und – in abgestimmter Form und innerhalb abgestimmter Zeit – an das Palantir-System liefern. So etwas ist technisch zwar möglich. Es erfordert jedoch Aktivität VOM QUELLSYSTEM.
   • Wird diese aktive Unterstützung von den Entwicklern von CRIME, dem Fallbearbeitungssystem in Hessen, überhaupt geliefert? Wer sind die aktuell überhaupt? Wie lange dauert eine solche Weiterentwicklung? Und was bringt sie für das System CRIME, dessen Ende längst beschlossen ist?
   • Wer implementiert die entsprechenden Aktivitäten in POLAS für die beiden Fahndungsdatenbanken? Und wann ist diese Funktionalität dann auch für die Palantir-Platform verfügbar? Und wer bezahlt das? Vor allem dann, wenn es eine Funktion ist, die aktuell nur in Hessen benötigt wird? Nicht aber in den anderen Ländern/Behörden, die auch mit POLAS arbeiten?
   • Sinngemäß lassen sich die gleichen Fragen stellen für die in Hessen eingesetzten Überwachungsprogramme der Telekommunikation (TK),
   • für die forensischen Systeme zum Auslesen von Handy-Daten, wie z.B. EnCase
   • und für das System EPOST810 für die Fernschreiben im polizeiinternen Verkehr.
2. Wenn das Quellsystem selbst jedoch NICHT AKTIV wird – was aus Gründen der Abstimmung mit mehreren Systemanbietern, der Kosten und ungeklärter Fragen, insbesondere bei CRIME, wahrscheinlich erscheint: Dann lassen sich Veränderungen zwischen den Daten im Quellsystem und denen auf der Palantir-Plattform nur durch einen PERMANENTEN VERGLEICH zwischen relevanten Beständen der jeweiligen Systeme feststellen. Das ist ein immenser Aufwand. Und erfordert auch ein logisches Re-Mapping, was nach einem Hinweis in einem Palantir-Datenblatt auch tatsächlich geleistet wird. Palantir "weiß" also auch, wie die in Hessendata objektorientierte Struktur jedes Informationsobjekts und seiner Beziehungen und Dokumente auch – umgekehrt – im Quellsystem strukturiert und gespeichert ist. Und es kann diese Informationen gezielt dort auslesen. Das erfordert folglich auch die Einwilligung des jeweiligen Systembetreibers auf einen automatisierten Zugriff auf das jeweilige Quellsystem und die technische Realisierung dieses Zugriffs: Alles in allem – meiner Erfahrung nach – eine Option, die – obwohl grundsätzlich denkbar – in der Praxis abgelehnt und daher nicht realisiert wird.

Entgegen der – vielleicht etwas vollmundigen – Werbeaussage erscheint es durchaus möglich, dass der auf der Palantir-Plattform GEDOPPELTE Datenbestand vom Originalbestand immer mehr abweichen wird.

Die Frage: Welchen Aussagewert haben eigentlich die Informationen auf der Analyseplattform? Vor allem für die Verwendung im Rahmen der Strafverfolgung und nach den Regeln der Strafprozessordnung? Wenn Zweifel bestehen können, ob es aktuelle, valide, vollständige und richtige Informationen sind, auf deren Basis dort Auswertungen getroffen werden? Dieser Einwand sollte insbesondere STAATSANWÄLTEN, RICHTERN und STRAFVERTEIDIGERN zu denken geben!

Wer – außer der Polizei – kann eigentlich einsehen, was im Analysesystem gespeichert ist?

Die Datenschützer, falls Ihnen diese Antwort eingefallen ist, sind es sicher NICHT! Die können höflich fragen und um Antworten bitten. Sie können jedoch nicht SELBST prüfen, was eigentlich alles in einem polizeilichen Informationssystem gespeichert ist. Übrigens: Dürfen die Datenschützer überhaupt ein System prüfen, das von einer externen Firma BETRIEBEN wird?

Die Polizei selbst (gegenüber den Betroffenen)? Eher nicht: Der Gesetzgeber in Hessen hat sich jedenfalls große Mühe gemacht und mit dem §29 des HSOG eineinhalb A4-Seiten unverdaulichen Text aufgewendet, um Information, Benachrichtigung und Auskunft (an Betroffene von einer Speicherung) faktisch unmöglich zu machen. Im darauf folgenden §29a – Datenschutzkontrolle – genügten dann drei ZEILEN zur Beschreibung der (eingeschränkten) Kontrollrechte des/der Datenschutzbeauftragten.

Die Polizei wird Ihnen als Betroffenem in gewohnter Praxis erklären, dass es sich um Informationen handelt, die der Geheimhaltung bedürfen und für die im Übrigen keine Auskunftspflicht besteht. Einem Rechtsanwalt, den Sie u.U. einschalten, wird es auch nicht anders gehen. Denn derzeit gibt es keine wirksam und zeitnah durchsetzbare Rechtsgrundlage dafür, dass die Polizei Auskünfte gegenüber einem Betroffenen erteilen müsste, also gegenüber einem Menschen, dessen personenbezogene Daten dort gespeichert sind.

Die meisten Betroffenen ahnen jedoch gar nicht, dass Informationen über sie in einem solchen System gespeichert sind. Daran wird sich solange nichts ändern, bis einer breiteren Zahl von Betroffenen, Anwälten, Staatsanwälten und Richtern aufgefallen sein wird, dass die Ergebnisse dieser Analysen einer wesentlich besseren Datenqualitätskontrolle unterworfen werden müssen. Und dass wesentlich mehr Transparenz nötig ist. Um vielleicht doch noch aufzuhalten oder zumindest zu verlangsamen, dass sich diese Demokratie zunehmend in Richtung Orwell'scher Visionen – gepaart mit den seit Orwell wesentlich verbesserten Möglichkeiten undurchschaubarer Algorithmen – entwickeln wird.

Fragen zur Qualität und Verlässlichkeit der Daten

NOCH sind die Datenquellen, aus denen Hessendata gespeist wird, im Wesentlichen strukturiert, das heißt, sie haben jeweils eine festgelegte und sich nicht ändernde Datenstruktur. Das gilt für die beiden Fahndungsdatenbanken, für das Fallbearbeitungssystem CRIME, für die Daten aus TK-Überwachungsmaßnahmen, für solche aus dem Auslesen sichergestellter Handys und bei den Fernschreiben zumindest für den Kopf jedes Fernschreibens.

Wie zuverlässig funktioniert die automatische Aufbereitung der Informationen aus unstrukturierten Datenquellen?

Daneben gibt es aber auch jetzt schon Teilbereiche mit unstrukturierten Daten. Das sind z.B. die Freitextfelder, wie sie im Fallbearbeitungssystem CRIME verwendet werden. Oder die Textfelder aus den Fernschreiben des Bundeskriminalamts (BKA): Um die Inhalte solcher Texte auswertbar zu machen, müssen sie – automatisiert – analysiert und in die objektorientierte Speicherstruktur (siehe Teil V) überführt werden. Das bedeutet: Aus Freitexten müssen die darin enthaltenen Informationsobjekte erkannt werden, der richtige Objekttyp muss bestimmt werden und sie müssen richtig benannt werden. Diese, technisch so genannte "Object Extraction", ist keine triviale Aufgabe. Sie erfordert den Einsatz spezieller linguistischer Werkzeuge, die natürlich geeignet sein müssen, mit Texten in deutscher Sprache umzugehen.

Die Fragen:

• Werden überhaupt spezielle Werkzeuge für die Object Extraction in Hessen eingesetzt? Wenn ja: Von welchem Hersteller stammen die und was kostet es, bis diese Werkzeuge funktionsfähig sind?
• Mit welcher Erfolgsquote erkennen diese Werkzeuge automatisch Objekte vom Typ Person, Geschäftsbetrieb, KfZ, Telefonanschluss, IP-Adresse, E-Mail-Adresse – um nur die wichtigsten und automatisiert gut identifizierbaren Objekttypen zu nennen?

Wie verhindert Hessendata, dass aus einem "Objekt der realen Welt" mehrere Informationsobjekte im Analysesystem werden?

"Objekt-Identität" ist ein wichtiges, aber ziemlich schwierig zu lösendes Problem. Die Forderung dahinter lautet: Jedes Objekt in der realen Welt soll durch EIN UND NUR EIN Informationsobjekt im Analysesystem repräsentiert sein.

Doch die Wirklichkeit sieht meist ganz anders aus:

• Schon kleine Schreibfehler machen aus EINER Person in der Wirklichkeit, mehrere Personenobjekte im System: Georg Meier wird zum Georg Meyer oder Mair oder Maier oder Mayer … Bei Namen von ausländischen Personen, vielleicht sogar noch aus arabischen Ländern oder Ländern mit anderem Zeichenvorrat, potenziert sich dieses Problem!
• Ein Objekt ist gar nicht mit einem KONKRETEN NAMEN bekannt. Beim ersten Mord im NSU-Verfahren haben Zeugen zwei jüngere Männer beobachtet, die sich vom Tatort mit Fahrrädern entfernt hatten. In verbreiteter polizeilicher Schreibweise könnten diese als "uPm1" und "uPM2" (= unbekannte männliche Person X) erfasst worden sein. Erst später und in ganz anderem Zusammenhang stellt sich heraus, dass diese Personen (wahrscheinlich) Uwe Böhnhardt und Uwe Mundlos hießen. Wie werden solche "Aliasobjekte" in Hessendata zu einem Objekt verschmolzen?

Ein ähnliches Problem stellt sich, wenn die Polizei – an sich ja vollkommen regelkonform – in Freitextfeldern Personen NICHT mit konkreten Namensangaben bezeichnet, sondern vom "Zeugen", "Tatverdächtigen" oder "Geschädigten" spricht. So sehen es die Datenschützer gerne. Diese unkonkreten Bezeichnungen lassen sich aber kaum mehr nachträglich und automatisiert einer bestimmten Person zuordnen.

Fragen zum Informationsmodell

Das mit der "fall"- oder kundenspezifischen Erstanlage des Informationsmodell ist ein schlechter Scherz – oder?

Palantir sagt über seine dynamische Ontologie:

Weil unterschiedliche [Kunden-]Organisationen die Welt in unterschiedlicher Art und Weise wahrnehmen, und weil diese Modelle sich im Zeitverlauf auch verändern, wird die dynamische Ontologie fall-/kundenspezifisch [?] [im Original: "on a per case basis"] festgelegt und kann aktualisiert werden, wenn neue Datenquellen hinzukommen, wenn andere Datenquellen entfernt werden oder einfach dann, wenn es notwendig ist das Informationsmodell zu überarbeiten. (Hervorhebung von POLICE-IT)

Dazu zwei Beispiele:

1) INPOL-Fall

INPOL-Fall ist das zentrale Informationssystem beim Bundeskriminalamt für die Datenbanken des kriminalpolizeilichen Meldedienstes (KPMD) und der Sondermeldedienste. Dort gibt es aus rechtlichen Gründen verschiedene Datenbanken für verschiedene Deliktsbereiche, wie zum Beispiel politisch motivierte Kriminalität, Rockerkriminalität, Falschgelddelikte, Kinderpornographie und vieles mehr. INPOL-Fall ist von seiner Anlage her ideal als einheitliche Plattform für verschiedene, logisch voneinander getrennte Datenbanken. Dennoch ist der Einsatz von INPOL-Fall als das Zentralsystem für den KPMD gescheitert, weil auch im federführenden BKA niemand erkannt hat, wie wichtig ein einheitliches logisches Informationsmodell ist. Mit dem Ergebnis, dass weit über hundert verschiedene Informationsmodelle entstanden sind. Und der Folge, dass die Informationen aus den unterschiedlichen Datenbanken nicht miteinander kompatibel sind und datenbank-übergreifende Auswertungen daher nicht möglich sind. Dies ist DER WESENTLICHE Grund dafür, warum die kriminalpolizeilichen Meldedienste bis heute nicht den Informationsaustausch ermöglichen, den man sich immer davon versprochen hat. Und warum man dies mit dem PIAV, dem Polizeilichen Informations- und Analyseverbund, neu aufsetzen musste.

2) RS-CASE und seine Varianten

Auch das Fallbearbeitungssystem RS-CASE der Firma Rola Security Solutions wurde, jedenfalls anfangs, damit beworben, dass jeder Kunde frei ist in der Definition seines Informationsmodells. Gleichzeitig bestand Einvernehmen unter den politischen Entscheidern, dass die Verwendung des GLEICHEN Fallbearbeitungssystems (also RS-CASE), schon dafür sorgen würde, dass Informationen aus den unterschiedlichen RS-CASE-Systemen relativ einfach miteinander ausgetauscht werden können. Auch diese Annahme hat sich leider erst in der Praxis als falsch herausgestellt. Wenn es nicht so wäre, wenn also alle RS-CASE-Implementierungen im Informationsmodell kompatibel zueinander gewesen wären, hätte nicht die Notwendigkeit bestanden, die Entwicklung des PIAV in Angriff zu nehmen!

Und nur am Rande bemerkt: Auch der PIAV sieht sieben verschiedene (sic!) Ausbaustufen für unterschiedliche Deliktsbereiche vor. Auch das legt die Vermutung nahe, dass dort unterschiedliche Informationsmodelle bzw. deliktsspezifische Varianten des Grundstandards vom Informationsmodell der Polizei (IMP) verwendet werden, obwohl doch der PIAV eigentlich die neue vereinheitlichte Informationsplattform der deutschen Polizei sein soll. Solche Varianten von Informationsmodellen haben jedoch zwangsläufig die Auswirkung, dass allenfalls die Informationen miteinander ausgetauscht werden können, deren jeweiliger Objekttyp, Attributtyp, … in dem allen Modellen gemeinsamen Grundmodell, quasi als kleinster gemeinsamer Nenner, enthalten ist.

Ist das IMP, das standardisierte Informationsmodell der Polizei, in Hessendata integriert?

In den letzten zehn Jahren wurde in der deutschen Polizei, insbesondere beim BKA, viel Arbeit und Zeit dafür investiert, ein für alle deutschen Polizeibehörden gemeinsames, standardisiertes "Informationsmodell Polizei" (IMP) zu definieren und möglichst flächendeckend auch einzuführen. Das IMP ist z.B. das gemeinsame logische Informationsmodell für den PIAV, den polizeilichen Informations- und Analyseverbund und damit wohl auch die Basis für das zukünftige "Datenhaus Polizei" im aktuellen Entwicklungsprojekt der Informationstechnik der Polizei namens "Polizei 2020".

Für Außenstehende ist jedoch nicht ersichtlich, ob und in welchem Umfang die dynamische Ontologie in Hessendata mit dem Informationsmodell Polizei kompatibel ist. Anders ausgedrückt: Stimmt das Informationsmodell in Hessendata mit der aktuellen Version von IMP überein? Oder hat man in Hessendata ein kunden- bzw. fallspezifisches eigenes Informationsmodell kreiert, wie es im Rahmen des Pilotbetriebs oder der späteren Einführung gerade passend erschien? Sollte das der Fall sein, wird sich nur noch eine weitere Informationsinsel unter den polizeilichen Informationssystemen dieses Landes entwickeln.

Fragen zum Eigentum an der Palantir-Technologie

Open Source and Technology Ownership

Palantir betont an mehreren Stellen in seinen Produktbeschreibungen, dass viele der Systemkomponenten auf Open-Source-Entwicklungen beruhen. Das erweckt den Eindruck einer offenen, transparenten Entwicklung: in die auch externe Dritte Einblick haben, weil sie Teil der Open-Source-Community sind. Das wirkt dem möglichen Vorurteil entgegen, dass Palantir eine zu große Nähe zu amerikanischen Geheimdiensten habe.

Aus der Sicht eines Herstellers kann die Verwendung von Open Source generell auch den Vorteil der kürzeren Entwicklungszeit und auch der geringeren Entwicklungskosten bieten. Allerdings steht es dem Hersteller auch jederzeit frei, eine Open-Source-Komponente in sein kommerzielles System einzubauen und dort in INDIVIDUELL MODIFIZIERTER Form weiter zu verwenden. Je nach Nutzungsbedingungen können damit Lizenzzahlungen und andere Auflagen verbunden sein. Das berührt allerdings vor allem die Rechtsbeziehung zwischen dem Hersteller (hier also Palantir) und dem Rechteinhaber und ist von außen schwer feststellbar.

Hinzu kommt, dass ein Gesamtsystem, wie Palantir Gotham, aus einer Vielzahl von Komponenten besteht. Ein Code Review, der ja bekanntlich eine sehr sinnvolle und wirksame Maßnahme sein kann, um Schwachstellen und Hintertüren in einem polizeilichen Informationssystem zu erkennen, wird technisch dadurch nahezu undurchführbar. Ganz abgesehen davon, dass es selbst für den Hersteller schon logistisch und technisch sehr schwierig werden dürfte, den Quellcode für JEDE EINZELNE Komponente für eine solche Sichtung durch externe Fachleute beizubringen.

Palantir hält viele US-Patente

Eine Recherche von POLICE-IT im November 2018 in der Datenbank des amerikanischen Patentamts ergab, dass zu diesem Zeitpunkt 289 erteilte Patente für Palantir eingetragen waren. Das spricht für eine starke Betonung der "technology ownership" und den Wunsch, die eigene Technologie gegenüber dem Mitbewerb rechtlich verteidigen zu können.

ERTEILTE Patente sind für jedermann frei einsehbar. Das gilt auch für US-Patente. Ein Patent gibt dem Patentinhaber den Schutz, seine Erfindung anderen gegen Lizenzgebühren zur Nutzung zu überlassen. Das Patent verleiht jedoch nicht den Schutz, dass andere nicht einsehen und sich ansehen können, was denn im Patent steht. Open Source für die Entwicklung von Softwarekomponenten und zahlreiche Patent sprechen eigentlich dafür, dass viel offengelegt ist. Insofern wundert man sich doch sehr über die Begründung für die freihändige Vergabe des Auftrags an Palantir: Die "Ausschließlichkeitsrechte wie zum Beispiel des Patent- oder Urheberrechts" seien zu schützen gewesen, heißt es da.

Open Source in zahlreichen Komponenten des Gotham Systems einerseits und eine Fülle von Patenten für viele technische Einzelheiten andererseits sprechen dafür, dass Palantir offen ist gegenüber diversen Open-Source Communities. Und sich – zu Recht – auf den Schutz durch Patente verlässt. Das wirft die Frage auf: Wen oder was sollte diese an den Haaren herbeigezogene Begründung für die freihändige Vergabe der hessischen Polizei an Palantir Deutschland eigentlich schützen?

Fazit

Mit dem System Gotham alias Hessendata verfügt die hessische Polizei über die technischen Möglichkeiten, AUTOMATISIERT Informationen aus sozialen Medien und anderen Datenquellen (wie theoretisch denkbar z.B. Datenbanken über das Kaufverhalten, die Kreditwürdigkeit etc.) zusammenzuführen mit Daten aus polizeilichen Informationssystemen. Die Befugnisse hat ihr der hessische Gesetzgeber verliehen – mit dem umfassend geänderten Hessischen Polizeiaufgabengesetz (HSOG), das im August 2018 in Kraft getreten ist. Damit darf die Polizei, zumindest in Hessen, im Rahmen der GEFAHRENABWEHR alle diese Befugnisse nutzen. Ein weitreichend formulierter Paragraf 20 dieses Gesetzes verschafft ihr faktisch auch die Möglichkeit zur Nutzung im Rahmen ihrer Tätigkeit als Ermittlungsgehilfe der Staatsanwaltschaft. Zumal die Einschränkung, über entgegenstehende Bestimmungen der Strafprozessordnung (in §20, Abs. 6 HSOG) insofern ins Leere geht, als dass die Strafprozessordnung hinter der TECHNISCHEN ENTWICKLUNG in Palantir und vergleichbaren Systemen um Lichtjahre hinterherhinkt.

Auf der vor wenigen Tagen zu Ende gegangenen Herbsttagung seiner Behörde hat BKA-Präsident Münch ein neues Prinzip für die Zusammenarbeit zwischen den Polizeibehörden von Bund und Ländern bei der gemeinsamen Weiterentwicklung der polizeilichen IT-Infrastruktur ausgerufen – es heißt "Themenführerschaft":

Wenn einzelne Länder, Länderverbünde oder der Bund auch für alle anderen Entwicklungen vorantreiben, werden wir deutlich schneller ans Ziel kommen. Land A kümmert sich zum Beispiel um ein Einsatzdokumentationssystem, Land B um ein Asservatensystem und Land C um ein System zur Auswertung unstrukturierter Massendaten. (…) Aus der Übernahme des Themas muss sich gleichzeitig die Prokura ergeben, das jeweilige Vorhaben voranzutreiben. Und zwar ohne detaillierte Abstimmungen, dafür in kleinen Schritten, um anhand von praktischen Erfahrungen und Feedback nachzusteuern und die Produkte so stetig zu verbessern. … (Hervorhebung von POLICE-IT).

Vieles spricht dafür, dass das extrem weit gefasste, neue hessische Polizeiaufgabengesetz in Verbindung mit der klandestinen Beschaffung des Palantir-Systems für den BETRIEB einer Analyseplattform für die hessische Polizei das Pilotprojekt für die Themenführerschaft beim "Connecting the Dots with Big Data" in der deutschen Polizei werden wird.

Diesen Artikel finden Sie im Original auf POLICE-IT.

RT Deutsch bemüht sich um ein breites Meinungsspektrum. Gastbeiträge und Meinungsartikel müssen nicht die Sichtweise der Redaktion widerspiegeln.

Fortsetzung: Teil VII – Palantir-Untersuchungsausschuss: Von echter Aufklärung keine Spur

Mehr zum Thema - Blick in die Zukunft: Deutschlands paramilitärische Polizei