What to Ask Before Using an Unapproved AI Tool at Work

Direct answer: ask for approval of the exact workflow

Before you send work material to an AI tool, check whether your employer’s policy covers this exact use. If it does not, ask the policy owner to decide on the workflow: task, tool and account, enabled features, information, output, and how that output will be checked. Until you have a answer, use an approved alternative or keep the existing process. A vendor’s privacy or security terms describe product conditions; they do not, by themselves, give you workplace authorization.

An organization may permit a tool for one task but restrict some data, integrations, or uses of its result. The United States University Enterprise Artificial Intelligence Policy and Employee Use Standard illustrates this separation: it asks staff to check the exact tool, feature, account, and integration, then whether each information item is allowed and whether the output could affect a person or public claim. Your employer may set different limits. Microsoft’s Enterprise Data Protection documentation describes protections for some organizational products and configurations, with distinct conditions for web queries and agents. Those vendor terms can inform a review, but cannot replace the employer’s decision.

Sources: United States University — Enterprise Artificial Intelligence Policy and Employee Use Standard; Microsoft — Enterprise data protection in Microsoft 365 Copilot and Microsoft 365 Copilot Chat

Why should I ask about the workflow rather than ask whether AI is allowed?

A broad question such as “Are we allowed to use AI?” sounds efficient, but it can hide several decisions. An employer might permit one service for public information while restricting another account, feature, data type or purpose. It might allow a draft but require a person to check it before sending. The useful question names the whole workflow: what task you want done, which tool and account would do it, what information would go in, and where the result would go. That gives the reviewer something concrete to assess instead of asking them to approve an undefined category of technology. This distinction matters because a system’s capability does not confer workplace permission. A tool may be able to summarize, classify or draft text; that says nothing by itself about whether your organization has approved its use, whether the information is authorized for that service, or whether its output may be relied on. Seeing a colleague use it does not establish that their task, account or data falls within the same rules. The risk can change with purpose and consequence even when the interface looks identical. Summarizing a public guidance page into notes for your own review involves different information and consequences from pasting customer records into a prompt. Drafting a message for a person to check differs from asking for a recommendation that could affect someone’s employment, or connecting a tool so it sends messages automatically. These examples do not establish a universal ranking; they show why the reviewer needs to know what the output will do and who could be affected. The National Institute of Standards and Technology’s *Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile* treats risk as dependent on context and describes its profile as voluntary guidance for organizations. Its suggested actions include policies for acceptable uses and human-AI configurations, attention to third-party components, and organizational oversight. This supports asking about purpose, system and handling together; it does not prescribe your workplace’s approval chain or create permission for an employee. A current United States University employee policy illustrates how an employer can turn that idea into a gate: it asks whether the tool is approved, whether information is permitted for that tool, and whether the proposed use is low risk or needs review. The policy says to seek guidance if an answer is uncertain, and assigns responsibility for review and accountability. This is one university’s rule, not evidence that every employer uses the same test. So describe the task in terms an approver can answer: “May I use this account and feature to summarize these public documents into an internal draft, with a person checking it before it is shared?” If the intended use involves customer details, a consequential recommendation or automatic action, say so plainly. Ask what part is approved and what conditions apply. Until current policy or a clear decision covers the exact workflow, continue with an approved alternative or the existing process. The request is therefore about this task’s boundaries, not an abstract endorsement of AI.

Sources: NIST — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile; NIST — AI Risk Management Framework; United States University — Enterprise Artificial Intelligence Policy and Employee Use Standard

What should I check before asking for an exception?

