AIFC-034: AI Lock-in and Exit Strategy

Status: Draft 0.1 Standard: AI-First Community Standard Zkráceně: AIFC Navazuje na:

AIFC-000 Manifest AI-first komunity
AIFC-001 Core Concepts
AIFC-002 Community Model
AIFC-010 Knowledge Structure
AIFC-011 Operational DNA
AIFC-020 Human-Managed AI
AIFC-021 AI as External Expert Capacity
AIFC-022 AI-NDA Boundary
AIFC-023 AI as Team Member
AIFC-024 Human Capability Reserve
AIFC-030 AI Capacity Planning
AIFC-031 AI Autonomy and Intensity
AIFC-032 AI Operating Modes
AIFC-033 AI Budget and Cost Control

Účel dokumentu: Definovat AI lock-in jako riziko ztráty nezávislosti komunity na konkrétním AI vendorovi, modelu, agentovi, nástroji, paměti, skill store, workflow nebo integraci. Popsat požadavky na exit strategii, přenositelnost know-how, fallback, vendor replacement, export, audit, Human Capability Reserve a ochranu Operational DNA.

1. Purpose of this document

Tento dokument definuje AI Lock-in and Exit Strategy.

AIFC připouští, že AI může být hluboce integrovaná do práce komunity.

AI může pomáhat:

psát dokumentaci,
analyzovat rozhodnutí,
navrhovat workflow,
spravovat knowledge base,
podporovat vývoj,
třídit support,
udržovat backlog,
vytvářet skills,
provozovat agenty,
akcelerovat delivery,
a pracovat s Operational DNA.

Čím hlubší je integrace AI, tím větší vzniká riziko lock-inu.

Komunita se může stát závislou na:

konkrétním vendorovi,
konkrétním modelu,
konkrétním agentovi,
konkrétním prompt workflow,
konkrétním proprietárním skill store,
agentické paměti,
konkrétním formátu knowledge base,
konkrétním Human Cockpit Layer nástroji,
konkrétní integraci,
nebo konkrétním cenovém modelu.

Tento dokument stanovuje princip:

AI may be deeply integrated.
It must not become impossible to leave.

Česky:

AI může být hluboce integrovaná.
Nesmí být nemožné ji opustit.

2. Core principle

Základní princip tohoto dokumentu je:

No critical community capability may depend on a single AI vendor, model, agent memory or proprietary workflow without an approved exit strategy.

Česky:

Žádná kritická schopnost komunity nesmí záviset na jednom AI vendorovi, modelu, agentické paměti nebo proprietárním workflow bez schválené exit strategie.

AIFC říká:

AI acceleration is welcome.
AI captivity is not.

Česky:

AI akcelerace je vítaná.
AI zajetí ne.

Exit strategy není známka nedůvěry v AI.

Je to podmínka důvěryhodného AI-first provozu.

3. Definition of AI lock-in

AI lock-in je stav, kdy komunita nemůže realisticky opustit konkrétní AI nástroj, vendora, model, agenta, skill store nebo workflow bez významné ztráty schopnosti, know-how, provozu, kvality, bezpečnosti nebo kontinuity.

AI lock-in může být:

technický,
datový,
znalostní,
procesní,
ekonomický,
smluvní,
bezpečnostní,
lidsko-schopnostní,
agentický,
nebo kulturní.

Lock-in není vždy špatný.

Každá integrace vytváří určitou závislost.

Problém vzniká tehdy, když je závislost:

neviditelná,
nekontrolovaná,
bez ownera,
bez exportu,
bez fallbacku,
bez náhrady,
bez exit plánu,
nebo přesouvá kritickou schopnost mimo komunitu.

Minimum requirement

Kritické AI závislosti musí být identifikované, vlastněné a pravidelně revidované.

4. Definition of exit strategy

Exit Strategy je předem definovaný plán, jak komunita ukončí, nahradí, omezí nebo obejde konkrétní AI závislost bez nepřijatelné ztráty schopnosti.

