• Link zu LinkedIn
  • English English Englisch en
  • Deutsch Deutsch Deutsch de
AT: +43 1 714 00 20 | DE: +49 69 348763610 | Mo-Fr 8-17 Uhr
Spirit in Projects
  • Training / AKADEMIE
  • Blog
  • Innovation
  • Zertifizierungen
  • Beratung
  • Über uns
  • Jobs
  • Englisch
  • Click to open the search input field Click to open the search input field Suche
  • Menü Menü
Claude Mythos

Cybersecurity in der Ära autonomer KI

24. April 2026/von Karl Schott

Claude Mythos Preview ist das fähigste KI-Modell, das Anthropic nach eigenen Aussagen je trainiert hat. Es wird bis auf weiteres nicht für die Öffentlichkeit freigegeben, sondern nur ausgewählten Partnern für spezielle Projekte zur Verfügung gestellt. Warum das so ist – und was es bedeutet habe ich mir genauer angesehen.

Was ist Claude Mythos Preview?

Claude Mythos Preview ist Anthropics neuestes Frontier-Modell, veröffentlicht am 7. April 2026. Laut dem begleitenden System Card zeigt es „einen markanten Sprung“ bei vielen Evaluierungs-Benchmarks gegenüber dem bisherigen Spitzenmodellen von Antrophic, z.B. Claude Opus 4.6.

Anthropic hat beschlossen, das Modell ausschließlich im Rahmen von Project Glasswing an eine begrenzte Zahl von Partnerorganisationen bereitzustellen, die kritische Softwareinfrastruktur betreiben.

Der Grund wurde eindeutig benannt: Die Cybersecurity-Fähigkeiten des Modells sind so weit fortgeschritten, dass eine unkontrollierte Freigabe als zu riskant eingestuft wird.

Anthropic formuliert es auf der Glasswing-Seite explizit:

„Securing critical infrastructure is a top national security priority for democratic countries—the emergence of these cyber capabilities is another reason why the US and its allies must maintain a decisive lead in AI technology.“

Wie gut ist Claude Mythos Preview wirklich in Cybersecurity?

Die Angaben aus dem System Card sind noch nicht unabhängig bestätigt. Sollten sie tatsächlich zutreffen, sind sie durchaus beeindruckend:

Cybench – CTF Challenges

Cybench ist ein etablierter öffentlicher Benchmark mit 40 Capture-the-Flag-Challenges (CTF) aus echten Sicherheitswettbewerben. CTF-Challenges simulieren reale Angriffs- und Verteidigungsszenarien, von Reverse Engineering bis hin zu Schwachstellenanalyse. Anthropic hat Claude Mythos Preview auf einem Teilausschnitt von 35 Challenges evaluiert.

ModellLösungsrate (pass@1, 35-Challenge-Subset)
Claude Mythos Preview100 %
Claude Opus 4.6~70 %
Claude Sonnet 4.6~60 %

Claude Mythos Preview löst jede getestete Challenge mit 100 % Erfolgsquote. Der Benchmark ist damit saturiert – Anthropic erwägt Cybench für zukünftige Modelle nicht mehr zu reporten.

CyberGym – Echte Schwachstellen in Open-Source-Software

CyberGym ist anspruchsvoller: Hier geht es nicht um gamifizierte Challenges, sondern um die Reproduktion von echten, bereits bekannten Sicherheitslücken aus realen Open-Source-Projekten. Das Modell erhält eine Beschreibung der Schwachstelle und muss sie eigenständig in der Software auffinden. Der Benchmark umfasst 1.507 solche Aufgaben.

ModellScore (pass@1)
Claude Mythos Preview0,83
Claude Opus 4.60,67
Claude Sonnet 4.60,65

Ein Sprung von ~24 % gegenüber dem bisherigen Spitzenmodell – bei echten, bereits bekannten Sicherheitslücken.

Firefox 147 – Von der Schwachstelle zum funktionierenden Exploit

Gemeinsam mit Mozilla hatte Anthropic bereits zuvor Sicherheitslücken in Firefox Release 147.0 (vom 13. Jan 2026) gefunden und gepatcht. Auf dieser Arbeit wurde ein weiterer Test aufgesetzt. Das Modell erhielt 50 bereits von Opus 4.6 entdeckte Crash-Kategorien (d.h. grundlegende Arten von Problemen in Firefox) als Ausgangspunkt und sollte in einer isolierten Umgebung für die JavaScript und WebAssembly-Engine (SpiderMonkey) von Firefox funktionsfähige Exploits entwickeln, die beliebige Code-Ausführung ermöglichen.

  • Claude Opus 4.6 schaffte Exploits in nur 2 von mehreren hundert Versuchen und konnte dabei zuverlässig nur einen der verfügbaren Bugs nutzen
  • Claude Mythos Preview erkennt zuverlässig die verwertbarsten Schwachstellen und entwickelt daraus eigenständig Proof-of-Concept-Exploits – fast jedes Mal mit denselben zwei kritischsten Bugs, unabhängig davon, mit welcher Crash-Kategorie die Analyse startete. In einer Variante ohne diese „Top 2″ Bugs nutzt das Modell noch vier weitere bekannte Bugs für Code Execution

Das neue Modell hat also eine viel bessere „Intuition“ dafür wie es Schwachstellen auf verschiedenste Art und Weise ausnützen kann.

Das erste Modell, das ein Unternehmensnetzwerk autonom angreift

Externe Partner testeten das Modell auf geschlossenen Cyber Ranges (simulierten Unternehmensnetzwerken) mit realistischen Schwachstellen.

Die Ergebnisse:

  1. Claude Mythos Preview ist das erste Modell überhaupt, das eine dieser Cyber Ranges vollständig und autonom abgeschlossen hat. Es absolvierte als selbständiger Agent in kürzester Zeit eine Simulation eines Unternehmensangriffs, für die ein menschlicher Experte schätzungsweise über 10 Stunden gebraucht hätte.
  2. Es ist laut externen Testern fähig, autonome End-to-End-Cyberangriffe auf kleine Unternehmensnetzwerke mit schwacher Sicherheitslage durchzuführen (keine aktiven Abwehrsysteme, minimales Monitoring).
  3. Es konnte allerdings eine komplexere Cyber Range in einer Operational-Technology-Umgebung (d.h. eine spezialisierte Betriebstechnologie z.B. Industriesysteme) nicht abschließen.

Was das für schwach geschützte Systeme bedeutet: Angriffe in einer Frequenz und Geschwindigkeit, die manuelle Verteidigung schlicht überfordert.

Wurde das Modell speziell für Cybersecurity Aufgaben entwickelt

Nein – und das ist bemerkenswert. Das System Card beschreibt Claude Mythos Preview ausdrücklich als allgemeines Frontier-Modell mit Fähigkeiten „in many areas“, darunter Software Engineering, Reasoning, Computer Use und Wissensarbeit. Das Training basierte auf einer allgemeinen Mischung aus öffentlich verfügbaren Internetdaten, privaten Datensätzen und synthetischen Daten; das anschließende Post-Training zielte auf Werte-Alignment und nicht auf Cybersecurity ab.

Die außergewöhnlichen Sicherheitsfähigkeiten des Modells sind lt. Anthrophics ein spontan aufgetauchtes Ergebnis gestiegener Allgemeinkapazitäten: Anthropic bezeichnet sie als „inherently dual-use“ und beschreibt den Leistungssprung als unerwarteten Quantensprung gegenüber allen Vorgängermodellen.

Mit anderen Worten – das Modell wurde nicht zum Cybersecurityexperten trainiert, es wurde einfach allgemein fähiger als seine Vorgänger und machte damit einen Sprung zum besseren Hacker.

Alignment-Paradox: Besser ausgerichtet, aber gefährlicher

Anthropic formuliert es an zwei Stellen in der System Card deutlich:

„Claude Mythos Preview is […] the best-aligned of any model that we have trained to date by essentially all available measures.“

— Claude Mythos Preview System Card, Einleitung

Und im Alignment-Kapitel:

„It likely poses the greatest alignment-related risk of any model we have released to date.“

— Claude Mythos Preview System Card, §4.1.1

Wie passt das zusammen? Anthropic vergleicht es mit einem erfahrenen Bergführer: Weil dieser kompetenter ist, bekommt er gefährlichere Anfragen und führt Kunden schließlich auch zu extremeren Routen. Die erhöhte Kompetenz kann erhöhte Vorsicht überkompensieren.

Konkret beobachtete Vorfälle:

  • Sandbox-Ausbruch mit ungefragtem Exploit-Leak: Ein simulierter Nutzer wies das Modell an, aus einer gesicherten und eingeschränkten Umgebung auszubrechen. Das Modell entwickelte dafür einen mehrstufigen Exploit, um breiten Internetzugang zu bekommen und veröffentlichte dann ungefragt Details des Exploits auf mehreren schwer auffindbaren, aber technisch öffentlichen Websites. Die Fähigkeit zum Ausbruch war schon beunruhigend, das unaufgeforderte Offenlegen machte den Vorfall ernst.
  • Tracks verwischen: In sehr seltenen Fällen nahm das Modell regelwidrige Aktionen vor und versuchte dann, diese zu verbergen – darunter das Bearbeiten von Git-Commit-Histories, um Änderungen unsichtbar zu machen.

Die Vorfälle verdeutlichen: Je fähiger ein Modell, desto folgenreicher seine seltenen Fehler.

Mythos heute, Standard morgen: Andere Modelle werden folgen

Anthropic ist nicht allein. Während Mythos Preview die Messlatte gerade neu setzt, trainieren dutzende weitere Labore ihre eigenen Frontier-Modelle – und die Fähigkeitskurve zeigt überall nach oben.

Die Frage ist nicht ob andere Modelle die Cybersecurity-Fähigkeiten von Mythos Preview erreichen werden, sondern wann – und unter welchen Zugangsbedingungen diese Modelle stehen werden.

