Rodrigo Salinas had been the State Archivist for eleven years when the first AI document classification tools arrived. He had weathered a records management software migration in 2017 that cost his agency $4.2 million and fourteen months of disruption. He had lived through a cloud storage contract that became obsolete before it expired. So when the vendor demonstrating an AI-powered FOIA (Freedom of Information Act) processing system told him the tool would be future-proof, he asked a question the vendor had not expected: which future? Rodrigo understood something many senior leaders learn the hard way. You cannot futureproof a system against specific technologies. You can only futureproof the organization's ability to adapt to whatever those technologies turn out to be, and that ability is built out of procurement terms, policy structure, data decisions, and staff skills rather than out of any prediction about the technology itself. This lesson is about how to build that capacity.

Why Predicting the Technology Is the Wrong Goal

Every strategic planning exercise asks the same question: what will AI look like in five years? The honest answer is that nobody knows. Multimodal models, autonomous agents, AI-generated synthetic data, and foundation models fine-tuned on government-specific corpora were each a niche research topic three years before they became a procurement conversation. Planning for specific capabilities is a losing strategy. By the time an agency has adapted its workforce and its procurement rules to one wave, the next wave is already rearranging the vendor landscape underneath the plan.

This is not an argument against planning. It is an argument about what the plan should commit to. A plan that names a technology commits the agency to a bet, and the bet is settled by events nobody in the agency controls. A plan that names an adaptive capacity commits the agency to something it can actually build and keep: a contract clause, a policy structure, a data format, a skill in the workforce. Those hold their value across several waves of technology, which is precisely why they are worth spending scarce planning attention on when the technology itself is unknowable.

The more useful frame is adaptive architecture: the set of organizational structures, policy designs, and workforce practices that let an agency respond to whatever AI becomes rather than to what it predicted. Think of a building with a reinforced floor plan designed to accommodate different interior configurations. The walls are fixed and the layout can change. The reinforcement costs something up front and buys nothing visible on the day it is installed, which is exactly why it tends to be cut from a first design and exactly why its absence is discovered at the worst moment.

Scenario Planning for Government Leaders

Scenario planning is a structured method for preparing for several plausible futures rather than betting on one. Government leaders often treat strategic planning as forecasting: pick the most likely future and optimize for it. Scenario planning does something different. It identifies the key uncertainties, builds two to four contrasting stories about how those uncertainties could resolve, and then asks which decisions would hold up across all of them. The output is not a prediction and should never be presented as one, because a scenario read as a forecast will be argued about on the wrong terms.

For a government AI leader in 2026, the most consequential uncertainties are how quickly AI performance in high-stakes domains such as medical benefits, criminal adjudication, and public safety will become reliable enough to reduce human review requirements; how the regulatory environment will evolve at federal and state level; and how the vendor market will consolidate or fragment. You do not need to predict which scenario will occur. You need to identify which investments make sense regardless of which one does, and those are your near-term priorities.

That test is the whole discipline. Run each candidate investment against every scenario and sort the results. An investment that pays off in one scenario and is wasted in the others is a bet, and bets are sometimes worth making but should be labelled as such when they go to leadership. An investment that pays off in all of them is not a bet at all; it is infrastructure, and it should be funded first. The sorting is what turns a workshop full of speculation into a budget request that survives contact with a skeptical reviewer.

For Rodrigo's agency, one investment robust across all scenarios was a vendor-agnostic data schema for records indexing. Whatever AI tool the agency used next, the underlying records data needed to be portable. That decision saved his agency from a $1.8 million migration cost when their AI vendor was acquired and discontinued the state government product line eighteen months into a three-year contract. Nothing in the scenario work predicted the acquisition. The schema decision was worth making without knowing about it, which is the point.

Adaptive Architecture: Four Design Principles

Modular procurement over monolithic systems. Large integrated AI systems are difficult to modify when the technology changes, because the parts that need replacing are entangled with the parts that do not. Modular systems, where individual components can be swapped without rebuilding the whole, cost more to design initially and far less to adapt. For agencies constrained by multi-year procurement cycles, modularity is not a luxury: it is the practical way to avoid being locked into obsolete technology for the full contract term. The contract length is the real constraint being designed around, which is why the modularity decision belongs to the same conversation as the term length.