Exit strategy odpovídá na otázky:

Co přesně opouštíme?
Proč bychom to museli opustit?
Které workflow jsou dotčené?
Jaká data musíme exportovat?
Jaké skills musíme zachovat?
Kde je uložené know-how?
Jak nahradíme agenta?
Jaký fallback se aktivuje?
Jaký vendor nebo model může být náhradou?
Kdo rozhodne o exitu?
Jak dlouho exit trvá?
Jaké riziko vznikne během přechodu?
Jak ověříme, že komunita zůstala schopná fungovat?

Minimum requirement

Kritické AI workflow musí mít exit strategii nebo explicitně schválené riziko její absence.

5. Why AI lock-in matters

AI lock-in je zásadní, protože AI často neukládá jen technické nastavení.

Může do sebe vtáhnout:

kontext,
rozhodovací logiku,
firemní jazyk,
dokumentační styl,
skills,
workflow,
prioritizaci,
backlog patterny,
zákaznické vzory,
governance pravidla,
agentickou paměť,
a Operational DNA.

Pokud toto know-how zůstane pouze v AI nástroji, komunita ztrácí vlastnictví části své schopnosti.

AI lock-in není jen vendor risk.

Je to riziko, že se část provozní inteligence komunity přesune mimo její source of truth.

Minimum requirement

AI lock-in musí být posuzován nejen technicky, ale také znalostně, procesně a lidsko-schopnostně.

6. Forms of AI lock-in

AIFC rozlišuje několik typů AI lock-inu.

6.1 Vendor lock-in

Závislost na jednom AI vendorovi.

Příklady:

proprietary API,
specifický enterprise tenant,
vendor-specific data retention,
vendor-specific pricing,
vendor-specific agent framework.

6.2 Model lock-in

Závislost na konkrétním modelu nebo jeho schopnostech.

Příklady:

workflow funguje jen s jedním modelem,
prompty jsou optimalizované na jeden model,
kvalita výstupu se zhroutí při změně modelu.

6.3 Tool lock-in

Závislost na konkrétním AI UI nebo aplikaci.

Příklady:

knowledge je v chatu,
approvals jsou v konkrétním nástroji,
export je omezený.

6.4 Agent lock-in

Závislost na konkrétním agentovi.

Příklady:

agent má unikátní memory,
agent má proprietary instructions,
agent má specifické napojení na systémy.

6.5 Skill store lock-in

Závislost na proprietárním úložišti AI skills.

Příklady:

agent skills nejdou exportovat,
skills nejsou human-readable,
skills nejsou verzované.

6.6 Memory lock-in

Závislost na agentické nebo chatové paměti.

Příklady:

důležitý kontext není v source of truth,
agent si pamatuje pravidla, která lidé neznají,
memory nelze auditovat nebo exportovat.

6.7 Workflow lock-in

Závislost na konkrétním AI workflow.

Příklady:

proces funguje jen přes AI,
neexistuje non-AI fallback,
automatizace není dokumentovaná.

6.8 Data format lock-in

Závislost na proprietárním formátu.

Příklady:

knowledge base nejde exportovat,
metadata nejsou přenositelná,
rozhodnutí jsou uzamčená v nástroji.

6.9 Human capability lock-in

Závislost vzniklá tím, že lidé přestali umět práci bez AI.

Příklady:

vývojáři neumí rutinní kód bez AI,
tým neumí psát rozhodovací podklady,
owner neumí posoudit AI výstup.

Minimum requirement

AI lock-in assessment musí rozlišovat alespoň vendor, model, data, workflow, memory a human capability lock-in.

7. Lock-in is not only technical

Technický export nestačí.

Komunita může mít data exportovaná, ale stále nemusí být schopná fungovat.

Příklad:

