How should a company roll out AI to 100 mostly non-technical employees?

Begin with business work and risk classes

Do not start by asking, “Which AI product should everyone receive?” Start with, “Which recurring task is painful, common enough to matter, and safe to test?” A license can be useful, but it is an implementation choice. The business case begins with a task, an owner, a baseline, a risk level, and a way to tell whether the work improved.

Ask each team to nominate two recurring tasks. For each one, record the starting point, who performs it, inputs, desired output, systems touched, data classification, current time or error burden, what a bad answer could cause, whether a person can review it, and how easily the action can be reversed. This small inventory exposes whether a proposed use case is genuinely ready or merely interesting.

This is not a statement that medium or high-risk work can never use AI. It is a sequencing decision. A 100-person company learns more safely from four low or medium-risk workflows with clear outcomes than from unrestricted access across every job.

NIST's Generative AI Profile explains that AI risk management must reflect the organisation's goals, resources, legal requirements, and priorities. It provides suggested actions rather than one universal implementation. NIST AI 600-1 ISO/IEC 42001 likewise applies an AI-management-system approach to organisations that use, provide, or develop AI systems, with continuous improvement rather than a one-time deployment. ISO/IEC 42001

Give the rollout clear ownership

An AI rollout can fail when every department buys tools but no one owns the outcome, risk, or employee experience. Put a small working group in place before the pilot. It needs authority to say “not yet” as well as “yes.”

Employee consultation is operationally useful, not just a communications exercise. The people who perform a task can identify exceptions, hidden work, misleading outputs, and quality requirements that a leader may not see. OECD case-study evidence found that worker involvement helped prototype development and testing because workers could identify mistakes and redirect the technology toward useful work. OECD workplace case studies Where a union, works council, or consultation duty exists, involve the appropriate representatives early and follow the applicable agreement or law.

The first 30 days establish a safe starting point

The first month is about reducing ambiguity. Do not promise that everyone will save a fixed number of hours. The output should be a small, transparent pilot that employees understand and can support.

Keep the pilot intentionally narrow. Four teams with five to eight participants each are enough to reveal training gaps and control failures without creating a support crisis. Employees should be invited because the workflow is relevant, not because their personal output must be compared with colleagues'. If participation must be mandatory because of a formal job change, communicate that separately and consult HR or worker representatives before treating the activity as a “pilot.”

Choose a limited pilot with a simple scorecard

Score each candidate task from 1 to 5 on five questions: How often does it occur? How much does the existing process slow work or create rework? Can the input stay within an approved data boundary? Can a knowledgeable person review the output before it matters? Can the result be measured without recording individual prompts or monitoring personal productivity? Start with tasks that score high on usefulness and reviewability, and low on data sensitivity and consequence.

Hypothetical example: An operations team repeatedly answers staff questions about travel expenses. The first proposal is a free-form assistant with access to all shared drives. The task is common, but the access design is too broad. The redesigned pilot uses only the approved expense-policy pages, provides citations, has no action capability, and tells the user to route exceptions to Finance. The takeaway is that narrowing the data and action scope can turn a risky idea into a testable workflow.

Set policy and controls before broad access

The policy should be short enough to use. It should not read like a legal memo, but it must state practical boundaries. Pair it with configurations and support, because a policy alone will not prevent shadow AI.

Minimum acceptable-use policy

The policy should say, in plain language:

• Use only company-approved AI services for company work. Do not create a personal account to process company tasks when an approved path exists.
• Do not enter restricted or confidential information unless the service, account type, feature, and use have been explicitly approved for that classification. Give examples that match the company, such as customer records, source code, contracts, credentials, pricing, employee information, financial information, health information, and security incidents.
• Treat outputs as drafts. Verify important facts, calculations, citations, and customer-facing statements. A person remains accountable for the final decision, message, or action.
• Do not ask a model to make employment, legal, financial, medical, safety, or other high-impact decisions without the approved process and qualified review.
• Disclose permitted AI assistance where a client, regulator, contract, or internal policy requires it. Do not misrepresent generated work as verified analysis.
• Report a suspected data exposure, harmful output, security issue, or unexpected automated action promptly. Reporting in good faith will not be treated as a performance failure.