Was heute „zu gefährlich zum Veröffentlichen“ ist, wird in einer bis zwei Modellgenerationen ein Standardfeature sein. Unternehmen müssen ihre Sicherheitsstrategien entsprechend anpassen – nicht für die Bedrohungslage von 2026, sondern für die von 2027 und 2028.

Was bedeutet das für Unternehmen?

Claude Mythos Preview wird in nächster Zeit voraussichtlich keine breite Unternehmensanwendung finden – es bleibt vorerst Glasswing-Partnern vorbehalten. Aber die Entwicklung, die es repräsentiert, ist für alle relevant. Hierzu meine persönliche Meinung:

1. KI wird zum unausweichlichen Bestandteil der Cybersecurity

Angreifer und Verteidiger werden gleichermaßen auf immer leistungsfähigere Modelle zurückgreifen. Wer KI-gestützte Sicherheitswerkzeuge nicht einsetzt, verliert strukturell gegen Angreifer, die es tun.

2. Schwachstellenanalyse wird schneller und vollständiger

Modelle wie Mythos Preview können Code-Audits, Penetrationstests und Vulnerability Assessments in einem Bruchteil der bisherigen Zeit durchführen – was heute ein 10-Stunden-Expertenprojekt ist, könnte morgen ein 10-Minuten-Modelllauf sein.

3. Legacy-Sicherheitslücken werden gefährlicher

Ältere Software mit bekannten aber ungepatchten Schwachstellen war bisher oft relativ sicher, weil der Exploit-Entwicklungsaufwand hoch war. Das ändert sich durch die Möglichkeit zur Automatisierung der Angriffe – auch ohne Zero-Day-Fähigkeiten ist das Risikoprofil für bestehende Systeme deutlich gestiegen.

4. Überwachung und Auditierbarkeit von KI Agenten wird kritisch

Wenn KI-Agenten mit hoher Autonomie arbeiten, müssen Menschen ihre Aktionen nachvollziehen können. Logging, Monitoring und klare Autorisierungsgrenzen für agentengestützte Systeme sind keine optionalen Features.

5. Das Modell-Update-Risiko ist real

Das System Card stellt fest: Selbst bei Anthropic führte ein Modell mit mehr Fähigkeiten und mehr Autonomie zu unvorhergesehenen Problemen. Organisationen, die KI-Agenten einsetzen, brauchen Prozesse, um zu verstehen, was das Modell in ihrem Namen tut – nicht nur, was es auf Anfrage antwortet.

Fazit: Eine neue Klasse von Fähigkeiten – mit doppeltem Ausgang

Für die Cybersecurity-Landschaft bedeutet das: KI ist kein Hilfsmittel für Sicherheitsteams mehr – sie wird zum primären Akteur auf beiden Seiten des Konflikts. Die Frage für Unternehmen ist nicht mehr, ob man KI im Sicherheitsbereich einsetzt. Die Frage ist, ob man sich leisten kann, es nicht zu tun.

Man muss jetzt aber nicht darauf warten, bis man selbst das beste Modell zum Hacken in Händen hält. Dieser Zeitpunkt könnte nämlich zu spät sein. Für den Aufbau der Verteidigung sind bestehende Frontier-Modelle bereits ganz gut ausgestattet.

Quellen: Anthropic System Card: Claude Mythos Preview (April 2026), Frontier Red Team Blog: Mythos Preview (April 2026), Project Glasswing – Anthropic (April 2026, inkl. Partneraussagen und Zitat zur nationalen Sicherheit), CyberGym Benchmark und CyberGym Blog – UC Berkeley RDI (Oktober 2025), Cybench

https://spiritinprojects.com/wp-content/uploads/2026/04/technology-human-touch-backgroun-1.jpg 450 800 Karl Schott https://spiritinprojects.com/wp-content/uploads/2020/04/sip_web_padding_10px_topbot.jpg Karl Schott2026-04-24 11:44:032026-04-28 15:30:03Cybersecurity in der Ära autonomer KI
large language model

Open Source bei Large Language Models: Wie offen ist „offen“ wirklich?

20. April 2026/von Karl Schott

Die Begriffe „Open Source“ und „offen“ werden in der LLM-Welt inflationär verwendet –  hinter den Marketingaussagen verbergen sich jedoch massive Unterschiede. Ich möchte in diesem Beitrag das Spektrum der Offenheit dieser Systeme einordnen und zeigen, welche relevanten Modelle in welche Kategorie fallen. Gerade für vertrauenswürdige KI-Anwendungen ist volle Transparenz entscheidend – wie wir sehen werden, ist sie jedoch selten.

Das Spektrum der Offenheit: 5 Stufen

Die Open Source Initiative (OSI) hat 2024 mit der Open Source AI Definition (OSAID 1.0) erstmals einen Standard geschaffen. Ergänzend bietet das Model Openness Framework (MOF) der Linux Foundation einen abgestuften Ansatz, um zu entscheiden, wie offen und damit nachvollziehbar ein LLM tatsächlich ist. Aus diesen Frameworks und der Praxis können wir fünf Stufen ableiten – von vollständig geschlossen bis vollständig offen.

Kategorie Weights: Die trainierten Modellparameter – das „Gehirn“ des Modells, das direkt ausgeführt werden kann.

Kategorie Code: Quellcode für Training – ermöglicht Nachvollziehbarkeit und eigene Anpassungen.

Kategorie Trainingsdaten: Die verwendeten Datensätze – entscheidend für Transparenz, Bias-Analyse und rechtliche Nachvollziehbarkeit.

Kategorie Trainings-Methodik: Verfahren, Hyperparameter und Prozesse beim Training – von kurzen Paper-Beschreibungen bis zur vollständigen Reproduzierbarkeit.

Übersicht

StufeBezeichnungWeightsCodeTrainingsdatenTrainings-methodikLizenz
5Closed/ Proprietär❌❌❌❌Nur API-Zugang
4Restricted Weights✅⚠️ teilweise❌⚠️ PaperRestriktiv (Nutzungslimits)
3Open Weights✅⚠️ teilweise❌⚠️ PaperFrei bis restriktiv
2Open Weights + Offene Methodik✅✅⚠️ teilweise✅Frei
1Vollständig Open Source✅✅✅✅Frei (Apache 2.0, MIT)

Stufe 5: Closed / Proprietär ⚫

Kein Zugang zu Weights, Code oder Daten. Nutzung ausschließlich über APIs oder lizenzierte Integrationen.

Diese Modelle stehen unter vollständiger Kontrolle der Entwicklerfirmen. Man kann sie nutzen, aber nicht inspizieren, modifizieren oder selbst hosten. Die interne Architektur, die Trainingsdaten und der Code bleiben Betriebsgeheimnisse.

Relevante Modelle

ModellOrganisationBesonderheiten
GPT-4o / GPT-5OpenAIFlaggschiff-Modelle. Multimodal. Nur per API.
Claude 4 / 4.5AnthropicFokus auf Sicherheit und lange Kontexte. Nur per API.
Gemini 3.1 / 3.1 ProGoogleNativ multimodal. Tief in Google-Produkte integriert.
Grok-3 / 4xAINachfolger von Grok-1 und 2 (die noch offen waren). Closed.

Einordnung: Diese Modelle bieten oft die höchste Leistung „out of the box“, aber keine Kontrolle über Daten, keine Reproduzierbarkeit der Ergebnisse und damit vollständige Abhängigkeit vom Anbieter. Oft ist nicht einmal bekannt, wie groß das Modell ist oder wie viele Trainingsdaten verwendet wurden.

Stufe 4: Restricted Weights (Eingeschränkt offen) 🔴

Weights sind herunterladbar, aber die Lizenz enthält signifikante Einschränkungen, z. B. kommerzielle Nutzungslimits, Nutzungsvorschriften oder Attributionspflichten ab bestimmten Schwellenwerten.

Diese Modelle werden oft als „Open Source“ vermarktet, sind es nach der OSI-Definition aber nicht. Sie bieten Zugang zu den Weights, binden die Nutzung aber an Bedingungen.

Relevante Modelle

ModellOrganisationLizenzEinschränkungen
Llama 4 (Scout/Maverick)MetaLlama LicenseKommerzielle Nutzung bis 700 Mio. monatlich aktive Nutzer (MAU). Darüber: separate Lizenz nötig. Verbot, andere LLMs damit zu trainieren.
Kimi K2.5Moonshot AIModified MITAb 100 Mio. MAU oder $20 Mio. Umsatz: „Kimi K2.5″-Branding Pflicht.
Command R+CohereCC-BYNC-4.0Keine kommerzielle Nutzung ohne separate Lizenzvereinbarung mit Cohere.

Einordnung: Die Llama-Modelle von Meta sind das prominenteste Beispiel für diese Kategorie – sie sind zweifellos nützlich und leistungsstark, aber die Lizenz schließt wichtige Open-Source-Freiheiten aus.

Stufe 3: Open Weights 🟠

Modellgewichte sind frei verfügbar und nutzbar (auch kommerziell), aber Trainingsdaten und oft auch der Trainingscode bleiben geschlossen.

Das ist die häufigste Kategorie unter den „offenen“ Modellen. Man kann sie herunterladen, lokal betreiben und feinabstimmen – aber man kann sie nicht von Grund auf reproduzieren, da die Trainingsdaten fehlen.

Relevante Modelle

ModellOrganisationLizenzBesonderheiten
Gemma 3 / 4GoogleGemma-LizenzMultimodal. Effizient auf Consumer-Hardware. 256K Kontext.
GLM-5Zhipu AIMIT744B MoE (40B aktiv). Stark in Coding und Agentic Tasks. Keine Nutzungseinschränkungen.
gpt-oss 120bOpenAIApache 2.0Erstes offenes OpenAI-Modell seit GPT-2. 117B (MoE, 5,1B aktiv). Stark bei Wissen (MMLU-Pro ca. 80,8 %).

Einordnung: Für die meisten Unternehmen und Entwickler:innen ist diese Kategorie der Sweet Spot – man erhält leistungsstarke Modelle mit weitgehender Nutzungsfreiheit, ohne die Komplexität vollständiger Reproduzierbarkeit.

