Reusable AI capability
Evaluate Educational AI Procurement and Student Data Risk
Evaluate an educational AI acquisition against learning need, vendor evidence, accessibility, student-data controls, security, equity, total cost, lock-in, and accountable approval requirements.
This Skill packages a reusable way to use the linked Prompt or Workflow; Amo.ng does not run it for you.
# Evaluate Educational AI Procurement and Student Data Risk Skill ID: AMO-S-000036 Skill URL: https://amo.ng/skills/evaluate-educational-ai-procurement-student-data-risk Purpose: Give academic, procurement, privacy, security, accessibility, finance, and technology owners a reusable education-specific decision gate for acquisition, renewal, conditional pilot, further due diligence, or rejection. Required inputs: - Learning need, affected students and staff, intended outcomes, baseline, proposed use, and viable non-AI or existing-service alternatives. - Vendor proposal, claims, architecture, contracts, data-processing terms, support model, prices, and independent evidence. - Student and staff data flows, model use, subprocessors, residency, retention, deletion, export, consent or lawful-basis context, and incident arrangements. - Accessibility, safeguarding, security, identity, permissions, auditability, inclusion, and equity evidence for actual delivery modes. - Implementation, integration, training, review, remediation, migration, exit, and continuity costs and constraints. - Named academic, procurement, finance, privacy, security, accessibility, legal, budget, and institutional decision owners. How to use: When to use: - Before acquiring, renewing, piloting, or materially expanding an AI service used in teaching, learning, assessment, student support, or educational administration. - When student-data handling, accessibility, evidence of educational benefit, or institutional authority affects the decision. - When a team needs a traceable gate rather than an unstructured vendor comparison. When not to use: - Do not use as a generic procurement-intake checklist when the education, student-data, accessibility, and learning-outcome decision is out of scope. - Do not treat it as legal, privacy, security, accessibility, procurement, or financial certification. - Do not paste restricted contracts, identifiable education records, credentials, or confidential vendor evidence into an unauthorized assistant. Instructions: 1. Define the educational problem, affected users, learning outcome, baseline, minimum benefit, alternatives, exclusions, and decision owner. 2. Decompose vendor statements into checkable claims and classify supplied support by source authority, independence, currency, scope, contradiction, and missing evidence. 3. Trace student, staff, research, and institutional data from collection through model use, human and vendor access, telemetry, retention, secondary use, export, deletion, incident response, and exit. 4. Assess accessibility, safeguarding, security, identity, permissions, inclusion, equity, interoperability, support, and change-notification evidence in the real delivery context. 5. Normalize implementation, integration, licences, usage, training, review burden, remediation, migration, continuity, and exit costs. 6. Compare Do not acquire, Further evidence, Bounded pilot, Conditional procurement, and Proceed to accountable approvals. Define conditions, stop criteria, expiry, and review dates. 7. Route each unresolved issue and consequential decision to its named institutional owner. Preserve dissent and conflicting evidence. Expected output: An educational need and alternative statement, claim-evidence register, student-data lifecycle map, accessibility/privacy/security/equity control matrix, total-cost and exit scenarios, evidence requests, bounded gate recommendation, required approvals, and decision-record template. Constraints and boundaries: - Never invent vendor capabilities, certifications, legal requirements, data locations, retention periods, test results, prices, approvals, or accessibility findings. - Treat questionnaires and assurances as claims until their evidence and scope are established. - Prefer aggregated, synthetic, or minimized examples; identifiable student data requires documented necessity, approved handling, and accountable authorization. - Final procurement, legal, privacy, security, accessibility, academic, financial, and budget decisions remain with the responsible officers. Powered by Prompt: Educational AI Procurement and Student Data Decision Gate Source ID: AMO-P-000337 https://amo.ng/prompts/educational-ai-procurement-student-data-decision-gate Completion criteria: Complete when the learning need and alternatives are explicit; material vendor claims have current evidence status; student-data flows, model use, retention, deletion, and exit are mapped; accessibility, privacy, security, safeguarding, equity, cost, and lock-in gaps have owners; and every required approver and stop condition is named. Otherwise return a provisional gate with targeted evidence requests. Use this Amo.ng Skill with your preferred AI tool. Supply the required inputs and follow the usage instructions. # Evaluate Educational AI Procurement and Student Data Risk Skill ID: AMO-S-000036 Skill URL: https://amo.ng/skills/evaluate-educational-ai-procurement-student-data-risk Purpose: Give academic, procurement, privacy, security, accessibility, finance, and technology owners a reusable education-specific decision gate for acquisition, renewal, conditional pilot, further due diligence, or rejection. Required inputs: - Learning need, affected students and staff, intended outcomes, baseline, proposed use, and viable non-AI or existing-service alternatives. - Vendor proposal, claims, architecture, contracts, data-processing terms, support model, prices, and independent evidence. - Student and staff data flows, model use, subprocessors, residency, retention, deletion, export, consent or lawful-basis context, and incident arrangements. - Accessibility, safeguarding, security, identity, permissions, auditability, inclusion, and equity evidence for actual delivery modes. - Implementation, integration, training, review, remediation, migration, exit, and continuity costs and constraints. - Named academic, procurement, finance, privacy, security, accessibility, legal, budget, and institutional decision owners. How to use: When to use: - Before acquiring, renewing, piloting, or materially expanding an AI service used in teaching, learning, assessment, student support, or educational administration. - When student-data handling, accessibility, evidence of educational benefit, or institutional authority affects the decision. - When a team needs a traceable gate rather than an unstructured vendor comparison. When not to use: - Do not use as a generic procurement-intake checklist when the education, student-data, accessibility, and learning-outcome decision is out of scope. - Do not treat it as legal, privacy, security, accessibility, procurement, or financial certification. - Do not paste restricted contracts, identifiable education records, credentials, or confidential vendor evidence into an unauthorized assistant. Instructions: 1. Define the educational problem, affected users, learning outcome, baseline, minimum benefit, alternatives, exclusions, and decision owner. 2. Decompose vendor statements into checkable claims and classify supplied support by source authority, independence, currency, scope, contradiction, and missing evidence. 3. Trace student, staff, research, and institutional data from collection through model use, human and vendor access, telemetry, retention, secondary use, export, deletion, incident response, and exit. 4. Assess accessibility, safeguarding, security, identity, permissions, inclusion, equity, interoperability, support, and change-notification evidence in the real delivery context. 5. Normalize implementation, integration, licences, usage, training, review burden, remediation, migration, continuity, and exit costs. 6. Compare Do not acquire, Further evidence, Bounded pilot, Conditional procurement, and Proceed to accountable approvals. Define conditions, stop criteria, expiry, and review dates. 7. Route each unresolved issue and consequential decision to its named institutional owner. Preserve dissent and conflicting evidence. Expected output: An educational need and alternative statement, claim-evidence register, student-data lifecycle map, accessibility/privacy/security/equity control matrix, total-cost and exit scenarios, evidence requests, bounded gate recommendation, required approvals, and decision-record template. Constraints and boundaries: - Never invent vendor capabilities, certifications, legal requirements, data locations, retention periods, test results, prices, approvals, or accessibility findings. - Treat questionnaires and assurances as claims until their evidence and scope are established. - Prefer aggregated, synthetic, or minimized examples; identifiable student data requires documented necessity, approved handling, and accountable authorization. - Final procurement, legal, privacy, security, accessibility, academic, financial, and budget decisions remain with the responsible officers. Powered by Prompt: Educational AI Procurement and Student Data Decision Gate Source ID: AMO-P-000337 https://amo.ng/prompts/educational-ai-procurement-student-data-decision-gate Completion criteria: Complete when the learning need and alternatives are explicit; material vendor claims have current evidence status; student-data flows, model use, retention, deletion, and exit are mapped; accessibility, privacy, security, safeguarding, equity, cost, and lock-in gaps have owners; and every required approver and stop condition is named. Otherwise return a provisional gate with targeted evidence requests.Copy skill copies the Skill details. Use with AI adds a short instruction for your preferred AI tool; neither action runs the Skill.
Purpose
Give academic, procurement, privacy, security, accessibility, finance, and technology owners a reusable education-specific decision gate for acquisition, renewal, conditional pilot, further due diligence, or rejection.
Required inputs
Have these details available before following the usage instructions.
- Learning need, affected students and staff, intended outcomes, baseline, proposed use, and viable non-AI or existing-service alternatives.
- Vendor proposal, claims, architecture, contracts, data-processing terms, support model, prices, and independent evidence.
- Student and staff data flows, model use, subprocessors, residency, retention, deletion, export, consent or lawful-basis context, and incident arrangements.
- Accessibility, safeguarding, security, identity, permissions, auditability, inclusion, and equity evidence for actual delivery modes.
- Implementation, integration, training, review, remediation, migration, exit, and continuity costs and constraints.
- Named academic, procurement, finance, privacy, security, accessibility, legal, budget, and institutional decision owners.
How to use this Skill
When to use:
- Before acquiring, renewing, piloting, or materially expanding an AI service used in teaching, learning, assessment, student support, or educational administration.
- When student-data handling, accessibility, evidence of educational benefit, or institutional authority affects the decision.
- When a team needs a traceable gate rather than an unstructured vendor comparison.
When not to use:
- Do not use as a generic procurement-intake checklist when the education, student-data, accessibility, and learning-outcome decision is out of scope.
- Do not treat it as legal, privacy, security, accessibility, procurement, or financial certification.
- Do not paste restricted contracts, identifiable education records, credentials, or confidential vendor evidence into an unauthorized assistant.
Instructions:
1. Define the educational problem, affected users, learning outcome, baseline, minimum benefit, alternatives, exclusions, and decision owner.
2. Decompose vendor statements into checkable claims and classify supplied support by source authority, independence, currency, scope, contradiction, and missing evidence.
3. Trace student, staff, research, and institutional data from collection through model use, human and vendor access, telemetry, retention, secondary use, export, deletion, incident response, and exit.
4. Assess accessibility, safeguarding, security, identity, permissions, inclusion, equity, interoperability, support, and change-notification evidence in the real delivery context.
5. Normalize implementation, integration, licences, usage, training, review burden, remediation, migration, continuity, and exit costs.
6. Compare Do not acquire, Further evidence, Bounded pilot, Conditional procurement, and Proceed to accountable approvals. Define conditions, stop criteria, expiry, and review dates.
7. Route each unresolved issue and consequential decision to its named institutional owner. Preserve dissent and conflicting evidence.
Expected output:
An educational need and alternative statement, claim-evidence register, student-data lifecycle map, accessibility/privacy/security/equity control matrix, total-cost and exit scenarios, evidence requests, bounded gate recommendation, required approvals, and decision-record template.
Constraints and boundaries:
- Never invent vendor capabilities, certifications, legal requirements, data locations, retention periods, test results, prices, approvals, or accessibility findings.
- Treat questionnaires and assurances as claims until their evidence and scope are established.
- Prefer aggregated, synthetic, or minimized examples; identifiable student data requires documented necessity, approved handling, and accountable authorization.
- Final procurement, legal, privacy, security, accessibility, academic, financial, and budget decisions remain with the responsible officers.
Powered by an Amo.ng Prompt
Educational AI Procurement and Student Data Decision Gate
Open the linked prompt to use the instructions that power this Skill.
Completion criteria
Complete when the learning need and alternatives are explicit; material vendor claims have current evidence status; student-data flows, model use, retention, deletion, and exit are mapped; accessibility, privacy, security, safeguarding, equity, cost, and lock-in gaps have owners; and every required approver and stop condition is named. Otherwise return a provisional gate with targeted evidence requests.
Was this useful?
Explore related Workflows
Browse WorkflowsGovern University AI Adoption, Curriculum and Impact
Move from approved university AI policy through procurement, curriculum alignment, implementation oversight, and evidence-based institutional impact decisions with accountable authority at every gate.
Related Prompts
Browse PromptsUniversity AI Initiative Portfolio and Academic Impact Review
Reconcile teaching, research and administrative AI initiatives against mission outcomes, cost, risk, duplication, inclusion and evidence quality for a bounded portfolio decision.
AI Curriculum Currency and Graduate Competency Gap Audit
Compare a programme with dated primary standards, credible research and labour evidence to separate durable AI competencies from short-lived vendor fashion.
University AI Policy-to-Practice and Appeals Map
Translate supplied university AI policy into traceable role-specific rules, evidence requirements, escalation routes and fair appeals without inventing institutional authority.
Student AI Prototype Readiness and Handoff Review
Test whether a student AI prototype has documented users, data rights, evaluation evidence, limitations, risks and a safe accountable owner before demonstration or reuse.
AI Club Workshop Facilitator and Learning-Evidence Pack
Turn a defined AI topic into a practical club workshop with source-grounded explanations, exercises, facilitator cautions and observable before-and-after learning evidence.
Blind AI Model Comparison Teaching Lab and Evaluation Pack
Design a reproducible learning lab that hides model identity, uses held-out tasks and calibrated scoring, and teaches students to interpret uncertainty and failure slices.