Your AI guidance policy (if you have one) is probably out of date: Key considerations for developing an institutional AI guidance policy – Artificial Intelligence for Research Administration

By Dashiell Tyler, AI4RA Program Manager, University of Idaho

Introduction

Artificial intelligence (AI) is rapidly evolving, and with it, strong guidance on how to use it safely is becoming essential. Through our work with the broader research administration (RA) community, our team has seen a growing need for clear guidance on how, when, and where AI can be used in RA work. With that guidance in place, RAs can use AI safely, keeping sensitive data in approved, secure tools, and confidently take advantage of the significant efficiency gains it has to offer. To support the safe and effective use of AI by RAs, we evaluated 20 institutions’ AI guidance policies (AIGP) to find the common threads between them and provide you with a checklist describing everything to be included in a strong AIGP. The purpose of this blog post is to showcase the considerations necessary to create an environment that ensures the safety of your institution’s data while you use the tools that maximize your effort. After all, at its core, AI guidance is just data guidance.

Our Team’s AIGP Review

We reviewed the AIGPs of 20 different institutions, ranging from principle statements to binding IT standards, and compared them using Anthropic’s Claude Opus 5.5 large language model (September 2026). The review included public and private institutions of varying sizes from across the United States. AI was used to compare them, describe their strictness level, and extract common themes. This evaluation was then used to create a checklist of important elements of a strong AIGP. Finally, every AIGP was then evaluated against the checklist for completeness. It was found that the most complete AIGP evaluated only contained 39 of the 61 items included on the checklist (64%), suggesting that most institutions likely have incomplete or out of date AIGPs.

Our review at a glance: 20 institutions’ AI guidance policies reviewed, public and private, across the U.S. The most complete policy covered only 39 of 61 checklist items, or 64 percent. How we analyzed them, in four steps: 1, AIGPs compared, a side-by-side review of 20 policies. 2, Strictness evaluated, each rated on the 5-level scale. 3, Checklist created, 61 items built from common themes. 4, Completeness checked, each policy scored against the checklist.

Types of AI Guidance

Guidance can take shape in a variety of ways, including physical guidance, technical guidance, and behavioral guidance. Each one speaks to AI usage from a different perspective, and each is an important consideration to ensure the safety of your data. Physical guidance refers to storage and access to equipment, including where to physically store data and GPUs. Technical guidance refers to controls built into data handling systems, accounts, and networks, such as model selection when deploying new tools. Behavioral guidance refers to rules people must follow, decisions they must make, and responsibilities they have, such as training people on what types of data can be entered into what systems.

A complete AIGP will contain guidance for all of these aspects, covering details on each of these areas for every component of the guidance policy. Failure to do so may result in unintentional data security risks. For example, if your policy requires you to state a specific tool’s data security level (technical) but fails to require training to identify what types of data exist at which levels (behavioral), users may fall out of compliance unintentionally by not recognizing the security level of the data they are using despite knowing the tool’s security level. A complete AIGP will prevent security risk so long as the user remains compliant with the stated requirements of the policy or guidance.

Three types of AI guidance. Physical: where data and equipment live, for example where to store data and GPUs. Technical: controls built into systems and networks, for example choosing the model a new tool uses. Behavioral: rules and duties people follow, for example training on which data goes in which tools.

AIGP Strictness

The strictness of an AIGP refers to the degree of rigor, inflexibility, and enforcement applied to the AIGP, as well as the amount of space the AIGP has for exceptions or interpretation. Strictness can be broadly represented at 5 different levels:

Strictness Level	Description	Example
Level 1: Guidance stated as general principles	State general values that apply to AI without explicitly mentioning it or mentioning it only in passing.	“Our use of AI will keep people, relationships and human judgment at the center of everything we do.”
Level 2: Guidance considered advisory	Mentions best practices when using AI and provides you with a few firm rules.	“Researchers should err on the side of disclosing any material use of generative AI and verify all outputs before relying on them.”
Level 3: Explicitly defined expectations	Provides you with specific data and disclosure rules, however, those rules are mostly self-enforced.	“Do not enter confidential or restricted data into AI tools and disclose AI use whenever it makes up more than 25% of a deliverable.”
Level 4: Explicit descriptions of controlled use	Provides you with approved-tool lists, rules for specific data risk levels, establishes review processes, and provides other controlled usage requirements.	“Moderate-risk data may be used only in the AI tools approved for that risk level, and any new tool must go through the AI risk assessment before use.”
Level 5: Strict guidance	Requires you to only use approved tools within an approved infrastructure and requires disclaimers or enforcement when not in compliance.	“Microsoft Copilot Chat is the only approved AI tool, and every AI-generated output must carry the disclaimer ‘This output was generated by artificial intelligence.’”

