The Architecture Question Nobody Asks Early Enough
Most campus AI conversations start with features. Can it tutor? Can it summarize a syllabus? Can it draft advising notes?
Those are fine questions. They're also the wrong first questions.
The first question should be: what does the architecture look like when this thing is running across seven colleges, three SIS instances, and forty thousand FERPA-protected student records?
Because by the time you're asking that question after procurement, you've already locked yourself in.
What "AI-Ready" Actually Means for a University
The term gets thrown around in vendor decks and strategic plans. An AI-ready campus, supposedly, is one that has adopted AI tools. But that definition confuses consumption with capability.
A campus that subscribes to three AI SaaS products isn't AI-ready. It's AI-dependent.
AI-ready means the institution can swap models, add new data sources, build custom workflows, and maintain compliance — without calling a vendor's professional services team.
That requires architecture, not just adoption.
The Three Pillars of Modular AI Architecture
LLM Agnosticism
The AI model landscape shifts every quarter. A platform that hardcodes a single provider — OpenAI today, maybe someone else tomorrow — becomes a liability the moment that provider changes pricing, terms, or capability.
LLM-agnostic architecture means the university can route queries to different models based on cost, latency, accuracy, or compliance requirements. A simple advising FAQ might use a lightweight model. A complex research synthesis might use a frontier model.
This isn't theoretical. ibl.ai runs this way in production, letting institutions swap models without re-engineering their deployments.
The practical benefit: when your provost asks why AI costs tripled this semester, you have an answer — and a lever to pull.
Source Code Access and Institutional Ownership
Here's the part that makes vendors uncomfortable.
If your institution can't read the source code of the AI platform processing student data, you don't have a technology partner. You have a black box with a subscription fee.
Source code access matters for three reasons that higher ed leaders consistently underestimate.
First, FERPA compliance audits. Your CISO needs to verify how student data flows through the system. API documentation isn't enough. The Office of Civil Rights doesn't accept "the vendor assured us" as a compliance posture.
Second, customization. Every university has unique workflows. The registrar's office at a 5,000-student liberal arts college operates differently from one at a 50,000-student R1.
Platforms that only offer configuration — not modification — force institutions to adapt to the software instead of the reverse.
Third, continuity. If the vendor goes under, gets acquired, or pivots strategy, the university needs to keep running. Source code access is the difference between a disruption and a crisis.
Integration via Open Protocols (MCP, LTI, xAPI)
The average university runs Canvas or Blackboard for learning, Ellucian Banner or Workday Student for student information, Salesforce Education Cloud or Slate for CRM and admissions, plus dozens of homegrown systems.
AI platforms that can't reach into these systems are glorified chatbots. They answer questions from their own training data, not from the institution's actual records.
The Model Context Protocol (MCP) provides a standardized way to connect AI platforms to institutional data sources. Instead of building custom integrations for every SIS and CRM, MCP creates a common interface.
The AI can pull a student's enrollment status from Banner, their engagement data from Canvas, and their advising notes from Salesforce — all through governed, auditable connections.
LTI 1.3 keeps AI tools inside the LMS where students already work. xAPI captures learning events in a format your institutional research team can actually use.
The architecture question isn't "does it integrate?" — it's "does it integrate through open protocols that I control, or through proprietary connectors that the vendor controls?"
FERPA Compliance at the Code Level
Let's talk about what FERPA compliance actually requires in an AI context, because most vendor claims don't survive scrutiny.
FERPA compliance isn't a checkbox. It's a set of ongoing obligations about how education records are stored, processed, accessed, and disclosed.
When an AI platform ingests student data — grades, enrollment status, advising notes, accommodations — every query against that data is potentially a disclosure.
The institution needs to know, at the code level, that student records aren't being sent to third-party model providers without appropriate agreements.
This means data residency matters. Where do embeddings live? Where do conversation logs persist? If a student asks the AI about their financial aid status, does that query — which now contains PII — leave your cloud environment?
Institutions running ibl.ai deploy in their own infrastructure, which makes the FERPA analysis straightforward. The data never leaves the institution's control.
Contrast this with SaaS platforms where student queries traverse multiple third-party services before generating a response.
Your CISO should be asking: show me the data flow diagram for a student query that references their academic record. If the vendor can't produce one, that's your answer.
How to Assess Sourcing and Partnering Decisions
The standard RFP process for AI platforms tends to optimize for features and price. Both matter, but neither captures the architectural risk.
Here's a more useful assessment framework.
Portability test. If you cancel this contract in two years, what happens to your data, your customizations, and your integrations? If the answer is "you lose them," the platform is a trap, not a tool.
Inspection test. Can your IT team audit how the platform processes student data? Not through documentation — through actual code review. If no, you're trusting marketing materials for FERPA compliance.
Evolution test. When a new LLM launches next quarter with better performance at lower cost, how long does it take to switch? If the answer is "wait for our next release," you've outsourced your AI strategy to someone else's roadmap.
Integration test. Does the platform connect to your SIS, LMS, and CRM through open protocols, or through proprietary connectors that only the vendor can maintain?
Governance test. Can your faculty and staff define who sees what data, which models handle which queries, and what guardrails apply to which use cases? If governance is limited to an admin dashboard with toggle switches, it's not governance — it's configuration.
Governance Through Ownership
There's a pattern in higher ed technology that keeps repeating. The institution adopts a platform. The platform works well. The institution becomes dependent. The vendor raises prices, changes terms, or gets acquired. The institution has no leverage.
This happened with LMS platforms. It happened with SIS platforms. It's happening right now with AI.
The alternative isn't building everything from scratch. That's impractical for all but the largest R1 institutions with significant engineering teams.
The alternative is modular ownership. Use a platform that gives you the source code, runs in your infrastructure, connects through open protocols, and lets you swap components as your needs evolve.
Syracuse University took this approach — deploying AI infrastructure they control rather than subscribing to a black box.
The result is an AI capability that evolves with the institution's needs, not with a vendor's product roadmap.
The Architecture Decision Is the Strategy Decision
Campus AI strategies that start with "which tool should we buy?" end up with fragmented, ungovernable deployments.
Strategies that start with "what architecture do we need?" end up with platforms that scale, comply, and adapt.
The provost doesn't need to understand Kubernetes. The CISO doesn't need to evaluate transformer architectures. But both need to understand this: the architecture you choose today determines whether AI becomes institutional capability or institutional dependency.
Choose the architecture you can own. Everything else follows from that.