Die KI-Readiness-Checkliste

35 Fragen für CTOs und Engineering Manager, die eine Initiative mit KI-Agenten vor einem Umsetzungsentscheid prüfen. Die Fragen decken Anwendungsfall, Daten, Architektur, Team, Governance, Sicherheit, Kosten und Betriebsmodell ab. Kostenlos, ohne Anmeldung und druckbar.

Markieren Sie jede Aussage mit Ja, Nein oder Unklar. Nutzen Sie das entstehende Muster als Gesprächsgrundlage. Die Checkliste ist eine Orientierungshilfe, kein validiertes Reifegradmodell, keine Zertifizierung und kein automatischer Go/No-Go-Entscheid.

Ergebnisse in 30 Minuten besprechen Agentic AI Engineering

1. Anwendungsfall & Geschäftswert

Auch ein technisch leistungsfähiges Modell kann einen ungeklärten Anwendungsfall nicht kompensieren. Es braucht klare Verantwortung, messbaren Nutzen und einen definierten Umgang mit falschen Ergebnissen.

  • Wir können den konkreten Geschäftsprozess benennen, den die KI verbessern soll, und die Person, die den Prozess verantwortet, hat den Bedarf bestätigt
  • Wir wissen, was der Prozess heute kostet (Zeit, Geld oder Fehler), und können messen, ob die KI ihn tatsächlich verbessert
  • Die Aufgabe erfordert Entscheidungen auf Basis unstrukturierter Informationen; ein regelbasiertes System oder ein Batch-Job würde sie nicht günstiger lösen
  • Wir haben definiert, was «gut genug» bedeutet: eine akzeptable Fehlerquote und was passiert, wenn die KI falsch liegt
  • Jemand mit Budgetverantwortung trägt das Vorhaben; es ist kein Nebenprojekt mit der Begründung «der Verwaltungsrat will KI»

2. Daten & APIs

Nutzen und Risiko eines Agenten hängen von den Daten ab, die er lesen darf, und von den Aktionen, für die er eine Berechtigung erhält.

  • Das Wissen, das die KI braucht, existiert maschinenlesbar, nicht nur in Köpfen, gescannten PDFs oder einem Wiki, das niemand pflegt
  • Wir wissen, wo diese Daten liegen, wem sie gehören und ob wir sie für diesen Zweck nutzen dürfen
  • Die Systeme, in denen der Agent Aktionen ausführen soll, bieten APIs; die Aktionen stecken nicht hinter UIs, Batch-Dateien oder manuellen Schritten
  • Diese APIs haben Authentifizierung und Autorisierung, die einen Agenten von einem menschlichen Benutzer unterscheiden können
  • Wir können zu einer Frage relevante, aktuelle Dokumente abrufen, eine Voraussetzung für RAG, ohne zuvor ein separates Vorhaben zur Aufbereitung der Datengrundlage starten zu müssen

3. Architektur

KI-Agenten greifen auf Ihre Systeme zu. Bestehende Grenzen, Schnittstellen und Kontrollen bestimmen, was sie tun können und wie sich Fehler eindämmen lassen.

  • Unsere Landschaft hat Modul- oder Servicegrenzen, denen die Berechtigungen eines Agenten folgen könnten; sie ist kein Geflecht, in dem jeder Zugriff eine Alles-oder-nichts-Entscheidung ist
  • Fachliche Aktionen stehen über klar definierte, wo möglich idempotente Schnittstellen zur Verfügung; das empfangende System validiert jeden Aufruf
  • Wir können eine realistische Nicht-Produktionsumgebung betreiben, in der sich ein Agent mit realistischen Abläufen testen lässt, ohne Produktionsdaten zu verwenden
  • Wir verwenden eine offiziell unterstützte Kombination aus JDK, Spring Boot und Spring AI und haben für die geplante Lebensdauer des Agenten einen Upgradepfad definiert
  • Wir haben einen klaren Integrationspunkt für KI-Komponenten; dafür müssen wir keine separate Parallelarchitektur aufbauen

4. Teamkompetenzen & KI-gestützte Entwicklung

Das Team, das nach dem Go-live die Verantwortung trägt, braucht genügend Kompetenz und Kapazität, um den Agenten zu evaluieren, zu überwachen und weiterzuentwickeln.

  • Das Wissen ist im Team geteilt: Mehr als eine Entwicklerin oder ein Entwickler hat über ein Tutorial hinaus etwas mit LLM-APIs, Embeddings oder einem Framework für KI-Agenten gebaut
  • Das Team weiss, dass Antworten von Sprachmodellen probabilistisch sind, und baut explizite Prüfungen ein, statt den Antworten ungeprüft zu vertrauen
  • Die Entwicklerinnen und Entwickler nutzen bereits KI-gestützte Werkzeuge; deren Vorschläge durchlaufen dieselben Code-Reviews, Tests und Qualitätskontrollen wie anderer Code
  • Wir können repräsentative Datensätze, wiederholbare Evaluationen und Akzeptanzkriterien für das Verhalten des Agenten aufbauen und pflegen
  • Es gibt einen Plan, wer den Agenten nach dem Go-live betreibt, überwacht und verbessert; die Verantwortung endet nicht bei der Demo

5. Governance, Risiko & Compliance

