KI-Infrastruktur hosten und sichern

Wer Agenten betreibt, lernt schnell, dass das Modell der einfachste Teil davon ist. Dieses Paper beschreibt die Arbeit, die danach beginnt: Modelle und Agenten auf eigener Infrastruktur hosten, netzwerktechnisch isolieren, härten und rund um die Uhr betreiben: so, wie LSA Linux-Infrastruktur betreibt.

1. Die These

Sprachmodelle sind heute herunterladbar, Agent-Runtimes sind offene Software: die Beschaffung ist gelöst. Was damit nicht gelöst ist, ist der Zustand danach: Ein Agent, der mehrstufig arbeitet, wird von der Umgebung abhängig, auf der er läuft. Er braucht Rechenleistung, die im Dauerbetrieb nicht ausfällt, einen Netzpfad, der ihn begrenzt, Protokolle, die seine Handlungen nachweisen, und eine Wiederherstellung, die auch dann greift, wenn niemand daneben sitzt.

Unsere These: Agenten sind Produktionsumgebungen: sie verdienen dieselbe Sorgfalt, die Linux-Teams seit Jahren in Härtung, Monitoring und Backup investieren. Das ist für Selbst-Hoster und DevOps-Praktiker keine neue Disziplin, sondern die nächste Stufe der eigenen. Wer heute Server betreibt, Patch-Zyklen kennt und Wiederherstellungen geübt hat, besitzt bereits das Fundament, auf dem ein Agent-Stack läuft; er muss nicht umdenken, sondern nur das Bestehende erweitern.

Der Unterschied zwischen einem gut geführten Agent-Stack und einem Risiko entsteht deshalb nicht bei der Modellauswahl, sondern beim Hosting, in der Isolation und im Betrieb. Genau dort ist der Rest dieses Papers zu Hause.

Was dieses Paper ist und was nicht

Dieses Paper ist kein Tutorial, kein Modell-Benchmark und keine Rechtsberatung. Es ist eine Betriebsansicht: die Perspektive eines Teams, das Linux-Server betreut, Umgebungen härten und den Betrieb rund um die Uhr offen hält. Regulatorische Fakten stehen dort, wo sie den Betrieb direkt berühren; sie ersetzen keine rechtliche Prüfung im Einzelfall. Die Kapitel folgen der Frage, die im Betrieb zuerst kommt: Wo läuft es (Abschnitt 3), wie wird es begrenzt (Abschnitt 4), wie bleibt es im Tagesgeschäft gesund (Abschnitt 5)?

2. Agenten sind Betriebslasten

Vom Chatbot in die Produktionsumgebung

Ein Chatbot antwortet, wenn jemand fragt. Ein Agent arbeitet in einer Schleife: Er plant Schritte, ruft Werkzeuge auf, prüft Zwischenergebnisse und setzt fort, so oft die Aufgabe es verlangt. Aus Sicht der Infrastruktur bedeutet dieser Unterschied konkret:

1. Dauerbetrieb: Agenten laufen im 24/7-Betrieb; die Umgebung braucht dieselben Standards wie jeder Produktionsservice.
2. Werkzeugaufrufe: Jede Schleife produziert Zugriffe auf APIs, Dienste und Datenquellen; jede einzelne muss protokolliert und begrenzbar sein.
3. Ressourcennutzen: Modell-Inferenz ist Rechenlast mit Spitzen: Kapazität, die geplant wird, nicht eine, die einfach übrig bleibt.

Zu dieser Betriebslast kommt eine, die sich in Piloten selten zeigt: Kettenbildung. Sobald der Ausgabe eines Agenten der nächste Agent folgt, potenziert sich das Zugriffsprofil: jede Kettenglied-Verbindung ist ein Pfad, den es zu begrenzen, zu protokollieren und bei Bedarf zu kappen gilt. Was in der Testphase eine einzige Schleife war, ist im Betrieb ein kleiner Verbund, mit genauso vielen Pfaden, als hätte man mehrere Services eingeführt.

Was die Marktzahlen über Betrieb sagen

