KI-Deployment-Modelle: Welche Lösung passt zu Ihrem Unternehmen?

Die richtige Deployment-Strategie für Ihre KI-Anwendungen

Die Nutzung von Künstlicher Intelligenz bietet enorme Potenziale für Unternehmen – doch die Wahl des richtigen Deployment-Modells ist entscheidend für den Erfolg. Soll die KI lokal am eigenen Rechner laufen, auf einem Server im eigenen Rechenzentrum, über spezialisierte Dienste wie OpenRouter oder direkt über APIs der Anbieter? Jede Option hat ihre eigenen Vor- und Nachteile. In diesem Beitrag stellen wir die wichtigsten Deployment-Modelle vor und zeigen, welche Lösung sich für welche Anforderungen eignet.

1. Lokale KI am eigenen Rechner

Beschreibung

Bei diesem Modell werden KI-Modelle direkt auf der Hardware des Nutzers ausgeführt – sei es auf dem Desktop-PC, Laptop oder einer dedizierten Workstation. Tools wie Ollama oder LM Studio ermöglichen die einfache Installation und Nutzung von Open-Source-Modellen wie Llama, Mistral oder DeepSeek.

Vorteile

Neben dem maximalen Datenschutz ist ein weiterer wesentlicher Faktor, dass keine laufenden Kosten anfallen. Die Nutzung kann auch offline erfolgen und unterliegt keiner externen Filterung. Man behält die volle Kontrolle und durch die geringe Latenz erzielt man – bei geeigneter Hardware – schnelle Reaktionszeiten. 

Nachteile

Die Nachteile sind neben hohen Anforderungen an Hardware (moderne GPU erforderlich: z.B. Nvidia RTX 4080 mit 16+ GB VRAM), eine begrenzte Modellgröße und auch erforderliches technisches Know-how in House. Die Anwendungen sind nicht automatisch skalierbar, also auf die locale Hardware-Kapazität begrenzt und haben einen erhöhten Wartungsaufwand. 

Typische Anwendungsfälle

  • Persönliche Assistenten für sensible Aufgaben (darunter fällt auch die SW-Entwicklung kritischer Systeme)
  • Entwicklung und Prototyping von KI-Anwendungen
  • Verarbeitung hochsensibler oder vertraulicher Daten
  • Offline-Einsatzszenarien (z.B. im Feld)

Für wen geeignet?

Lokale KI sind daher geeignet für Einzelpersonen und kleine Teams mit technischem Know-how, datenschutzbewusste Nutzer in regulierten Branchen,  Entwickler, die experimentieren und anpassen möchten, sowie Unternehmen mit sporadischem KI-Bedarf und geringem Volumen.


2. On-Premise im eigenen Rechenzentrum

Beschreibung

KI-Modelle werden auf eigenen Servern im Unternehmen gehostet. Dies kann von einzelnen KI-Appliances bis zu kompletten GPU-Server-Clustern reichen. Die Infrastruktur wird dabei vollständig intern verwaltet. Manche KI-Appliances verwenden allerdings proprietäre Software. Zumeist werden Open Source Modelle oder selbstentwickelte Modelle eingesetzt, es können aber auch Closed-Source Modelle lizensiert und eingesetzt werden.

Vorteile

On-Premise Lösungen halten die digitale Souveränität, bieten hohe Sicherheit, haben vorhersagbare Kosten und keine Bandbreitenbeschränkungen. Sie sind in ihrem Volumen skalierbar und bieten eine langfristige Kosteneffizienz. 

Nachteile

On-Premise Lösungen bieten neben den genannten Vorteilen auch Nachteile durch eine hohe Anfangsinvestition, erforderliche IT-Expertise, haben dadurch längere Implementierungszeit eine begrenzte Elastizität und eine gesteigerte Verantwortung für Updates.

Typische Anwendungsfälle

  • Automatisierte Dokumentenanalyse (z.B. Contract Review)
  • Massenhafte Dokumentenverarbeitung (z.B. Rechnungsverarbeitung)
  • Screening und Analysen von sensiblen Unternehmensdaten
  • KI-gestützte Videoüberwachung und -analyse
  • Interne Wissensdatenbanken und Enterprise Search

Für wen geeignet?

Diese Lösung ist gut geeignet für mittelständische bis große Unternehmen mit konstantem, hohem KI-Bedarf in regulierten Branchen, sowie Organisationen mit strengen Compliance-Anforderungen (DSGVO, NIS2) und Unternehmen mit etablierter IT-Infrastruktur und Rechenzentrums-Expertise.


3. Cloud-basierte API-Dienste (Direkt)

Beschreibung

Direkte Nutzung von KI-Modellen über die APIs der Anbieter wie OpenAI (GPT-5), Anthropic (Claude), Google (Gemini) oder Mistral AI. Der Zugriff erfolgt per API-Schlüssel die Abrechnung nach Nutzung (Pay-per-Token).

Vorteile

Die Vorteile sind neben einer sofortigen Verfügbarkeit, dass es keine Infrastruktur-Verwaltung benötigt und, dass man Zugriff auf neueste Modelle erhält. Eine flexible Skalierung ist möglich, die Einstiegshürden sind niedrig und die Anfangsinvestition ist gering. 

Nachteile

Cloud-basierte Lösungen tragen laufende Kosten (bei hohem Volumen können API-Gebühren stark steigen), es können Datenschutzbedenken bestehen und gegebenenfalls ein Vendor Lock-in-Risiko. Die potenzielle Latenz ist netzwerkabhängig und daher nicht ideal für Echtzeit-Anwendungen. Darüberhinaus bestehen begrenzte Anpassungsmöglichkeiten (keine Kontrolle und oftmals auch keine Transparenz über Modellverhalten oder -filterung).