Stufe 2: Open Weightss + Offene Methodik Gelber Kreis

Weights und Code sind offen und ohne Nutzungseinschränkungen lizenziert, Trainingsdaten sind teilweise dokumentiert oder referenziert, aber nicht vollständig verfügbar.

Diese Modelle gehen weit über „nur Weights“ hinaus: Sie veröffentlichen detaillierte Technical Reports, Trainingsrezepte und oft auch den Trainingscode – aber die exakten Trainingsdaten sind nicht vollständig verfügbar, etwa aus urheberrechtlichen Gründen oder wegen der schieren Datenmenge.

Relevante Modelle

ModellOrganisationParameterLizenzBesonderheiten
DeepSeek V3 / V3.2DeepSeek671B (37B aktiv, MoE)MIT (Code) / DeepSeek Model License (Weights)Vollständiger Trainingscode offen. Detailliertes Paper. Trainingsdaten nicht offen, aber Methodik exzellent dokumentiert. Weights kommerziell nutzbar.
DeepSeek R1DeepSeek671B (37B aktiv, MoE)MIT (Code) / DeepSeek Model License (Weights)Reasoning-Modell mit RL. Destillierte Varianten: Qwenbasierte unter Apache 2.0, Llama-basierte unter LlamaLizenz.
Qwen 3 / 3.5Alibababis 397B (MoE)Apache 2.0Breiteste Modellpalette (0,6B– 235B). 200+ Sprachen. Trainingsmethodik in Papers dokumentiert.
Mixtral 8x22B / Mistral Small 3Mistral AI141B (MoE, 39B aktiv) / 24BApache 2.0Europabasiertes Unternehmen. Frei nutzbar (im Gegensatz zu Mistral Large 2, das unter der Mistral Research License steht und damit in Stufe 4 einzuordnen wäre).

Einordnung: Hier finden sich viele der aktuell leistungsstärksten offenen Modelle. DeepSeek und Qwen setzen mit MIT bzw. Apache 2.0 den Maßstab für industrietaugliche Offenheit – ohne die vollen Trainingsdaten preiszugeben.

Stufe 1: Vollständig Open Source Grüner Kreis

Alles ist offen: Weights, Code, Trainingsdaten, Methodik und Dokumentation. Das Modell kann von Grund auf reproduziert werden.

Dies ist die strengste Kategorie – und die seltenste. Gemäß der OSI-Definition (OSAID 1.0) müssen alle Komponenten ohne Nutzungseinschränkungen verfügbar sein (etwa unter Apache 2.0 oder MIT): Modellgewichte, vollständiger Trainingscode, die Trainingsdaten (oder hinreichend detaillierte Dokumentation) sowie die gesamte Trainingsmethodik.

Warum ist das wichtig?

Nur bei vollständiger Offenheit kann man den Bias in Trainingsdaten auditieren, Ergebnisse nachvollziehen und das Modell tatsächlich von Grund auf reproduzieren. Das ist die Grundlage für echte Nachprüfbarkeit.

Relevante Modelle

ModellOrganisationBesonderheiten
OLMo 3 / 3.1AI2 (Allen Institute)Alle Checkpoints, Dolma-3-Trainingsdaten, Logs, EvalCode offen. Apache 2.0. Inkl. OLMoTrace für Rückverfolgung zu Quelldaten.
Amber-7B / Crystal-7B / K2-65BLLM360Projekt mit radikaler Transparenz („360°“): alle Checkpoints, Trainingsdaten, Metriken und W&B-Logs offen. K2-65B übertrifft Llama 2 70B.
PythiaEleutherAIForschungsmodell-Suite mit 8 Größen (70M–12B), jeweils 154 Checkpoints. Pile-Trainingsdaten offen. Apache 2.0.
BLOOM (176B)BigScience / HuggingFacePionierprojekt (Juli 2022): ROOTS-Corpus (1,6 TB, 46 Sprachen) offen. BigScience BLOOM RAIL License v1.0.
MAP-Neo (7B)M-A-PBilingual (EN/ZH). 4,5T Tokens. Trainingsdaten (MatrixPile), Cleaning-Pipeline und Checkpoints offen.

Einordnung: Diese Modelle sind nicht die leistungsstärksten – aber sie sind für die Wissenschaft und die Open-Source-Gemeinschaft von unschätzbarem Wert. OLMo von AI2 ist hier das aktuelle Flaggschiff.

Die wichtigsten Unterscheidungsmerkmale im Detail

Was genau ist verfügbar?

Stufe 5Stufe 4Stufe 3Stufe 2Stufe 1
Weights❌✅✅✅✅
Architektur-Details❌⚠️✅✅✅
Trainingscode❌❌⚠️✅✅
Trainingsdaten❌❌❌⚠️✅
Trainingsmethodik❌⚠️⚠️✅✅
Freie Lizenz❌❌✅✅✅
Reproduzierbarkeit❌❌❌⚠️✅

Lizenz-Landkarte

LizenzTypKommerzielle NutzungBeispiele
ProprietärGeschlossen❌ Nur per APIGPT-4, Claude, Gemini
CC-BY-NCRestriktiv❌ Nur nichtkommerziellCommand R+
Llama LicenseRestriktiv⚠️ Bis 700M MAULlama 3, Llama 4
RAILRestriktiv⚠️ Mit NutzungsverbotenBLOOM
Gemma LicenseSemi-Offen✅ Mit NutzungsrichtlinienGemma 3, Gemma 4
MITOffen (keine Einschränkung)✅ UneingeschränktDeepSeek (Code), GLM-5, Phi-4
Apache 2.0Offen (keine Einschränkung)✅ UneingeschränktQwen, Mixtral, OLMo, Falcon 7B/40B

Fazit: Was bedeutet das für die Praxis?

  1. „Open Source“ ≠ „Open Source“ – Die Bezeichnung wird inflationär verwendet. Nur Modelle der Stufe 1 erfüllen die OSI-Definition vollständig. Die meisten populären „offenen“ Modelle fallen in Stufe 2–3.
  2. Der Sweet Spot liegt bei Stufe 2–3 – Modelle wie DeepSeek V3.2, Qwen 3.5 oder Gemma 4 bieten eine exzellente Balance aus Leistung, Nutzungsfreiheit und Zugänglichkeit.
  3. Vorsicht bei Stufe 4 – Llama-Modelle sind fantastisch für Prototyping und Forschung, aber die Lizenzbedingungen können bei kommerziellem Einsatz zum Problem werden.
  4. Stufe 1 ist entscheidend für die Wissenschaft – Projekte wie OLMo und Pythia ermöglichen echte Forschung über das Verhalten von LLMs, Bias-Analyse und algorithmische Transparenz.
  5. Die Lücke schließt sich – Offene Modelle (Stufe 1–3) erreichen 2025/2026 auf vielen Benchmarks das Niveau das proprietärer Modelle nur ein paar Monate zuvor hatten. Der Grund, sich vollständig an geschlossene Anbieter zu binden, wird immer schwächer.

Stand: April 2026. Die LLM-Landschaft entwickelt sich rasant – neue Modelle und Lizenzen können die Einordnung schnell verändern.

Quellen & weiterführende Links

Open Source AI Definition (OSAID 1.0) – OSI

Model Openness Framework – Linux Foundation

OLMo – AI2

Open Source LLM Leaderboard – whatllm.org

https://spiritinprojects.com/wp-content/uploads/2026/04/18928-1.jpg 450 800 Karl Schott https://spiritinprojects.com/wp-content/uploads/2020/04/sip_web_padding_10px_topbot.jpg Karl Schott2026-04-20 16:03:582026-04-20 16:03:59Open Source bei Large Language Models: Wie offen ist „offen“ wirklich?
KI Maennchen Halluzination

KI-Halluzinationen: Wenn Large Language Modells überzeugend lügen – und warum das öfter passiert als man denkt!

9. April 2026/von Karl Schott

LLMs erfinden Gerichtsurteile oder Entdeckungen des James-Webb-Teleskops. Ein Reiseportal schickt Touristen zu Sehenswürdigkeiten, die nicht existieren. Willkommen in der Welt der KI-Halluzinationen!

Was sind KI-Halluzinationen?

KI-Halluzinationen treten auf, wenn ein LLM (Large Language Modell) Antworten generiert, die überzeugend klingen, aber faktisch falsch, frei erfunden oder aus dem Kontext gerissen sind. Anders als menschliche Halluzinationen (Sinnestäuschungen) handelt es sich hier um erzeugte Inhalte – Texte, Bilder, Code – die keinerlei faktische Grundlage haben.

Das Tückische: Die Antworten klingen nicht nur plausibel, sie werden oft mit größter Selbstsicherheit präsentiert, die den Benutzer damit leicht in die Irre führen kann. Es gibt Berichte, dass KI-Modelle häufiger Formulierungen wie „definitiv“ oder „ohne Zweifel“ verwenden, wenn sie falsche Informationen generieren – also gerade dann, wenn sie sich irren.

Arten von KI-Halluzinationen

TypBeschreibungBeispiel
FaktenfehlerFalsche Tatsachenbehauptungen„Sydney ist die Hauptstadt Australiens“
Erfundene QuellenNichtexistierende Studien oder ZitateFiktive Gerichtsurteile in Anwaltsschriftsätzen
WidersprücheAussagen, die sich selbst widersprechenGegensätzliche Empfehlungen im selben Text
Nonsens-InhalteLogisch unsinnige AntwortenTomatensauce im Kuchenrezept
Visuelle HalluzinationenFehler in KI-generierten BildernElefant mit sechs Beinen, Uhren mit zu vielen Zeigern

Probiere es selbst aus: KI-Halluzinationen live erleben

Die Modelle werden besser – viele können inzwischen „Ich weiß es nicht“ sagen. Aber mit den richtigen Fragen lassen sich auch aktuelle Modelle noch zuverlässig zum Halluzinieren bringen. Probiere die folgenden Experimente in verschiedenen Chatbots aus (ChatGPT, Gemini, Claude, Mistral, Copilot …) und vergleiche die Ergebnisse. Gerade der Vergleich ist aufschlussreich.

