The governance gap in AI-assisted learning

Introduction

At 7:45 a.m. on a Tuesday, a registrar emails a dean. A freshman composition section has a rubric that no longer matches the work. Submissions look fluent, but the voice is flat and citations don't map to the arguments. The learning management system shows a third‑party writing assistant was enabled in the course shell one week earlier. A similar alert fires in advising: the triage bot is proposing identical course plans for different majors. None of this is hypothetical. It’s happening now on campuses and in districts that never announced an “AI launch.”

This is how categories form: experimentation at the edge → rapid fragmentation → pressure for standards → consolidation. I watched this cycle once before in the early days of online learning. In the late 90s, the operational reality was a lab PC, a crossover cable, and a professor trying to put a syllabus on the web. Three years later, the team at Blackboard was fielding campus-wide requests for content standards, gradebook integrations, and identity management. Our extension framework — Building Blocks, introduced around 2000 — was less a feature than a governance instrument. It named interfaces, documented boundaries, and gave institutions a way to say “this is allowed” without stalling innovation. It wasn’t glamorous, but it scaled. It made change additive, not destructive.

AI‑assisted learning is in that same formation arc, but with a bigger blast radius. Student work, advising notes, video proctoring, clickstream telemetry, and vendor models all sit on the same page. The unit of change isn't a tool; it's a decision about what data moves where, with whose agency, under what policy, and with what feedback loop.

Plain statement: the gap is governance, not imagination.

Here, I map where the real governance gaps sit in AI‑assisted learning and lay out what boards and CIOs can do this year without freezing instruction. The cadence is practical: condition → operational consequence → system implication → institutional significance. The metaphor is construction scaffolding — the temporary structure you erect so people can work at height without falling. That’s what good governance is at this stage: a provisional frame that lets work proceed safely while the building takes shape.

The five fault lines

Governance isn't a position paper. It's a set of repeatable behaviors encoded in people, contracts, and systems. On campuses, I’ve seen five predictable fault lines open as AI‑assisted learning moves from pilots to production. Each starts with a concrete operational condition and ends with an institutional choice.

Data boundaries and consent

Condition. Student artifacts are no longer local. A draft essay, an advising note, or an accommodation plan now transits through third‑party models to provide feedback, summarize, or route next steps. A writing assistant inside an LMS plugin may ship a paragraph to a vendor endpoint. An advising chatbot may persist a summary on a cloud service the institution did not contract directly.

Operational consequence. Without a named data classification and consent regime, people act on defaults. This means student content gets treated as product data and sensitive categories — disability notes, PII — get co‑mingled with low‑risk data. Once these flows harden in practice, reversing them is politically and technically expensive.

Lesson — Name your data classes before third parties do it for you.

Without a clear data classification regime, student work gets treated as product data by default. You must declare data classes—like Student Content, Student Record, and Faculty Work—and attach rules for where each can be processed, retained, or used for model training. This is how you reclaim control from vendors and define what your institution can responsibly study, improve, and defend.

System implication. You must declare data classes, attach default consent rules, and route flows accordingly. At minimum: Student Content (work product, submissions); Student Record (directory and protected data); Faculty Work (prompts, rubrics, feedback); and Operational Telemetry (clickstream, usage metrics). Attach rules to each class: where it may be processed, if it may be retained, if it may be used for vendor model training, and who can opt in or out.

Institutional significance. This is not theoretical privacy hygiene. It determines what your institution can responsibly study, improve, and defend. If you don't name and route the data, the vendor will.

> Hammer: If the data class isn’t named, it will leak.

Authorship, identity, and assessment

Condition. In composition, design, and problem-solving courses, students use assistants for brainstorming, outlining, and surface edits. Faculty sense a shift but can't verify agency or reward good process. Some sections post a blanket ban; others operate as “assumed but unstated.” The result is ambiguity.

