Data, Privacy, and Model Controls in Teams

This is the page to send to whoever has to approve Scholarly — a security reviewer, an IT lead, a procurement contact. It covers what happens to your team's material, what an admin controls, what an admin can see, and what stays private no matter who is asking.

Legally binding detail lives in the Privacy Policy. This page describes how the product behaves.

What Scholarly does with your team's material

Your sources are processed to deliver the features you ask for. When someone generates a study guide from a handbook, that handbook is read to produce that study guide. When someone asks a grounded question, the relevant sources are read to answer it. That is the extent of it.

Private User Content is not used to train general-purpose AI models by default. Any optional training program would require separate, informed opt-in, and connected-service data (such as files from Google Drive) stays subject to its own stricter restrictions regardless. Scholarly's Terms of Service state this directly — see the Terms of Service and the Privacy Policy.

Running an AI model to answer your request is not the same thing as training a model on your request. The distinction matters in a review, and it is the one most often collapsed.

Choosing which AI models your team can use

Admins set model policy for the whole team at Team → Billing → Plan & AI models.

Model by model, or by tier

The catalogue lists every model grouped by the company behind it — OpenAI, Anthropic, Google, xAI, Meta, and an approved open-source group from Mistral, Z.ai, and Moonshot AI — with hosting and data-retention details shown where available. You can:

• Search the catalogue by model or company name.
• Filter to All, Enabled, or Disabled.
• See how many creation surfaces each model covers, so you know what turning one off actually affects.
• Read a running summary — "X of Y models available to members" — so the blast radius of a policy is never a guess.

Broader switches cover the tiers rather than individual models: the Premium models tier, the Frontier models tier included on Laureate seats, and the extended open-source catalogue beyond the curated defaults.

A policy can only remove access

This is the rule that prevents surprises in both directions:

A team policy can only ever remove access. It cannot grant a member a model above their effective plan. Enabling a Frontier model does not give a Premium seat Frontier access — it only stops the team policy from being the thing in the way.

Require Zero Data Retention

If your organization has a data-handling policy that rules out providers retaining request data, turn on Require Zero Data Retention in the same place.

What it does: only models whose provider route is approved for zero data retention stay available to the team. Everything else is blocked for every member, without anyone needing to be told which models to avoid.

Which models stay available: enough to work with. Zero Data Retention narrows the catalogue rather than emptying it — models remain available across chat and the creation tools, spanning more than one provider. The exact set is shown live in the catalogue, filtered to Enabled, which is a more reliable answer than any list written down here.

Why something is unavailable is never a mystery. A blocked model says which rule blocked it — Blocked by the Zero Data Retention rule, Blocked by the Frontier models rule, Blocked by the Premium models rule, Blocked by the open-source catalog rule. Admins get the reason, not a silent absence, so a policy question gets a one-glance answer.

Models outside the zero-retention set carry a plain warning that their provider may retain request data under the provider agreement — so an admin makes the call with the facts on screen rather than from memory.

Where the models run

Scholarly routes across models from several AI labs, including open-source routes and EU-hosted options for teams working under European data requirements. Every open-source route is hosted in the United States, and the catalogue labels hosting where it is known.

The practical argument for this is not variety for its own sake — it is continuity. No single provider's outage, policy change, or price move can stop your team working. If one lab goes down or blocks a use case, an admin enables a different model and the team keeps producing. A workspace wired to exactly one provider does not have that option.

If your organization needs every model hosted in a specific region, that is a conversation to have with us before you roll out — see Who to contact below.

What admins can and cannot see

Adoption reporting lives at Team → Overview → Activity. It answers "is the team using this?" and nothing else.

What it shows

Over the last 30 days, with a 7-day option, grouped by UTC day:

There is an activity over time view and a per-member breakdown, so you can tell the difference between one enthusiastic user and a team that has adopted the tool.

What it does not show

• Content titles. Not in the report, not per member, not anywhere.
• Prompts, instructions, or chat messages. Never surfaced to an admin.
• Any private source or creation. There is no admin view, export, or override that opens a member's private work.

Counts are aggregated by design. Reporting tells an admin whether the team is adopting Scholarly, not what any individual wrote. There is also no team credit balance or cost-per-action report, because limits are per person.

What stays private inside a team

Joining a team does not move your account into a fishbowl.

• Content is private until someone chooses to share it. Uploads, chats, and creations are private to the member who made them. Your team is an explicit, per-item choice in the Share window, alongside Private and Public. The Team library contains exactly what people deliberately put there.
• Project chats and project memories are never shared. Even in a project the team owns, every member has their own private chats and their own private memories. No other member, no project owner, and no admin can read them.
• Admin controls are policy, not access. An admin can decide which models the team may use, require Zero Data Retention, publish shared profiles, and manage seats and roles. None of that grants a route into a member's private content.
• Leaving or being removed ends access, not ownership. A departing member loses the shared library and the team's plan access immediately. Everything they personally made stays in their own account. Work in a team-owned project stays with the team.

For the personal version of all this, see Privacy, Cookies, and Your Data.

Connected accounts

Google Drive is connected per member, and per file.

• Files are selected through Google's own picker. Scholarly can use only the files that member picked, plus files it creates there when they export something.
• It cannot browse the rest of the Drive — not unselected folders, not files shared with that person by someone else.
• Access to what is picked is read-only: Scholarly reads those files to answer questions and build creations. It does not edit, rename, re-share, or delete anything.
• A member disconnects at any time from Settings → Connections, or revokes access from their Google account. Disconnecting stops future access; anything already imported or generated is removed separately.

See Connections.

Who to contact

Self-serve Teams covers 1–29 paid seats, with a free trial of up to 3 seats before checkout. Talk to us directly when:

• A security, privacy, or procurement review needs answers specific to your organization.
• You need every model hosted in a particular region.
• You are rolling out across departments, need more than 29 seats, or need invoicing or a purchase order.

Use Talk to our team on the Teams page and tell us what you are rolling out — we reply by email, usually within one business day. We would rather answer a precise question than have a reviewer infer the answer from a help article.

Related

• Privacy, Cookies, and Your Data — the same questions from an individual account's point of view.
• Managing Your Team — seats, roles, invitations, and where each control lives.
• Your Team Library and Team Projects — what the shared library holds and who owns what.
• AI Models — the model catalogue and how model choice affects a creation.
• Scholarly Teams — plans, seats, and what a team includes.