Die Marktberichte zeichnen die Lage nach; für Betriebsverantwortliche klingt sie betrieblich: McKinsey berichtet für die State-of-AI-Erhebung vom März 2025, dass mehr als drei Viertel der Befragten KI in mindestens einer Geschäftsfunktion einsetzen. Gartner prognostiziert in der Pressemitteilung vom 25. Juni 2025, dass bis 2028 rund 33% der Enterprise-Software-Anwendungen Agenten-Fähigkeiten enthalten werden, gegenüber unter 1% in 2024, und dass mindestens 15% der alltäglichen Arbeitsentscheidungen bis 2028 autonom durch Agenten getroffen werden.

Der zweite Teil derselben Prognose gehört zur ehrlichen Rechnung: Mehr als 40% der Agentic-AI-Projekte werden laut Gartner bis Ende 2027 abgebrochen werden, wegen steigender Kosten, unklarem Geschäftsnutzen oder unzureichenden Risikokontrollen. Zwei Aussagen gelten gleichzeitig: Die Nutzung ist breit, die Ausfallquote ist hoch. Für Infrastruktur-Teams hat das eine klare Bedeutung: Die Abbruchgründe sind betrieblich, und genau deshalb sind sie die eigenen Zuständigkeiten. Kostenkontrolle heißt planbare Kapazität (Abschnitt 3); Nutzenkontrolle heißt messbare Arbeitsprozesse und ein Besitzer pro Agent (Abschnitt 6); Risikokontrolle heißt Isolation, Protokolle und Wiederherstellbarkeit (Abschnitte 4 und 5). Jeder Abbruchgrund des Markts ist in dieser Sicht ein Architektur-Baustein, den man vorab stellen kann.

Agenten-Frameworks laufen bei mehreren unserer Kunden bereits aktiv. In den Umgebungen, die stehen und tragen, ist der Unterschied selten das Modell, es ist das Fundament, auf dem sie laufen. Nicht zufällig kommt der Rat im selben Gartner-Text: Agenten nur dort betreiben, wo ein klarer Wert oder ROI erkennbar ist. Wir lesen das nicht als Verkaufssperre, sondern als Planungsregel: sie gilt für die Infrastruktur genauso, die man dafür baut.

Wo Agenten heute realistisch tragen, entscheidet der Arbeitsalltag: wiederkehrende Abläufe, gut abgegrenzt, fehlertolerant: Routine-Diagnose, Protokoll-Lesen, Vorfall-Vorsortierung, Ticketpflege. In unserem Blog-Beitrag zur Rolle der KI in der Linux-Server-Administration (KI in der Linux-Server-Administration, DE) beschreiben wir die Betriebsseite desselben Themas: die Modelle, die heute lokal laufen können, und das Monitoring, das dazu passt.

3. Hosten: On-Premise, Colocation, Cloud

Wo Ihre Modelle leben: Sie bestimmen es

Es gibt drei sinnvolle Orte für Agent-Stacks, und keiner davon verlangt eine Glaubensentscheidung: On-Premise auf Ihrer Hardware, Colocation in einem Rechenzentrum Ihrer Wahl oder eine Cloud-Region, die Sie kontrollieren. Der Unterschied liegt nicht im Modell, sondern im Datenpfad und im Verantwortungsbereich: Was auf Ihren Maschinen verarbeitet wird, verlässt Ihren Perimeter nicht; was in einer Cloud-Region läuft, unterliegt deren Betriebsvertrag; beide Wege sind legitim, solange Protokolle, Zugriffe und Wiederherstellung unter Kontrolle bleiben.

Wir betreuen selbst Umgebungen in allen drei Formen (On-Premise in München, Colocation in Frankfurt, Cloud-Native in einer Cloud-Region) und empfehlen die Form nach Arbeitslast und Datenschutz-Notwendigkeiten, nicht aus Prinzip. Cloud-Aufbau und -Migration benennen wir im Serviceangebot; EU-Cloud-Regionen sind bei Datenschutz-Notwendigkeiten der Standard-Fall.

