AIFC-034: AI Lock-in and Exit Strategy

Status: Draft 0.1 Standard: AI-First Community Standard Abbreviation: AIFC Builds on:

• 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-033 AI Budget and Cost Control

Purpose of this document: Define AI lock-in and exit strategy so an AIFC community can use AI deeply without losing the ability to leave, replace, reduce, or recover from AI tools, vendors, models, workflows, or memories.

1. Purpose of this document

This document defines AI lock-in and exit strategy.

AI lock-in occurs when the community becomes dependent on a specific AI vendor, model, tool, agent, memory, skill store, workflow, integration, or human behavior pattern in a way that makes exit difficult.

This risk is broader than technical vendor lock-in.

It includes:

• know-how trapped in agent memory,
• skills trapped in a proprietary store,
• workflows that only one AI tool can perform,
• prompts and configurations that cannot be exported,
• human capability lost because AI always performs the work,
• Operational DNA encoded in an external system,
• cost or contract structures that make leaving impractical.

AIFC does not reject AI tools.

It requires that critical AI dependency has an exit strategy.

2. Core principle

The core principle of this document is:

Critical AI capability must remain exit-capable.

The community may use AI deeply.

But it must not quietly transfer its future ability to continue into an AI vendor, model, agent, memory, or proprietary workflow.

AIFC therefore says:

Use AI.
Do not become owned by the conditions of one AI system.

3. Definition of AI lock-in

AI lock-in is a dependency created when a community cannot realistically continue, migrate, reduce, replace, pause, or recover from a specific AI vendor, model, agent, tool, workflow, memory, or proprietary store without unacceptable harm.

AI lock-in may affect:

• data,
• knowledge,
• skills,
• workflows,
• decision support,
• Operational DNA,
• customer support,
• development,
• governance,
• compliance,
• human capability.

Minimum requirement

Critical AI workflows must be assessed for AI lock-in risk.

4. Definition of exit strategy

Exit strategy is the plan that allows a community to reduce, replace, pause, terminate, migrate away from, or recover from an AI dependency.

It defines:

• what must be exported,
• what must be documented,
• what fallback exists,
• who owns exit,
• what cost exit has,
• what triggers exit,
• how capability is preserved,
• how the source of truth remains community-owned.

Minimum requirement

Critical AI dependencies must have an exit strategy or an approved risk of not having one.

5. Why AI lock-in matters

AI lock-in matters because AI may become embedded in the way the community thinks, decides, writes, learns, and acts.

If the community cannot leave, it loses strategic freedom.

Risks include:

• price increases,
• model degradation,
• vendor shutdown,
• legal or policy change,
• data access loss,
• trust incident,
• missing export,
• lost human capability,
• hidden memory dependency,
• Operational DNA exposure.

Minimum requirement

The community must treat AI lock-in as a governance risk, not only a procurement risk.

6. Forms of AI lock-in

6.1 Vendor lock-in

Dependency on a specific provider or contract.

6.2 Model lock-in

Dependency on the behavior, pricing, context window, quality, or capabilities of one model.

6.3 Tool lock-in

Dependency on a specific AI application or interface.

6.4 Agent lock-in

Dependency on a specific configured agent or agent platform.

6.5 Skill store lock-in

Human or AI skills are stored in a proprietary system and cannot be exported.

6.6 Memory lock-in

Critical context exists only in agent memory or chat history.

6.7 Workflow lock-in

The community cannot perform a workflow without a specific AI workflow.

6.8 Data format lock-in

Data or knowledge is stored in a format that cannot be easily exported or reused.

6.9 Human capability lock-in

People lose the ability to perform or validate work without AI.

Minimum requirement

Lock-in assessment must consider technical, knowledge, workflow, memory, and human capability dependency.

7. Lock-in is not only technical

AI lock-in may appear even when data is technically exportable.

For example:

• the exported data is unusable without the original tool,
• prompts and configurations are missing,
• humans no longer understand the process,
• agent memory contains context outside the source of truth,
• the team relies on model-specific behavior,
• workflows are not documented,
• the community cannot afford the migration.

Minimum requirement

Exit strategy must cover practical ability to continue, not only legal or technical export.

8. Critical dependency

A dependency is critical when losing it would significantly harm:

• purpose,
• values,
• operations,
• customers,
• security,
• legal compliance,
• Operational DNA,
• source of truth,
• human capability,
• governance,
• ability to recover.

Minimum requirement

Critical AI dependencies must be explicitly identified.

9. Lock-in assessment

Lock-in assessment should ask:

• What AI system is the community dependent on?
• What work stops if it disappears?
• What know-how is stored there?
• Can data, prompts, skills, memory, and outputs be exported?
• Can people perform the work without it?
• Is there an alternate vendor or workflow?
• What would migration cost?
• What is the fallback?

Minimum requirement

Critical AI dependencies must have periodic lock-in assessment.

10. Exit triggers

Exit strategy should define triggers.

Examples:

• vendor trust incident,
• data incident,
• pricing change,
• quality degradation,
• policy change,
• legal restriction,
• model removal,
• contract change,
• AI-NDA Boundary conflict,
• unacceptable dependency level.

