Wenn Daten töten: Fall Amad A. (3): LKA und LZPD geben Rätsel auf

Am Montag Morgen, dem 09.07.2018 lag die Mitteilung über die Inhaftierung von Amad A. beim LKA vor und wurde dort in ViVA übernommen. Dass der eindeutig identifizierte Amad A. in Haft saß auf der Grundlage von Haftbefehlen für einen Amedy G. wurde auch dort nicht bemerkt. Wo Daten nicht „passten“, wurden sie passend gemacht. Und endlich wurde auch die ED-Behandlung vom 04.07.2018 in ViVA abgeschlossen. Bei all dem kam es zu einer Reihe von bis heute ungelösten Rätseln …
Lesedauer: Ca. 20 Minuten

Teil 3 der Serie ‚Wenn Daten töten – Der Fall des Syrers Amad A.‘

Wenn Daten töten: Fall Amad A.: Die bisher erschienenen Artikel

Mittwoch, 04.07.2018: Die fatalen Folgen einer Schwarzfahrt
Freitag, 06.07.2018: Festnahme mit Haftbefehl eines anderen
Montag, 09.07.2018: Technische Dienstleister werden zu weiteren Beteiligten am Schicksal vom Amad A.

Technische Dienstleister werden zu weiteren Beteiligten am Schicksal von Amad A.

Am 04.07. und am Freitag, dem 06.07.2018, bei der Inhaftierung von Amad A., hatten Polizeivollzugsbeamte aus operativen Polizeibehörden das weitere Schicksal von Amad A. eingeleitet. Ab Montag, dem 09.07.2018, bei der Verbuchung seiner Inhaftierung und im weiteren Verlauf seiner Haft wurden auch technische Dienstleister zu direkten Beteiligten am weiteren Schicksal von Amad A. und später dann zu Erfüllungsgehilfen bei den Ermittlungen nach seinem Tod. Interessenkonflikte, die sich dabei ergeben haben dürften, wurden bis heute nicht untersucht.

Sachgebiet 33.2 im Landeskriminalamt NRW als technischer Dienstleister

Das Sachgebiet 33.2 im Landeskriminalamt NRW war zu fraglichen Zeit die ‚Koordinierungsstelle ViVA/INPOL‘, sowie verantwortlich für die Qualitätssicherung ViVA 2.0/Basis-Web.

Basis-Web, das ‚Das Buchhaltungs- und Abrechnungssystem im Strafvollzug (BASIS)‘ kommt zum Einsatz, um Aufenthalte in den Haftanstalten des Landes Nordrhein-Westfalen zu verbuchen und abzurechnen. Veränderungen im „Bestand“ (der Häftlinge / Haftanstalten) müssen zeitnah gegenüber den Polizeibehörden mitgeteilt werden. Solche Mitteilungen der Strafvollzugsbehörden werden über eine Schnittstelle zwischen Basis-Web bei ViVA angeliefert.

Die vielfachen Rollen des Landesamts für Zentrale Polizeiliche Dienste (LZPD) als technischer Dienstleister

Das LZPD ist der wichtigste technische Dienstleister im Geschäftsbereich des Innenministeriums für die Polizei NRW. Das LZPD betreibt auch die Datenbanken für die Polizei und ist verantwortlich für die Planung und Entwicklung polizeilicher Informationssysteme und Anwendungen.

Mitentwickler von ViVA – Verfahren zur integrierten Vorgangsbearbeitung und Auskunft

Das LZPD, dort insbesondere die Sachgebiete 12.2 und 13.2 – sind Entwickler und Projektverantwortliche für ViVA – das Verfahren zur integrierten Vorgangsbearbeitung und Auskunft.
Dieses System wurde in den neunziger Jahren des vergangenen Jahrhunderts unter dem Namen POLIKS für die Polizei Berlin entwickelt. Anbieter von ViVA in NRW ist die Deutsche Telekom Healthcare Solutions GmbH (DTHS), die das System (auf der Basis von POLIKS) in Zusammenarbeit mit dem LZPD für die Zwecke der Polizei NRW angepasst hat und gemeinsam mit dem LZPD weiterentwickelt.

Einführung von ViVA in Nordrhein-Westfalen

Die Einführung von ViVA in der Polizei des Landes NRW begann Anfang des Jahres 2017. Das System sollte schrittweise zwei langjährig in NRW genutzte Systeme unter einer einheitlichen Oberfläche vereinen: Nämlich die integrierte Vorgangsbearbeitung (= IGVP) und das INPOL-Land-System POLAS, welches als INPOL-Teilnehmersystem beim BKA, bei der Bundespolizei und in der Mehrzahl aller anderen Bundesländer im Einsatz war und noch ist.

Am 11.12.2019 erhielt DTHS den Zuschlag für die Fortführung der laufenden Pflege, Wartung und Weiterentwicklung von ViVA für einen Zeitraum von weiteren sechs Jahren ab 2020. Der Vertrag hat ein Volumen von 27.706.890 Euro (exkl. MWSt) [1].

ViVA ist eigentlich eine ganze Familie von Anwendungen und Datenbanken. Neben der Komponente für INPOL-Land gehören dazu die ViVA-Vorgangsbearbeitung, aber auch flankierende Systeme, wie z.B. Digi-ED oder eben Basis-Web.

Informationen in ViVA

In ViVA werden von allen Polizeibehörden des Landes NRW sämtliche polizeilich relevanten Vorgänge erfasst. In ViVA werden darüber hinaus alle Informationen erfasst und gespeichert, die für das Verbundsystem INPOL relevant sind, sofern sie das Land NRW betreffen. INPOL-relevant sind Informationen über Personen, insbesondere Personen, die strafrechtlich in Erscheinung getreten sind bzw. zur Fahndung ausgeschrieben sind, sowie Informationen über Sachen (insbesondere zur Fahndung ausgeschriebene, z.B. Fahrzeuge) und Informationen über Fälle.

