The short version: a successful pilot produces a decision, not a deployment. The ten steps below take you from an approved decision paper to an institution-wide service, each with its owner and its artefact. Two of them — the procurement route and the exit terms — have to happen before signature, and both are routinely discovered afterwards.
This picks up where a departmental pilot ends. If you have not run one yet, do that first: the eleven steps and the criteria sheet are in how to run a departmental pilot of an AI writing tool, which is deliberately scoped to one term and one department. Breadth across the institution is a rollout, and it is a different exercise.
Step 1: Re-scope the problem statement at institutional scale
Owner: the sponsor. Artefact: a revised one-paragraph problem statement plus a named exclusions list.
The pilot’s problem statement was written for one department. Before extending it, establish where the evidence does not transfer. A result obtained in a taught master’s programme in social science says little about a studio-based art faculty, a clinical programme with placement-based assessment, or a mathematics department writing in LaTeX.
Name those units explicitly and state what you will do about them: include with an adapted deployment, defer to a later wave, or exclude. An exclusions list written now is a plan; the same list written after a faculty complains is a retreat.
Step 2: Establish the contract value and the procurement route
Owner: procurement lead. Artefact: a written route determination.
This is the step that most often adds six months to a timeline nobody had budgeted six months for, and it turns on a number.
If your institution is a contracting authority under EU public procurement rules — most publicly funded European universities are; private institutions may not be — then Directive 2014/24/EU applies above a stated threshold. For 2026–2027, set by Commission Delegated Regulation (EU) 2025/2152 of 22 October 2025, the figures are:
| Contracting authority | Service and supply contracts |
|---|---|
| Central government authorities | €140,000 |
| Sub-central contracting authorities (where most universities sit) | €216,000 |
| Social and other specific services (Annex XIV) | €750,000 |
Two things determine whether you cross it. The value is the estimated total for the contract, which includes the full term and any options or extensions, not the first year’s invoice. And the pilot’s price per seat is not the institutional price per seat, in either direction.
A departmental pilot almost always sits below the threshold. A three-year institutional licence for a research-intensive university almost always sits above it, and above it the default is an EU-wide open procedure with published timescales. Get the determination in writing from procurement before you tell anyone a launch date. Institutions outside the EU are under their own regimes — the UK and US have separate rules and separate figures — so confirm yours rather than transposing these.
Step 3: Extend the data protection position, do not carry it forward
Owner: data protection officer. Artefact: an updated assessment and an updated record of processing.
A pilot assessment was scoped to one cohort, one set of purposes and one integration depth. Institutional deployment changes the population, usually adds purposes such as analytics or reporting, and typically deepens the integration. That is a materially different processing operation, and the assessment has to be re-run rather than amended in the margin.
Two specifics are commonly missed at this step. Confirm your lawful basis still holds at the new scale and for the new purposes, which is a narrower question than most institutions assume — see whether a university can rely on student consent. And re-run the assessment itself against the current criteria rather than the pilot’s, using the sequence in how to run a data protection review before deploying an AI writing tool.
Step 4: Secure the exit terms before signature
Owner: contracts. Artefact: four clauses in the executed agreement.
Leverage exists exactly once, and it is now. Four things belong in the agreement:
- Export format and completeness. Named machine-readable formats, covering documents, metadata and version history — not a screen-scrape or a bulk PDF dump.
- Deletion timetable. What is deleted, from where, including backups, and by when.
- Evidence of deletion. A written certificate, not an assurance in a support ticket.
- Transition assistance at no charge. A stated number of days of vendor effort during wind-down.
Charging for export or deletion prices the option to leave, and an institution that cannot leave is not negotiating at renewal. The wider question set to put to a supplier is in our procurement question bank.
Step 5: Harden the integration
Owner: IT lead. Artefact: a signed-off integration test plan with results.
Pilots frequently run on a shared link, a manually managed user list or a departmental tenant. None of that survives institutional scale. Move to production single sign-on and automated provisioning, and test the part everyone forgets: de-provisioning. A leaver whose account persists is a data protection finding, and it will be found at the next audit rather than the next login. The routes and the service-selection decisions are covered in how to set up SSO and LMS integration.
Step 6: Publish the rules before enabling access
Owner: academic registrar. Artefact: updated student-facing guidance with a version date.
The rules must be in force on the day the tool becomes available, not in the term after. Enabling a capability before publishing the standard that governs it produces a cohort who used it under no rule and cannot fairly be judged by one applied later.
Practically, that means the assessment regulations, the disclosure requirement and the permitted-use categories are all updated before the enablement wave, not alongside it.
Step 7: Build the support model before the first ticket
Owner: service desk manager. Artefact: a one-page routing document.
Three questions, answered in writing: where does a user go, who answers, and what is the escalation path to the vendor with what response time. A pilot was supported informally by the person who ran it. At institutional scale that person becomes a bottleneck within a fortnight, and the deployment’s reputation is set by the first hundred support interactions rather than by the tool.
Include a named vendor contact and the contractual response time in the same document, so the escalation path is a fact rather than an email address someone remembers.
Step 8: Train the trainers, not the institution
Owner: academic development lead. Artefact: a session pack plus a named local lead per faculty.
Central training delivered to everyone is the most expensive and least effective option available. Prepare one adaptable session and a local lead in each faculty who can translate it into that discipline’s practice.
Two things belong in the pack beyond the mechanics. The European Code of Conduct for Research Integrity (2023 revised edition), which the European Commission recognises as the primary standard for research integrity in EU-funded projects, states in its section on Training, Supervision and Mentoring that senior researchers and supervisors “mentor their team members, lead by example, and offer specific guidance and training to properly develop and structure their research activities”. Staff who cannot use the tool cannot model its use.
The same Code also requires researchers to report methods “including the use of external services or AI and automated tools” in a way that facilitates verification, and lists “hiding the use of AI or automated tools in the creation of content or drafting of publications” among violations of research integrity. Those duties fall on staff as well as students, which is the part training packs usually omit. The wider curriculum question is handled in how to build an AI literacy curriculum.
Step 9: Phase the enablement by faculty
Owner: programme manager. Artefact: a wave plan with a readiness definition.
Define readiness before you define the schedule: local lead trained, rules published to that faculty’s students, integration tested against that faculty’s programmes, support routing live. A faculty that meets the definition goes in the next wave; one that does not, waits.
Put a genuine hold point between waves — a week in which no new faculty is enabled and the support queue is read. The purpose of a wave structure is to make it possible to stop, and a schedule with no gap in it cannot be stopped without being seen to fail.
Step 10: Instrument the rollout and fix the review date
Owner: the sponsor. Artefact: a measurement plan and a diarised review with a named owner.
Carry the pilot’s baseline measures forward unchanged so the two are comparable, then add the three the pilot did not need: activation rate by faculty, support tickets per hundred active users, and de-provisioning accuracy. Set the review date at launch, with a named owner and a fixed date, because a rollout without a review date becomes an assumption.
State also what would cause you to stop. A rollout, like a pilot, needs a stop condition it is allowed to meet.
A realistic timeline
| Phase | Elapsed | Gating item |
|---|---|---|
| Decision paper approved to route determination | 2–4 weeks | Procurement’s written answer |
| Open procedure, if triggered | 4–9 months | Published timescales, plus evaluation |
| Data protection review at institutional scope | 4–8 weeks, in parallel | DPO capacity, not complexity |
| Contract negotiation including exit terms | 4–8 weeks | Legal review of the four clauses |
| Integration hardening and testing | 4–6 weeks | De-provisioning test |
| Wave enablement across faculties | One to two terms | Readiness definition, not appetite |
The single most useful thing this table does is show a committee that the procurement route, not the technology, is the long pole. Deciding it in week one changes the whole plan.
If you would like to work through the route determination, the exit clauses and a wave plan against your own governance calendar, request an institutional evaluation and we will go through them with your procurement and DPO leads.
Frequently asked questions
Does a successful pilot let us skip a tender?
No. A pilot is evidence for a decision, not a procurement route. If the institutional contract value crosses the applicable threshold, the procedure that threshold requires applies regardless of how the pilot went.
What is the EU procurement threshold for a services contract in 2026?
Under Directive 2014/24/EU as amended by Commission Delegated Regulation (EU) 2025/2152, €140,000 for central government authorities and €216,000 for sub-central contracting authorities, for the years 2026–2027.
Is the threshold measured per year?
No. It is the estimated total value of the contract, including the full term and any options or extensions. A modest annual figure over a long term can cross it.
Do universities count as contracting authorities?
Publicly funded universities in EU member states generally do, as bodies governed by public law. Private institutions may not. Confirm your own status with procurement rather than assuming either way.
Can we reuse the pilot’s data protection assessment?
Not as it stands. A change of population, purposes and integration depth is a materially different processing operation and needs the assessment re-run at the new scope.
What exit terms should we insist on?
Named export formats covering documents, metadata and version history; a deletion timetable including backups; written evidence of deletion; and transition assistance at no charge.
Should we enable everyone at once?
No. Wave by faculty against a written readiness definition, with a hold point between waves in which nothing new is enabled and the support queue is read.
Who should own the rollout?
A sponsor with budget authority, not the person who ran the pilot. The pilot owner should remain involved, because they hold the baseline, but a rollout needs someone who can stop it.
What should we measure that the pilot did not?
Activation rate by faculty, support tickets per hundred active users, and de-provisioning accuracy. Carry the pilot’s baseline measures forward unchanged so the comparison stays valid.
How do we handle a faculty that refuses?
Put it on the exclusions list at step one with a stated reason and a review date. An unmanaged refusal becomes a shadow deployment on someone’s departmental card.
Do staff have obligations of their own here?
Yes. The European Code of Conduct for Research Integrity requires researchers to report the use of external services or AI and automated tools, and lists hiding such use among violations of research integrity.
What is the most common reason a rollout stalls?
A procurement route determined after the launch date was announced. It is the cheapest step on this list and the most expensive one to take late.