The hotel industry knows how to plan for things going wrong. Disaster recovery playbooks, business continuity procedures, redundancy across reservations infrastructure—these are established disciplines. Most hotel CIOs have already pressure-tested their organizations against cyber incidents, outages and platform failures.
But there is a gap in almost every continuity plan written in the last three years, and it sits beneath one of the most significant technology shifts the sector has ever made.
The artificial intelligence (AI) foundation models underpinning revenue management systems, guest messaging platforms, virtual concierge tools and review response workflows are rarely under the direct control of hotel operators. Instead, they are typically supplied by third-party providers, often through software vendors already embedded within the wider technology stack.
If a provider retires a model, changes pricing or shifts strategic direction, the impact can extend well beyond a single application, affecting multiple workflows simultaneously.
That is not a theoretical scenario. It is already happening. Since 2023, OpenAI has issued deprecation notices for dozens of model versions, typically providing organizations with only a few months' notice before support ends. As AI providers continue to evolve their models, this is becoming part of the normal technology lifecycle rather than an exceptional event.
The dependency hotels don't realize they have
For hotel CIOs, the challenge is that AI dependency rarely arrives through one deliberate strategic decision. Instead, it accumulates gradually.
The numbers reflect just how embedded AI has become in hospitality and how exposed most organizations are. The H2c 2025 global study found that 78% of hotel chains already deploy AI systems, yet only 7% operate with a comprehensive AI strategy.
Many operators never receive deprecation notices directly because the contractual relationship sits with the software vendor rather than the hotel itself. As multiple software-as-a-service products often rely on the same underlying providers, a single model change can affect several systems simultaneously before organizations fully understand the impact.
What a real AI continuity plan covers
Reducing this risk does not mean avoiding AI. Instead, it means treating AI resilience as an architectural consideration rather than simply a product decision.
The first step is understanding where AI is actually being used. Many AI capabilities are embedded within third-party software, meaning operators may not even know which models support critical business processes. Mapping those dependencies makes it easier to identify concentration risk before it becomes an operational problem.
The second priority is building flexibility into the technology architecture. Rather than tightly coupling applications to a single model provider, organizations should design systems that can switch between models with minimal disruption. Technologies such as the Model Context Protocol provide an abstraction layer between applications and model providers, making future transitions significantly easier to manage.
The third layer combines multi-model architecture with version control. Run different models for different tasks based on cost, latency, or data residency: a lightweight model for classification, a larger one for complex reasoning, a local model for sensitive data that cannot leave your infrastructure.
Equally important is recognizing where the real long-term value sits. AI agents are increasingly making commercial decisions, from adjusting pricing to responding to guests and processing reservations. The governance surrounding those decisions—approval workflows, authority limits and business rules—should exist independently of any individual model. When those rules are maintained separately, organizations can adopt new models without rebuilding months of operational knowledge.
Your prompts, governance rules, authority ceilings and operating procedures are the real intellectual property built on top of a model. Treat them as code. Store them in Git. Run them through a continuous integration and continuous delivery pipeline that validates outputs against your primary and fallback models. A tested fallback with a second provider is meaningful risk reduction but only if the governance layer survives the switch intact.
Where portability gets tough
Good architecture reduces the blast radius, but it does not remove the portability problem. Prompts tuned for one model can behave meaningfully differently on another, a behavioral problem that only regression testing can surface. And you cannot back up a proprietary foundation model. What you can preserve is everything built on top of it: your governance logic, prompt library, evaluation suites and integration architecture.
As AI agents become more deeply embedded in hotel operations, the accumulated value lies not in the model itself but in the operating procedures, authority limits and governance that sit around it. When those assets are portable, organizations can change models without rebuilding operational trust from scratch.
Technology vendors should also be transparent about which models underpin their products, how model changes are managed and what contingency plans exist if providers alter pricing, licensing or availability.
The architecture question hotels need to ask
Good governance and abstraction layers matter, but they can only do so much if the underlying platform is not built for openness. The hotels navigating AI model transitions most confidently are those where the AI layer sits above the core systems rather than baked into them. When that separation exists, swapping a model is a routing decision, and the governance layer ensures the new model operates within the same boundaries as the old one.
AI models will continue to change, deprecate and evolve. That is not a risk to be feared; it is a condition to be designed for.
The hotels best positioned for what comes next are those whose architecture already assumes that reality and whose operational governance is portable enough to survive it. The single point of failure is already in your stack. The question is whether you have the architecture to do something about it before it fails.
About the authors...
Stephan Wiesener is the co-founder and CTO of
Apaleo. Mike Rawson is the CIO of
citizenM.