KI & Sicherheit

Anbieterprüfung und fertige KI-Lösungen

Welche Kriterien bei KI-Anbietern, Plugins, lokalen Stacks, MCP-Servern und fertigen Tools zählen.

Stand: 2026-06-05

Kurzfassung

  • Anbieterprüfung betrifft nicht nur Datenschutz, sondern auch Lieferkette, Updates, Plugins, Rule-Packs und Toolrechte.
  • Große Anbieter werden einfacher freigegeben, aber nicht blind vertraut.
  • Kleine Tools, Plugins, MCP-Server, Rule-Packs und Skills werden restriktiver geprüft.
  • Experimente sind erlaubt, aber nur isoliert und nicht auf Rechnern mit Zugriff auf Kundenprojekte.
  • Security-Patches sollen zügig eingespielt werden; neue Fähigkeiten werden kontrolliert geprüft.
  • latest ist keine produktive Update-Strategie.
  • Tools ohne klare Herkunft, Rechtebegrenzung, Kontext-Ausschluss oder Rollback sind nicht erlaubt.

Grundsatz

Vendor Due Diligence heißt bei KI:

Security-Patches zügig, neue Fähigkeiten kontrolliert.

Ein Anbieter oder Tool wird nicht nur danach bewertet, wie bekannt er ist, sondern danach, welche Daten er sieht, welche Rechte er bekommt und wie kontrollierbar Updates, Plugins und neue Funktionen sind.

Anbietergruppen

Große KI-Anbieter:

  • OpenAI / ChatGPT / Codex,
  • Anthropic / Claude,
  • JetBrains AI,
  • GitHub/GitLab/Bitbucket AI-Funktionen.

Prüfung:

  • Datenschutz,
  • Training/Opt-out,
  • Retention,
  • Region,
  • DPA/AVV,
  • Enterprise-/Team-Funktionen,
  • Admin-Kontrollen,
  • Security-Dokumentation.

IDE-/Agenten-Tools:

  • Cursor,
  • PhpStorm AI,
  • Codex-/IDE-Agenten,
  • andere Agenten mit Projektkontext.

Prüfung:

  • Projektkontext,
  • .aiignore oder gleichwertige Ausschlüsse,
  • Dateizugriff,
  • Schreibrechte,
  • Commands,
  • Git,
  • Logs,
  • Update-Verhalten.

Lokale LLM-/UI-Stacks:

  • Ollama,
  • LM Studio,
  • Open WebUI,
  • llama.cpp.

Prüfung:

  • Installationsquelle,
  • Updates,
  • Netzwerkzugriff,
  • Authentifizierung,
  • Logs,
  • Modellquellen,
  • Plugins,
  • Service-Rechte.

Fremde Rule-Packs, Skills, MCP und Plugins:

  • öffentliche Repos,
  • Templates,
  • Marketplace-Erweiterungen,
  • fertige Agenten-Skills,
  • MCP-Server.

Prüfung:

  • besonders kritisch,
  • keine direkte Installation,
  • keine Schreib-, Command-, Git- oder Projektdateirechte ohne explizite Freigabe,
  • nur als Ideenquelle oder nach gezieltem Review.

Experimente

Neue KI-Tools, Plugins, Rule-Packs und Updates dürfen getestet werden, aber nur isoliert.

Experiment:

  • isolierte Umgebung,
  • keine Kundendaten,
  • kein echter Projektcode,
  • keine echten Tokens,
  • keine produktiven Zugriffe,
  • keine Schreibrechte auf Kundenprojekte.

Pilot:

  • internes Projekt oder Demo-Projekt,
  • klarer Zweck,
  • begrenzte Rechte,
  • Status geduldet/in Prüfung in der Tool-Liste.

Freigegeben:

  • geprüft,
  • Rechte begrenzt,
  • Update- und Rollback-Verhalten verstanden,
  • kompatibel mit Projektregeln.

Wandregel:

Experimente ja, aber nicht auf Kundenprojekt-Rechnern.

Updates

Updates brauchen eine differenzierte Regel.

Security-Patches:

  • zügig einspielen,
  • nicht unnötig verzögern,
  • Security Notes prüfen,
  • Risiko und Dringlichkeit abwägen.

Funktionsupdates:

  • kontrolliert prüfen,
  • nicht automatisch in kritischen Projektphasen,
  • nicht direkt vor Release oder Deployment,
  • neue Major-Versionen separat bewerten.

Besonders kritisch bei Updates:

  • neue Toolrechte,
  • neue Cloud-Synchronisierung,
  • neue Telemetrie,
  • geändertes Kontextverhalten,
  • neue MCP-/Plugin-Schnittstellen,
  • automatische Rule-/Skill-Nachladung,
  • geänderte Retention- oder Training-Einstellungen,
  • neue Schreib-, Git- oder Command-Funktionen.