má export chatů,
ale neví, které části jsou platné,
nemá decision records,
nemá human skills,
nemá fallback,
nemá ownera,
nemá validátory,
nemá náhradní workflow,
neumí výstupy posoudit bez původního modelu.

AIFC proto chápe exit strategii jako kombinaci:

data portability
+ knowledge portability
+ workflow portability
+ skill portability
+ human capability
+ governance continuity

Minimum requirement

Exit strategy musí řešit nejen data export, ale i schopnost pokračovat v práci.

8. Critical dependency

Kritická AI závislost je závislost, jejíž ztráta by významně poškodila:

provoz,
zákazníky,
bezpečnost,
compliance,
decision-making,
source of truth,
Operational DNA,
human capability,
delivery,
support,
maintenance,
nebo reputaci.

Příklady kritické AI závislosti:

AI agent spravuje knowledge cleanup bez náhrady,
support triage bez AI nefunguje,
decision support je plně závislý na jednom modelu,
AI workflow aktualizuje source of truth,
agentická paměť obsahuje kritický kontext,
AI nástroj je jediným místem, kde existují skills.

Minimum requirement

Kritické AI závislosti musí mít exit strategy, fallback a ownera.

9. Lock-in assessment

AIFC doporučuje pravidelně provádět lock-in assessment.

Otázky:

Na jakém vendorovi závisíme?
Na jakém modelu závisíme?
Kde je uložena agent memory?
Jsou AI skills exportovatelné?
Jsou AI skills human-readable?
Je workflow dokumentované mimo nástroj?
Existuje non-AI fallback?
Existuje alternativní model nebo vendor?
Umí lidé workflow vykonat bez AI?
Jsou výstupy zapisované do source of truth?
Co se stane, když AI nástroj zítra vypneme?
Co se stane, když cena vzroste 3×?
Co se stane, když vendor změní podmínky?
Co se stane, když model začne dávat horší výstupy?

Minimum requirement

Kritická AI workflow musí mít lock-in assessment při zavedení a při významné změně.

10. Exit triggers

Exit strategie musí definovat, kdy se aktivuje.

Možné triggery:

vendor outage,
model degradation,
unacceptable cost increase,
AI-NDA Boundary incident,
security incident,
legal or compliance issue,
loss of data control,
terms of service change,
inability to export data,
unacceptable hallucination rate,
human capability degradation,
budget exhaustion,
strategic decision to switch vendor,
acquisition or ownership change of vendor,
loss of trust,
better alternative available.

Minimum requirement

Exit strategy musí mít definované trigger conditions.

11. Exit levels

Exit nemusí být vždy úplné ukončení.

AIFC rozlišuje úrovně exitu.

11.1 Pause

Dočasné pozastavení AI workflow.

11.2 Reduce

Snížení AI intensity nebo autonomy.

11.3 Replace

Nahrazení modelem, vendorem, agentem nebo nástrojem.

11.4 Fallback

Přechod na non-AI nebo low-AI workflow.

11.5 Terminate

Úplné ukončení AI závislosti.

11.6 Extract and migrate

Export know-how, skills, memory, workflows a migrace do jiného systému.

Minimum requirement

Exit strategy musí říkat, zda jde o pause, reduce, replace, fallback, terminate nebo migrate variantu.

12. Data portability

Data portability znamená, že komunita může získat svá data ven z AI systému.

Data mohou zahrnovat:

prompty,
outputs,
logs,
embeddings,
vector stores,
agent memory,
feedback,
approval history,
workflow configuration,
skills,
decision support,
audit records.

Data portability musí řešit:

export formát,
úplnost,
čitelnost,
metadata,
citlivost,
šifrování,
mazání,
retention,
vlastnictví,
právní omezení.

Minimum requirement

Kritické AI systémy musí umožnit export důležitých dat v použitelném formátu nebo mít kompenzační fallback.

13. Knowledge portability

Knowledge portability je důležitější než samotný export dat.