Minimum requirement

Exit strategy must define conditions that trigger review or exit.

11. Exit levels

Exit does not always mean immediate termination.

11.1 Pause

Temporarily stop or suspend AI use.

11.2 Reduce

Lower AI Intensity, autonomy, scope, or cost.

11.3 Replace

Move to another model, vendor, tool, or agent.

11.4 Fallback

Switch to non-AI or reduced-AI workflow.

11.5 Terminate

End the dependency.

11.6 Extract and migrate

Export knowledge, skills, memory, prompts, data, and workflows into community-owned structures.

Minimum requirement

Exit strategy should define the expected exit level.

12. Data portability

Data portability means the community can export and reuse data outside the AI system.

It should include:

• standard formats,
• complete export,
• metadata,
• access history where needed,
• ownership information,
• retention and deletion rules.

Minimum requirement

Critical data used by AI must remain portable.

13. Knowledge portability

Knowledge portability means durable know-how is stored in the source of truth, not only in AI chats, vendor tools, or agent memory.

Portable knowledge should be:

• human-readable,
• structured,
• versioned,
• reviewable,
• exportable,
• linked to decisions and workflows.

Minimum requirement

Critical AI-generated or AI-assisted know-how must be portable through the source of truth.

14. Skill portability

Human and AI skills should be exportable and understandable.

Skill portability requires:

• plain text or open format,
• versioning,
• owner,
• examples,
• review rules,
• relation to source of truth,
• human-readable explanation.

Minimum requirement

Critical AI skills must not be trapped in a proprietary skill store without export.

15. Workflow portability

Workflow portability means the community can understand and recreate the workflow outside a specific AI tool.

This requires:

• workflow description,
• inputs,
• outputs,
• decision rules,
• approval gates,
• fallback,
• owner,
• dependencies.

Minimum requirement

Critical AI workflows must be documented enough to be recreated or replaced.

16. Memory portability

Agent memory is a major lock-in risk.

If critical context exists only in memory, exit becomes difficult.

Memory portability requires:

• export,
• classification,
• review,
• deletion path,
• source-of-truth write-back,
• restriction of sensitive memory.

Minimum requirement

Critical agent memory must not be the only location of important know-how.

17. Prompt and configuration portability

Prompts, system instructions, tool configurations, and agent settings may contain important operational logic.

They should be:

• exportable,
• versioned,
• reviewed,
• linked to purpose,
• understandable to humans.

Minimum requirement

Critical prompts and configurations must be preserved outside a proprietary runtime.

18. Vendor replacement

Vendor replacement requires more than choosing another vendor.

It may require:

• data export,
• skill migration,
• prompt adaptation,
• workflow testing,
• security review,
• AI-NDA Boundary review,
• cost review,
• fallback activation,
• human retraining.

Minimum requirement

Critical vendor dependency must have a replacement or fallback path.

19. Model replacement

Model replacement may change quality, style, risk, cost, latency, and behavior.

The community should not assume that all models are interchangeable.

Minimum requirement

Critical workflows must identify model-specific dependency where it exists.

20. AI-off fallback

AI-off fallback is part of exit strategy.

It allows the community to continue critical work when AI is unavailable, unsafe, or inappropriate.

Minimum requirement

Critical AI-dependent workflows must have AI-off fallback or approved risk of not having one.

21. Exit and Human Capability Reserve

Exit is impossible if humans no longer understand the work.

Human Capability Reserve protects the ability to leave AI systems.

Minimum requirement

Exit strategy for critical AI dependency must include human capability preservation.

22. Exit and AI-NDA Boundary

AI-NDA Boundary must define how data, prompts, outputs, logs, and memory are handled during exit.

This may include deletion, export, retention, or restriction.

Minimum requirement

Exit strategy must respect AI-NDA Boundary requirements.

23. Exit and Operational DNA

Operational DNA must not be trapped in an AI tool.

If AI works with Operational DNA, the community must preserve its own version in the source of truth.

Minimum requirement

Operational DNA used by AI must remain community-owned and exit-capable.

24. Exit and source of truth

The source of truth is the main protection against AI lock-in.

Minimum requirement

Critical knowledge required for exit must be stored in the source of truth.

25. Exit and Human Cockpit Layer

The Human Cockpit Layer should make lock-in and exit readiness visible.

It may show:

• critical AI dependencies,
• exit strategy status,
• export status,
• fallback status,
• lock-in risk,
• owner,
• last exit test,
• open gaps.

Minimum requirement

Critical lock-in risks must be visible to accountable humans.

26. Exit testing

Exit strategy should be tested.

Tests may include:

• export test,
• fallback drill,
• alternate model test,
• vendor replacement exercise,
• memory export review,
• AI-off work simulation.

Minimum requirement

Critical exit strategies must be periodically tested or reviewed.

27. Exit cost

Exit has cost.

Costs may include:

• migration,
• retraining,
• lost productivity,
• data cleanup,
• contract termination,
• security review,
• workflow redesign,
• human capability rebuilding.

Minimum requirement