Regel:

Auto-Updates nur bei niedrigem Risiko und klarem Rollback.

Für Tools mit Zugriff auf Kundenprojekte, Dateisystem, Commands, Git oder externe Systeme gilt:

  • Auto-Updates möglichst deaktivieren,
  • Updates manuell oder kontrolliert einspielen,
  • neue Versionen zuerst isoliert testen,
  • Rollback-Version kennen,
  • latest vermeiden.

Wenn Auto-Updates technisch nicht abschaltbar sind, wird das Tool als höheres Risiko eingestuft oder nur eingeschränkt verwendet.

P0-No-Gos

  • Keine Tools ohne klare Herkunft.
  • Keine Tools ohne nachvollziehbare Versionen oder Releases.
  • Keine latest-Strategie für produktive KI-/Agenten-/Plugin-Tools.
  • Keine Experimente auf produktiven Systemen oder Rechnern mit Zugriff auf Kundenprojekte.
  • Keine fremden Rule-Packs, Skills, Plugins oder MCP-Server ohne Review.
  • Keine Tools, die Regeln, Plugins oder Code automatisch nachladen.
  • Keine Tools ohne Möglichkeit, Rechte zu begrenzen.
  • Keine Tools ohne Möglichkeit, Projektkontext auszuschließen.
  • Keine Tools mit unklarer Cloud- oder Datenübertragung.
  • Keine Tools, die mehr Datenzugriff fordern als nötig.
  • Keine Tools, die Secrets oder Tokens im Prompt, Regeltext oder Chat verlangen.
  • Keine kritischen Funktionsupdates direkt vor Release oder Deployment.
  • Keine Annahme, dass Enterprise-/Team-Kontrollen aktiv sind, wenn sie nicht im gebuchten Plan verfügbar sind.

Mindeststandard

Vor Freigabe eines KI-Tools oder fertigen KI-Bausteins wird mindestens geklärt:

  • Wer ist Anbieter oder Maintainer?
  • Woher kommt das Tool?
  • Welche Version wird genutzt?
  • Welche Daten sieht das Tool?
  • Werden Daten lokal oder in der Cloud verarbeitet?
  • Gibt es Training/Retention/Opt-out-Angaben?
  • Können Projektbereiche ausgeschlossen werden?
  • Welche Rechte bekommt das Tool?
  • Gibt es Schreib-, Command-, Git-, API- oder MCP-Zugriffe?
  • Gibt es Plugins, Skills oder Rule-Packs?
  • Wie laufen Updates?
  • Ist Rollback oder Deinstallation möglich?
  • Für welche Projekte ist das Tool freigegeben?

Teamentscheidung

Kleine Tools, Plugins, Rule-Packs und MCP-Server sind nicht grundsätzlich verboten, aber nur nach Review und mit eingeschränkten Rechten erlaubt.

Experimente finden isoliert statt und nicht auf produktiven Systemen oder Rechnern mit Zugriff auf Kundenprojekte.

Security-Patches werden zügig eingespielt. Funktionsupdates, Major-Versionen und neue Agentenfähigkeiten werden kontrolliert geprüft.

Auto-Updates sind nur bei niedrigem Risiko und klarem Rollback akzeptabel. Für Tools mit Zugriff auf Kundenprojekte werden Auto-Updates möglichst deaktiviert.

Große Anbieter werden einfacher bewertet, aber nicht blind freigegeben. Einstellungen, Plan, Datenverarbeitung und Admin-Kontrollen müssen geprüft werden.

Wandregeln

Security-Patches zügig, neue Fähigkeiten kontrolliert.

Latest ist keine produktive Strategie.

Experimente ja, aber nicht auf Kundenprojekt-Rechnern.

Große Anbieter einfacher prüfen, kleine Tools restriktiver.

Anbieterclaims sind keine Controls.

Offene Teamfragen

  • Wo wird die Anbieter-/Tool-Prüfung dokumentiert?
  • Wer bewertet kleine Tools, Plugins, Rule-Packs und MCP-Server?
  • Welche Tools dürfen Auto-Updates behalten?
  • Welche KI-Tools müssen auf Testmaschinen zuerst geprüft werden?
  • Welche Anbieter brauchen DPA/AVV oder Datenschutzprüfung?
  • Wie wird geprüft, ob Enterprise-/Team-Einstellungen wirklich aktiv sind?
  • Welche Tools gelten aktuell nur als geduldet/in Prüfung?