Give employees a one-page version, a fuller internal policy, and examples that show the difference between an allowed and prohibited action. Update it when a major new capability, integration, or legal obligation changes the risk.

Identity, data, and system controls

Where the selected service supports them, use company-managed accounts, single sign-on, multi-factor authentication, and group-based access. Do not share accounts. Use separate groups for pilot users, champions, administrators, and any higher-privilege feature. Review access before a team gains a new connected data source, and remove access immediately when an employee leaves or moves roles.

NIST's Cybersecurity Framework 2.0 identifies managed identities and credentials, authentication, and access limited according to risk as core protection outcomes. NIST CSF 2.0 Apply the same principle to AI features, data connectors, saved prompts, bots, and automations. A generic chat interface and an agent that can access a CRM or send messages do not belong in the same risk class.

Configure the service to match the approved use. This may include disabling public sharing, restricting external connectors, setting retention and export options, applying data-loss controls where available, limiting web or tool access, and putting spend alerts or caps in place. Do not assume a vendor's default consumer setting meets company policy. Record the configuration, owner, data classes approved, and date of the review in a small tool register.

Procurement questions that change the decision

Before purchasing or expanding a service, get clear answers to these questions:

• What exact product, account tier, model options, and connected features are included?
• What company data can the provider receive, retain, use for service improvement or training, disclose to subprocessors, or transfer across borders?
• Can the company control user identities, remove access, export required records, and delete data at contract end?
• What security, privacy, availability, incident-notification, accessibility, and support commitments are contractual rather than marketing claims?
• Can the product meet the organisation's accessibility needs, including keyboard access, screen-reader compatibility, captions or transcripts, language needs, and alternative formats?
• How are pricing, rate limits, feature changes, model changes, and automated actions controlled?
• What happens to data, integrations, and user access when the pilot ends or the company changes vendors?

For accessibility, test the actual workflows with affected users rather than relying on a product claim. WCAG 2.2 is a technology-neutral standard for accessible web content and includes requirements relevant to keyboard operation, visible focus, input, and authentication. W3C WCAG 2.2

Make training about real work

Mostly non-technical employees do not need a lecture on model architecture. They need to know when the tool is appropriate, what data can enter it, how to ask for a useful first draft, how to check the result, and where to get help. Use the pilot teams' own harmless or sanitised examples.

Run a 60-minute team session for each workflow, followed by a short practice task and a written cheat sheet. The trainer should demonstrate a good request, a weak request, a plausible but incorrect output, and the correct escalation path. Then hold weekly office hours during the pilot. Champions can help peers with workflow questions, but they should be able to say “I do not know, ask the rollout team” when a question involves data, contracts, HR, or legal risk.

Offer training in accessible formats. Provide live captions or a transcript, written examples, recordings where appropriate, keyboard-accessible materials, and a way to ask questions privately. Do not make high-speed typing, visual interpretation, or public demonstration a condition of participation. A non-AI alternative workflow must remain available when a tool is inaccessible, ineffective for a worker, or inconsistent with an agreed workplace adjustment.

Measure outcomes without measuring people

The rollout should answer whether a workflow got better, not identify who typed the most prompts. AI-assisted workplace surveillance can create privacy, autonomy, and psychosocial risks. The ILO reported in 2026 that intrusive AI surveillance and loss of autonomy can be associated with work intensification, privacy concerns, and risks to workers' well-being. ILO workplace surveillance analysis

Measure at the workflow or team level, with advance notice about what is collected and why. Do not read prompt contents for productivity scoring, record keystrokes, rank employees by usage, infer effort from tool activity, or use pilot metrics in compensation, discipline, or performance review. Those practices distort behaviour and encourage employees to hide useful concerns.

Set a baseline before users receive the tool. For example, a support team can sample 20 standard replies for two weeks, record the time to a reviewed draft and the number of corrections, then use the same rubric on 20 comparable pilot replies. A small sample is enough for an early decision if the result is treated as directional, not as a promise of a companywide percentage gain.