The strictness of an AIGP must be decided early in the drafting process. Different institutions may have more strict requirements depending on things like requirements for security compliance, IT approval processes, data storage requirements, and usage auditability.

Where Policies Diverge

Five choices where policies split. 1, Rules: general principles, flexible but relies on judgment, versus firm requirements, clear and enforceable but less flexible. 2, Tools: describe kinds of tools, so users vet tools themselves, versus name approved tools, so security specialists vet them. 3, Disclosure: encouraged only, easy to follow but inconsistent, versus required for any material use, the safest choice. 4, Scope: one office or unit, specific and easier to apply, versus whole institution, consistent protection everywhere. 5, Home: standalone AI policy, easier to review and update, versus part of data governance, fits the larger framework.

Each of the 20 AIGPs reviewed had differing design choices which caused them to fundamentally diverge. While these choices do not necessarily make the AIGP better or worse, they do impact it in many ways. First, some AIGPs were written as general principles while others were requirements. Using general principles makes the AIGP more open for interpretation, which makes it more flexible while also risking human judgement errors.

Second, many AIGPs approved or banned specific tools, while others only described what kinds of tools were allowed. Only describing what kinds of tools are approved without stating the tools explicitly places more responsibility on the user to vet the tools they use but allows more space for new tools to be incorporated into their workflows at will. Specifying allowed tools ensures your data security by placing the responsibility in the hands of security specialists.

Third, while all AIGPs mentioned disclosure of AI usage, the point at which that disclosure was required changed. Some required disclosure for any material use, some used a percentage threshold where the amount of content generated determined the point at which disclosure was necessary, some provided a required pre-drafted disclosure statement, and others only encouraged disclosure. Additionally, institutions varied in their consequences of failing to disclose, with some naming it as a core research integrity issue and labelling it as misconduct. It is typically safest to always disclose when using AI-generated material.

Fourth, the scope of the AIGP differed between institutions. Some developed policies specific to a single office or organization, while others made policies which covered the entire institution. Making your AIGP more specific helps to avoid ambiguity and eases the burden of the individual when interpreting its application. Using an institutional AIGP ensures the protection of your full institution and consistency across your institution.

Fifth, many institutions had a standalone AIGP, while others folded it into large data governance policies. A single, standalone policy will be easier to review and update as AI continues to develop, but incorporating it into a larger policy will ensure it fits within the larger governance framework.

Before you can start drafting an AIGP, you must consider these key foundational elements to define exactly how the policy is written. These design choices directly affect how the AIGP manifests, including its strictness, applicability, and interpretability. It is important for you to work with the office or unit responsible for institutional data security standards from the beginning of the drafting process to ensure the AIGP fits within your larger institutional governance framework.

10 Sections of a Strong AIGP

A strong AIGP will mention every item listed below, ideally considering the physical, technical, and behavioral components of each one.

Section	Description	Purpose
Governance and scope	Who owns the policy, who and what it covers, and how it connects to existing policies and legal mandates.	This section makes sure the tools people use have been checked for security, privacy, and contract risks before institutional data goes into them.
Tools and procurement	Which AI tools are approved, for what kinds of data, and how new tools get requested, vetted and contracted.	This section makes sure the tools people use have been checked for security, privacy, and contract risks before institutional data goes into them.
Data protection	What information may and may not go into AI tools, based on the institution’s data classification, plus how exceptions are approved and accidental disclosures reported.	This section keeps sensitive and regulated data from leaving the institution’s control through AI use.
Disclosure and attribution	When and how people must acknowledge AI use in their work, including what the disclosure says and where it appears.	This section keeps AI’s contribution visible, so readers, reviewers, and sponsors can judge the work accurately.
Human oversight and accountability	A description of how people remain responsible for anything AI produces and must review it for accuracy and bias before using it.	This section makes sure a person, not a tool, answers for every outcome.
Research integrity	How AI use fits with existing standards for honest research, including authorship, misconduct and record-keeping.	This section protects the trustworthiness of research by making clear that AI-assisted errors or fabrication carry the same consequences as any other.
Research and sponsored programs	Rules for AI in proposals, awards and compliance, such as who certifies AI-assisted proposal content and whether AI can be used in peer review.	This section keeps AI use within sponsor requirements and protects confidential proposal and research administration information.
Special uses	Rules for AI applications with distinct risks, such as meeting recorders, AI agents that act on their own, agentic coding, copyrighted material, and accessibility.	This section covers situations that the general rules don’t handle well on their own.
Training and communication	How the institution builds AI literacy and makes the rules easy to find, through training, a central information page, and a named contact.	This section makes sure people know the policy exists, understand it, and know where to get help.
Maintenance	How the policy stays current through scheduled reviews, version tracking, community feedback, and periodic re-review of approved vendors.	This section keeps the policy from going out of date as AI tools and regulations change.