Before requesting an exception, check whether your employer has already answered the question in a current policy. Look for an AI acceptable-use policy, approved-tool list, information-classification guide, records rules, and task-specific instructions. Read for scope and decision route, not just the headline. The IPC Generative AI Policy tells its own staff to check whether an open-access use is prohibited and whether it is pre-authorized; it lists task types subject to conditions, requires approval for other uses, and specifies training and work-account rules. The United States University Enterprise Artificial Intelligence Policy and Employee Use Standard gives its employees a three-question test: is the tool approved, is the information permitted, and is the use low risk or does it need review? If any answer is uncertain, it says to stop and seek guidance. These are organization-specific rules, not universal requirements. They show why “we allow AI” may leave the practical boundary unanswered. Use a coverage test before deciding that a policy applies. Match the tool and service, account or organizational tenant, feature path, information category, task purpose, your role, and output destination or audience. A work account may be treated differently from a personal account; a chat feature may differ from an integration that accesses files; an internal draft may differ from material sent to a customer. Check these points against your employer's wording rather than assuming every system behaves alike. Where the policy names a version or configuration, verify that yours matches. Next check whether the policy is current and identifies a route for exceptions. An old saved copy may omit a later restriction or process. Note its revision date, linked tool register, relevant section, and contact or role for questions. The IPC policy names an approval route and risk-assessment process for uses outside its pre-authorized list. If documents name possible reviewers, ask which has authority for this specific task. The British Business Bank's published IT Acceptable Use Policy is another organization-specific reference for an employer-defined technology boundary. AI instructions may sit inside broader IT rules, not only a document titled “AI policy,” so check relevant acceptable-use, confidentiality, data-handling, records, and contractual guidance. Do not copy another institution's rule into your workplace decision: the IPC serves a NSW public-sector context, USU sets rules for its workforce, and the British Business Bank has its own scope. If every part of your workflow fits a current, explicit authorization, follow its conditions. If a part is missing, conflicts with another rule, or is unclear, define that gap. Ask the policy owner or designated reviewer whether the exact task, account, feature, information, and output are covered or need an exception. This check may avoid an unnecessary request when permission already exists; otherwise it gives the reviewer a precise question instead of asking them to approve “AI” in general. The relevant document may be separate from the tool list, so check links and cross-references before concluding no rule exists.

Sources: Information and Privacy Commission NSW — Generative AI Policy; United States University — Enterprise Artificial Intelligence Policy and Employee Use Standard; British Business Bank — Information Technology Policy

What information and features must the approval cover?

Name the information the task needs, then ask what the particular service is allowed to receive and how it handles that information. Describe whether it is public, internal, personal, confidential, or otherwise restricted. Do not paste a real example into the unapproved service to clarify the request. Use the employer’s own data labels where available. A task description can remain useful without examples. Ask whether prompts, uploaded files, generated responses, and any context drawn from connected work systems are retained, used to improve or train a service, or available to administrators or other users. Ask where processing occurs and who can access stored interactions. A general claim that a product is “private” does not answer them. The NSW Information and Privacy Commission’s May 2026 guide identifies prompts, files and outputs as possible routes for personal information to be handled, and says providers’ practices differ. It is guidance for NSW public-sector agencies, not a universal account of every provider or a rule for every workplace. Also identify the path through which information would move. A chat box may be only one part of the workflow: a task could involve an uploaded spreadsheet, a browser reading an internal page, web search, a plugin, an agent, or an integration that sends the result to another system. Ask which of those features are enabled, what information each can access, and whether the requested use can be limited to the basic feature needed. If the task only requires summarizing a public manual, for example, ask whether the document can be supplied without internal notes or connected account context. If it needs an internal file, ask whether an approved work environment can access only that file rather than a broader collection. Present alternatives for review; do not try them first. Microsoft’s enterprise data protection documentation is a useful example of why the exact configuration matters. For organizational Microsoft Copilot and Copilot Chat, it describes protections under Microsoft’s data protection terms, but says specific controls vary by subscription. It also explains that web-search queries follow separate data-handling practices and directs users to check an agent’s own terms and privacy statement. This vendor documentation covers named products and configurations; it says nothing about another provider or your employer’s setup. Product protections do not authorize a task. Ask your reviewer to confirm the account or tenant, license, settings and connected features covered by any approval. Then compare the minimum information needed with what the task currently contains. Could you answer using public sources? Could you remove names, account numbers, contact details, confidential passages or unrelated rows before a reviewer-approved workflow? Could an approved tool or existing template do the job without sending the material elsewhere? Redaction may reduce exposure, but combinations may still identify someone and employer rules may still restrict the material. The NSW guide notes that prompts and files may contain information about identifiable people, while outputs can also create information or opinions about them. That is why the reviewer should assess the data category and workflow, not just whether a name is visible. A practical request can state: “For [task], may I use [tool, work account and feature] with [data categories]? It would produce [draft, summary or other result] for [audience]. The workflow would not use [unneeded data or connected feature]. Please confirm retention and access expectations, whether this configuration is approved, and what review is required before I rely on or share the output.” Ask for any required limits in writing. Until the employer confirms the exact combination, keep real work material out of the unapproved tool. The goal is to let the reviewer decide whether an approved environment or reduced-data version can meet the task without first testing the unknown service on workplace information.