Data portability as a contract requirement. Every AI contract should require that all agency data, including training data, processed outputs, and system logs, be exportable in a standard format within 30 days of contract termination. Many agencies discover this need only when they try to exit, by which point it is a negotiating point the vendor holds rather than a right the agency has. Written into the original contract it is close to free at signing and creates genuine leverage later. A clause creates a right, not an outcome: test the export path while the relationship is healthy, because a vendor that has been acquired or has failed may be unable to perform.

Policy language that accommodates evolution. Rigid policy that names specific technologies becomes obsolete quickly. Effective AI policy governs capabilities rather than products: automated decision-making affecting individual rights, systems that process biometric data, tools that generate synthetic content for public distribution. When a new tool enters the market, the policy already reaches any tool in a governed capability category. That reach still depends on someone deciding which category a new tool falls into, so name the office that makes the determination and the point in the acquisition process where it happens, or the policy applies in principle and to nothing in practice.

Workforce agility over tool-specific training. Training staff on specific tools is necessary and not sufficient, because the tools will change. The durable skills are cognitive: evaluating AI outputs critically, recognizing when human judgment should override an algorithmic recommendation, and documenting AI-assisted decisions for accountability. An agency that invests in those, and not only in onboarding for the current product, has a workforce that can absorb the next generation of tools. It also has staff who can tell a genuine capability from a demonstration, which is worth more at procurement time than any single tool skill.

Rigid policy is not the only failure mode; policy that is silent is the other. Where an agency has no position on a capability, the position is set in practice by whichever program adopts it first, and that de facto standard is much harder to change later than a written one. Capability-based drafting is partly a defence against that, because it lets a policy issued today reach categories of tool the drafters have not seen, and it gives a program office a rule to point at rather than a gap to fill on its own initiative.

Horizon Scanning as an Institutional Practice

Horizon scanning is the systematic monitoring of emerging technologies for potential impact on agency operations. It is standard practice at defense and intelligence agencies and rare at civilian ones, which is a gap worth closing. The reason it is rare is not that anyone objects to it. It is that no single program owns it, its output is a briefing rather than a deliverable, and a function without an owner or a deliverable is the first thing to disappear from a constrained budget.

An effective practice does not require a large team or a large budget. It requires three things: a designated function, often a senior analyst or a small innovation office; a structured process for monitoring relevant signals, such as peer agency deployments, OMB guidance, academic research, and vendor market activity; and a defined reporting cadence, typically quarterly briefings to senior leadership. The output is not a prediction. It is an early warning that gives leadership 12 to 18 months of lead time to adapt procurement strategy, update policy, and begin workforce preparation before a new capability becomes a crisis.

That lead time applies to the signals the function chose to watch. Horizon scanning is a lens, not a perimeter, and a capability that arrives from a domain nobody put on the monitoring list arrives without warning regardless of how well the process runs. Treat the source list itself as a thing to review, ask periodically what you would have missed in the last year, and record the categories you have deliberately decided not to watch so that the decision is visible rather than accidental. A scanning function that is never surprised is usually a scanning function looking only where it already expects to find things.

Rodrigo's agency established a two-person horizon scanning function in its technology services division, at an annual cost of approximately $85,000 including staff time and information service subscriptions. In the second year the function flagged an emerging capability in AI-assisted redaction, which let the agency get ahead of a FOIA processing bottleneck before it became a litigation risk. The staffing and cost that worked in one state agency's division are not a template for another; what transfers is the structure of the function, which is a named owner, a defined signal list, and a fixed reporting cadence.

Flexible Policies Built for Revision

Government policy is designed to be stable, which is appropriate for most regulatory matters and awkward for this one. The technology underneath AI policy changes faster than the policy review cycle, which means a policy written to the current state of AI will be outdated before it is fully implemented. The usual response is to write the policy more broadly, which trades one problem for another: a policy vague enough to survive the technology is usually too vague to tell anyone what to do.

Two mechanisms help. The first is a mandatory review clause requiring policy review every 18 to 24 months regardless of whether an incident has triggered a reactive review. This is standard practice in technology procurement policy at several federal agencies and belongs in AI governance policy at every level of government. The value of the mandatory clause is that it removes the need for anyone to argue that a review is warranted, which is the argument that does not get made when everyone is busy and nothing has visibly gone wrong.

