Every vendor in your design stack wants the same thing: for leaving to be unthinkable. The pitch is always integration - everything works together, the AI reads your files, the assistant knows your brand - and integration is genuinely useful, but integration is also the mechanism of lock-in, because the more deeply a stack is woven into your work the more expensive it is to leave. This lesson teaches the two audits a Design Strategist owes their organization before going all-in on any walled garden: a lock-in audit that maps the real cost of committing fully to Adobe Firefly plus Express plus the Firefly AI Assistant (in public beta as of April 2026), or to Figma AI plus Make plus Code Connect, or to Microsoft Designer plus Copilot - and designs an escape hatch before you need one; and a data-sovereignty audit that maps where your design data actually flows, through Figma, Adobe Firefly, third-party plugins, and AI image hosts, and which of those carry SOC 2, GDPR, and EU AI Act obligations. The artifact is a vendor-risk matrix plus a one-page data-flow diagram for your CISO, because the person who has to sign off on your stack's risk cannot do it if they cannot see where the data goes.

Integration Is the Mechanism of Lock-In

Start with the uncomfortable truth that the thing you most want from a stack is the thing that traps you. When Figma AI reads your design system, when Code Connect maps your components to code, when the Firefly AI Assistant knows your brand library, the work gets faster and better - and every one of those connections is a thread binding you to that vendor, because replacing the tool now means re-establishing all of those connections elsewhere. This is not a reason to avoid integration; integration is where the value is. It is a reason to integrate with your eyes open, knowing that you are accumulating switching cost with every connection and deciding deliberately how much switching cost is acceptable for how much value, rather than discovering after three years that leaving the walled garden would cost more than staying in it ever did.

The walled gardens are specific and each has a distinct shape of lock-in. Going all-in on Adobe - Firefly, Express, the Firefly AI Assistant - binds you to Adobe's file formats, its asset library, its commercial-indemnification terms (a genuine value), and its assistant's knowledge of your brand, so leaving means migrating assets, re-establishing indemnification elsewhere, and losing the assistant's accumulated context. Going all-in on Figma - AI, Make, Code Connect - binds you to Figma as the source of truth, the design-to-code mapping, and the Make prototyping that lives in the Figma context, so leaving means your design system, your handoff pipeline, and your prototyping all move at once. Going all-in on Microsoft - Designer, Copilot - binds you to the Microsoft identity and document ecosystem, so the lock-in is organizational, not just a design-tool one. Each is a different trap, and the audit's job is to see the specific shape of each before committing, not to avoid commitment.

The Lock-In Audit: Mapping the Real Cost of Leaving

The lock-in audit asks one question per vendor: if we wanted to leave in two years, what would it cost, and could we? The answer has several components, and naming them is the audit. Data portability: can you get your work out in a usable format, or is it trapped in a proprietary one - your Figma files, your Firefly-generated assets with their provenance, your token system, your component mappings? Workflow entanglement: how many of your processes assume this tool, so that leaving means rebuilding not just the tool but the workflows around it? Skill investment: how much of your team's trained fluency is tool-specific and non-transferable, so that leaving means retraining? And capability dependence: does leaving mean losing a capability you now rely on (the indemnification, the AI-readable handoff) that the alternatives do not match?

The audit is not a verdict against the walled gardens - they are often the right choice, because the integration value is real and the alternatives are frequently worse. The audit is a clear-eyed pricing of the commitment, so that the decision to go all-in is made knowing the exit cost rather than discovering it later. The strategic principle, borrowed from the use-case matrix's reversibility axis, is that a deep vendor commitment is a low-reversibility decision, and low-reversibility decisions should be made deliberately, with the cost of being wrong understood in advance, not drifted into one convenient integration at a time. A team that integrates deeply without ever pricing the exit has made the largest reversibility bet in its stack by accident.

Designing the Escape Hatch Before You Need One

The active half of the lock-in audit is designing the escape hatch - the deliberate preservation of an exit option even while committing deeply. An escape hatch is not a plan to leave; it is the cheap insurance that keeps leaving possible, so that the vendor's pricing, terms, and roadmap stay negotiable rather than dictated. Concrete escape hatches: maintaining your design tokens in an open, portable format (DTCG) rather than only in a vendor's proprietary store, so the source of truth can move; keeping a periodic export of your critical assets in a standard format; avoiding building workflows that have no equivalent outside the walled garden; and preserving the team's transferable skills alongside the tool-specific ones. The escape hatch costs a little ongoing discipline and buys you the negotiating leverage and the genuine option to leave that a fully-entangled team has forfeited. A vendor who knows you cannot leave has no reason to keep earning your business; an escape hatch is what keeps them earning it.

