Simple rules for AI at work.

01 / Tool approval

An approved tool is only the start.

The name on the login screen tells you very little about the risk. The same product can rewrite a sentence, search confidential files, publish a customer answer, or operate another system. Each task needs different rules.

The tool list also ages quickly. Models, connectors, memory, browsing, and agent features change faster than most policies are reviewed. Rules written around one interface can become obsolete without anybody changing the document.

Employees are already using these tools. Verizon’s 2026 Data Breach Investigations Report found regular GenAI use on corporate devices had reached 45%, and 67% of those users accessed AI through non-corporate accounts. The practical question is no longer whether employees will use these tools. It is whether the safe route is clear and useful enough to become the normal route.

02 / Three questions

Ask three questions about each task.

Use plain categories people can remember.

1. 01

   What data goes in?

   Public, internal, or restricted. Restricted includes personal data, credentials, source code, legal material, customer records, and anything governed by contract or regulation.

2. 02

   Who can be affected by the output?

   Only the employee, an internal team, a customer, or the public. Reach matters because errors become harder to contain once the output leaves the desk.

3. 03

   What authority does the system have?

   Suggest, draft, recommend, decide, or act. An assistant that proposes a CRM update is not the same as an agent that can make it.

Use the highest-risk answer. A private draft with restricted data still needs restricted-data controls.

03 / Four levels

Use four levels.

Ordinary work should move quickly. Risky work should be harder to do by accident.

This mirrors the useful part of modern AI regulation: controls rise with consequence. The EU AI Act treats employment and worker-management systems as high-risk uses, while most low-risk AI use remains outside that category. It also requires logging, human oversight, robustness, and traceability for high-risk systems.

Exact legal duties depend on the use and jurisdiction. The basic rule is still useful: a grammar edit and a hiring decision need different approval paths.

04 / Approved tools

Give people a safe tool that works.

“Do not use personal accounts” is not a control unless employees have a company account that works. Provision the approved workspace, connect identity, remove access when people leave, and make the permitted use cases clear inside the tool.

A managed workspace should be checked for:

• Contractual terms for prompts, outputs, and model training
• Single sign-on, automated provisioning, and role-based access
• Retention settings that match legal and operational needs
• Audit or compliance logs that can reach the existing security workflow
• Controls for browsing, memory, connectors, sharing, and third-party tools
• Data residency and encryption where the use case requires them

Current enterprise products from major providers expose many of these controls. These controls help. They cannot make an answer correct, stop every bad action, or decide whether a use is lawful.

05 / Review

Put review before the risky step.

“Keep a human in the loop” is too vague. Name the step, the reviewer, and what that person can inspect. The reviewer needs the source and the power to stop or reverse the action.

This matters more as tools become agents. OWASP’s latest agentic security work calls out tool misuse and identity or privilege abuse as distinct risks. The employee may ask for a reasonable result while the system reaches too far to produce it. Limit the tools and permissions the agent can reach.

06 / Training

Train people on their own work.

Training should use the work each team does. Finance needs examples about forecasts and confidential numbers. Sales needs examples about customer data and generated claims. Engineering needs examples about source code, credentials, and tool access.

This is also the shape of the EU AI Act’s AI literacy requirement. Training should account for the person’s experience, the context of use, and the people who may be affected. The obligation has applied since February 2025, with national supervision beginning in August 2026.

One person should own the operating policy. Security, legal, data, and affected teams contribute where their expertise matters, but the final owner must be able to approve a tool, stop a use, and change a workflow. A committee can advise. It cannot be the name in the incident log.

07 / What to track

Track mistakes and corrections.

Review use and results at the workspace and task level. Look at an individual only when a real security, legal, or quality issue requires it.

Give each log a reviewer and a clear next action.

08 / First steps

Start with what people use today.

Start with the tools people use now, including personal accounts and browser tools. Then add the smallest set of rules that makes the work safer.

1. 01

   Inventory actual tools, accounts, connectors, and recurring tasks.

2. 02

   Define public, internal, and restricted data in company language.

3. 03

   Rate each recurring use on data, reach, and authority.

4. 04

   Provision the approved route and configure its access and retention.

5. 05

   Put approval, logging, and rollback before high-risk steps.

6. 06

   Train each role on two real tasks and one clear failure case.

7. 07

   Review incidents, provider changes, and sampled outcomes every month.