Sources: Microsoft — Enterprise data protection in Microsoft 365 Copilot and Microsoft 365 Copilot Chat; Information and Privacy Commission NSW — Guide: Privacy risks associated with the use of generative AI tools; British Business Bank — Information Technology Policy

Who decides, and what should I put in the request?

Ask your manager or policy contact who owns approval for this workflow. The right reviewer depends on what it touches: routine drafting may follow a manager’s process, while personal records, customer data, code, regulated material, or consequential actions may need technology, security, privacy, legal, records, procurement, or a data owner. Ask where requests go and whether your manager can decide or should route it. The United States University policy is one example, not a rule for other employers. It names an AI Governance Committee for tool and use-case approval, gives managers responsibility for authorized use in their areas, and lists potential reviewers including technology, cybersecurity, privacy, legal and procurement. Its employee guide asks whether the exact tool, feature, account and integration are approved, whether information is permitted, and whether the use needs review. The IPC Generative AI Policy applies to NSW Information and Privacy Commission staff and contractors and has its own risk-assessment route. The employer’s current policy or intake channel should control; neither policy establishes a universal reporting line. Give the reviewer a decision-ready description instead of asking, “Can I use AI?” State the problem and intended result. For example: “I prepare an internal first draft summarizing public product manuals; I will check each factual statement against those manuals.” Compare: “I want to analyze customer case notes and send individualized recommendations.” These examples do not establish approval. The latter makes customer information and recommendations visible, so the reviewer can assess data permissions and impact. A concise request could say: “For [task and purpose], may I use [named tool, account, feature or integration] with [information categories]? The output goes to [audience or system] for [limited use]. I propose [checks, reviewer, disclosure or recordkeeping]. Is this within policy, or who must review it? What scope, conditions, training, documentation or end date apply? Meanwhile I will use [approved tool or existing process].” Do not attach sensitive material whose handling is in question. This template synthesizes the USU policy’s request fields: problem, desired outcome, current process, tool and integrations, affected users, data, risk, human oversight, fallback and relevant reviews. Its appendix also lists vendor, features, integrations, data classification, oversight, fallback, affected users and review considerations. Its formal process covers introducing or expanding uses, so a one-task question may be shorter. The IPC policy also separates permitted, prohibited and approval-required uses and provides risk assessment for other uses. Neither source requires every employer to use these forms. Give the owner enough context to decide without testing on real work content. Ask for the decision and boundaries in a recordable form, such as the employer’s ticketing system or the channel its policy specifies. Confirm whether it applies to you or a team, which account and features it covers, allowed information, output destination, and required checks or training. Ask whether it expires or must be reconsidered if the task, data, tool or integration changes. The USU policy, for example, requires documented, narrowly scoped, time-limited exceptions and reassessment after material changes. That is its rule, not a deadline to assume elsewhere. If the reviewer cannot decide, ask who owns the next step and what approved workflow to use meanwhile. A record helps you follow conditions; it does not guarantee accuracy. You can send this short version: “I want to [task] for [purpose]. The tool/account/features are [details]; information is [categories]; output goes to [destination] for [use]. I would check it by [method] and keep a person responsible for [decision or release]. Is this authorized under current policy? If not, who should review it, and what approved process should I use meanwhile?” Wait for an answer covering the relevant pieces before submitting work material. Vendor terms describe a service; they do not identify who at your employer may authorize the workflow.

Sources: United States University — Enterprise Artificial Intelligence Policy and Employee Use Standard; Information and Privacy Commission NSW — Generative AI Policy; NIST — AI Risk Management Framework

What should I ask about checking and using the output?

