AI Strategy Considerations: The Appendix Material That Matters More Than the Body
The finding came late on a Friday in February, in the second week of an external audit I had been brought in to support. The audit was supposed to be a routine governance review of an EU insurer’s AI portfolio — three customer-facing tools, two internal, all of them with model cards, evaluation logs, the standard kit. The auditor’s third-day question was the one that broke the engagement open. He asked what would happen to the customer-facing claims-triage assistant if the underlying provider deprecated the specific model version it was built on. Nobody in the room knew. The model card named the provider and the model family. It did not name the version. The version had been deprecated by the provider three weeks earlier; the assistant was still running because the provider had granted a six-month grace period that nobody on the operating team had read. The grace period would end in September. There was no plan, no budget, no engineering capacity reserved for the migration, and no second model evaluated against the same use case. The strategy that had authorised the assistant was silent on model deprecation. The failure was not in the prose of the document; it was in the design of the strategy.
That story is the shape of this entire page. The visible decisions in an AI strategy — which capabilities to build, which to buy, which to govern, which to discontinue — are the ones that get the chapter headings. The considerations behind them are the appendix material, the assumptions that the chapter headings depend on. The considerations are what determines whether the visible decisions survive the second year of execution. Most strategy templates I read in 2026 have all six chapter headings and none of the considerations. The result is a document that is correct in its body and unsurvivable in its second year.
I am writing this page because the keyword work I do shows “AI strategy considerations” as a recurring search from procurement teams and operating leads who have already read the framework comparisons and want the second-order content. They are right that this is the right next question. The intent behind the query is what am I missing that the framework did not warn me about, and the honest answer is the six considerations below, in roughly the order they will bite.
Consideration one: model-cost volatility
The single most predictable surprise in an AI programme’s second year is the cost trajectory of the underlying model APIs. The cost-per-token figures that the strategy was built on were a snapshot of a specific moment in a fast-moving pricing market, and they will be wrong by month nine in either direction. The honest planning assumption is that prices for the same capability will fall by 50% to 80% over eighteen months, and that prices for new frontier capabilities will arrive at a price point above what the existing capability cost when first deployed. The volatility is asymmetric: commodity tasks get cheaper, frontier tasks stay expensive.
The implication for strategy is that the unit economics calculations in the body of the document have to be marked as snapshot-dated rather than committed. A strategy that says “the customer-service assistant costs €0.04 per resolved ticket at current model prices” is making a claim that will be wrong within a year. A strategy that says “the customer-service assistant costs €0.04 per resolved ticket at current model prices; we have reserved engineering capacity to re-architect the cost stack against the model market in months six and twelve” is making a claim that survives the volatility. The difference is one sentence. The sentence is missing from most templates.
The downstream considerations include caching strategy (which models you cache against, with what eviction policy), the prompted-large-model versus fine-tuned-small-model tradeoff (which shifts every six months as fine-tuning costs fall), and the batch-versus-realtime split (which is the single biggest cost lever most programmes never use). None of these belong in a strategy document at the level of detail above — they belong in the roadmap. What belongs in the strategy is the acknowledgement that the cost stack will be re-engineered at least once per year, and the budget commitment to do so.
Consideration two: vendor lock-in calculations at portfolio scale
Vendor lock-in in AI is structurally different from vendor lock-in in traditional SaaS, and most strategy templates treat the two as the same problem. SaaS lock-in is about data export and process re-implementation. AI lock-in is about prompt engineering, evaluation harnesses, fine-tuning artefacts, and the institutional knowledge built around a specific model’s quirks. The cost of switching from one provider to another is not the cost of data export; it is the cost of re-doing six months of prompt-engineering work, re-running the evaluation suite, and accepting that the second-best model on your eval set is the new floor.
At the level of a single capability this is navigable. At portfolio scale it compounds. Five capabilities built against the same provider’s models share the prompt-engineering and evaluation-harness infrastructure, which sounds like an efficiency until the provider raises prices or deprecates a model. Then five capabilities are simultaneously exposed to the same vendor decision, and the portfolio-level switching cost is not five times the single-capability switching cost; it is roughly the single-capability switching cost multiplied by the inverse of how much infrastructure was shared. Sharing more infrastructure lowered the build cost; it also raised the switching cost. The strategy template that does not name this tradeoff is letting the team make the build-cost decision without the switching-cost information.
The defensible posture in 2026 is multi-provider from day one for at least two capabilities, with the evaluation harness deliberately built to run the same test suite against multiple model providers. The cost is roughly 15% to 25% of platform-engineering capacity. The benefit is that the lock-in calculation stops being a guess and becomes a measurable parameter. Strategies that defer this work to “later” rarely do it; the moment the provider raises prices is the moment you discover the harness is single-provider-shaped and the migration takes nine months instead of three.
Consideration three: the GDPR–EU AI Act interaction at portfolio scale
This is the consideration that most strategy templates handle worst, and it is the one where the regulatory cross-walk maintenance burden becomes operational rather than theoretical. At a single-use-case level the EU AI Act and GDPR interaction is navigable: you do a data protection impact assessment for the personal-data processing, a conformity assessment for the high-risk system if it qualifies, and the obligations rarely conflict directly. The Act explicitly preserves GDPR; it does not override it. So far so manageable.
At portfolio scale, the interaction compounds in a way the single-use-case reviews never surface. A training-data decision made for use case A — say, the lawful basis chosen for processing customer interaction data — constrains the lawful-basis claim available for use case B, which uses adjacent data. The auditability claim for use case C, which relies on the same data pipeline as A and B, has to be consistent with both. A portfolio-level review uncovers the inconsistencies that per-use-case reviews miss, because the per-use-case reviewers each see only their own slice. The portfolio review is a separate exercise. It belongs in the strategy document as a quarterly commitment, not in the governance chapter as a one-off paragraph.
The maintenance burden is real and growing. The EU AI Act August 2026 high-risk obligations bite; the GDPR enforcement priorities have shifted toward automated decision-making and profiling; the national-level guidance from the Bavarian DPA, the CNIL, and others is moving faster than the Commission’s. A regulatory cross-walk maintained in a spreadsheet that nobody updates is worse than no cross-walk at all, because it produces false confidence. The strategy should name the named owner of the cross-walk, the refresh cadence (quarterly, in 2026), and the budget for the work. None of this lives in the body of a typical template. It belongs there.
The governance hub holds the operational detail on the alphabet soup of frameworks. What belongs in the strategy itself is the acknowledgement that regulatory consistency across the portfolio is not free, that the cost is roughly one full-time equivalent for a mid-sized enterprise portfolio, and that the cost rises every quarter as the regulatory landscape thickens. Strategies that treat regulatory work as a one-off cost are mis-priced by approximately the cost of the second-year audit response.
Consideration four: the “what happens when the team that built it leaves” question
The AI engineering talent market in 2026 is not yet stable. Tenure on AI engineering teams is averaging around eighteen months at the senior level, lower at the staff level when the work is interesting and the comp is not at the frontier. The strategy assumption that the team building the first version of a capability will still be the team operating it in year three is, in most organisations, wrong. The strategy should be written to survive a 40% rotation of the engineering team between year one and year three, which is the median outcome I have observed across the engagements I have audited.
The implications cascade. Documentation that the original team relied on tacit knowledge for becomes a gap when the original team leaves. Model evaluation methodology that was held in one senior engineer’s head becomes irreproducible. Vendor relationships that were managed through individual lines of communication revert to formal procurement, which is slower and less responsive. The capability that was delivered on schedule under the original team becomes operationally fragile under the second team, not because the second team is less competent but because the artefacts were not produced for them.
The strategy commitment that addresses this is dull and necessary. Every capability shipped under the strategy must produce four artefacts before it leaves the build phase: a model card with version, a written evaluation methodology with reproducible test suite, a deployment runbook usable by an engineer who joined the team that week, and a vendor-relationship map showing who at the vendor knows what. Without these four artefacts, the capability is delivered but not handed over. Year-three operating cost rises sharply, and the strategy was the place this could have been prevented.
This is Brooks’s argument from 1975, restated for AI. The cost of building a working capability is roughly a third of the cost of building a working capability that another team can operate. The strategy that does not budget for the difference is mis-budgeted by a factor of three on the operating side.
Consideration five: the cost of unwinding a workstream in flight
Every strategy implicitly assumes that workstreams will either complete or run to the end of their budget. Mid-flight cancellation is treated as an exception. In practice mid-flight cancellation is the modal outcome for at least one workstream in any portfolio of three or more, and the cost of unwinding it cleanly is roughly 20% to 35% of what the workstream would have cost if completed. Strategies that treat cancellation as free under-budget mid-cycle by exactly this amount.
The cost is real and itemisable. Vendor contracts with exit penalties or notice periods. Data infrastructure built for the cancelled workstream that has to be decommissioned or repurposed. Team members who were hired for the workstream and have to be re-deployed or released. Stakeholder communications that have to land cleanly so that the next workstream’s stakeholders trust the team. The financial cost of these is roughly knowable in advance; the political cost is harder to budget but more dangerous to ignore.
The strategy should name an unwind budget for each workstream, set at 25% of the workstream cost, and ring-fenced from the workstream’s operating budget. This is the equivalent of the rollback plan in a deployment runbook — the discipline of naming what happens if the deployment fails, before the deployment happens. Strategies that do not budget for unwind treat cancellation as catastrophe, which makes cancellation politically expensive, which means the team keeps spending on workstreams the data says should be cut. The mechanism feeds itself; the only way out is to name the unwind cost in advance.
Consideration six: the model-deprecation calendar
The opening anecdote was a model-deprecation surprise, and it deserves a section. The major providers — OpenAI, Anthropic, Google, the open-weight providers behind whatever your team has fine-tuned — deprecate models on schedules that are public but rarely tracked by the operating team. OpenAI deprecates a model on average every twelve to fifteen months with a six-month grace period. Anthropic’s cadence is similar. Google’s Vertex line moves slightly faster. The open-weight ecosystem is less predictable but no slower.
A strategy that authorises capabilities built on specific model versions inherits the deprecation calendar of those versions. The honest commitment is that the strategy will maintain a model-deprecation tracker, refreshed quarterly, naming each capability’s underlying model version and the announced or expected deprecation date. The tracker is shared with the engineering team, the procurement team, and the named owner of the affected capability. When a deprecation date moves inside a six-month horizon, the migration plan becomes a committed workstream rather than a hypothetical one. The capacity to migrate is reserved in advance.
This is the operational application of the considerations frame: the visible decision is which model to use for which capability; the hidden constraint is that the model will not exist in eighteen months in the version you authorised. The strategy that treats the constraint as a surprise will be surprised. The strategy that treats it as a commitment will not. The difference is, again, one sentence in the body and one tracker in the appendix.
Where these considerations live in the document
The considerations above do not each get a chapter in the strategy. The body of the strategy stays focused on the four-question diagnostic — posture, cost ceiling, timeline pressure, failure tolerance — and the capability list. The considerations live in two places: a short paragraph in the body of the document acknowledging the relevant constraint and naming the commitment, and an appendix section per consideration with the operational detail.
The geometry is the point. A strategy document that reads as if the considerations did not exist is hiding the most important information from the reader. A strategy document that buries the considerations in a fifty-page appendix nobody reads is also hiding it. The version that works is the one that names each consideration in a paragraph of the body — long enough for the reader to know it has been thought about, short enough not to overwhelm — and reserves the operational detail for the appendix where the operator can find it.
The two people who read the appendix are the named owner of the strategy and the engineering lead who will execute it. The forty other people who read the body are board members, executives, divisional heads, and the procurement team. The body has to survive their reading. The appendix has to survive execution. The considerations have to be in both, at the right depth for each audience.
What I would do on Monday morning
If you are writing a strategy from scratch, write the body first, then add the six paragraphs above to the appropriate sections — model-cost volatility in the cost-ceiling section, vendor lock-in in the capability list, GDPR–EU AI Act interaction in the governance section, team-departure risk in the capability list, unwind costs in the budget section, model deprecation in the procurement section. Write the appendix detail in parallel with the corresponding body paragraph; do not let the appendix work be deferred, because deferred appendix work is the appendix work that does not get done.
If you have a strategy and want to test whether it survives these considerations, take the document and mark each section against the six items above. A defensible strategy addresses all six explicitly. A theatrical strategy addresses none. The middle ground — addresses some, ignores others — is where most working strategies sit, and the gaps are usually the place where the second-year surprises arrive. Close them before the surprise, not after.
If you have been handed an “AI strategy and program” mandate — the procurement-team variant of this query — what your procurement function needs from the strategy is exactly the six considerations above translated into contract clauses. The cost volatility translates into renegotiation triggers; the lock-in translates into exit clauses; the regulatory cross-walk translates into compliance covenants; the team-departure risk translates into knowledge-transfer requirements; the unwind costs translate into termination-fee caps; the model deprecation translates into provider-substitution rights. The enterprise strategy piece holds the contract language detail. Read it after you have written the considerations into the strategy proper, not before.
Sources & methodology
- EU AI Act, Regulation (EU) 2024/1689 — the regulatory anchor for consideration three
- NIST AI Risk Management Framework, v1.0 — the public-domain reference for failure-mode and post-deployment monitoring practice that underwrites considerations four and six
- OpenAI model deprecation policy and equivalent provider documentation — the public source for the deprecation calendar in consideration six
- Brooks, F. (1975), “The Mythical Man-Month” — the original argument behind consideration four’s three-times cost factor for handover-quality engineering work
- Methodology: claims drawn from approximately forty AI programmes audited or run between 2023 and 2026, anonymised. Per-consideration cost figures are the median observed in mid-sized European enterprise engagements; figures will differ in other geographies and sectors.
If you have a consideration I have missed — and there will be more, this list is current to 2026-05-29 — send it and I will publish the addition with attribution.