Was this forwarded to you by a friend? Sign up, and get your own copy of the news that matters sent to your inbox every week. Sign up for the On EdTech newsletter. Interested in additional analysis? Upgrade to the On EdTech+ newsletter.
Recently Morgan covered the MIT ad hoc committee on generative AI [emphasis in original].
One of the striking things about the report is how seriously the committee grapples with the challenges AI poses, only to arrive at recommendations that sound remarkably like good educational practice. In some ways, they are pretty obvious.
But that obviousness is deceptive. Taken together, the recommendations amount to a fairly substantial rejection of three increasingly common responses to AI in education: blanket restrictions on AI use, technological silver bullets such as AI detectors, and attempts to retreat to an imagined pre-AI classroom through blue books and heavily weighted in-class exams.
Alas, Morgan’s and MIT’s rejection of blanket restrictions and silver bullets aside, we are now seeing a rapidly growing anti-AI movement in education. She further noted a significant limitation: MIT is much better at describing where it needs to go than explaining how it gets there.
Let’s extend the conversation along both lines—looking at the practical implications of the anti-AI movement, and considering implementation issues relating to specific EdTech product categories.
These are not easy questions. I described this summer’s LMS conferences, which had plenty of AI announcements, from course authoring to student study tools. Courseware and engagement tools are adding their own features. Zoom can translate captions and generate notes. And all along, universities are signing Big Tech agreements that give students and faculty access to the same AI platforms some courses prohibit.
In the end, there are far better policy ideas that can deal with practical nuances of new and rapidly changing generative AI than seen in the bans and resistance, and some of the leading ideas come from academia itself.
Anti-AI policies in more detail
The highest-profile AI bans come from the K-12 world, but given the social contagion nature of this movement, they are relevant to higher education. New York City’s 2026–27 guidance prohibits student-facing generative AI from 2K through eighth grade, with high school use limited to approved programs. Teachers can continue using approved AI tools for instructional planning and operational work. AI grading, behavior monitoring, and decisions about placement, promotion, and graduation are prohibited. There are exceptions for necessary accessibility tools, including technologies required by Individualized Education Programs and 504 plans.
NYC is introducing restrictions on particular uses of generative AI, with different rules for students and staff. This does not mean every piece of software containing something its vendor calls AI is no longer allowed.
Los Angeles has taken a broader approach to student access. The district confirmed to K-12 Dive that it was restricting access to generative AI platforms for students across all grades for 2026–27 while reviewing instructional uses and safeguards. Its ad hoc committee is expected to recommend policy by the end of the school year.
Higher education examples are not as simplistic or consistent, even if centered on prohibitions and pauses:
University of Chicago’s Social Sciences Core: Guidance reported by the Chicago Maroon calls for predominantly analog courses, restrictions on student AI use, and human-produced syllabi. It also restricts AI-assisted grading, with an exception for faculty evaluating its validity against human grading, and allows consultation over instructional experiments. This applies to the Social Sciences Core, not the whole university.
UC Berkeley Law: Its policy effective summer 2026 defaults to prohibiting AI in producing work for credit, including outlining, drafting, revising, translating, and editing. Instructors can authorize exceptions in writing. Permission to identify research sources does not amount to permission to generate the submitted work.
Rutgers: In February, the university announced a temporary pause on Canvas IgniteAI features pending review, including search, discussion summaries, and translation. It proposed a pilot as part of that process. The announcement documents a deployment pause, rather than a standing prohibition on students using AI in their assignments.
There are other examples, and they approach bans and restrictions through different lenses. And there is some real momentum behind this anti-AI movement.
Five categories help make sense of the tools
I, however, find it more useful to ask what work the AI performs in an educational context.
What the AI does | Examples | The practical policy question |
|---|---|---|
Makes material accessible | Captions, translation, document remediation | Is the function covered, excluded, or allowed through an exception? |
Prepares instruction | Generates course materials, questions, rubrics, or coding exercises | May instructors use it, and under what review or disclosure requirements? |
Coaches the student | Provides hints, explanations, practice, or formative feedback | Is guided assistance permitted, and who decides? |
Performs the student’s work | Produces essays, code, solutions, or analysis | Which parts of the assignment may AI complete? |
Evaluates the student | Assigns grades, judges mastery, or recommends consequential interventions | Does the policy distinguish feedback, recommendations, and final decisions? |
These categories describe use cases. The same product can appear in several rows, and the same feature can change categories depending on how it is used.
At the LMS conferences this summer I saw several relevant examples. At D2L Fusion, the strategy included AI-assisted content creation alongside Lumi Learner Mode, announced for a fall beta, with explanations, practice, and a home for Lumi Tutor. Those functions span preparing instruction and coaching students.
At InstructureCon, Canvas Study Tools generated flashcards, summaries, and practice questions from instructor-sanctioned content. Knowledge Chats had been rebuilt from the earlier LLM Assignments concept: what was previously positioned as an AI-graded activity became a formative check-in. In the categories described above, that would move its role from evaluating the student toward coaching the student.
Blackboard’s conference included Ally accessibility remediation and AVA study tools, including a rubric check that provides feedback before submission. Again, checking a draft against a rubric and assigning its final grade are different uses, even when similar technology sits underneath.
Some of these features are available, while others were announced as pilots or roadmap items. The direction is clear, however: buying an LMS increasingly means buying a collection of embedded AI functions that require different policy decisions.
The distinctions from outside the LMS
zyBooks lets instructors generate coding labs and assessment questions. Its AI Hints feature provides students with directional assistance on their code and is disabled by default, with instructors choosing whether to enable it for each lab. That gives a course a way to permit instructional preparation while restricting student assistance.
According to zyBooks, its code grading uses deterministic test cases, not AI judgments of student submissions. AI can help create those tests, but in operation it is not an AI activity, per se. A policy against AI grading might not be clear about whether it also restricts AI-assisted assessment design. Calling the whole product “AI-powered” does not answer that question.
Zoom illustrates a different issue. Translated captions provide access to a conversation; AI-generated notes can summarize it and identify key points. If a student is assigned to write a summary of that conversation, the latter may perform part of the assigned work. If it is an approved accommodation, a different rule may apply.
And consider Wooclap’s AI facilitation features, which can organize and summarize student responses for the instructor. Students do not need to open a chatbot for their contributions to be processed by AI. A restriction framed around students directly using AI can leave that situation unresolved.
Zach Justus, in “Ban AI in NYC and LA Schools,” describes the folly of simplistic policy assumptions.
This hits home for us in higher education as well. For years Nik and I have pushed back on what we called “abstinence only” education about AI. The problem is kids are in school for 6-8 hours a day. Limiting access to LLMs on school devices during school hours does not eliminate AI from schoolwork, teaching/learning, or from social lives. [snip]
I don’t pretend this is easy or that solutions are straightforward, in fact my issue with this has less to do with the ban itself than the willful ignorance of commentators and perhaps policy makers that the solution to AI is as simple as banning it.
There is a big difference between announcing a restriction and implementing it.
MIT and the University of Sydney offer more useful starting points
There are other emerging approaches that will go further in addressing the practical questions around implementation, although neither supplies a complete feature-by-feature implementation guide.
MIT’s committee report, released in August, recommends explicit course policies and supplies examples ranging from prohibited to required AI use. Its limited-use example separates assistance from producing substantial assignment solutions, while acknowledging disagreement over where assistance ends.
Sydney’s August green paper remains a consultation document, with a final strategy planned for November. It builds on an established assessment framework: open assessments allow AI as part of learning, while secure assessments control the conditions under which students demonstrate capability.
Here is how those approaches map to the same five categories. These are descriptions of the guidance, not blanket approvals of particular products.
AI function | MIT | University of Sydney |
|---|---|---|
Makes material accessible | Recognizes accessibility benefits; does not give detailed captioning or translation rules. | Emphasizes equitable access; the green paper does not resolve individual accessibility features. |
Prepares instruction | Addresses generated teaching materials and recommends disclosure of substantial use. | Emphasizes educator control over AI-enabled learning design. |
Coaches the student | Provides for tutoring and assistance within stated course boundaries. | Promotes educator-controlled Cogniti agents for practice, inquiry, and feedback. |
Performs the student’s work | Permission depends on course goals and explicit instructions. | Open assessments permit AI; secure assessments specify controlled conditions. |
Evaluates the student | Discusses grading transparency and using AI rubric feedback for practice rather than final grades. | Separates developing capability from assuring it; does not supply a blanket AI-grading rule. |
This comparison draws on the MIT report, Sydney green paper, and Sydney Assessment Framework.
These papers offer a more useful basis for EdTech implementation than does the treatment of presence of AI as the deciding factor. Both MIT and Sydney give an academic technology team something to work with: the relevant activity, who can authorize it, and the conditions that need to be supported. There will still be difficult interpretations, but at least the questions are more useful.
Not a consensus, however
I should point out that the work done at these two universities should not imply that educators are largely in agreement. In particular, there is a real resistance movement with instructors that appears to have little desire to find nuance in approaches, as described in Ithaka S+R’s recent study on attitudes about AI skills [emphasis added].
Several recipients of the survey invitation email responded directly to
express a negative opinion about AI in general, AI in higher education, or
the survey itself. These responses expressed various levels of pessimism
about or disapproval of AI along with the message that they would not be
participating in this research effort because of those beliefs. It is safe to
assume that some unknown number of potential respondents declined to
participate on similar grounds but chose not to reply to the invitation
email. Because non-participation in this research is the defining behavior
for some subset of instructors who have strong objections to AI, it can be
assumed that the results reported throughout include some degree of a
positive bias.
Some participants echoed these negative sentiments in their narrative
responses to the survey, meaning that these perspectives are captured to
some degree in the data and analysis presented here. For example, one
instructor suggested that knowing “[h]ow to disable and resist AI is the
most important skill.” Another offered that the “skill of doing things
without AI” should be prioritized for college graduates. The survey did not
directly ask respondents about their opinion of AI in higher education, but
it is clear from the responses to survey invitation and the open-text
questions that there is strong resistance from many instructors
Campus AI deals add another layer
The Cal State initiative, Anthropic’s university partnerships, and Google’s higher education programs are expanding institutional access to AI. They do not, by themselves, determine which assignments students may complete with it.
The University of Chicago’s June announcement of its Anthropic agreement provided for broad Claude Enterprise access while explicitly respecting course policies. A student can have university-provided access to Claude and still be prohibited from using it in a Social Sciences Core course.
The vendor and academic technology communities are beginning to address the implementation issues. SIIA’s response to NYC argues for distinguishing purpose-built educational tools from general commercial technology and criticizes the restrictions. But that argument does not establish that a particular tool is permitted. Earlier ACE and EDUCAUSE procurement guidance addresses a more operational problem: institutions need to review AI added to existing software, not just newly purchased AI products.
There are some relevant vendor moves. Instructure described plans to ask integration partners to disclose their AI features, while D2L’s Brightspace Apps provides information on requested permissions and controls over deployment scope. Those developments, covered in the conference posts linked above, can help institutions understand what they are enabling. Whether the controls are granular enough to carry out a particular policy depends on the institution and state or district.
For institutions and vendors, the questions are fairly concrete:
Which functions does the restriction cover, and for which users?
Can those functions be controlled separately at the institution, course, or assignment level?
Who can approve an exception, including an accessibility exception?
Does the rule cover AI processing student work even when students never interact with an AI interface?
What happens when an already approved product adds another AI feature?
My view is that the MIT and Sydney approaches are much more useful than the politically driven rush to announce moratoria. Their advantage is practical: they provide a basis for making decisions about teaching activities and tools. Morgan was right that the implementation work remains substantial, but a policy has to get far enough that someone can determine what to enable, what to disable, and who makes the call. Otherwise, “we banned AI” tells us more about the announcement than about what will happen in course activities.
The main On EdTech newsletter is free to share in part or in whole. All we ask is attribution.
Thanks for being a subscriber.
