# AI Across the Administrative Surface — Owned by the Institution

> Source: https://ibl.ai/resources/use-cases/ai-for-higher-education-administration


*Admissions, registrar, advising, financial aid, and student success — one platform, one governance layer, FERPA-aligned by architecture, with the source code in the institution's repository.*

## The Problem

Higher education administration is the most distributed buyer in the AI conversation. Admissions wants prospect engagement. The registrar wants degree-audit automation. Financial aid wants application triage. Advising wants student-success agents. Student affairs wants 24/7 service. Each office buys its own tool, on its own contract, with its own data flow.

The result is a sprawl of single-purpose SaaS AI products, each carrying student data into a different vendor's perimeter, each producing audit evidence in a different format, and each generating a separate FERPA conversation with general counsel.

ibl.ai is the platform layer that lets one institutional AI deployment serve every administrative office — with FERPA-aligned routing per workload, audit evidence unified in the institutional SIEM, and source-code ownership the institution can defend in the next budget cycle.

## Pain Points

### Per-Office AI Sprawl Drives Cost and Risk

Each administrative office procures its own AI tool with its own contract, identity flow, and data-handling commitments — multiplying the per-seat cost and the FERPA surface across the institution.

*Metric: Stacked per-seat AI commonly lands at $60-80 per user per month across 4-5 SaaS tools*

### Student Data Lives in Many Vendor Perimeters

Each per-office tool processes student data on a different vendor's infrastructure. Data-residency commitments to students and state regulators get harder to document with each addition.

*Metric: A typical multi-office AI deployment routes student data through 5-8 distinct vendor perimeters*

### FERPA Audit Evidence Is Fragmented

Audit evidence for AI sessions lives in each vendor's dashboard, in the vendor's format. Producing a defensible institutional view of AI use across the administrative surface is manual and brittle.

*Metric: Vendor dashboards rarely export in the institution's audit-of-record format*

### Identity Binding Breaks Across Tools

Faculty and staff use personal accounts on some AI tools, sanctioned accounts on others. Shadow usage is invisible to the central audit chain.

*Metric: Most institutions have no defensible inventory of staff and faculty AI use across administrative offices*

### Cabinet Changes Strand Deployments

When provost, CIO, or president changes, the patchwork of per-office AI tools is hard to defend and harder to extend. Re-procurement under pressure is the common path.

*Metric: Higher-ed AI vendor turnover within 18 months of leadership change is common*

## Solution Capabilities

### One Platform, Every Administrative Office

Admissions, registrar, advising, financial aid, student affairs, IT — one platform, one identity flow, one audit chain, one set of vendor relationships to maintain.

### FERPA-Aligned Routing per Workload

Workloads that touch student educational records route to a local open-weights model running on institutional GPUs. Non-FERPA workloads route to BAA/contract-covered frontier models. Audit evidence captures the routing decision.

### Audit Evidence in the Institutional SIEM

Every prompt, response, and model invocation captured in the institution's SIEM in the institution's format, on the institution's retention schedule. FERPA evidence production is a SIEM query, not a vendor ticket.

### Identity Federated to the Institutional IdP

Every AI session bound to a named member of the institutional community through Shibboleth, Azure AD, Okta, Ping — via SAML 2.0, OIDC, or SCIM. No personal accounts for institutional work.

### LMS, SIS, CRM, and Advising Integration

Canvas, Brightspace D2L, Moodle, Blackboard via LTI 1.3. Banner, Workday Student, PeopleSoft, Jenzabar via REST/Ethos. Slate, EAB Navigate, Salesforce Education Cloud. Inline AI within the systems the workforce already uses.

### Source-Code Ownership and Multi-Cabinet Continuity

The institution receives the complete platform code under a perpetual license. New leadership, new priorities, and new regulatory expectations are implemented inside the institutional platform — not negotiated with a SaaS vendor.

## Implementation

### Phase 1: Architecture Decisions and Governance Charter (2 weeks)

Provost, CIO, CISO, Registrar, General Counsel, Finance, and one academic-affairs lead align on the deployment topology, FERPA posture, first workload, and success metrics. Governance committee chartered.

- Deployment-topology decision (institutional cloud, on-prem, hybrid)
- FERPA architecture document
- First-workload scope and metrics
- Governance committee charter and meeting cadence

### Phase 2: Platform Deployed and Integrated (2 weeks)

Production-grade platform installed in institutional infrastructure. Identity federation via SAML/OIDC to the institutional IdP. Audit-of-record SIEM integration live. First LMS and SIS integrations wired.