Dediziertes GPU-Hosten heißt im Kern: Die Kapazität hinter Ihren Inferenz-Workloads steht unter derselben Betriebsdisziplin wie der Rest Ihres Stacks, gemeinsam mit Ihnen dimensioniert, gepatcht, überwacht und neu startbar, unabhängig davon, wo die GPUs stehen. Die konkrete Form ist damit verbindlich festgelegt: dedizierte GPU-Server in unserem eigenen Rechenzentrum sowie der Betrieb kundeneigener GPU-Hardware.

Lokale Modelle: die Betriebsrealität

Lokale Modelle haben einen unbestreitbaren Vorteil: Der Datenpfad bleibt kurz und in Ihrem Perimeter, und der Stack skaliert mit Ihrer Dimensionierung, nicht mit der Nutzung. Dazu gehört die ungeschönte zweite Hälfte: Lokal heißt nicht automatisch sicher. Auch ein lokaler Stack schreibt Protokolle, hält Kontexte im Speicher und braucht ein Rechte-Muster; die Architektur entscheidet, ob diese Fläche klein bleibt. Was lokal entfällt, ist der Anbieteranteil des Datenwegs; was lokal dazukommt, ist der eigene Betriebsanteil.

Die Dimensionierung ist Handwerk, kein Geheimwissen. Beispielrechnung (ausdrücklich gekennzeichnet): Die 8B-Variante von Metas Llama 3.1 hat laut Model Card ein Kontextfenster von 128k; die quantisierte Q4_K_M-Fassung in der Ollama-Bibliothek liegt bei rund 4,9 GB Modellgröße (8,03B Parameter). Solche Modelle laufen auf Hardware, die Selbst-Hoster ohnehin betreiben, wobei die Praxis weit mehr Kalkulationsspielraum braucht als die nackte Modellgröße: Hauptspeicher für Kontext und Zwischenspeicher, Speicherraum für Logs und Artefakte, CPU-GPU-Auswuchtung je Aufgabentyp. Wer die Größe der Modelle kennt, kann auch den Rest planen: Modell-Updates kommen im Zyklus, wie andere Software-Updates sie mitbringen, und ein Rollback auf eine getestete Version ist kein Extra, sondern Teil des Pakets.

Große Modelle in einer kontrollierten Cloud-Region bleiben der ergänzende Pol für Aufgaben mit hohem Qualitätsanspruch; der Mix ergibt sich je Aufgabe, nicht als Einmaleinrichtung. Vektorstores und Retrieval-Komponenten laufen in diesem Bild wie jeder andere Service: versioniert, gesichert, überwacht; nichts davon ist „einfach ein Embedding“.

Model-Serving und Agent-Runtimes

Der dauerhafte Betrieb eines Agent-Stacks gliedert sich in zwei Betriebskomponenten:

1. Model-Serving: Modelle laufen containerisiert (Docker, Podman, Kubernetes), versioniert und neu startbar; Modell-Updates folgen denselben Mustern wie andere Software-Updates: getestet, protokolliert, reversibel. Rollback-Pfade werden nicht improvisiert, sondern geplant.
2. Agent-Runtimes: Agenten bekommen eine eigene Spur: Sandboxes mit Least-Privilege-Credentials statt administrativer Schlüssel; offene Agenten-Frameworks (etwa OpenClaw oder Hermes) als Orchestrierung, die nur über definierte Wege auf Ihre Systeme zugreifen. Je Agent eine eigene Identität, keine geteilten Keys; was ein Agent aufrufen darf, steht an der Zugriffsstelle, nicht in der Orchestrierung.

Beide Komponenten teilen denselben Grundsatz: Die Runtime entscheidet, was ein Agent tut; die Rechte- und Zugangsschicht entscheidet, was er darf. Nur dort sind Rechte auditierbar, nur dort entziehbar.

4. Sichern: Netzwerk-Isolation und Härtung

Segmente, Allowlists, VPN-Zugriff

Ein Agent-Stack gehört in eigene Netzsegmente, getrennt von Ihrem Prod-Verkehr, Ihrem Backoffice und allem, was nicht dazugehören muss. Die Muster dafür sind Standard-DevOps-Handwerk; für Agenten sind sie Pflicht statt Option. Der Grund liegt im Aufrufmuster: Agenten überschreiten von Natur aus Vertrauensgrenzen: sie holen sich Kontext aus dem einen System, um im anderen zu handeln. Ohne Segmente und Allowlist-Regeln wird jede dieser Grenzüberschreitungen stillschweigend genehmigt:

