A school can work productively with a major technology company without handing over control of its educational future. The useful question is not whether a provider is a partner or a threat. It is whether the school can still protect learning, understand how its systems work and change direction when a product, price, policy or AI model changes.
Dependence becomes a problem when essential records, routines, expertise or teaching decisions are difficult to move or sustain without one provider. That risk can be reduced before adoption: define the learning purpose, map what the school would rely on, test whether data and work can travel, and preserve the professional knowledge needed to continue without a particular feature.
Reliance is normal; avoidable lock-in is a design choice
Schools rely on other organisations every day: publishers, transport operators, assessment services and internet providers. A digital platform can also bring real value. A well-supported service may improve access, reduce local maintenance, connect existing systems or give teachers useful tools that a school could not build alone.
The goal is not technological self-sufficiency. It is a relationship in which the school understands the exchange and retains meaningful choices. A school is not necessarily “locked in” because it uses one platform. The stronger test is what happens if it needs to leave, pause, reduce use or replace a component.
That distinction matters because “vendor lock-in” is sometimes used as a catch-all accusation. In practice, it describes a specific loss of choice: the cost or difficulty of switching becomes high enough that an institution keeps a service even when another option, a new policy or a changed educational need would be preferable. Costs may be financial, but they can also be operational: lost records, broken integrations, retraining, disrupted timetables or a teaching approach that staff cannot reproduce elsewhere.
The concern is therefore not that a large provider has influence simply by being large. It is whether the school can see where that influence enters the system and whether it has practical alternatives.
Four layers of dependence can accumulate
Data dependence is the most visible. A provider may hold student accounts, assignments, feedback histories, settings and activity records. A downloadable file is useful, but portability is not proved by the existence of an export button. Can the school identify what is included, preserve relationships between records, read the format without the original platform and import the information into a successor system? Are there records that cannot or should not be transferred? Who is responsible for return, deletion, backups and confirmation at exit?
A second layer is technical dependence. A tool may connect to a school’s identity service, management information system, learning platform, assessment records or content library. Each connection can make daily work smoother; several tightly coupled connections can also make a change harder. An API is not automatically meaningful interoperability: the school needs documentation, permission, a stable format and a receiving system that can use the information.
Third is workflow dependence. Staff build habits around the platform: where assignments are created, how feedback is reviewed, which dashboard signals prompt an intervention and what students are asked to do next. Those routines can be worth keeping. But if only the vendor knows how a workflow was configured, or if teachers have never discussed the educational decisions embedded in it, switching the software may also erase the school’s own process.
Finally, there is pedagogical dependence. AI can shape what counts as a good answer, how a task is sequenced, which hints are offered and when a learner is considered ready to move on. If staff cannot explain or challenge these choices, a product is doing more than delivering a feature: it is quietly setting part of the instructional environment. That does not make the tool harmful by definition. It does mean educators need enough knowledge to judge its role and revise the design.
These layers interact. A platform can be easy to export from but hard to leave because staff routines depend on its feedback workflow. A school may have a contractual exit clause yet lack the technical capacity to test migration. The relationship is resilient only when data, operations and professional judgment are considered together. For the classroom side of this question, see how schools can turn AI policy into routines and evidence.
Current guidance points towards reversibility
Recent guidance makes this concern concrete without proving that every school is locked in. In September 2026, UNESCO reported a joint ministerial statement calling for AI systems in education to be auditable, data to be portable, total ownership costs to be considered and education systems to retain the ability to change course. This is a public-interest policy direction, not an empirical finding that a particular product causes dependence.
The OECD’s Digital Education Outlook 2023 explains why interoperability matters: when systems cannot exchange information, moving providers can become more difficult and records may be lost or costly to reconstruct. The report also describes trade-offs in how systems are provided. Central procurement can support consistency and technical capacity; local or school-level choice can respond more closely to local needs. Neither model automatically guarantees flexibility. A fragmented collection of tools can be as difficult to manage as a single tightly integrated platform.
England offers practical examples of how to turn reversibility into requirements. The Department for Education’s school MIS procurement principles, updated in July 2026, call for migration-ready, machine-readable school data, access by download or API and supplier cooperation during migration, including at contract exit. These principles apply to school management information systems in England; they are not a universal rule for every AI product or jurisdiction.
Separate Department for Education guidance for schools and colleges on cloud services asks schools to plan for portable data, common or open formats, secure documented APIs and timely transfer at contract end. Its EdTech data-protection guidance, updated in October 2026, also directs schools to review changes to AI tools and consider portability, data return and deletion, including backups. Together these sources show that exit planning is not merely a procurement formality. It touches technical operations, privacy and continuity.
They do not answer every educational question. A machine-readable record may preserve a student’s submission while losing the teacher’s reasoning about the feedback. A functioning API may transfer data but not reproduce a classroom routine. Contract terms can protect rights on paper while a school still lacks time, staff or a destination system. Reversibility has to be exercised, not just promised.
A hypothetical school scenario: when the tool becomes the routine
Consider a fictional school network that adopts an AI feedback service to help teachers respond to student writing. The initial decision is limited: a small group tests feedback on one type of assignment. Teachers compare the suggestions with their own criteria, revise unsuitable comments and decide what students should do with the feedback.
Over time, other departments use the service. The network connects it to student accounts, stores examples and creates a local workflow around its feedback categories. Staff begin to refer to those categories in meetings. Nothing about that growth proves the service is bad; it may be meeting a real need. But the school’s exposure has changed. The decision is no longer just “Do we renew a writing tool?” It now includes which records can move, whether the categories map to the school’s own assessment language, how teachers will work if the service changes and whether the student experience can continue during migration.
Imagine the provider later changes a feature or the school decides its contract no longer fits. A data export may contain the final writing but not a useful history of feedback. Some routines might be rebuilt; others might have to be reconsidered. The school can still leave, but leaving has become a curriculum and workload decision as well as a technical one.
This example is hypothetical, not a reported school case. Its point is to expose a common planning blind spot: the dependency usually forms through ordinary success. Teams adopt a useful feature, connect it to existing systems, train people and rely on it. By the time someone asks about exit, the institution may have invested in much more than a licence.
A six-part reversibility test for school leaders
Before expanding an AI or learning platform, leaders can ask whether the school has clear answers to six questions:
| Test | Question to ask | Evidence to request |
|---|---|---|
| Learning purpose | Which learning task should improve, and what must remain a teacher or learner decision? | A defined use case, review criteria and a non-AI comparison where appropriate |
| Data portability | What can the school retrieve, in what format, and what cannot be transferred? | A sample export, field descriptions, relationships between records and a deletion plan |
| Interoperability | Can another authorised system use the information without a proprietary workaround? | Current API documentation, transfer permissions and a test with a plausible receiving system |
| Change management | How will the school know when a model, feature, data flow or term changes? | Notice periods, version/change information, human review and a process to pause a feature |
| Retained capability | Could teachers explain and continue the learning routine if the tool were unavailable? | Staff-owned criteria, editable materials, practice and a workable manual or alternative route |
| Exit readiness | Who would migrate, how long might continuity take and what would the school pay or do? | Named responsibilities, timetable, service continuity, costs and a rehearsed exit scenario |
The table is a decision aid, not a certification scheme. The answers should be specific to the tool and the school’s legal and technical setting. A supplier’s general assurance that “data can be exported” is not a substitute for seeing a representative export and confirming that the school can make sense of it. Equally, not every log or AI interaction should be retained or moved; privacy, purpose limitation and retention duties still apply.
Keep the educational core outside the product
A practical partnership distinguishes what the school is buying from what the school must continue to own as professional work. Teachers and leaders should retain the learning objectives, assessment criteria, safeguarding decisions and judgment about whether an AI-generated suggestion is appropriate. A supplier can provide a service and explain its design; it cannot assume the school’s responsibility for deciding what counts as learning in a particular class.
This boundary is especially important when AI features change. A feature that once generated optional prompts may later recommend actions, summarise student work or process new kinds of information. The correct response is not to assume that every update is dangerous, nor to accept every update as trivial. Ask what changed, which users and data are affected, whether the educational purpose still holds and who has authority to pause or review the feature.
Leaders should also separate the value of a product from the visibility it creates. A polished demonstration can make innovation feel urgent; a strong partnership can also include a small trial, a negative finding or a decision not to expand. A school is better positioned when it can say both what a provider contributes and what the institution has learned independently. That includes asking whether students learn more, rather than treating adoption as the outcome; our article Your School Has AI. Are Students Actually Learning More? examines that distinction.
Make the relationship collaborative and reversible
Good partnerships do not require suspicion. They require clarity. Schools can invite providers to explain limitations, support migration and respond to educator feedback while retaining the ability to test claims and choose another path. A provider that helps a school understand its data and exit options is not undermining the relationship; it is making the relationship more credible.
For school leaders, the best time to discuss dependence is before adoption and before renewal. Map the data, integrations, routines and skills the service will touch. Agree how updates will be reviewed, how records will be returned or deleted, how continuity will be maintained and what would trigger a pause or exit. Then test one concrete scenario: if the service were unavailable next term, what would teachers need in order to continue the learning task?
For education conference organisers, this is a more useful conversation than a general debate about whether schools should embrace technology. A leadership session can compare two adoption plans: one that optimises for immediate convenience, and one that includes a learning objective, an exit route, a continuity plan and retained teacher judgment. The discussion is not anti-vendor. It is a way to turn enthusiasm into a decision that remains answerable to learners.
School technology choices inevitably create relationships and reliance. The objective is to keep that reliance proportionate, visible and reversible enough that a school can preserve the parts that help and change the parts that no longer do.
A school’s capacity to choose again is part of responsible innovation. Planning a school leadership or education conference about AI, learning and institutional readiness? Explore Learning Coach’s international keynotes and request a tailored proposal.
References
UNESCO. Education Ministers call for education to remain a common good in the age of AI at UNESCO’s Digital Learning Week. 9 September 2026; updated 10 September 2026. UNESCO’s report on the joint ministerial statement and its public-interest priorities for AI in education.
OECD. Digital Education Outlook 2023: Interoperability—unifying and maximising data reuse within digital education ecosystems. 2023. Analysis of interoperability, switching costs and vendor lock-in risks in digital education ecosystems.
OECD. Digital Education Outlook 2023: Public procurement—shaping digital education ecosystems. 2023. Discussion of procurement models and their trade-offs; not a study of current AI vendors.
UK Department for Education. Core Principles for school MIS procurement. Updated 17 July 2026. Applies to England and school management information systems.
UK Department for Education. Meeting digital and technology standards in schools and colleges: Cloud solutions. Published 23 March 2022; updated 16 September 2026. Guidance on portable data and cloud transfer for schools and colleges.
UK Department for Education. Data protection in schools: Procuring educational technology (EdTech). Published 3 February 2023; updated 14 October 2026. UK school guidance on EdTech data protection, changes and exit planning.
Sources accessed 29 October 2026. This article is an editorial decision framework, not legal advice or an evaluation of named vendors. The England examples are explicitly jurisdiction- and system-specific.