Operational consequence. Assessment design collapses when intent is unobservable. Grades drift toward product quality, detached from method. Students who work ethically — using AI to plan but not fabricate — cannot demonstrate that discipline. Students who outsource wholesale hide in the noise.

Lesson — Assess the student's work process, not just the final product.

The fix starts with making the student's process visible rather than trying to perfectly detect AI use. Adjust rubrics to reward planning artifacts, drafts, critique, and revision history. Ask students for submission metadata, such as what AI tools they used and for what steps, to create a system of structured disclosure that values observable work.

System implication. The fix starts with visible, low‑friction provenance. Ask for submission metadata in the LMS workflow: “What AI tools did you use? For what steps? Provide any machine‑generated text as an appendix.” Provide an AI citation scaffold — a short form students can adopt. Adjust rubrics to reward process: planning artifacts, drafts, critique, and revision. You don't need perfect detection to locate agency. You need structured disclosure and assessments that value observable work.

Institutional significance. Institutions that teach and assess process will graduate students who can work with AI as a partner, not a crutch. That is a labor‑market advantage and a quality signal to accreditors.

Hammer: You can’t grade intent you can’t see.

Model drift and vendor control

Condition. Many campus tools “have AI,” which means they call a third-party model behind the scenes. A vendor can switch models overnight for cost or quality reasons. The institution experiences changed behavior without notice. The same prompt now yields different feedback. Rubrics trained on prior behavior no longer match outcomes.

Operational consequence. If the tool supports grading or advising, silent drift is a governance failure. Appeals grow. Faculty trust erodes. Auditors ask what model produced which decision. No one can answer.

System implication. Require a model bill of materials (BOM) for any tool that processes student content or produces evaluative feedback. The BOM must name the model family and version, the inference endpoint, known safety filters, any fine‑tuning, and the vendor’s change policy. Insist on change notices with effective dates, a test environment, and the ability to roll back or pin a version for a grading period. Log which model handled which request. This is ordinary discipline for regulated systems; apply it here.

Institutional significance. Model transparency is table stakes for any defensible use of AI in instruction. It's also the only way to support research on efficacy and bias over time.

Hammer: No graded use without a model change log.

Policy encoded in systems

Condition. Institutions have drafted AI use policies, but they live as PDFs on a website. Faculty and students encounter rules only after choosing a tool or a workflow. The policy exists, but the system doesn't express it.

Operational consequence. Rules that aren't present at the decision point don't govern behavior. People default to convenience. Over‑the‑counter tools proliferate. The policy becomes a compliance afterthought, not an instructional guide.

Lesson — Build policy directly into the tools and workflows your campus already uses.

Policies that live only in PDFs do not govern behavior. Translate rules into the systems people use every day, like your learning management system. Use course templates with pre-filled AI usage statements and assignment types that signal the expected role of AI. This guides both faculty and students toward compliant choices by making them the path of least resistance.

> System implication. Translate policy into configuration, templates, and UI. In the LMS: use course templates with AI usage statements and metadata fields. Use assignment types that flag the expected role of AI (prohibited, limited, cited, required) and route submissions to the right rubric. In advising: use prompts that include consent language. Use summary templates that separate student voice, advisor voice, and machine summary.

Institutional significance. When policy is encoded in systems, you reduce friction for compliant behavior and make exceptions visible. That makes governance additive, not punitive.

Hammer: If the rule isn’t in the workflow, it isn’t real.

Equity, access, and cost

Condition. AI features appear first in premium tiers, English‑first interfaces, and on modern devices. Writing assistance is bundled only in top‑tier LMS licenses. Advising bots meter usage by the token. On‑device features require hardware many students don't own.

Operational consequence. Without explicit choices, equity becomes an accident. Students with means buy extra tools; students without wait for lab access. Language learners face more friction. Faculty fragment their practices based on who can pay, not on what works.

System implication. Treat equity as a design input. Choose institution‑wide licensing where it affects assessment. Provide on‑campus access points with privacy. Favor tools that support multilingual prompts and outputs. Budget time with disability services to co‑design patterns that meet accommodation needs without forcing parallel tracks.

