A strategy problem institutions have that most businesses don't
Most companies get to choose when AI shows up. A school or university mostly doesn't. Students and staff had access to generative tools well before any administrator convened a committee to think about what that meant, and by the time a policy conversation starts, the practice it's meant to govern is often already normal. That gap between behaviour and governance is the defining shape of AI strategy in education, and it means a strategy engagement here has to do something a typical corporate audit doesn't: catch up to what's already happening, rather than plan for something that hasn't started yet.
The other difference is who leadership answers to. A retailer's AI decisions mostly answer to a board and a budget. A principal, dean, or provost answering the same question is also answering to teaching staff who didn't ask for this, to students who are already using the tools whether or not a policy exists, to parents or guardians who want reassurance rather than a technical explanation, and to a governing body that will ask what was decided and why, months after the fact. A strategy engagement for an institution has to produce something that holds up in front of all four audiences at once, not a roadmap that only satisfies whoever commissioned it.
Separating the administrative opportunity from the academic integrity question
This split is the single most useful thing a strategy engagement does for an institution, and it's the one most rushed AI pilots skip. AI strategy consulting usually starts with an opportunity audit — the same audit we'd run for any business — but in education that audit has to sort every candidate into one of two very different buckets before anything else happens.
The administrative bucket is the safe one: enquiry handling, document chasing, timetabling, HR onboarding, policy lookup, alumni outreach — the operational load our education work covers in more depth. These are workflows where getting something wrong costs an institution time, not trust, and where the fix is a procurement and build decision like any other. An institution can act on this bucket now, with a clearly scoped project and a contained, well-understood risk.
The academic integrity bucket is a different kind of decision entirely: what counts as acceptable use of AI in coursework, whether and how student writing gets evaluated for AI involvement, what a teacher may use AI for when giving feedback, and where the line sits between a study aid and a shortcut. None of that gets resolved by buying a tool. It's a policy and pedagogy decision that belongs to your academic leadership and teaching staff, built on your institution's own values about what learning is for. A strategy engagement's job is to make that split explicit early, not to quietly answer the academic question with a procurement choice just because that's the kind of question a vendor is equipped to sell an answer to.
To be direct about where Calfy sits on this: we don't build systems that grade student work autonomously or stand in for a teacher, and we don't sell plagiarism-detection or AI-detection tooling. That's deliberate. A vendor selling a detection tool has an interest in that being the answer to the academic integrity question — we'd rather name the question honestly and leave it with the people who are actually accountable for teaching and assessment.
What the engagement actually produces
The engagement ends with a small set of concrete things your institution can act on, not a slide deck about the future of AI in education.
- A ranked list of administrative opportunities, scored on staff hours involved and how contained the risk is if a system gets something wrong.
- An acceptable-use policy draft, written in language your staff and students will actually read, tested against scenarios your institution recognises rather than borrowed from somewhere else.
- A staff capability and training plan, scoped to the roles actually affected — admissions counsellors, teaching staff, IT, student services — instead of a generic introduction to AI.
- A student-data governance and access framework: who can see what, what gets logged, and where a safeguarding concern routes.
- A procurement due-diligence checklist, covering the AI features already sitting inside systems your institution has already bought.
- A sequencing plan naming the first project, why it's first, and what has to be true before the second one starts.
It's the same discipline behind AI strategy consulting generally, applied to an institution that's answering to more audiences than a typical business ever has to.
How the work runs: three walkthroughs
The clearest way to see what this looks like is to walk through how three actual sessions run.
Sorting a wishlist that has a chatbot and a grading assistant on the same list
A working session usually starts with whatever every department has been wanting: an admissions chatbot, a plagiarism checker someone saw at a conference, an AI tool that drafts feedback comments, a request from IT to finally automate new-starter paperwork. All four land on the table in the same hour, and left alone they'd get evaluated as if they were the same kind of decision. They aren't. The admissions chatbot and the onboarding paperwork go straight into the administrative bucket — scoped, sized, and ready to rank against each other on hours saved and risk. The grading assistant and the plagiarism checker go into the academic integrity bucket, get flagged as a policy question for academic leadership, and get taken off the build list entirely until that policy exists. The session ends with a shorter, sharper list than it started with, and a name attached to who owns the question that isn't going to be answered by a purchase order.
Drafting an acceptable-use policy with the people who have to follow it
A policy nobody reads doesn't change anything a week after it's published, so the drafting session runs with the people who'll actually be bound by it — a handful of teaching staff, someone from admissions, someone from IT — rather than being written in a legal vacuum and circulated afterwards. We test the draft against real scenarios: a teacher using AI to draft comments on a stack of essays, a student using it to brainstorm an outline versus to write the outline itself, a staff member pasting a document into a public chatbot without thinking about what's in it. Where the draft produces a clear, defensible answer to a scenario, it stays. Where it produces a shrug or an argument, it gets rewritten until it doesn't. The result is shorter than most policy documents and considerably more likely to survive contact with an actual Monday.
A procurement review turns up an AI feature nobody switched on
Somewhere in most institutions, a system already in use — the learning platform, the student information system, a communications tool — has quietly shipped an AI feature as part of a routine update, sometimes turned on by default. The procurement review works through the institution's existing contracts and vendor systems asking one question of each: what AI capability does this already have, who enabled it, and does anyone know what it does with the data it sees. It's not unusual for the honest answer to be "we didn't know it was there." From that point it's a short, concrete decision — turn it off, configure it properly, or accept it with eyes open — made by someone at the institution with the authority to make it, not left as a default a vendor chose on your behalf.
Staff capability: training that survives a Monday morning
A policy that lives only in a document doesn't change what happens in a classroom or an admissions office. Training is the work of getting the people who'll actually use or manage a system, or work under a new policy, comfortable with it before it shows up in their week — not a generic session on what AI is, but time spent on their actual role: an admissions counsellor deciding when a chatbot answer is good enough to send versus when it needs a human, a teacher deciding what AI-assisted feedback still needs their own read before it goes to a student, an HR coordinator learning what an onboarding assistant will and won't do on its own.
The measure of a good session isn't attendance. It's whether, a month later, staff can explain what a system or a policy actually asks of them, and whether they trust it enough to use it the way it was intended rather than working around it.
Student data governance and access control
Anything a strategy engagement recommends has to be built around student data from the start, not bolted on afterwards. Student data is sensitive by nature — academic records, family and financial details, and in some cases safeguarding information — and an institution carries real obligations around how that information is collected, stored, shared, and retained. Those obligations vary by institution, and only your institution's own data protection or compliance lead can define them precisely for your context; a strategy engagement supports that work, it doesn't replace it.
In practice, the governance framework we produce sets out the narrowest access each proposed system would need — read-only where reading is enough, scoped credentials rather than a shared login — and a clear line on what a system may surface to a person versus what it may act on directly. It sets out what gets logged, so "who or what touched this record, and why" has an answer months later, and it makes explicit that anything resembling a safeguarding concern routes immediately to a named person rather than being handled by any automated system.
Sequencing: why the first project is never the exciting one
Ranked opportunities don't get built in order of ambition. The first project should be administrative, small enough to ship in weeks, and uncontroversial enough that nobody outside the project team has to weigh in before it goes live — an enquiry line, a document-chasing workflow, a policy lookup tool, not anything that touches grading or academic judgement.
That first project earns the institution something a planning document can't: proof, to staff, students, and a governing body, that a system was scoped honestly, stayed inside its stated boundaries, and didn't need to be walked back. That proof is what makes the second, harder conversation — about AI and academic integrity — easier to have, because it isn't happening in the shadow of a rushed rollout that went wrong somewhere else in the institution.
How this connects to what gets built afterward
Once the sequencing plan names a first project, the strategy engagement hands off directly into a build, using everything the audit already established rather than starting the scoping conversation over. An enquiry-handling opportunity usually becomes a voice AI system for education built around your existing phone number and calendar. A document-chasing or approval workflow usually becomes a custom AI agent for education that works a queue the way a coordinator would. Timetabling, room admin, and onboarding paperwork usually become workflow automation for education that keeps systems of record in sync without anyone re-typing the same details twice. And a policy or handbook question problem usually becomes a knowledge system for education that answers from what the institution actually has on file, and says so honestly when it doesn't know.
Some engagements end with a document your team executes internally instead — that's a legitimate outcome too, and the strategy work is priced and delivered as its own engagement either way, not as a sales step toward a build we assume you'll commission.