Client AI Permission: What to Agree When There Is No Policy

Client AI permission should describe the work you actually plan to do. A client who has no written policy has not answered whether you may supply their information to a particular tool. For Nigerian freelancers serving local or overseas businesses, the useful next step is a specific conversation.

This guide separates the tool, inputs, human review and intended use. It includes one survey chart, a data-flow infographic and four downloadable CSV resources. The templates are discussion aids, rather than a universal contract or a compliance certificate.

Client AI permission: what the new US survey adds

Gusto’s State of Small Business 2026, published on 12 November, reports that 25% of businesses with employees had an AI policy, 28% were considering one and 47% had neither a policy nor plans. Those figures concern an employee-business subgroup, not all AI adopters.

Client AI permission context: US businesses with employees reported policy status of 25% existing, 28% considering and 47% no policy or plans.
Figure 1. US policy status offers context for a conversation; it cannot establish permission from your client.

The wider survey covered 1,731 US owners with at most 24 employees, recruited from Gusto customers operating for at least twelve months. Fieldwork ran from 17 August to 7 September 2026, with sector and firm-age weighting. The overall margin of error was ±3.4 percentage points; subgroup uncertainty is larger.

This customer sample does not measure Nigerian policy prevalence. Weighting also cannot remove every difference between Gusto customers and other businesses. Most importantly, a foreign survey cannot tell you what one named client has authorised.

Define one proposed use before asking for approval

Start with a bounded task and deliverable. “Draft a summary from these approved public product pages” is easier to evaluate than “use AI on the project”. Identify the proposed tool and account, rather than leaving the destination unspecified.

Explain the stage at which the tool would be used. A first draft, a factual check and an automated customer response involve different responsibilities. Permission to help draft text does not automatically include permission to send it or publish it.

Also explain the non-AI alternative and any practical effect on the agreed workflow. This gives the client a concrete choice. Avoid presenting a tool purchase or an AI method as an unavoidable requirement unless that follows from the actual assignment.

Trace the input-to-use boundaries

Task and inputs, tool and account, human review, and use or publication each have a clarification stop point. Changed scope requires confirmation.
Each boundary needs its own answer: what goes in, where it goes, who reviews it and how the output may be used.

For each input, record the allowed class of material and any restrictions. A public page, a confidential draft and a customer record are not interchangeable. Supply only what the actual decision permits and what the task needs.

Keep prohibited material explicit. If the client has not authorised a data class or destination, pause that use and clarify. A synthetic demonstration or a suitable non-AI method may help you discuss the task without supplying the uncertain material.

Agree the tool and account precisely

Name the relevant product and account arrangement in the matrix. Do not assume that a free personal account and a client’s managed business account have identical settings or terms. Verify the actual current conditions that matter for the proposed use.

The worksheet includes a field for retention and reuse terms to verify. It does not fill those answers for any vendor. Retain the source and checked date for a relevant condition, and ask an appropriate adviser when the requirement is unclear.

Do not upload confidential information simply to test whether a template works. Use fictional or approved public inputs for a demonstration. A successful technical test would not establish the right to supply the real material.

Assign review and publication responsibilities separately

Name the person who checks the output

Record who will verify factual claims, tone and fit for the task. Identify the source material and acceptance requirement they will use. “Human reviewed” is incomplete if nobody knows who owns the check.

Keep the check proportionate to the consequences of an error. Work involving specialist judgement may require a qualified reviewer. The permission matrix does not grant the freelancer professional authority they otherwise lack.

Record who may send or publish

A client may permit drafting while retaining final approval. Write that boundary plainly, including the approved channel and audience where relevant. Do not turn approval of one sample into standing permission for every future use.

For the separate issue of authority to act on customer requests, see our holiday e-commerce human-review guide. The present article addresses permission for your own tool use before you supply information.

Keep an actionable decision record

Each row should state the task, tool/account, allowed inputs, prohibited material, decision owner and date. Add the review owner and publication boundary. Preserve unresolved points rather than converting a partial reply into a blanket “yes”.

For example, a fictional client might permit drafting from two public pages while prohibiting customer records and reserving publication. This is a discussion example, not an approval from any real client. Your actual record must reflect the named client’s decision.

Our freelance agreement guide can help frame a later scope discussion. Obtain appropriate legal or security advice for the actual obligations; no checklist alone proves compliance.

Revisit permission when the use changes

A different tool, account, data class or purpose may change the original decision. Use the change log to identify what changed and who must confirm the affected scope. Keep the previous record so the history remains understandable.

Until the new boundary is clear, continue only with work that remains authorised. Avoid assuming that urgency expands permission. A short clarification is more useful than a retrospective explanation after information has already been supplied.

Download the evidence and discussion resources

The matrix and log are unfilled. The question examples contain fictional details and require adaptation. None records a real client’s approval or supplies vendor privacy terms.

Method and limitations

We checked Gusto’s report and methodology on 15 November 2026, transcribed the three subgroup percentages and plotted them without estimating counts. The chart retains the subgroup label. Our workflow framework is editorial guidance, not a finding from a Nigerian survey.

Suggested citation: Nigerian Freelance Master, Client AI Permission: What to Agree When There Is No Policy, 15 November 2026. Retain the US population, fieldwork dates and subgroup qualification when quoting the chart.