AI at Work: A Practical Guide to Safer Adoption

Adopt workplace AI with confidence: start with a focused business problem, protect sensitive data, and set clear review responsibilities before expanding beyond a pilot.

A manager uses artificial intelligence to draft an internal briefing. The draft arrives quickly, reads well, and appears ready to share. But it includes an unsupported claim, draws on information the manager should not have uploaded, and leaves nobody clearly responsible for checking the result.

This hypothetical scenario captures the challenge of business AI adoption: getting an output is easy. Making that output trustworthy, secure, and useful requires deliberate work.

AI covers many technologies, from predictive analytics to systems that generate text, images, and code. This guide focuses primarily on generative AI and the workplace tools built around it. These systems can help people organize information, explore ideas, and prepare drafts. They can also introduce errors, expose sensitive data, and execute actions beyond their intended scope.

The goal is not to eliminate every risk before using AI. It is to define acceptable uses, establish controls, and expand based on evidence—not enthusiasm alone.

Start With a Business Problem, Not an AI Mandate

“We need an AI strategy” is not a sufficiently specific starting point. “We need to reduce the effort required to prepare an internal briefing from approved public materials” is a problem you can test.

A useful first pilot has a narrow purpose, clear inputs, and a result that someone can evaluate. Avoid beginning with workflows where an error could directly affect a person’s employment, access to credit, medical care, or other consequential outcomes.

Consider a pilot that drafts an internal FAQ using an approved, non-sensitive policy document. Employees remain responsible for confirming that each answer matches the source. The tool does not publish the FAQ or respond directly to customers.

Before testing, document:

  • The intended benefit: What should improve—drafting effort, consistency, or access to information?
  • The permitted inputs: Which documents and data categories may the tool receive?
  • The reviewer: Who has the expertise and authority to approve the output?
  • The unacceptable outcomes: What would trigger a pause, such as disclosure of restricted information or repeated factual errors?

This turns a broad technology experiment into a manageable business decision.

Decide What Information AI May Receive

Data protection begins before an employee enters a prompt. It includes uploaded files, connected repositories, conversation histories, generated outputs, and records retained by vendors or internal systems.

The joint AI data-security guidance from NSA, CISA, FBI, and international partners emphasizes reliable data sources, provenance tracking, integrity checks, access controls, secure storage, and ongoing monitoring. It also addresses risks involving data supply chains, maliciously modified data, and data drift.

For business leaders, the practical implication is straightforward: assess the entire information flow, not just the chat interface.

An Approved-Data Checklist

Before permitting a workflow, confirm that:

  • Data classification is clear. Employees know whether the material is public, internal, confidential, or restricted.
  • The specific service is approved. Review the product, subscription plan, contractual terms, and relevant settings.
  • Training and retention practices are understood. Determine whether submissions may be used for model improvement, how long records persist, and what deletion options exist.
  • Access is appropriately limited. Check employee permissions, administrative access, shared conversations, and connected data sources.
  • Legal and contractual obligations are satisfied. Consider privacy requirements, confidentiality commitments, intellectual property, and restrictions on data transfer.
  • Sources remain trustworthy. Identify who owns the source material and how changes or suspicious modifications will be detected.

Do not assume every AI service trains on every submission. Equally, do not assume an enterprise label resolves every concern. Verify the actual arrangement.

If a workflow can succeed using public, synthetic, or appropriately de-identified information, start there. Removing names alone may not sufficiently protect sensitive data; context can still reveal identities or confidential details.

Treat Generated Answers as Drafts, Not Evidence

Generative AI can produce confident, polished statements that are incorrect. NIST calls this risk confabulation in its Generative AI Profile, which also addresses privacy, information integrity, and information security. The profile accompanies NIST’s voluntary AI Risk Management Framework.

The operational lesson is simple: fluency is not verification.

Suppose an AI tool summarizes a supplier agreement. It may accurately describe most provisions while misstating a termination requirement. A summary that is mostly correct can still be unsuitable for a consequential decision.

