Test question generation from teaching material

Test question generation is the process by which teachers and school administrators turn existing teaching material into ready-to-use test questions at defined difficulty levels. A teacher identifies a need, selects the relevant source material, drafts questions manually, checks that each question has exactly one correct answer, and then passes the draft through a review and approval step before the final question set is stored and used. The whole cycle currently runs on email and spreadsheets, with no single system holding the end-to-end process. It happens several times a day across a team of roughly twenty teaching staff and one administrator, adding up to around 1,500 runs per year at an average of twenty minutes each.

The process carries two layers of constraint that shape any automation decision. First, the school operates within a centrally managed, locked-down IT environment with limited in-house technical capability, which rules out any solution that requires local installation, bespoke development, or ongoing developer support. Second, because teaching material may touch on information about identifiable minors, the process sits under GDPR with heightened care, and institutional policy requires that a human being remains accountable for every final question set before it goes into use. These constraints are not obstacles to automation; they are design requirements that the right solution must meet from the start.

The recommended path is an AI Workflow: a hosted, low-code platform that takes teaching material as input, drafts questions at the required difficulty levels using a large language model, and routes the output through a human review gate before anything is approved for use. The case for this path rests on a straightforward match between what the process needs and what current AI tooling can reliably deliver. Generating structured, curriculum-aligned questions from semi-structured text is precisely the kind of language task that modern LLMs handle well. The rules for standard cases are clear enough to express in a prompt template, the volume is high enough to justify the investment, and the 10 to 15 percent of exception cases are handled cleanly by routing them to a human reviewer rather than asking the AI to resolve genuine ambiguity.

The school's technology situation points firmly toward a hosted SaaS platform rather than anything that requires installation or developer resource. Microsoft Copilot Studio is a strong candidate given that many schools already operate within the Microsoft 365 ecosystem, which simplifies both central IT approval and GDPR compliance through Microsoft's EU data residency commitments. Other EU-compliant, browser-based low-code AI platforms are viable if the school's IT governance points elsewhere, but the principle is the same: the tool must be accessible via a standard browser, governable by central IT policy, and hosted entirely within a compliant EU environment. No local infrastructure, no Python scripts, no ongoing developer involvement.

It is worth being direct about why the AI Workflow scores higher than the Hybrid path despite their surface similarity. The distinction between the two in this context is mostly one of framing. A well-designed AI Workflow already incorporates human review gates, so calling it a Hybrid adds no practical value and risks introducing a more elaborate escalation structure than a small, non-technical team can sustain. The AI Workflow recommendation is not a lights-out automation; it is a system where AI handles the drafting of the 85 to 90 percent of standard cases and humans handle everything that requires genuine judgement. That division of labour is what makes both the workload saving and the compliance position achievable at the same time.

The Education path, which would mean training staff to use AI assistants directly without a structured workflow, is a realistic near-term complement rather than a replacement. It could be deployed quickly and at low cost, and the AIRIES learning programme covers exactly the skills involved. However, it would not deliver the consistency or throughput that a workflow provides, and it would leave each teacher making individual decisions about which AI tool to use and how, which creates an unacceptable data compliance risk in an environment where consumer AI tools might become a workaround. Education is therefore positioned as a parallel investment that equips the administrator to manage the workflow and the teaching staff to review AI output critically, not as an alternative to the workflow itself.

RPA, Traditional Code, and AI Agent all fail for different but clear reasons. RPA cannot generate natural language content and would add brittle screen automation on top of a process that is already inconsistent. Traditional Code would require developer resource and local hosting that the school does not have and cannot easily acquire. A fully autonomous AI Agent without human checkpoints is ruled out by both GDPR and institutional assessment policy: there must be a human accountable for every question set, and that accountability cannot be delegated to an autonomous system. The only honest recommendation given all these constraints is the AI Workflow, and the tradeoff it requires, preserving human review rather than automating it away, is not a weakness of the approach but a deliberate and necessary design choice.

