From the Campus Operations edition of November 4, 2026
ASU Engineering issues a five-step data check for staff and faculty before using university data in AI tools
Arizona State University, Ira A. Fulton Schools of Engineering (In the Loop) · Higher education IT governance and data security · Arizona, United States
- Publisher
- In the Loop (ASU Engineering internal news)
- Original publication
- 4 November 2026 (In the Loop, ASU Engineering)
- Source retrieved
- 2026-11-05
- Event date
- 2026-11-04
What happened
ASU Engineering's 4 November staff and faculty guidance says to classify data with the ASU Data Classification Tool first, use only tools listed at ai.asu.edu that have cleared vendor risk review for general business and FERPA-regulated data, sign in with ASURITE because approval follows the access path (ChatGPT Edu approved, public version not), note that FERPA approval does not cover all regulated data, and follow the Digital Trust Guidelines.
Why it matters
Shows a large public university running operations AI on data classification, a vetted tool list and SSO-based approval.
Evidence and measured results
Primary institutional guidance; describes controls, not measured compliance or incidents.
Limitations and uncertainty
Guidance only; no adoption, compliance or incident data; school-level post restating university rules.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-11-04; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Staff use the same AI brands through consumer and enterprise accounts with different data permissions.
- Stakeholders
- CISO
- Privacy officer
- CIO
- School IT leads
- Discovery questions
- Is there a published approved-tool list tied to data classes?
- Can consumer AI sign-ins be distinguished from enterprise?
- How is regulated non-FERPA data handled?
- Value hypothesis
- A clear data-class-to-tool map may reduce accidental exposure; ASU reports no measured effect.
- Potential engagement
- A bounded data-class and approved-AI-tool mapping and enforcement review.
- Unsupported claims
- Reduced incidents
- Staff compliance rates
- Equivalence of FERPA and HIPAA approval
Pre-sales engineering
Role takeaway
- Fit
- Institutions with enterprise AI licences alongside consumer use.
- Architecture and integration
- Classification tool plus approved-tool catalogue plus SSO tenant sign-in.
- Prerequisites
- Data classification scheme
- Vendor risk review process
- Enterprise SSO for AI tools
- Constraints
- FERPA approval does not cover all regulated data
- Consumer accounts outside institutional control
- Security
- Enforce tenant sign-in and DLP by label; review connected apps and agents.
- Proof of value
- Measure share of AI traffic via approved tenants
- Test DLP blocks for regulated data classes
Delivery
Role takeaway
- Work
- Operationalize the five-step check across onboarding and tool requests.
- Dependencies
- Central IT security
- Privacy office
- School communications
- Ownership
- ASU central IT and information security, with schools reinforcing.
- Skills and adoption
- Short training on classification before AI use.
- Governance checkpoints
- Vendor risk review before listing
- Per-use approval for regulated data
- Acceptance criteria
- Proposed: published data-class-to-tool matrix
- Proposed: quarterly approved-list review
- Proposed: tracked staff attestation rate
- Risks
- Staff skip classification
- Shadow AI via personal accounts
- Connected apps exceed tool approval
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
Approval is tied to the identity path (SSO tenant), so consumer and enterprise versions of the same model are treated differently.
Governance
Who approves, reviews and stays accountable for outcomes?
Vendor risk review feeds a published approved-tool list; regulated data needs approval for each use.
Security and privacy
What data, permissions and controls need testing?
Data classification determines protection, so FERPA approval does not cover HIPAA or other regulated data.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Puts the classification step on each employee; training and checking that people follow it are not described.
Procurement
What should contracts, pricing and exit terms secure?
Tools reach the approved list only after vendor risk review, which links procurement to permitted data use.
Operating model
Which teams own the service once it runs?
Central approved-tools catalogue with local reminders through school communications.
Publication history
- 2026-11-04Campus Operations · Issue 572 resources
Stable resource ID: asu-engineering-ai-data-classification-approved-tool-checklist-20261104