A school tutoring AI reuses a vendor PoC architecture without adapting to district controls. What should the auditor emphasize?

Requiring methodology maturity steps that adapt vendor PoC architectures to district security, privacy, and control requirements before production tutoring AI works because proof-of-concept success demonstrates feasibility, not production readiness for student data. PoCs often use permissive identities, demo datasets, weak logging, and vendor-default retention that conflict with FERPA-minded district controls, least privilege, and audit needs. Maturity uplift re-architects identity, data flows, encryption, monitoring, and vendor contracts to district standards before children depend on the system. The correct emphasis is controlled adaptation, not shipping the demo path. Documenting PoC tutoring accuracy and response latency to support district-wide classroom rollout decisions this semester fails because accuracy and latency metrics do not prove that security, privacy, and district controls are hardened for production student data. Relying on vendor-provided model cards and built-in filters to meet district student privacy obligations during production operations fails conceptually: vendor collateral is not a substitute for district-specific control adaptation and enforceable privacy safeguards. Scheduling detailed control mapping and privacy review after the tutoring platform completes full district enrollment and operational handover fails because it leaves demo-grade protections in place until after student data is already live.

Exam caveat: “adaptation” must be verified with district control tests—paper mapping to policies without technical enforcement still leaves the PoC posture live. Operational check: produce a PoC-to-production gap assessment against district security/privacy baselines, remediate high findings before go-live, and retest student data paths (access, retention, logging) under production configuration—not the demo tenant.