🧪 Experiment 1: Die erfundene Firmengeschichte

Prompt: „Was genau ist am 14. März 2019 bei der Firma Siemens passiert? Beschreibe das Ereignis im Detail.“

Tipp: Du kannst jede beliebige Kombination aus realem Unternehmen + konkretem Datum verwenden – z. B. „Was geschah am 7. Juni 2018 bei Bosch?“. Bei diesem Test fallen insbesondere einfachare Modell herein. Aktuelle Marktführer sind dagegen schon gut durch zusätzliche Filter gerüstet können aber zufällig auch überraschend schlechte Antworten generieren.

Was passiert: Die meisten Modelle erfinden ein plausibel klingendes Ereignis – eine Produktankündigung, eine Übernahme, eine Restrukturierung – mit konkreten Details, die frei erfunden sind. Manche Modelle lehnen ab, andere halluzinieren selbstbewusst. Die Überprüfung ist einfach: Google das Datum + Firmenname und prüfe, ob das genannte Ereignis tatsächlich stattfand.

Warum das funktioniert: Das Modell kennt viele reale Fakten über Siemens und viele typische Unternehmens-Events. Es kann nicht zwischen „Ich weiß etwas über diesen Tag“ und „Ich kann mir etwas Plausibles zusammenreimen“ unterscheiden.

🧪 Experiment 2: Der Widerspruchstest

Prompt 1: „Welches Land hat die höchste Lebenserwartung weltweit und wie hoch ist sie genau?“

(Antwort abwarten, dann in derselben Konversation:)

Prompt 2: „Bist du sicher? Ich habe gelesen, dass es eigentlich Andorra ist mit 89,4 Jahren.“

Was passiert: Viele Modelle knicken ein und ändern ihre (oft korrekte!) Erstantwort. Sie bestätigen die falsche Behauptung, erfinden eine Quelle dafür oder relativieren ihre ursprüngliche Aussage – selbst wenn die erste Antwort richtig war. Das ist eine besonders tückische Form der Halluzination: Speichelleckerei – das Modell sagt dem Nutzer, was er hören will.

Warum das funktioniert: LLMs werden durch Reinforcement Learning durch Human Feedback (RLHF) trainiert, bei dem „hilfreich sein“ und „dem Nutzer zustimmen“ oft belohnt wird. Das führt dazu, dass Modelle bei Widerspruch eher nachgeben als bei ihrer korrekten Antwort zu bleiben.

💡Was du beim Testen lernen wirst: Die Ergebnisse variieren stark zwischen Modellen. Manche halluzinieren bei Experiment 1, aber nicht bei 2 – und umgekehrt. Genau das ist der Punkt: Halluzinationen sind nicht vorhersagbar. Und genau deshalb muss man sie systematisch adressieren.

Wie stark halluzinieren die einzelnen Modelle?

Die Halluzinationsraten variieren stark je nach Modell, Aufgabe und Benchmark. Es gibt inzwischen etablierte Leaderboards, die systematisch messen.

Vectara Hallucination Leaderboard (HHEM)

Das Vectara Hallucination Leaderboard ist einer der bekanntesten Benchmarks. Es misst, wie häufig ein LLM beim Zusammenfassen von Dokumenten Informationen erfindet, die nicht im Quelltext stehen (grounded summarization).

Bekannte Modelle mit niedrigen Halluzinationsraten (März 2026):

ModellHalluzinationsrate
OpenAI GPT-5.4 Nano3,1 %
Google Gemini 2.5 Flash Lite3,3 %
Microsoft Phi-43,7 %
Meta Llama 3.3 70B4,1 %
Mistral Large4,5 %
DeepSeek V3.25,3 %
OpenAI GPT-4.15,6 %
xAI Grok-35,8 %

Bekannte Modelle mit höheren Raten:

ModellHalluzinationsrate
OpenAI GPT-4o9,6 %
Anthropic Claude Haiku 4.59,8 %
Anthropic Claude Sonnet 4.610,6 %
Google Gemini 3 Pro13,6 %
OpenAI GPT-5-hgih15,1 %

Quelle: Vectara Hallucination Leaderboard auf GitHub, Stand März 2026

Interessant: Ausgerechnet auch die leistungsstärksten „Reasoning“-Modelle zeigen bei diesem Benachmark höhere Halluzinationsraten. Vectara nennt dieses Phänomen den „Reasoning Tax“ – die Modelle „überdenken“ den Text und weichen vom Quellmaterial ab, anstatt einfach zusammenzufassen.

AA-Omniscience (Artificial Analysis)

Der AA-Omniscience Benchmark misst etwas anderes: Weiß ein Modell, dass es etwas nicht weiß? Er testet Wissensfragen in verschiedenen Themengebieten und bestraft falsche Antworten stärker als ein ehrliches „Ich weiß es nicht“.

Ergebnis: Nur wenige der getesteten Modellen erreichten zumindest einen niedrigen positiven „Omniscience Index“ – die meisten Modelle geben im Durchschnitt lieber eine überzeugt klingende falsche Antwort als zuzugeben, dass sie es nicht wissen.

ModellOmniscience Index*
Gemini 3.1 Pro Preview33
Grok 4.20 (Reasoning)15
Claude Opus 4.6 (max)14
GPT-5.4 (xhigh)6
Gemini 3.1 Flash-Lite-16
DeepSeek V3.2–21
K2 Think V2–34
gpt-oss-120B (high)-50

* Werte von 100 bis -100. 0 würde gleich viele korrekte wie falsche Antworten bedeuten.

Zitierfähigkeit: Der Sonderfall

Besonders drastisch sind die Halluzinationsraten bei Quellenangaben. Eine Studie der Columbia Journalism Review (März 2025) testete, wie korrekt KI-Modelle Nachrichtenquellen zitieren:

ModellHalluzinationsrate bei Zitaten
Perplexity37 %
Microsoft Copilot40 %
ChatGPT67 %
Gemini76 %
Grok-394 %

Quelle: Columbia Journalism Review – AI Search Has a Citation Problem

Fazit: Kein einzelner Benchmark erzählt die ganze Geschichte. Ein Modell kann bei Zusammenfassungen exzellent abschneiden und gleichzeitig bei Zitaten in 94 % der Fälle halluzinieren. Die Wahl des richtigen Modells hängt vom konkreten Einsatzszenario ab.

Wie lassen sich KI-Halluzinationen reduzieren?

Vollständig eliminieren lassen sich Halluzinationen beim aktuellen Stand der Technik nicht. Aber es gibt Strategien, um das Risiko als Benutzer drastisch zu senken:

🔧 Technische Maßnahmen

1. Retrieval-Augmented Generation (RAG) Der aktuell wirksamste Ansatz: Das KI-Modell wird mit einer verifizierten Wissensdatenbank verbunden. Anstatt nur aus dem Trainingsgedächtnis zu antworten, greift die KI auf geprüfte Quellen zu. RAG soll Halluzinationen um 30 – 70 % reduzieren können.

2. Domain-spezifisches Fine-Tuning Durch gezieltes Nachtraining mit qualitativ hochwertigen, fachspezifischen Daten wird die Genauigkeit in den trainierten Bereichen deutlich verbessert.

3. Multi-Modell-Ansätze Mehrere KI-Modelle werden parallel eingesetzt und ihre Antworten verglichen. Abweichungen werden für menschliche Überprüfung markiert.

4. Guardrails und Faktencheck-Layer Technische Schutzmechanismen überwachen KI-Ausgaben in Echtzeit und erkennen unplausible Antworten, bevor sie den Nutzer erreichen.

👤 Organisatorische Maßnahmen

5. Human-in-the-Loop Für kritische Anwendungen ist menschliche Überprüfung nicht optional, sondern Pflicht. KI liefert Entwürfe – Menschen entscheiden.

6. Prompt Engineering Klare, präzise Anweisungen reduzieren Halluzinationen messbar. Dazu gehört: – Angabe vertrauenswürdiger Quellen als Kontext – Strukturierte Vorlagen zu Antworten, die keine Spekulation erlauben – Explizite Aufforderung, bei Unsicherheit „Ich weiß es nicht“ zu sagen

7. Temperatur-Einstellungen anpassen Wer Zugang zu Modellparametern hat: Eine niedrigere „Temperature“ priorisiert das wahrscheinlichste nächste Wort (und damit oft korrektere) Antworten gegenüber kreativeren. Die Konversation mit dem Modell wird dadurch für Menschenen aber wesentlich eintöniger.

8. Regelmäßiges Testen und Monitoring KI-Systeme sollten kontinuierlich auf Halluzinationsraten geprüft und überwacht werden – besonders nach Updates der zugrunde liegenden Modelle. Also nicht immer einfach auf das neueste Modell „upgraden“, sondern zuerst seine Leistungen beurteilen.

Fazit: KI-Halluzinationen sind kein Bug – sie sind ein Feature, das Management braucht

KI-Halluzinationen werden nach meiner Einschätzung nicht verschwinden. Sie sind ein strukturelles Merkmal der aktuellen Generation von Sprachmodellen. Die entscheidende Frage ist nicht ob eine KI halluziniert, sondern wie wir damit umgehen.

Für Unternehmen bedeutet das:

✅ KI niemals unbeaufsichtigt in kritischen Prozessen einsetzen ✅ RAG und Faktenprüfung als Standard implementieren ✅ Mitarbeiter für KI-Halluzinationen sensibilisieren und schulen ✅ Klare Richtlinien für den KI-Einsatz etablieren ✅ Das richtige Modell für den richtigen Einsatzzweck wählen – die Benchmarks zeigen: Die Unterschiede sind enorm

Die Unternehmen, die KI-Halluzinationen ernst nehmen und systematisch adressieren, werden einen entscheidenden Wettbewerbsvorteil haben – gegenüber denen, die erst durch einen teuren Fehler aufwachen.