Das LZPD als Auswerter der Protokolldatenbanken von ViVA

Alle Daten zur Identifizierung und Beschreibung einer Person und ihrer polizeilich relevanten Historie werden in einem so genannten ViVA-Personen(daten)satz zusammengefasst.
Sämtliche Aktivitäten, die Benutzer am ViVA-Datensatz einer Person ausüben werden automatisch in der „ViVA Protokolldatenbank Änderungsverfolgung“ mitprotokolliert. Der ausführende Benutzer kann diese Protokollierung nicht an- oder abschalten, sie erfolgt automatisch im Hintergrund.

Einträge im Veränderungsprotokoll eines Personen-Datensatzes

Protokolliert wird jede einzelne Aktion eines Benutzers an diesem Datensatz: Dazu gehören das Hinzufügen von Attributen (z.B. Namen, Geburtsdaten, etc.) oder Objekten (z.B. Datengruppe für einen weiteren Aliasnamen) bzw. das Verändern und das Löschen solcher Daten.
Für jeden einzelnen Bearbeitungsschritt wird ein Eintrag („eine Zeile“) geschrieben: Der enthält

• einen Zeitstempel (Datum und sekundengenaue Uhrzeit),
• Angaben zum Benutzer (Client-Info, Login-Name, Benutzer-Name Dienststelle),
• Die Id des Datensatzes, der bearbeitet wurde,
• Die Art der einzelnen Aktion (z.B. Attribut hinzugefügt | geändert | gelöscht), und
• Die Art des bearbeiteten Objekts (z.B. Alias-Datengruppe) oder Attributs (z.B. Familienname) und
• Der eigentliche Wert dieses Attributs (z.B. Amed als Familienname)

Vorkehrungen gegen spätere Manipulationen

Eine Abfolge von zusammen gehörenden einzelnen Bearbeitungsschritten – z.B. das Anlegen einer neuen Alias-Datengruppe und das Befüllen mit den Namen und Daten dazu – wird in einer Bearbeitungssequenz zusammengefasst. Jede Bearbeitungssequenz beginnt mit einer so genannten fsAktualisierungsnummer. Diese werden automatisch fortlaufend hochgezählt. Anhand der aufsteigenden Folge dieser fsAktualisierungsnummern kann man also die Folge von Bearbeitungssequenzen an einem bestimmten ViVA-Datensatz mitverfolgen. Genauso wie die einzelnen Bearbeitungsschritte innerhalb einer fsAktualisierungsnummer sollte diese Abfolge der fsAktualisierungsnummern lückenlos sein, also keine Nummern auslassen.
Mit einer solchen Vorkehrung in Protokolldatenbanken sollten spätere Löschungen erkennbar gemacht werden.

Das LZPD als verantwortlicher Auswerter der ViVA-Protokolldatenbank Änderungsverfolgung

Ein ’normaler‘ Benutzer hat keinen Zugriff auf diese Protokolldatenbank. Sie steht nur berechtigten Mitarbeitern des LZPD zur Verfügung. Das sind insbesondere Mitarbeiter des Sachgebiet 12.2 im LZPD, welches zuständig ist für IT-Anwendungen zur Vorgangsbearbeitung, also insbesondere für ViVA und eben für die Auswertung der ViVA-Protokolldatenbanken.

Montag, 09.07.2018: Zuordnungs- und andere Fehler / Der Tag der vielen Rätsel

1. Die fehlerhafte Verbuchung der Inhaftierung des Amad A. im LKA-Sachgebiet 33.2

Eine Regierungsangestellte aus dem LKA-Sachgebiet 33.2 hatte am Morgen des 09.07.2018 die Aufgabe, die Meldungen aus Basis-Web über Veränderungen bei den Inhaftierungen seit dem vergangenen Freitag in ViVA zu übernehmen und so quasi dort zu verbuchen.

Vollautomatische bzw. manuelle Zuordnung von Haftnotierungen zu Personen-Datensätzen

Wenn die Personalien aus BASIS eindeutig einer Person in ViVA zugeordnet werden können, erfolgt die Zuordnung vollautomatisch. Das bedeutet, dass die entsprechende Daten über die Inhaftierung oder Verlegung oder Entlassung in der Haft-Datengruppe dieses Personen-Datensatzes eingetragen werden.

Wenn die Zuordnung nicht automatisch erfolgen kann, wird der fragliche Datensatz in eine Liste aufgenommen; die Einträge darin müssen dann von einem angestellten Mitarbeiter bzw. einer Mitarbeiterin des Sachgebiets 33.2 intellektuell überprüft und manuell einem Personen-Datensatz in ViVA zugeordnet werden.

Unvollständige Daten über den Amad A. aus Basis-Web

Genau das traf zu für die Haftnotierung des Amad A., der am 06.07. spätabends in die JVA Geldern eingeliefert worden war. Eine vollautomatische Zuordnung seiner Verhaftung zu seinem in ViVA existierenden Datensatz war gescheitert, weil er in Basis-Web nur mit wenigen Daten erfasst worden war. Die Regierungsangestellte hatte also zu prüfen ob der Inhaftierte AMED Amed, *01.01.1992 in TOMBOUCTOU, unbekannte Staatsangehörigkeit identisch sei mit dem in ViVA gespeicherten AMED Amed, *01.01.1992 in Aleppo, syrischer Staatsangehöriger.

Aktuell angezeigt wird der zusammengeführte Datensatz!

ViVA zeigt für einen Personen-Datensatz im linken Teil des Bildschirms einen Strukturbaum an: Er besteht aus aufklappbaren Sektionen für die

• Personalien,
• Personenbeschreibungen,
• ED-Behandlungen,
• Fahndungen,
• Haftnotierungen,
• Zusätzlichen Personendaten
• und ggf. noch andere

