AI as an Interface to Institutional Systems
Most colleges are already using AI. Staff and students use ChatGPT, Claude and Copilot; the VLE, the CRM and the service desk have each grown an AI feature of their own. The question that matters now is not whether institutions will use AI, but how AI can be connected safely to the systems they already depend on.
The limit of the standalone assistant
A chatbot with a knowledge base can explain the fee policy. It cannot tell a student what they owe, when their next class is, or whether yesterday’s support request has been picked up, because the answers live in the student information system, the timetable and the service desk, and the assistant has no governed way to reach them. Students should not have to know which system holds what. Until the assistant can use those systems on the student’s behalf, with the student’s permissions, it is a better search box and not much more.
AI above the systems, not instead of them
The architecture we have been building at Inneall puts an AI assistant above existing institutional systems rather than in place of them. The SIS, VLE, CRM, timetabling and service desk remain the systems of record. The assistant uses them through secure, narrowly defined integrations: retrieve this student’s timetable, list their Moodle courses, search the approved knowledge base, check the status of a ticket, create a service request, fetch an authorised record. Each capability is authenticated, authorised against the user’s existing permissions, and logged.
The Model Context Protocol (MCP) is one practical way to expose capabilities like these to an AI system. Instead of giving a model access to a database, an institution publishes a small set of named tools, each with a defined input, output and permission check. The model can call only what has been published, and every call is auditable. This is the same least-privilege principle that governs conventional integrations, applied to AI.
The result, for a student asking “what do I need to do this week”, is one answer drawn from four systems: a lecture tomorrow at 10:00, an assignment due Friday, two unread announcements in Moodle, and a document the programme office is waiting for. For an academic, it is their modules, classes and outstanding marking. For a support team, it is the case history and the relevant policy in one place, before they pick up the phone.
What we have learned from running it ourselves
Inneall runs AI agents inside its own operation: one works our client service desk as a named member of the team, handling first-line tickets across email, Jira and Slack; another watches our production estate and proposes incident responses that an engineer approves before anything is changed. We have written up both: Lugh, our service desk agent, and the Ops Agent, with the real tickets and messages on how we use AI at Inneall.
Three lessons carry over directly to institutions. The integration layer is where most of the work and most of the risk sits, not the model. The agent must be able to say “I can’t do that” and hand over with full context, and the hand-over is where it earns trust. And the audit trail has to be designed in from the first day, because the first question from a data protection officer will be “show me what it did and why”.
Governance is part of the architecture
Colleges hold a great deal of personal and sometimes sensitive data. An AI assistant must never become a way around the access controls of the underlying systems: a user should be able to see through the assistant only what they could already see in the SIS or the VLE. Data residency, retention, logging, human oversight and the choice of model provider are architecture decisions, not policy afterthoughts. For institutions in Ireland that generally means EU hosting, a data processing agreement with every provider in the chain, and a clear statement of what is and is not used to train models.
Start small, and measure
A pilot that connects an assistant to two or three systems for one group of users answers the questions that matter: whether people use it, where it saves time, what it should and should not have access to, and where a human must stay in the loop. Those answers are worth more than any transformation programme designed before anyone has used the technology.
Inneall has spent nine years building, hosting and integrating systems for higher education. We are now applying that experience to AI inside those environments, and we are looking for institutions that want to go beyond a demonstration. If you are considering how AI could work with your VLE, student records, CRM, service desk or internal knowledge, we would be glad to talk, and our AI Readiness Assessment is a fixed-price place to start.
Ciarán Mac Donncha, Director, Inneall