• ▸Eigene Netzsegmente und Firewall-Regeln für Agent-Workloads, gemeinsam mit Ihnen abgestimmt
• ▸Agenten erreichen Ihre Systeme ausschließlich über explizite Allowlist-Regeln, keine offenen Pfade
• ▸Administrativer Zugriff nur per VPN; Agenten-Verwaltung und sonstiger Admin-Verkehr getrennt

Diese Struktur gibt Ihnen zwei Dinge, die sonst kaum erreichbar sind: eine kleine, erklärbare Angriffsfläche und die Fähigkeit, im Störungsfall nachzuvollziehen, was ein Agent gerade erreicht hat. Mit Segmentierung wird ein Störungsfall von „irgendwo im Verbund“ zu „im Agenten-Segment“: abgrenzbar, eingrenzungsfähig, wieder freigebbar.

Secrets und Credentials

Zugangsdaten haben im Agent-Stack keinen Platz im Arbeitskontext: Keine Keys in Prompts, keine gemeinsamen Admin-Zugänge, keine in der Orchestrierung hartkodierten Pfade. Geheimnisse werden als Geheimnisse verwaltet und zur Laufzeit injiziert, nicht im Agenten-Kontext gespeichert. Rotation gehört dazu: Credentials, die regelmäßig wechseln, machen auch den Fall handhabbar, in dem ein Agent-Verhalten auffällig wird; der Wegzug der Rechte ist dann ein Verwaltungsakt, kein Zerlegungsvorhaben.

Härtung als Arbeitsstandard

Agenten-Umgebungen verdienen kein Sonderwerkzeug, sondern denselben Härtungsstandard wie jeder Produktionsserver, mit einem Zusatz: Sie hosten ein System, das sich selbst aufruft. Bewährt hat sich in unserem Alltag:

• ▸CIS-Benchmark-Ausrichtung, CVE-Patching und SSH-Härtung als fester Standard
• ▸Rate- und Ressourcen-Limits: ein durchdrehender Agent kann seine Nachbarn nicht mitreißen
• ▸Vollständiges Aktions-Logging je Agent, eingespeist in die Audit-Log-Prüfung, und protokolliert auch, wer Rechte vergibt oder entzieht

Die Log-Spur ist mehr als Nachweis: Sie ist die Rohfassung jeder späteren Analyse: Debugging, Audit, Vorfallberichte. Wer sie von Anfang an verlangt, betreibt ein System; wer sie erst nach dem ersten Zwischenfall einführt, beschreibt bis dahin ein Experiment. Zur Log-Spur gehört auch die Vorhaltedauer: Legen Sie fest, wie lange Aktions-Protokolle greifbar bleiben; wir richten die Speicherung danach ein, so dass Rückfragen nicht ins Leere laufen.

Klein halten, schnell stoppen

Zwei Fragen entscheiden über die Sicherheit: Wie wenig darf der Agent? Und: Wie schnell stoppen Sie ihn? Die Antwort auf die erste heißt Least Privilege: je Agent eigene Credentials, gebunden an die konkrete Aufgabe, entziehbar und ablaufend. Die Antwort auf die zweite heißt Kontrollebene: Unumkehrbare Aktionen laufen über bestätigte Schritte; jeder Agent-Prozess ist stoppbar; Notfallprozeduren werden geübt, nicht nur dokumentiert. Ein Agent, den niemand beobachtet, ist kein Betrieb; er ist ein Experiment, das auf seinen Zwischenfall wartet. Und weil Rechte vergeben und entzogen werden, gehört auch diese Vorgeschichte ins Protokoll: Wer wann welchem Agenten welche Berechtigung gab, ist spätestens bei einer Rückfrage nach dem Vorfall relevant.

5. Betreiben: Monitoring, Backup, Recovery

Monitoring, das die Schleife sieht

