Recently, a colleague told me his institution’s university-wide ChatGPT license might not survive another budget cycle. I was not surprised. He knew I had always questioned the value of blanket AI licenses. The cost is substantial, the market remains unsettled, and I have been reluctant to extend the startup model providers the same trust that comes from an established institutional agreement with companies like Microsoft, Oracle, or Google. We had talked through those differences before.
Still, skepticism is not a strategy. Universities need a practical answer for those who already use personally licensed AI in their day-to-day work. As I work with others to develop an AI strategy at my new institution, I keep returning to one simple principle: data protection should correlate with the consequence of disclosure. Data classification gives us a way to translate that principle into everyday judgment.
In today’s Dispatch, I want to use that framework to consider when personally licensed AI is appropriate for university work, when an institutionally licensed tool is required, and when data should not enter a cloud-based AI service at all.
The big picture
Most universities are answering the wrong question about AI. They ask which tools to allow. The more useful question is which data may go where.
Universities tend to take one of two positions on personally licensed AI use. The first treats it as a risk to be banned. Prohibition rarely stops the behavior; it drives use underground, out of the institution’s view and beyond its governance. The second accepts the use because people are already relying on these tools, but offers little guidance about what information belongs in them. One position prohibits without distinction; the other permits without boundaries. Neither helps users distinguish between an ordinary draft and data whose disclosure would create real harm.
Universities should stop writing AI rules around tool adoption and start writing them around data classification. In “Everyone’s Using GenAI, Few Admit It,” I argued that concealment is not primarily a technology problem. A 2025 KPMG and University of Melbourne survey of 48,000 workers found that 57 percent hide their AI use at work. Concealment on that scale is not adequately explained as individual rule-breaking. It is also a structural response to rules people find difficult to understand or apply.
Classify the Data, Not the Tool
The instinct is to sort AI tools into two bins: personal accounts that are risky and university licenses that are safe. A personal tool is not inherently unsafe. What matters is the data placed into it and the terms under which the provider uses that data. A university-licensed tool is appropriate for more sensitive information because of its contract and data-processing terms, not because the university paid for it.
The right bin depends on the data's classification, the consequence of disclosure, and the contract governing the service. One rule holds it together: protection standards should rise with the consequence of disclosure. Public and ordinary university data can go into either type of environment. Sensitive data belongs only in a service the university has under contract. Restricted data belongs inside a controlled system.
Public data is what the institution has already released to anyone: websites, catalogs, adopted policies. If anyone can obtain it easily, the institution gains little by dictating which AI reads it. Personally licensed AI is appropriate.
University data is ordinary internal working material that is neither published nor regulated: drafts, plans, routine correspondence, analysis. Personally licensed AI can be acceptable here. Most of this could be released under an open-records request. Its disclosure may create embarrassment or operational difficulty, but not the consequences associated with losing a regulated record. But not every internal file is ordinary. Personnel matters, privileged communication, identifiable survey responses, and procurement material may belong in a tier higher regardless of disclosure requirements. This is also where my own practice has become more conservative than this framework strictly requires.
Sensitive data is covered by statute, regulation, contract, or policy: FERPA records, HIPAA-regulated information, identifiable human-subject research. It belongs only in an approved university environment governed by contract, including appropriate restrictions on retention, disclosure, and model training. The dividing line is not free versus paid but personal terms versus institutional protection. A paid personal subscription does not provide those institutional protections: no contract, no audit rights, no enforceable controls. Holding the license is not the end of it. Even inside an approved environment, local policy and the principle of data minimization still govern what should be disclosed.
Restricted data is high-value information whose disclosure can trigger a breach notification and remediation: Social Security numbers, financial account information, authentication secrets, or controlled research data. A university license does not clear it for a general cloud AI service. It belongs in a local model, a secure enclave, or another approved architecture that contains it. Some data can be protected by contract. Restricted data requires a protected architecture.
The framework is best understood as four simple principles:
Public: personal or university AI is appropriate.
University: personal or university AI, with discretion.
Sensitive: approved university-licensed AI only.
Restricted: local model, secure enclave, or other approved architecture.
Drawing these lines is the easy part. Two common institutional responses fall short: licensing and mandating a single tool, as if standardizing the tool settled what data belongs where; and routing every use through someone for approval, as if a gate best replaces human judgment. Neither teaches people to classify the data in front of them and use the right tool accordingly. Only that education moves governance forward, and only if the policies and guidance are simple enough to remember and apply.
Where My Own Practice Changed
This framework permits me to use a personally licensed AI tool with ordinary university data. Increasingly, I choose not to. The reason has less to do with model quality than with where my personal and institutional context already resides.
Recently, I needed to prepare for a meeting on a complex subject. The relevant material was scattered across email, OneDrive files, file attachments, and earlier exchanges I only partly remembered. I could have collected those materials and uploaded them to a personal AI service. Instead, I asked Microsoft Copilot to examine the information already available across my Office 365 account and prepare a briefing.
It did the work well, but the quality of the summary was not what changed my prior thinking about Copilot. The personal context was already there. Months of email, attachments, drafts, and earlier decisions had accumulated inside systems where the university already stored and governed its work. Copilot could use the portions of that record I was authorized to access without requiring me to find the relevant materials, download them, and upload them to ChatGPT or Claude.
That was more than a convenience. Moving the same information into a personally licensed AI tool would require me to decide what to transfer and whether the university had accepted the terms under which that service would receive it. I would be taking information out of an established institutional relationship and placing it into a personal one. Copilot made the accumulated context useful without requiring me to reconstruct the university’s contractual and technical boundaries around it.
My university already has a data-processing agreement with Microsoft governing the material stored in Exchange, OneDrive, and SharePoint. Connecting a personally licensed service to those systems would place university data within a relationship the institution didn’t choose or negotiate. The Microsoft contract does not eliminate risk. It does establish obligations, institutional authority, and recourse that a personal subscription cannot provide. Copilot is now my go-to for university or sensitive data.
Why Copilot Deserves Another Look
In my 2025 comparison of Copilot, ChatGPT, and Gemini, I described Copilot as enterprise-grade but underwhelming. Microsoft offered strong institutional privacy protections, but the product itself suffered from weak personalization, restrictive file handling, and an experience that felt designed more for corporate use than for higher education users. That assessment was once fair. The product has gotten much better.
Microsoft has since moved Copilot toward a multi-model platform, with Anthropic models joining OpenAI models within the Microsoft environment. This changes the institutional calculation. A professional Copilot license is no longer simply a bet on a single Microsoft-selected model. The university can gain access to different models while preserving the contractual protections and administrative controls of the Microsoft relationship. Memory and custom instructions also make Copilot better suited to sustained, personalized work, though those capabilities remain subject to licensing, institutional configuration, and ongoing product maturity.
This returns me to an argument I have made about Apple. Apple is trying to keep the personal context close to the device. Microsoft is building the enterprise counterpart, keeping the user’s work context inside the cloud environment that already holds the email, files, permissions, and accumulated record of institutional work. The architectures are different, but the governing principle is the same. Useful AI depends on context. Trust depends on where that context is best allowed to reside.
The final word
Copilot’s progress does not remove the need for sound data governance. Because it works with existing permissions, it can make institutional oversharing easier to discover and use. That is not an argument against Copilot. It is a reminder that a capable AI tool inherits the strengths and weaknesses of the environment around it.
But good data governance cannot be reduced to controls, tollgates, or a hierarchy of approvals. Most decisions about data are made by users in the ordinary flow of work, when they collect, share, analyze, store, or place information into an AI tool. No technical control can anticipate every circumstance. Institutions must give people simple principles, teach them to assess the risks associated with different types of data, and empower them to apply proportionate protection while minimizing what they collect and disclose. Sound judgment is not a substitute for governance. It is what good governance should produce: a community prepared to recognize risk and act responsibly without routing every decision through a central authority.
Universities need boundaries that reflect the consequences of disclosure, not one rule for every tool or a single tool. Personally licensed AI still has a place. Sensitive data requires institutional protection; Restricted data requires architectural containment. The best policy develops the judgment people need to know where each kind of work belongs. And when that work depends on the accumulated context of the institution, Microsoft Copilot has become a far more credible default than I once believed.
Really enjoyed this piece, Tim, especially your reconciliation with Copilot. Its proprietary access to the Microsoft Graph is unparalleled and the fact that the harness and the models are becoming increasingly capable has been encouraging to me. I was also a very early adopter of Copilot Cowork which I would have described at the time as unusable slop. I was quite impressed with the evolution of the product by the time it became GA and how capable it is-- again, working against the MS Graph in particular.
Interesting and thoughtful dive on an important topic. I appreciate reading that Copilot is getting better in your estimation - that has been a major factor limiting wider adoption. Also, the 'my work is spying on me' thing. And, like you, I suspect bans would drive most users underground. Some combination of disclosures, trainings, and bifurcation of which data go into which tools is probably with thinking about.