Diese Baumstrukur und ihre Handhabung ist ja aus vielen anderen Web- bzw. Windows-Anwendungen weltweit bestens bekannt.

Aufgrund der ungeklärten, unrechtmäßigen und fehlerhaften Datensatzzusammenführung vom Mittwoch der Vorwoche war der Baum für den Personen-Datensatz des Amad A. prall gefüllt:

Unter der Sektion „Personalien“ standen

• die Führungs- und vier Andere Personalien, die den Amad A. Betrafen
• darunter die Führungs- und elf Andere Personalien, die den Amedy G. betrafen

Unter der Sektion „Personenbeschreibung“ und „ED-Behandlung“ waren sowohl die des Amad A. aufgelistet, als auch die des Amedy G. usw. Aufgrund der Baumstruktur, ist es unmöglich, solche vorhandenen Daten im Baum NICHT zu erkennen …

Eine Datenlage, die Fragen aufwerfen musste …

Aus dieser Datenlage konnten, ja mussten Fragen entstehen: Die Regierungsangestellte rief also in INPOL die Datensätze von Amad A. und von Amedy G. auf. In INPOL waren die zwölf Personalien und vier Fahndungsnotierungen im Datensatz von Amad A. jedoch NICHT zu sehen. Denn dort hatte ja nie eine Datensatzzusammenführung stattgefunden! Vielmehr standen die Personalien (und anderen Daten) des Amedy G. dort, wo sie hingehörten, nämlich im INPOL-Datensatz von Amedy G. Also ergab sich aus der Datenlage in INPOL (nicht zusammengeführt) und in ViVA (zusammengeführt) ein deutlicher Widerspruch. Der zusätzliche Fragen aufwerfen musste, warum der Amad A. auf der Grundlage von Haftbefehlen für den Amedy G. in Geldern in der JVA einsitzt.

Eine Angestellte verfällt ins Grübeln … und findet eine überraschende Lösung

Danach verfiel die Angestellte anscheinend für eine Viertelstunde ins Grübeln. Um 9:06 Uhr dann verzeichnet der vorliegende Protokollauszug ihre nächsten Aktivitäten: Sie löschte den zuvor aus Basis-Web übernommenen Haftbefehl („2107“) für den Amedy G. für eine Ersatzfreiheitsstrafe und ersetzte ihn durch den Haftbefehl („3104“) für den Rest einer neunmonatigen Gesamtfreiheitsstrafe. Dazu ergänzte sie noch, dass diese Freiheitsstrafe (unter Anrechnung der bereits von Amedy G. abgesessenen Untersuchungshaft) beendet sein würde am 18.10.2018. Sie ignorierte also alle Widersprüche, die deutlich zu erkennen waren und zementierte mit ihrer Eingabe auch im Datensystem die unrechtmäßige Inhaftierung von Amad A.

Rätsel, die die Angestellte aus dem LKA SG 33.2 aufgibt

Im Rahmen der polizeiinternen Ermittlungen nach dem Tod von Amad A. wird am 1.11.2018 ein Vorgesetzter von ihr, in der Hierarchie einige Ebenen über ihr, im internen Schriftverkehr sagen:
„Die eigentliche Frage … können wir nicht beantworten. Wir können nicht darlegen, warum die Haftgruppe unter AMED und nicht unter Amedy G. angelegt wurde.“

Dem ist zuzustimmen: Mehr als zwei Jahre später stellt sich jedoch die Frage: Wurde dieses Rätsel inzwischen ausermittelt und gelöst?

2. Das ViVA-Dienstkonto des LZPD legt einen neuen Datensatz für den Amedy G. an

Als Folge der „Verbuchung“ durch die LKA-Angestellte lag um 09:06 Uhr ein ViVA-Datensatz für den Amad A. vor, der noch weiter als vorher von der Wirklichkeit entfernt war.

Er enthielt nicht nur die Personalien, Personenbeschreibung und Daten der ED-Behandlung aus 2016, die den Amad A. tatsächlich betrafen (die ED-Behandlung vom 04.07.2018 war noch nicht dauerhaft gespeichert …). Sondern darüber hinaus noch zwölf Personalien des Amedy G., vier Fahndungsnotierungen für diesen und nun auch noch eine verbuchten Haftnotierung des Amedy G, für den man allerdings den AMED Amed in der JVA Geldern aufgenommen hatte. Ein größeres Durcheinander geht wohl kaum noch! … Sollte man meinen.

Doch unmittelbar danach trat das ViVA-Dienstkonto aus dem LZPD in Aktion:

Die INPOL-ViVA-Verbundverfahrenskontrolle

Das Sachgebiet 12.2 im LZPD teilte sich zur fraglichen Zeit mit dem LKA, Sachgebiet 33.2 die Aufgabe der sogenannten INPOL-ViVA-Verbundverfahrenskontrolle. Sie ist verantwortlich für die Koordinierung von Daten und Nachrichten zwischen dem INPOL-Landessystem, also ViVA, und dem INPOL-Zentralsystem beim BKA, also INPOL-Z.

Die erste direkte Involvierung des LZPD (09.07.2018)

Um 09:08 Uhr, zwei Minuten nach dem letzten Eintrag der Mitarbeiterin aus dem Sachgebiet 33.2 des LKA ist im Protokollauszug eine Aktivität verzeichnet, die auf das LZPD zurückgeht: Es wurde da unter der Kennung des ViVA-Dienstkontos des LZPD für den Amedy G. ein neuer Datensatz in ViVA angelegt. Das überrascht: Denkt man doch, dass für den Amedy G. doch ebenfalls in ViVA ein Datensatz vorhanden sein müsste.

Der alte Datensatz soll aufgrund der Datensatzzusammenführung gelöscht worden sein

