Skip to main content
Lesson 14 of 16 · ChatGPT for Teachers

Manage Student Access and Limits

Lesson 14 of 16 Updated November 6, 2026 Intermediate
On this page
  1. Grant Access Without Losing Control
  2. Provision Student Accounts
  3. Calibrate Limits
  4. What You See and What You Don’t
  5. When Things Go Wrong
  6. Evolve the Framework
  7. Your Turn
  8. Key Takeaways

Grant Access Without Losing Control

Opening ChatGPT to students is an institutional decision, not just a technical setting. It requires both a pedagogical framework—what we use the tool for and why—and a technical framework—who accesses what, within what limits, and under what supervision. These two go hand in hand: an ambitious project without access management creates chaos, while locked-down access without a clear project yields a tool no one uses.

Start with the ground rules. ChatGPT is not intended for users under 13, and those aged 13–18 need parental consent. For students, the CNIL (France’s data protection authority) states that a consumer tool should not force them to create individual accounts; such accounts remain possible for tools deployed by the ministry, notably via GAR. Any other deployment falls to the school principal, working with the data protection officer (DPO). The ministry’s usage framework limits student use to supervised class settings from grade 7 (4e) onward, moving toward autonomy only in high school. Therefore, this lesson primarily targets higher education and adult training; in middle and high schools, it serves to inform decision-making with administration.

Provision Student Accounts

Three methods for creating accounts coexist in ChatGPT Edu. Single Sign-On (SSO) lets users log in with their institutional account, managed by the institution’s identity provider—Microsoft Entra ID, Okta, or another SAML-compatible provider—and administered centrally. This is the preferred route because it adds no extra passwords to remember or reset. Email invitations or CSV imports sent to institutional addresses remain practical for pilot deployments. Automatic provisioning via the SCIM protocol—with Okta, Microsoft Entra ID, or Google Workspace, among others—synchronizes the workspace with the institution’s directory and makes sense whenever student turnover is frequent.

Four habits prevent common headaches: use only institutional addresses that the institution controls; revoke access at the end of the year, knowing that removing someone from the workspace deletes neither their personal OpenAI account nor their personal space; create accounts in batches, class by class; and document the procedure so IT staff can replicate it without you.

Calibrate Limits

Not every user needs the same access, and misunderstood equality costs money. In workspace settings, adjust permissions role by role: available models—reserve the most powerful ones, like GPT-6 Pro, for roles that actually need them—memory, link sharing, projects, and connected apps. Then monitor actual consumption in the admin console for a quarter before tightening or loosening restrictions; no one gets it right the first time.

Features depend on context. Enable them via workspace permissions where possible; otherwise, rely on instructions. Web search is invaluable for research projects but distracting during a lecture. Image generation fits creative projects. File analysis becomes essential once exercises rely on documents. Finally, disable memory during individual assessments; otherwise, one student arrives with accumulated context that their peers lack.

What You See and What You Don’t

Transparency about supervision builds user trust, and that trust drives honest usage. The admin console displays usage statistics—active users, messages, projects—broken down by group and exportable by user. Conversations do not appear there, but they are not entirely out of reach: the organization can access them for compliance purposes via the platform designed for Enterprise and Edu workspaces, within the retention period it has set. In a shared project, members see the project’s conversations.

State this explicitly rather than letting users guess: what the institution can see and under what circumstances, the consequences of misuse announced before it happens, who to contact for technical or ethical issues, and their right of access and deletion under GDPR. A class briefed on these rules for ten minutes respects them better than one that suspects general surveillance.

When Things Go Wrong

Plan your procedure before an incident occurs. A graduated response aligned with internal regulations works well: for a first offense, a reminder of the rules and a discussion; for a second, temporary access restriction; for a third, account suspension paired with a meeting involving the student and their family. Announcing this escalation path upfront prevents most incidents. Technical outages require a designated point person capable of resetting blocked access, resolving SSO issues, and escalating to OpenAI support—without one, everything lands on the professor who introduced the tool, quickly discouraging them.

Evolve the Framework

Limits set in September are not meant to last three years. Natural progression moves from strict limits with active supervision and student training in the first quarter, to relaxed rules and greater autonomy in the second, then to mature usage in the third, where limits become minimal because self-regulation takes over. If an institution is still in the initial phase by June, ask yourself: either the training missed the mark, or no one dared to loosen the grip.

What the institution sees and what to say Two columns. What the institution sees: usage by group in the console, conversations via the compliance platform, conversations in a shared project for its members. What to tell users: the rules and graduated response, the contact person, and their rights of access and deletion. ACCESS What the institution sees and what to say The institution sees Console Usage, by group Compliance Conversations, if needed Shared project Conversations, for members Tell users Before Rules and graduated response Contact Designated point person Rights Access and deletion Consumer tool: no individual account required for students (CNIL).
Based on the "Workspace analytics" and "OpenAI Compliance Platform" articles from the OpenAI Help Center (November 2026) and the CNIL FAQ (June 2025).

Your Turn

Justify every setting.

  1. Review the permissions table for one of your groups
  2. Justify each line—model, feature, access—with a sentence stating the pedagogical objective
  3. Delete or correct lines that don’t hold up: they merely copy a default setting
  4. Draft a ten-line note telling users what the institution can see
  5. Have your data protection officer review it

Official sources: Is ChatGPT safe for all ages? · Managing workspace settings in ChatGPT Enterprise · Workspace analytics for ChatGPT Enterprise and Edu · OpenAI Compliance Platform for Enterprise and Edu customers · Projects in ChatGPT · Single sign-on (SSO) setup for OpenAI products · SCIM provisioning and management · Managing members, workspace roles, and seats in ChatGPT Enterprise and Edu (OpenAI Help Center) · Teacher: How to use an AI system in your duties? (CNIL) · Artificial intelligence and its uses in education (éduscol)

Key Takeaways

  • SSO with your institution’s identity provider is the preferred route
  • According to the CNIL, a consumer tool should not force students to create individual accounts
  • Set permissions role by role, then adjust based on actual consumption
  • Clearly state what the institution can see, including via its compliance tools
  • Evolve limits progressively as usage maturity grows