Chiranjeevi Maddala
June 2, 2026
Every AI vendor will tell you the platform is easy to deploy. What they will not tell you is what happens at 8:47 on a Monday morning when 400 students try to log in simultaneously, two teachers cannot access their dashboards, the principal wants to know why the monitoring data has not updated since Friday, and you are the person whose phone is ringing. This blog is for you.
The IT coordinator is the most underserved person in every school AI implementation. The vendor demos are designed for principals. The training sessions are designed for teachers. The board presentations are designed for trustees. And the IT coordinator — the person who actually has to make the technology work, every day, in the real conditions of a real school — is given a technical specification document and a support email address and expected to figure out the rest.
This blog is the resource that should have been in the implementation package from day one. It covers everything an IT coordinator needs to know about managing AI in schools: how to evaluate a platform before your principal commits to it, what the network and device requirements actually look like in practice, how to build a data governance framework that satisfies India's DPDP Act, what the access control architecture should look like, how to handle the incidents that every implementation produces, and what questions to ask a vendor whose answers will tell you more about the quality of their platform than any demo ever could.
It is written in plain language because the IT coordinator who has to manage AI in a school does not need more vendor jargon. They need specific, honest, practical information about what they are actually taking on.
The IT coordinator who asks the right questions before the implementation begins is the IT coordinator who sleeps through the night after it launches.
By the time the IT coordinator is involved in a school AI adoption conversation, the principal has usually already seen the demo, been impressed by the outcomes data, and formed a strong preference for the platform. The IT coordinator's job in this phase is not to be the person who says no. It is to be the person who ensures that what the principal wants to buy is something the school can actually operate.
There are eight technical questions that every IT coordinator should get specific, written answers to before any AI platform is procured. These questions are not on any vendor's standard FAQ page because honest answers to some of them reveal limitations that vendors prefer not to highlight in advance.
Question 1: What are the actual network requirements, not the minimum requirements?
Every platform specification lists minimum network requirements. Minimum requirements are the conditions under which the platform technically functions. They are not the conditions under which it functions well enough to use in a classroom. Ask the vendor: what bandwidth per concurrent user do you recommend for a good experience? What happens to performance at 80% of recommended bandwidth? At 60%? What specific degradations occur and how do they affect the teacher and student experience?
For AI Ready School's Zion platform, the honest answer to this question is that cloud deployment requires reliable connectivity to function well, and that schools in lower-connectivity environments should use Matrix on-premises infrastructure to eliminate the dependency entirely. A vendor who gives you a minimum bandwidth number and does not mention what happens below that number is not giving you the information you need.
Question 2: What does the authentication architecture look like?
Single sign-on integration, password management, account provisioning and deprovisioning, and session management are the authentication concerns that determine whether your first week of implementation produces smooth access or 200 support tickets from teachers and students who cannot log in.
Ask specifically: does the platform integrate with your existing identity provider (Google Workspace, Microsoft 365, or your own directory)? What is the process for provisioning accounts for a new academic year? What happens to data when a student account is deprovisioned at the end of the year? What is the session timeout policy and can it be configured?
Question 3: What data does the platform collect, where does it go, and who can access it?
This is the DPDP Act compliance question and it requires a specific, written answer rather than a general reassurance. You need to know: what categories of data are collected (interaction logs, performance data, behavioural patterns, device information, location data)? Where is this data stored (specific server locations, not general regions)? Who at the vendor organisation has access to it? What are the data retention periods? What is the process for a data deletion request?
For Matrix on-premises deployments, the answer to all of these questions is that data stays on school-owned hardware and the school determines every aspect of its governance. For cloud deployments, the answers require specific contractual documentation that the IT coordinator should review before procurement rather than after.
Question 4: What are the device requirements and compatibility limitations?
The demo was run on a high-specification laptop with a fast internet connection. Your school has a mix of devices of varying ages, operating systems, and specifications. Ask specifically: what is the oldest device generation that produces an acceptable experience? What browsers are supported and which are not? Does the platform function on tablets as well as laptops, and if so, which tablet operating systems? Are there known compatibility issues with any common school device configurations?
Question 5: What does the access control architecture look like for administrators?
You need to know: can you restrict specific tools or features for specific grades, classes, or individual students without contacting the vendor? How quickly do access changes take effect — immediately, or on next login, or at the next session? Can you export a complete audit log of user activity? Can you set session limits, content filters, or usage time restrictions by user group?
For Zion, the access control architecture allows per-grade, per-class, and per-student tool restrictions from a single administrative console with immediate effect. This is the standard you should expect from any K-12 platform. If a vendor cannot describe a comparable access control architecture, the platform was not designed for school deployment regardless of how it is marketed.
Question 6: What is the incident response process?
When something goes wrong — and something will go wrong — what happens? Is there a specific support contact for school IT issues, or is it a general support queue? What are the response time commitments? Is there an escalation path for critical incidents? What is the vendor's history of major outages and how were they communicated?
Question 7: What does the integration architecture look like with your existing systems?
Does the platform integrate with your student information system? Your learning management system? Your parent communication platform? What data flows between these systems and what are the integration options (API, CSV export, SSO only)? Integrations that are not explicitly documented before procurement become custom development requests after it — which is expensive, slow, and often not possible.
Question 8: What is the offboarding process?
If the school decides not to renew after Year 1, what happens to the data? Can you export it in a usable format? What is the timeline for data deletion from vendor systems? What happens to the Cypher learner profiles and Morpheus monitoring data — does the school own it, and can it be exported?
The vendor who answers all eight of these questions specifically and in writing before procurement is a vendor whose platform was designed with the IT coordinator in mind. The vendor who deflects, generalises, or routes you to a sales representative when you ask technical questions is telling you something important about what the post-sales support experience will look like.
Having evaluated the platform, the next IT coordinator responsibility is ensuring the school's network can support it. The network requirements for school AI deployment are different from the requirements for standard school web browsing, and the difference matters enough to be worth a specific assessment before Day 1.
Bandwidth planning
The critical calculation is concurrent users multiplied by per-user bandwidth requirement. For a school deploying Zion and Cypher to 400 students simultaneously — which is what a school-wide deployment looks like during a structured AI learning period — the bandwidth requirement is substantially higher than the school's current peak usage, which is typically driven by video streaming during assemblies or content-heavy browsing across classrooms.
The specific number depends on the platform and the features in use. Interactive AI conversation (Cypher sessions) is more bandwidth-intensive than static content consumption. Video generation in Zion's Creative Hub is more intensive than text interaction. Get the specific per-feature bandwidth numbers from the vendor and calculate your peak concurrent requirement before deployment, not during it.
For schools where external bandwidth is the constraint, Matrix on-premises infrastructure routes all AI processing through the school's internal network rather than external internet. The bandwidth requirement for AI processing drops to near zero, and the only external bandwidth required is for browser-based access to the platform interface, which is minimal. This is the practical reason that Matrix is not just a data sovereignty solution — it is a connectivity solution for schools where external bandwidth is scarce or unreliable.
Network segmentation
School networks that have not been redesigned for AI deployment typically run all device traffic on a flat network or a simple two-segment design (staff and student). AI deployment benefits significantly from a more structured segmentation: separate segments for AI platform traffic (prioritised), student device traffic (standard), staff device traffic (standard), and administrative systems (isolated).
Traffic prioritisation ensures that AI learning sessions are not degraded by simultaneous video streaming or software updates. Network isolation for administrative systems ensures that AI platform data — which includes student learning data — is not accessible from network segments that are outside the school's security perimeter.
Monitoring and alerting
Before the implementation goes live, establish network monitoring that will tell you when performance is degrading before teachers and students start calling. Specific thresholds to monitor: bandwidth utilisation above 80% of capacity, latency above 150ms for AI platform traffic, and packet loss above 1%. These thresholds are leading indicators of the performance problems that produce a degraded user experience before they produce platform failures.
The gap between "the platform supports these device types" and "these are the devices your school has" is the IT coordinator's daily reality. Managing that gap well requires three specific practices.
Device audit before deployment
Before Day 1, audit every device that will be used in the implementation against the platform's actual performance requirements. Not the minimum requirements — the actual performance requirements at which the platform works well enough for classroom use. Devices that fall below the threshold need either to be upgraded, replaced, or excluded from the initial deployment scope.
The device audit is not just about specification. It is about condition. A four-year-old laptop that meets the specification on paper may have accumulated software, registry issues, and storage problems that degrade performance below what the specification predicts. Include a performance test — not a specification check — in your device audit.
Standardised browser and extension management
AI platforms are browser-based applications. Browser extensions — particularly ad blockers, privacy extensions, and content filters — can interfere with platform functionality in ways that produce symptoms (content not loading, interactions failing, data not saving) that look like platform bugs but are actually extension conflicts.
Before deployment, establish a standardised browser configuration for school devices that includes only the extensions required for school use and excludes those known to interfere with the AI platform. Communicate this configuration to teachers and students before Day 1 so that extension-related issues do not produce unnecessary support load during the first weeks of use.
Update management during implementation
Operating system and browser updates that occur during the first weeks of an AI implementation can introduce compatibility issues that were not present during pre-deployment testing. Establish a update management policy for the implementation period: defer automatic updates on school devices for 48 hours after a new OS or browser version releases, test the AI platform on the updated version internally before allowing the update to propagate to all devices.
India's Digital Personal Data Protection Act 2023 creates specific obligations for schools that process student data. The IT coordinator is the person most directly responsible for ensuring that the school's technical architecture satisfies those obligations. Here is what that means in practice.
Data mapping
Before any AI platform goes live, create a data map that documents every category of student data that the platform collects, processes, or stores. For Cypher, this includes interaction logs, learner profile data, performance data, and behavioural pattern data. For Morpheus, it includes teacher-generated content, monitoring dashboard data, and student assessment data. For Zion, it includes tool usage logs, creative outputs, and project data.
The data map should specify: what data is collected, where it is stored, who can access it, how long it is retained, what the deletion process is, and what the legal basis for processing is under DPDP. This document is the foundation of your DPDP compliance framework and should be reviewed by the school's legal advisor before the implementation goes live.
Consent management
DPDP requires verifiable parental consent for the processing of children's data. This consent must be collected before the implementation begins, must be specific to the categories of data being processed, and must be documented in a way that can be produced in response to a regulatory inquiry.
The IT coordinator's role in consent management is to ensure that the consent collection process is technically sound — that consent records are stored securely, that the consent withdrawal process works as documented, and that student accounts cannot be activated for AI platform use before consent is recorded.
Breach notification readiness
DPDP requires notification to the Data Protection Board of India and to affected individuals in the event of a personal data breach. The IT coordinator should have a documented breach notification process in place before the platform goes live: how a breach is detected, who is notified internally, what the timeline for external notification is, and what information needs to be included in the notification.
For schools using Matrix, the breach risk is substantially reduced because student data never leaves school-owned infrastructure. There is no external transfer to monitor, no cloud provider to be notified by, and no third-party breach to respond to. The IT coordinator's breach response process for a Matrix-deployed school is an internal incident response process — which is significantly more straightforward than the multi-party coordination that a cloud data breach requires.
Access control for a school AI platform is more complex than access control for most school systems because it involves multiple user types (students, teachers, administrators, parents), multiple access levels within each user type (a Grade 6 student has different access than a Grade 10 student), and multiple dimensions of access (which tools, which features, which data).
The access control architecture you should implement has four layers.
Layer 1: Authentication. All users authenticate through a single identity provider — ideally your school's existing Google Workspace or Microsoft 365 tenant. This eliminates the need for separate password management for the AI platform, ensures that users who leave the school (teachers at the end of contract, students at the end of the year) are automatically deprovisioned from the AI platform when their school account is deactivated, and produces a single audit trail for user access across all school systems.
Layer 2: Role-based access. Define roles — Student, Teacher, Academic Coordinator, School Admin — and assign platform capabilities to roles rather than to individuals. This means that when a new teacher joins the school and is assigned the Teacher role, they automatically receive the correct platform capabilities without individual configuration. It also means that when a teacher moves from Class 7 to Class 10, their access updates when their role assignment updates.
Layer 3: Grade and class-level restrictions. Within the Student role, implement grade-level and class-level restrictions on tool access. A Grade 3 student should not have access to the same Zion tools as a Grade 10 student. A student in a class whose teacher has not yet been trained on a specific hub should not have access to that hub until the teacher is ready to monitor their use. These restrictions should be configurable by the academic coordinator without IT intervention.
Layer 4: Individual overrides. For edge cases — a student with specific learning needs who requires different tool access, a teacher who is piloting a feature before school-wide rollout — implement individual override capability that is logged and time-limited. Individual overrides that are not time-limited accumulate into an unmanageable access control debt that makes auditing impossible.
Every implementation produces incidents. The IT coordinator who has planned for the common ones handles them in minutes. The IT coordinator who encounters them without a plan handles them in hours — with the additional complications that unplanned incident response typically produces.
The Monday Morning Login Failure
Symptoms: large numbers of users unable to log in, often after a weekend. Causes: expired session tokens, authentication provider outage, cached credentials that have been invalidated. First response: check the authentication provider's status page before assuming a platform issue. If the authentication provider is operational, check whether the issue affects all users or a specific group (which indicates a configuration issue rather than a platform issue). Resolution: in most cases, clearing browser cache and cookies resolves cached credential issues. For broader authentication failures, escalate to the platform support team with the specific error messages being produced.
The Dashboard Not Updating
Symptoms: Morpheus monitoring dashboard showing data that is older than expected. Causes: data synchronisation delay (normal, typically resolves within 2-4 hours), connectivity issue preventing data sync, or user account configuration issue. First response: confirm whether the issue affects one teacher or multiple. Single-teacher issues are usually account configuration. Multi-teacher issues are usually synchronisation or connectivity. Resolution: for synchronisation delays, wait 4 hours before escalating. For connectivity issues, check network logs for the timeframe when data sync should have occurred.
The Content Filter Blocking Legitimate Platform Content
Symptoms: teachers or students unable to access specific platform features, receiving content filter or security warning messages. Causes: school network content filtering rules blocking AI platform domains or IP ranges. This is common in schools that have aggressive content filtering and have not whitelisted the AI platform domains before deployment. Resolution: obtain the complete list of domains and IP ranges that the AI platform requires and add them to your content filter whitelist. This should be done during pre-deployment testing rather than after a live incident, but if it was missed, it is a straightforward fix.
The Performance Degradation During Peak Usage
Symptoms: platform running slowly during specific periods (typically first and last periods of the day when multiple classes are starting simultaneously). Causes: bandwidth saturation at peak concurrent usage. Resolution: check bandwidth utilisation during the affected periods. If bandwidth is saturated, either schedule AI-intensive activities to avoid peak periods, implement traffic prioritisation for AI platform traffic, or — for persistent issues — consider Matrix infrastructure to eliminate the external bandwidth dependency.
Beyond incident response, a monthly maintenance routine keeps the implementation healthy and prevents the accumulation of technical debt that produces major incidents.
Every month: review user account status and deprovision accounts for students or teachers who have left the school. Review access control assignments for accuracy against current class and grade assignments. Review content filter logs for any platform domains that are being blocked. Check bandwidth utilisation trends against the previous month to identify gradual increases that may require network capacity planning.
Every term: review the full data map against any platform updates that may have changed what data is collected or processed. Review DPDP consent records against current student enrollment to identify any students who are using the platform without recorded parental consent. Review the platform's security update status and apply any pending updates to the Matrix local deployment.
Every year: conduct a full device audit against the platform's current performance requirements. Review the authentication integration for any changes required by updates to your identity provider. Prepare the annual data processing report for the school's legal compliance record. Review the data retention schedule and execute any required deletions of data that has exceeded its retention period.
In schools where implementations work smoothly, the IT coordinator has typically done three things that their counterparts in struggling implementations have not.
They built relationships with teachers before the implementation began. The IT coordinator who is known to teachers as a person — someone who has been helpful, responsive, and honest about what technology can and cannot do — receives very different reports of problems than the IT coordinator who is a ticketing system. Teachers who trust the IT coordinator describe problems specifically and early. Teachers who do not trust the IT coordinator either live with problems or complain to the principal.
They documented everything before Day 1. Network configuration, device audit results, access control architecture, data governance framework, vendor support contacts and escalation paths. The documentation is not for the IT coordinator's own benefit — they know what they set up. It is for the moment at 8:47 on a Monday morning when the IT coordinator is dealing with a separate incident and someone else has to handle the login failures.
They established clear boundaries for what the IT coordinator handles and what the AI coordinator handles. The IT coordinator handles technical issues: network, devices, authentication, access control. The AI coordinator handles pedagogical issues: how to use the platform, what the data means, how to design AI learning activities. The boundary is not always clean — a teacher's difficulty using a platform feature could be a technical issue or a training issue — but having a clear default assignment for each category of problem produces faster resolution than having every issue route to the same person.
The IT coordinator who prepared before Day 1 is the IT coordinator who handles Day 1's surprises with confidence. The one who did not is the one whose phone does not stop ringing.
AI Ready School provides dedicated technical evaluation sessions for school IT coordinators before any procurement decision. The session covers the complete technical architecture of the platform, the specific network and device requirements for your school's size and infrastructure, the Matrix on-premises deployment option, the DPDP Act compliance framework, and the access control architecture options.
To book a technical evaluation call or to discuss your school's infrastructure requirements, reach out at hey@aireadyschool.com or call +91 9100013885.
Book a Technical Evaluation Call
.png)