Typische Anwendungsfälle

  • Chatbots und Customer Support
  • Content-Generierung (Marketing, Social Media)
  • Übersetzungen und Textverarbeitung
  • Schnelle Prototypen und MVP-Entwicklung
  • Sporadische oder experimentelle KI-Nutzung

Für wen geeignet?

Diese Lösung ist ideal für Startups und kleine Unternehmen ohne IT-Infrastruktur, Projekte in der Proof-of-Concept-Phase, für Teams mit variablen oder unvorhersehbaren Workloads, sowie für die Anwendungen mit nicht-sensiblen Daten.


4. Aggregations-Dienste (OpenRouter, Portkey, etc.)

Beschreibung

Plattformen wie OpenRouter bieten einen einheitlichen Zugang zu über 300+ KI-Modellen verschiedener Anbieter. Statt mehrere API-Schlüssel zu verwalten, nutzen Sie eine standardisierte Schnittstelle mit automatischem Fallback und Routing.

Vorteile

Dieser Zugang bietet Unabhängigkeit von einem einzelnen Anbieter, da der Zugriff auf 300+ Modelle über eine API möglich ist. Automatische Fallbacks – bei Ausfall eines Anbieters wechselt das System automatisch – sind möglich, die Integration wird vereinfacht, durch transparentes Routing wird automatisch das günstigsten/schnellsten Modells gewählt.  Dieses System ist experimentierfreundlich und man benötigt lediglich einen API-Schlüssel für alles – von der zentralen Verwaltung hin zur Abrechnung.

Nachteile

Der Nachteil liegt in dem gesteigerten Preis da 10-15% Aufschlag auf die Original-API-Kosten verrechnet werden können. Es kann durch durch die zusätzliche Latenz zu minimalen Verzögerungen kommen, das System ist abhängig vom Aggregator und der Datenschutz ist durch eine zusätzliche Instanz, durch die die Daten fließen, gefordert. 

Typische Anwendungsfälle

  • Multi-Modell-Anwendungen (verschiedene Modelle für verschiedene Tasks)
  • Evaluierung und Benchmarking verschiedener Modelle
  • Entwicklung flexibler KI-Assistenten
  • Rapid Prototyping mit Model-Switching

Für wen geeignet?

Diese Lösung ist primär für Entwicklung und Tech-Teams, die Flexibilität schätzen, geeignet, aber auch für Unternehmen mit wechselnsen Anforderungen, sowie Projekte, die mehrere Modelle parallel nutzen und Teams, die Vendor Lock-in vermeiden wollen. 


5. Hybrid-Deployment

Beschreibung

Kombination mehrerer Ansätze: Sensible Daten werden lokal oder on-premise verarbeitet, während weniger kritische Workloads in die Cloud ausgelagert werden. Tools wie Microsoft Azure ML oder AWS SageMaker unterstützen hybride Architekturen.

Vorteile

Der größte Vorteil, den das hybride Modell bietet ist, dass das beste aus beiden Welten kombiniert wird – die Flexibilität der Cloud und die Sicherheit von On-Premise Modellen. Darüberhinaus bietet es eine optimierte Kostenstruktur, ist Compliance-konform, skalierbar und bietet eine hohe Redundanz durch Verteilung. 

Nachteile

Zu den Nachteilen zählen neben einer höheren Komplexität auch ein erhöhter Integrations-Aufwand. Auch durch die zu erwartetende Redundanz kann es zu höheren Kosten kommen.

Typische Anwendungsfälle

  • Finanzinstitute mit Mischung aus sensiblen und öffentlichen Daten
  • Healthcare-Organisationen (Patientendaten on-premise, Forschung in Cloud)
  • Enterprise AI mit saisonalen Schwankungen

Für wen geeignet?

Das Hybridmodell ist für große Unternehmen mit komplexen Anforderungen, in Branchen mit teilweise sensiblen Daten und Organisationen in Transformationsphasen gut geeignet. 


6. Integrierte KI in Applikationen (AI as a Service)

Beschreibung

KI-Funktionen werden direkt in bestehende Software-Produkte integriert, z.B. über Microsoft Copilot, Salesforce Einstein, GitHub Copilot oder spezialisierte Branchen-Lösungen. Die KI ist für den Nutzer unsichtbar in den Workflow eingebettet.

Vorteile

Die Vorteile sind eine nahtlose Nutzererfahrung, bei der keine separate Plattform erforderlich sind, es besteht ein Kontextbewusstsein, da die KI Zugriff auf relevante Unternehmensdaten hat. Die Einführung ist erleichtert und benötigt keine aufwendige technische Integration. Kontinuierliche Updates, sowie Support sind ohne Mehrkosten im Paket enthalten.

Nachteile

Der große Nachteil ist das Vendor Lock-in, eine begrenzte Anpassbarkeit, oftmals  Zusatzkosten durch Premium-Features mit Aufpreis sowie Bedenken hinsichtlich des Datenschutzes, da Daten vom Plattform-Anbieter verarbeitet werden. 

Typische Anwendungsfälle

  • Code-Vervollständigung in IDEs (GitHub Copilot)
  • CRM-Assistenz und Sales-Insights (Salesforce Einstein)
  • Automatisierte Büroaufgaben (Microsoft 365 Copilot)
  • E-Mail-Intelligenz und Meeting-Zusammenfassungen

Für wen geeignet?

Integrierte KI in Applikationen sind für Unternehmen, die bereits die Basis-Plattform nutzen geeigent, ebenso wie für Non-Tech-Nutzer ohne KI-Expertise und Teams, die schnelle, unkomplizierte KI-Unterstützung wollen.

Vergleichstabelle: Deployment-Modelle im Überblick


Fazit: Es gibt nicht die “eine” richtige Lösung