Share the aggregated findings with the pilot teams, including what failed. OECD research on algorithmic management reports that consultation, guidelines, risk assessments, audits, and complaint channels are used as organisational governance measures, but it also notes that their effectiveness needs further evidence. OECD algorithmic-management evidence Consultation must be paired with a real ability to change or stop a pilot.

Days 31 to 60 improve the pilot rather than widen it

The second month is where most value emerges. Staff have encountered exceptions, controls have been tested, and the organisation has evidence rather than assumptions.

Prevent shadow AI by making the supported route easier than the prohibited one. Employees often seek outside tools because the approved process is slow, unavailable, or unclear. Provide a lightweight request form for a new use case, a response target such as five business days for low-risk requests, a published approved-tool list, and a safe way to ask “Can I use this?” without embarrassment. The answer may be no, but it should explain the boundary and offer a workable alternative.

Do not answer shadow AI only with blocking and warnings. Those may be necessary for high-risk data, but the long-term control is a useful approved option, specific training, managers who do not demand impossible productivity gains, and a culture where staff can report a mistake promptly. NIST's AI RMF identifies governing practices, lifecycle risk management, monitoring, and incident response as connected activities rather than isolated compliance tasks. NIST AI RMF Core

Days 61 to 90 decide what deserves scale

At 90 days, the company should not ask whether “AI adoption” succeeded. It should decide the status of each individual workflow: scale carefully, redesign, pause, or stop. Scale only work that has a named owner, evidence of value, a manageable risk profile, accessible training and support, an offboarding path, and documented controls.

Stop criteria should be written before the pilot

Write the stop criteria on each pilot card at the start. Examples include an unauthorised data disclosure, an automated action beyond the permitted scope, a repeated factual error that reviewers cannot correct efficiently, a material accessibility failure without an adequate alternative, a team-level quality decline, unexplained spending, or evidence that staff feel compelled to use the tool to meet performance expectations. A stop is not a failed transformation programme. It is a successful control response.

NIST recommends connecting measurement to deployment context and consulting domain experts and relevant end users. It also calls for plans to respond to and communicate about incidents. NIST AI RMF Core Treat the sponsor's scale decision as one such documented risk decision.

Build support, reporting, and offboarding into the service

Create two easy channels from day one. The first is ordinary support for access, training, workflow questions, and accessibility barriers. The second is an incident or concern channel for suspected data exposure, unsafe output, unexpected action, bias concern, security issue, or policy breach. The channel should state what to include, such as the time, tool, feature, data category, and a safe description of the event, but it should warn staff not to paste sensitive content into the report.

Publish a simple response model: acknowledge quickly, contain access or sharing where necessary, preserve records under the incident process, investigate with the right owner, notify affected parties when required, fix the control or policy, and communicate the lesson in a privacy-preserving way. Do not make the first reporter responsible for diagnosing the incident.

Offboarding is part of rollout design, not an end-of-contract surprise. Maintain a register of approved services, account owners, data classifications, integrations, access groups, records or retention rules, and exit steps. When someone changes role or leaves, revoke accounts, tokens, connector access, and saved automations according to the same identity process used for other business systems. When a pilot or vendor ends, remove groups and integrations, preserve or delete data according to the contract and records policy, export required business material, and tell users which workflow replaces it.

Common rollout failures and better responses

Legal, privacy, and workforce boundaries

This plan is not legal advice. The company must check applicable privacy, employment, records, accessibility, consumer-protection, procurement, intellectual-property, sector, and cross-border data rules before enabling a tool or connecting business data. High-impact uses may require specific assessment, notices, consultation, human oversight, or prohibitions depending on jurisdiction.

Do not use the rollout to make automated employment decisions or covertly assess employee performance. Workplace monitoring rules vary, but the risk is broader than compliance. The ILO reports that AI-driven surveillance can affect privacy, autonomy, and well-being, while its global case studies describe social dialogue as a way to encourage AI that complements rather than controls workers. ILO surveillance analysis ILO social-dialogue case studies

For a 100-person company, the proportional approach is simple: use a short policy, narrow pilots, company-managed access, actual employee consultation, human review, aggregate outcome measures, documented stop rules, and a clear way to raise concerns. Build sophistication only where the use case and risk justify it.