---
name: evaluate-educational-ai-procurement-student-data-risk
description: 'Evaluate an educational AI acquisition against learning need, vendor evidence, accessibility, student-data controls, security, equity, total cost, lock-in, and accountable approval requirements. Use when 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.'
compatibility: 'Instruction-only Agent Skill. Requires an Agent Skills-compatible client and access to the tools or systems named in the instructions. No executable scripts are bundled.'
metadata:
  publisher: RichlyAI
  product: Amo.ng
  amo_id: AMO-S-000036
  canonical_url: 'https://amo.ng/skills/evaluate-educational-ai-procurement-student-data-risk'
  package_version: 1.0.0
  source_type: prompt
  source_amo_id: AMO-P-000337
  source_content_sha256: 1db835a4ecd4ad706ff753aa6e529aafa264b4bebacbf3afb8b947146d4ae3d0
  source_version: 1.1.0
---

# Evaluate Educational AI Procurement and Student Data Risk

## When to use this Skill

- 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 this Skill

- 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.

## 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.

Use [INPUT-TEMPLATE.md](assets/INPUT-TEMPLATE.md) to organize the supplied information.

## Required tools or access

Published source tool designations: General AI. These are source designations, not portable-client compatibility claims. Use only authorized access described in the inputs and source instructions. Do not claim access or inspection without evidence.

## Procedure

Before starting, read [SOURCE.md](references/SOURCE.md), including the exact Prompt instructions and any ordered Workflow steps, review notes and carry-forward requirements.

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.

Published 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.

## Review gates

Read and apply the source review instructions in [SOURCE.md](references/SOURCE.md) before acting. Keep proposed, unrun and executed actions distinct; preserve missing evidence and obtain the human approvals required by the source.


## 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 the [completion checklist](references/COMPLETION-CHECKLIST.md) and record unresolved items.

## Limitations

- 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.

This is an instruction-only package. Packaging does not execute work, grant access or independently verify the package. Existing public verification in amo.json describes only the identified published source resources.

## References

- [Published source instructions](references/SOURCE.md)
- [Completion checklist](references/COMPLETION-CHECKLIST.md)
- [Input template](assets/INPUT-TEMPLATE.md)
- [Rights](RIGHTS.md)
- [Canonical Amo.ng Skill](https://amo.ng/skills/evaluate-educational-ai-procurement-student-data-risk)
