24měsíční plán

Smluvní kontrolní seznam poskytuje páku; tato kapitola určuje pořadí. Záleží na tom, v jakém pořadí jsou kroky prováděny. Sekvenování se řídí třemi zásadami:

1. Diagnostika předchází smluvní obnově. Bez znalosti vlastní expozice nelze vyjednat správné smluvní doložky.
2. Smluvní obnova předchází architektonické migraci. Bez sjednaných možností výstupu není migrace proveditelná.
3. Testování odolnosti přichází až po diverzifikaci. Testování odolnosti monolitického nasazení má omezenou hodnotu.

Fáze 1: Diagnostika (Q2–Q3 2026, tři měsíce)

První fáze je čistě informační. Klade si otázku: co vlastně máme a kde jsme vystaveni riziku?

• Inventář všech dodavatelů ICT a jejich jurisdikcí. Tabulkový formát postačuje; důležitá je úplnost a aktuálnost.
• Klasifikace pracovních zátěží podle citlivosti v rámci tří vrstev digitální autonomie: bit, interpretace, instrumentace. Různé pracovní zátěže vyžadují různou míru smluvní důslednosti.
• Identifikace bodů koncentrace. Kde zajišťuje jediný dodavatel více než dva kritické systémy? Tento seznam je výchozím bodem pro plánování diverzifikace.
• Mapování expirace smluv v horizontu nejbližších 24 měsíců. Obnovení smluv jsou přirozenými okamžiky pro uplatnění kontrolního seznamu; bez tohoto přehledu se příležitosti promarní.

Výstup fáze 1: diagnostická zpráva sdílitelná s vedením organizace, identifikující 10 nejvýznamnějších rizik závislosti a kalendář příležitostí k jejich řešení.

Fáze 2: Smluvní obnova (Q3 2026 – Q1 2027, šest měsíců)

S diagnostikou v ruce druhá fáze aktivuje dostupné páky:

• Uplatnění smluvního kontrolního seznamu při každém obnovení. Nejprve stávající obnovení, poté nové smlouvy.
• Proaktivní sjednávání výstupních doložek pro 10 nejkritičtějších dodavatelů, nikoli až při obnovení smlouvy. Pokud dodavatelé odporují, odpor zdokumentujte — je to samo o sobě informace o strategickém postoji dodavatele.
• Požadavky na SBOM ve všech softwarových smlouvách.
• Aktivace BYOK/HYOK všude tam, kde to poskytovatel podporuje (AWS KMS s External Key Store, Azure Key Vault Managed HSM, Google Cloud EKM).
• Dokumentace výstupní strategie dle DORA pro finanční sektor. Pro nefinanční organizace jde o doporučenou praxi, která však zatím není zákonně povinná.

Výstup fáze 2: smluvní ustanovení, která činí migraci právně a komerčně proveditelnou, i když k samotné migraci ještě nedochází.

Fáze 3: Architektonická diverzifikace (Q1 – Q3 2027, šest měsíců)

Třetí fáze přechází od papíru k nasazení:

• Pilotní provoz jedné pracovní zátěže na evropském cloudu (OVHcloud, Scaleway nebo STACKIT). Volba pracovní zátěže je důležitá: měla by být dostatečně netriviální, aby ověřila provozní model, ale ne tak kritická, aby její selhání bylo katastrofální. Typickou první volbou jsou staging prostředí, interní nástroje nebo analytický pipeline bez kontaktu se zákazníkem.
• Pilotní nasazení Nextcloud nebo IceWarp pro jeden nekritický tým. Migrace 50členného oddělení na Nextcloud je reálným testem produktivního stacku bez vsazení celé organizace.
• Pilotní nasazení Keycloak nebo Authentik pro jednu nekritickou aplikaci. Migrace identity přináší integrační riziko; pilot v omezeném rozsahu odhalí, s čím se širší migrace setká.
• Vyhodnocení Mistral AI Studio pro jeden případ využití AI. I když produkční migrace počká, vyhodnocení vytváří základní znalostní bázi.

Výstup fáze 3: empirické, organizačně specifické znalosti o tom, co každá evropská alternativa skutečně přináší, s kvantifikovanými rozdíly oproti stávajícímu americkému stacku. Tyto znalosti jsou předpokladem pro jakákoli další rozhodnutí o migraci.

Fáze 4: Testování odolnosti (Q3 2027 – Q1 2028, šest měsíců)

Čtvrtá fáze prověřuje architekturu v praxi:

• Stolní cvičení scénářů „zablokování dodavatele". Simulujte ztrátu přístupu ke kritickému dodavateli — co by organizace podnikla, v jakém pořadí a jaké by to mělo náklady?
• Testy migrace dat v reálném čase. Přesuňte data od poskytovatele A k poskytovateli B v produkčním měřítku. Změřte čas, náklady a způsoby selhání.
• Testy plánů BC/DR s novým poskytovatelem. Plán existuje na papíře; funguje i při reálném provedení?
• Audit smluvních doložek po prvním roce provozu. Která ustanovení dodavatelé dodrželi? Která vyžadovala eskalaci? Která je třeba posílit při příštím obnovení?

Výstup fáze 4: empirický důkaz, že páková ustanovení z fáze 2 skutečně fungují, a nestojí jen na papíře.

Co tento plán neřeší

Plán se zabývá vlastní pozicí organizace vůči jejím dodavatelům. Neřeší politickou vrstvu (regulatorní diplomacii s USA, vyjednávání o výjimkách z CLOUD Act), ani problémy vyžadující kolektivní unijní akci (budování nových výrobních závodů, podpora ekosystému RISC-V, energetická politika pro datová centra). To je doménou státních plánovačů.

Ve svém záběru přináší konkrétní výsledek: v Q1 2028 organizace prokázala schopnost přejít k jinému dodavateli v řádu měsíců, nikoli let; má smluvní ustanovení, která to prakticky umožňují; testovala architekturu pod simulovaným stresem; a disponuje interní kapacitou pro provoz diverzifikovaného stacku. To je provozní smysl pojmu MVS.