The two strongest paths here are AI Workflow and Hybrid, and in practice the gap between them is narrower than the labels suggest. The recommended AI Workflow already incorporates human review gates for exceptions and a final approval step before questions go live, which means it carries the essential features of a hybrid approach without the additional coordination overhead. A more formally structured Hybrid path, with dedicated escalation workflows and distinct human decision stages built around every step, would add process complexity that a small team with limited technical capability would find difficult to sustain. The AI Workflow wins because it keeps the human involvement where it actually matters, at the exception and approval stages, rather than distributing it across the whole process.

Education and upskilling via the AIRIES programme is a genuine alternative worth acknowledging, not a consolation option. If central IT approval for a hosted platform takes longer than expected, or if budget is constrained in the short term, training staff to use a compliant AI assistant directly for question drafting is a realistic interim step. It would not match the consistency or throughput of a structured workflow, and it places more cognitive load on individual teachers, but it builds the foundational skills that make the eventual AI Workflow adoption easier. The two paths are complementary rather than competing.

RPA, Traditional Code, and AI Agent all score poorly for reasons that are specific to this process rather than generic. RPA has no role in generating natural language content from semi-structured teaching material. Traditional Code would require developer resource and infrastructure the school does not have, and would still need an AI component to do the generative work. An autonomous AI Agent operating without structured human checkpoints is inappropriate where GDPR obligations covering data on minors and institutional accountability for assessment decisions are both in play. Staying manual perpetuates the exact problem the client wants to solve, so it is not a viable baseline.

The first practical step is getting central IT involved early, because everything else depends on it. The school needs to select a GDPR-compliant, EU-hosted low-code AI platform that central IT can approve and govern within existing policy. Microsoft Copilot Studio is a strong candidate here, partly because many schools already operate within Microsoft 365 tenancies, which removes a significant procurement and security review hurdle, and partly because it provides a low-code workflow builder that a non-technical administrator can manage without developer support. Other options worth evaluating include Make (formerly Integromat) connected to a compliant Azure OpenAI deployment, or a dedicated education-sector AI platform if the school's procurement framework includes one. The key criteria are EU data residency, no training on customer data, and browser-based access that requires no local installation.

Once the platform is approved, the implementation work centres on prompt and workflow design. A prompt template is built for each difficulty level, instructing the AI model to generate questions of a defined type from a pasted or uploaded excerpt of teaching material. The prompt includes explicit constraints: one unambiguous correct answer, no reliance on information outside the provided text, and a specific output format that matches the school's existing question structure. The workflow then routes the AI-generated output through two paths. Standard outputs, which are expected to cover roughly 85 to 90 percent of cases, go directly to a light-touch staff review screen where the responsible teacher confirms or edits the draft before marking it approved. Outputs flagged as exceptions by the AI, or caught by simple rule checks such as missing answer options or ambiguous phrasing, are routed to a separate review queue where a senior staff member applies full human judgement before the question is passed on.

The data flow is straightforward. A teacher submits a section of teaching material through the platform's input interface, which may be a simple web form or a Teams-integrated submission panel depending on the chosen platform. The platform sends the text to the AI model, receives structured question drafts, and writes them to a shared output store, likely a SharePoint list or a structured folder within the school's existing Microsoft 365 environment. No pupil data enters this flow at any point; the inputs are curriculum material only, and the platform's data residency settings ensure that content never leaves the EU-hosted environment. The administrator can monitor the queue, track approval status, and pull a weekly summary of volumes and exception rates without any technical intervention.

Staff training covers three practical skills: how to submit material and specify difficulty level, how to review AI-generated questions critically rather than treating them as final, and how to handle the escalation queue when exceptions arise. A single one-hour session with a one-page reference guide is sufficient for most teaching staff, with the administrator taking a slightly deeper orientation on managing the workflow configuration and monitoring outputs. The whole rollout, from platform approval to all twenty staff using the system on live material, is realistically achievable within thirteen to sixteen weeks, with the GDPR data protection impact assessment running in parallel during the pilot stage rather than as a sequential gate.