Die Wahl des optimalen KI-Deployment-Modells hängt stark von den spezifischen Anforderungen ab. Während Cloud-APIs einen niedrigschwelligen Einstieg bieten, sind On-Premise-Lösungen für datenintensive, regulierte Branchen oft langfristig wirtschaftlicher und sicherer. Hybride Ansätze vereinen die Vorteile beider Welten, erfordern jedoch mehr Komplexität in der Verwaltung.

Unsere Empfehlung:

1. Starten Sie mit einer klaren Analyse Ihrer Anforderungen: Datenschutz, Volumen, Budget, technische Expertise 

2. Beginnen Sie klein: PoC mit Cloud-APIs, um die Machbarkeit zu testen 

3. Evaluieren Sie langfristig: Bei steigendem Volumen (>50 Mio. Tokens/Monat) prüfen Sie On-Premise Lösungen

4. Planen Sie Flexibilität ein: Vermeidung von früher Festlegung auf einen Anbieter 

5. Denken Sie an Compliance: In regulierten Branchen sollten von Anfang an lokale oder On-Premise-Optionen bevorzugt werden

Was ist NIS 2 – und warum betrifft es (fast) alle?

Die neue EU-Richtlinie NIS 2 verändert die Spielregeln für IT-Sicherheit in Europa. Seit Oktober 2024 müssen Mitgliedstaaten sie in nationales Recht umgesetzt haben. Sie verpflichtet Unternehmen und Behörden, ihre Cyber-Sicherheit systematisch zu organisieren – mit klaren Prozessen, Meldepflichten und Verantwortung auf Management-Ebene.

Für viele Organisationen kommt das einer Zeitenwende gleich: Was früher „Best Practice“ war, wird jetzt Pflicht. Und betroffen sind weit mehr Einrichtungen als bisher – von Energieversorgern über Stadtwerke und Krankenhäuser bis hin zu IT-Dienstleistern und Gemeinden.

Was steckt hinter NIS 2?

NIS 2 steht für „Network and Information Security Directive 2“. Sie ersetzt die erste NIS-Richtlinie aus dem Jahr 2016 und verfolgt ein klares Ziel:

Ein hohes, einheitliches Cyber-Sicherheitsniveau in der gesamten EU.

Neu ist der deutlich erweiterte Anwendungsbereich und die verbindliche Haftung für das Management. NIS 2 soll sicherstellen, dass nicht nur technische Abwehrmaßnahmen vorhanden sind, sondern auch Governance, Risikomanagement und Lieferkettenkontrolle gelebt werden.

Die Richtlinie ist seit 16. Jänner 2023 in Kraft.

  • In Deutschland wurde das NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG) im Sommer 2025 beschlossen.
  • In Österreich verzögerte sich die Novelle des NIS-Gesetzes (NISG); eine neue Fassung ist für 2025 in Vorbereitung.

Selbst wenn nationale Gesetze noch in Arbeit sind, gilt: Die Anforderungen stehen fest. Organisationen, die jetzt handeln, sichern sich wertvolle Zeit und Compliance-Vorsprung.

Was verlangt NIS 2 konkret?

Der Kern der Richtlinie besteht aus zehn verpflichtenden Sicherheits- und Organisationsmaßnahmen, die alle betroffenen Einrichtungen umsetzen müssen:

  1. Risikoanalyse & Sicherheitsstrategie
  2. Incident-Handling – Erkennung, Reaktion, Wiederherstellung
  3. Business Continuity & Backup-Management
  4. Lieferkettensicherheit
  5. Sichere Entwicklung & Wartung (inkl. Schwachstellenmanagement)
  6. Wirksamkeitsbewertung der Sicherheitsmaßnahmen
  7. Cyber-Hygiene & Schulungen
  8. Zugriffs- und Identitätsmanagement
  9. Kryptographie & Verschlüsselungsrichtlinien
  10. Richtlinien für System- und Netzwerksicherheit

Hinzu kommt eine strenge Meldepflicht bei Sicherheitsvorfällen, die sogenannte 24/72/30-Regel:

  • Innerhalb von 24 Stunden: „Early Warning“ an Behörde oder CSIRT
  • Innerhalb von 72 Stunden: Incident-Meldung mit Erstbewertung
  • Spätestens nach 30 Tagen: Abschluss- oder Fortschrittsbericht

Management in der Verantwortung

Eine der gravierendsten Änderungen betrifft die Geschäftsleitung.

Nach Artikel 20 NIS 2 muss das Management:

  • das Sicherheits-Risikomanagement genehmigen und überwachen,
  • geeignete Maßnahmen einführen und
  • regelmäßig an Schulungen teilnehmen.

Bei Verstößen drohen empfindliche Geldstrafen – und persönliche Haftung der Leitungsebene:

  • Essential Entities: bis 10 Mio. € oder 2 % des weltweiten Jahresumsatzes
  • Important Entities: bis 7 Mio. € oder 1,4 % des Umsatzes

Damit wird Cybersicherheit zur Chefsache – vergleichbar mit Arbeitssicherheit oder Datenschutz.

Bin ich betroffen? – Der schnelle Selbstcheck

  1. Tätig in einem der 18 Sektoren laut NIS 2?
  2. Mehr als 50 Mitarbeitende oder > 10 Mio. € Umsatz?
  3. Erbringe ich kritische Dienstleistungen für Bürger:innen oder Wirtschaft?
  4. Bin ich Lieferant eines betroffenen Unternehmens oder einer Behörde?
  5. Habe ich dokumentierte Prozesse für Risiko- und Incident-Management?

Wenn Sie eine dieser Fragen mit Ja beantworten, ist Ihre Organisation höchstwahrscheinlich im Scope von NIS 2.