Doch der alte ViVA-Datensatz von Amedy G. soll am 04.07.2018 in ViVA im Zuge der Zusammenführung der Datensätze von Amad A. und Amedy G. gelöscht worden sein. So legte es jedenfalls der leitende Mitarbeiter aus diesem Sachgebiet, seines Zeichens auch der „Auswerter der ViVA-Protokolldatenbanken“ und auch der federführende Autor in seinem ‚LZPD-Analysebericht‘ vom 25.04.2019 dar.

Und wieder schlug der Abgleichsprozess in ViVA zu

Um 09:08 Uhr, das erkennt man am Namen dieses Datensatzes, wird von diesem ViVA-Dienstkonto im LZPD – angeblich automatisch – in ViVA der neue Datensatz für den Amedy G. angelegt. Wenn das zutrifft, müssten die Daten dafür aus INPOL-Zentral geholt worden sein. Denn zwei Minuten zuvor war – laut Abfrageprotokoll – dort eine Abfrage nach dem Amedy G. durchgeführt worden. Üblich ist in solchen Fällen, dass der komplette Personen-Datensatz aus INPOL-Z dann in ViVA übernommen wird.

Auslöser dafür müsste dann der Datensatz des Amad A. gewesen sein, der zu diesem Zeitpunkt die Personalien (und andere Datengruppen) von Amad A. und von Amedy G. aufwies. Dieser, ja generell sehr aktive Prozess, müsste also festgestellt haben, dass im Datensatz des Amad A. auch Datengruppen des Amedy G. enthalten sind. Müsste durch eine Recherche in INPOL (die ja stattfand), ferner festgestellt haben, dass es zum Amedy G. einen Datensatz in INPOL gab. Konnte durch weitere Vergleiche feststellen, dass dieser INPOL-Datensatz z.B. in den Personalien übereinstimmte mit den Personalien im zusammengemischten Datensatz von Amad A. Entschied daraufhin (automatisch!), dass die beiden Personen NICHT identisch sind. Und legte einen neuen ViVA-Datensatz für den Amedy G. an, eine exakte Kopie von dessen Datensatz aus INPOL.

Dieser Ablauf wäre, wenn es so gelaufen sein sollte, ein Kuriosum, sachlich/fachlich nicht plausibel zu erklären: Da werden am 04.07.2018 (die Umstände sind nach wie vor ungeklärt; Beweise fehlen) in den ViVA-Datensatz des Amad A. eine oder mehrere Personalien und andere Datengruppen des Amedy G. hineingemischt. ViVA verarbeitet diese, obwohl leicht festzustellen gewesen wäre, dass sich die beiden Datensätze auf unterschiedliche Personen beziehen mit unterschiedlichen D-Nummern, also Fingerabdrucksätzen. Und löscht anschließend den ‚untergehenden‘ Datensatz von Amedy G.

Fünf Tage später revidiert ViVA diesen Vorgang: Nachdem es durch die LKA-Angestellte erneut mit dem Datensatz des Amad A. zu tun bekommt. Stellt fest, dass darin die Personalien von zwei unterschiedlichen Personen enthalten sind. Und legt zwei Minuten nach der Aktivität der Angestellten (angeblich automatisch!) wieder einen Datensatz für den Amedy G. an, also exakt den Datensatz, der am 04.07.2018 gelöscht worden sein soll.

Könnte es sein, dass das LZPD im Fall Amad A. einen Interessenkonflikt hat?

Ein solches, schwer zu erklärendes Verhalten eines IT-Systems könnte für viele Produktverantwortliche zu gestörtem Nachtschlaf führen. Ob das bei den Verantwortlichen im LZPD so war, wissen wir nicht. Diese „Merkwürdigkeiten“ des IT-Systems ViVA müssen jedoch im Gesamtzusammenhang damit betrachtet werden, dass mit ViVA befasste Mitarbeiter des LZPD zu wesentlichen Erfüllungsgehilfen bei der Ermittlung und Aufklärung dieses Falles gemacht wurde? Denn wer gibt schon gerne zu, dass das eigene System unerklärliche Aktivitäten ausführt?!

• Da soll ViVA EINEN „Kreuztreffer“ ausgewiesen haben, gebildet aus zwei Namensfragmenten (Amed / 01.01.1992) und damit eine Angestellte zu einer Datensatzzusammenführung veranlasst haben. Nach dieser Logik müssten die Personalien von Amad A. bei den weit mehr als hundert Abfragen, die allein am Vormittag des 04.07.2018 nach ihm getätigt wurden, noch VIEL MEHR Kreuztreffer produziert haben. Davon war jedoch bisher nie die Rede. Warum nicht?!
• Da führt dieses System zwei Datensätze von Personen zusammen, aus denen selbst eine Software ohne „KI (= künstliche Intelligenz) durch einen einfachen Vergleich der D-Nummern erkennen MUSSTE, dass sie zu NICHT IDENTISCHEN Personen gehören.
• Nach der Zusammenführung wird dann der „untergehende“ Datensatz (des Amedy G.) gelöscht.
• Beim nächsten Bearbeiten des nun zusammengemischten Satzes stellt ViVA dann fest, dass die Personen doch nicht identisch sind
• und legt den Datensatz (von Amedy G.) – vollautomatisch?! – wieder an.

Ist es nicht zu blauäugig, solche Merkwürdigkeiten im Systemverhalten NICHT zu berücksichtigen? Gerade wenn man man die Verantwortlichen für dieses IT-System und Auswerter sämtlicher Aktivitätsprotokolle aus diesem System zu den alleinigen Experten der späteren technischen Ermittlungen macht?! Diese Konstellation lässt an sich schon aufgrund des mit Händen zu greifenden Interessenkonflikts an der Objektivität der Ermittlungsergebnisse zweifeln!

