AI at Work: How to Capture Value Without Giving Up Control

AI can save time, but unchecked outputs can create costly risks. Learn how to define measurable business pilots, set clear boundaries, and keep leaders accountable.

Consider a hypothetical operations team using AI to summarize customer contracts. The summaries arrive quickly, read well, and appear ready for management review. But one omits a termination clause. Another describes an obligation that does not exist. If the team treats those summaries as authoritative, a time-saving tool becomes a business risk.

The problem is not simply that AI can make mistakes. People and conventional software make mistakes, too. The problem is introducing a new capability without deciding what it may access, how its work will be checked, and who remains accountable.

For business owners, executives, and boards, successful AI adoption starts with those decisions—not with choosing a chatbot. The goal is to capture measurable value while keeping authority, information, and accountability under control.

Approve a defined AI use case—not unrestricted access to a tool.

Understand the Capability Before Buying the Promise

Artificial intelligence is a broad category. Some systems classify transactions, identify patterns, or generate forecasts. Generative AI produces content, including text, images, audio, video, and code. These capabilities can support useful business tasks, but they require different evaluation methods and controls.

As the National Institute of Standards and Technology’s Generative AI Profile explains, generative AI can produce confidently presented errors, including fabricated reasoning and citations. A polished answer is therefore not proof of accuracy.

For leaders, this distinction matters: generating a plausible response and establishing a reliable fact are different functions. Connecting an AI system to company documents may improve its usefulness, but it does not eliminate the need to test whether it interprets those documents correctly.

Evaluate the capability against the work. An internal brainstorming assistant and a system making customer eligibility decisions should not face the same approval process.

Start With a Business Problem You Can Measure

“We need an AI strategy” is not a sufficiently defined business problem. “Our managers spend too much time assembling weekly project updates” is a better starting point because it identifies a workflow that can be examined and tested.

Choose a bounded pilot with accessible source material, clear review standards, and consequences the organization can manage. Before selecting a tool, document:

  • The task: What should the system produce, and for whom?
  • The baseline: How does the current process perform in time, cost, and quality?
  • The boundaries: What is explicitly outside the system’s role?
  • The acceptance criteria: Which errors are tolerable, and which require rejection?
  • The accountable owner: Who approves results and decides whether the pilot continues?

For example, a hypothetical project-summary pilot might use only approved status reports, require links to supporting passages, and route every draft to a project manager. It would not update budgets, change deadlines, or send commitments to customers.

This is not a guarantee of productivity. It is a controlled way to discover whether the proposed capability improves the actual process.

Set the Information Boundary Before Connecting Data

AI becomes more useful when it can access relevant information. It also becomes more consequential. Connecting email, customer records, financial files, or internal knowledge repositories expands what the system—and potentially an attacker exploiting it—can reach.

NIST identifies leakage and unauthorized disclosure of sensitive information among generative AI risks. However, services do not all handle information identically. Review the specific product, configuration, contract, and deployment rather than assuming that every offering is either safe or unsafe.

Ask Procurement Questions That Change the Decision

  • What prompts, uploaded files, outputs, and usage records are retained?
  • Is submitted information used for model training, and under what terms?
  • Who can access the information, including vendor personnel and subprocessors?
  • What deletion, logging, security, and contractual controls apply?
  • Can access follow existing employee permissions rather than exposing an entire repository?

Apply data minimization: provide what the task needs, not everything available. An assistant summarizing approved product documentation does not automatically need access to personnel records or executive correspondence.

Also examine the underlying permissions. Connecting AI to a poorly governed document repository can make existing oversharing easier to exploit. AI deployment is not a substitute for fixing access management.

Separate Producing an Answer From Taking Action

An assistant that drafts text is different from an agent that sends messages, changes records, or initiates transactions. As autonomy increases, mistakes can move from an inaccurate screen response into operational consequences.

In a hypothetical sales workflow, an assistant might draft a customer follow-up using approved notes. That does not mean it should receive permission to send the email, modify contract terms, or export the customer database.

The Cybersecurity and Infrastructure Security Agency’s announcement on agentic AI security recommends limiting autonomy and access, strengthening identity management, monitoring activity, and conducting security assessments. Translate those principles into explicit operating rules:

  • Give each system only the credentials and permissions its task requires.
  • Require separate authorization for consequential actions.
  • Record tool use, approvals, and changes so activity can be investigated.
  • Test how to revoke access and stop execution before deployment.

Account for prompt injection, too: instructions embedded in documents, messages, or websites can attempt to redirect an AI system. Treat retrieved content as untrusted input, not as permission to override business rules. Approval gates and restricted permissions should remain effective even when the model encounters malicious instructions.

Make Verification Part of the Workflow

“A person will review it” is not a complete control. That person needs relevant expertise, access to original evidence, enough time, and clear authority to reject the result.

NIST’s warning about fabricated citations is particularly important. A reference can look legitimate without supporting the claim—or without existing at all. For important decisions, open the original source and confirm what it actually says.

Review More Than Writing Quality

  • Facts: Are names, dates, obligations, and claims supported?
  • Sources: Do citations exist, and do they substantiate the conclusion?
  • Calculations: Can figures be reproduced using a reliable calculation method?
  • Context: Did the output omit exceptions, uncertainty, or conflicting evidence?
  • Consequences: Could an error affect someone’s rights, finances, safety, or opportunities?

Test representative work and difficult cases before rollout. Include incomplete records, contradictory documents, and requests the system should decline or escalate. Define what happens when evidence is insufficient. A useful system must sometimes say it cannot provide a reliable answer.

Measure the Complete Workflow, Not the Impressive Demo

A fast draft is not necessarily a faster business process. If employees spend substantial time checking, correcting, and reformatting the result, the apparent benefit may disappear.

Compare the pilot with the existing workflow using consistent measures:

  • Time saved after review and correction.
  • Error, omission, and rework rates.
  • Total operating cost, including integration, oversight, and support.
  • Security incidents, policy violations, and unauthorized actions.
  • Whether the original business objective was achieved.

Look beyond averages. A system may handle routine documents well while failing on the exceptions that matter most. Evaluate quality by task type and business consequence, not just by how often users accept an answer.

Make expansion conditional on evidence. If the pilot does not meet its acceptance criteria, narrow the scope, improve the controls, or stop it.

Keep Accountability With Leadership

Assign a business owner, involve security and privacy teams early, and establish who can approve changes in data access or autonomy. Give employees a clear route to request approved tools and report problems without hiding mistakes.

NIST’s Generative AI Profile supports structured risk management, but it accompanies a voluntary framework. It is not a compliance certification, and following it does not automatically satisfy legal obligations. Evaluate applicable requirements separately with qualified counsel and relevant specialists.

A Checklist Before Expanding

  • Is there a named owner accountable for outcomes?
  • Are permitted data and prohibited uses documented?
  • Are action permissions limited and consequential actions separately authorized?
  • Have quality standards and escalation rules been tested?
  • Are activity monitoring and incident response in place?
  • Can access be revoked and the workflow stopped safely?
  • Does measured performance justify expansion?

Move Forward With Discipline

AI can help organizations create, analyze, and act more effectively. But capability alone does not establish business value. Value emerges when the task is clear, information access is appropriate, outputs are checked, and someone remains responsible.

Choose one workflow and write down its boundaries before approving another tool. Establish the baseline, name the owner, test the controls, and measure the result. That is how leaders move beyond experimentation without giving up control.

Browse all insights · Contact Bart McDonough