The second is to separate principles from procedures. The principles are stable: AI systems must be subject to human oversight, equity impacts must be assessed before deployment, decisions affecting individual rights must be explainable. The procedures implementing those principles will need to evolve as the technology and the practice evolve. Keeping the two in separate documents makes it possible to update a procedure without reopening the underlying policy debate every time, and it makes visible which changes are technical adjustments and which are genuine changes in what the agency stands behind.

Both mechanisms depend on someone reading the resulting documents together. A procedures document that drifts far enough from its principles stops implementing them and starts quietly replacing them, and because procedure updates attract less scrutiny than policy changes, the drift can run for a long time before anyone notices. Build the check into the mandatory review: alongside asking whether the policy is still current, ask whether the procedures still do what the principles say. That is a short question with a written answer, and it is the one thing that keeps the separation honest.

What the State Archivist Knew

Rodrigo's FOIA AI contract eventually went through, with the vendor-agnostic data schema included, the 30-day data portability clause signed, and a review cadence set at 12 months. The tool reduced the agency's average FOIA response time from 23 days to 14 days. When the vendor was acquired 18 months later, the agency's data was fully portable within the contracted window, and a competing product was onboarded within 60 days with no migration project.

The sequence is worth reading carefully, because none of the protective decisions were made in response to the acquisition. They were made at signing, when the relationship was new, the vendor was accommodating, and nothing appeared to be at risk. That is the only moment at which those terms are cheap. Every one of them would have been a concession to negotiate for, or simply unavailable, at the point they were actually needed. Rodrigo had not predicted which AI tool would serve his agency in year three. He had built an organization that could adapt when the answer changed, and that is what futureproofing actually means in government.

Anti-Patterns

• Treating a portability clause as a portability guarantee. A contract term creates a right and an argument, not a working export. Vendors are acquired and product lines are discontinued, and the party that owes you performance may be unable to deliver. Exercise the export path while the relationship is healthy, verify that what comes out is usable, and treat an untested clause as an assumption rather than a control.
• Writing capability-based policy without naming who classifies new tools. Governing capabilities rather than products is the right design, but a new tool does not classify itself. If no office owns the determination and no step in the acquisition process forces it, the policy reaches every tool in principle and none in practice. Name the office, name the trigger point, and record the classification decision alongside the acquisition.
• Reading a horizon scanning report as coverage of the whole horizon. The function reports on the signals it was told to watch, and a capability from an unmonitored domain arrives with no lead time at all. Review the source list itself, and write down the categories you have decided not to watch so the gap is a choice rather than an oversight.
• Deferring adaptive design because the current tool works. Modular structure, portable schemas, and export terms cost something now and pay nothing visible today, so they are the first candidates for cuts. They are also unavailable when needed, because by then the leverage sits on the other side of the table. Decide them at design and signing.

Practice Prompts

• Check the AI contract your agency is closest to signing against the four adaptive design elements: modular structure, data export in a standard format with a stated deadline, capability-based policy coverage, and skills that transfer beyond this tool. Note which are absent and what it would take to add each before signature.
• Write two contrasting scenarios for one uncertainty that matters to your program, such as regulatory direction or vendor consolidation. Mark each of your three largest planned AI investments as robust across both or dependent on one, and bring the dependent ones to leadership labelled as bets.
• List the data your agency would need to take with it if it changed AI tools tomorrow: training data, processed outputs, system logs. For each, state the format it would come out in today and who at the vendor would have to be asked.
• Draft the signal list a horizon scanning function in your agency would monitor, then write the list of domains you are deliberately not monitoring and the reason for each. Ask a colleague from a different program to name one thing missing from the first list.
• Separate one AI policy your agency has issued into principles and procedures. Identify which sentences would need rewriting if the technology changed significantly, and move those into a procedures document that can be revised without reopening the policy.

Reflection

Think about the AI tool your agency depends on most heavily today and ask Rodrigo's question of it: if the vendor were acquired next quarter and the product line discontinued, what would the agency actually be able to take with it, and how long would the transition take? Then ask which of the answers were decided at signing and which would have to be negotiated now under pressure. The gap between those two lists is your agency's current exposure, and it is almost always larger than the people who signed the contract believe it to be.

Glossary