Zumal die – sehr spät übrigens, nämlich erst im April 2019 – präsentierten Erklärungen des LZPD über Kreuztreffer und Datensatzzusammenführung und die Weiterungen daraus einen erheblichen Nachteil haben: Belastbare Sach- oder Personenbeweise für die Kernaussagen liegen nicht vor. An zu vielen Stellen zeigen die vom LZPD vorgelegten Protokollauszüge gerade NICHT, was bewiesen werden müsste. Und offensichtlich wurde der Fehler mit der Datensatzzusammenführung im LZPD – intern – ja auch schon im August 2018 erkannt. Man beließ es allerdings dabei, dass LZPD-MitarbeiterInnen vier Fahndungsnotierungen und zwölf Personalien-Datengruppen aus dem (vermischten) Datensatz von Amad A. herauslöschten. Und damit den Fehler in der Datenwelt korrigierten. Der Fehler in der Wirklichkeit – die Inhaftierung von Amad A. – wurde jedoch nicht korrigiert. Mit letztlich fatalen Folgen für den jungen Syrer.

Doch damit noch nicht genug:

3. Im neuen Datensatz von Amedy G. wird – verfälschend – eine Aliaspersonalie von Amad A. eingetragen

Ein sehr schlecht aber immerhin noch lesbarer Bildschirmauszug in den Unterlagen zeigt die neunte von insgesamt elf A-Datengruppe aus diesem neu angelegten ViVA-Datensatz von Amedy G. Anhand ihrer Referenznummer ist zu ersehen, dass diese Datengruppe ursprünglich im Jahr 2016 in INPOL angelegt worden war. Die Übernahme in ViVA entstand am Vormittag des 09.07.2018 um 09:06 Uhr, als der INPOL-Datensatz für den Amedy G. als neuer ViVA-Datensatz kopiert wurde.

Aus INPOL, sowie aus Aussagen des Landeskriminalamts Hamburg – es ist „Besitzer“ des entsprechenden Datensatzes – ist bekannt, was VORHER in dieser Alias-Personalie stand. Und aus dem gerade erwähnten Bildschirmauszug ist zu erkennen, was dort NACH 09.06 Uhr und BIS 11:48 Uhr (dem Zeitpunkt der letzten dokumentierten Änderung) eingetragen wurde:

Wer nahm diese Verfälschungen vor – und warum?

Der Geburtsort war ersichtlich ein „Fake“, der aus einer Fahndungsnotierung des Amedy G. stammte („AGO: TOMBOUCTOU“). Als ‚Ergänzung zur Personalie‘ war noch angegeben worden: „LT POL KLEVE 5150000-02578-18/2“. Ein klarer Hinweis darauf, dass die Daten manuell erfasst worden sein mussten, und nicht das Ergebnis eines Datenabgleichs (mit welchen Daten auch) gewesen sein können. Doch wer war der Urheber für diese Verfälschung? Und welches Motiv steckte dahinter??

Wieder einmal fehlt ein Protokoll

Auch im Fall dieses ViVA-Datensatzes hatte das LKA (als Beauftragter für solche Ermittlungen) beim LZPD ein vollständiges Protokoll aller Veränderungen bis zum 07.08.2018 angefordert. Auch für diesen Datensatz hat der Auswerter – und Autor des LZPD-Analyseberichts – keinen vollständigen Protokollauszug vorgelegt. Sondern lediglich einen kleinen Schnipsel, der die oben dokumentierte Änderung der A-Datengruppe in ViVA am 09.07.2018 um 11.48 Uhr zeigt.

Die kann aber auf unterschiedlichen Wegen entstanden sein: Aufgrund des fehlenden vollständigen Protokolls ist nicht festzustellen, wann wer diesen Eintrag tatsächlich vorgenommen hat. Denn der ausgewiesene Protokollschnipsel kann auch bedeuten, dass die Veränderung zuerst in INPOL durch das LKA Hamburg als dem Besitzer dieser A-Datengruppe vorgenommen worden war. Und dann aufgrund des automatischen Austauschs zwischen INPOL-Systemen an NRW, also ViVA gemeldet und dort in ViVA entsprechend registriert wurde. Was jedoch die Frage aufwirft: Woher soll das LKA Hamburg ohne Zutun aus NRW gewusst haben, auf welche Vorgangsnummer (5150000-02578-18/2) in NRW sich diese Änderung bezieht?

Selbst wenn es so gewesen sein sollte, bleibt allerdings die Kardinalfrage unbeantwortet: Aufgrund welcher polizeifachlichen Erkenntnisse durfte in ViVA bzw. INPOL registriert werden, dass der Amedy G. den Aliasnamen Amad A. geführt hat????? Auch dafür gibt es wieder einmal keinen Nachweis aus der Wirklichkeit.

Ergebnis dieser Verfälschung

Bei diesem Eintrag handelt es sich um die Verfälschung von Daten. Denn zuvor stand in dieser klar identifizierten A-Datengruppe die oben in der linken Spalte angegebene Personalie (SIDIBE …). Die dann durch die Personalie in der rechten Spalte (AMED ..) manuell überschrieben wurde. Mit dieser Verfälschung, die zeitgleich auch in INPOL erfolgte, wurde erreicht, dass im INPOL- und im ViVA-Datensatz von Amedy G. die Personalie von Amad A. aufscheint. Was es auch in INPOL so aussehen ließ, als sei der Amad A. personenidentisch mit dem Amedy G. ist tatsächlich noch mit „Fahrlässigkeit“ zu entschuldigen, dass solche fatalen Änderungen am Datensatz vorgenommen worden sind?

Eklatanter Verstoß gegen die Regeln von INPOL

