Centralise the rules, decentralise the decisions, and prove both. Colleges and professors innovate inside shared guardrails, and every decision that scales carries its evidence.
Universities are told to transform digitally, but they swing between two failures: central control that is slow, and local freedom that fragments.
Every tool waits for a committee. Faculty route around it with personal accounts and unapproved AI.
Each department buys its own systems. Data cannot be joined, and central purchases go unused.
Decisions are rarely evaluated. Nobody can say which change improved learning, or show who decided it.
UAE and international rules now expect human oversight, transparency and accountability for AI in education.
The literature recommends central standards with local execution, but gives no working mechanism for it. Six gaps follow.
| Gap | What the literature shows | PolicyOps response |
|---|---|---|
| G1 | Digital transformation in universities is studied in fragments; none of the proposals reviewed is holistic. [1] | One framework across teaching, assessment, quality, campus and AI |
| G2 | University IT governance is at an early maturity stage; formal committees are often seen as ineffective. Authors recommend central standards with decentralised execution. [2] | A federation council plus guardrails written as checkable rules |
| G3 | In decentralised universities, central integration rules clash with local choices; existing frameworks support vertical, not horizontal, coordination. [3] | Shared catalogue where colleges classify systems as essential or optional |
| G4 | Few universities measure the effect of IT investment on teaching and learning. [2] | A causal check after every decision that scales |
| G5 | Decision records are internal and editable; outsiders cannot verify who decided what, on which evidence. | Tamper-evident decision log, verifiable like certificate transparency [9] |
| G6 | AI rules require human oversight, transparency and accountability; the EU treats AI that evaluates students as high-risk. [10] [12] | AI register, red lines, and an ethics board seat in the federation |
Theory base: IT governance archetypes and decision rights [4], polycentric governance [5], and federated computational governance from data mesh [6]. A full systematic review is validation stage V0.
Three tiers set and use the rules. One evidence spine runs beside them and turns local results into shared knowledge.
| Tier | Who | Decides | Never decides |
|---|---|---|---|
| T1 | Board, president's office, CIO, data protection officer | Principles, standards, security, the shared platform, budget envelopes | Which tool a professor uses in class |
| T2 | College deans, IT, quality office, legal, ethics, a student representative | Shared rules, the system catalogue, AI register entries, scaling a pilot | Rules that break a T1 guardrail |
| T3 | Colleges, programmes, professors | Tools, pilots and teaching designs within the rules | Anything that moves personal data outside the platform |
| Sector | A network of universities, under the ministry's framework | Shared standards and joint learning between institutions | Any single university's internal choices |
Each decision type sits where it belongs on the central–local spectrum. Weill's decision domains, adapted to teaching and AI.
| Decision | Centre | Federation | Unit |
|---|---|---|---|
| Digital principles and red lines | decides | advises | follows |
| Identity, security, data standards | decides | advises | follows |
| Shared platform (LMS, student system, data store) | decides | agrees | uses |
| System catalogue: essential or optional | informed | decides | votes |
| AI tool that evaluates students | sets limits | decides | proposes |
| Scaling a successful pilot | funds | decides | proposes |
| Teaching tools for one course | informed | informed | decides |
| Local pilot with no personal data | — | informed | decides |
"Informed" means the decision appears in the shared log; no approval is needed. This replaces most committee approvals with a guardrail check.
Eight steps for every decision. Machines check rules and measure effects; only people decide.
| Step | What happens | Tool or method |
|---|---|---|
| Check | The proposal is tested against the guardrails automatically, before any meeting | Rules written as code [6] |
| Measure | The same indicators are taken before and after, plus a comparison group where possible | Course, CLO and service data on the shared platform |
| Causal check | Estimates the effect and its uncertainty, and tests whether the result survives a refutation test | DoWhy [8] |
| Record | Decision, evidence and decider are hashed into an append-only log anyone can audit | Transparency log [9], optional public timestamp |
| Scale | The federation scales what worked; models learn across universities without moving student data | Federated learning [7] |
Try it: describe a decision and see which tier decides, which checks apply, and what goes into the log.
An illustration of the rules on this page, not a policy engine. The log line is a real SHA-256 hash of the decision record.
Five red lines hold at every tier. A unit's freedom ends where one of them begins.
No AI makes a final decision on admission, grades, progression or discipline. A person decides and signs.
No student or staff surveillance: no emotion, location or biometric tracking for teaching decisions.
No accommodation, disability or health data in shared datasets or models.
No unregistered AI tool used on students. Every tool sits in the AI register.
No decision that scales without a record of its evidence and decider.
| Duty | How PolicyOps meets it |
|---|---|
| Human oversight, accountability, transparency (UAE AI Charter) [10] | People-only decide step; signed decision log; public AI register |
| Personal data protection (UAE PDPL) [11] | Impact assessment before any data decision; federated learning keeps data in place |
| AI that evaluates learning is high-risk (EU AI Act, for partners abroad) [12] | Federation decides; ethics board review; risk record kept with the tool |
| Outcome-based accreditation (MoHESR OBEF) [14] | Causal checks produce outcome evidence the quality office can submit |
PolicyOps is the governance pillar of a smart campus. It stands on its own and works with the other pillars through the shared log.
| Works with | What PolicyOps gives it | What it gives PolicyOps |
|---|---|---|
| Veritwin (student twin) | Decision rights and red lines for every new data source | Cohort evidence for programme decisions, with consent |
| Fair assessment providers | Approval route for any AI that marks students | Signed, recomputable results to audit |
| ProfStack | Guardrails professors can see before they choose a tool | Pilot results from real courses |
Five phases, each opened by a gate. The first pilot is one college, not the whole university.
Design Science Research: build the framework as an artefact, then evaluate it in stages inside real universities [13].
| DSR activity (Peffers et al., 2007) | In PolicyOps |
|---|---|
| Identify the problem | Systematic review of digital transformation and IT governance in higher education |
| Define objectives | Gaps G1–G6 turned into design requirements |
| Design and develop | Tiers, decision rights, loop, guardrails, red lines, log |
| Demonstrate | Replay of past decisions, then one college pilot |
| Evaluate | Validation stages V0–V5, mixed methods |
| Communicate | Open specification, papers, evidence for accreditation |
Six stages, from the idea to a second university. Each must pass before the next phase opens.
| Stage | Question | Method | Evidence that it passed |
|---|---|---|---|
| V0 | Are the gaps real? | Registered systematic review (PRISMA) | G1–G6 confirmed or revised |
| V1 | Is the design sound? | Delphi rounds with CIOs, deans, quality and legal experts | Agreement on the decision-rights matrix, recorded changes |
| V2 | Do the mechanics work? | Replay last year's decisions through the guardrail checks and the log | Every past decision routed; log verifies end to end |
| V3 | Does it work in one college? | One-year pilot: decision time, conflicts, staff and student survey | Faster decisions with no red line crossed |
| V4 | Does it improve outcomes? | Causal checks on scaled decisions, with comparison groups | Effect estimates with uncertainty, reported openly |
| V5 | Does it transfer? | Second GCC university joins; federated analysis | Same protocol, comparable results, no raw data moved |
Every component already exists as open source. What is new is how they are joined and governed.
| Function | Open-source component | Role |
|---|---|---|
| Guardrails as code | Open Policy Agent | Checks each proposal against the centre's rules |
| Decision log | Trillian (transparency log) | Append-only, verifiable record of decisions |
| Causal checks | DoWhy | Effect estimates with refutation tests |
| Federated learning | Flower | Models trained across universities, data kept local |
| Dashboards | Apache Superset | What each tier sees: decisions, effects, red-line alerts |
Smallest real prototype: guardrail checks plus the decision log for one college's AI tools, for one semester.
A tested mechanism for "central standards, local execution" in universities, with decision rights, evidence and AI duties in one model.
Faster, safer digital decisions: professors innovate without waiting, leaders see everything without approving everything.
A shared, open standard universities can adopt together, aligned with UAE AI and data rules and outcome-based accreditation.