Institutional significance. Equity decisions in AI‑assisted learning are architecture, not a scholarship fund. Make them early and visibly.

Hammer: Equity is a configuration choice, not a press release.

A 12 month board plan

Boards and CIOs can set direction without freezing instruction. The key is sequencing decisions around evidence. A one‑year plan maps cleanly to governance calendars. The objective is to build a discipline, not chase a feature.

Plain statement: Make the work boring and repeatable.

Lesson — Start with a small, cross-functional inventory of AI usage before launching new initiatives.

The first step is to establish a review loop with leaders from IT, academics, student affairs, and risk management. This group should inventory all active and proposed AI uses across campus, tagging them with data classifications. This allows you to freeze new high-risk deployments while permitting low-risk experimentation to continue safely in sandboxed environments.

0–90 days: inventory and guardrails

• Establish a cross‑functional review loop chaired by the CIO and provost designee, with faculty assessment, disability services, IRB, risk, and student affairs represented. Publish its scope and cadence.
• Inventory active and proposed uses of AI‑assisted learning across instruction, advising, admissions, and student life. Tag each use with the four data classes named earlier.
• Freeze net‑new high‑risk deployments (grading, advising, proctoring) pending model transparency and audit logs. Allow low‑risk experimentation in sandboxed courses.
• Issue interim guidance for faculty: standardized AI usage statements, a one‑page student disclosure form, and rubric language to reward process.
• Ask existing vendors for model BOMs and change policies. If a vendor can't provide them, limit their use to non‑evaluative contexts while you test alternatives.

90–180 days: guided pilots and routing

• Launch 3–5 guided pilots in courses representing different assessment types (writing, problem solving, design) with faculty who opt in. Co‑design assignments with visible AI roles and provenance capture.
• Stand up a routing “switch” that enforces data boundaries: which classes of data may be processed by which models, with logging and opt‑out options. Use this for pilots, even if it’s manual at first.
• Publish the model BOMs for all pilot tools and set effective dates for any changes during the term. Provide a test environment for faculty to compare behavior.
• Begin advising pilots with explicit consent language and summary templates that separate sources (student, advisor, machine). Prohibit auto‑writing of official records.
• Establish a one‑page monthly report to the board’s academic and risk committees summarizing pilots, metrics, and incidents.

180–270 days: encode policy and scale

• Convert interim guidance into encoded policy: course templates with AI statements, assignment types with expected AI roles, LMS submission metadata fields, and routing rules embedded in the switch.
• Expand pilots based on evidence: which patterns supported learning outcomes, which produced confusion or equity gaps. Publish a short “what works” note to faculty with examples.
• Negotiate procurement clauses for any tool scaling beyond pilots, including model transparency, change notices, audit rights, and equitable pricing.
• Train advisors and writing center staff on citation scaffolds and consent patterns. Align support services with the new templates so students hear one message.

270–360 days: institutionalize and audit

• Move from pilots to institutional services where the reference architecture is in place (see next section). Set a quarterly audit cadence on data flows, model changes, and outcome signals.
• Publish a governance calendar for the next year: policy review dates, vendor audit windows, and planned expansion areas.
• Refresh the board’s one‑page report with trend lines: incidents, learning impact signals, and operational risks.

The goal is not to slow change. It is to give change a spine.

The reference architecture to build

A minimal, reusable architecture for AI‑assisted learning has four parts. We learned this discipline at Blackboard: you must allow local innovation without breaking the gradebook or identity store. The same logic applies here. Think of it as scaffolding you erect early and move as the building grows.

Plain statement: One small stack, many safe uses.

The ledger: data classes and consent