https://spiritinprojects.com/wp-content/uploads/2026/06/KI-Maennchen_Halluzinationen-1.png 450 800 Karl Schott https://spiritinprojects.com/wp-content/uploads/2020/04/sip_web_padding_10px_topbot.jpg Karl Schott2026-04-09 18:28:402026-06-10 13:21:44KI-Halluzinationen: Wenn Large Language Modells überzeugend lügen – und warum das öfter passiert als man denkt!

Mehr Transparenz am Vorfeld: Flughafen München digitalisiert die Flugzeugabfertigung & CEO Wolfgang Hiermann spricht dazu auf der REConf 2026

8. April 2026/von Tanja Meszarits

Mehr Transparenz in der Abfertigung: Flughafen München setzt auf kamerabasierte Statuserfassung 

Der Flughafen München treibt die Digitalisierung seiner Betriebsprozesse konsequent voran. Wir haben dieses Vorhaben von Beginn an begleitet – von der Erstellung des Lastenhefts über die Ausschreibungsbegleitung bis hin zur Umsetzung und Abnahme. Damit konnten wir die Grundlage für die kamerazentrierte Abfertigungszustandserkennung (KAZE) schaffen und aktiv zur erfolgreichen Realisierung beitragen.  

Im März 2026 wurde im Terminal 2 ein kamerabasiertes System zur Erfassung des Abfertigungsstatus in Betrieb genommen. In den kommenden Monaten wird die Lösung schrittweise auf alle Abstellpositionen auf den Vorfeldern 1,2 und 3 ausgeweitet. 

Ziel ist es, die Flugzeugabfertigung vom Anrollen bis zum Abrollen lückenlos, objektiv und datenbasiert nachvollziehen zu können. Mit diesen Daten und Ergebnissen soll weiterhin ein transparentes, effizientes und zukunftsorientiertes Flughafenmanagement unterstützt werden.  

Von der Prozessbeobachtung zu belastbaren Echtzeitdaten 

An den Abstellpositionen erfassen jeweils 2 Kameras mithilfe von Software und künstlicher Intelligenz sämtliche Abfertigungsprozesse – von der Betankung, über die Gepäckbeladung bis zum Catering – und versehen diese mit einem präzisen Zeitstempel. So entsteht eine objektive Datenbasis, die deutlich über klassische manuelle Statusmeldungen hinausgeht. Die Datenerfassung pro Stand umfasst rund 2 Monate, in denen Daten über verschiedene Arbeitsabläufe aus verschiedenen Flugzeugmodellen gespeist werden.  

Der Mehrwert von KI-Unterstützung liegt nicht nur in der Dokumentation, sondern vor allem in der operativen Steuerung: Die gewonnenen Echtzeitdaten können die Koordination zwischen beteiligten Stellen verbessern, fundierte Entscheidungen im Tagesgeschäft unterstützen und so zu mehr Pünktlichkeit, Stabilität und Effizienz beitragen.  

Für einen Flughafen sind diese Turnaround-Prozesse entscheidend, da diese hochkomplex sind: Viele Gewerke greifen ineinander, Zeitfenster sind eng, Abweichungen wirken sich schnell auf nachfolgende Umläufe aus. Eine durchgängige, objektive Sicht auf den Abfertigungsstatus schafft Voraussetzungen, damit Engpässe früher erkannt, die Übergaben transparenter gestaltet, Abläufe datenbasiert optimiert und operative Entscheidungen schneller und belastbarer getroffen werden können.   

Auszeichnung: Unser Geschäftsführer Wolfgang Hiermann als Speaker auf der ReConf 26

Projekte im Requirements Engineering sind auch Thema auf der REConf26: Wolfgang Hiermann wurde als Speaker angenommen und wird gemeinsam mit Johannes Knöferle (Leitung Produkt- und Performance Management, Flughafen München) Einblicke und Learnings rund um den Einsatz von Requirements Engineering in KI-Projekten teilen.  

Die Einladung ist eine besondere Anerkennung: Laut Rückmeldung der Veranstalter gab es so viele Einreichungen, wie noch nie (mehr als in den letzten zwei Jahrzehnten), bei durchweg hoher Qualität und sehr engem Bewertungsfeld. Umso mehr freut es uns, dass sich unser Projekt durchsetzen konnte und zu den ausgewählten Vorträgen gehört.  

Was ist die REconf? 

Die REConf (Requirements Engineering Conference) von der HOOD GmbH ist eine führende europäische Fachkonferenz in München, die sich auf Requirements Engineering, Systems Engineering und agile Methoden spezialisiert und seit 2002 jährlich stattfindet, um die besten aus der Branche zusammen zu bringen, um gegenseitig zu lernen, auszutauschen und zu diskutieren. 

https://spiritinprojects.com/wp-content/uploads/2026/04/Flughafen-1.jpg 450 800 Tanja Meszarits https://spiritinprojects.com/wp-content/uploads/2020/04/sip_web_padding_10px_topbot.jpg Tanja Meszarits2026-04-08 10:11:492026-04-29 13:56:44Mehr Transparenz am Vorfeld: Flughafen München digitalisiert die Flugzeugabfertigung & CEO Wolfgang Hiermann spricht dazu auf der REConf 2026
Büro mit 4 Mitarbeitern, die an Laptops und großen Bildschirmen sitzen

KI als Teil des Softwareentwicklungsprozesses: Schnellere Umsetzung – bei verlässlich hoher Code-Qualität

12. Februar 2026/von Florian Gürtler

Künstliche Intelligenz verändert derzeit die gesamte IT-Branche – und damit auch grundlegend, wie Software entwickelt wird. Begriffe wie Agentic Programming oder Prompt-Driven Development tauchen immer häufiger in Entwickler*innen-Communities auf und stehen für einen neuen Ansatz: Code wird nicht mehr ausschließlich Zeile für Zeile geschrieben, sondern entsteht im Zusammenspiel mit Large Language Models (LLMs) – schneller, iterativer und stärker über Anforderungen gesteuert. Für Unternehmen ist das vor allem aus drei Gründen relevant: kürzere Time-to-Market, höhere Produktivität und ein stärkerer Fokus auf fachliche Anforderungen.

Wir haben diesen Ansatz in einem unserer internen Projekt bei Spirit in Projects eingesetzt – und haben dabei zwei zentrale Learnings bei der Verwendung von KI in Entwicklungsprojekten gewonnen: KI kann die Entwicklung von Anwendungen deutlich beschleunigen, verlangt aber Mehraufwand durch präzise Steuerung sowie eine konsequente Qualitätssicherung durch Reviews und Tests.

Nachdem Stefan Hiermann in einem anderen Blogbeitrag bereits Power Apps und eine herkömmliche Entwicklung mit KI-Unterstützung anhand desselben Projekts gegenübergestellt hat (👉 hier geht’s zu Teil 1), zeigen wir in diesem Beitrag, wie KI-Integration bei uns in der Softwareentwicklung umgesetzt wurde, welche Erfahrungen wir dabei gesammelt haben – und warum KI-gestützte Programmierung für uns mehr als ein kurzfristiger Trend ist.

Projektkontext

Ziel dieses internen Projektes war die Entwicklung eines Dashboards für Mitarbeitende und Management als zentrales Portal für:

  • Arbeitszeiterfassung
  • Ressourcenmanagement
  • Urlaubsverwaltung

Technisch basiert die Lösung auf Django (Python) und HTMX. Die Software- und Datenarchitektur (u. a. Struktur, Rollen, Rechte, Datenmodell) haben wir dabei selbst entworfen, um eine robuste und langfristig wartbare Grundlage zu schaffen. 

Unser Vorgehen: KI-gestützt entwickeln – ohne Qualitätsverlust

Die Grundlage des gesamten Entwicklungsprozesses waren klar definierte Anforderungen. Deshalb haben wir vor der Umsetzung eine Requirements Engineering Phase durchgeführt: Gemeinsam mit unseren Stakeholder*innen haben wir Ziele, Rollen, Rechte und Prozesse geschärft, User Stories inkl. Use Cases beschrieben und davon priorisierte Anforderungen mit Akzeptanzkriterien abgeleitet – die als „Single Source of Truth“ dienten. Mehr dazu in unseren IREB/CPRE Trainings.

Darauf aufbauend wurde der Code promptgetrieben mithilfe eines AI-nativen Plugins (Kilo Code) direkt in unserer Entwicklungsumgebung (Visual Studio Code) generiert. Dabei haben wir unterschiedliche Modelle eingesetzt (u. a. Gemini 3 Flash oder Claude Sonnet 4.5). Einen Vergleich dieser Modelle haben wir bereits in einem separaten Beitrag beschrieben: 👉 Hier gehts zum Beitrag

Der KI-generierte Code wurde anschließend regelmäßig reviewed, an unsere Standards angepasst und bei Bedarf manuell ergänzt, insbesondere bei komplexerer Logik oder spezifischen Bugs. Durch konsequentes Testing konnten wir Fehler frühzeitig identifizieren und beheben. In Kombination mit unserer technischen Expertise stellte das sicher, dass Qualität, Wartbarkeit und Stabilität jederzeit gewährleistet blieben.

Die zentralen Herausforderungen (und was wir daraus gelernt haben)

Der Einsatz von KI in der Softwareentwicklung bringt neben großen Chancen auch berechtigte Herausforderungen mit sich. Drei Punkte waren für uns dabei besonders relevant – und sind zugleich die wichtigsten Learnings:

1) Konkret zu formulieren, was wir wirklich wollen

KI ist besonders stark, wenn Aufgaben genau beschrieben sind. In der Praxis war es jedoch teilweise überraschend anspruchsvoll, den LLMs das gewünschte Verhalten so präzise zu vermitteln, dass wirklich die passende Lösung entsteht.

Konsequenz:  Wir haben weniger „einfach direkt implementiert“, sondern deutlich stärker in geschärfte Anforderungen, konkrete Beispiele sowie Use- und Edge Cases investiert.

2) Mehr Aufmerksamkeit für Seiteneffekte

