.png)
Over the past couple of years, I have worked with education and edtech clients across the UK, Europe and the US. In that time, I have seen the AI conversation in education become louder, but not always clearer. It often comes back to two questions: are students using AI to cheat, and are institutions using it legally?
Both questions matter. But they are not the whole story. In the projects I have worked on, the more important question is usually less visible: can an institution bring together its students, courses, content and outcomes into one reliable view? Or is that picture still scattered across platforms that were never designed to work as one?
That question is becoming urgent because AI is no longer sitting at the edge of education. It is already part of how students study, how institutions think about assessment, and how vendors design digital learning products. The Higher Education Policy Institute’s 2025 student survey found that 92% of UK undergraduates now use AI tools in some form, and 88% have used generative AI for assessments. This is the operating environment universities, colleges and edtech providers are already designing around.
Why the data layer matters more than the chatbot
What I have seen in practice is that the teams making real progress are not treating AI as a feature layer alone. They are looking underneath the interface and asking whether the data foundation is strong enough to support personalisation, automation, accountability and governance. That may sound less exciting than launching a chatbot, but it is usually where the long-term value is created.
Education data is rarely tidy at the start. Student records may sit in one system, learning activity in another, assessment submissions in a separate tool, and feedback somewhere else again. Course catalogues, timetables, content libraries and support interactions often have their own structures and identifiers. Each system works for its original purpose, but AI needs context across the whole learning journey.
That is why connected data is not just a technical preference. It affects the quality of the learning experience, the confidence staff have in the system, and the ability of an institution to explain how decisions or recommendations were made. Without that foundation, AI may still produce polished outputs, but those outputs can be based on incomplete, stale or poorly joined information.
What assessment redesign changes in practice
The UK discussion around generative AI in higher education has moved steadily away from simple detection and towards assessment redesign. That shift is important because it accepts the reality that students already have access to these tools. The business question for institutions is how to protect academic standards, student trust and operational confidence without building processes that are impossible to sustain.
In practice, assessment redesign quickly becomes a data challenge. If an institution wants to understand how a student learns over time, it cannot look only at the final submitted document. It needs to understand prior performance, engagement patterns, feedback loops, draft activity, assessment type, course context and support history. These signals are usually spread across several systems, which makes joined-up decision-making harder than it looks.
One project I worked on showed this clearly. The client was a large university built around online delivery. The goal was to support more personalised learning and assessment, but the work had a wider business purpose too: improving learner support, making staff time more effective, and helping the institution understand progression earlier rather than only reacting after a problem had become visible.
My role was to help shape the technical direction around the data foundation. We used an AWS-native architecture with Snowflake as the central warehouse, bringing together transcript-transfer data from external institutions, degree-progress tracking, course and class scheduling, and event-level LMS data such as quiz attempts, submissions, instructor feedback and grading history. The hard work was not glamorous. It was identity resolution, course-code mapping, data quality checks and agreeing what different systems meant by basic concepts such as enrolment status or progression.
Once that foundation existed, the AI capability became much easier to design. The service could analyse a student’s historical performance, areas of weakness and instructor feedback, then generate a personalised quiz or formative assessment. We kept the workflow human-in-the-loop because the aim was not to remove instructors from the process. It was to give them better signals, reduce repetitive work and make support more timely.
The lesson was simple but important: personalisation only works when the system has a reliable picture of the learner. If the data model is weak, the AI may still sound confident, but it will personalise against the wrong context. For education leaders, that creates a real risk: a system that feels tailored, but is actually working from a partial view of the student.
Why AI governance has to sit on top of the data foundation
The EU AI Act is also changing how edtech vendors and EU-facing institutions think about AI architecture. In education, AI systems used for admissions, evaluating learning outcomes, assessing a learner’s level, or monitoring behaviour during tests can fall into the high-risk category. For me, the practical implication is that governance cannot sit in a separate document. It has to be reflected in how the system is designed, logged, reviewed and operated.
This is often described as a legal or compliance challenge. From what I have seen, it is just as much a data and engineering challenge. You cannot produce meaningful audit logs if systems do not have consistent identifiers. You cannot provide useful human oversight if reviewers only see part of the evidence. You cannot explain an automated recommendation if the data feeding it is inconsistent, untraceable or governed differently across platforms.
A second project made this point from a different angle. The client was a UK-headquartered global education publisher building AI-enabled tutoring, personalised study paths and AI-assisted content generation for a large base of learners and instructors. The business outcomes were clear: improve the learner experience, support content teams, protect intellectual property and reduce the risk of unsafe or inconsistent AI outputs. The architecture had to support all of that, not just the demo experience.
Here, governance could not be treated as a policy document written at the end. It had to be designed into the platform. IP-aware controls were needed so that large language models could use the publisher’s content assets appropriately without leaking or reproducing protected material in unsafe ways. Access control, logging and content-usage tracking had to work consistently across the cloud environments. A unified AI profile was also needed so that students, instructors and content creators were not each served by disconnected AI features with different rules.
The practical lesson was that AI governance is not something that can be bolted on after the product is live. It depends on the data and platform choices made much earlier: what is captured, how it is classified, who can access it, how prompts and outputs are logged, where human review sits, and how exceptions are handled. If those design decisions are fragmented, the governance model will be fragmented too.
What this means for UK and European edtech teams
For universities, colleges and edtech providers, the practical starting point is not usually a new model. It is an honest inventory of the data estate. Which systems hold learner records, activity, content, assessment outcomes and support interactions? Where are the duplicate identifiers? Which data is reliable enough to drive a recommendation? Which signals are useful for personalisation, and which should never be used because they create unfairness or privacy risk?
The next step is to design governance into the same architecture, not as a separate workstream. That means defining human oversight points, logging requirements, model and data change controls, escalation routes, consent and transparency processes, and criteria for when a use case should not proceed. It also means being honest that some AI ideas will look good in a demo but fail in production because the data foundation is not ready, the workflow does not fit staff practice, or the risk is not worth the benefit.
This is where the conversation needs to become more practical. AI in education will not be made trustworthy by policy statements alone, and it will not scale responsibly through isolated pilots. It needs connected data, clear accountability and architecture that makes oversight possible. The unglamorous work is the work that matters: resolving identities, improving data quality, joining learning signals, setting access rules, and making sure people can understand, monitor and challenge what the system is doing.
The real foundation for AI in education
If there is one lesson I take from these projects, it is this: AI in education does not scale on model quality alone. It scales when institutions first build a connected, governable data foundation that represents learners, content and learning activity accurately. Once that is in place, personalisation becomes more useful, compliance becomes less reactive, and AI features are more likely to earn trust from students, instructors and institutions.
That is the shift I see across UK and European edtech. The strongest organisations will not necessarily be the ones with the most visible AI interface. They will be the ones that understand the stack beneath it: data clean enough to personalise, governance strong enough to control risk, and design practical enough to fit how education actually works.
