Many higher education institutions are moving beyond standalone generative AI experiments towards AI embedded in operational systems and workflows: asking about real applicants, real cohorts and real records, inside the platforms that run admissions, student information, finance and engagement.
At that point, model capability is only part of the equation. The reliability of the AI also depends on what institutional data it can access, how that data is defined and maintained, whether two systems agree on what a value means, and whether the user's permissions are respected. Those are questions of data governance.
That is the argument of this article. Institutions cannot build reliable, useful institutional AI on top of data they do not understand, trust, govern or control. Data governance is therefore not a parallel workstream to AI adoption; it is part of the foundation that makes it possible. In many institutions the AI conversation starts too high in the stack, with tools and use cases, when the limiting factor sits lower down, in the definitions, ownership and permissions attached to the data.
AI is the reason the topic has become urgent. Data governance is the subject.
The development and maintenance of an in-house system is a complex and time-consuming task. Full Fabric lets you turn your full attention to maximizing growth and performance.
Data governance in higher education is the framework of decision rights, ownership, policies, standards and accountability that determines how an institution's data is defined, accessed, maintained, protected and used across its systems and teams. It answers questions such as who owns applicant data, which system holds the authoritative enrolment status, what "active student" means for reporting, who may access sensitive information and why, and how long records are retained. A workable framework covers eight things:
The two terms are often used interchangeably. Governance can exist while management is weak, and management can be sophisticated while governance is absent.
| Data governance | Data management | |
|---|---|---|
| What it is | Decision rights, ownership, policies, standards, accountability and acceptable use | The processes and technologies used to collect, store, integrate, protect, maintain and use data |
| Typical questions | Who owns this? What does it mean? Who may use it, and for what? | How is it stored? How is it synchronised? How is quality monitored? |
| Typical owners | Executive sponsor, data governance lead, data owners, stewards | IT, integration teams, database administrators, analytics engineers |
| Typical artefacts | Policies, data dictionary, ownership register, access rules, retention schedule | Pipelines, warehouses, integrations, validation rules, backups |
| Failure mode when missing | Nobody can say which number is right or who decides | Data exists but is slow, duplicated, stale or unreliable |
A useful shorthand: governance decides, management implements. Neither works for long without the other.
| Discipline | Primary concern | Relationship to data governance |
|---|---|---|
| AI governance | How AI systems are selected, risk-assessed, overseen and monitored | Depends on data governance for the data AI consumes; also covers models, use cases and human oversight |
| Cybersecurity | Protecting systems and data from unauthorised access | Enforces access decisions that governance defines; does not define meaning or ownership |
| Privacy and data protection | Lawful, fair and transparent processing of personal data | Sets legal constraints on purpose, minimisation and retention; governance operationalises them |
| Data architecture | How systems, models and flows are designed | Implements the structure governance requires, including systems of record and integration patterns |
| Data quality | Whether data is fit for its intended use | Governance sets the standard; management measures and remediates |
Collapsing these into one concept tends to leave gaps, usually around semantics (what a field means) and ownership (who may change it), which are the gaps AI exposes first.
Reporting tolerates a surprising amount of ambiguity. An analyst who sees an enrolment figure that looks too high checks the filters. A dean who receives two retention numbers asks which definition each office used. Institutional memory fills the gaps that documentation leaves.
AI systems do not inherently understand an institution's local definitions, policies and reporting conventions. That context has to be supplied through governed data, metadata, system design and appropriate instructions. Institutional data and analytics staff at Rowan University, writing in EDUCAUSE Review in January 2026, described an early prototype that was asked for an enrolment total, summed every academic year and reported 600,000 students: correct arithmetic, meaningless institutionally, because nobody had told the system what the question meant. Their conclusion was that AI does not solve governance so much as expose it (EDUCAUSE Review, 2026).
Three categories of institutional AI make the dependency concrete.
An assistant answering staff questions about applicants, students or operations needs things only governance can supply: which records it may access for the user asking, which system is authoritative when the CRM and the student information system disagree, whether the data is current, what a field means (does "status: withdrawn" refer to an application, a module or a programme?), whether two records describe the same person, and where its answer came from. Without them the assistant is unreliable in a way that is hard to detect, because the output looks fluent either way.
Predictive models and cohort analysis inherit every definitional inconsistency in the underlying data. If "enrolled student" is counted at offer acceptance in one system and at registration in another, a model trained on one and applied to the other learns the wrong thing. If applicant records are incomplete for certain programmes, gaps get mistaken for patterns. Strong data governance removes or reduces an important class of avoidable data-related failures, but it does not guarantee that an AI output will be correct.
Some institutional AI use cases are moving beyond information retrieval towards proposed or controlled actions: updating a record, sending a communication, moving an application to the next stage. The Rowan team describe an "AI to Human Handshake" in which the system prepares the work and a person confirms it. Wherever AI is allowed to act, bad data stops producing bad answers and starts producing operational consequences: a message to the wrong cohort, a workflow triggered by a stale value. Where human approval is required for consequential actions, stronger data governance does not remove that requirement. It reduces the risk that the person is being asked to approve an action based on incorrect, stale or poorly defined data.
The difficulty is not that universities are technologically backward; many run modern cloud platforms, warehouses and integration layers. The difficulty is structural. A typical university holds personal and operational data across a CRM, admissions or application systems, a student information system, an LMS or VLE, finance and payment systems, identity management, marketing automation, careers and alumni platforms, research systems, a warehouse or lake, and a long tail of departmental spreadsheets. These systems are often introduced by different teams, at different times and for different operational needs, and each carries its own model of what a person, a programme and a status are. That produces a recognisable set of governance problems. Not every institution has all of them, but most will recognise several:
EDUCAUSE's 2025 Top 10, which placed the data-empowered institution at number one, noted that data management, integration and governance remain challenges, that data has to be treated as an institutional asset rather than the property of individual stakeholders, and that large, decentralised institutions struggle with this most (EDUCAUSE, 2024). Its 2027 Top 10, published in October 2026, describes a strong and adaptive data governance backbone as a foundation for scaling analytics and AI, and recommends approaches that balance collective commitment with local autonomy (EDUCAUSE, 2026).
That balance is the heart of the problem. Faculties, schools and professional services have legitimate reasons to manage their own data. Governance that ignores that fails through non-adoption; governance that accepts it without shared definitions and authoritative sources fails through fragmentation. The task is to agree the small set of things that must be common and leave the rest local.
Data governance has always had a compliance dimension through data protection law. AI regulation and standards are adding a second layer.
The EU AI Act. Regulation (EU) 2024/1689 lists certain education uses in Annex III as high-risk, including systems intended to determine access or admission, evaluate learning outcomes, assess the level of education a person can receive, or monitor prohibited behaviour during tests. Article 10 sets out data and data governance requirements for high-risk systems, covering the training, validation and testing datasets used to develop them, including their origin, preparation, suitability and examination for possible biases (EUR-Lex, Regulation 2024/1689).
Three points of precision matter. Article 10 obligations fall primarily on providers, the organisations that develop or place high-risk systems on the market; deployers have separate obligations under Article 26, including human oversight and log-keeping. These rules do not apply to every AI tool a university uses, only to systems that meet the high-risk classification, which depends on the specific system, its intended purpose and the institution's legal role. And timelines have moved: the Digital Omnibus on AI, Regulation (EU) 2026/1744, entered into force on 27 July 2026 and deferred stand-alone Annex III high-risk obligations to 2 December 2027 (EUR-Lex, Regulation 2026/1744). None of this is legal advice; institutions should confirm the current position with their data protection officer and legal advisers. The point for this article is that an institution which already knows the provenance, ownership and quality of its data is better placed to work with providers and regulators.
NIST AI Risk Management Framework. The NIST AI RMF 1.0 is a voluntary, cross-sector framework from the United States National Institute of Standards and Technology, not a higher education regulation or a mandatory standard. It structures AI risk management into four functions, Govern, Map, Measure and Manage, and its Generative AI Profile (NIST AI 600-1) names risks that depend directly on data, including confabulation, data privacy and information integrity (NIST, AI RMF; NIST AI 600-1). Its emphasis on documentation, provenance and monitoring applies directly to institutional data programmes.
UNESCO. UNESCO's 2023 guidance on generative AI in education and research argues for a human-centred approach, treats the protection of data privacy as a regulatory priority, and stresses that institutions should validate generative AI systems before relying on them (UNESCO, 2023). This reinforces the need for institutions to retain governance over the purposes for which their data is used.
The nine foundations below form a higher education data governance framework designed to support analytics, automation and AI. They are not sequential; an institution can be strong in some and weak in others.
Every important data domain (applicant, student, programme, finance, engagement, alumni) needs a named owner accountable for its definition, quality and acceptable use, and stewards who maintain it day to day. Ownership varies by institutional structure. In many institutions, student-record accountability may sit with the registrar or registry, applicant data with admissions, and financial data with finance, while IT remains responsible for the systems and technical controls. The principle is explicit functional accountability, not identical titles everywhere.
For each domain, the institution should be able to say which system holds the authoritative value of each important field, and which hold copies. This does not require a single physical database; it requires a documented decision. Enrolment status may be authoritative in the student information system while contact preferences are authoritative in the CRM. What matters is that integrations respect the decision and AI tools are pointed at the authoritative source rather than whichever copy was easiest to connect.
Apparently simple terms become ambiguous across teams. "Enrolled" may be counted at acceptance, deposit, registration or census. "Conversion" may be measured from enquiry, application or offer. The Rowan team found that one ambiguous request for average financial aid led them to separate aid awarded, accepted and disbursed into distinct definitions, which improved every downstream report, not only the AI. A maintained data dictionary recording the agreed definition, valid values, owner and authoritative source of each important field is one of the most useful artefacts a governance programme can produce for AI.
AI that supports the learner lifecycle needs to know that the enquirer from two years ago, the applicant from last spring and the current student are the same person. Duplicate identities are one common reason that context is lost. Institutions need a persistent identifier that survives the transitions from recruitment through to alumni engagement, agreed matching rules for merging duplicates, and a process for ambiguous cases.
Quality should be defined in measurable terms: completeness (are required fields populated), accuracy (do values reflect reality), timeliness (how soon after the event is the record updated), consistency (do systems agree) and validity (are values within the allowed set). EDUCAUSE's 2025 guidance was direct: data leaders should begin by ensuring data is accurate, reliable and relevant to institutional needs. Quality metrics should have named ownership and agreed accountability, and should be monitored routinely against the needs of the use cases that depend on them.
AI should not become a shortcut around existing access controls. If a member of staff cannot open a record in the source system, an assistant acting on their behalf should not be able to summarise it. Inside institutional systems, AI should inherit the user's role and permissions rather than operating through a privileged account that sees everything. Across systems, the institution needs an explicit decision about which data it may access, through what channel and for which purposes. The Rowan team's phrase for the goal, governed access to trusted data, is a good test for any proposed integration.
Student and applicant records contain personal data and may include special category or otherwise sensitive personal data, such as health or disability information, depending on the jurisdiction and what is collected. Governance needs to record the purpose for which each category was collected, apply minimisation so AI tools receive only what a task requires, enforce retention schedules, and flag sensitive fields so they are excluded from AI access by default. Full Fabric's guide to student data privacy and compliance in higher education covers the legal frameworks; the governance task is making those obligations enforceable by systems.
Teams need to trace where a value came from, how it was transformed and when it last changed. For AI, that extends to seeing what data an answer was based on and what steps produced it. Lineage is partly a management capability (logging, versioning, documented transformations) and partly a governance decision: that it is required, and that outputs without provenance are not relied on for consequential decisions.
APIs and connectors do not solve governance automatically. Each integration needs an owner, a documented direction of synchronisation, rules for conflicts when the same field changes in both systems, and monitoring so failures are noticed before they propagate. Governance as a whole works the same way: an operating model with regular review cycles, not a data-cleaning project completed before an AI launch. Definitions, ownership and use cases all change, and the last changes fastest.
AI readiness in higher education does not mean consolidating every piece of university data into one database. Research data, learning content and finance ledgers have good reasons to live where they live. It means the data AI will use has a coherent set of characteristics, wherever it sits:
The requirement is coherent ownership, semantics, access and connectivity. An institution can meet it with a connected operational platform for the student lifecycle, a well-governed warehouse, a semantic layer over existing systems, or a combination. It cannot meet it by accident.
Data governance cannot realistically belong only to IT. IT can build the systems and enforce the controls, but it cannot decide what "enrolled" means, which programme owns a shared module, or whether marketing may use enquiry data for predictive segmentation. Titles vary by institution, and smaller institutions will combine several of the roles below in one person, but each responsibility needs a home.
| Role | Responsibility in data governance |
|---|---|
| Executive sponsor (provost, COO, registrar or equivalent) | Sets the mandate, resolves cross-functional disputes, makes decisions binding |
| CIO and IT leadership | Owns systems, integration and security architecture; implements governance technically |
| Data governance lead (institutional research, IT or a data office) | Runs the operating model, maintains the data dictionary and ownership register |
| Data owners (registrar, admissions director, finance director, alumni lead) | Accountable for definitions, quality and acceptable use in their domain |
| Data stewards (senior functional staff) | Maintain data day to day, resolve quality issues, document local practice |
| Security | Enforces access controls, monitors unauthorised access, assesses integration risk |
| Privacy and data protection officer | Advises on lawful basis, purpose limitation, retention, impact assessments and data subject rights |
| Institutional research and analytics | Defines reporting standards, validates metrics, tests governed data against intended analysis |
| Functional teams (admissions, student services, marketing, faculties) | Apply definitions in practice, raise issues, shape use case design |
Accountability matters more than the exact structure: every important domain has a named owner outside IT, and a forum exists where owners, IT, security and privacy decide together. Full Fabric's piece on the SIS as a north star for higher education leaders covers the related question of where the student record should sit institutionally.
The sequence below does not require a multi-year enterprise data transformation before any value from AI is realised. The intention is to govern the data specific AI use cases need, learn from that, and expand.
The last step matters because governance that stops after the first pilot becomes a one-off project. Definitions, ownership, permissions and integrations need continued review as systems and use cases change.
Not every institution needs to pause AI work until governance is complete. Some signs do suggest scaling should wait:
None of these is catastrophic alone. Several together increase the risk that AI will amplify existing data problems rather than deliver its intended value. In that situation, strengthening governance may be more valuable than scaling additional AI use cases.
The arguments above apply whatever systems an institution runs. Full Fabric is relevant to a specific part of the problem.
Full Fabric is a unified higher education platform built around one connected record per person across the student lifecycle, with CRM, applications, admissions, enrolment and the student information system operating on the same underlying data model. For the student lifecycle domain, this can reduce several of the governance problems described above: duplicate identities across recruitment and records, inconsistent lifecycle definitions between CRM and SIS, and undocumented transformations between them.
Full Fabric's contextual AI, delivered through the AI Console, operates against the same platform data, permissions and workflows staff already use. It is designed to respect the user's existing role and access permissions, its steps can be visible in the conversation, and administrators can review AI Console activity through audit logs. AI features are disabled by default, access can be restricted by role, and access to personal data can be limited or excluded. The AI Console falls within the scope of Full Fabric's ISO/IEC 27001:2022 certification, and the AI model providers operate under Zero Data Retention terms, as described on the security and compliance page.
On the wider estate, Full Fabric's integrations and API support configurable field mappings, synchronisation direction and frequency where supported, and an institution can retain another enterprise CRM as an authoritative system while using Full Fabric for higher-education-specific lifecycle workflows. The platform's GDPR features, including data subject access request handling, consent tracking, retention controls and audit trails, support the privacy foundations, though compliance depends on how the institution configures and uses the platform.
The limits matter as much as the capabilities. Full Fabric does not replace institution-wide data governance. It is not an enterprise master data management platform, a data warehouse or a data catalogue, and it does not govern research, finance or learning systems across the wider estate. A unified platform reduces integration complexity within the student lifecycle; it does not remove the need for integrations elsewhere, and it does not make AI trustworthy simply because data is held in one place. Institutions remain responsible for definitions, ownership, acceptable use, lawful processing and human oversight of any AI output that affects an individual. What a connected operational platform can do is keep key student lifecycle information inside one coherent data model, apply common identity, permissions and workflow context, and give AI a governed foundation in that domain. For IT and data teams, that is a meaningful reduction in scope rather than a complete answer.
Data governance in higher education is the framework of decision rights, ownership, standards, access rules, quality expectations and accountability that governs how a university's data is defined, maintained, protected and used. It determines which system is authoritative for each domain, what key terms mean, who may access what, and for which purposes data may be used, including analytics and AI.
AI systems do not inherently understand an institution's definitions, policies or reporting conventions. Every gap in definition, ownership, quality or permissions can become an error in an output or an action with real consequences. Governance supplies the missing context: authoritative sources, agreed definitions, resolved identities, enforced permissions and provenance. It does not guarantee correct outputs, but it removes a large class of avoidable failures.
Data governance defines decision rights, ownership, policies, standards, accountability and acceptable use. Data management implements the processes and technologies that collect, store, integrate, protect and maintain the data. Governance decides what "enrolled" means and who owns the student record; management builds the integrations and validation rules that make the data reliable. Each depends on the other.
Responsibility is shared. An executive sponsor provides the mandate; data owners in functional areas are accountable for definitions, quality and acceptable use; stewards maintain data day to day; IT owns systems and technical enforcement; security and the data protection officer advise on access and lawful processing. Titles vary, but governance that sits only in IT tends to fail because the key decisions are institutional rather than technical.
AI-ready data has stable identity across the learner lifecycle, documented lifecycle states, designated authoritative fields, explicitly modelled relationships, permissions that machines can apply, traceable changes, owned integrations, machine-readable structure and historical context where relevant and lawful. The requirement is coherent ownership, semantics, access and connectivity, not consolidation of all institutional data into one place.
A university needs a documented source of truth for each important domain and field, not a single database holding everything. Enrolment status may be authoritative in the student information system while engagement history is authoritative in the CRM. What matters is that the decision is explicit, integrations respect it, and AI tools connect to the authoritative source rather than a convenient copy.
Start with the data that specific, high-value use cases need rather than the whole estate. Inventory systems, assign owners, agree definitions for the most contested terms, measure quality against them, map access and sensitive data, resolve duplicates and conflicting integrations, and only then pilot AI against governed data. Treat wrong AI answers as governance findings.
Data governance governs the data: what it means, who owns it, who may use it and how good it is. AI governance governs the systems that use it: permitted use cases, risk assessment, human oversight, monitoring and incident handling. AI governance depends on data governance, but it also covers model selection and vendor due diligence. Institutions need both, with clear ownership for each.
Article 10 of the EU AI Act sets data and data governance requirements for high-risk AI systems, and Annex III classifies certain education uses as high-risk, including systems used to determine access or admission or to evaluate learning outcomes. Article 10 obligations fall primarily on providers; deployers have separate obligations under Article 26. Stand-alone Annex III high-risk obligations are now scheduled to apply from 2 December 2027. Whether a deployment is in scope depends on the specific system and use case. This is not legal advice; institutions should consult their data protection officer and legal advisers.