Agenten schlafen nicht, die Infrastruktur dahinter darf es auch nicht. Wir binden GPU-Hosts, Model-Serving und Agent-Runtimes ins Monitoring ein (Grafana und Prometheus, Ihre Instanz oder unsere), mit Metriken für Laufzeit, Fehlerquote, Werkzeugaufrufe und Kapazität. Ein Agent-Stack hat über die klassischen Server-Metriken hinaus eigene Signale, die man erst einmal führen muss: dauert ein Werkzeugaufruf länger als gewohnt, häufen sich Wiederholungen, verlangsamt sich eine Schleife, wächst die Warteschlange an der GPU: alles Zustände, die man sieht, wenn man sie misst, und verpasst, wenn man sie nicht misst. Alarme laufen in die Kanäle, die Sie bereits nutzen, statt eine neue Insel zu gründen. Proaktives Monitoring und Alerting gehören bei jedem Engagement zum Lieferumfang, kein Zusatz.

Backups mit getesteter Wiederherstellung

Modell-Artefakte, Agent-Zustände und Konfigurationen brauchen durchdachte Backup-Strategien, und Wiederherstellungsprozesse, die wirklich getestet wurden, kein „funktioniert wahrscheinlich“. Der Unterschied zu klassischen Backups liegt im Tempo der Systeme: Agent-Zustände ändern sich während des Betriebs; eine Wiederherstellung muss deshalb auch die Frage beantworten, welche Konsistenz Sie brauchen: die letzte bestätigte Handlung, nicht den letzten geschriebenen Zustand. Ein Restore, der ohne Übung zum Einsatz kommt, ist kein Restore, sondern eine Suche.

Betreiben unter Melde- und Transparenzpflichten: keine Rechtsberatung

Wir sind keine Rechtsanwälte, und in diesem Abschnitt steht keine Rechtsberatung. Aber die Regulierungslage ist eine Betriebslage, und sie trifft Agent-Stacks konkret: Nach der NIS-2-Richtlinie (Richtlinie (EU) 2022/2555) gelten die Vorgaben seit dem 18. Oktober 2024, und für wesentliche Vorfälle verlangt Artikel 23 eine Kette aus Frühwarnung (unverzüglich, in jedem Fall innerhalb von 24 Stunden), Meldung (innerhalb von 72 Stunden) und Endbericht (binnen eines Monats nach der Meldung). Innerhalb dieser Fristen kann man nur melden, was die eigenen Systeme belegen: wer war beteiligt, was wurde geändert, welche Daten waren betroffen. Ein Agent-Stack ohne vollständiges Aktions-Logging erzeugt genau die Lücke, die diese Fristen unausfüllbar macht.

Dasselbe Prinzip, eine zweite Ebene von Regeln: Der überwiegende Teil der EU-KI-Verordnung gilt seit dem 2. August 2026, darunter die Transparenzregeln nach Artikel 50 (Zeitleiste: Europäische Kommission, AI Act Service Desk). Nachvollziehbarkeit wird damit zur Entwurfsanforderung; die Log-Struktur, die Sie für Vorfälle brauchen, ist dieselbe, die Transparenz verlangt. Zwei Zeitschläge, ein Fundament: Wer Logs so führt, dass Vorfalle innerhalb der NIS2-Fenster beantwortbar sind, hat damit bereits die Grundlage, die Transparenzpflichten verlangen, ohne zwei Log-Welten getrennt zu betreiben.

Für die Bewertung Ihrer Pflichten im Einzelfall nehmen Sie rechtliche Beratung. Unser Teil ist der Betrieb, der diese Anforderungen erfüllbar macht: Protokolle, die die Fragen beantworten, und Prozeduren, die im Störungsfall greifen.

Der Betrieb hinter diesem Paper trägt dieselben Zusagen, die wir für den Rest unseres Stacks veröffentlichen: Verfügbarkeit 24/7, Verfügbarkeitsziel 99.9% und Reaktionszeit unter 1 Stunde. Das sind keine für dieses Paper entworfenen Absichten; es sind die Kennwerte, auf denen unser Linux-Betrieb bereits läuft, unverändert übernommen für Agenten-Stacks und GPU-Hosts, weil hinter beiden dasselbe Team, dasselbe Monitoring und dieselben Eskalationswege stehen. Der Dauerbetrieb rund um die Uhr ist die Grundlage, die dieser Abschnitt von Anfang an beschrieben hat (Monitoring, getestete Wiederherstellung, protokollierte Handlungen), und sie ist die Grundlage, die Ihr Agenten-Stack erbt.

