MEMORANDUM
DATE: April 20, 2026
TO: Vice Presidents, Deans, Department Heads, and Directors
FROM: Timothy Chester, Vice President for Information Technology
SUBJECT: Custom-Developed Applications and Generative AI Coding Tools
Generative AI tools have made it considerably easier to write functional code, and that capability has attracted real interest across campus. The prospect of staff-built software that addresses local needs quickly is understandably appealing. This memo describes the practical boundaries of that work as it relates to University of Georgia information policy, institutional responsibility, and UGA’s longer-term technology direction.
UGA’s approach to information technology is built on a framework articulated as Edge- Leverage-Trust. The principle is straightforward: scale what should scale and preserve flexibility where local innovation matters most. EITS manages shared infrastructure and enterprise systems because that is where standardization produces reliable, secure, cost-effective outcomes. Units manage local tools and workflows because that is where mission-specific needs require flexibility. The governance requirements described in this memo follow directly from that framework. They are not a constraint on local initiative; they are the boundary condition that makes local initiative sustainable.
A 15-Year Direction
The University has been moving away from staff-coded applications for roughly fifteen years. That direction was deliberate. Custom applications can align precisely with a unit’s immediate needs. Still, they carry persistent costs: they are harder to secure, harder to maintain, more difficult to integrate with other University systems, and they tend to fragment data in ways that undermine institutional analytics and reporting. Vendor-supported applications distribute those responsibilities to organizations with the scale and specialization to manage them sustainably. This does not mean units should not innovate locally. In a federated institution like UGA, edge innovation is expected and valued. Colleges and divisions use tools specific to their missions, configure platforms to fit their workflows, and experiment with approaches that EITS could not anticipate or serve at scale. That flexibility is a feature of the model, not a gap in it. What the 15-year direction reflects is a clear judgment about which category of work belongs where: local productivity and workflow improvements belong at the edge; systems that touch shared infrastructure, enterprise data, or broad institutional audiences belong in the Leverage layer, where governance and support capacity are matched to the responsibility.
Generative AI changes none of this. Tools like ChatGPT, Gemini, or Claude Code can produce working code more efficiently than a developer writing from scratch. Still, the resulting code has the same structural properties as any other custom code. It requires the same ongoing maintenance. It introduces the same integration challenges. It carries the same information security obligations. Speed of creation is not the same as the quality of the outcome, and the speed itself can introduce additional risk: code written quickly and reviewed lightly is more likely to surface problems under operational conditions. Amazon has experienced several significant outages across its cloud infrastructure in recent months attributable in part to AI-generated code that was deployed without sufficient review by human engineers. That pattern deserves attention.
My experience is that generative AI tools shift software developers from writing code to reviewing code. The productivity gain is often modest, and it comes with a corresponding increase in risk when the review function is not performed rigorously. Units should not assume that output from a generative AI tool is production-ready simply because it appears to work.
What Counts as a Custom Application
Several colleagues have asked where the line falls between a local productivity tool and a custom application subject to governance review. The question is fair, and clear boundaries are needed.
The practical test is whether a tool integrates with a Leverage service: a core enterprise system, shared identity infrastructure, the institutional data warehouse, or any platform that serves audiences beyond the unit that built it. Tools that do not touch those systems sit at the edge. They are the unit’s business, the unit’s responsibility, and entirely within the unit’s discretion to build, modify, or discontinue. A staff member using Claude to write a one-time data transformation script, a locally maintained Excel macro, or a workflow automation that operates entirely within a unit’s own environment does not require governance review. These are edge tools, and the federated model is designed to accommodate them.
Tools that do touch Leverage services are a different matter. A staff-coded application that pulls from the data warehouse, integrates with Banner or PeopleSoft, authenticates against UGA’s identity systems, or is offered to other units for their use crosses into territory where durability, security, integration integrity, and institutional continuity are at stake. That is where our Banner or PeopleSoft leadership teams come in. A useful secondary test is whether a solution introduces its own authentication, persistent data storage, a user interface intended for broad use, or system integrations with EITS-operated systems. When those characteristics are present, the tool has taken on the responsibilities of an application, not a local script or dashboard.
This distinction also addresses the question of BI tools and reporting dashboards. A dashboard that displays data a unit already has access to, without introducing new integrations or authentication layers, is an edge tool. A custom-coded dashboard that establishes its own live connection to an enterprise system, or that is distributed across units, is not.
University Policy Requirements
Regardless of how staff-coded software is developed, UGA’s information policies apply in full. Two requirements deserve specific attention for any initiative that uses University data.
First, any real-time integration between a custom application and the University’s core enterprise systems or data warehouse must be approved by the appropriate governance body, either the Banner leadership team or the PeopleSoft leadership team, depending on the system involved. This approval is required before integration is established, not after.
Second, data obtained from University systems for one approved purpose may not be redirected to a new application or initiative without approval from the appropriate data steward. This requirement applies when University data is being used in a new application context, not to every instance of a staff member working with data in the ordinary course of their responsibilities. The distinction matters: routine work with University data in approved systems is not the target of this requirement. The target is the repurposing of that data to feed a new tool or application without a separate authorization.
These are not new requirements, and they are not specific to AI-related development. They apply equally to applications built by professional developers and to applications built by staff using generative AI tools. For additional context on the University’s expectations around AI use more broadly, units should consult the UGA AI acceptable use guidelines available through the AI Hub at aihub.uga.edu.
Unit Responsibility and EITS’s Role
Several motivated teams across campus have developed tools that reduce administrative friction within their local operations. That kind of initiative reflects genuine effort, and some of it has delivered real value within its local scope. The relevant question is what happens when a unit considers extending such a tool beyond its original context, particularly to a broader or University-wide deployment.
Units that develop and operate custom applications bear complete responsibility for them. That responsibility includes development, ongoing maintenance, user communication, troubleshooting, security compliance, and continuity planning if the staff involved change roles or leave the University. EITS will not provide infrastructure hosting, operational management, or end-user support for staff-developed applications outside of what has been reviewed and approved through the Banner and PeopleSoft governance committees. This is not a refusal to engage with good ideas; it is a clear statement about where institutional responsibility resides. A unit that deploys a staff-coded application is operating and supporting that application.
Where EITS can and does play a consultative role is in helping units evaluate vendor solutions. As interest in AI-enabled administrative and student-facing tools grows, units are increasingly approached by vendors making significant efficiency claims. EITS can help units assess architectural fit, data governance implications, information security requirements, integration complexity, and total cost of ownership before a commitment is made. Early engagement in those conversations is genuinely useful and does not carry the support obligations that custom development does. Units considering vendor AI tools are encouraged to bring EITS into those discussions early.
A More Useful Frame for These Tools
Generative AI tools are genuinely capable, and the Edge-Leverage-Trust framework helps clarify where they add the most durable value. At the edge, these tools are well-suited to expanding individual and team productivity: drafting, research assistance, analysis, workflow automation within a unit’s own environment, and working through complex problems more efficiently. That work is appropriate, it is encouraged, and it does not require EITS involvement. This is the space where generative AI is likely to deliver its most consistent returns, and where our community will develop the fluency that informs better institutional decisions over time.
At the Leverage layer, the calculus changes. Generative AI tools are not a solution to institutional process problems, and the ease of building something should not be confused with the wisdom of deploying it at scale. Where a University process creates friction, the appropriate response is usually to examine and improve the process itself. Building a custom application on top of a poorly designed process does not resolve the problem; it adds a layer of complexity that the unit must then maintain, support, and eventually replace. The friction should be addressed at its source.
What I am more confident about is the longer arc. Higher education IT has been on roughly a 25-year trajectory away from building technology and toward helping people derive value from it. That shift was not arbitrary. The history of higher education institutions creating administrative technology for themselves is littered with expensive, high-profile failures. The successes have almost always come from leveraging platforms built by organizations whose entire business is building and scaling that technology across our industry. I do not see that changing. Vendors will continue to have scale advantages, and I would expect customers to see those gains reflected in pricing and feature velocity over time rather than in a fundamental shift away from vendor solutions. I want to hold that view with appropriate humility, because this space is moving fast. But the 20-year pattern is not nothing.
The threshold questions this memo raises, specifically what distinguishes edge tools from applications subject to governance, and what constitutes a use of University data that requires data steward approval, are actively being discussed across several stakeholder groups. The goal is clarity that supports local initiative within a framework that protects institutional integrity, not a set of constraints that discourages productive work.
These judgments are genuinely complex, and the line between a useful local tool and an institutional dependency that becomes a liability is not always obvious in advance. I am available to any decision-maker who would like to think through the specifics of a particular initiative before it moves forward.