Was jetzt zu tun ist

  1. Gap-Analyse durchführen: Welche Anforderungen sind bereits erfüllt, welche fehlen?
  2. Governance anpassen: Rollen, Verantwortlichkeiten, Freigabeprozesse.
  3. Incident-Playbook erstellen: klare Meldewege und Eskalationsstufen.
  4. Lieferantenverträge prüfen: Cyber-Sicherheitsanforderungen verankern.
  5. Management & Mitarbeitende schulen: Bewusstsein schaffen, Haftung vermeiden.

Fazit

NIS 2 ist weit mehr als ein Regulierungsthema – es ist ein Impuls für professionelles Sicherheits- und Risikomanagement.

Organisationen, die heute beginnen, gewinnen nicht nur Rechtssicherheit, sondern auch Vertrauen und Resilienz in einer zunehmend digitalen Welt.

NIS 2 ist gekommen, um zu bleiben – wer jetzt startet, ist im Vorteil.

Ihr erster Schritt

NIS-2 Readiness-Check

Unsere Expert:innen analysieren den Reifegrad Ihrer Organisation – konkret, praxisnah und vertraulich.

Anforderungen an KI-Systeme: Wie ein durchdachtes Vorgehensmodell Projekte zum Erfolg führt 

Spirit in Projects begleitet seit Jahren Unternehmen und öffentliche Auftraggeber bei der Konzeption, Ausschreibung und Umsetzung von KI-Systemen. Dabei hat sich eines immer wieder bestätigt: Ein strukturiertes, daten- und nutzenorientiertes Vorgehensmodell ist der Schlüssel zum Erfolg – unabhängig davon, ob das Projekt nach V-Modell XT, Scrum oder einem individuellen Hybridmodell abläuft. 

Viele KI-Projekte scheitern nicht an der Technologie – sondern am fehlenden methodischen Vorgehen bei der Anforderungserhebung und der Umsetzung. 

Vom Bauchgefühl zur strukturierten Anforderung 

In klassischen Projekten reichen oft Lastenhefte mit klaren Funktionalitäten – bei KI-Systemen funktioniert das so nicht. Hier braucht es einen anderen Denkansatz: 

  • Was ist das eigentliche Erkenntnisziel der KI? 
  • Welche Daten stehen wirklich zur Verfügung? 
  • Wie genau muss ein Modell sein, um den späteren Mehrwert zu liefern? 

Wir nutzen dafür intern einen methodischen Rahmen, der sich stark am CRISP-DM-Modell orientiert – angepasst auf moderne KI-Projekte mit Anforderungen wie MLOps, Re-Training und kontinuierlicher Verbesserung. Dieses Modell strukturiert unsere Workshops und Interviews mit Stakeholdern – vom Business Understanding über Data Understanding bis hin zu konkreten Evaluierungskriterien für KI-Modelle. 

Vorgehen mit Plan – auch im agilen oder klassischen Kontext 

Unsere Kunden arbeiten mit unterschiedlichen Vorgehensmodellen: Manche setzen auf Scrum, andere auf das V-Modell XT. Für KI-Projekte empfiehlt sich jedoch, zusätzlich eine KI-spezifische Struktur zu verwenden. Wir integrieren dazu unsere CRISP-DM-basierte Logik in das bestehende Rahmenwerk: 

  • In agilen Projekten bringt sie Ordnung in explorative Datenarbeit. 
  • Im klassischen Umfeld (z. B. öffentlicher Ausschreibungen) dient sie als inhaltlicher Bauplan für KI-spezifische Anforderungen. 

Entscheidend ist: Wir schaffen eine gemeinsame Sprache zwischen Fachbereich, Data Scientists und IT – und sorgen dafür, dass Anforderungen nicht nur geschrieben, sondern auch verstanden und später überprüfbar gemacht werden. 

Anforderungen brauchen Iterationen – und Daten 

Ein weiterer Praxisleitsatz: KI-Anforderungen entstehen nicht auf dem weißen Blatt Papier, sondern durch Iteration, Diskussion – und durch das, was die Daten hergeben. Ein ideales Vorgehensmodell berücksichtigt genau das: 

  • Datenexploration führt oft zu neuen Erkenntnissen, die Anforderungen verändern. 
  • Modelltests zeigen, ob eine Zielgenauigkeit realistisch ist – oder ob nachjustiert werden muss. 
  • Die Rückkopplungsschleifen mit den Stakeholdern sind nicht lästig, sondern wertvoll. 

In unseren Projekten haben wir diese Schleifen bewusst eingeplant – nicht als Ausnahme, sondern als Regel. Das erhöht nicht nur die Qualität der Ergebnisse, sondern auch die Akzeptanz beim späteren Einsatz. 

Fazit: Struktur gibt Sicherheit 

Ein KI-Projekt ohne strukturiertes Vorgehen ist wie ein Flug ohne Flugplan – man kommt selten dort an, wo man hinwollte. Mit einem durchdachten, auf KI abgestimmten Vorgehensmodell helfen wir unseren Kunden, frühzeitig Klarheit zu schaffen, realistische Anforderungen zu definieren und belastbare Ausschreibungen aufzusetzen.

Anforderungen an KI-Systeme: Warum sie anders sind als bei klassischen Softwaresystemen 

Bei Spirit in Projects begleiten wir seit vielen Jahren Unternehmen dabei, Anforderungen an komplexe IT-Systeme zu definieren und Ausschreibungen professionell vorzubereiten. In den letzten Jahren hat sich dabei ein klarer Trend gezeigt: Künstliche Intelligenz (KI) wird in immer mehr Projekten eingesetzt — und bringt ganz eigene Herausforderungen mit sich. 

