Blog

Einordnung zum Veröffentlichungszeitpunkt: Ein KI-Register sollte Einsatz, Verantwortlichkeiten und Risikoeinordnung getrennt von den jeweils maßgeblichen Anwendungsfristen führen. Änderungen am regulatorischen Fahrplan sind ein Anlass zur Überprüfung des Registers; sie ändern nicht automatisch den tatsächlichen Zweck eines Systems. Ein KI-Register klingt zunächst wie ein Verwaltungsartefakt: eine Liste, ein Tool, ein paar Felder, fertig. Genau s

Als über den EU AI Act gesprochen wird, landen die Gespräche oft sehr schnell bei Governance-Strukturen, Risikoklassen, Registern und internen Prüfprozessen. Das ist wichtig – aber es blendet eine Realität aus, die in vielen Unternehmen darüber entscheidet, ob AI-Compliance überhaupt kontrollierbar wird: Der größte Teil der KI, die heute genutzt wird, wird nicht „gebaut“, sondern eingekauft. Und genau deshalb ist Einkauf und Vendor Management die

AI Governance ist gerade dabei, zwei typische Extreme zu produzieren. Das erste Extrem ist „wir machen erst mal gar nichts, bis alles klar ist“. Das zweite Extrem ist „wir bauen sofort ein großes Programm, das alles abdeckt“. Beides führt in der Praxis selten zu einem stabilen Ergebnis. Das erste Extrem endet meistens in Schattennutzung und hektischer Nacharbeit. Das zweite endet oft in Überkomplexität, Widerstand und Workarounds. Die brauchbare

Einordnung zum Veröffentlichungszeitpunkt: Die Risikoeinordnung richtet sich nach Zweck und Einsatzkontext. Sie ist von der Frage zu trennen, wann eine konkrete Pflicht anwendbar wird. Ein gemeinsamer Stichtag für sämtliche KI-Systeme wäre deshalb keine tragfähige Planungsgrundlage. Auf dem Papier wirkt die Risikologik des EU AI Act zunächst wie eine saubere Sortierung: Einordnen, Pflichten ableiten, fertig. In der Praxis ist genau dieser Schritt

Einordnung zum Veröffentlichungszeitpunkt: Die Anwendung des AI Act erfolgt gestaffelt und hängt von der Rolle sowie dem jeweiligen System oder Modell ab. Die Regeln für verbotene Praktiken gelten bereits seit Februar 2025, die Regeln für Modelle mit allgemeinem Verwendungszweck seit August 2025. Ein Governance-Aufbau sollte deshalb bestehende Pflichten von später anwendbaren Anforderungen unterscheiden. Quelle Es gibt zwei typische Reaktionen, w

Vertrauen ist die Währung des modernen Wirtschaftssystems. Ohne Vertrauen, dass Lieferanten liefern, Dienstleister leisten, Plattformen stabil bleiben und Updates sicher sind, stünde jede Organisation still. Doch genau an diesem Punkt entsteht ein Paradox: Je mehr wir auslagern, standardisieren und „as-a-Service“ konsumieren, desto öfter liegt der kritischste Teil unserer Wertschöpfung außerhalb unserer direkten Kontrolle. Lieferketten – ob physi

Wenn in der Praxis über DORA gesprochen wird, geht es oft zuerst um interne Themen: Prozesse, Rollen, Tests, Meldungen, Nachweise. Das ist nachvollziehbar, weil man dort „direkt“ gestalten kann. Der größte Hebel für die operative Stabilität liegt aber in vielen Unternehmen an einer anderen Stelle: bei externen Dienstleistern. Nicht, weil Dienstleister per se schlecht wären – im Gegenteil. Sondern weil moderne IT-Landschaften ohne Provider, SaaS,

DORA hat eine Eigenschaft, die in vielen Organisationen erst spät wirklich ankommt: Es geht nicht nur darum, dass Sie Prozesse und Kontrollen haben. Es geht darum, dass Sie unter realistischen Bedingungen zeigen können, dass Ihr Betrieb Störungen aushält – und dass Sie daraus sichtbar besser werden. Genau deshalb rückt Testing unter DORA so stark in den Vordergrund. Und genau deshalb entsteht rund um „Threat-led Penetration Testing“ (kurz TLPT) e

Operational Resilience klingt wie ein großes Programm. In der Praxis entscheidet sich aber sehr vieles an einer erstaunlich einfachen Frage: Wie schnell wird aus einem technischen Problem eine klare Entscheidung – und wie schnell wird aus dieser Entscheidung ein koordinierter Ablauf? Genau an dieser Stelle sind Incident-Prozesse in vielen Organisationen zu langsam. Nicht, weil Menschen nicht reagieren. Sondern weil sie im entscheidenden Moment zu

Der Moment, in dem DORA plötzlich „real“ wird, ist selten das Kick-off, selten das erste Requirements-Dokument und auch nicht die hundertste Folie. Real wird DORA meistens dann, wenn jemand fragt: „Zeigen Sie mir das bitte.“ Nicht: „Erklären Sie mir, wie Sie es machen.“ Nicht: „Schicken Sie mir Ihr Konzept.“ Sondern: „Zeigen Sie mir konkret den Nachweis, dass es im Betrieb funktioniert.“ Genau hier trennt sich in der Praxis die Spreu vom Weizen.