Before relying on an output, ask what it may be used for, who must check it, what evidence they should use, whether AI assistance must be recorded or disclosed, and who remains accountable. A tool may help prepare an internal draft while its output is unsuitable for sending to a customer, publishing, or making a decision. Get the boundary stated in terms of the deliverable and audience, not just an instruction to “review the answer.” Ask the reviewer to make verification concrete. For a summary of public source documents, should you compare statements with the original passage and keep a citation? For a calculation, should you recompute figures from underlying data rather than accept a plausible-looking result? For code, which tests or human review are required in the authorized environment before it can be merged or run? The approval should identify evidence available to the checker and when a result must be rejected or escalated. For example, a draft may be checked against cited source passages, while a calculation needs comparison with the underlying figures. The NSW Information and Privacy Commission’s Generative AI Policy offers an example of an organization spelling out conditions for its own staff, including checks on permitted use and records requirements. The United States University Enterprise Artificial Intelligence Policy and Employee Use Standard asks whether a proposed use could materially affect a person or support a public claim, and calls for appropriate human review. The British Business Bank Information Technology Policy also directs users to verify outputs. These documents show that organizations can attach review, recordkeeping, and use limits to AI work. They apply to particular organizations and settings; they do not establish a universal checklist or tell you what your employer requires. “Human in the loop” is not a complete control unless the named person can do the work. Ask who has knowledge, time, source access, and authority to correct or reject the output. If the reviewer only skims an answer, review may not catch an error. Ask whether the reviewer must document sources checked, changes made, or reasons for accepting a result, and whether another approval is required before a consequential action. Checking a draft for factual support is not the same as validating advice that could affect someone’s access, treatment, money, or work. Ask whether internal recipients, customers, clients, or the public must be told that AI assisted, whether the prompt and final version belong in an approved record, and which person signs off. Do not assume disclosure is always required or never required; the answer depends on employer policy, audience, work, and applicable obligations. Disclosure also does not transfer responsibility to the tool. The employer should identify who owns accuracy and follow-up if a recipient questions the result. A useful approval names the allowed output, destination, reviewer, evidence standard, record or disclosure requirement, and accountable owner. If any remain vague, ask a focused follow-up before sending or acting on the result. It is to know what check is expected, who can perform it, and where the output may go. Only then can you decide whether the workflow is usable within the authorization granted.

Sources: Information and Privacy Commission NSW — Generative AI Policy; United States University — Enterprise Artificial Intelligence Policy and Employee Use Standard; British Business Bank — Information Technology Policy

What if the answer is no, unclear or late?

Treat an unanswered request as unresolved, not as permission. A vague response such as “be sensible” or “people use it all the time” does not identify which account, information, features, or outputs are allowed. Ask what you can do while a decision is pending: Is there an approved tool for the task? Can the work stay in its current process? Who owns the decision, and when should you follow up? That gives you a next step without placing company material into a service whose status is unknown. The United States University employee guide directs unsure staff to its approved-tool route or request process, and identifies steps for unexpected behavior. This is one institution’s procedure, but it illustrates why uncertainty needs a named route.

There are three practical options. First, use an approved tool and account if its documented scope covers the task, information, features, and output. This offers the clearest authorization path, though result checks or input limits may still apply. Second, request a bounded review of the unapproved workflow. Describe the task, minimum information, account and connected features, output destination, and proposed human check. This may preserve usefulness if the employer approves that scope, but a pending request is not permission. Third, continue with the current authorized process or an approved alternative. It may take longer, yet lets work proceed without assuming approval. The British Business Bank’s information technology policy illustrates an organization specifying an enterprise boundary, permitted information categories, output checks, and incident reporting. Those provisions apply to that organization, not every employer.

Compare the options by authorization clarity, information exposure, reviewability, delay, and whether the result still meets the task. A familiar interface or fast answer addresses convenience, not authorization. Urgency also cannot supply a missing decision. If a deadline is near, tell the manager or requester what is blocked, ask which approved route to use, and agree on scope or timing. You can prepare without disclosing work material: outline questions, organize authorized sources, draft a review checklist, or identify unnecessary fields. These steps preserve progress while keeping sensitive input out of the unapproved service. This is a cautious approach inferred from the different controls in the cited policies, not a universal procedure.

If the answer is no, keep the task out of that tool and ask what approved alternative meets the need. A refusal may concern one account, feature, data type, or use. Ask whether a narrower version can be reviewed, such as a draft based on public material, kept internal and checked before use. Do not treat a refusal as approval to switch to a personal account or reword a prompt. If no permitted alternative is clear, ask the responsible manager or policy contact how to complete the work through the established process. The aim is to learn the boundary for this task and meet the work obligation within it.