• A simple registry that names data classes (Student Content, Student Record, Faculty Work, Operational Telemetry), attaches default consent rules, and records overrides.
• A UI surface — even a form — where faculty declare the expected role of AI for an assignment and what will be logged.
• A student disclosure and consent path that is visible, brief, and revisable.
• A log that records which class of data moved to which model, when, and under which consent basis. This is more important than a universal detector.

The switch: routing and blocks

• A policy engine that routes requests based on the ledger: e.g., Student Content from ENG101 may be processed by Model X for drafting feedback, but not stored beyond 30 days. Student Record data may not leave the system of record.
• Model‑level allow/deny lists, with the ability to pin versions for a term.
• Safety filters that can be tuned and tested in a sandbox before production.
• A visible error pattern that teaches, not just blocks (e.g., “This assignment is ‘limited assistance.’ You can ask for brainstorming but not rewrites. Here’s the citation form.”)

The sandbox: real pilots, safe by design

• Course shells and advising flows set up for experimentation with clear expectations, extra logging, and alternative assessments if needed.
• A faculty and staff cohort trained to run comparative assignments (AI‑assisted vs. not) with common rubrics and reflection prompts.
• A small research support function to help analyze outcomes quickly and share back patterns.

The review loop: audit and outcomes

• A monthly triage that reviews incidents (privacy, bias, harm), change notices, and pilot results. This loop proposes configuration changes.
• A quarterly review that rolls up to board committees: one page with three lines — safety/privacy incidents, learning signals by course type, and operational risk.
• A standing path to pause or roll back a model or feature for a term if drift or harm is observed.

Early scaffolding isn't glamorous work. It's what lets you build higher, safely.

Measurement that boards can read

THE ONLY MEASUREMENTS THAT MATTER ARE SIMPLE, COMPARABLE, AND TIED TO DECISIONS. A board cannot act on a scatterplot. It can act on a trend line and a threshold.

Plain statement: Measure a little, the same way, every month.

Safety and privacy

• Count and classify incidents by severity: privacy exposure, inappropriate content, biased outputs with harm, and model misbehavior. Show the monthly count and time to mitigation.
• Map each incident to a data class and a model. Use this to improve routing rules and vendor expectations. Publish anonymized summaries to build trust.

Learning impact

• Focus on course types, not courses: composition, problem solving, design, and lab skills. For each, track 2–3 signals co‑designed with faculty: rubric dimensions that changed, revision depth, student self‑report on process, and persistence/withdrawal.
• In pilots, compare sections with and without AI assistance on the same assignment pattern. Do not over‑interpret. Look for directional signals and teachable patterns.

Operational risk

• Track vendor and model drift: how many change notices, which models, and what effects were observed. Maintain a simple table the board can scan.
• Track support load: faculty and student tickets tied to AI features, and average time to resolution.

A one‑page monthly rollup keeps leadership focused on governance as a practice, not an event.

Procurement that holds the line

> Contracts are governance. They translate institutional choices into vendor behavior.

The clauses that matter in AI‑assisted learning are specific and testable.

Plain statement: No black boxes on student data.

Lesson — Write your governance rules into vendor contracts to enforce transparency and data rights.

Your contracts must demand a model bill of materials that names the model family, version, and any fine-tuning. Require change notices with a test environment and the option to roll back or pin a version for a grading period. Critically, prohibit the use of student work for vendor training without explicit, institution-level consent that can be revoked.

Model transparency and change control

• Require a model bill of materials that names the foundation model family and version, any fine‑tuning, safety filters, the inference endpoint, and the policy.
• Require change notices with effective dates, test access, and a rollback or pinning option for a grading period.
• Require per‑request logging to support audits: which model, which call, with time and context class, stored for at least a term.

Data use and rights

• Prohibit use of Student Content and Student Record classes for vendor training unless explicitly and revocably consented to at the institutional level.
• Permit bounded use of de‑identified Operational Telemetry to improve product stability, with retention limits.
• Require deletion and export rights aligned to your retention schedule and local law.

Equity and pricing

