About Campus AI Development

Why it exists

A gap between tools and policy

Anyone on campus can now build working software in an afternoon. Most guidance either reviews tools or sets policy, and little of it helps someone decide how to build the thing in front of them, or helps an institution decide how much oversight that work needs.

This guide offers a shared vocabulary for that decision: a continuum of approaches, a parallel platform track, six questions to ask of any project, data classification levels, proportionate control tiers and the legal triggers that apply regardless of approach.

Where this fits

A companion to the Campus AI Framework

The Campus AI Framework provides the institutional operating model: eight pillars for strategy and governance, four application domains and the AI Strategic Compass for prioritization.

Once an initiative is worth pursuing, this guide helps decide how to build it. It focuses on the homegrown, in-house pathway and the practical choices inside the Capabilities pillars, especially Campus Readiness and Implementation & Operations. It arranges approaches from vibe coding to governed multi-agent work on a continuum of structure and governance, so institutions can match the method to the work, the data, the audience and the evidence they need to keep.

In practice, the Framework’s Strategic Compass decides whether an initiative goes ahead and how closely it is reviewed; this guide decides how it is built. See how they connect. Both are starting points for local adaptation, not mandates.

Who it’s for

Builders and the people who support them

1. 01LeadersCIOs, provosts, deans and research officers deciding what to enable and fund.
2. 02BuildersStaff, faculty, researchers and students who build their own tools.
3. 03Central and research ITTeams that provide platforms, environments and review.
4. 04Governance officesSecurity, privacy, accessibility, data governance, legal and procurement.

Principles

What the guide stands on

1. 01A lens, not a rulebookEvery recommendation is a starting point to adapt with local stakeholders and policy.
2. 02Proportion over prohibitionControls should match the risk. Too little exposes people and data; too much drives work to unsanctioned tools.
3. 03The law follows what software doesObligations attach to the data and the people affected, not to how the code was written.
4. 04Honest about evidenceClaims link to sources, disagreements are shown, and gaps in the evidence are named.

Independence

Not institutional policy

Campus AI Development is an independent personal project. It is not affiliated with, sponsored by or endorsed by any institution, employer or vendor, and it does not represent their views. Nothing here is legal advice. Consult your campus stakeholders, policies and counsel before acting on it.

Institutions, products and case studies are named because they have published accounts of their practice, not as endorsements. Discussion cases are hypothetical composites.

Keeping it current

Dated, sourced and versioned

Tools, models and law are changing quickly. Legal status is dated where it appears, claims link to their sources, and every release is recorded in the version history. This is version 1.0, published October 11, 2026.

How to cite

Referencing the guide

Campus AI Development. (2026). Building software with AI in higher education (Version 1.0). https://campusaidev.com

Contact

Corrections, examples and questions

Spotted an error, an out-of-date legal date, or a campus example that belongs here? Small or partial accounts are welcome. Write to joepsabado@gmail.com.

Related work: campusairegistry.com, campusdatagov.com, campusaiframework.com and campusaiexchange.com.