An escape hatch is not a plan to leave. It is the cheap insurance that keeps leaving possible - which is exactly what keeps the vendor's pricing, terms, and roadmap negotiable. A vendor who knows you cannot leave has no reason to keep earning your business.

The Data-Sovereignty Audit: Where Does the Design Data Actually Go

The second audit is about data, and it answers a question your CISO will eventually ask and you will not be able to answer without having done the work: where does our design data actually flow? The surprising thing about a modern design stack is how many places the data goes that nobody mapped. Your design files live in Figma's cloud. Your generated images pass through Adobe Firefly or other image hosts. Your third-party plugins - and a Figma file can have many - each touch your data and send it somewhere, often to servers you have never evaluated. Your research data, sometimes including user PII in transcripts, passes through synthesis tools. The data-flow map makes all of this visible, because you cannot govern a flow you cannot see, and the default state of a design stack is a tangle of flows nobody has ever drawn.

Mapping the flow is half the audit; the other half is the compliance overlay - which of these flows carry obligations under SOC 2, GDPR, and the EU AI Act. SOC 2 matters where the data includes anything your customers entrusted you with or that your own security commitments cover, and a vendor without SOC 2 in a flow that should be covered is a finding. GDPR matters wherever the flow touches personal data of EU individuals - and research transcripts, user testing recordings, and anything with names or identifiers frequently do, often through a synthesis tool nobody vetted for GDPR. The EU AI Act matters increasingly as it phases in, with obligations that depend on the AI system's risk classification, and a design stack using AI on personal or consequential data may carry obligations the team has never considered. The audit overlays these obligations onto the data-flow map so each flow is marked with what it must comply with and whether it does.

The Third-Party Plugin Problem

The single most overlooked data-sovereignty risk is the third-party plugin, because plugins are installed casually by individual designers, each one gets access to the file's data, and each sends that data to a server nobody on the team has evaluated for security or compliance. A design team can have dozens of plugins across its files, installed over years by people who have left, each a data flow to an unvetted third party, and none of it on anyone's map. The plugin layer is where the gap between "our stack is Figma and Adobe" (what leadership thinks) and "our data flows to forty companies" (what is actually true) is widest. The audit has to enumerate the plugins, because they are the flows most likely to carry an unexamined obligation and the ones a CISO most needs to see.

The Two Artifacts: A Vendor-Risk Matrix and a Data-Flow Diagram

The deliverable is two artifacts, deliberately, because they serve two audiences and two decisions. The vendor-risk matrix is the lock-in audit made legible: each vendor scored on the lock-in dimensions (data portability, workflow entanglement, skill investment, capability dependence) and the data-sovereignty dimensions (what data flows to them, which obligations apply, whether they meet them), so a leader can see at a glance which vendors carry which risks and where the escape hatches are. It is the strategic instrument for the all-in-or-not decision.

The data-flow diagram is the one-page picture for your CISO, and the one-page constraint is deliberate, because a CISO who cannot see your entire data flow on one page cannot sign off on it. It shows every place design data goes - Figma, Adobe Firefly, the synthesis tool, every third-party plugin, every AI image host - as nodes, with the data type on each edge and the compliance obligation marked on each node. The one page is the thing the CISO has been unable to get from the design team, because no one ever drew it, and producing it is what moves the design org from "a risk the security team worries about and cannot assess" to "a mapped, governed flow the security team can sign off on." The diagram is not for design; it is the bridge between design's reality and the security function that has to vouch for it.

A Worked Example: Auditing an All-In Adobe Decision

Run it concretely. The team is considering going all-in on Adobe - Firefly, Express, the Firefly AI Assistant in its April 2026 public beta. The lock-in audit: data portability is moderate (assets are exportable but the assistant's accumulated brand context is not, and Firefly's provenance metadata is somewhat proprietary), workflow entanglement is high if the brand pipeline is built around the assistant, skill investment is Adobe-specific, and capability dependence is real because Firefly's commercial indemnification is a genuine value the alternatives do not all match. The escape hatch: keep brand assets exported in standard formats on a schedule, keep the brand system documented outside the assistant so its context can be rebuilt, and avoid building the entire pipeline so deeply into the assistant that nothing works without it - so that the indemnification value can be enjoyed without the exit becoming impossible.