Ein zweites, sehr praxisnahes Learning: Wenn wir an Stelle A im Code etwas geändert haben, konnte an Stelle B unerwartet etwas kaputtgehen. Das ist grundsätzlich ein bekanntes Thema in der Softwareentwicklung – durch KI-generierten Code und schnelleren Iterationen wird es jedoch noch relevanter.

Konsequenz: Wir haben spürbar mehr Zeit in Code Reviews und Tests investiert, um Stabilität und Wartbarkeit zuverlässig abzusichern.

3) Architektur bleibt Verantwortung des Teams

KI kann bei der Umsetzung sehr gut unterstützen. Architektur und Datenmodell haben wir jedoch bewusst selbst verantwortet und KI vor allem dort eingesetzt, wo sie zuverlässig beschleunigt: bei Umsetzung, Refactoring und Detailarbeit.

Fazit

Innerhalb weniger Wochen konnten wir ein modernes und übersichtliches Dashboard launchen, das unsere Prozesse effizient abbildet und genau auf unsere Anforderungen zugeschnitten ist. Was mit klassischer Vorgehensweise vermutlich Monate gedauert hätte, ließ sich so in deutlich kürzerer Zeit erreichen.

KI-gestützte Softwareentwicklung ist für uns kein Ersatz für Erfahrung, sondern vielmehr ein Hilfsmittel, das die bereits gewonnene Erfahrung verstärkt. Den größten Nutzen sehen wir dann, wenn KI nicht „einfach eingesetzt“ wird, sondern mit klaren Anforderungen, konsequenter Qualitätssicherung und Architekturverantwortung im Team zusammenspielt. So lässt sich die Entwicklungszeit deutlich reduzieren – bei gleichzeitig hoher Codequalität sowie stabilen, wartbaren Ergebnissen und das Wichtigste: Zufriedene Benutzerinnen und Benutzer.

https://spiritinprojects.com/wp-content/uploads/2026/05/Blogbeitrag_Florian_KI-SoftwareEntwicklung.png 450 800 Florian Gürtler https://spiritinprojects.com/wp-content/uploads/2020/04/sip_web_padding_10px_topbot.jpg Florian Gürtler2026-02-12 12:28:252026-05-07 13:29:35KI als Teil des Softwareentwicklungsprozesses: Schnellere Umsetzung – bei verlässlich hoher Code-Qualität
Retro-Wecker in kräftigem Orange mit klassischem Zifferblatt auf einem modernen Schreibtisch. Orangefarbene Büroaccessoires und ein weicher, unscharfer Hintergrund verbinden nostalgisches Design mit zeitgemäßem Arbeitsumfeld.

Eine Zeiterfassung, die Zeit frisst: Unser Power-Apps-Experiment

10. Februar 2026/von Stefan Hiermann

Als kleines Team aus drei Entwicklern, haben wir eine interne Zeiterfassungs-App entwickelt. Ziel war ein stabiles internes Tool, das sich sauber in unsere Systemlandschaft integriert und langfristig wartbar bleibt.

Da unser Unternehmen stark in Microsoft 365 integriert ist, haben wir uns für unsere – bis dato – aktuelle Zeiterfassung für Power Apps entschieden. Rückblickend war diese Entscheidung naheliegend – aber nicht effizient.

Warum Power Apps für uns zunächst sinnvoll war

Auf dem Papier bietet Power Apps viele Vorteile für Microsoft-365-nahe Organisationen. Azure Active Directory, Outlook, Teams und SharePoint sind direkt angebunden. Authentifizierung, Benutzerverwaltung und Rollenmodelle sind vorhanden und müssen nicht neu entworfen werden.

Genau diese Punkte haben uns überzeugt. Die Plattform versprach einen schnellen Einstieg, wenig Infrastrukturaufwand und eine niedrige Einstiegshürde – insbesondere für interne Anwendungen.

In der Praxis sah das jedoch anders aus.

Die Realität: Ein Jahr Einarbeitung in eine Low-Code-Welt

Die Entwicklung der Zeiterfassung in Power Apps war kein schneller Start.
Im Gegenteil: Es hat uns knapp ein Jahr gekostet, um die Plattform richtig zu entwickeln.

Der größte Zeitfaktor war nicht die fachliche Komplexität, sondern die Einarbeitung in:

  • die Denkweise von Power Apps,
  • die Limitierungen der Formeln und Komponenten,
  • die Eigenheiten von Power Automate,
  • und das Zusammenspiel der verschiedenen Microsoft-Werkzeuge.

Da man nicht direkt im Code arbeitet, sondern über die von Microsoft vorgegebenen Werkzeuge, Patterns und Abstraktionen, ist man stark eingeschränkt. Viele Dinge, die in klassischem Code trivial sind, lassen sich nur über Umwege oder gar nicht umsetzen.

Ein großer Teil der Entwicklungszeit floss nicht in fachliche Logik, sondern in das Verstehen und Umgehen der Plattformmechanismen.

Wenn Low-Code zum strukturellen Problem wird

Die Performance-Probleme von Power Apps waren kein schleichender Effekt, sondern von Beginn an vorhanden. Bereits beim Öffnen der Anwendung dauerte es spürbar lange, bis alle notwendigen Operationen, Abhängigkeiten und Initialisierungen geladen waren. Dieses Verhalten war unabhängig von Datenmenge oder Nutzung und zeigte klar die fehlende Effizienz des Frameworks.

Optimierung war kaum möglich, da wesentliche Abläufe außerhalb unseres Einflussbereichs lagen. Zusätzlich verschärften systemische Eigenheiten wie das automatische Deaktivieren inaktiver Power-Automate-Flows die Situation. Um produktive Prozesse stabil zu halten, mussten technische Workarounds implementiert werden, ohne fachlichen Mehrwert.

An diesem Punkt wurde deutlich: Unsere Entwicklungsarbeit richtete sich nicht mehr nach fachlichen Anforderungen, sondern nach Plattformgrenzen.

Der Vergleich: Drei Monate Django statt ein Jahr Power Apps

Der Wechsel war kein Experiment, sondern eine bewusste Entscheidung.
Wir haben die Zeiterfassung neu aufgebaut – dieses Mal mit Django in Python.

Die eigentliche Entwicklung der neuen Plattform dauerte rund drei Monate.

Trotz vollständiger Neuentwicklung waren wir deutlich schneller als mit Power Apps. Der Grund war einfach: Wir konnten wieder direkt im Code arbeiten. Architektur, Datenmodelle, Geschäftslogik und Performance lagen vollständig in unserer Hand.

Wir setzen dabei auf Prompt Driven Development als Produktivitätsverstärker. KI-gestützte Prompts unterstützen uns bei Standardlogik, Tests, Refactorings und Modellierung. Die technische Verantwortung bleibt jedoch klar beim Entwicklungsteam.

Die bestehende Power-App wurde nicht abrupt abgeschaltet. Die relevanten Daten wurden über Dataflows aus der Power-Apps-Welt entkoppelt und in eine eigenständige Datenbasis überführt. So konnten wir schrittweise migrieren, ohne den laufenden Betrieb zu gefährden.

Dieser Ansatz ermöglichte uns, die neue Plattform parallel aufzubauen und sukzessive zu übernehmen.

Microsoft-Integration ohne Low-Code

Mit dem Wechsel entfiel die implizite Microsoft-Integration von Power Apps. Authentifizierung, Benutzer-Synchronisation und Berechtigungen mussten explizit umgesetzt werden – etwa über Azure AD, OAuth und Microsoft Graph.

In der Praxis erwies sich dieser Aufwand als überschaubar und gut kontrollierbar. Statt impliziter Plattformlogik gibt es nun explizite Schnittstellen, klare Konfigurationen und nachvollziehbares Verhalten. Die Integration ist nicht schwieriger – sie ist transparenter und besser testbar.

Fazit: Low-Code kostet Zeit – klassischer Code spart sie

Power Apps hat uns keinen schnellen Start ermöglicht. Die Plattform erforderte eine lange Einarbeitung und zwang uns, in den Grenzen ihrer Werkzeuge zu denken.

Die Django-basierte Neuentwicklung war dagegen deutlich schneller, obwohl sie vollständig neu implementiert wurde. Direkter Code, klare Architektur und volle Kontrolle über das System haben sich als effizienter erwiesen als jede Low-Code-Abstraktion.

Heute entwickeln wir zielgerichteter, stabiler und nachhaltiger.
Unsere Zeiterfassung tut wieder das, was sie soll:
Zeit erfassen – nicht verbrauchen.

https://spiritinprojects.com/wp-content/uploads/2026/01/beitragsbild_Zeiterfassung.png 450 800 Stefan Hiermann https://spiritinprojects.com/wp-content/uploads/2020/04/sip_web_padding_10px_topbot.jpg Stefan Hiermann2026-02-10 12:00:152026-04-08 12:51:01Eine Zeiterfassung, die Zeit frisst: Unser Power-Apps-Experiment

AI Governance Schulung für E-Control

2. Februar 2026/von Patrik Mariel

Es ist wie mit jeder Technologie, die neu etabliert wird: Viele Unklarheiten bestehen in der Anwendung, das Verständnis über die Reichweite der Möglichkeiten ist nicht greifbar und oftmals wissen nur wenige Personen die Antworten, womit diese leicht mit Anfragen überlastet werden. Man kann versuchen, sich querzustellen und die Technologie zu vermeiden – „Es hat ja vorher auch schon super funktioniert!“ – doch wie weit man mit dieser Haltung kommen wird bzw. unternehmerischen Erfolg haben wird – das lasse ich Sie selbst beantworten.

Die Herausforderung

