AI at Work: A Practical Guide to Protecting Your Data and Keeping Humans in Control

Use generative AI at work without surrendering control. Learn how to set clear task boundaries, protect confidential data, and keep people accountable for AI-assisted decisions.

A polished answer can create a dangerous impression: that the work is finished. An AI assistant produces a confident summary, a professional email, or a plausible recommendation, and the temptation is to move straight to action. But speed and fluency are not the same as accuracy, authorization, or sound judgment.

For businesses, the opportunity is real. Generative AI can help employees organize information, develop ideas, and produce useful first drafts. The challenge is capturing that value without exposing confidential information, trusting unsupported claims, or giving software more authority than the task requires.

The right starting point is not “Where can we add AI?” It is “Which task can we improve, with what information, under whose supervision?” That question turns a technology experiment into a manageable business decision.

1. Start With a Bounded Task, Not a Broad Mandate

Artificial intelligence covers many technologies. This article focuses on generative AI: systems that produce content such as text, images, and code, including assistants connected to workplace applications. Those connections matter because a tool that drafts text presents a different risk from one that can access customer records or execute changes.

Choose an initial task with a clear purpose, limited inputs, and an output someone can evaluate. Drafting an outline from public material is a more manageable starting point than allowing an assistant to answer customer questions autonomously.

Hypothetical example: A marketing team uses an approved AI tool to turn a published product description into a draft webinar outline. The inputs are public, the output stays internal, and a designated employee checks every product claim before publication.

Before a pilot begins, document:

  • The objective: What specific work should become easier or better?
  • The boundary: What information and actions are off-limits?
  • The owner: Who reviews the output and remains accountable?
  • The failure condition: What result would require stopping or redesigning the pilot?

A narrow pilot is not a lack of ambition. It creates evidence for deciding where broader adoption makes sense.

2. Decide What Information the Tool May Receive

An AI prompt is a data-sharing decision. So is uploading a document, enabling a connector, or allowing an assistant to search an internal repository. Employees need rules for all of these activities—not just a warning to “be careful.”

Establish an approved-tool policy that identifies which services, accounts, and configurations may handle each category of information. A personal account and an organization-managed offering should not be treated as interchangeable.

Review the Actual Service and Its Settings

Before permitting sensitive information, examine contractual protections, retention and deletion terms, whether submitted data may be used for model training, access controls, and connected applications. These details vary by product, plan, and configuration. Do not assume that every AI service trains on every submission—or that a business subscription automatically resolves every privacy concern.

Provide a clear prohibited-input list. Depending on the organization, that may include passwords, authentication codes, private keys, regulated personal information, confidential client records, and proprietary material outside an approved workflow. Tell employees where to go when classification is unclear.

Protect Data Beyond the Prompt

The joint government guidance on securing data used to train and operate AI systems recommends lifecycle protections, including encryption, access controls, provenance tracking, and secure storage.

Apply that principle to source documents, retrieved content, outputs, and logs. Track where important information originated and who may access it. Prompts and monitoring records can themselves contain sensitive data, so oversight should not create an uncontrolled archive.

Use the minimum information necessary. Replacing a real customer record with a carefully constructed fictional example may achieve the same drafting objective without exposing the customer.

3. Verify the Answer, Not Just the Writing

Generative AI can produce confident statements that are false or unsupported. The NIST Generative Artificial Intelligence Profile addresses risks including confidently false outputs, privacy, information security, and human–AI interaction. It is voluntary risk-management guidance, not a certification or blanket legal requirement.

The practical lesson is straightforward: an answer does not become reliable because it sounds professional or includes citations.

Build review around the substance:

  • Names and dates: Confirm people, organizations, events, and timelines against reliable records.
  • Calculations: Recompute important figures using an appropriate independent method.
  • Citations: Open the original source and check whether it supports the claim.
  • Recommendations: Examine assumptions, missing context, and potential consequences.
  • Code and instructions: Test in an appropriate environment before production use.

Match review to the stakes. Brainstorming a meeting title needs less scrutiny than preparing a financial disclosure, interpreting a contract, or changing a security configuration.

Asking the same assistant whether its answer is correct is not independent verification. Reviewers need relevant expertise, access to original evidence, and enough time to challenge the result.

Use AI to accelerate the work—not to bypass the judgment the work requires.

4. Limit Permissions Before Adding Automation

The risk changes when an assistant can act. Drafting an email is different from sending it. Suggesting an account change is different from applying it. Summarizing an invoice is different from authorizing payment.

Apply least privilege: give the system only the access and capabilities required for its approved task. For connected tools, check both the assistant’s permissions and the underlying repositories. Existing access problems can become easier to exploit when information is easier to retrieve.

Joint guidance on securely deploying AI systems recommends least-privilege access, secure APIs, and controls for malicious inputs such as prompt injection. Its primary scope is organizations deploying AI systems themselves, but the permission-setting principle is also useful when evaluating connected workplace assistants.

Treat Retrieved Material as Untrusted Input

Prompt injection occurs when malicious content attempts to steer an AI system away from its authorized task. That content may appear in a document, webpage, or other material the assistant retrieves.

Hypothetical example: An assistant summarizing an external document encounters text instructing it to disclose internal files. Those words are part of the document—not legitimate authorization to access or transmit information.

A warning in a prompt is not a complete defense. Limit accessible data, restrict available actions, enforce authorization outside the model, and require explicit approval for consequential changes. An approval step should show the reviewer exactly what will happen, not merely ask for a vague confirmation.

5. Measure Useful Work and Keep Testing

A successful demonstration is not proof of a successful deployment. Evaluate the full workflow, including the time spent checking and correcting outputs.

Useful pilot measures include:

  • Time saved after review: Include verification, corrections, and rework.
  • Correction rate: Track outputs requiring substantive changes.
  • Unacceptable outputs: Record failures that cross defined business or safety boundaries.
  • Security incidents and near misses: Capture inappropriate disclosures, access attempts, and blocked actions.

These are practical evaluation measures, not universal industry benchmarks. Define success and stopping conditions around your own workflow.

Continue oversight after launch. The deployment guidance recommends monitoring, rollback preparations, and renewed accuracy, performance, and security evaluations when model versions change. Changes to connectors, permissions, or source material also warrant review because they can alter what the system sees and does.

Assign an owner who can investigate problems and suspend access. Maintain a fallback process. Where actions cannot reliably be reversed, use stronger preventive controls rather than relying on rollback alone.

A Checklist Before Using AI at Work

Before submitting information, connecting a system, or acting on an output, ask:

  • Is this tool, account, and configuration approved for this information?
  • Can the task be completed with less sensitive data?
  • Who will verify the result against original evidence?
  • What can the system read, share, or change?
  • Which actions require explicit human approval?
  • How will we detect, stop, and, where possible, reverse a mistake?
  • Who owns the outcome if something goes wrong?

If those answers are unclear, narrow the task before proceeding.

Make Accountability Part of Adoption

Responsible AI adoption is not a choice between innovation and security. It is the discipline of connecting a useful capability to appropriate information, limited permissions, meaningful verification, and clear ownership.

Start with one bounded workflow. Name its owner, approve its inputs, define its review process, and measure whether it genuinely improves the work. Expand only when the evidence supports it.

The goal is not to put AI everywhere. It is to put AI where it helps—and keep people accountable for what happens next.

Browse all insights · Contact Bart McDonough