Znamená, že know-how je zachováno v podobě, kterou komunita dokáže použít i mimo původní AI nástroj.

To vyžaduje:

source of truth,
human-readable dokumentaci,
decision records,
human skills,
AI skills export,
workflow definitions,
examples,
anti-patterns,
metadata,
review history,
ownerství.

Minimum requirement

Kritické know-how vytvořené nebo používané AI musí být uloženo v source of truth, ne pouze v AI nástroji.

14. Skill portability

AI skills a human skills musí být přenositelné.

AI skill portability znamená:

skill je exportovatelný,
je verzovaný,
je human-readable,
má ownera,
je napojený na human skill,
není závislý pouze na proprietární platformě,
lze ho převést na jiného agenta nebo model.

Human skill portability znamená:

lidé umí princip,
existuje dokumentace,
existují příklady,
existuje trénink,
existuje fallback.

Minimum requirement

Kritické AI skills nesmí existovat pouze v proprietárním nebo neexportovatelném skill store.

15. Workflow portability

Workflow portability znamená, že workflow lze pochopit, obnovit nebo převést mimo původní AI nástroj.

Workflow musí být popsán:

účelem,
vstupy,
výstupy,
kroky,
rozhodovacími body,
rolemi,
AI kroky,
non-AI fallbackem,
pravidly schvalování,
datovými hranicemi,
auditními požadavky.

Minimum requirement

Kritická AI-assisted workflow musí mít human-readable workflow definition mimo samotnou AI platformu.

16. Memory portability

Agent memory je zvláštní riziko.

Pokud agent memory obsahuje důležité know-how, musí být:

auditovatelná,
exportovatelná,
smazatelná,
klasifikovaná,
napojená na source of truth,
kontrolovaná ownerem,
zahrnutá do exit strategie.

Nejlepší praxe AIFC:

Agent memory may support work.
It must not replace source of truth.

Česky:

Agentická paměť může práci podporovat.
Nesmí nahradit source of truth.

Minimum requirement

Kritická agent memory musí mít export, audit nebo schválené omezení jejího použití.

17. Prompt and configuration portability

AI workflow často závisí na:

promptech,
system instructions,
agent configuration,
tool configuration,
routing rules,
model parameters,
retrieval settings,
guardrails,
evaluation criteria.

Pokud tyto prvky nejsou exportovatelné nebo dokumentované, vzniká skrytý lock-in.

Minimum requirement

Kritické prompty, instrukce a konfigurace AI workflow musí být verzované nebo exportovatelné.

18. Vendor replacement

Exit strategy by měla popsat možnost vendor replacement.

Otázky:

Existuje alternativní vendor?
Existuje alternativní model?
Jak se liší kvalita?
Jak se liší náklady?
Jak se liší AI-NDA Boundary?
Jak se migrují skills?
Jak se migruje memory?
Jak se ověří výstupy po migraci?
Jak dlouho poběží paralelní provoz?
Kdo schvaluje switch?

Minimum requirement

Kritické AI workflow musí mít alespoň základní představu, jak by se nahradil vendor nebo model.

19. Model replacement

Model replacement může být jednodušší než vendor replacement, ale stále nese rizika.

Rizika:

jiné chování,
jiný styl výstupu,
jiná schopnost práce s kontextem,
odlišná spolehlivost,
jiná cena,
odlišná bezpečnostní pravidla,
nutnost upravit prompty,
horší práce s jazykem komunity,
horší práce s doménovým know-how.

Minimum requirement

Kritická AI workflow závislá na konkrétním modelu musí mít model replacement test nebo alespoň model dependency assessment.

20. AI-off fallback

AI-off fallback je klíčová součást exit strategie.

Pokud AI nástroj nebo vendor přestane být použitelný, komunita musí vědět:

co běží bez AI,
co běží v omezeném režimu,
co se pozastaví,
kdo přebírá práci,
jaké checklisty se použijí,
jak se komunikuje dopad,
jak dlouho fallback vydrží,
jaký je minimální provozní standard.