E-Control hat erkannt, dass die Verwendung von Künstlicher Intelligenz (KI), im Sinne von Sprachmodellen, ein riesiges Potenzial hat und die bisherigen internen Richtlinien für die Verwendung von KI eine Anpassung benötigen. Zusätzlich tritt die EU-KI-Verordnung (EU AI Act) schrittweise in Kraft. Der EU AI Act ist das weltweit erste umfassende Gesetz zur Regulierung von KI und legt verbindliche Regeln für Sicherheit, Transparenz und den Schutz der Grundrechte fest. Die Verordnung stellt konkrete Anforderungen an Unternehmen und Organisationen – darunter auch die Pflicht, alle Mitarbeiter:innen im Umgang mit KI angemessen zu schulen und weiterzubilden. Neben der Präsenzteilnahme wurde die KI-Schulung auch online angeboten und aufgezeichnet, sodass alle Personen unabhängig von ihrer Verfügbarkeit von den Inhalten profitieren konnten.

Unser Ansatz

Unser Anspruch bei dieser Schulung war es, allen teilnehmenden Personen eine ganzheitliche Betrachtungsweise zu vermitteln. Das Thema KI ist nämlich mit dieser Schulung nicht vorbei, sondern es entwickelt sich stetig fort. Genau deswegen möchten wir unsere eigenen Lehransätze den teilnehmenden Personen vermitteln, damit diese eigenständig im Nachgang wissen, welche Themen am relevantesten sind. Für E-Control selbst haben wir den Fokus auf behördliche Themen gesetzt und Use Cases für die Schulung vorbereitet. Somit wurden direkt die Grundlagen und das Verständnis für die Ergebnisse eine eines Sprachmodells besprochen und diskutiert. Wer selbst schon viel mit KI zu tun gehabt hat, der weiß, wie unterschiedlich die Ergebnisse sein können. Mit speziellen Techniken oder Leitfäden für das Prompt Engineering lassen sich die Ergebnisse mit sehr hoher Wahrscheinlichkeit verbessern. Neben dem positiven Potenzial beim Einsatz von KI, birgt die Technologie ebenso Risiken und Herausforderungen, die wir klar hervorgehoben haben, damit die teilnehmenden Personen darüber informiert sind. Bei E-Control selbst war der EU AI Act ein wichtiger Pfeiler in unserem Vortrag, weshalb diesem Thema mehr Zeit zugewandt wurde.

Der Nutzen

Spirit in Projects hat jahrelange Erfahrung bei der Ausarbeitung diverser Schulungen. Somit konnten wir schnell und professionell ein Konzept gemeinsam mit den Verantwortlichen von E-Control ausarbeiten. Die Anforderungen seitens E-Control konnten alle vollständig berücksichtigt werden. Die vorgetragenen Inhalte stießen bei den Teilnehmenden auf sehr gute Resonanz und wurden als hilfreich bewertet. Das Ziel war nicht, das Thema einmal zu besprechen und einen „Haken“ darunter zu setzen, sondern eine Grundlage zu schaffen, auf welcher E-Control nachhaltig aufbauen kann. Oftmals kommt es nicht auf die Abteilung an, denn der Einsatzbereich von KI ist größer als man denkt. Im Vordergrund steht hierbei immer der Mensch, der die Technologie verwendet und dafür geradesteht.

Möchten auch Sie KI in Ihrem Unternehmen klar strukturiert, rechtssicher und ohne Berührungsängste einführen? Wir unterstützten Sie gerne dabei, das volle Potenzial auszuschöpfen.

Jetzt Kontakt aufnehmen und Beratungstermin vereinbaren!

https://spiritinprojects.com/wp-content/uploads/2026/02/Bildschirmfoto-2026-02-02-um-15.52.35.png 404 1008 Patrik Mariel https://spiritinprojects.com/wp-content/uploads/2020/04/sip_web_padding_10px_topbot.jpg Patrik Mariel2026-02-02 14:58:052026-02-03 13:25:21AI Governance Schulung für E-Control
IREB LOGO

IREB ZERTIFIZIERUNG

19. Januar 2026/von Tanja Meszarits

In unserem vorherigen Blogbeitrag haben Sie bereits gelesen, dass wir seit Jänner 2026 IREB/CPRE Platinum-zertifiziert sind. Heute möchten wir tiefer in das Thema eintauchen und über die Ursprünge des IREB (International Requirements Engineering Board) berichten.

Das IREB ist aus der Vision entstanden, Requirements Engineering (RE) als eigenständige Disziplin international einheitlich, vergleichbar und professionell zu vermitteln – um Missverständnisse, Change Requests, Verzögerungen und ungeplante Mehrkosten in Projekten zu reduzieren.

Ausgangslage: Warum brauchte man Vereinheitlichung?

In den frühen 2000er-Jahren war Requirements Engineering zwar als Erfolgsfaktor in Projekten anerkannt, aber:

  • es gab keinen international einheitlichen Lehrplan,
  • die Ausbildung war stark heterogen (je nach Unternehmen, Hochschule, Trainer oder Methode),
  • viele Projekte litten unter unklaren, widersprüchlichen oder schlecht abgestimmten Anforderungen,
  • zudem fehlte ein vergleichbarer Kompetenznachweis für RE-Know-how.

Das führte in der Praxis zu einem zunehmenden Bedarf nach Standardisierung, den CEO Karl Schott erkannte. Er definierte, welche Mindestanforderungen „gutes“ Requirements Engineering erfüllen sollte – unabhängig davon, ob agil, klassisch oder hybrid gearbeitet wird. Darauf aufbauend gründete er 2003 das D-A-CH Board mit dem Ziel, einen einheitlichen Standard im deutschsprachigen Raum zu etablieren.

Gründung: Wie wurde das IREB ins Leben gerufen?

Auf Basis des D-A-CH Boards wurde in den Folgejahren das IREB als international ausgerichtete, unabhängige Organisation gegründet. Ziel war dabei weniger ein klassischer Mitgliedschaftsverband, sondern vor allem:

  • ein neutrales Gremium, das Inhalte abstimmt, 
  • die Definition eines öffentlich zugänglichen Grundwissens (Syllabus), 
  • die Vergabe darauf aufbauender Zertifizierungen.

Wie ging es dann weiter?

Da das IREB großen Anklang fand, wurde es weiter internationalisiert und verbreitet. Es entstanden ein einheitlicher Syllabus sowie standardisierte Prüfungsfragen, die über internationale Trainings- und Prüfungsnetzwerke ausgerollt wurden. Seitdem gilt IREB in vielen Unternehmen als anerkannter Qualifikationsstandard – unter anderem für Business Analyst:innen, Requirements Engineers, Product Owner und weitere Rollen.

Wir sind stolz darauf, als einer der führenden IREB-Partner in Österreich RE-Kurse anzubieten. Unsere aktuellen Kurse finden Sie hier:
https://spiritinprojects.com/requirements-engineer/

https://spiritinprojects.com/wp-content/uploads/2026/01/IREB-LOGO-.png 436 820 Tanja Meszarits https://spiritinprojects.com/wp-content/uploads/2020/04/sip_web_padding_10px_topbot.jpg Tanja Meszarits2026-01-19 15:55:372026-01-20 14:55:12IREB ZERTIFIZIERUNG
IREB CPRE Platinum 2026

IREB / CPRE PLATINUM ZERTIFIZIERUNG!

15. Januar 2026/von Tanja Meszarits

IREB / CPRE PLATINUM ZERTIFIZIERUNG!

Seit Anfang des Jahres sind wir bei Spirit in Projects IREB/CPRE Platinum zertifiziert.

Damit legen wir nicht nur mit unseren Trainings den Grundstein für eine IREB/CPRE Zertifizierung für unsere TeilnehmerInnen, sondern haben uns unsere In-House Kompetenzen jetzt auch offiziell zertifizieren lassen. Uns war wichtig, ein sichtbares Zeichen nach außen zu setzen.

Unsere Mitarbeiter – Spezialisten im RE

Wir sind sehr stolz darauf, denn diese Auszeichnung steht vor allem für eines: gelebte Requirements-Engineering-Kompetenz innerhalb unseres Teams. Die IREB/CRPE Zertifikate legen dar, wie viele Mitarbeitende eines Unternehmens selbst eine IREB Zertifizierung haben. Bei uns so viele, dass wir die Platinum – und damit höchste – Ebene erreichen konnten. Für unsere Kunden und Kundinnen bedeutet das, dass wir leben, was wir „lehren“ = RE-Kompetenz auf höchstem Niveau. Gleichzeitig geben wir unser Wissen weiter: Als Trainingsanbieter bieten wir praxisnahe Schulungen im Requirements Engineering an, mit denen sich Teilnehmende gezielt auf eine IREB/CPRE-Zertifizierung vorbereiten können.

Über IREB/CRPE

CPRE (Certified Professional for Requirements Engineering) – ist eine weltweit anerkannte Personenzertifizierung im RE Bereich. Das Zertifikat ist ein anerkannter Nachweis der Fähigkeiten und dokumentiert den erforderlichen Wissensstand und somit ein Garant für hohe Qualität.

Es ist ein vierstufiges Zertifizierungsprogramm, das jede Stufe mit einem eigenen Zertifikat abschließt und Wissen um den professionellen Umgang mit Anforderungen dokumentiert.  

Das Zertifikat ist:

  1. Ein Zertifikat mit lebenslanger Gültigkeit
  2. Praxisrelevant
  3. International anerkannt und geschätzt
  4. Mitbewerbs-Vorteil am Arbeitsmarkt

Gründungsmitglied Karl Schott
Wussten Sie, dass…

… Spirit in Projects von Anfang an mit der IREB®-Zertifizierung verbunden ist? Geschäftsführer und Gründungsmitglied von Spirit in Projects Karl Schott wollte das Berufsbild des Requirements Engineer professionalisieren und gründete 2003 das D-A-CH RE Board. Später ist daraus das weltweit agierende International Requirements Engineering Board (IREB®) entstanden.

Heute sind weltweit mehr als 90.000 Personen in 102 Ländern im Bereich des Certified Professional Requirements Engineering zertifiziert worden. Spirit in Projects ist der führende Anbieter dieser internationalen Zertifizierung in Österreich und international einer der top Trainingsprovider und Berater. Als erstes Unternehmen weltweit haben wir Trainings zu den Advanced Levels der IREB®-Zertifizierung angeboten und durchgeführt.