6. Vom Paper zur Zusammenarbeit

Ein Paper bleibt Papier, bis jemand es auf Ihre Umgebung anwendet. Die Zusammenarbeit mit LSA beginnt deshalb nicht mit dem Aufbau eines Stacks, sondern mit einer Bestandsaufnahme, und nach jedem Schritt folgt eine Ihrer Entscheidungen:

1. 1

   Erstkontakt

   Beschreiben Sie kurz, wo Agenten in Ihren Abläufen arbeiten sollen oder bereits laufen, per Formular, E-Mail oder WhatsApp; wir melden uns zurück, und es entscheidet sich, ob die Bestandsaufnahme der richtige Einstieg ist.

2. 2

   Bestandsaufnahme

   Wir erfassen, was läuft (Server, Netze, Zugriffswege, Datenflüsse, bestehende Automatisierung) und arbeiten aus dem laufenden Betrieb statt aus einem Formular-Dialog die Abläufe heraus, in denen ein Agent mehrstufige Arbeit übernehmen kann. Wer uns bereits betreut, hat hier einen Vorsprung: Umgebung, Historie und Sicherheitsniveau sind teilweise schon bekannt; die Aufnahme beginnt dann nicht bei null.

3. 3

   Empfehlung & Roadmap

   Stack-Empfehlung, priorisierte Einsatzfälle und Sicherheitsrahmen stehen schriftlich, inklusive einer offenen Antwort, wo Agenten (noch) nicht tragen. Sie bekommen die Begründung in einem Briefing erläutert; Freigabe ist Ihre, nicht unsere.

4. 4

   Aufbau & Betrieb

   Nach Ihrer Freigabe bauen wir auf: GPU-Kapazität, Model-Serving, isolierte Runtimes, Monitoring und Backup-Strategien; alles dokumentiert so so, dass Ihr Team oder jeder spätere Betreiber die Umgebung sicher fahren kann, und betreiben es danach dauerhaft. Ihr Team behält jederzeit vollen Zugriff.

Uns leitet derselbe Maßstab, den Gartner in derselben Prognose anlegt: Agenten nur dort betreiben, wo ein klarer Wert oder ROI erkennbar ist. Die Bestandsaufnahme kann deshalb mit der Antwort enden, dass Agenten in Ihrer Umgebung heute noch keinen Mehrwert bringen. Diese Antwort ist ein Ergebnis, kein Versäumnis, und sie ist der günstigste Zeitpunkt, um es zu wissen.

Der Ablauf ist bewusst so gebaut, dass jede Stufe ein schriftliches Zwischenergebnis hinterlässt, das Ihnen gehört: Sie können nach jeder Stufe anhalten, verschieben oder weiterziehen. Was an keinem Punkt dieses Ablaufs passiert: Ein Stack entsteht ohne Ihre schriftliche Freigabe; die Roadmap ist das Entscheidungsdokument, keine Vollmacht.

7. Schluss

Agenten verlagern die eigentliche Arbeit an den Projektanfang: Bevor das Modell startet, entscheidet das Fundament: das Hosting (On-Premise, Colocation oder Cloud, je nach Arbeitslast und Datenschutz-Notwendigkeit), die Isolation (Segmente, Allowlists, getrennte Runtimes) und der Betrieb (Monitoring, protokollierte Handlungen, getestete Wiederherstellung). Die Disziplin, die Agent-Stacks brauchen, besitzen gut geführte Linux-Umgebungen bereits, vervollständigt wird sie um Isolation, Aktions-Logging und Rechte-Verwaltung. Nichts davon braucht einen Neustart Ihrer Praxis; es ist dieselbe Praxis, um einen neuen Baustein erweitert.