Minimum requirement

Kritické AI-dependent workflow musí mít AI-off fallback nebo schválené riziko absence fallbacku.

21. Exit and Human Capability Reserve

Exit strategy je nefunkční, pokud lidé nemají schopnost převzít práci.

Proto musí být exit propojen s Human Capability Reserve.

Otázky:

Umí lidé práci vykonat?
Umí výstup validovat?
Existuje human skill?
Existuje training?
Existuje junior learning path?
Existuje fallback drill?
Existuje review competence?
Umí komunita pracovat se source of truth bez agenta?

Minimum requirement

Exit strategy kritických workflow musí obsahovat posouzení Human Capability Reserve.

22. Exit and AI-NDA Boundary

Exit může být vyvolán porušením AI-NDA Boundary.

V takovém případě je potřeba:

zastavit přístup,
odvolat oprávnění,
exportovat audit,
posoudit únik,
vymazat data, pokud je to možné,
označit compromised artefakty,
informovat ownery,
aktivovat fallback,
rozhodnout o náhradě.

Minimum requirement

AI-NDA Boundary musí obsahovat revocation and exit mechanismus.

23. Exit and Operational DNA

Operational DNA vyžaduje nejpřísnější exit ochranu.

Pokud AI nástroj pracuje s Operational DNA, exit strategy musí řešit:

export nebo zničení dat,
derived knowledge,
agent memory,
audit,
vendor retention,
source of truth integrity,
fallback,
human capability,
právní a bezpečnostní dopady,
zákaz dalšího použití,
incident response.

Minimum requirement

AI workflow s přístupem k Operational DNA musí mít explicitní exit strategii před zahájením použití.

24. Exit and source of truth

Source of truth je hlavní ochrana proti lock-inu.

Pokud jsou hodnoty, rozhodnutí, skills, workflow, pravidla a know-how uložené v source of truth, komunita může nástroj vyměnit snáz.

Pokud jsou uložené pouze v chatu, agentovi nebo vendor platformě, exit je obtížný.

Minimum requirement

Kritické knowledge artefakty nesmí být autoritativně uložené pouze v AI vendor systému.

25. Exit and Human Cockpit Layer

Human Cockpit Layer musí zviditelňovat lock-in a exit readiness.

Může ukazovat:

kritické AI dependencies,
exit strategy status,
fallback readiness,
vendor risk,
model dependency,
memory exportability,
skill portability,
AI-NDA Boundary status,
cost risk,
human capability risk,
next review date,
lock-in incidents.

Minimum requirement

Odpovědné role musí mít lidsky dostupný přehled kritických AI závislostí a exit readiness.

26. Exit testing

Exit strategie, která nebyla nikdy testována, může být iluze.

AIFC doporučuje u kritických workflow provádět exit testing nebo tabletop exercise.

Test může ověřit:

zda lze exportovat data,
zda fallback funguje,
zda lidé umí převzít práci,
zda náhradní model dává použitelné výstupy,
zda jsou skills přenositelné,
zda jsou audit logs dostupné,
zda lze agenta vypnout,
zda lze obnovit provoz bez AI.

Minimum requirement

Kritická AI dependency musí mít periodické exit review; u nejkritičtějších oblastí i exit test.

27. Exit cost

Exit má cenu.

Exit cost může zahrnovat:

migraci dat,
úpravu workflow,
přepsání promptů,
training lidí,
přechod na jiný model,
paralelní provoz,
security review,
právní review,
ztrátu produktivity,
dočasný pokles kvality,
ztrátu agent memory.

Exit cost musí být známý nebo odhadnutý.

Nízké měsíční AI náklady mohou skrývat vysoký exit cost.

Minimum requirement

Kritické AI závislosti musí mít alespoň hrubý odhad exit cost nebo exit complexity.

28. Exit complexity levels