Build Verification Into the Workflow

  • Factual claims: Compare material assertions with authoritative sources.
  • Citations: Open the source and confirm that it exists and supports the claim.
  • Calculations: Recompute important figures using a reliable method.
  • Recommendations: Review assumptions, missing context, and potential consequences.
  • Code: Use established review, testing, and security processes before deployment.

Match review depth to potential harm. An internal brainstorming list needs a different review process from customer advice or production code. In every case, the reviewer needs adequate context, competence, and time—not merely an approval button.

AI can help produce an answer. Your organization remains responsible for deciding whether that answer is fit for use.

Give Automation Limited Authority

An assistant that drafts text presents a different risk from one that can send messages, modify records, or execute transactions. As capabilities expand, so should the controls surrounding them.

For an initial pilot, consider read-only access to a narrowly defined information set. Require human approval before external communications, changes to business systems, or other consequential actions. These are risk-reduction measures, not guarantees of safety: read-only access can still expose information if permissions are too broad.

Connected tools also create opportunities for prompt injection, where instructions embedded in retrieved documents, messages, or other content attempt to redirect an AI system. Treat that external content as untrusted input, not as authority to change the tool’s behavior.

For example, an assistant summarizing customer emails should not follow an instruction inside an email to retrieve unrelated confidential documents.

Limit available actions, enforce permissions outside the model, and record significant activity. Avoid relying on a prompt such as “never disclose sensitive information” as the primary security control. The system’s actual access and capabilities should reflect its authorized purpose.

Make Accountability Explicit—and Train People to Question Outputs

“A human is in the loop” is not an accountability model. Name the business owner, technical administrator, reviewer, and escalation contact. In a smaller organization, one person may hold several roles, but the responsibilities still need to be clear.

Employees should know which tools are approved, what information is prohibited, when review is required, and how to report a questionable result or accidental disclosure. Make the approved path practical; a policy that employees cannot realistically follow will not provide dependable protection.

Training should preserve professional judgment rather than teach prompt-writing alone. CISA’s guidance on using AI advises users to avoid sharing sensitive information and maintain their own expertise instead of relying exclusively on generated content.

CISA also warns about synthetic voices and images used for impersonation. Reinforce independent verification for unusual payment requests, credential requests, or instructions to bypass normal procedures. A familiar voice is not sufficient authorization; confirm through an established, trusted channel.

Measure the Whole Workflow and Keep an Exit Plan

A fast first draft does not necessarily mean a better process. If employees spend additional time checking, correcting, and reformatting it, the apparent gain may disappear.

Evaluate the complete workflow against the existing process. Useful measures include:

  • Completed, usable work: How often does the output meet the agreed standard?
  • Review and correction effort: What work remains before the result can be used?
  • Error patterns: Which mistakes recur, and how consequential are they?
  • Security and privacy events: Have inappropriate disclosures, access problems, or unauthorized actions occurred?
  • Operational dependence: Can the team continue working if the tool becomes unavailable?

Establish pause criteria before the pilot begins. Assign an owner who can restrict access or stop the workflow when those criteria are met. Preserve a fallback process and understand how to disconnect integrations, revoke credentials, and handle retained information.

Reassess after meaningful changes to the model, vendor terms, integrations, source data, or business purpose. A previously approved workflow can develop new risks as its environment changes.

Expand Only When the Evidence Supports It

Responsible AI adoption does not require choosing between innovation and security. It requires treating security, accuracy, and accountability as part of the innovation process.

Start with one useful workflow. Establish its data boundaries, limit its authority, appoint a capable reviewer, and measure the full cost of producing a usable result. Keep the ability to pause.

Your next step: bring the business owner, security lead, and intended users together to define that pilot. Decide what success looks like—and what would make you stop—before connecting more data or granting more authority. Then expand only when the evidence supports it.

Browse all insights · Contact Bart McDonough