Gerade bei KI-Systemen ist es entscheidend, die richtigen Anforderungen von Beginn an zu definieren. Viele Unternehmen nutzen dafür noch dieselben Methoden wie bei klassischen Softwareprojekten — und scheitern später an mangelnder Qualität, fehlender Erklärbarkeit oder unrealistischen Erwartungen. 

Wir bei Spirit in Projects unterstützen unsere Kunden deshalb gezielt dabei, Anforderungen an KI-Systeme so zu formulieren, dass sie sowohl für die Implementierung als auch für den späteren Betrieb und die Ausschreibung tragfähig sind.

Lernen statt Programmieren 

Klassische Softwaresysteme folgen klar definierten Regeln: Wenn Eingabe X, dann Ausgabe Y. Das Verhalten ist deterministisch und vorhersehbar. 

KI-Systeme funktionieren grundlegend anders: Sie lernen aus Daten und entwickeln daraus ein Modell. Die „Regeln“ entstehen also nicht durch Programmierung, sondern durch maschinelles Lernen. Daraus folgt: Daten sind der Schlüssel zum Erfolg. Schon in der Anforderungsdefinition müssen deshalb Fragen beantwortet werden wie: 

  • Welche Daten liegen vor? 
  • In welcher Qualität und in welchem Umfang? 
  • Wie werden die Daten aktuell gepflegt und verfügbar gemacht? 

Unsere Erfahrung zeigt: In der Praxis wird dieser Aspekt oft unterschätzt — mit fatalen Folgen für das Projekt. 

Wahrscheinlichkeiten statt Garantien 

Ein weiterer fundamentaler Unterschied: KI-Systeme liefern probabilistische Ergebnisse. Ein System zur Bilderkennung meldet z.B.: „Dieses Objekt ist mit 95 % Wahrscheinlichkeit eine Katze.“ Es garantiert aber nicht, jede Katze fehlerfrei zu erkennen. 

Anforderungen an die Qualität der Ergebnisse (Accuracy, Precision, Recall, Konfidenzintervalle) müssen daher explizit definiert werden. In unseren Ausschreibungsprojekten für KI-Systeme achten wir darauf, diese Qualitätsparameter sauber zu spezifizieren — um spätere Enttäuschungen zu vermeiden.

Dynamisches Verhalten 

Klassische Software bleibt nach Auslieferung weitgehend stabil. KI-Modelle hingegen müssen oft regelmäßig neu trainiert werden, da sich Datenlagen und Umgebungen verändern (Concept Drift). 

Daraus ergeben sich spezifische Anforderungen an: 

  • Lifecycle-Management 
  • Modellüberwachung und -pflege 
  • Governance und Verantwortlichkeiten 

Spirit in Projects unterstützt Kunden dabei, diese Aspekte in der Anforderungsdefinition und in die Ausschreibungsunterlagen aufzunehmen — ein Punkt, der bei vielen Projekten sonst zu kurz kommt.

Erklärbarkeit und Nachvollziehbarkeit 

Gerade in regulierten Bereichen (z.B. Finanzdienstleistungen, öffentlicher Sektor, Gesundheit) ist Erklärbarkeit entscheidend. KI-Systeme dürfen keine Black Boxes sein. 

Anforderungen müssen hier klar festlegen: 

  • In welchem Umfang muss Erklärbarkeit gewährleistet sein? 
  • Für wen muss die Nachvollziehbarkeit gegeben sein (z.B. interne Audits, externe Prüfstellen)? 

In unserer Praxis achten wir darauf, dies in den Anforderungskatalog sauber zu strukturieren — und dabei marktübliche technische Möglichkeiten und regulatorische Vorgaben in Einklang zu bringen.

Fazit

Anforderungen an KI-Systeme sind keine simple Erweiterung klassischer Softwareanforderungen. Sie müssen die Lernfähigkeit, die probabilistische Natur und die Datenabhängigkeit explizit berücksichtigen. 

Spirit in Projects bringt in diesem Bereich umfassende Erfahrung aus zahlreichen KI-Projekten und Ausschreibungen mit. Wir unterstützen Unternehmen dabei, tragfähige und belastbare Anforderungen zu formulieren — als Grundlage für erfolgreiche KI-Projekte. 

Künstliche Intelligenz im Projektmanagement: Erfolgsfaktoren und Fallstricke

Die Integration von Künstlicher Intelligenz (KI) in Unternehmen verspricht große Fortschritte in der Automatisierung und Effizienzsteigerung. Doch ein KI-Projekt erfolgreich zu managen, erfordert mehr als nur technisches Know-how. Es gibt eine Reihe von Fallstricken und Normen, die Projektleiter beachten müssen, um die komplexen Herausforderungen zu meistern.

Realistische Ziele setzen

Einer der häufigsten Fehler in KI-Projekten ist eine unklare Zielsetzung. Viele Unternehmen erhoffen sich durch den Einsatz von KI schnelle, weitreichende Erfolge, die jedoch oft unrealistisch sind. KI kann Prozesse automatisieren und verbessern, doch sie ist keine universelle Lösung für jedes Problem. Der Erfolg hängt von klar definierten, messbaren und realistischen Zielen ab. Projektmanager sollten daher konkrete Use Cases identifizieren und die Erwartungen auf realisierbare Ergebnisse beschränken.

Datenqualität und Datenschutz

Die Grundlage jeder erfolgreichen KI-Anwendung sind Daten. Ohne qualitativ hochwertige und umfangreiche Datensätze bleibt die beste KI wirkungslos. Gleichzeitig darf der Datenschutz nicht vernachlässigt werden. In Europa spielt die Datenschutz-Grundverordnung (DSGVO) eine zentrale Rolle. Unternehmen müssen sicherstellen, dass alle verwendeten Daten rechtmäßig erhoben und verarbeitet werden und auch gelöscht werden können.

