The smartest way to introduce artificial intelligence into a business is to approve a specific use case—not unrestricted use of a tool. Start with a defined task, a clear data boundary, and a person who remains accountable for the result.
Imagine a manager asking an AI assistant to draft an employee FAQ. Using approved, non-sensitive material, that could be a useful experiment. Connect the same assistant to personnel files, let it interpret employment policies, and allow it to publish answers automatically, and the risk changes substantially. The technology may be similar. The authority and exposure are not.
That distinction should drive business adoption. The question is not simply whether AI can perform a task. It is whether the organization can use it reliably, securely, and with appropriate oversight.
Approve the work AI is allowed to do, the information it may use, and the decisions it cannot make.
Five questions provide a practical framework: What task will AI perform? What data can it access? Who checks its work? What actions can it take? Who can stop it?
1. What Task Will AI Perform?
“Use AI to improve productivity” is an ambition, not an operating plan. A useful starting point is a bounded task with a recognizable output and a manageable consequence if something goes wrong.
For an initial pilot, consider drafting an internal FAQ from approved onboarding materials. Keep the scope narrow: the assistant produces a draft, a designated employee reviews it, and nothing is published automatically. Exclude confidential personnel matters and policy interpretation.
Other potential starting points include:
- Summarizing public industry reports, with links back to the originals.
- Creating a first draft of an internal announcement from approved talking points.
- Suggesting categories for non-sensitive support requests, subject to employee review.
- Reformatting approved documentation into a checklist.
These are candidates for evaluation, not automatically safe applications. The suitability of each depends on the information involved, the consequences of error, and the controls available.
Define Success Before Testing
Write down what a successful output must contain and what would make it unacceptable. For the FAQ pilot, success might mean accurate answers supported by approved source material, no invented policies, and less total preparation time after review and corrections.
The NIST Generative AI Profile recommends documenting the intended context of use and evaluating potential benefits and harms. That discipline prevents an experiment from expanding into an undefined business process.
2. What Data Can It Access?
An AI workflow’s risk depends heavily on its inputs. A request to summarize a public brochure is different from a request containing customer records, contract terms, passwords, or sensitive financial information.
Document what employees may submit, what requires additional approval, and what is prohibited. Make the rules concrete enough to use during a busy workday. “Be careful with confidential information” is not sufficient guidance.
For the FAQ pilot, permitted inputs could be approved, non-sensitive onboarding documents. Employee records, credentials, and unpublished business plans would remain outside the boundary.
Examine the Service, Not Just the Brand
Before approving a product, review the terms and controls for the actual service and subscription plan being purchased. Do not assume that consumer, business, and enterprise offerings handle information identically.
- Retention: What inputs, outputs, and logs are stored, and for how long?
- Training use: Can submitted information be used to improve models, and what contractual commitments or controls apply?
- Deletion: What can be deleted, through what process, and with what limitations?
- Access: Who can access stored information, including administrators and service providers?
- Connections: Which files, mailboxes, applications, or databases can the system reach?
Connected-system access deserves particular attention. An assistant linked to a shared drive may encounter information far beyond the original task. Apply least privilege: provide only the access required, and verify the boundary through testing rather than relying solely on a policy statement.
3. Who Checks Its Work?
Generative AI can produce polished language that is factually wrong. A confident explanation is not evidence, and a citation is not proof that the cited source exists or supports the claim.
NIST identifies confidently incorrect outputs, privacy and information-security risks, and problematic human reliance among the concerns associated with generative AI. The practical response is verification matched to the consequences of error.
Assign a reviewer who understands the subject and has enough time to inspect the output. “A human is involved” means little if that person cannot recognize an error or is expected to approve drafts without checking them.
For the FAQ example, the reviewer should compare answers against the approved documents, confirm that no new commitments have appeared, and remove unsupported interpretations. For other workflows, review may require recalculating figures, checking source documents, or involving legal, compliance, or technical specialists.
Make Uncertainty an Acceptable Outcome
Design the workflow so the assistant can flag missing information rather than fill gaps with plausible language. Then test whether it actually does so. An instruction to “be accurate” is not a substitute for evaluation.
Include incomplete, ambiguous, and conflicting source material in testing. Check whether the system distinguishes between what the documents establish and what remains unknown. Reviewers should work from independent sources—not ask the same assistant to certify its own answer.
Human accountability must be operational: a named reviewer, a defined standard, and a clear escalation route.
4. What Actions Can It Take?
A drafting assistant produces material for someone to consider. An AI agent may also call tools, update systems, or execute steps in a workflow. That shift from assistance to action changes the security requirements.
A suggested customer response can be reviewed before use. An agent that sends the response, changes the account record, and initiates a refund has crossed several authority boundaries.
CISA and international partners’ guidance on AI agents recommends limiting autonomy and avoiding broad access to sensitive data or critical systems. For business leaders, the implication is straightforward: begin with narrow permissions and add authority only when the need and safeguards are clear.
- Start read-only where feasible. Let the system retrieve approved information before allowing it to modify records.
- Separate drafting from execution. Require explicit approval before consequential external communications or transactions.
- Constrain actions technically. Use application permissions and approval controls, not just instructions in a prompt.
- Limit scope. Restrict accessible accounts, records, destinations, and transaction types to the approved task.
- Record activity. Maintain appropriate logs of actions and approvals while protecting sensitive log contents.
Also consider prompt injection: malicious instructions embedded in material an AI system reads, such as a document or web page. Such content may try to redirect the system away from its authorized task. Treat retrieved material as untrusted, and do not let it independently authorize access or actions.
5. Who Can Stop It?
Every AI workflow needs an accountable owner with the authority and practical ability to suspend it. That means knowing how to disable connections, revoke permissions, halt pending actions, and involve security or other response teams.
Define stop conditions before launch. Examples include unauthorized data access, an unapproved external action, repeated material inaccuracies, or uncertainty about where sensitive information has gone.
Vendor selection is only the beginning. CISA and the UK NCSC’s secure AI development guidance addresses security across design, development, deployment, and operation. Business oversight should likewise continue after procurement.
Measure the Whole Workflow
Track reviewer time, correction rates, cost per completed task, and security incidents. Compare results with the existing process. A fast draft is not a productivity gain if checking and repairing it consumes more effort than the original task.
Reassess when the model, data sources, permissions, or business purpose changes. Approval for drafting an FAQ should not silently become approval to answer employee questions autonomously.
An AI Approval Checklist for Business Leaders
Before expanding a pilot, document:
- Purpose: The approved task and explicit exclusions.
- Data: Permitted inputs, prohibited information, and approved connections.
- Accountability: The business owner, qualified reviewer, and escalation contact.
- Authority: What the system can read, change, send, or execute.
- Validation: Tests, review requirements, and evidence of acceptable performance.
- Value: Success measures that include review, correction, and operating costs.
- Shutdown: Stop conditions, suspension procedures, and incident-reporting responsibilities.
The voluntary NIST AI Risk Management Framework can help structure this work. It is a risk-management resource—not a certification or guarantee of regulatory compliance.
Build Confidence Before Expanding Authority
Responsible AI adoption does not require waiting for perfect technology. It requires matching the task to the organization’s ability to control data, verify results, constrain actions, and respond when something fails.
Choose one bounded use case and complete the checklist before granting access. Run a measured pilot, inspect the failures as carefully as the successes, and expand only when the evidence supports it. The objective is not to use AI everywhere. It is to use it where the business can demonstrate value without surrendering accountability.