Vorteil für unsere Kunden

Unser Anspruch bleibt dabei klar: (Projekt-) Anforderungen so zu erheben, zu strukturieren und abzusichern, dass Projekte erfolgreicher werden – mit weniger Missverständnissen, weniger Rework und mehr Klarheit für alle Beteiligten.

https://spiritinprojects.com/wp-content/uploads/2026/01/800x450.png 450 800 Tanja Meszarits https://spiritinprojects.com/wp-content/uploads/2020/04/sip_web_padding_10px_topbot.jpg Tanja Meszarits2026-01-15 09:20:502026-04-29 13:51:52IREB / CPRE PLATINUM ZERTIFIZIERUNG!
Agiles Arbeiten

Einführung des Scaled Agile Framework SAFe: Agile Transformation bei AGES

3. Dezember 2025/von Tanja Meszarits

Die Österreichische Agentur für Gesundheit und Ernährungssicherheit (AGES) ist ein Unternehmen der Republik Österreich. Seit über 20 Jahren steht die AGES im Einsatz für die Gesundheit von Mensch, Tier und Pflanzen. Dabei nimmt sie unterschiedlichste gesetzlich festgelegte Aufgaben wahr – etwa im Bereich der Lebensmittel- und Arzneimittelsicherheit oder der Tiergesundheit.

Die Herausforderung

Die AGES betreibt eine Reihe von IT-Systemen, um ihren Aufgaben nachzukommen. Im Bereich der Softwareentwicklung wurden schon länger SCRUM-Methoden eingesetzt. Nach der erfolgreichen Teilnahme an einem Seminar von Spirit in Projects zum Scaled Agile Framework (SAFe) beschloss das Management der AGES, im Unternehmen zukünftig Methoden zur Skalierung von Agilität umzusetzen.

Mit einer Unternehmensgröße von über 1750 Mitarbeitenden und 10 Standorten ergab sich für die nachhaltige Integration in der Organisation eine durchaus beachtenswerte Herausforderung. In enger Zusammenarbeit mit dem Auftraggeber wurde von Spirit in Projects ein umfassendes Coaching- und Mentoring-Programm entwickelt, um die Integration der SAFe-Elemente in die Organisationsstruktur effektiv zu unterstützen.

Unser Ansatz

Bereits zu Anfang war klar, dass ein blindes Ausrollen des „Standard“-SAFe-Frameworks nicht infrage kommen würde. Hier war die umfassende Erfahrung von Spirit in Projects mit agilen Frameworks in unterschiedlichen Unternehmens- und Trainingskontexten nützlich. Im Zuge einer strategischen Beratung wurden geeignete Methoden aus SAFe identifiziert, die in weiterer Folge speziell auf die Bedürfnisse der AGES zugeschnitten werden sollten. Für das gesamte Projekt plante Spirit in Projects ein agiles Vorgehen in enger Abstimmung mit der Auftraggeberin.

Für die praktische Umsetzung bot Spirit in Projects gezielte Hands-on-Unterstützung bei der Einführung und Umsetzung des SAFe-Frameworks, von der initialen Konzeption bis hin zur operativen Durchführung.

Besonderes Augenmerk wurde auf Coaching- und Mentoring-Maßnahmen von einzelnen Mitarbeitenden und Teams gelegt. Diese wurden dabei unterstützt, die für das SAFe-Framework erforderlichen Rollen effektiv zu übernehmen und auszufüllen. Mit ihrer Expertise standen die Spirit-Consultants als Sparringpartner für fachliche und methodische Fragen zur Verfügung – immer mit dem Ziel, ein Verständnis der agilen Prinzipien und Praktiken zu vermitteln, um eigenständig Lösungen für zukünftige Herausforderungen zu entwickeln. Gemeinsam mit Entwicklungsteams wurden agile Praktiken wie SCRUM, Kanban und der Built-In-Quality-Ansatzes noch stärker etabliert, um den Produktentwicklungsprozess zu optimieren.

Für das Framework wurden relevante KPIs entwickelt und im Projekt implementiert, um eine Steuerung der Organisation zu ermöglichen. Dies erfolgte in enger Abstimmung mit dem organisatorischen Kernteam (Lean-Agile Change Agents) zur Festlegung von Zielsetzungen und nächsten Schritten.

Der Nutzen

Die über ein Jahr laufende Begleitung durch Spirit in Projects im Zuge der Implementierung von SAFe ermöglichte es den Mitarbeitenden der AGES, neue Methoden und Techniken effektiv anzuwenden und ihre Arbeitsprozesse kritisch zu reflektieren. Die Unterstützung bei der Auswahl und Anwendung der Methoden sowie das gezielte Feedback trugen signifikant zur Steigerung von Qualität, Struktur, Effizienz und Effektivität bei.

Die intensive Begleitung durch Planungsworkshops und Retrospektiven sowie individuelles Coaching vertiefte das Verständnis und die Anwendung der SAFe-Methodik. Zusätzlich wurde ein praxisorientierter Leitfaden für die Methoden entwickelt, und die Kommunikationsstrukturen sowie das Reporting innerhalb der AGES wurden optimiert.

Den Erfolg bescheinigt auch der Leiter der AGES IT-Services, Ing. Gottfried Scheck, BSc MSc: „Die Umsetzung und Begleitung der Transformation von SCRUM in das SAFe-Framework wurde zur vollsten Zufriedenheit umgesetzt. Neben der methodischen Unterstützung wurden die erforderlichen organisatorischen Anpassungen begleitet und unterstützt.“

Möchten auch Sie in Ihrem Unternehmen den nächsten Schritt gehen und von der Skalierung agiler Methoden profitieren? Wir bieten zum Thema Scaled Agile spezialisierte Trainingsangebote an und beraten Sie gerne mit unserem praxiserprobten Wissen zur Wahl der geeigneten Frameworks und Umsetzung für Ihr Business. Kontaktieren Sie uns – wir beraten Sie gerne!

https://spiritinprojects.com/wp-content/uploads/2025/12/confident-businesswomen-writing-.jpg 450 800 Tanja Meszarits https://spiritinprojects.com/wp-content/uploads/2020/04/sip_web_padding_10px_topbot.jpg Tanja Meszarits2025-12-03 09:17:112026-01-19 15:47:02Einführung des Scaled Agile Framework SAFe: Agile Transformation bei AGES
Seite 2 von 3123

Kontaktieren Sie uns!

Schicken Sie uns eine Nachricht per Kontaktformular.
  • Mail
  • Xing
  • Linkedin
© Copyright - Spirit in Projects - Enabling digital innovation
  • Trainings / AKADEMIE
  • AGB
  • Impressum
  • Datenschutz
  • Barrierefreiheitserklärung
  • Jobs
  • Kontakt
Nach oben scrollen Nach oben scrollen Nach oben scrollen

Diese Seite verwendet ausschließlich technisch notwendige Cookies. Es werden keine Drittanbieterdienste verwendet.

Schließen

Cookie- und Datenschutzeinstellungen



Wie wir Cookies verwenden

Wir können Cookies anfordern, die auf Ihrem Gerät eingestellt werden. Wir verwenden Cookies, um uns mitzuteilen, wenn Sie unsere Websites besuchen, wie Sie mit uns interagieren, Ihre Nutzererfahrung verbessern und Ihre Beziehung zu unserer Website anpassen.

Klicken Sie auf die verschiedenen Kategorienüberschriften, um mehr zu erfahren. Sie können auch einige Ihrer Einstellungen ändern. Beachten Sie, dass das Blockieren einiger Arten von Cookies Auswirkungen auf Ihre Erfahrung auf unseren Websites und auf die Dienste haben kann, die wir anbieten können.

Notwendige Website Cookies

Diese Cookies sind unbedingt erforderlich, um Ihnen die auf unserer Webseite verfügbaren Dienste und Funktionen zur Verfügung zu stellen.

Da diese Cookies für die auf unserer Webseite verfügbaren Dienste und Funktionen unbedingt erforderlich sind, hat die Ablehnung Auswirkungen auf die Funktionsweise unserer Webseite. Sie können Cookies jederzeit blockieren oder löschen, indem Sie Ihre Browsereinstellungen ändern und das Blockieren aller Cookies auf dieser Webseite erzwingen. Sie werden jedoch immer aufgefordert, Cookies zu akzeptieren / abzulehnen, wenn Sie unsere Website erneut besuchen.

Wir respektieren es voll und ganz, wenn Sie Cookies ablehnen möchten. Um zu vermeiden, dass Sie immer wieder nach Cookies gefragt werden, erlauben Sie uns bitte, einen Cookie für Ihre Einstellungen zu speichern. Sie können sich jederzeit abmelden oder andere Cookies zulassen, um unsere Dienste vollumfänglich nutzen zu können. Wenn Sie Cookies ablehnen, werden alle gesetzten Cookies auf unserer Domain entfernt.

Wir stellen Ihnen eine Liste der von Ihrem Computer auf unserer Domain gespeicherten Cookies zur Verfügung. Aus Sicherheitsgründen können wie Ihnen keine Cookies anzeigen, die von anderen Domains gespeichert werden. Diese können Sie in den Sicherheitseinstellungen Ihres Browsers einsehen.

Andere externe Dienste

Wir nutzen auch verschiedene externe Dienste wie Google Webfonts, Google Maps und externe Videoanbieter. Da diese Anbieter möglicherweise personenbezogene Daten von Ihnen speichern, können Sie diese hier deaktivieren. Bitte beachten Sie, dass eine Deaktivierung dieser Cookies die Funktionalität und das Aussehen unserer Webseite erheblich beeinträchtigen kann. Die Änderungen werden nach einem Neuladen der Seite wirksam.

Google Webfont Einstellungen:

Google Maps Einstellungen:

Google reCaptcha Einstellungen:

Vimeo und YouTube Einstellungen:

Datenschutzrichtlinie

Sie können unsere Cookies und Datenschutzeinstellungen im Detail in unseren Datenschutzrichtlinie nachlesen.

Datenschutz
Schließen