Bias und Fairness

Ein weiteres zentrales Problem von KI-Projekten ist die Frage nach Bias und Fairness. Verzerrungen in den Daten können dazu führen, dass KI-Systeme unfaire Entscheidungen treffen. Daher sollten Projektleiter Mechanismen zur Überprüfung und Sicherstellung der Fairness implementieren. Dies ist besonders wichtig in sensiblen Bereichen wie der Personalauswahl oder der Kreditvergabe, wo unfaire Entscheidungen weitreichende Folgen haben können.

Ethische und regulatorische Anforderungen

Neben technischen Herausforderungen müssen auch ethische und rechtliche Aspekte beachtet werden. Es gibt internationale Normen, wie den ISO/IEC-Standard 23894, der Leitlinien für den Lebenszyklus von KI-Systemen vorgibt. Zudem bieten Organisationen wie die Europäische Ethikkommission Richtlinien, die Projektleitern helfen, ethische Dilemmata zu adressieren und rechtliche Anforderungen zu erfüllen.

Interdisziplinäre Zusammenarbeit

KI-Projekte erfordern die Zusammenarbeit von Experten aus unterschiedlichen Disziplinen: Datenwissenschaftler, Ingenieure und Rechtsexperten müssen eng zusammenarbeiten. Projektleiter spielen eine entscheidende Rolle, um diese Zusammenarbeit zu fördern und die verschiedenen Teams effektiv zu koordinieren. Klare Kommunikationsstrukturen und ein gut abgestimmtes Team sind daher entscheidend für den Projekterfolg.

Fazit

Ein erfolgreiches KI-Projekt erfordert klare Ziele, qualitativ hochwertige Daten und die Einhaltung von Datenschutz- sowie Ethikrichtlinien. Projektleiter sollten sich dieser Herausforderungen bewusst sein und Maßnahmen ergreifen, um potenzielle Fallstricke zu umgehen. Nur durch ein durchdachtes Vorgehen und die Berücksichtigung technischer sowie ethischer Aspekte kann KI ihr volles Potenzial entfalten.

Agilität und Requirements Engineering: Ein Leitfaden für Projektmanager

Projektmanager stehen oft an der Schnittstelle zwischen sich ständig ändernden Marktanforderungen und den technischen Herausforderungen von Entwicklerteams. Das agile Modell verspricht Flexibilität und Anpassungsfähigkeit, während das Requirements Engineering (RE) strukturierte Klarheit bietet. Aber wie balancieren Projektmanager diese beiden Ansätze, um ein effizientes und erfolgreiches Projektmanagement zu gewährleisten? Modellbasierte Anforderungsdokumentation Oft müssen Projektmanager komplexe technische Details… Continue Reading Agilität und Requirements Engineering: Ein Leitfaden für Projektmanager

Skalierungsframeworks im agilen Umfeld: Was Sie als IT-Leiter wissen sollten

Die agile Methodik hat zweifellos die Landschaft der Softwareentwicklung geprägt. Doch wenn Sie vor der Aufgabe stehen, Agilität in Ihrer Abteilung oder im gesamten Unternehmen zu skalieren, könnten Sie sich fragen: „Welches Framework passt zu uns?“

Die Erfahrungen variieren je nach Organisation, Kultur, Art des Projekts und der gewählten Implementierung. Hier sind einige allgemeine Erfahrungen und Erkenntnisse, die Unternehmen mit verschiedenen Skalierungsframeworks gemacht haben.

Scaled Agile Framework (SAFe)

Dieses Framework bietet eine strukturierte Vorgehensweise, die in großen Organisationen oft geschätzt wird. Doch Vorsicht: Obwohl SAFe klare Rollen und Rituale liefert, empfinden es manche Teams als übermäßig bürokratisch. Es könnte also sein, dass Sie Anpassungen vornehmen müssen, um es in Ihre Unternehmenskultur zu integrieren.

Large Scale Scrum (LeSS)

Wenn Sie den Charme und die Einfachheit beibehalten möchten, selbst in großem Maßstab, könnte LeSS das Richtige für Sie sein. Beachten Sie jedoch, dass seine minimalistische Herangehensweise nicht jedem in Ihrem Unternehmen zusagen könnte, insbesondere wenn sie nach einer detaillierteren Struktur suchen.

Disciplined Agile Delivery (DAD)

Dieser flexible Ansatz berücksichtigt den gesamten Softwarelifecycle. Seine Anpassungsfähigkeit kann ein Segen sein, aber stellen Sie sicher, dass Sie klare Richtlinien für Ihr Team haben, um nicht in Unklarheiten zu versinken.

Einige Schlüsselerkenntnisse, die wir aus unserer Beratungstätigkeit erkannt haben:

  1. Anpassungsfähigkeit ist Ihr bester Freund: Kein Framework wird perfekt zu Ihrem Team passen. Seien Sie bereit, Anpassungen vorzunehmen, die Ihrem Team und Ihrer Kultur entsprechen.
  2. Die Kultur zählt: Ein echtes agiles Mindset sollte gefördert werden. Wenn Sie dies nicht tun, werden selbst die besten Frameworks nicht die gewünschten Ergebnisse liefern.
  3. Ihre Rolle als Führungskraft ist entscheidend: Ihr Engagement und Ihre Unterstützung sind unerlässlich für erfolgreiche agile Transformation.

Agile Ansätze können (und sollten oft auch) in großen Softwareprojekten eingesetzt werden, aber dies erfordert eine sorgfältige Planung, Anpassung, die Wahl des richtigen Skalierungsframeworks und eine starke organisatorische Unterstützung.

Usability Engineering – eine wichtige Ergänzung für Requirements Engineers