Conclusion

For research administrators, these gaps are not abstract. The proposals, budgets, award documents, and compliance records you handle every day are exactly the kind of data an AIGP is meant to protect. Yet research and sponsored programs were one of the weakest areas in our review: on average, policies addressed only 16% of the items in our AI Guidance Policy Checklist. When a policy is silent on these questions, you are left to make judgment calls on your own, often under deadline pressure and potentially subjecting your institution to major data security risk. Use our provided checklist to see where your institution’s AIGP stands then bring the gaps to your sponsored programs of leadership, information security office, and Research Integrity Officer. RAs are well placed to lead this conversation, because you already translate sponsor rules and institutional policy into daily practice. A strong AIGP is simply the next set of rules that lets you do that work safely and efficiently.

What you can do now. Step 1, Check: compare your institution’s policy to the checklist in this post. Step 2, Find the gaps: note what’s missing, especially research and sponsored programs items. Step 3, Bring them forward: share the gaps with your sponsored programs office, leadership, information security office, and Research Integrity Officer.

AI Guidance Policy Checklist

Download checklist

Important foundational decisions

Each item below directly impacts a policy’s strictness, applicability, and interpretability. Consider each item carefully and deliberately carry your decision throughout the details and language you use in your policy.

Required or recommended: decide whether people must follow the document (a formal policy or standard) or whether it only offers advice (principles or guidance). Advice is easier to update as AI changes; required rules can be enforced when broken.
Home of the rules: a standalone AI policy, AI clauses added to existing policies, or a crosswalk that maps each existing policy to AI
Scope model: one institution-wide policy, separate policies by function, or a system framework with campus policies
Tool model: a single approved tool, a tool-by-data-risk matrix, or a “use vetted tools” principle
Disclosure model: any material use, a percentage threshold, required wording, or encouraged only
Enforcement: consequences for violations and whether AI use is monitored
Research integrity stance: whether the misconduct policy names AI explicitly or relies on existing definitions

Name an owner office and a standing review group
Define who is covered: faculty, staff, students, contractors, affiliates
List which functions are covered, following the scope model: administration, teaching, research, or all
Define AI terms, including generative and agentic AI
Map existing policies that already apply: data classification, acceptable use, privacy, IP, misconduct
Check federal, state, sponsor, and system mandates, such as executive orders, system directives, and institutional governance.

Publish the approved tools that follow from the tool model, and where to find them
State which data risk level each tool is approved for
Set a request process for new tools, with a named form
Require security and privacy review for AI vendors, such as HECVAT or SOC 2 Type II
Require contract terms that bar training on institutional data and set retention and breach notice
Cover AI features added to software already in use
Decide on named bans
Require institutional accounts for university work

Link AI rules to the existing data classification tiers
State plainly which data may never go into AI tools, such as SSNs, PHI and FERPA protected data
Set an approval path for exceptions, naming who signs off
Require data minimization and synthetic data for testing
Require data-owner consent before sharing non-public data
Say how to report an accidental disclosure

Say what a disclosure includes: tool, version, purpose, extent, date
Say where the disclosure goes: acknowledgments, methods section, a footnote, or an internal note to a manager
State that spelling and grammar help needs no disclosure, if so
Point to citation style guidance

Clarify that the PI certifies AI-assisted proposal content; research administration staff cannot
Prohibit AI in confidential peer review of proposals, in line with NIH and NSF notices
Require checking sponsor and publisher AI rules
Route human-subjects and clinical data through IRB
Address controlled data: HIPAA, FERPA, Common Rule, export control
Decide whether AI tool costs may be charged to awards
Set a review step before research administration records enter an AI workflow

Meeting AI: require participant notice and consent, or ban unapproved note-takers
Agentic AI: no credentials to institutional systems, sandbox testing, limits on actions
Intellectual property: check tool terms for output ownership; no uploads of others’ copyrighted work
Accessibility: AI outputs must meet accessibility policy

Offer AI literacy training, and decide whether it is required or annual
Publish one central page for tools, rules and contacts
Name a contact for questions and incidents

Set a review date and cycle for the policy
Label it a living document and track versions
Collect community feedback before finalizing
Re-review approved vendors on a schedule