Here is a question I want every superintendent and IT director to be able to answer before the next board meeting: who in your district can read a student’s AI conversation?
On most commercial AI products, the honest answer is “the vendor decides, and the terms can change.” On a private AI server for schools, the answer is “we decide.” That’s the whole point. But owning the decision means you actually have to make it, and the newest round of updates to the private server puts that question right in front of district leaders.
Since my October update post, the platform has shipped several more releases, closing out with a bigger one in early November. Some of it is plumbing. Some of it is exactly the kind of control a district should want. And one change is a default your team needs to review on purpose.
Key takeaways
- A new Sessions view gives administrators a timeline of every chat, and admin access to conversations is on by default. Districts should decide, in policy, who may use it and when.
- New controls let IT hide specific features from non-admins, keep base models out of a group’s picker, and require users to approve tool actions before they run.
- Shared notes, workspace-wide search and comments make the server more useful for teams, while riskier features (side chats, sub-agents, encrypted person-to-person chats) stay off until an administrator turns them on.
- The latest releases include security fixes; with cybersecurity ranked the top priority by K-12 tech leaders, staying current through support matters.
Visibility: the Sessions view and admin chat access
The private server now has a Sessions tab in its analytics area. It lists every chat with its responses, errors and timing, and opening one shows a timeline of replies and tool calls, including whether each one worked. When a teacher says “the assistant broke during third period,” IT can see what actually happened instead of guessing.
Here’s the part to slow down on. The setting that lets administrators open other people’s chats is on by default, and the platform’s own guidance says to switch it off before updating if administrators shouldn’t read others’ conversations. That is not a bug. It’s a choice, and it’s your choice.
Think about the K-12 reality. A counselor or student-services lead may need to review a concerning student conversation. A teacher may reasonably expect that their lesson-planning chats aren’t casually browsed. Your acceptable-use policy probably already says the district can monitor its systems. So the real questions are: which administrators, for what reasons, and with what record? A district that owns its server can answer those itself and configure the server to match. That’s the governance argument I made in Who Governs Your District’s AI?, made concrete.
Administrators can also now rotate or delete a user’s API key from the user editor, which is handy when a staff member leaves.
Guardrails IT can actually set
This batch of updates is full of switches, and switches are what make a platform school-ready.
- Hide controls from non-admins. IT can turn off individual on-screen controls for everyone except administrators. Example: a middle school student environment that shows a clean, simple chat with only the buttons students need. One caution the platform is clear about: hiding a control removes it from the screen, but the feature behind it keeps working. Use permissions for real restrictions; use hiding for simplicity.
- Hidden models. A group can build assistants on a base model that never appears in that group’s model picker. Example: the English department’s writing-feedback assistant runs on a model you chose, and teachers see the assistant, not a confusing list of raw models.
- Ask before tools act. Once an administrator turns on tool permissions, users can choose “Ask for approval,” so the assistant has to get a yes before it runs a tool. The default is still full access, so this is a setting worth deciding on deliberately, especially for staff assistants connected to calendars or documents.
- Knowledge-base caps. IT can limit how many files a knowledge base holds, how large each file can be, and how many go in per upload. Example: the special education team’s library of IEP-goal templates (no student information) stays organized and doesn’t quietly balloon.
- Off until you say so. Side chats are limited to administrators and people given a new permission, which is off by default. Sub-agents (assistants that hand work to other assistants) are off by default. Encrypted direct messages and private group channels between people are off by default and require an administrator to enable and grant them. For student environments, I’d leave all three off and revisit in a pilot.
Teamwork features teachers will notice
Not everything here is about locking things down. A few updates make the server feel like a shared workspace rather than a private chatbot:
- Shared notes with pages and subpages, and you can see who else is in a note. Example: a grade-level team keeps a unit-planning notebook with a page per week, and the assistant can help draft, but it’s designed to re-read a page before editing so it doesn’t overwrite a colleague’s changes.
- Workspace-wide search across your chats, chats shared with you, channels and notes. Example: an instructional coach finds the rubric conversation from September in seconds.
- Comments, which an administrator can turn on, plus a tabbed workspace where files, previews and voice calls sit next to the conversation.
- Read Aloud can now use a voice that runs in the browser, and a fix stops read-aloud from cutting off after the first sentence. For students who benefit from hearing text, that’s a small change that matters.
The early-November release also adds more advanced capabilities, such as letting models work in a terminal and browser, write their own tools, and connect to code repositories. Those are powerful for an IT team or a computer science pathway, but they are not classroom-default features. Treat them like any new system: staff-only, pilot first.
As always: these features are now available in the platform; districts get them as their server is updated through support.
What district leaders can do this month
- Write down who can read AI conversations. Name the roles (e.g., IT for troubleshooting, student services for safety concerns), the reasons, and who approves access. Do this whether you run a private server or a commercial tool.
- Ask your current AI vendors the same question. Who at the vendor and in your district can see student and staff chats, and where is that written in the contract?
- Review defaults before you upgrade any system. Make “what’s on by default?” a standing agenda item for AI updates.
- Keep student environments simple. Decide which features students see, and which stay off (direct messaging, side chats, autonomous agents) until a pilot proves them out.
- Put AI updates on the security calendar. CoSN’s U.S. State of EdTech 2026 report says cybersecurity remains the No. 1 priority for edtech leaders, while 65% cite insufficient staffing and no dedicated budget as top barriers. An AI platform with a support plan that applies updates is one less thing for a thin team to chase.
Why a private AI server for schools
Every one of these updates is a setting the district controls. That’s the difference between owning your AI platform and renting someone else’s. When a consumer product changes a default, you find out after the fact. When your server gets a new capability, your IT team reviews it, your leaders set the policy, and it runs on district-owned hardware, which is why the program recommends on-site deployment for the strongest control over data.
It’s also why I care that this comes through LeadershipAIplus: educational leaders supporting educational leaders. The server includes 12 months of remote support and a year of virtual professional development, and LeadershipAIplus offers a server admin certification and user guide so your team builds real capacity, not dependency. If you want the basics on how the server works, the PrivatEDU AI FAQ is a good start.
FAQ
Can administrators read student AI chats on a private AI server?
They can if the district allows it. Admin access to conversations is on by default in the platform, and the district can turn it off or limit it by policy. The point is that the district, not a vendor, makes that call.
Do districts get new private server features automatically?
New features become available in the platform, and districts receive them as their server is updated through support. Many new features stay off until an administrator turns them on.
Should students have access to every new feature?
No. Start students with a simple, focused environment and add features after a staff pilot. The server’s role-based access is built for exactly that.
The choice is the feature
Knowing who can see what, and deciding it yourself, beats any new button. If you want a deeper conversation about student safety and AI guardrails, my co-host Tricia’s episode Beyond Screen-Time Bans: Student Safety in the Age of AI is worth your commute.
So here’s my question for you: if a parent asked tomorrow who can read their child’s AI conversations, could your district answer in one sentence?
If not, let’s work on it together. Schedule a Systems Review and we’ll map your current AI tools, your defaults, and what a district-owned server would change.
Sources
- CoSN, “U.S. State of EdTech 2026,” State of EdTech Leadership Report, 2026. cosn.org
- Paul Cuffe, “Why K-12 cybersecurity education needs practice, not just awareness,” eSchool News, Sept. 14, 2026. eschoolnews.com
- Jeff Utecht, “Private AI Server for Schools: October Updates,” PrivatEDU AI, Oct. 31, 2026. privatedu.ai