Use an AI tutor without enabling cheating

2026-07-07 · The alltutors.ai team

The fear is right, so let's take it seriously

Ask a student success office or a compliance lead what worries them about AI in a course, and you get one answer before any other. They ask the same thing first: will this just do the homework for students. It is the dominant narrative in higher ed and the first objection in every L&D procurement review. Most vendor pages wave it away with a slogan. We are not going to.

A general chatbot really is an integrity problem. But an AI tutor and a chatbot that does the homework are not the same product. This post separates the two, including the places where we do not have the control you might want yet.

Why a raw chatbot is the integrity problem

Hand a student a general-purpose chatbot and two things happen that break academic integrity at the root.

First, it hands over the finished answer on demand. Ask it to solve the problem set, write the essay, fill in the lab report, and it produces the completed artifact. There is no friction between the question and the deliverable. The student does not have to reason through anything. The work arrives done. That is the tool working as designed. The design is just wrong for a graded context.

Second, it leaves no record. The conversation lives in the student's private session. You, the faculty member or the L&D owner, cannot see what was asked, what was produced, or whether the submission that lands in your inbox was reasoned out or copy-pasted. Click-through completion has the same hole in compliance training: a green checkmark that proves nothing about understanding. The chatbot version is worse, because now the artifact itself is generated.

Those two properties, answer-on-demand and no-record, are the actual integrity risk. A purpose-built tutor only matters if it changes those two things. So let's look at what genuinely does.

What a purpose-built tutor actually changes

The table below skips "AI good, AI bad" and lays out the integrity-relevant dimensions where a raw chatbot and a purpose-built tutor really differ.

Every row in the right column is a real, shipped lever. Below are the ones that matter most, then the two that are not there yet.

The work has a shape, and the shape is the lever

The strongest honest claim is not that the tutor refuses to answer. It does not, and any vendor telling you their AI withholds answers is describing a prompt, not a guarantee.

What differs is that a student is not sitting at a blank prompt. They are going through a plan you built: a sequence of units and lessons, in formats you chose, each asking them to do something. A quiz they answer. A practice task they attempt. A speaking exercise where they say it out loud. A conversation with the tutor where the tutor knows the course and has the context of what came before. A raw chatbot has one move, which is to produce the artifact. A plan has many, and most of them are the student producing rather than receiving.

That does not stop a determined student from opening a chatbot in another tab. Nothing does. It does mean the path of least resistance inside your course is doing the work, and that the work leaves a trail you can look at.

The loudest faculty objection after cheating is deskilling: the worry that AI does the thinking students should be doing. The honest answer is the same one. You choose the formats. A plan built out of readings and lectures is passive by construction. A plan built out of quizzes, practice and speaking makes the learner produce, and that choice is yours at build time, not something the tool decides at runtime.

The answer key never reaches the device

The second concrete lever is where a lot of cheating actually happens, and it is unglamorous: students pulling the answer key out of the page.

With a quiz built the naive way, the correct answers are sent to the browser so the page can grade the response locally. Anyone who opens the developer tools or reads the network tab can see the key. The quiz is theater.

Our quizzes are graded on the server. The answer key never ships to the student's device. The page shows the question. The answer goes to the server. The server decides and sends back the result. There is nothing in the page source to scrape, because the correct answer was never there. It holds across every quiz kind: multiple-choice, true/false, type-in, order-the-steps, fill-the-blank. A student can guess, but they cannot read the key off the screen. That is a real, structural difference from a page you can inspect.

Grounding and preview keep the tutor on your material

Two more levers, quickly, because they matter to accuracy as much as integrity.

Grounding. You upload your files, paste links, or connect a Drive, and the tutor retrieves from your material before it answers, filtered to that specific tutor. Ingestible sources are text, PDF, and web links. The effect is that answers trace back to your own course content instead of the model free-associating about the subject. Think of the intro-stats or gen-chem section where a third of the cohort does not make it through. In a weed-out course like that, where accuracy is non-negotiable, this is the difference between a tutor anchored to your syllabus and a chatbot winging it. It is not a correctness guarantee. It pulls the tutor toward your material and cuts down off-topic invention, which is why you still review before you publish. We wrote up how retrieval actually works in a grounded AI tutor.

Preview and instructor shaping. Nothing goes live until the person who built it publishes it. This is not a system imposed on faculty from the provost's office. The faculty member or instructional designer owns the tutor, shapes its study plan, grounds it in the material, and previews the whole thing first. You see what a student will see before a student sees it. That upstream control, what it is grounded in and what plan it teaches, is the real lever you have today, and it is the answer to the governance question of who decides what the tool does. The guide to designing a study plan walks through shaping that sequence.

The gaps, stated plainly

Two things come up constantly in higher-ed and compliance conversations, are not shipped, and we are not going to imply they are.

There is no answer-refusal mode, and no format that structurally withholds an answer. You cannot set a rule that says "the tutor must never give the answer," and there is no per-topic block-list you can hard-code. We shipped a scored Socratic sparring format once and have since removed it, because it was never actually reachable in a published plan; we would rather say that than keep it on a feature list. Control today is upstream, through grounding, the plan you build and the formats you choose, not a rule engine at runtime.

There is no LMS, LTI, or Canvas gradebook integration. You do not embed the tutor with an LTI launch, and completion does not pass back to your gradebook. What you actually do is share a link. Publishing gives you a private, link, or public share page, and you put that link wherever you want, including inside a Canvas page or module. But it is a link, not an embedded LTI tool, and there is no SDK or iframe widget. Completion and engagement live in the owner dashboard, which shows completion rates, session counts, and time spent, not in Canvas. Weak LMS integration has killed more than one AI-tutor pilot. If deep LTI passback is a hard requirement for your office, know it is on the roadmap, not in the product.

For a compliance buyer the record question goes further than "can faculty see the work." You want an exportable, defensible per-learner record, and the ability to lock content once it is approved. The owner dashboard shows completion, sessions, and time spent today. Formal audit logs, SSO, and export-for-audit tooling are roadmap, in the same bucket as LTI. If your rollout has to survive an audit, treat those as not-yet-built and plan around it.

On data: uploaded material is encrypted at rest, and retrieval is scoped to the single tutor you attached it to, so one tutor's content does not leak into another. That is the real posture today. Formal FERPA paperwork, a signed DPA, and SSO sit in the same roadmap territory as the above. If student-data privacy is a procurement gate, ask exactly where it stands before you commit a cohort.

Measuring understanding is its own discipline, and completion alone will not tell you who learned. We think that gap matters more than most integrity conversations admit, and we made the case in completion isn't competence.

How to think about it

None of this is "we solved cheating." Determined students defeat any system, and the two controls you might most want, a global refusal mode and LMS passback, are not here yet. What is here is a course with a shape, server-graded checks a student cannot read off the page, material the tutor is anchored to, and a record of who actually went through it. The instructor builds and previews all of it before it ships.

The reason that matters is not cheating in the abstract. It is the number your office is accountable for. An engagement signal you can trust is what moves a DFW rate in a gateway course. A completion checkmark that proves nothing does not. The dashboard shows completion next to sessions and time spent, a real signal on whether people are sticking with it, not just who clicked through. It is a proxy, not a verdict, but it beats a green checkmark.

The fastest way to judge it for your own course is to build one and try to cheat it yourself. Start a tutor with your syllabus and lecture notes and put a student's hat on, or book a walkthrough if you want it shown to your office on a live example first.