• Insist on institution‑wide pricing or equitable access plans for features affecting assessment. Avoid paywall‑driven inequities.
• Favor vendors with multilingual support, low‑bandwidth modes, and accessible design as first‑class features.

Audit and recourse

• Reserve the right to audit model behavior and to commission third‑party red‑teaming for high‑stakes features.
• Require indemnification for IP infringement from generated outputs and for privacy violations from vendor misconfiguration.

Procurement sets the outer boundary of safe practice. Your internal architecture sets how you live inside it.

The bet I’d make this year

I learned this with the first generation of learning platforms. The innovation was not simply that instructors could post a syllabus; it was that they could do it without breaking the rest of the campus. The connective tissue — directories, grades, content rights — mattered more than any one feature. That same logic applies to AI‑assisted learning now.

I would make a small, explicit bet: build the scaffolding this year and let usage grow into it. That means four concrete commitments:

1) Put data classes and consent in writing, then wire them into a ledger you actually use. Do this even if the first version is a spreadsheet. 2) Require model BOMs, change notices, and per‑request logs for any tool that touches grading or advising. If a vendor can't meet that bar, keep them out of evaluative contexts. 3) Encode policy into the LMS and advising flows — assignment types, submission metadata, UI cues — so compliance is the path of least resistance. 4) Run guided pilots with real assessment patterns and publish what you learn monthly, on one page, to both faculty and the board.

You'll notice what’s missing: a promise to standardize on one model or a plan to “solve” detection. The market will keep moving. Your job is to build capacities that survive motion.

Scaffolding is not the building. It’s what lets people work safely while the building rises. Good scaffolding is assembled quickly, adapted often, and removed when walls and rails make it redundant. Governance in AI‑assisted learning should feel the same: light, strong, and temporary where it needs to be.

Plain statement: Build the scaffolding, then build the future on purpose.

Boards and CIOs who take this path won't just avoid harm. They'll produce evidence about what works, recruit faculty into designing new practices, and give students a vocabulary for responsible use. That is how categories consolidate — through operational discipline that earns trust, one term at a time.

Boards keep asking, “Where is the real AI risk in our learning systems?”
Here’s the answer I give in the room: the weak points are in process, not in tools.

AI-assisted learning is already present—in LMS plugins, writing centers, advising flows, and student devices. The question is how we govern the work, the data, and the vendors without stalling instruction.

Five fault lines to close now:
1) Data boundaries and consent. Student work, advising notes, and clickstream data now touch models. Classify data, set default consent rules, and require vendor model transparency. If the data class isn’t named, it will leak.
2) Authorship and assessment. You can’t grade intent you can’t locate. Require submission metadata (what AI was used, for what), give students an AI-citation scaffold, and align rubrics to observable behaviors.
3) Model drift and vendor control. Vendors swap models overnight. Ask for model bills of materials, change notices, and rollback paths. No graded use without them.
4) Policy translated into systems. PDF policies do not govern systems. Encode rules in LMS configs, assignment templates, and UI cues.
5) Equity and cost. AI access follows price, language defaults, and device constraints. Treat equity as a design input, not a scholarship afterthought.

A 12-month plan that fits governance calendars:
- 0–90 days: inventory uses, freeze new high‑risk deployments, stand up a review loop.
- 90–180: launch guided pilots with consent, route data via a “switch,” and publish the model BOMs.
- 180–270: encode policy in systems—templates, rubrics, data blocks, and audit logs.
- 270–360: institutionalize pricing, procurement clauses, and a monthly one‑page board report.

Build one reference stack—ledger (data classes + consent), switch (routing + blocks), sandbox (safe pilots), review loop (audit + outcomes)—and reuse it across use cases.

Plain truth: the gap isn’t a product you buy; it’s a discipline you run. Start with one gateway course and one advising case; prove value, then expand.

If you want the full framework, I wrote a long-form guide. Happy to share templates.

#HigherEd #EdTech #DataGovernance #AI #BoardGovernance