A rewrite kész. A monolit szét van bontva service-ekre, a pipeline zöld, és ott állok az igazgatóság előtt, amikor jön a kézenfekvő következő kérdés: rendben, és akkor AI-ready ez? A tanácsom mindig ugyanaz: lassítsuk le ezt a beszélgetést. Mert az őszinte válasz az, hogy »részben«, és a hiányzó rész az, amit senki nem tervezett be a büdzsébe.
Ehhez a különbséghez térek vissza mindig. A modernizációtól AI-capable lesz a szoftvered, vagyis képes lesz beszélni az AI-jal. A platformtól lesz AI-ready, vagyis alkalmas AI-futtatásra éles környezetben. A kettő nem ugyanaz, és a köztük lévő rés az, ahol a legtöbb program csendben megfeneklik.
Először pontosítanom kell, hogyan jutunk el egyáltalán a zöld pipeline-ig. A Glosternél a modernizációt agent-accelerated, de human-led módon visszük: az ügynökök viszik a rutinmunkát, a mérnökeink viszik az architektúrát és a döntéseket. Pont ez ad szabad kezet ahhoz, hogy a platformról szóló, nehezebb beszélgetést is le tudjuk folytatni.
Kérdezz meg tíz mérnökcsapatot, mitől AI-ready egy alkalmazás, és a legtöbb a szoftverréteget írja le: egy API, amit a modell meg tud hívni, egy adatpipeline, aminek az adatminősége elég jó a modell betáplálásához, és egy service, ami promptot fogad és választ ad vissza. Ez valós munka, és ez az a rész, amit egy modernizációs projekt magától megtermel. Így a szoftvered már tud beszélni az AI-jal.
A másik rész a kód alatt van. Ez a runtime. Ahhoz, hogy egy alkalmazás éles környezetben tényleg AI-jal dolgozzon, a platformnak, amin fut, terhelés alatt is megbízhatónak kell lennie, az edge-en kontrollálhatónak, alapértelmezés szerint biztonságosnak, és teljesítményben elbírnia az inferenciát. Ezek az infrastruktúra jellemzői, nem a kódbázisé.
Szóval két kérdés van, nem egy. Tud a szoftvered beszélni az AI-jal? A legtöbb csapat itt megáll. És AI-ready platformon fut? Ez az, amit túl későn tesznek fel, jellemzően azután, hogy az első feature már élesben van.
A különbségtétel üzletileg is számít. Ha az AI-readiness kizárólag szoftveres kérdés lenne, refaktorálással elérhetnéd. Mivel viszont nagyrészt platformkérdés, a refaktorálás elvisz egy darabon, aztán megáll. A többi már infrastruktúrális döntés, azok pedig hajlamosak drágák lenni, ha késve hozod meg őket.
Ez a rész az, ami miatt a CISO-k nem alszanak. Abban a pillanatban, amikor az alkalmazásod felhasználói inputot kezd küldeni egy modellnek, minden prompt egy belépési ponttá válik. Szó szerint. Egy szövegdoboz, amit egy LLM-re kötöttél, egy új bejárati ajtó, és nem úgy viselkedik, mint amiket a WAF-od már ismer.
Három kockázat, ami minden általam vitt review-n felbukkan.
Nem tudod kontrollálni azt, amit nem látsz, és minden védtelen prompt egy bekövetkezésre váró adatszivárgás.
Az AI-forgalom kontrollálása azt jelenti, hogy még azelőtt átvizsgálod, hogy a modell látná: elkapod az injection-kísérleteket, blokkolod a jailbreak-mintázatokat, és kiszűröd az érzékeny adatokat. Szabályozott környezetben ez az inspekciós réteg az, ami az AI-használatodat a GDPR, a NIS2 és a DORA kötelezettségeire képezi le. Enélkül egy olyan compliance-rést üzemeltetsz, amit még megmérni sem tudsz.
Ezért mozdult el a beszélgetés a hagyományos cloud stacken túlra, az olyan edge platformok felé, mint a Cloudflare. Az érv egyszerű: azok a biztonsági, governance- és teljesítménytulajdonságok, amelyektől egy alkalmazás AI-ready lesz, már léteznek globális hálózatként, tehát implementálod őket ahelyett, hogy összeraknád.
A nagyságrendeket érdemes kereken kimondani, mert ez az a fajta védelem, amit szinte egyetlen szervezet sem tudna magának megépíteni. A Cloudflare hálózata naponta több mint 230 milliárd kiberfenyegetést blokkol (Cloudflare 2026 Threat Report, 2026. március 3.). 2025 szeptemberében automatikusan mitigált egy akkori rekordot jelentő, 22,2 Tbps-os DDoS-támadást 330-nál is több városban világszerte; a jelenlegi legnagyobb regisztrált támadás a 2025. november eleji, 31,4 Tbps-os (Cloudflare 2025 Q4 DDoS Report / 2026 Threat Report). A hálózat minden, mások ellen irányuló fenyegetésből tanul, mielőtt az egyáltalán eljutna hozzád. Pontosan ez a közös védelem a platform használatának a lényege: a te threat modelled profitál minden más célpontból, ami ugyanazon a hálózaton van.
Ugyanezt magadnak megépíteni, vagyis a globális threat mitigationt, az adatvesztés-megelőzést, a shadow-AI governance-t és az edge inferenciát, többéves program. A Cloudflare implementálásával sok minden az első napon készen áll.
Nem teszek úgy, mintha a hálózat sosem esne ki. 2025. november 18-án a Cloudflare-nek kb. háromórás, a kritikus szolgáltatásokat érintő kiesése volt (teljes helyreállás ~5 óra 46 perc), a legsúlyosabb 2019 óta. Amit utána láttam, az a lényeg. Matthew Prince még aznap publikált egy részletes, nyilvános root-cause elemzést. 2025. december 19-én Dane Knecht bejelentett egy »Code Orange: Fail Small« nevű resilience-programot, válaszul a november 18-i és a december 5-i kiesésre is, épp azért, hogy egy hiba egy szeletet rontson el, ne az egészet.
Egyetlen platform sem tévedhetetlen; a lényeg, hogyan hibázik, és milyen nyíltan reagál. Ezen a mércén a transzparencia többet mondott nekem, mint egy makulátlan előélet. Így néz ki a tudatos bizalom: inkább építek olyan platformra, ami megmutatja a hibáit, mint olyanra, ami elrejti.
Use case 1: biztonságos AI-hozzáférési réteg
Megtartod a meglévő infrastruktúrádat, és egy kontrollált, forgalomszűrt utat helyezel a modelljeid elé. A Zero Trust és a Cloudflare Tunnel kizárólag kimenő irányú kapcsolatot épít, így nincs kitett bejövő felület. Az AI Gateway láthatóságot és kontrollt ad a modellforgalom felett. A WAF és az AI Security for Apps injectionre, jailbreakre és PII-re szűri a promptokat, még mielőtt elérnék a modellt.
A trade-off, egyenesen megfogalmazva: eggyel több TLS-hop lesz az útvonalon, a tunnel és a kliens kiterjesztése a teljes informatikai szervezetre pedig tervezést és change managementet igényel. Cserébe governance-t kapsz az AI-forgalom felett anélkül, hogy az alatta lévő rétegekhez hozzá kellene nyúlnod.
Use case 2: építs és futtass AI-t a Cloudflare-en
Az első pillanattól a platformra építesz. A Workers és a Workers AI edge-en futtatja az inferenciát, az AI Gateway kerül elé, a Vectorize AutoRAG-gel oldja meg a retrievalt, az R2 és a D1 tárolja az adataidat, a Workflows pedig orkesztrálja a lépéseket.
A trade-off, egyenesen: a Workers memória- és CPU-plafonja meghatározza, mit tudsz egyáltalán az edge-en futtatni, egy natív modell melletti elköteleződés pedig architekturális döntés, amit tudatosan hozol meg. Cserébe a retrieval és az inferencia a felhasználóiddal egy helyen fut, beépítve, nem utólag ráaggatva.
Attól, hogy a platform készen áll, a bekötés még nem triviális. Eldönteni, melyik minta illik a szervezetedhez, hol legyen az inspekciós határ, hogyan folyik át rajta az identity, és hogyan képződik le a compliance-kötelezettségeidre: ez mérnöki munka, ami a modernizált szoftvered és az alatta lévő platform között ül.
Ebben a térben dolgozik a csapatom. Microsoft Solutions Partnerként, AWS Select Partnerként és Cloudflare partnerként, több mint 20 év vállalati projektszállítási tapasztalattal a hátunk mögött, az AI-readinesst a modernizáció utáni következő mérnöki fázisként kezeljük. Az együttműködés három szakaszban fut. Felmérés: feltérképezzük a szervezetet és az AI-ambícióit. Eco-design: megtervezzük a cél-architektúrát. Megvalósítás: megvalósítjuk, agent-accelerated, human-led módon, végig audit-ready állapotban. A modelljeid és az adataid a tieid maradnak.
Vedd fel velünk a kapcsolatot, és beszéljük át, hol tart a szervezeted!
The rewrite is done. The monolith is broken into services, the pipeline is green, and I am standing in front of the board when someone asks the obvious next question: right, so is it AI-ready? My advice, every time, is to slow that conversation down. Because the honest answer is »partly«, and the part that is missing is the part nobody budgeted for.
Here is the distinction I keep coming back to. Modernisation makes your software AI-capable. The platform makes it AI-ready. They are not the same thing, and the gap between them is where most programmes quietly stall.
I should be plain about how we get to that green pipeline in the first place. At Gloster we run modernisation agent-accelerated but human-led: agents take the routine lifting, my engineers own the architecture and the judgement. That is what leaves us free to have the harder conversation about the platform underneath.
Ask ten engineering teams what makes an application AI-ready and most describe the software layer: an API the model can call, a data pipeline clean enough to feed it, a service that can accept a prompt and return a response. That is real work, and it is the half a modernisation project naturally produces. Your software can now talk to AI.
The other half sits underneath the code. It is the runtime. For an application to genuinely work with AI in production, the platform it runs on has to be reliable under load, controllable at the edge, safe by default, and performant enough for inference. Those are properties of infrastructure, not of the codebase.
So there are two questions, not one. Can your software talk to AI? Most teams stop here. And does it run on an AI-ready platform? This is the one that gets asked too late, usually after the first feature is already live.
The distinction matters commercially. If AI-readiness were purely a software concern, you could reach it by refactoring. Because it is largely a platform concern, refactoring gets you partway and then stops. The rest is an infrastructure decision, and those have a habit of being expensive when they are made late.
Here is the part that keeps CISOs awake. The moment your application starts sending user input to a model, every prompt becomes a way in. I mean that literally. A text box wired to an LLM is a new front door, andit does not behave like the ones your WAF already knows.
Every prompt is now an attack surface — three risks that show up on every review
You cannot govern what you cannot see, and every unguarded prompt is a leak waiting to happen.
Governing AI traffic means inspecting it before the model sees it: catching injection attempts, blocking jailbreak patterns, and stripping personally identifiable information at the boundary. In regulated settings that inspection layer is what maps your AI usage to GDPR, NIS2, and DORA obligations. Without it, you are running a compliance gap you cannot even measure.
This is the reason the conversation has moved beyond the traditional cloud stack toward edge platforms such as Cloudflare. The argument is straightforward: the safety, governance, and performance properties that make an application AI-ready already exist as a global network, so you adopt them rather than assemble them.
The scale figures are worth stating plainly, because they are the kind of protection almost no single organisation could build for itself. Cloudflare's network blocks more than 230 billion cyber threats every day (Cloudflare 2026 Threat Report, 3 March 2026). In September 2025 it auto-mitigated a then-record 22.2 Tbps DDoS attack across 330+ cities worldwide; the current largest on record is the 31.4 Tbps attack of early November 2025 (Cloudflare 2025 Q4 DDoS Report / 2026 Threat Report). The network learns from every threat against everyone else before it ever reaches you. That shared-defence effect is the whole point of adopting a platform: your threat model benefits from every other target on the same network.
Building the equivalent yourself — global threat mitigation, data-loss prevention, shadow-AI governance, and edge inference — is a multi-year programme. Adopting Cloudflare, much of it is ready on day one.
I will not pretend the network never goes down. On 18 November 2025 Cloudflare had an outage of approximately three hours of core impact (full recovery ~5h46m), its worst since 2019. What I watched next is the part that matters. Matthew Prince published a public root-cause the same day, in detail. On 19 December 2025 Dane Knecht announced a resilience programme called »Code Orange: Fail Small«, in response to both the 18 November and 5 December outages, precisely so that a fault degrades a slice rather than the whole. No platform is infallible; what matters is how it fails and how openly it responds. Judged on that, the transparency told me more than a perfect record would have. That is what eyes-open trust looks like: I would rather build on a platform that shows me its failures than one that hides them.
Use case 1: a secure AI access layer
You keep your existing infrastructure and put a controlled, inspected path in front of your models. Zero Trust and Cloudflare Tunnel make the connection outbound-only, so nothing inbound is exposed. AI Gateway gives you visibility and control over model traffic. The WAF and AI Security for Apps screen prompts for injection, jailbreaks, and PII before they reach the model.
The trade-off, stated plainly: you add one extra TLS hop, and rolling out the tunnel and client across an estate takes planning and change management. In return you get governance over AI traffic without rebuilding anything underneath.
Use case 2: build and run AI on Cloudflare
You build on the platform from the start. Workers and Workers AI give you inference at the edge, AI Gateway sits in front of it, Vectorize with AutoRAG handles retrieval, R2 and D1 hold your data, and Workflows orchestrate the steps.
The trade-off, stated plainly: Workers carry a memory and CPU ceiling that shapes what you can run at the edge, and committing to a native model is an architectural choice you make deliberately. In return you get retrieval and inference co-located with your users, built in rather than retrofitted.
The platform being ready-made does not make the wiring trivial. Deciding which pattern fits your estate, where the inspection boundary should sit, how identity flows through it, and how it maps to your compliance obligations is engineering work that sits between your modernised software and the platform beneath it.
That is the space my team works in. As a Microsoft Solutions Partner, AWS Select Partner, and Cloudflare partner, with over 20 years of enterprise delivery behind us, we treat AI-readiness as the next engineering phase after modernisation. The engagement runs in three stages. We Explore the estate and its AI ambitions. We Eco-design the target architecture. We Implement it, agent-accelerated, human-led, and audit-ready throughout. Your models and data stay yours.
Get in touch to talk through your platform position!
Die Modernisierung ist abgeschlossen. Der Monolith ist in Services zerlegt, die Pipeline läuft grün, und ich stehe vor dem Vorstand, als jemand die naheliegende Frage stellt: »Gut – und ist das jetzt KI-ready?« Mein Rat ist jedes Mal derselbe: an dieser Stelle das Tempo herausnehmen. Denn die ehrliche Antwort lautet »teilweise«, und der fehlende Teil ist genau der, den niemand eingeplant hat.
Hier ist die Unterscheidung, auf die ich immer wieder zurückkomme: Modernisierung macht Ihre Software KI-fähig. Die Plattform macht sie KI-ready. Das ist nicht dasselbe, und in der Lücke dazwischen geraten die meisten Programme unbemerkt ins Stocken.
Dazu gehört auch, offenzulegen, wie wir überhaupt zu dieser grünen Pipeline kommen. Bei Gloster modernisieren wir agentenbeschleunigt, aber menschengeführt: Agenten übernehmen die Routinearbeit, meine Entwickler verantworten Architektur und fachliche Bewertung. Genau das verschafft uns den Freiraum für das schwierigere Gespräch über die Plattform darunter.
Fragen Sie zehn Engineering-Teams, was eine Anwendung KI-ready macht, und die meisten beschreiben die Softwareschicht: eine API, über die sich das Modell aufrufen lässt, eine Datenpipeline, die sauber genug ist, um es zu versorgen, einen Service, der einen Prompt annimmt und eine Antwort zurückgibt. Das ist echte Arbeit – und es ist die Hälfte, die ein Modernisierungsprojekt ohnehin mit hervorbringt. Ihre Software kann jetzt mit KI sprechen.
Die andere Hälfte liegt unter dem Code: die Laufzeitumgebung. Damit eine Anwendung im Produktivbetrieb wirklich mit KI arbeitet, muss die Plattform, auf der sie läuft, unter Last zuverlässig, am Edge steuerbar, standardmäßig sicher und performant genug für Inferenz sein. Das sind Eigenschaften der Infrastruktur, nicht der Codebasis.
Es gibt also zwei Fragen, nicht eine. Kann Ihre Software mit KI sprechen? Die meisten Teams hören hier auf. Und läuft sie auf einer KI-ready-Plattform? Diese Frage wird zu spät gestellt – meist erst, wenn das erste Feature schon live ist.
Die Unterscheidung ist auch kommerziell relevant. Wäre KI-Readiness eine reine Softwarefrage, ließe sie sich durch Refactoring lösen. Weil sie größtenteils eine Plattformfrage ist, bringt Refactoring Sie ein Stück weit – und dann nicht weiter. Der Rest ist eine Infrastrukturentscheidung, und solche Entscheidungen werden erfahrungsgemäß teuer, wenn man sie zu spät trifft.
Jetzt zu dem Teil, der CISOs den Schlaf raubt. In dem Moment, in dem Ihre Anwendung Nutzereingaben an ein Modell schickt, wird jeder Prompt zu einem Einfallstor. Das meine ich wörtlich: Ein Textfeld, das an ein LLM angebunden ist, ist eine neue Eingangstür – und sie verhält sich anders als die, die Ihre WAF bereits kennt.
KI-Traffic zu steuern heißt, ihn zu prüfen, bevor das Modell ihn sieht: Injection-Versuche abfangen, Jailbreak-Muster blockieren und personenbezogene Daten schon am Edge entfernen. In regulierten Umgebungen ist diese Prüfschicht das, was Ihre KI-Nutzung mit DSGVO-, NIS2- und DORA-Pflichten in Einklang bringt. Ohne sie haben Sie eine Compliance-Lücke, die Sie nicht einmal beziffern können.
Drei Risiken, die in jedem Review auftauchen
Sie können nicht steuern, was Sie nicht sehen, und jeder ungeschützte Prompt ist ein Leak, das nur auf seine Gelegenheit wartet.
Genau deshalb hat sich das Gespräch über den klassischen Cloud-Stack hinaus zu Edge-Plattformen wie Cloudflare verlagert. Das Argument ist einfach: Die Sicherheits-, Governance- und Performance-Eigenschaften, die eine Anwendung KI-ready machen, existieren bereits als globales Netzwerk – Sie können sie nutzen, statt sie selbst zusammenzusetzen.
Die Größenordnungen sollte man klar benennen, denn sie stehen für ein Schutzniveau, das kaum eine einzelne Organisation für sich allein aufbauen könnte. Cloudflares Netzwerk blockiert täglich mehr als 230 Milliarden Cyberbedrohungen (Cloudflare 2026 Threat Report, 3. März 2026). Im September 2025 wehrte es automatisch einen damaligen Rekord-DDoS-Angriff von 22,2 Tbps ab, verteilt über mehr als 330 Städte weltweit; der größte je verzeichnete Angriff liegt inzwischen bei 31,4 Tbps und stammt von Anfang November 2025 (Cloudflare 2025 Q4 DDoS Report / 2026 Threat Report). Das Netzwerk lernt aus jeder Bedrohung, die sich gegen andere richtet – noch bevor sie Sie erreicht. Genau darin liegt der Sinn, eine fertige Plattform zu nutzen: Ihr Bedrohungsmodell profitiert von jedem anderen Ziel im selben Netzwerk.
Das Äquivalent selbst zu bauen – globale Bedrohungsabwehr, Data Loss Prevention, Shadow-AI-Governance und Edge-Inferenz – ist ein mehrjähriges Programm. Wenn Sie auf Cloudflare setzen, steht vieles davon am ersten Tag bereit.
Ich will nicht behaupten, dass das Netzwerk nie ausfällt. Am 18. November 2025 hatte Cloudflare eine Störung, deren Hauptauswirkungen rund drei Stunden anhielten (vollständige Wiederherstellung nach rund fünf Stunden und 46 Minuten) – die schwerste seit 2019. Was danach geschah, ist der Teil, der zählt: Matthew Prince legte noch am selben Tag eine detaillierte Ursachenanalyse öffentlich vor. Am 19. Dezember 2025 kündigte Dane Knecht als Reaktion auf die Störungen vom 18. November und 5. Dezember ein Resilienzprogramm namens »Code Orange: Fail Small« an – genau darauf ausgelegt, dass ein Fehler künftig nur einen Ausschnitt trifft und nicht das Ganze.
Mir sagt diese Transparenz mehr als eine makellose Bilanz. Ich baue lieber auf einer Plattform, die mir ihre Fehler zeigt, als auf einer, die sie verbirgt. So sieht bewusstes Vertrauen aus.
Anwendungsfall 1: eine sichere KI-Zugriffsschicht.
Sie behalten Ihre bestehende Infrastruktur und legen einen kontrollierten, geprüften Pfad vor Ihre Modelle. Zero Trust und Cloudflare Tunnel machen die Verbindung ausschließlich ausgehend, sodass eingehend nichts offenliegt. AI Gateway verschafft Ihnen Transparenz und Kontrolle über den Modell-Traffic. WAF und AI Security for Apps prüfen Prompts auf Injection, Jailbreaks und personenbezogene Daten, bevor sie das Modell erreichen.
Trade-off: Sie fügen einen zusätzlichen TLS-Hop hinzu, und das Ausrollen von Tunnel und Client erfordert Planung und Change-Management. Dafür erhalten Sie Kontrolle über den KI-Traffic, ohne darunter etwas neu bauen zu müssen.
Anwendungsfall 2: KI auf Cloudflare bauen und betreiben.
Sie bauen von Anfang an auf der Plattform. Workers und Workers AI geben Ihnen Inferenz am Edge, AI Gateway sitzt davor, Vectorize mit AutoRAG übernimmt das Retrieval, R2 und D1 halten Ihre Daten, Workflows orchestrieren die Schritte.
Trade-off: Workers unterliegen einer Speicher- und CPU-Obergrenze, die bestimmt, was Sie am Edge betreiben können, und die Festlegung auf ein natives Modell ist eine Architekturentscheidung, die Sie bewusst treffen müssen. Dafür liegen Retrieval und Inferenz dort, wo Ihre Nutzer sind – eingebaut statt nachgerüstet.
Dass die Plattform fertig vorliegt, macht die Anbindung noch nicht trivial. Zu entscheiden, welches Muster zu Ihrem Bestand passt, wo die Prüfgrenze liegen soll, wie Identity hindurchfließt und wie sich das Ganze zu Ihren Compliance-Pflichten verhält – das ist Engineering-Arbeit, die zwischen Ihrer modernisierten Software und der Plattform darunter liegt.
Genau hier arbeitet mein Team. Als Microsoft Solutions Partner, AWS Select Partner und Cloudflare-Partner mit über 20 Jahren Enterprise-Delivery im Rücken behandeln wir KI-Readiness als die nächste Engineering-Phase nach der Modernisierung. Die Zusammenarbeit läuft in drei Stufen: Wir erkunden den Bestand und die KI-Ambitionen dahinter (Explore), gestalten die Zielarchitektur (Eco-design) und setzen sie um (Implement) – agentenbeschleunigt, menschengeführt und durchgängig auditierbar. Ihre Modelle und Daten bleiben Ihr Eigentum.
Sprechen Sie mit uns über Ihre Plattformposition!
.webp)