Ein Seitenblick in Richtung X/UI lohnt sich für Anforderungsanalysten. Denn das Benutzerinterface bestimmt wesentlich die Akzeptanz einer Lösung mit.

Nein, Usability Engineering beschäftigt sich nicht mit der schönen grafischen Gestaltung von Oberflächen. Ja, Requirements Engineers, insbesondere solche, die mit Applikationen für Endkunden, aber auch mit Applikationen einer großen Anzahl von internen Anwendern beschäftigt sind, sollten sich unbedingt mit Usability Engineering auseinandersetzen.

UX-Herausforderungen im Anforderungsmanagement

Eine immer größere Herausforderung für Requirements Engineers ist die funktionale Beschreibung von Applikationen, die nicht nur den Anspruch erheben, korrekt und effizient zu sein, sondern gleichzeitig auch einfach zu erlernen (am besten benötigt man gar keine Einschulung), für die Benutzer verständlich und übersichtlich, fehlertolerant nicht nur bei Falscheingaben, sondern auch bei fehlerhafter Nutzung sowie für die Benutzer insgesamt sogar attraktiv und hilfreich sind.

Ein schönes Benutzerinterface ist nur ein Aspekt für die Übersichtlichkeit, Erlernbarkeit oder Attraktivität eines Systems. Die Gestaltung dieses Aspekts obliegt dem User-Interface-Designer, erfolgt tatsächlich ebenfalls mit nachvollziehbaren Methoden und benötigt durchaus auch Geschmack und einen Hauch von künstlerischer Gestaltung.

Der Lösungsweg: Usability Engineering

Beim Usability Engineering geht es jedoch darum, funktionale und nicht funktionale Eigenschaften des Systems aus der Betrachtung des gesamten Umfelds der Benutzer abzuleiten und zu optimieren. Ein weiterer Aspekt ist es, die komplette User Journey abzubilden und in die Systemgestaltung einzubeziehen.

So ist zum Beispiel für den Nutzer eines Webshops die Erfahrung mit dem System nicht bereits bei der Bestellung beendet, sondert geht bis zum Erhalt des Pakets beziehungsweise zur Unterstützung bei Reklamationen. Im Requirements Engineering grenzen wir uns (völlig absichtlich) vom nicht direkt mit dem System im Zusammenhang stehenden Umfeld ab.

Dies lernt man bereits im Zuge der Erstellung von Kontextdiagrammen. Dadurch gelingt aber manchmal nur schwer, die Beweggründe der Benutzer hinter einzelnen Aktivitäten zu verstehen. Weiters gibt es im Requirements Engineering keine Betrachtung der Benutzerzufriedenheit über den kompletten Life cycle (auch außerhalb der Systemgrenzen) der Nutzung.

Die Methoden des Requirements Engineering und des Usability Engineering ergänzen sich diesbezüglich hervorragend und bilden für viele Aufgaben einen guten Mehrwert. Das Kursportfolio von Spirit in Projects bietet für beide Richtungen Grundlagen- und Spezialisierungskurse. So können Sie Ihr individuelles Skillset gezielt erweitern.


Trainingsangebote zu UX/UI:

Ebenen der Businessanalyse

Businessanalyse ist nicht gleich Businessanalyse. Tatsächlich gibt es unterschiedliche Varianten, die je nach Betrachtungsaspekt und Zielsetzung eingesetzt werden müssen.

Die unterschiedlichen Einsatzmöglichkeiten erfolgen aus den verschiedenen Aufgabenstellungen, die im Zuge der Digitalisierung von Geschäftsprozessen und unterstützenden Prozessen vorgefunden werden. Grundsätzlich kann man drei Varianten unterscheiden:

  • Teilgeschäftsprozess- bzw. IT-System-Analyse
  • Geschäftsprozessanalyse
  • Enterprise-Analyse

Diese drei Varianten der Business Analyse werden nun näher betrachtet und verglichen.

Teilgeschäftsprozessanalyse

Die Teilgeschäftsprozessanalyse hat als Fokus einen Ausschnitt eines Geschäftsprozesses. Sie wird in der Praxis daher am besten zur Digitalisierung einzelner Prozessschritte eingesetzt. Diesbezüglich ist sie dem klassischen Requirements
Engineering sehr ähnlich, da die Anforderungen an ein IT-System im Vordergrund stehen. Aus diesem Fokus heraus können die Funktionalitäten des Systems optimal gestaltet werden, es findet aber keine gesamtheitliche Prozessoptimierung statt.

Tatsächlich ist diese Variante jene, die in der Praxis am häufigsten angetroffen wird, da zumeist bestehende Prozesse weiter optimiert werden sollen, ohne am Grundgerüst der Abläufe zu rütteln. Der Vorteil dieser Variante liegt in ihrem überschaubaren Umfang. Die lokale Optimierung eines Prozesses führt über längere Zeit jedoch dazu, dass das volle Potenzial einer Prozessoptimierung nicht ausgeschöpft wird.

Geschäftsprozessanalyse

Die Geschäftsprozessanalyse legt den Fokus auf die Ende-zu-Ende-Betrachtung eines ganzen Prozesses. Diese Variante wird am häufigsten bei der Neugestaltung ganzer Prozesse eingesetzt. Beispiele dafür sind:

  • Ein Prozess wird erstmalig vollständig digitalisiert.
  • Das IT-System eines Prozesses wird ausgewechselt oder wesentlich verändert (z.B. werden mehrere Systeme zusammengelegt oder die Technologie einzelner Prozessschritte geändert).
  • Die Leistungsdaten eines Prozesses sind nicht mehr ausreichend und sollen mit einem grundlegenden Redesign unter Nutzung von IT-Systemen neugestaltet werden.