Die Art und Weise dieser Verfälschung – Überschreiben einer vorhandenen Personalie mit anderen Daten – ist ein eklatanter Verstoß gegen die Regeln von INPOL, die für alle INPOL-Verbundteilnehmer gelten. INPOL schreibt verbindlich vor, dass in einem solchen Fall eine neue A-Datengruppe für die neue Personalie angelegt wird und ergänzt wird im Personen-Datensatz der Person, der diese neue A-Datengruppe zugeordnet werden soll. ViVA ist das INPOL-Land-System für die Polizei Nordrhein-Westfalens. Warum lässt ViVA zu, dass durch Überschreiben vorhandener Daten so massiv gegen fundamentale INPOL-Regeln verstoßen werden kann?

4. Endlich wird auch die ED-Behandlung im Polizeipräsidium Krefeld vom 04.07.2018 in ViVA abgeschlossen

Am Mittwoch, dem 4.7.2018 war Amad A. zum wiederholten Male einer erkennungsdienstlichen Behandlung unterzogen worden. Die dabei entstandenen Lichtbilder und der Fingerabdrucksatz waren unter dem Datum des 04.07.2018 gespeichert worden. Das ist systemtechnisch nur möglich, wenn zuvor auch der passende Personendatensatz aufgerufen wurde und einige „Verwaltungsdaten“ über die ED-Behandlung im ViVA-System erfasst werden: Also wann, wer, aufgrund welcher Rechtsgrundlage die ED-Behandlung durchgeführt hat usw.

Zu den Pflichtangaben in allen INPOL-Teilnehmersystemen, und somit auch in VIVA zählt auch, dass dabei die Personalien der Person gesondert erfasst, die da ED-behandelt wird.

Ein technisch und sachlich plausible Möglichkeit für die Entstehung der Datensatzzusammenführung

Es besteht die MÖGLICHKEIT, dass bei dieser ED-Behandlung anstelle des Namens von Amad A. der Name von Amedy G. eingetragen wurde als Person, die ED-behandelt wurde. Diese Möglichkeit besteht systemtechnisch, weil die Felder für die „Person bei ED-Behandlung“ Pflichtfelder sind und dort etwas ausgefüllt werden muss.
Diese Möglichkeit besteht auch sachlich, denn das LKA hat im Rahmen seiner späteren Ermittlungen festgestellt, dass der ED-Sachbearbeiter „angenommen“ habe, dass der Amad A. und der Amedy G. ein- und dieselbe Person seien. Es wäre also vollkommen plausibel gewesen, wenn der ED-Sachbearbeiter den Namen Amedy G. als Namen für die ED-behandelte Person in den Pflichtfeldern eingetragen hätte, wenn er schon die Identität von Amad A. und Amedy G. annimmt. Daraus wiederum hätte bei dem abgleichs-freudigen System ViVA eine automatische Zusammenführung der ViVA-Datensätze von Amad A. und Amedy G. resultieren KÖNNEN.

Die fehlende Überraschung über eine nunmehr zu einem Datensatz verschmolzene Person

Am Datensatz des Amad A., den der ED-Sachbearbeiter da am 9.7. ergänzte, hingen inzwischen zwölf Personalien des Amedy G. Das wusste der ED-Sachbearbeiter auch, denn er erzeugte einen Ausdruck „ED-Ergebnismitteilung“, in dem die Personalien von Amad A. und die zwölf weiteren Personalien von Amedy G. deutlich sichtbar aufgelistet waren. Das scheint den Sachbearbeiter allerdings nicht im Mindesten überrascht zu haben. Lag das daran, dass dieser Ausdruck genau seiner Annahme entsprach? Wenn ja: Woher stammte diese „Annahme“ und wodurch war sie begründet?

Gut zu erkennen war an diesem Datensatz auch, dass der Amad A. seit dem 06.07. verhaftet war und in der JVA Geldern einsaß. Auch das ließ den ED-Sachbearbeiter anscheinend völlig unbeeindruckt. Lag das vielleicht daran, dass ihm das alles längst nicht mehr „neu“ war?!

Rätsel, die der ED-Sachbearbeiter aufgibt …

Auch die sonstigen Aktivitäten dieses ED-Sachbearbeiters am 09.07.2018 geben Anlass für weitere Fragen:

1. Warum hat er eine ED-Behandlung vom 04.07.2018 nicht schon an diesem Tag abgeschlossen, sondern damit fünf Tage gewartet?
2. Warum hat der ED -Sachbearbeiter den hellhäutigen, westasiatischen Syrer in der Personenbeschreibung als nordafrikanisch dargestellt?
3. Warum hat er ausdrücklich vermerkt, dass ein Personen-Feststellungsverfahren (PFV) nicht erforderlich sei? Denn er war doch gerade derjenige, der die Annahme verfolgte, dass der Amad A. identisch sei mit einem ganz anderen Menschen namens Amedy G. Also hätte er doch daran interessiert sein müssen, dass diese seine Annahme beim BKA auch durch einen Vergleich der von ihm erneut vom Amad A. genommenen Fingerabdrücke geklärt wird.
4. Wie kam das LKA zu der Ansicht, dass der ED-Sachbearbeiter die Personenidentität von Amad A. und AmedyG „angenommen“ habe?
5. Wurde dieser Ermittlungsansatz weiter verfolgt? Wenn nein: Warum nicht?

5. Übertragung des Amad A.-Datensatzes mit der ED-Behandlung an das BKA

Kurz nach halb zehn Uhr am Morgen des 09.07.2018 hatte der ED-Sachbearbeiter diese ED-Behandlung in ViVA „abgeschlossen“: beendet. Das ViVA-Dienstkonto schaltete sich wieder ein und sperrte diesen Datensatz für weitere Veränderungen. Daraufhin wurde er in einem automatischen Prozess an das BKA übertragen. Dort erfolgt an sich nach jeder ED-Behandlung der Abgleich der (pflichtmäßig bei jeder ED-Behandlung genommenen) Fingerabdrücke mit den dort gespeicherten. Und der Abgleich schon vorhandener Personenbeschreibungen mit den jetzt neu angelieferten.