AIFC může používat úrovně exit complexity.

Level 0 — Easy exit

AI je ad hoc helper. Žádný kritický lock-in.

Level 1 — Low exit complexity

Data a výstupy jsou v source of truth. Fallback je jednoduchý.

Level 2 — Moderate exit complexity

Je potřeba upravit workflow nebo prompty, ale schopnost zůstává.

Level 3 — High exit complexity

AI je hluboce integrovaná. Přechod vyžaduje projekt.

Level 4 — Critical lock-in

Komunita by bez AI nástroje ztratila kritickou schopnost nebo významnou část Operational DNA.

Minimum requirement

Kritická AI workflow musí mít přiřazenou úroveň exit complexity nebo lock-in risk.

29. Lock-in risk indicators

AIFC doporučuje sledovat indikátory lock-inu.

Příklady:

neexistuje export,
neexistuje fallback,
agent memory obsahuje kritické know-how,
skills nejsou human-readable,
skills nejsou verzované,
workflow není dokumentované mimo nástroj,
tým neumí práci bez AI,
model replacement nebyl testován,
náklady rostou, ale výměna je obtížná,
vendor změnil podmínky a komunita nemá alternativu,
AI výstupy nejsou zapisované do source of truth,
approvals existují jen v proprietárním systému.

Minimum requirement

AI Retrospective nebo governance review musí sledovat lock-in indicators u kritických AI oblastí.

30. Lock-in incidents

Lock-in incident je situace, kdy AI závislost způsobí provozní, bezpečnostní nebo hodnotový problém.

Příklady:

vendor outage zastaví kritický proces,
model change zhorší kvalitu výstupů,
cena vzroste a workflow je neudržitelné,
agent memory nelze exportovat,
AI tool ztratí přístup a tým neumí pokračovat,
vendor terms se změní a AI-NDA Boundary už není splněna,
AI skill store je uzamčený a nejde migrovat.

Lock-in incident musí být zpracován jako observed signal nebo change proposal.

Minimum requirement

Významné lock-in incidents musí vést k aktualizaci exit strategie, fallbacku nebo AI governance.

31. Exit strategy lifecycle

Exit strategy má lifecycle.

Doporučené stavy:

not_required
draft
proposed
under_review
approved
active
tested
needs_update
deprecated
failed

Minimum requirement

Exit strategy kritických AI workflow musí mít status, ownera a review cycle.

32. Suggested metadata

Příklad metadat pro AI lock-in assessment:

ai_lock_in_assessment:
  id:
  title:
  status: draft | active | under_review | archived
  owner:
  related_ai_workflow:
  related_ai_team_member:
  related_ai_engagement:
  vendor_dependency: low | medium | high | critical
  model_dependency: low | medium | high | critical
  tool_dependency: low | medium | high | critical
  agent_memory_dependency: low | medium | high | critical
  skill_store_dependency: low | medium | high | critical
  workflow_dependency: low | medium | high | critical
  human_capability_dependency: low | medium | high | critical
  data_portability: yes | partial | no
  knowledge_portability: yes | partial | no
  skill_portability: yes | partial | no
  workflow_portability: yes | partial | no
  ai_off_fallback_defined: true | false
  exit_complexity: 0 | 1 | 2 | 3 | 4
  exit_strategy_required: true | false
  exit_strategy_status:
  last_reviewed:
  review_cycle:

Příklad metadat pro exit strategy:

ai_exit_strategy:
  id:
  title:
  status: draft | proposed | under_review | approved | active | tested | needs_update | deprecated | failed
  owner:
  scope:
  related_ai_workflows:
  related_ai_team_members:
  related_ai_nda_boundaries:
  exit_triggers:
  exit_level: pause | reduce | replace | fallback | terminate | extract_and_migrate
  replacement_options:
  data_export_plan:
  knowledge_return_plan:
  skill_export_plan:
  memory_export_or_delete_plan:
  workflow_fallback:
  human_capability_assessment:
  operational_dna_handling:
  audit_export:
  incident_response:
  estimated_exit_cost:
  estimated_exit_duration:
  test_plan:
  last_tested:
  review_cycle:

Tyto struktury jsou ilustrativní.

Finální schéma má být definováno v agent-actionable vrstvě standardu.

33. Anti-patterns

AIFC odmítá následující anti-patterny.

33.1 AI tool as hidden operating system

AI nástroj se stane neformálním operačním systémem práce, ale není řízen jako kritická závislost.

33.2 Agent memory as company memory

Agentická paměť nahradí source of truth.

33.3 Skills trapped in vendor platform

Kritické skills existují pouze v proprietárním skill store.

33.4 No export

Komunita nemůže získat svá data, prompty, výstupy, konfigurace nebo skills.

33.5 No fallback

Workflow funguje pouze s konkrétní AI.

33.6 No human capability

Lidé neumí práci převzít po vypnutí AI.

33.7 Exit strategy as document only

Exit strategie existuje, ale nikdy nebyla testována a nikdo ji neumí použít.

33.8 Cheap lock-in

AI je levná na začátku, ale pozdější exit je velmi drahý.

33.9 Model monoculture

Všechna kritická AI workflow závisí na jednom modelu bez alternativy.

33.10 Lock-in ignored because AI is useful

Přínos AI zakryje fakt, že komunita ztrácí nezávislost.

34. Minimal requirements

AIFC komunita musí v oblasti AI Lock-in and Exit Strategy minimálně splnit:

Identifikuje kritické AI závislosti.
Kritické AI závislosti mají ownera.
Kritická AI workflow mají lock-in assessment.
Lock-in assessment rozlišuje vendor, model, tool, memory, skill, workflow a human capability lock-in.
Kritická AI workflow mají exit strategy nebo schválené riziko její absence.
Exit strategy má trigger conditions.
Exit strategy definuje exit level.
Kritické AI systémy mají data portability nebo kompenzační fallback.
Kritické know-how není uložené pouze v AI nástroji.
Kritické AI skills jsou exportovatelné, verzované nebo human-readable.
Kritická AI-assisted workflow mají human-readable workflow definition mimo AI platformu.
Agent memory nesmí nahradit source of truth.
Kritické prompty a konfigurace jsou verzované nebo exportovatelné.
Kritická AI workflow mají alespoň základní vendor nebo model replacement assessment.
Kritická AI-dependent workflow mají AI-off fallback nebo schválené riziko absence fallbacku.
Exit strategy obsahuje Human Capability Reserve assessment.
AI workflow s Operational DNA má explicitní exit strategy před zahájením použití.
Human Cockpit Layer nebo governance rozhraní zviditelňuje kritické AI závislosti a exit readiness.
Kritické AI závislosti mají exit review; nejkritičtější oblasti mají exit test nebo tabletop exercise.
Významné lock-in incidents vedou k aktualizaci governance, fallbacku nebo exit strategie.

35. Summary

AI lock-in není pouze technický problém.

Je to riziko, že komunita ztratí schopnost opustit nástroj, který se stal nositelem její práce, znalostí, workflow, rozhodování nebo Operational DNA.

AI může být hluboce integrovaná.

Ale komunita musí zůstat vlastníkem svého know-how a schopnosti.

AIFC proto říká:

Integrate AI deeply.
Keep knowledge portable.
Keep workflows explainable.
Keep skills exportable.
Keep humans capable.
Keep exit possible.

Česky:

Integrujte AI hluboce.
Držte know-how přenositelné.
Držte workflow vysvětlitelné.
Držte skills exportovatelné.
Držte lidi schopné.
Držte exit možný.

AI-first komunita nesmí být uvězněna ve své AI infrastruktuře.

AI Lock-in and Exit Strategy turns AI dependency into managed reversibility.