Decide how to give a small team AI access without shared logins, unclear ownership or unnecessary seats, using account checks and a worked cost comparison.
Direct answer: Do not share a personal AI login between colleagues. Give each actual user an authorised account, then pay only for the access your tasks justify. For occasional work, one named operator can produce reviewed outputs for colleagues without handing over their login, provided the service terms and your data rules permit the work. A paid team workspace is justified when its verified controls and recurring use meet a real need, not simply because your organisation has several people.
A shared subscription appears economical because the bill is easy to see. The less visible questions are who can read previous work, who authorised an account connection and who can recover access when the original owner is unavailable.
Neither trust between colleagues nor a shared company email address answers those questions. You need an access arrangement that continues to make sense after a mistake, a role change or a departure.
Applies to: small teams selecting interactive AI application accounts. API access and automated service identities are separate arrangements with their own terms and controls.
Build an access ownership map
The access ownership map is an editorial method for tracing four things: the person using the application, the work they can see, the permissions they can grant and the route for recovering control. Draw these connections before comparing subscription prices.
Start with the task rather than an organisation chart. A researcher using AI daily to structure public material has a different requirement from a colleague requesting an occasional rewrite. List actual users, frequency and permitted input. That identifies who needs direct access and who only needs a reviewed result.
The parent guide, How Small Teams Can Adopt AI Without Losing Trust, sets the broader requirement for approved accounts and accountable output. This decision is narrower: whether your access arrangement can support that accountability when several people work together.
Establish whether sharing is even permitted
Read the account terms for the specific provider, subscription and purchasing region. Do not infer permission from the fact that a password works on another device. For example, OpenAI's account-sharing policy says an account is for the individual who created it, while allowing that individual to use multiple devices. Those are different permissions.
Ask the provider if the wording is unclear. Save the relevant answer with your purchasing decision. A team workspace, shared project and shared login are not interchangeable concepts; collaboration may involve distinct users with separate authentication.
If the terms prohibit account sharing, remove it from the cost comparison. Your alternatives are permitted individual access, a suitable managed plan, an authorised operator or completing the task another way. Treating a prohibited arrangement as the cheapest option distorts the decision before you consider usefulness.
Trace identity, history, permissions and recovery
For identity, write who signs in and who can demonstrate that a particular output was reviewed. Shared credentials make that harder. The UK National Cyber Security Centre recommends separate work accounts and explains that shared access weakens privacy and attribution. A promise to remember who used the tool is a fragile substitute.
For history, check the application's actual visibility rules. Establish whether users, workspace administrators or people given a shared link can read conversations, attachments and stored instructions. Do not upload private personnel or client material merely to discover who can see it. Use invented sample content to explore permitted sharing.
For permissions, record which external accounts could be connected and what access would be granted. A calendar connection and a document-store connection expose different information. Review the permission request before approving it. If an account does not need a connection to perform its task, leave it disconnected.
For recovery, identify the owner of the sign-in email, recovery methods and billing authority. Verify the provider's transfer and removal process before committing important work. Do not assume a business email address automatically gives another manager administrative control over an individually purchased subscription.
Protect each account using supported authentication controls. The NCSC's account-security guidance recommends two-step verification where available. This adds a second verification step to sign-in. Do not weaken it or circulate recovery codes just to make a shared login convenient.
Choose the smallest workable access arrangement
My default is distinct accounts for people who actually use the application, with paid access limited to evidenced needs. I would not buy seats for everyone before confirming the workload. Equally, I would not accept shared credentials as the price of making an AI trial affordable.
| Arrangement | Suitable workload | Ownership requirement | Main cost to count |
|---|---|---|---|
| Named operator producing reviewed outputs | Infrequent requests with an acceptable queue | Operator owns use; request owner checks suitability | Coordination and waiting as well as the permitted subscription |
| Separate approved individual accounts | Independent low-risk tasks, if terms and policy allow | Each account has a documented owner and recovery route | Actual subscriptions plus fragmented administration |
| Managed workspace with distinct users | Recurring team work needing verified shared controls | Named administrators and documented removal process | Seats, minimum commitments and administration |
| Existing non-AI process | Tasks with little gain or unsuitable data exposure | Existing work owner remains responsible | Manual effort and any existing software costs |
A managed workspace may be the right choice even at higher cost if it provides controls your work requires. Confirm those controls rather than relying on the word “business”. Compare the same data sensitivity and workload across options.
The operator arrangement has limits. A colleague should submit an approved task through your normal work process, not send credentials or bypass a required named seat. The operator must have capacity to review the output. If urgent requests repeatedly wait, the queue becomes evidence for another authorised user or a different process.
A four-person team does not automatically need four paid seats
Consider a fictional design studio with four colleagues. Two need direct daily access; two each request two small transformations monthly. The following figures are illustrative assumptions, not prices for any named service, and exclude VAT because no actual supplier quote is being modelled.
Suppose an authorised account costs £22 monthly and a hypothetical managed plan costs £28 per seat with no minimum. Four individual subscriptions would cost 4 × £22 = £88 monthly. Four managed seats would cost 4 × £28 = £112 monthly. Two individual subscriptions would cost 2 × £22 = £44 monthly if that arrangement meets the studio's requirements.
Under the two-user arrangement, assume four occasional requests require 10 minutes each for briefing, handling and review: 4 × 10 = 40 minutes monthly. Compared with four individual subscriptions, the direct bill is £44 lower, but the team spends those 40 minutes coordinating.
If it assigns an illustrative planning value of £30 per hour to that capacity, 40 ÷ 60 × £30 = £20. This is not a £20 invoice or an observed cash loss. It describes an opportunity cost. The choice remains £44 less cash spending with 40 minutes of coordination, plus any waiting that affects the work.
Add a one-off illustrative 45 minutes to set ownership and recovery, then 15 minutes monthly to review access. Do not hide this administration. If the individual accounts cannot satisfy the data rules, discard that option regardless of the arithmetic. If the two occasional users become daily users, calculate again.
Put the chosen arrangement into operation this week
- In a 30-minute session, list actual users, permitted data and the four connections in the access ownership map. Identify any shared credentials already in use.
- Before the next shared use, check the provider's terms and assign an authorised access route. Preserve necessary work in an approved location before changing access.
- Within two working days, verify sign-in protection, ownership and recovery with the designated people. Follow provider instructions for ending old sessions or revoking access when needed.
- After a month, compare requests, coordination time and seat use. Add access only where the evidence supports it, and remove unused paid access through the provider's documented process.
Stop the rollout if nobody can explain who controls an account or whether its data terms suit the task. Continue that work through the existing process until those specific questions are resolved.
Related guides
Frequently asked questions
Is sharing acceptable if we never use the account simultaneously?
Taking turns does not resolve an account-sharing restriction or establish separate ownership. You still need to check the provider's terms, and sequential users may encounter each other's work or change the same configuration. A timetable addresses demand, not permission. If occasional access cannot justify another account, consider a named operator who performs authorised work and returns a reviewed output. That arrangement still needs suitable data handling and enough time for review. Where the service offers an explicitly permitted shared-resource model, assess its documented controls rather than assuming ordinary personal-account rules apply.
Does a password manager make a shared account suitable?
A password manager can improve how credentials are stored, but it cannot change the provider's licence or create separate identities inside an application. It also does not by itself limit which conversations each user can read. Use password management as part of account security, not as an argument that shared access is now equivalent to named users. Some services have legitimate shared technical credentials with additional controls, but those need a separately approved design. For an interactive personal AI subscription, first resolve whether sharing is allowed and whether individual accountability is required.
Can I use my personal paid account for a work task?
Only if your organisation's rules and the provider's terms permit the particular use and information involved. Paying personally does not settle ownership, confidentiality or retention. Ask who may access the material, what happens when employment ends and where the approved final output belongs. A task using public information can present different concerns from processing customer records, but do not decide that distinction alone when workplace policy applies. If approval is absent, keep the work in the existing authorised process. Reimbursement of a subscription does not automatically turn a personal account into managed organisational access.
Will buying a team plan hide every conversation from colleagues?
Do not assume that. Read the exact workspace documentation for ordinary members, administrators, sharing links, projects and connected services. Visibility may differ between these features, and a setting for one does not establish privacy everywhere. Use synthetic content to confirm the documented sharing behaviour where you can, while recognising that a simple user view cannot reveal all administrative or provider access. Record the limitations alongside your approved input rules. If a particular task requires confidentiality that the account cannot demonstrate, change the workflow or service rather than relying on a reassuring plan name.
What should happen when somebody leaves the team?
Transfer necessary work and confirm a surviving owner's access before removing the departing person's authorised access. Check billing, shared outputs, connected accounts and recovery arrangements as separate items. Then follow the provider's documented removal and session-revocation process. Preserve records according to your organisational requirements without retaining personal material unnecessarily. If the account is individually owned and cannot be transferred, obtain provider guidance rather than impersonating its owner. The departure date should not be the first time you discover this limitation. An existing managed removal process may simplify the task, but verify its effects on stored work.
Is a free account enough for an occasional user?
Possibly, provided the account's current capabilities, usage limits and data terms suit the task. Assess the job the person must complete, including whether they can reliably finish it when needed, rather than assuming free access is unsuitable or interchangeable with a paid plan. Use synthetic information while checking an unapproved service. If occasional limits merely delay non-urgent work, paying may add little value. If the required controls or functionality are absent, a paid account or non-AI method may be necessary. Recheck material restrictions before adoption because plan features can change independently of your team's needs.
Sources and verification
- OpenAI: account-sharing policy, checked on 9 September 2026 for individual-account and multiple-device distinctions. This example does not establish other providers' rules.
- NCSC: creating separate user accounts, checked for organisational ownership and attribution guidance.
- NCSC: securing users' accounts, checked for sign-in protection guidance. No quoted subscription figures are vendor prices.
- The supplied parent-guide text was read locally. Its public category URL could not be retrieved during verification; the supplied editorial path is retained.
This article is practical guidance. Apply it in proportion to your tools, evidence, risks, and responsibilities.