Leider gibt es bei dieser Variante in der praktischen Umsetzung in vielen Unternehmen noch immer die zu überwindende Barriere zwischen der Verantwortung für die Prozessgestaltung beziehungsweise Optimierung und der Verantwortung für die Gestaltung und Entwicklung der IT-Systeme. Im Sinne der wo immer möglichen umfassenden Digitalisierung von Geschäftsprozessen erscheint dies jedoch nicht angebracht. Zumindest eine enge Zusammenarbeit oder sogar eine Integration ist wünschenswert, um zukünftige Herausforderungen annehmen zu können.

Enterprise-Analyse

Die Enterprise-Analyse wiederum hat einen noch größeren Aspekt. Dabei werden ganze Prozessgruppen, Teilorganisationen oder im Extremfall die gesamte Organisation betrachtet und Optimierungen ausgearbeitet. Dazu werden grob gesagt Unternehmensziele mit Prozessen, Services, Systemen und Technologien verbunden und gesamtheitlich betrachtet. Dieser Ansatz kann mit der üblichen Prozessanalyse nicht durchgeführt werden. Es müssen Methoden der Enterprise-Analyse (TOGAF®, ArchiMate®) angewandt werden. Weiters ist eine rein technische Aufbereitung der Analyse nicht ausreichend. Zuerst müssen Ziele aus der Unternehmensleitung klar definiert werden. Die enge Zusammenarbeit mit internen Stakeholders oder externer Beratung aus den Bereichen Finanzen und Kosten, Marketing und Verkauf, Produktion, Forschung und Entwicklung und so weiter ist für die erfolgreiche Umsetzung notwendig.

Aus Sicht des Businessanalysten soll bei dieser Vorgehensweise, ausgehend von optimierten Prozessen, eine darauf abgestimmte IT-Service- und Systemlandschaft erstellt werden. Der Vorteil dieser Methode liegt in der gesamtheitlichen Betrachtung der Organisation und der in die Methode integrierten Fokussierung auf die Digitalisierung der Prozesse. Ihr Nachteil liegt klar im hohen Aufwand. Praktisch bemerken wir auch häufig das Fehlen klarer unternehmerischer Zielvorgaben beziehungsweise auch die Problemstellung, dass die Gestaltung von Prozessen nicht immer ausschließlich rational abgewickelt werden kann, insbesondere bei Veränderungen in der Aufbauorganisation.

Prozesse: Auf der richtigen Ebene ansetzen

Für Ihr Unternehmen ist es wichtig, dass Sie nachhaltige Lösungen implementieren. Daher muss bereits die Analyse auf der richtigen Ebene Ihres Business ansetzen. Die Experten von Spirit in Projects unterstützen Sie dabei, Ihr Business und Ihre Prozesse zu durchleuchten. Wir beraten praxisrelevant und unterstützen Sie dabei, Know-how langfristig in Ihrem Unternehmen zu verankern.

Trainings in Business Analyse bei Spirit in Projects
Trainings in Business Analyse bei Spirit in Projects

Agilität mit Ziel

Agilität in unterschiedlichsten Ausprägungen ist die am weitesten eingesetzte Entwicklungsmethode geworden. Es werden kaum noch neue Entwicklungsprojekte gestartet, die nicht Agil, mit Kanban oder DevOps Methoden oder einer Mischung daraus durchgeführt werden. Aber geschieht das mit Maß und Ziel?

Die modernen Entwicklungswerkzeuge sind inzwischen fast vollständig auf die Nutzung agiler Methoden ausgelegt. Von vielen Kunden hören wir, dass Entwickler in der Bewerbung schon oft, auf den Einsatz dieser Methoden bestehen.

Trotz des Einsatzes dieser modernen und für moderne Projekte adäquater Methoden gibt es in der Praxis jedoch immer noch Probleme mit Projektverzug und Kostenüberschreitungen. Aus unserer Sicht, sind Qualitätsprobleme deutlich seltener geworden.

Die Kehrseite: Agilität ohne Ziel

Es lässt sich leider beobachten, dass manche Projekte ohne entsprechende Vorbereitung gestartet werden. In der puren agilen Weltsicht ist dies auch korrekt. Trägt dafür doch der Product Owner des internen oder externen Auftraggebers die Verantwortung. Zumindest für rechtzeitige Abklärung der Anforderungen.

In der Praxis muss der Product Owner jedoch häufig durch einen Business Analysten oder Requirements Engineer zumindest unterstützt werden, um diese Verantwortung auszufüllen. Bei komplexen Systemen müssen vorab grundlegende Entscheidungen zur Systemarchitektur getroffen werden, was vom Product Owner kaum zu verlangen ist.

Auch zu beachten ist, dass Projekte budgetiert und zeitlich geplant werden müssen, weshalb manche Entscheidungen bereits vor der agilen Umsetzung getroffen werden müssen.

Die Kombination macht‘s

Der Ausweg liegt im Einsatz der bewährten Planungs- und Analysemethoden. So kann auch für ein agiles Projekt ein Lastenheft erstellt werden und für die Vorbereitung der Umsetzung herangezogen werden. Diese Vorbereitung zahlt sich aus und bei der agilen Umsetzung hilft die Möglichkeit auf Änderungen adaptiv zu reagieren im Rahmen des gegebenen Budgets und der Zeit.

Die Experten von Spirit in Projects unterstützen Sie gerne dabei, agile Methoden in Ihrem Unternehmen erfolgreich und nachhaltig einzuführen oder gezielt anzuwenden. Mit unserem Kursportfolio zu agilen Methoden unterstützen wir Sie bei der Qualifizierung Ihrer Mitarbeiter.

Trainings für Agile Methoden und Kanban bei Spirit in Projects
Trainings für Agile Methoden und Kanban bei Spirit in Projects
Trainings für Agile Methoden und Kanban bei Spirit in Projects