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 sparring format makes students reason, not receive

The most important lever is the format we call Socratic sparring. It is a chat, but not a chat where the student asks and the tutor answers. It is the reverse. The learner argues toward a goal against a tutor persona. A hidden rubric drives a live meter, so the tutor is measuring the student's reasoning in real time and pushing where it is thin. When a student stalls, a hint is available, but a hint is never the point. The point is to get the learner to produce the argument themselves.

That inverts the integrity problem. A raw chatbot moves work from the student to the model. Sparring moves it back onto the student. They cannot receive the answer, because the format is not built to hand it over. It is built to make them construct it out loud, which is exactly the thing a graded submission is supposed to prove they can do.

The loudest faculty objection after cheating is deskilling: the worry that AI does the thinking students should be doing. Sparring is the answer to exactly that fear. It forces the student to produce the reasoning rather than outsource it.

One note, because it is the biggest landmine in this whole topic. Answer-withholding is a property of the sparring format specifically. It is not a global switch you flip that forces a reading, a lecture, or a flashcard deck to refuse answers. If you want the friction, you use sparring for the part of the plan that needs it. We will come back to what does not exist yet.

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 and battles 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. It also holds for battle, the async speed-duel on a lesson's questions with a course leaderboard. A student can guess, and answering after the window costs the speed bonus, 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 global instructor-tunable answer-refusal mode. You cannot set a single "the tutor must never give the answer" rule that applies across every format. The answer-withholding behavior is a property of the sparring format, and you get it by using that format where it belongs. There is also no per-topic block-list you can hard-code. Control is upstream, through grounding, the plan, and format choice, not a fine-grained 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 tutor that is structurally harder to cheat with than a chatbot, and one the instructor builds and previews 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.