Der EU AI Act ist in Kraft, doch Pflichten und Anwendungsfristen hängen von der Rolle Ihrer Organisation, dem Anwendungsfall und seiner Risikoklassifizierung ab. Er kann auch für ein Schweizer Unternehmen gelten, wenn ein System auf dem EU-Markt angeboten oder sein Ergebnis in der EU verwendet wird. Nutzen Sie die Hinweise der Europäischen Kommission und qualifizierte Rechts- oder Datenschutzberatung; diese Checkliste ersetzt keine rechtliche Beurteilung.

  • Wo der EU AI Act anwendbar ist, haben wir unsere Rolle, die relevante Risikoklassifizierung, die geltenden Fristen und die daraus entstehenden Pflichten bestimmt
  • Jemand ist für KI-Entscheidungen in Produktion verantwortlich: ein Name, kein Gremium, das später gebildet wird
  • Wir wissen, welche Daten rechtlich an welchen Modellanbieter gehen dürfen und ob wir EU-Hosting, einen Schweizer Anbieter oder lokale Modelle brauchen
  • Die erforderlichen Freigaben durch Menschen sind definiert: Wir wissen, welche Aktionen eine Freigabe brauchen und wer sie erteilt
  • Wir können die Eingaben, Modellantworten, Tool-Aufrufe, Freigaben und Systemreaktionen rekonstruieren, die zu einem Ergebnis geführt haben, und berücksichtigen dabei, dass sich die interne Herleitung eines Sprachmodells nicht vollständig erklären lässt

6. Sicherheit

Ein Agent schafft eine neue Angriffsfläche: Er verarbeitet nicht vertrauenswürdige Eingaben und besitzt Zugangsdaten, um Aktionen auszuführen.

  • Wir behandeln Prompt Injection als Angriffsklasse: Alles, was der Agent liest, darunter Dokumente, E-Mails oder Webinhalte, gilt als nicht vertrauenswürdige Eingabe
  • Der Agent bekommt eine eigene Identität mit minimalen Rechten; er handelt nicht mit den breiten Berechtigungen eines Menschen oder eines Service-Accounts
  • Destruktive oder unumkehrbare Aktionen werden technisch begrenzt, etwa durch Rate Limits, Freigabeschritte und Positivlisten, und nicht nur im Prompt untersagt
  • Geheimnisse, Personendaten und vertrauliche Informationen werden gefiltert, bevor sie an einen Modellanbieter übermittelt werden können
  • Unsere bestehenden Sicherheitspraktiken (Dependency-Scanning, Zugriffs-Reviews, Incident Response) erstrecken sich auf die KI-Komponenten; sie sind nicht ausgenommen, weil sie neu sind

7. Kosten & Betrieb

Die Wirtschaftlichkeit eines Piloten lässt sich selten direkt auf den produktiven Betrieb übertragen. Volumen, erneute Modellaufrufe, Modell-Routing, Latenzziele und Fallback-Verhalten brauchen explizite Annahmen.

  • Wir können die Kosten pro Aufgabe schätzen (Tokens, Aufrufe, Retries) und was das bei Produktionsvolumen bedeutet, nicht bei Demovolumen
  • Das Modell-Routing folgt einer expliziten Abwägung zwischen Kosten und Qualität: günstigere Modelle für einfachere Schritte und leistungsfähigere Modelle dort, wo der Qualitätsgewinn die Mehrkosten rechtfertigt
  • Wir haben Observability, mit der das Betriebsteam arbeiten kann: Latenz, Fehlerraten, Token-Verbrauch und Qualitätsmetriken pro Schritt
  • Es gibt einen definierten Fallback, wenn der Modellanbieter ausfällt, langsam ist oder nur eingeschränkt funktioniert; der Geschäftsprozess bleibt nicht einfach stehen
  • Eine verantwortliche Person prüft die laufenden KI-Kosten in einem vereinbarten Rhythmus gegen den erzielten Nutzen und darf Funktionen drosseln oder abschalten

So ordnen Sie das Muster ein

Behandeln Sie die Gesamtsumme nicht als Entscheid. Prüfen Sie die Belege hinter jeder Antwort, beachten Sie Unklarheiten und beginnen Sie mit den Bereichen, die einen sicheren Betrieb oder messbaren Geschäftswert verhindern könnten.

  • Wenige Lücken: vor der Umsetzung validieren

    Bestätigen Sie den stärksten Anwendungsfall mit repräsentativen Daten, expliziten Akzeptanzkriterien und den Personen, die ihn betreiben werden. Eine Discovery mit klarem Umfang kann diese Annahmen vor einer grösseren Investition prüfen.

  • Mehrere Lücken: die schwächsten Bereiche bearbeiten

    Priorisieren Sie Lücken, die Nutzen, Berechtigungen, Datenqualität, Evaluation, Sicherheit oder Verantwortung betreffen. Einige lassen sich in einer Discovery klären; andere gehören vor der Umsetzung auf die technische Roadmap.

  • Viele Lücken oder Unklarheiten: Grundlagen schaffen

    Klären Sie Anwendungsfall und Verantwortung, bevor Sie eine Technologie wählen. Arbeiten an Grenzen, APIs, Tests, Observability und Governance verbessern das Gesamtsystem auch dann, wenn Sie sich gegen einen Agenten entscheiden. Starten Sie je nach Engpass mit der Anwendungsmodernisierung oder einem Architektur-Review.

Bei Lücken in den Teamkompetenzen können unsere Schulung zu Spring AI & Embabel oder unser Entwickler-Coaching passende nächste Schritte sein. Lücken bei Daten, Architektur oder Sicherheit brauchen vor der Umsetzung klare Verantwortliche und einen technischen Plan.

Eine zweite Meinung zu Ihren Antworten?

Buchen Sie 30 Minuten mit Patrick und prüfen Sie die Belege hinter Ihren schwächsten Abschnitten. Gemeinsam bestimmen wir den nächsten praktischen Schritt, auch wenn zuerst technische Grundlagen nötig sind und ein KI-Agent noch nicht ansteht.

30-minütiges Gespräch buchen Agentic AI Engineering