Wenn Sie prüfen wollen, wo Agenten in Ihren Abläufen tragen, und was das Fundament dafür heute schon hergibt: Sprechen Sie mit uns über Ihre Umgebung. Das Infrastruktur-Briefing ist kostenlos, und Sie behalten die Entscheidung.

Quellen

1. Gartner, Inc.: "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027" (Pressemitteilung, 25.06.2025) — „Over 40% of agentic AI projects will be canceled by the end of 2027, due to escalating costs, unclear business value or inadequate risk controls“; darin: „33% of enterprise software applications will include agentic AI by 2028, up from less than 1% in 2024“; „at least 15% of day-to-day work decisions will be made autonomously through agentic AI by 2028, up from 0% in 2024“; „Gartner recommends agentic AI only be pursued where it delivers clear value or ROI“. Direkt-Fetch blockiert; verifiziert über Webarchiv-Snapshot (20250926185809, web.archive.org, abgerufen 2026-11-01).https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027
2. McKinsey & Company: "The state of AI: How organizations are rewiring to capture value" (12.03.2025) — „More than three-quarters of respondents now say that their organizations use AI in at least one business function.“ Direkt-Fetch bot-gebunden (Timeout); verifiziert über Webarchiv-Snapshot (20251229181420, web.archive.org, abgerufen 2026-11-01); die exakten Prozentwerte (78/72/55) erscheinen im Archivtext nicht — deshalb bewusst als „mehr als drei Viertel“ wiedergegeben.https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai-how-organizations-are-rewiring-to-capture-value
3. Richtlinie (EU) 2022/2555 (NIS2), offizieller EUR-Lex-Text (CELEX 32022L2555) — Artikel 41(1): „By 17 October 2024, Member States shall adopt and publish the measures necessary to comply with this Directive. … They shall apply those measures from 18 October 2024.“; Artikel 23: Frühwarnung „within 24 hours of becoming aware of the significant incident“, Meldung „within 72 hours“, Endbericht „not later than one month after the incident notification“. Direkt-Fetch blockiert; verifiziert über Webarchiv-Snapshot des ELI-Permalinks (20261005173546, web.archive.org, abgerufen 2026-11-01).https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng
4. Europäische Kommission: „Timeline for the Implementation of the EU AI Act“ (AI Act Service Desk) — Meilenstein „02 Aug 2026 — The majority of rules of the AI Act come into force and enforcement starts for applicable rules. Transparency rules (Article 50) start to apply.“ (live abgerufen 2026-11-01).https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act
5. Meta: Llama-3.1-Model-Card (meta-llama/Llama-3.1-8B-Instruct, Hugging Face) — 8B/70B/405B, Kontextfenster „128k“ (live abgerufen 2026-11-01). · Ollama Library: llama3.1:8b-instruct-q4_K_M — „4.9GB“, „model arch llama · parameters 8.03B · quantization Q4_K_M“ (live abgerufen 2026-11-01).https://huggingface.co/meta-llama/Llama-3.1-8B-Instructhttps://ollama.com/library/llama3.1:8b-instruct-q4_K_M
6. LSA Live-Bestand (eigene Fetches 2026-11-01): Umgebungs-Satz auf allen drei Startseiten (DE: „Ob On-Premise in München, Colocation in Frankfurt oder Cloud-Native in [Anbieter-Region — gemäß Kopierregel (d), 2026-11-01, nicht übernommen]: Wir passen uns Ihrer Sprache und Ihrem Stack an.“); /service-support-Leistungszeilen („Sicherheitshärtung & Audits CIS-Benchmarks, CVE-Patching, SSH-Härtung, Audit-Log-Review“; „Netzwerk & Firewall Firewall-Konfiguration, VPN-Setups“); Tech-Stack-Zeile („Linux · Nginx · systemd · Docker/Podman · Kubernetes · Ansible · Terraform · [Anbietername — Regel (d)] · Grafana · Prometheus“); Cloud-Karte („[Anbieternamen — Regel (d)] — Aufbau und Migration von Cloud-Umgebungen“); KI-Blogbeiträge live auf allen drei Domains (.de-Slug ai-transforming-linux-server-admin, .com-Slug gleich, .cz-Slug jak-ai-meni-spravu-linux-serveru).