The data-sovereignty audit on the same decision: design and brand assets flow to Adobe's cloud (SOC 2 relevant, Adobe generally carries it - verify for the specific services), any generated imagery using customer or personal data carries GDPR and potentially EU AI Act considerations, and the plugin enumeration on the existing Figma files reveals - as it almost always does - a dozen third-party plugins sending data to vendors nobody vetted, several of which touch files with client material. The vendor-risk matrix scores Adobe as moderate lock-in with a designed escape hatch and acceptable data-sovereignty posture for the covered services, flags the unvetted plugins as the real immediate risk, and the one-page data-flow diagram for the CISO shows Adobe's cloud, the generated-imagery flow with its GDPR marking, and - critically - every one of those plugins as a node, which is the first time anyone has shown the security team where the data actually goes. The decision that falls out is not "do not use Adobe"; it is "going all-in on Adobe is acceptable with this escape hatch and these terms, and separately, the plugin layer is an unmanaged risk we are remediating now regardless of the Adobe decision."

Why This Is the Strategist's Job, Not IT's

It is tempting to think lock-in and data sovereignty are IT or security concerns, not design's, but the design stack is the one IT cannot see into. IT can audit the enterprise SaaS contracts; it cannot enumerate the third-party Figma plugins a designer installed last Tuesday, or know that the research synthesis tool is processing transcripts with user PII, or understand that the brand pipeline's dependence on the Firefly assistant is a strategic lock-in. These risks live inside the design workflow, visible only to someone who understands the work - the same reason the strategist owns the verification overhead in the TCO. The Design Strategist is the only person positioned to map the design stack's lock-in and data flows, which makes producing the vendor-risk matrix and the data-flow diagram a core strategic responsibility, not an IT hand-off.

This closes the L4 arc. The strategist diagnosed the team, made the bet, drew the human line, sequenced the roadmap, ran the initiatives, chose the tools, priced the stack - and this final audit ensures that the stack the team committed to is one it can leave and one whose data flows it can defend. It is the last piece of the same posture that runs through every L4 lesson: see the whole picture clearly, denominate the risk in terms the relevant executive (here, the CISO and finance) can act on, be honest about the costs and the exits, and produce an artifact that lets the organization make the decision deliberately. A strategist who can hand a CISO a one-page data-flow diagram and a vendor-risk matrix has done the thing that turns the design org from a black box the security team distrusts into a governed function the organization can stand behind - which is, in the end, what being a Design Strategist means: making the design org legible, defensible, and deliberate in a moment when the easy path is to integrate deeply, ship fast, and find out the cost of all of it too late.

Key Takeaways

• Integration is the mechanism of lock-in. The thing you most want from a stack - everything working together, the AI reading your files - is the thing that traps you, because every connection is switching cost. The answer is not to avoid integration but to integrate with your eyes open, pricing the exit deliberately rather than discovering after three years that leaving costs more than staying ever did.
• Each walled garden has a distinct lock-in shape: all-in Adobe (Firefly, Express, Firefly AI Assistant in April 2026 public beta) binds file formats, assets, indemnification, and assistant context; all-in Figma (AI, Make, Code Connect) moves your system, handoff, and prototyping at once; all-in Microsoft (Designer, Copilot) is organizational lock-in. The audit sees the specific shape before committing, not to avoid commitment.
• The lock-in audit prices the exit on four components - data portability, workflow entanglement, skill investment, capability dependence - because a deep vendor commitment is the largest low-reversibility bet in the stack, and low-reversibility decisions must be made deliberately with the exit cost understood, not drifted into one integration at a time.
• Design the escape hatch before you need one: portable token formats (DTCG), scheduled asset exports, avoiding workflows with no outside equivalent, preserving transferable skills. It is cheap insurance that keeps leaving possible, which is exactly what keeps the vendor's pricing and terms negotiable - a vendor who knows you cannot leave has no reason to keep earning your business.
• The data-sovereignty audit maps where design data actually flows - Figma's cloud, Adobe Firefly, third-party plugins, AI image hosts, synthesis tools touching user PII - because you cannot govern a flow you cannot see, and overlays the compliance obligations (SOC 2, GDPR, EU AI Act) onto each flow, marking which apply and whether the vendor meets them.
• The third-party plugin is the most overlooked risk: installed casually by individuals, each sending file data to an unvetted server, accumulating into dozens of unmapped flows. The plugin layer is where the gap between what leadership thinks the stack is and where the data actually goes is widest, and enumerating it is essential because it carries the most unexamined obligations.
• Produce two artifacts: a vendor-risk matrix (lock-in plus data-sovereignty scores per vendor, the strategic instrument for the all-in decision) and a one-page data-flow diagram for your CISO (every node, data type, and obligation), because a CISO who cannot see the whole flow on one page cannot sign off on it. This is the strategist's job, not IT's, because the design stack's plugins and workflow dependencies are visible only to someone who understands the work - and producing these artifacts turns the design org from a black box the security team distrusts into a governed function the organization can stand behind.