Before staff use a particular AI tool with identifiable or confidential client material, the firm should be able to explain and evidence two separate boundaries: which people inside the firm can use the tool and handle that information, and which people or roles at the AI provider can access it. If either boundary is unclear, cannot be limited, or cannot be checked, pause use of that material until the firm has resolved the gap.
Decide who can use the tool and with what information
Do not treat access as a simple yes-or-no question. A useful decision starts by mapping the people, work and information involved. A solicitor preparing advice, an accountant reviewing client records, an insurance adviser assessing a claim, and an operations administrator may have different work needs and different reasons to access a tool or its outputs.
For the proposed use, identify:
- Users and roles: Which teams and named roles need access, and who owns the decision to grant it?
- Work and data: What task will the tool support, and could the input or output include identifiable, confidential, privileged or commercially sensitive client information?
- Firm-side permissions: Can the firm limit tool access to the people and roles that need it, and separately control administrative privileges?
- Provider-side access: What access can the AI provider's personnel or support roles have to account data, prompts, files, outputs and settings? Which provider roles can administer the service?
- Lifecycle and evidence: How are access changes and departures handled, how often are permissions reviewed, and what records can the firm inspect?
These are buyer checks, not assumptions that a particular product supports a specific control. Ask the provider to explain the relevant controls and provide evidence that is appropriate to the proposed use. If the answer is vague, ask for clarification rather than treating a policy statement or product description as proof.
Keep firm permissions separate from provider access
The firm's user permissions determine who in the firm can access the AI tool and use client information through it. Provider access controls concern who at the AI provider can access the service environment or customer information, and under what circumstances. A firm may manage its own users while having limited visibility into provider personnel access; a provider's access controls do not, by themselves, restrict which firm staff can use the tool.
Assess both sides for the actual account, configuration and use under consideration. Ask which provider roles may access customer content, what purpose permits access, how such access is authorised and recorded, and what information the firm can review. Do not infer that a control exists because it is common in similar products or mentioned in general marketing.
Set a clear boundary before client information is entered
Use a practical tiered decision. For each proposed use, state what data may be entered, which roles may use the tool, what review is required, and what conditions trigger a pause. For example, a firm might allow an approved team to test a use case with non-identifiable material first, while requiring additional checks before identifiable or confidential client material is considered. The firm should decide the boundary based on its own information, engagement and professional context.
Pause the proposed use of client material if:
- the firm cannot identify who has access or explain why each access role is needed;
- administrative access is broader than the firm can justify or monitor;
- the provider cannot clearly explain relevant personnel access or the firm cannot obtain enough evidence to assess it;
- access cannot be removed promptly when a user changes role or leaves;
- the information the tool receives, retains or makes available to others is unclear for the proposed use; or
- the firm cannot keep a usable record of the tool, approved use, permitted data, access decision and review owner.
A written policy can describe expectations, but it does not itself enforce permissions. Confirm how access is actually configured, changed and reviewed.
Put the checks into a repeatable review
- Describe the use case. Name the task, users, client-data categories, expected outputs and responsible business owner.
- Map both access boundaries. Record firm user roles and administrator privileges separately from provider personnel and service access.
- Ask for specific evidence. Request explanations and records relevant to permissions, access changes, review and provider access. Record what was provided, what remains unknown and who assessed it.
- Configure and test the intended limits. Check that the actual account and settings match the approved user group and data boundary. Do not rely only on policy wording or a sales assurance.
- Assign ongoing ownership. Set who reviews access, how role changes and departures are handled, and when a material change in tool, provider or use case requires reassessment.
Keep a concise record of the decision: the tool and use case, permitted users and data, firm-side and provider-side access findings, evidence reviewed, unresolved points, reviewer and next review trigger. This helps the firm revisit the decision when the team, configuration, service or intended data changes.
Source and scope
The buyer question follows an issue raised in Vanta’s vendor-authored guide, Top questions to ask AI vendors during a security review, which asks whether providers restrict access to AI systems by user role. The guide offers due-diligence questions, not independent assurance or evidence about a specific product’s controls. The checks here are practical review recommendations, not a determination of legal or professional duties.
Discuss the access decision
Discuss your firm’s access boundaries and next step on a discovery call. If you first need a structured view of use cases, information and controls, see the AI Risk & Efficiency Audit.
