UMSN Faculty AI Reference Guide

Audience: University of Michigan School of Nursing (UMSN) faculty, researchers, instructors, and project teams

This guide explains how to evaluate the use of institutional data with U-M artificial intelligence services and when to consult the Institutional Review Boards (IRBs), Information Assurance (IA), Privacy, Procurement Services, or other U-M compliance offices.

Quick decision guide

1. Identify the activity. Is the work research, teaching, clinical care, quality improvement, administration, or software development?
2. Classify the data before entering it. Determine whether the material includes public, internal, sensitive, regulated, or restricted information.
3. Confirm that the specific AI service and model are approved. Approval can differ by service, model, feature, integration, and data type.
4. Check whether an existing protocol, agreement, consent form, or notice permits the use. AI use must remain consistent with IRB directives, participant consent, data use agreements, contracts, privacy notices, and sponsor requirements, and applicable law.
5. Engage the appropriate U-M office before use when a trigger below applies.
6. Use the minimum necessary data. Remove identifiers and unnecessary details, limit access, verify outputs, and follow applicable retention requirements.

U-M AI services

U-M GPT

U-M GPT provides eligible faculty, staff, and students with access to multiple generative AI models. U-M GPT offers institutional privacy and security protections that are not necessarily available in public or individually purchased AI accounts.

• Use only models and features approved for the applicable data classification.
• Do not assume that approval for one model applies to every model available through U-M GPT.
• PHI may be used only in a U-M GPT model and workflow explicitly approved for PHI and only when all HIPAA, institutional, access-control, and minimum-necessary requirements are satisfied.
• Users remain responsible for verifying output, protecting data, and complying with research, clinical, educational, and administrative requirements.

See Artificial intelligence services from U-M Information and Technology Services.

U-M Maizey

U-M Maizey allows users to create AI experiences grounded in selected datasets. Before adding institutional content, dataset owners should evaluate the classification of the source material, user access, copyright and licensing, retention, and whether the collection contains regulated data.

See U-M Maizey in depth.

U-M GPT Toolkit

U-M GPT Toolkit provides API-based access for application development, automated workflows, and large-scale analysis. API use may create additional security, architecture, logging, access-control, and cost considerations.

Consult IA or the appropriate IT security contact before using Toolkit when a workflow:

• Processes sensitive or regulated data;
• Connects to another U-M or external system;
• Stores prompts, responses, embeddings, logs, or uploaded files;
• Uses service accounts, API keys, or automated agents;
• Provides AI output to patients, students, research participants, or the public; or
• Could materially affect clinical, academic, employment, or administrative decisions.

See U-M GPT Toolkit. Toolkit usage has associated costs.

Using institutional data

Institutional data include information created, received, maintained, transmitted, or used by U-M. Examples include student records, research data, patient information, personnel records, internal reports, unpublished course material, contracts, financial information, credentials, and licensed content.

De-identification does not automatically resolve every requirement

Removing names may not make a dataset anonymous. Dates, locations, clinical details, rare diagnoses, free-text narratives, images, device identifiers, and combinations of variables can identify a person. Coded data may also remain identifiable when a team retains a key.

• HIPAA de-identification requires an approved method; it is not achieved merely by deleting names.
• IRB requirements may continue to apply to coded or de-identified research data.
• A data use agreement, consent form, sponsor condition, or contract may prohibit AI processing even when direct identifiers are removed.
• Do not ask an AI model to perform the initial de-identification unless the model is approved to receive the original identifiable data.

When to engage U-M compliance and service offices

Research scenarios

Analyzing interview transcripts

Confirm that the IRB protocol, consent documents, data management plan, and any data use agreement permit AI-assisted analysis. If transcripts contain identifiers, use only a service explicitly approved for that data. An amendment may be needed if AI analysis was not included in the approved protocol.

Drafting a manuscript or grant

Public or nonconfidential text is generally lower risk. Do not enter unpublished participant data, confidential peer-review material, sponsor-confidential information, or proprietary findings unless the service and workflow are approved. Verify citations because AI systems can generate nonexistent or inaccurate sources.

Creating synthetic data

Synthetic data can still expose source information or preserve identifying patterns. If identifiable or regulated data are used to generate the synthetic dataset, the source-data requirements still apply. Document the generation method and evaluate disclosure risk before sharing.

Building a research chatbot or participant-facing agent

Consult the IRB and IA before deployment. Address consent, safety monitoring, accessibility, data collection, retention, escalation to a human, model limitations, and how adverse events or inappropriate responses will be handled.

Teaching scenarios

• Course preparation: Faculty may use approved AI services to draft learning objectives, examples, or rubrics, but should verify accuracy, bias, copyright, and alignment with course standards.
• Student work: Do not upload identifiable student work, grades, accommodations, or advising information unless the service is approved for the information and the use is consistent with FERPA and course expectations.
• Grading: AI should not be the sole basis for a grade or high-impact academic decision. Faculty remain responsible for evaluation and should consider transparency, consistency, accessibility, and opportunities for human review.
• Clinical education: Remove patient information from case discussions unless the selected service is explicitly approved for PHI and the use is otherwise authorized. A fictionalized case must not contain a combination of details that identifies a real patient.
• Required student use: Check accessibility, privacy, cost, account requirements, and availability of an equivalent alternative before requiring an AI tool.

Minimum safeguards

• Use the least sensitive and smallest amount of data needed.
• Do not include passwords, API keys, authentication tokens, or private encryption keys.
• Verify that recipients are authorized to view both the input and output.
• Review model and feature settings, including file retention, sharing, connectors, plug-ins, and conversation history.
• Do not rely on AI output as authoritative without qualified human review.
• Check factual claims, calculations, quotations, references, and clinical content.
• Evaluate outputs for bias, stereotyping, fabricated information, and disclosure of sensitive information.
• Document consequential uses, including the model or service used, human review, and validation steps.
• Follow records-retention, litigation-hold, research-record, and data-deletion requirements.
• Report suspected data exposure or security incidents promptly.

Information to provide when requesting a review

Preparing the following information can help the reviewing office respond efficiently:

• Name and web address of the AI service, model, plug-in, or vendor;
• Purpose of the activity and intended users;
• Whether the activity is research, clinical care, teaching, quality improvement, or administration;
• Types and classifications of data involved;
• Whether the data contain direct identifiers, codes, free text, images, audio, or video;
• Where data, prompts, files, embeddings, logs, and outputs are stored;
• Who can access the data and output;
• Whether information will leave U-M systems or be accessible outside the United States;
• Vendor retention, deletion, and model-training practices;
• Relevant IRB protocol, contract, consent form, data use agreement, or sponsor terms;
• How outputs will be reviewed, validated, and corrected; and
• Whether the output will affect patients, students, employees, or research participants.

Authoritative U-M resources

• U-M Information and Technology Services: Artificial intelligence
• U-M Maizey in depth
• U-M GPT Toolkit
• U-M Sensitive Data Guide
• Safe Computing and Information Assurance
• U-M Privacy
• U-M Institutional Review Boards
• U-M Export Controls
• U-M Procurement Services
• U-M accessibility resources
• U-M records management

Disclaimer

This guide supports preliminary decision-making and does not replace an IRB determination, security review, privacy review, procurement process, legal advice, contractual review, or Michigan Medicine policy. Requirements can change as services and models are updated. When guidance conflicts, follow the more restrictive requirement and consult the responsible U-M office.

---