- Platform deployed and operational
- Identity federation live
- SIEM streaming
- Canvas/Brightspace and Banner/Workday integrations live

### Phase 3: First Workload in Pilot (4 weeks)

First administrative workload (e.g., admissions inquiry triage, advising-augmentation, registrar degree-audit assist) live with faculty and staff in the loop. Weekly review of audit logs and workflow metrics.

- First workload live in pilot scope
- Weekly review cadence with governance committee
- Workflow metrics in institutional dashboards
- FERPA evidence flow validated end-to-end

### Phase 4: Second and Third Workloads, Office Expansion (4-8 weeks)

Two additional administrative workloads launched. Governance posture proven across multiple offices. Forward-deployed engineering pairs with institutional engineering to set the team up to run the platform independently.

- Three workloads in production
- Institutional engineering team trained
- Roadmap for next 6 months of administrative workloads
- First quarterly governance-committee report to the cabinet

## Expected Outcomes

| Metric | Before | After | Improvement |
|--------|--------|-------|-------------|
| Per-user AI cost | $60-80 / user / month across stacked SaaS | $2-8 / user / month at developer-rate platform economics | 10-30x lower |
| FERPA evidence production time | Manual aggregation across 5+ vendor dashboards | SIEM query in institutional format | Days to hours |
| Number of vendor perimeters touching student data | 5-8 SaaS AI vendors | 1 institutional platform; frontier APIs routed only for non-FERPA workloads | Single perimeter for FERPA workloads |
| Cabinet-change continuity risk | Re-procurement of multiple SaaS contracts under pressure | Source code and platform stay; routing adapts to new priorities | Continuity preserved |

## FAQ

**Q: Does ibl.ai support all the main administrative offices in one deployment?**

Yes. One platform deployment serves admissions, registrar, advising, financial aid, student affairs, IT, and the back-office functions. Each office configures its own agents and workflows on the shared platform, under a unified governance layer. The institutional model is one platform deployment, many office-level configurations.

**Q: How does FERPA compliance work on the platform?**

FERPA-aligned posture is an architectural commitment: workloads that touch student educational records route to a local open-weights model running on institutional GPUs (no external API call), audit logs flow into the institutional SIEM, identity binds through the institutional IdP, and per-record access controls map to the institution's existing FERPA-defined access policies. Non-FERPA workloads route to BAA/contract-covered frontier models with the same audit capture.

**Q: What does the integration with our LMS and SIS look like?**

LMS integration uses LTI 1.3 plus direct API for Canvas, Brightspace D2L, Moodle, and Blackboard — agents can be invoked inline within course shells with grade-passback and assignment-aware context. SIS integration uses REST/Ethos and direct connectors for Banner, Workday Student, PeopleSoft, and Jenzabar — degree-audit assist, registration support, and financial-aid context flow from here. CRM (Slate, Salesforce Education Cloud, EAB Navigate), advising (Starfish, Civitas), and identity (Shibboleth, Okta, Azure AD) integrations are first-class.

**Q: How does the cost compare to per-office SaaS AI?**

Stacked per-office SaaS commonly lands at $60-80 per user per month. ibl.ai operates at developer-rate API pricing through the institutional platform, which typically lands at $2-8 per user per month at institutional scale — a 10-30x reduction. The trade-off is operational: the institution needs a small engineering team (often 2-5 engineers) to operate the platform. Forward-deployed engineering bridges this during initial deployment.

**Q: What is the typical first deployment scope and timeline?**

A typical first deployment is 12 weeks across four phases: architecture decisions and governance charter (2 weeks), platform deployed and integrated (2 weeks), first workload in pilot (4 weeks), and second/third workloads with office expansion (4-8 weeks). The first workload is usually a clear-impact administrative agent — admissions inquiry triage, advising augmentation, or registrar degree-audit assist.

**Q: What happens when leadership changes?**

The institution owns the platform code and the platform runs on institutional infrastructure, so leadership changes are configuration changes, not re-procurement. New priorities translate to new agents and new workloads on the existing platform. The governance committee adapts to new leadership; the platform stays.

**Q: How does this fit with our existing AI pilots and SaaS tools?**

Many institutions land at a hybrid posture: keep specific SaaS AI tools where they fit (e.g., LMS-embedded AI features under BAA/FERPA terms) and run institutional AI on the ibl.ai platform for everything else — especially the workloads touching student educational records. The institutional platform becomes the audit-of-record source and the routing layer; the SaaS tools become consumers of the institutional identity and audit posture.