Key takeaways
- Nobody demos the admin console, and it is where nearly all the manageable risk lives.
- Six settings do most of the work: training exclusion, retention, sharing, invitations, connectors, and deprovisioning.
- SSO is worth the tier upgrade in most organisations, because offboarding stops depending on memory.
- Two named administrators, minimum. One is a single point of failure with a password.
Every AI product demo shows you the chat window. None of them show you the settings page, which is a shame, because the settings page is what determines whether you have deployed a business tool or handed out a consumer app with a company logo on it.
This is a working checklist. It is deliberately provider-agnostic, because the labels differ between vendors while the underlying decisions do not. Work through it with whoever administers your systems and you will have covered most of what an auditor, a client questionnaire or an incident would ask about.
The six settings that carry the weight
1. Training exclusion
Confirm, at the tier you are actually buying, that your content is excluded from model training by default. Business and enterprise tiers generally are; consumer tiers frequently are not. Get this from the contract or the documentation rather than a salesperson's reassurance, and keep a copy, because this is the single most common question on client due diligence forms.
2. Retention
Decide how long conversation history is kept, and set it deliberately rather than accepting whatever the default is. Two competing pressures: shorter retention reduces the volume of material sitting in a third-party system, while longer retention preserves useful work and may be required by your own record-keeping obligations. There is no universally right answer, but there is a wrong one, which is not having decided.
3. External sharing
Most assistants can generate a link to a conversation. Decide whether that link can be opened by anyone with the address or only by people inside your organisation. This setting is easy to overlook and has an obvious failure mode: a shared conversation containing client material, indexed and reachable by anyone who has the URL.
4. Who can invite
If any user can invite colleagues, your seat count and your spend become emergent properties rather than decisions. Restrict invitations to administrators and require a normal request. This is also what keeps your user list matching your licence count.
5. Connectors and integrations
Connecting the assistant to your file storage, email or ticketing system is where it becomes genuinely powerful, and where the permission model needs real thought. The right question is not whether to connect but whether the connector respects your existing permissions. If a user can reach documents through the assistant that they could not open directly, you have created a permissions bypass and it will surprise someone eventually.
6. Deprovisioning
Removing access when someone leaves should be a single action, and ideally an automatic consequence of disabling their main account. Test this rather than assuming it. The test is simple: disable a test account in your identity provider and confirm it can no longer reach the AI tool.
The question that exposes most setups: if someone resigned this afternoon, how many separate systems would you have to touch to be confident they no longer have access to company information through an AI tool? If the answer is more than one, that is your next piece of work.
Single sign-on: worth it or not
SSO usually sits at a higher price tier, which prompts a reasonable question about whether it is worth the jump. For most organisations with an existing identity provider, it is, for four reasons that have nothing to do with convenience.
| Benefit | Without SSO | With SSO |
|---|---|---|
| Offboarding | A manual step on a checklist that someone must remember during a busy week. | Automatic. Disabling the identity account removes access. |
| Password hygiene | Another password, often reused, often stored badly. | No new password exists to be reused or leaked. |
| Multi-factor authentication | Depends on the AI vendor's implementation and each user enabling it. | Inherited from the policy you already enforce. |
| Access review | A separate user list to reconcile by hand. | Part of the review you already run. |
The counter-argument is real for very small organisations. If you have twelve people, no identity provider, and offboarding means the director revoking access personally over a coffee, the tier jump may not earn its keep. Below roughly twenty staff, a documented manual process is defensible. Above that, memory stops being a control.
Workspace structure
Most business tiers let you organise users into workspaces, projects or teams. It is tempting to skip this and put everyone in one pool. Two reasons not to.
Cost attribution. Structure gives you spend by team without extra work, which makes the value conversation at renewal dramatically easier. Without it you have one large number and no way to explain it.
Separation where it is genuinely needed. If one team handles material others should not see, workspace boundaries are the mechanism. Retrofitting this after six months of shared use is far more work than setting it up on day one.
Keep it simple. Mirror your existing team structure rather than inventing a new taxonomy, because the new taxonomy will not be maintained.
Audit and visibility
Understand what your tier actually records, and check it before you need it. Typically available: who has an account, when they last used it, and administrative changes. Typically not available in detail: the content of conversations, which is usually a deliberate privacy design rather than an oversight.
This matters for expectation setting. If a manager assumes they can review what their team has been asking, they are probably wrong, and it is much better to establish that in month one than during an investigation.
Set a calendar reminder now: a quarterly access review, comparing the user list against current staff, and checking last-login dates. It takes twenty minutes, reclaims dormant seats, and catches the leaver who slipped through offboarding.
A configuration checklist
- Business or enterprise tier confirmed, not consumer.
- Training exclusion confirmed in writing and filed.
- Retention period chosen deliberately and documented.
- External sharing of conversations set to your chosen level.
- Invitations restricted to administrators.
- Connectors reviewed, and permission inheritance tested with a real low-privilege account.
- SSO connected, or a documented manual offboarding process if not.
- Deprovisioning tested end to end with a test account.
- At least two named administrators recorded somewhere findable.
- Workspaces mirroring team structure, for attribution and separation.
- Hard spending limit set at the provider.
- Quarterly access review in a shared calendar with an owner.
Frequently asked questions
Do we need SSO for AI tools?
If you run an identity provider, yes. It makes offboarding automatic rather than dependent on someone remembering, and it inherits the multi-factor policy you already enforce. Below about twenty staff, a documented manual process can be enough.
Which admin settings matter most?
Training exclusion, retention, external sharing, who can invite users, which connectors are enabled and for whom, and how access is removed when someone leaves.
Who should own the admin console?
Whoever owns your other business systems, with at least two named administrators. It should not be owned by whichever enthusiastic person signed up first, because that arrangement fails the moment they change roles.
Can we see what staff are asking the AI?
Usually not in detail, and that is generally a deliberate privacy design. You can normally see who has accounts and when they last used them. Set that expectation early rather than during an incident.
Have the console configured and handed over
Admin portal configuration, optional SSO, retention and sharing settings, connectors and hard spending limits are all part of the Implementation Package, set up and then handed to your own team so you are not dependent on us to change a setting.