• Adaptive architecture. The organizational structures, policy designs, and workforce practices that let an agency respond to whatever AI becomes rather than to what it predicted. Its components are contract terms, data formats, policy structure, and skills.
• Scenario planning. A structured method that identifies key uncertainties, builds two to four contrasting stories about how they could resolve, and asks which decisions hold up across all of them. Its output is a sorted investment list, not a forecast.
• Robust decision. An investment that makes sense regardless of which scenario occurs. Robust decisions are infrastructure and get funded first; decisions that pay off in only one scenario are bets and should reach leadership labelled as such.
• Horizon scanning. Systematic monitoring of emerging technologies for potential impact on agency operations, run by a named function against a defined signal list on a fixed cadence. It gives lead time on what it watches and none on what it does not.
• Capability-based policy. Policy that governs categories of function, such as automated decisions affecting individual rights or biometric processing, rather than named products or model architectures, so that new tools fall under existing policy once someone classifies them.

Related Lessons

• Emerging AI Technologies Assessment covers the evaluation method for a capability once scanning has flagged it.
• Vendor Lock-In Prevention covers the contracting and architecture practices behind portability in depth.
• Long-Term AI Futures: 5, 10, 25-Year Horizons extends scenario work beyond the near-term planning window used here.
• AI Sandbox and Experimentation Frameworks and Building Innovation Ecosystems cover the structures that let an agency try an emerging capability before committing to it.
• Responsible Innovation: Speed and Safety and Workforce Planning for AI cover the pace and the staffing sides of the same adaptive capacity.

Closing

The vendor who told Rodrigo the tool was future-proof was making a claim about the product. Rodrigo's question, which future, moved the claim where it belonged: onto the organization. Nothing an agency buys is future-proof, and no framework here makes it so. What an agency controls is whether the data comes back, whether the policy still applies when the tool changes, whether staff can judge a new system on its merits, and whether anyone is watching for what is coming. Each is decided early and unavailable later. Rodrigo could not name the tool his agency would use in year three. He could name what would still be true about the agency whichever one it was.

Key Takeaways

• Futureproofing means building adaptive capacity, not predicting specific technologies. The organizations that survive technological change are the ones built to adapt, not the ones that guessed correctly.
• Scenario planning identifies robust decisions. Sort candidate investments by whether they pay off across all your scenarios or only one. The first group is infrastructure and gets funded; the second is a bet and should reach leadership labelled as one.
• Require data portability in every AI contract, and test it. Mandate exportable data in a standard format within 30 days of termination, and exercise the export while the relationship is healthy. A clause creates a right, not a working export from a vendor that has been acquired or has failed.
• Write policy around capabilities, not products. Define what triggers governance, such as automated decisions affecting individual rights or biometric processing, and name the office and acquisition step where a new tool gets classified.
• Invest in durable cognitive skills, not just tool-specific training. Critical evaluation of outputs, override judgment, and accountability documentation transfer across every generation of tools, and they improve procurement decisions as well as operations.
• Establish a horizon scanning function with a named owner, a signal list, and a fixed cadence. It buys lead time to adapt procurement, policy, and workforce, but only for the signals you chose to watch. Review the signal list itself.
• Build mandatory review cycles into AI policy and separate principles from procedures. A review trigger every 18 to 24 months removes the need for anyone to argue that a review is warranted, and separated documents let procedures be updated without reopening the underlying policy each time.
• Adaptive terms are cheap at signing and unavailable later. Modularity, portable schemas, and export deadlines pay nothing visible on the day they are agreed, which is why they get cut and why their absence is discovered under pressure.

Frequently Asked Questions

Is modularity worth the higher initial design cost for a small deployment? Weigh it against the contract term rather than the deployment size. The exposure a monolithic design creates is being unable to change anything until the contract ends, so a long term carries far more of it than a short one. Where the term is long, treat the extra design cost as the price of being able to act during it.

How do we run scenario planning without it becoming a speculation exercise? Keep the scenarios in service of a decision list. Build the contrasting stories, then immediately run your actual planned investments against them and sort the results. A session that ends with sorted investments has produced something usable; a session that ends with vivid scenarios and no sorting has produced a document nobody will open again.

Our agency cannot fund a dedicated horizon scanning team. What is the minimum? The structural elements matter more than the staffing: someone named as owner, a written list of signals, and a fixed reporting cadence. With those three defined the work can be assigned to an existing analyst. What does not work is scanning as everybody's responsibility, which reliably means nobody's.

If policy governs capabilities rather than products, how do staff know what applies to a new tool? Someone has to make the classification, and the policy should say who and when. Attach the determination to a step that already happens, such as acquisition review or the governance intake for a new system, so that no tool enters use without having been placed in a category or explicitly found to be outside all of them.