Exit strategy must include expected exit cost or complexity.

28. Exit complexity levels

AIFC may use exit complexity levels.

Level 0 - Easy exit

The community can stop or replace the AI use with minimal impact.

Level 1 - Low exit complexity

Exit requires some configuration or retraining but no critical loss.

Level 2 - Moderate exit complexity

Exit requires planned migration, fallback, and review.

Level 3 - High exit complexity

Exit is difficult and may significantly disrupt work.

Level 4 - Critical lock-in

The community cannot realistically exit without severe harm.

Minimum requirement

Critical AI dependencies must have an exit complexity assessment.

29. Lock-in risk indicators

Indicators include:

• no export,
• proprietary memory,
• skills trapped in vendor platform,
• model-specific prompts,
• no fallback,
• no human capability,
• undocumented workflow,
• critical decisions dependent on AI,
• high migration cost,
• source of truth not updated.

Minimum requirement

AI Retrospective should include lock-in indicators for significant AI use.

30. Lock-in incidents

A lock-in incident occurs when dependency causes harm or reveals unacceptable exit weakness.

Examples:

• vendor outage stops critical work,
• model change breaks workflow,
• memory cannot be exported,
• team cannot continue without AI,
• cost increase cannot be avoided,
• critical know-how is missing from the source of truth.

Minimum requirement

Significant lock-in incidents must be processed as observed signals or change proposals.

31. Exit strategy lifecycle

Exit strategy has a lifecycle:

identified
assessed
planned
approved
tested
active
updated
archived

Minimum requirement

Exit strategy must have owner, status, and review cycle.

32. Suggested metadata

Example metadata:

ai_exit_strategy:
  id:
  title:
  status: draft | assessed | planned | approved | tested | active | archived
  owner:
  related_ai_engagement:
  dependency_type:
    - vendor
    - model
    - tool
    - agent
    - skill_store
    - memory
    - workflow
    - data_format
    - human_capability
  criticality: low | medium | high | critical
  exit_complexity: 0 | 1 | 2 | 3 | 4
  exit_triggers:
  exit_level:
  data_portability:
  knowledge_portability:
  skill_portability:
  workflow_portability:
  memory_portability:
  fallback:
  human_capability_required:
  ai_nda_boundary:
  operational_dna_access:
  source_of_truth_targets:
  exit_cost:
  last_tested:
  review_cycle:

This structure is illustrative.

The final schema should be defined in the agent-actionable layer of the standard.

33. Anti-patterns

AIFC rejects the following anti-patterns.

33.1 AI tool as hidden operating system

The community cannot operate because a tool became the real operating system.

33.2 Agent memory as company memory

Critical memory exists only inside an agent.

33.3 Skills trapped in vendor platform

AI skills cannot be exported or understood outside one platform.

33.4 No export

Critical data or knowledge cannot be exported.

33.5 No fallback

Critical AI workflows have no non-AI path.

33.6 No human capability

People can no longer perform or validate the work.

33.7 Exit strategy as document only

An exit strategy exists but has never been tested and is not operational.

33.8 Cheap lock-in

The community accepts future dependency because the current tool is cheap.

33.9 Model monoculture

Critical workflows rely on one model with no tested alternative.

33.10 Lock-in ignored because AI is useful

AI value is used as a reason not to examine dependency.

34. Minimal requirements

In the area of AI Lock-in and Exit Strategy, an AIFC community must at minimum:

1. Assess critical AI workflows for lock-in risk.
2. Identify critical AI dependencies.
3. Give critical AI dependencies an exit strategy or approved risk of not having one.
4. Consider vendor, model, tool, agent, skill store, memory, workflow, data format, and human capability lock-in.
5. Define exit triggers.
6. Define exit level.
7. Preserve data portability.
8. Preserve knowledge portability through the source of truth.
9. Preserve skill portability.
10. Preserve workflow portability.
11. Prevent critical agent memory from becoming the only knowledge location.
12. Preserve critical prompts and configurations outside proprietary runtime.
13. Define vendor or model replacement path where relevant.
14. Provide AI-off fallback or approved risk for critical AI-dependent workflows.
15. Preserve Human Capability Reserve.
16. Respect AI-NDA Boundary during exit.
17. Keep Operational DNA community-owned and exit-capable.
18. Make lock-in and exit readiness visible to accountable humans.
19. Test or review critical exit strategies periodically.
20. Assess exit cost or complexity.
21. Process lock-in incidents as observed signals or change proposals.
22. Give exit strategy owner, status, and review cycle.

35. Summary

AI lock-in is not only a vendor problem.

It can live in models, agents, tools, workflows, memory, skill stores, prompts, formats, and lost human capability.

An AI-first community can use AI deeply.

But it must remain able to leave, reduce, replace, recover, and continue.

AIFC therefore says:

Use AI deeply.
Keep knowledge portable.
Keep skills exportable.
Keep workflows understandable.
Keep memory in the source of truth.
Keep fallback possible.
Keep humans capable.
Keep exit real.

AI Lock-in and Exit Strategy turns AI dependency into a governed, exit-capable relationship.