If material has already been entered, treat it as a possible incident, not an invitation to experiment further. Stop adding information and promptly use the employer’s incident channel or contact named in its policy. Report factually which service and account you used, what kind of material was submitted, when, and whether an output was copied or shared. Do not speculate about retention or access; leave that assessment to the organization. The United States University guide and British Business Bank policy both include incident routes, but their procedures are organization-specific. Follow your employer’s process. While review is pending, ask for the approved fallback and decision owner; after refusal, use a permitted alternative; after submission, report promptly. Silence is not a decision, but a clear next action can keep work moving.

Sources: United States University — Enterprise Artificial Intelligence Policy and Employee Use Standard; British Business Bank — Information Technology Policy; Information and Privacy Commission NSW — Generative AI Policy

How does the answer change across ordinary work examples?

Consider an illustrative task: turning public product manuals into an internal draft. Because the input is public and the output remains internal, the request may be narrower, but permission still needs confirmation. United States University's policy lists summarizing public documents among generally acceptable low-risk uses, while still requiring an approved tool and human review. The IPC Generative AI Policy permits certain public-information tasks under its own conditions, including no personal information and compliance with restrictions. These are examples, not a rule that public-source drafting is automatically approved elsewhere. Ask whether the account and feature are approved, whether the output may remain an internal draft, and what checking is required. If a written policy covers those particulars, follow its scope; otherwise, ask before entering prompts.

Now change the input: drafting a reply using details from a customer record. The prompt contains identifiable information and an error could affect the customer. Ask whether this data category may enter this tool and account for this purpose, whether identifiers can be removed, and who must review the reply before sending. The IPC Generative AI Policy bars personal, sensitive or confidential information in prompts to open-access tools under its own rules. United States University's policy separately requires authorization for both the tool and specific data use, with deeper review as consequences rise. Neither policy dictates another employer's answer. Check whether any existing approval covers the same data, feature and recipient; if not, do not test the boundary with a real customer record while waiting.

A third illustrative task is asking an AI feature to inspect source code or recommend a system change. The input might reveal proprietary code or security details, and the output could affect more than a draft. Ask whether this tool and feature may receive the code, whether connectors or execution functions are enabled, whether output is advisory, and who will inspect and test a proposed change in an authorized environment. United States University's policy treats source code, system configurations and security details as requiring special protection; it also says integrations need approval and review should rise with the consequence of error. That is a university example, not a universal classification. An employment recommendation raises a related issue: even with permitted input, ask whether AI may inform it, who decides, and what human review applies before any consequential use. The IPC policy, in its public-sector functions, bars open-access AI from specified statutory decisions and recruitment-related uses, illustrating that task purpose can matter alongside data. Across examples, four facts could change the request: written approval covers this workflow; the task can use less sensitive information; an integration can be disabled; or output can stay an internal draft for qualified review. State those facts instead of assigning your own risk score. If a point remains unresolved, ask about it and continue through the approved process meanwhile. A code suggestion that is never executed has a different path from an agent that can edit files or run commands; describe which one you propose. Likewise, an internal draft differs from a recommendation sent to a customer or used in a personnel decision. The reviewer needs those destinations and actions to set a usable boundary.

Sources: United States University — Enterprise Artificial Intelligence Policy and Employee Use Standard; British Business Bank — Information Technology Policy; Information and Privacy Commission NSW — Generative AI Policy

Your next step: send a bounded approval request

Before using an unapproved tool, write down the task, the exact tool and work account, any connected features, the information involved, where the output would go, and how you would check it. Compare those details with the policy and approved-tool list. If the policy does not clearly cover this combination, ask its named owner for a decision; do not enter work material while you wait. The United States University employee guide illustrates why: it asks staff to check the exact tool, feature, account and integration, the permissibility of each information item, and whether the output could materially affect someone.

A concise request could read: “I need to [task] using [tool, work account and features]. The input is [data category]; the output will be [destination and audience]. May I use this workflow? If so, what limits apply to the data or features, what review or record is required, and who should approve it? If not, which approved tool or existing process should I use?” Keep the task moving through that authorized alternative until you have a scoped answer. If the question is really which parts of your role are changing, the free task checker can help map task-level change pressure; it cannot authorize a tool or predict job loss.

Sources: United States University — Enterprise Artificial Intelligence Policy and Employee Use Standard