Aus dem Ausdruck der ED-Ergebniseinstellung vom 09.07.2018, die der ED-Sachbearbeiter erstellt hatte, ergibt sich ja, dass im Datensatz des Amad A. zu diesem Zeitpunkt zwölf Personalien von Amedy G. standen. Eine Übertragung eines solchen Zombie-Datensatzes, der ersichtlich aus Daten von zwei eindeutig identifizierten, unterschiedlichen Menschen besteht, muss eine Reaktion an die INPOL-Verbundverfahrenskontrolle in NRW ausgelöst haben. Entweder im LKA-Sachgebiet 33.2 oder im entsprechenden Sachgebiet beim LZPD muss diese Reaktion angekommen sein, denn die beiden teilten sich die Aufgaben der INPOL-Verbundverfahrenskontrollen.

Weitere Rätsel, die LKA bzw. LZPD beantworten können müssten …

• Wie sah diese Reaktion des BKA aus?
• Warum ist davon NICHTS in den Unterlagen zu finden?
• Wenn es diese Reaktion tatsächlich nicht gegeben haben sollte: Wie sah der Datensatz aus, der an das BKA übertragen wurde?
• Wer hat vor der Übertragung dafür gesorgt, dass die dort nicht hinein gehörenden Datengruppen von Amedy G. aus dem an das BKA gerichteten Datensatz entfernt werden?

Fragen über Fragen also, die im Fall Amad A. nach wie vor nicht beantwortet sind.

Wird es dem Untersuchungsausschuss im Landtag gelingen sie zu klären? Gibt es dort – im Vorwahlkampf – überhaupt noch ein Interesse daran, solche Fragen zu lösen? Oder hat sich die Annahme schon weiter verbreitet, dass der Fall Amad A. einmalig sei, unglücklich gelaufen und sich sicher nicht wiederholen würde?!
Das wäre angesichts der vielen ungeklärten Fragen an Vollzugsbeamte im operativen Dienst, aber auch an technische Dienstleister und deren IT-Systeme, eine eklatante Fehleinschätzung.

Beiträge zu verwandten Themen

[A]   Wie Manipulationen in INPOL den Syrer A.A. hinter Gitter brachten …, 04.04.2019
https://police-it.net/wie-manipulationen-in-inpol-den-syrer-a-a-hinter-gitter-brachten
MONITOR berichtete am 04.04.2019 über einen Vorgang in der Polizei Nordrhein-Westfalen und Hamburg, den man bisher so nicht für möglich gehalten hätte …

[B]   Wenn der Minister berichtet …, 11.04.2019
https://police-it.net/wenn-der-minister-berichtet

Innenminister Reul stellte sich am 10.04.2019 im Düsseldorfer Landtag einer Fragestunde zum Fall der Verfälschung von Namensangaben in INPOL, die den Syrer Amad A. dauerhaft hinter Gitter brachte. Dabei waren ihm zwei Dinge wichtig: Eine Datenmanipulation habe durchaus stattgefunden, aber eben nicht in NRW. Auch Fehler bei der Identitätsüberprüfung habe es gegeben. Aber gegen die beiden daran beteiligten Polizeibeamten habe er Disziplinarverfahren eingeleitet und ermittle die Staatsanwaltschaft. Das allein genügt allerdings nicht, um Polizei und Politik in NRW von ihrer Verantwortung zu befreien.

[C]   Probleme mit Kreuztreffern im NRW-Polizeisystem ViVA, 17.06.2020
https://police-it.net/probleme-mit-kreuztreffern-im-nrw-polizeisystem-viva
„Riesenprobleme“ habe es gegeben mit Kreuztreffern im NRW-Polizeisystem ViVa. Das berichtete ein Zeuge im parlamentarischen Untersuchungsausschuss. Heureka! Die Software ist schuld. Ist diese Erklärung wirklich haltbar?! Ich halte sie für widerlegbar aus mehreren, triftigen Gründen . Auch wenn sie – vor der Sommerpause – den erklärten „politischen Interessen“ nützt, die gerade die CDU im Ausschuss so massiv betont.

[D]   Nur die Spitze des Eisbergs?, 17.09.2020
https://police-it.net/polizei_nordrhein-westfalen-auslaenderfeindlichkeit-amedamed
In der Polizei Nordrhein-Westfalen ist eine rechtsextreme Chatgruppe aufgeflogen. 29 Polizeibeamte sind mit straf- bzw. disziplinarrechtlichen Maßnahmen konfrontiert. Innenminister Reul kündigte mit markigen Worten Gegenmaßnahmen an. Im „PUA-Kleve“-Untersuchungsausschuss zur unrechtmäßigen Inhaftierung des Syrers Amad A., könnte die CDU-Mehrheit demonstrieren, dass diese Ankündigung der neue politische Wille in NRW sind – und endlich für Aufklärung sorgen.

[E]   Fall Amad A.: Manipulationen an Protokoll und Daten, 17.01.2021
https://police-it.net/fall-amad-a-manipulationen-an-protokoll-und-daten
Manipulationen an einem beweisrelevanten Protokoll und die klammheimliche Korrektur von Daten schüren weitere Zweifel an der offiziellen Erklärung im Fall Amad A.

[F]   Fall Amad A.: Polizeidatenbank ViVA machte aus zwei NICHT identischen Menschen einen, 02.02.2021
https://police-it.net/fall-amad-a-polizeidatenbank-viva-machte-aus-zwei-nicht-identischen-menschen-einen
Wenn erkennungsdienstlich von der Polizei behandelte Personen unterschiedliche Fingerabdrücke haben, darf es nicht zu einer Datensatzzusammenführung kommen. Weil dann vom Bundeskriminalamt nach einer daktylo­skopischen Auswertung ihrer Finger-/Handflächenabdrucksätze bestätigt ist, dass diese Personen NICHT identisch sind. Amad A. und der datenmäßig mit ihm „zusammengeführte“ Amedy G. hatten definitiv unterschiedliche Abdrucksätze, d.h. unterschiedliche D-Nummern. Ein Vergleich dieser D-Nummern durch Software ist leicht möglich. Eine fachlich qualifizierte, mit den INPOL-Regeln konforme Software hätte den Unterschied erkennen müssen.

