Companies today run real work on a handful of large AI providers. Switching between them looks trivial: change one parameter in an API call and a different model answers. Regulation increasingly demands the ability to exit, for instance under the EU Data Act and the EU AI Act, and on paper that demand is easy to satisfy.

But the decisive question is not settled in the API call. It is settled in everything around it. Whether a company can actually move a workflow to another model, or keep it running when a model is deprecated, is determined by the prompts that were tuned to one model's quirks, by the evaluation that establishes whether output is good enough, by the retrieval setup and the tool schemas. Whoever builds these around one provider today has a workflow that is switchable on paper and stuck in production tomorrow.

Surprisingly little is known about this. Research on provider dependence measures the organisation as a whole, not the workflow where the work actually happens. And the obvious remedy — an orchestration layer that keeps the workflow model-independent — introduces a dependence of its own, on the orchestrator. Whether that is a good trade has, as far as we can tell, never been measured.

The scope of this thesis is deliberately open. Topic, focus and method can be shaped in a personal brainstorming session with the supervisor, so that the work fits your own interests and prior knowledge. What follows are possible directions, not a fixed specification.

The overall theme: how dependence on AI providers can be measured for a single workflow, what changes when that workflow is re-built to be model-independent, and what the independence costs — including the new dependence on the orchestration layer itself.

Possible directions, as examples:

• A measurement instrument for a single workflow, and what it cannot measure. Dependence is currently described for whole organisations. Some of those constructs survive the move down to one workflow and some do not: technical portability and key control can be established per workflow, continuity and in-house competence arguably cannot. Establishing which is which, and why, is a contribution in its own right — as is naming the dimensions that only appear with AI, such as prompt specificity, model deprecation, and the fact that a switch is only complete once output quality has been re-established.
• A before-and-after study of one workflow in two architectures. A regulated SME runs a real process directly on a provider's model; the same process is then re-built on a model-independent orchestration layer. The centrepiece is an actual, documented switch — not the claim that switching is possible, but the attempt, with the effort and the quality drift it produces.
• A switching experiment. The same reconstructed workflow run across several model classes, from a frontier model to a small local one, measuring porting effort, which artefacts had to change, output quality against a gold standard fixed in advance, cost per run and latency. The analytical core is the decomposition: once the model is decoupled, where does the remaining dependence sit?
• A focused deep dive into a single mechanism, for example what a model switch really costs in output quality, or what the option to switch is worth once the orchestration layer's own fixed cost is priced in.

Possible approaches, depending on the direction chosen: review of research literature and practitioner documentation such as provider deprecation policies, the switching provisions of the EU Data Act and current evaluation frameworks for language-model output; interviews with IT architects and process owners; assessment against real workflows; or a measurement setup.

Two directions depend on access to a pilot company, and that access is not yet secured. The other two do not. We agree which of the two situations you are in before you start, not afterwards.

One thing is worth saying plainly, because it shapes the design: the thesis tests an effect on a case, it does not assert one. A finding that dependence barely shifts, or that it simply reappears somewhere else, is a full result and will be graded as one.

• Studies in information systems, computer science, management, or a related field
• Interest in AI systems and in how technical decisions produce economic consequences
• Willingness to work through technical documentation and English-language research literature
• Structured, independent way of working, and the patience to fix a definition before collecting data
• An advantage but not a requirement: hands-on experience with language-model APIs, workflow automation, or empirical methods

• Close, hands-on supervision. Regular meetings, quick feedback, and a supervisor who is actually reachable between appointments.
• A topic that matters. The thesis is embedded in an ongoing doctoral project on corporate digital sovereignty and in a funded project with two Swiss companies. Your results feed into current research rather than disappearing into a drawer.
• Room to shape it. The concrete question is developed together with you, along your interests and prior knowledge.
• A prepared starting point. Access to a curated body of literature, existing preliminary work, and an established method for the topic, so you do not start from zero.
• Support on the craft. Help with research design, structure and academic writing, not just on the content.
• Your work stays yours. Data you collect belongs to you. If anything from your thesis is used in the doctoral project later, it is cited, not absorbed, and that is agreed in writing beforehand.
• Flexible working arrangements. Remote or on site, as it suits you.

Please send a short email with:

• a brief note on what interests you about the topic, a few sentences are enough
• your CV
• a current transcript of records

No motivation letter, no cover page. I care about whether the topic fits you, not about formatting.

After that we hold a short interview of about 15 minutes, in person or online. The point is not to test you. We use it to work out together which direction of the topic fits you, and whether the supervision is a good match on both sides.

The start date can be arranged, but note that theses are registered only four times a year, on 1 February, 1 May, 1 August and 1 November. Registrations outside these dates are rejected automatically, and the official working period starts on registration — so plan backwards from the deadline you are aiming for and get in touch early enough that we can prepare the proposal together.

Feel free to get in touch even if you are still unsure whether the topic is right for you, or if you would like to discuss a different angle on it. A short conversation usually clears that up faster than an email exchange.

Contact: Adrian Bohrer, adrian.bohrer@unisg.ch