[G]   Was unternimmt IM Reul, um zu verhindern, dass ViVA auch in Zukunft nicht identische Menschen zusammenführt?, 05.02.2021
https://police-it.net/was-unternimmt-im-reul-dagen-dass-viva-erneut-nicht-identische-menschen-zusammenfuehrt
Wieder einmal liegen Einstellungsbescheide der Staatsanwaltschaft Kleve vor zu Ermittlungsverfahren gegen Polizei- und Justizbeamte im Fall des Syrers Amad A.: In seinem Fall wird häufig der Vergleich angestellt mit dem tragischen Tod des Oury Jalloh in einer Polizeizelle in Dessau. Abgesehen von der Gemeinsamkeit des Brandes in der Zelle sehe ich wenige, bewiesene Übereinstimmungen. Ganz im Gegenteil halte ich den Fall des Amad A., für weitaus gravierender, wenn man ihn als Prototypen für einen möglichen Modus Operandi, also eine Vorgehensweise durch Polizei- bzw. Justizbeamte gegenüber Menschen ansieht, die ihnen (zeitweise) anvertraut sind. Dieser Modus Operandi kann sich wiederholen! Denn es kam im Fall Amad A. zur Herstellung einer Datenlage im polizeilichen Informationssystem. Die es so aussehen ließ, als seien der Syrer Amad A. und der Malier Amedy G. ein- und dieselbe Person. Infolgedessen kam es zur Verhaftung und Einlieferung des Amad A. in die JVA. Zehn Wochen später war Amad A. nicht mehr am Leben. Dafür war ein krass regelwidriges Systemverhalten von ViVA mitverantwortlich.

[H]   Wenn Daten töten (1): Fall Amad A.: Die fatalen Folgen einer Schwarzfahrt, 28.02.2021
Teil 1 der Serie ‚Wenn Daten töten – Der Fall des Syrers Amad A.‘
https://police-it.net/wenn-daten-toeten-1-fall-amad-a-die-fatalen-folgen-einer-schwarzfahrt
Ohne die Schwarzfahrt am 04.07.2018 hätte sich das Leben von Amad A. anders entwickelt. Denn die polizeiliche Sachbearbeitung seiner erneuten „Beförderungserschleichung“ an diesem Tag legte den Grundstein für seine unrechtmäßige Festnahme zwei Tage später. Die führte drei Monate später zu seinem Tod.

[I]   Wenn Daten töten: Fall Amad A. (2): Festnahme mit Haftbefehl eines anderen, 02.03.2021
Teil 2 der Serie ‚Wenn Daten töten – Der Fall des Syrers Amad A.‘
https://police-it.net/wenn-daten-toeten-fall-amad-a-2-festnahme-mit-haftbefehl-eines-anderen
Am 06.07.2018 wurde der Syrer Amad A. von der Polizei in Geldern in Gewahrsam genommen. Der Vorfall, der dem zugrunde lag, hätte keinesfalls eine richterliche Freiheitsstrafe nach sich gezogen. Sechs Stunden später war Amad A. festgenommen und in die JVA Geldern eingeliefert. Auf der Grundlage eines Haftbefehls gegen einen völlig anderen Menschen namens Amedy G. Spätere Ermittlungen gegen Polizei- und Justizvollzugsbeamten wurden eingestellt: Eine Kenntnis der fehlenden Identität von Amad A. und Amedy G. habe ihnen nicht nachgewiesen werden können …

[J]   Wenn Daten töten: Fall Amad A. (3): LKA und LZPD geben Rätsel auf, 08.03.2021
Teil 3 der Serie ‚Wenn Daten töten – Der Fall des Syrers Amad A.‘
Am Montag Morgen, dem 09.07.2018 lag die Mitteilung über die Inhaftierung von Amad A. beim LKA vor und wurde dort in ViVA übernommen. Dass der eindeutig identifizierte Amad A. in Haft saß auf der Grundlage von Haftbefehlen für einen Amedy G. wurde auch dort nicht bemerkt. Wo Daten nicht „passten“, wurden sie passend gemacht. Und endlich wurde auch die ED-Behandlung vom 04.07.2018 in ViVA abgeschlossen. Bei all dem kam es zu einer Reihe von bis heute ungelösten Rätseln …

Quellenangaben

[1]    Vergabebekanntmachung Nr. 2019/247-610303 des Landesamts für Zentrale Polizeiliche Dienste NRW vom 23.12.2019 über den Abschluss des EVB-IT-Sstemvertrages VIVA an die T-Systems Information Services GmbH; veröffentlicht in TED – Tenders Electronic Daily

Copyright und Nutzungsrechte

(C) 2021 CIVES Redaktionsbüro GmbH
Sämtliche Urheber- und Nutzungsrechte an diesem Artikel liegen bei der CIVES Redaktionsbüro GmbH bzw. bei dem bzw. den namentlich benannten Autor(en). Links von anderen Seiten auf diesen Artikel, sowie die Übernahme des Titels und eines kurzen Textanreißers auf andere Seiten sind zulässig, unter der Voraussetzung der korrekten Angabe der Quelle und des/der Namen des bzw. der Autoren. Eine vollständige Übernahme dieses Artikels auf andere Seiten bzw. in andere Publikationen, sowie jegliche Bearbeitung und Veröffentlichung des so bearbeiteten Textes ohne unsere vorherige schriftliche Zustimmung ist dagegen ausdrücklich untersagt.