Responsible AI: a reading guide for business teams

Before choosing an AI tool, agree on the task it should help with, the information it can access and the person accountable for the outcome. A system that drafts a reply needs different controls from one that changes a customer record or sends a payment instruction.

The reading below covers four different questions. The suggested project questions are TrilloBytes’ practical interpretation of the material, intended to help a team prepare its own brief.

1. What needs to change in the workflow?

McKinsey’s State of AI research discusses adoption, organisational impact and how higher-performing organisations redesign workflows. Use that wider business context to examine where work actually gets stuck before choosing an AI feature.

Bring to the project: Which handoff would improve, who owns it, and what evidence would show that the change helped? Include running costs and manual review in the comparison.

McKinsey: workflow redesign and scale

2. What should the agent be allowed to do?

IBM’s explanation of AI agents introduces systems that pursue goals and use tools to carry out tasks. It is useful background for distinguishing a conversational answer from a workflow that can take actions.

Bring to the project: List the tools the agent can access, the data each tool exposes and the actions that require approval. Start with the minimum access needed for the task, and define a clear stopping point.

IBM: agents use goals, tools, and rules

For a more specific tool-access discussion, OWASP’s Excessive Agency guidance connects unnecessary functions, broad permissions and excessive autonomy with damaging actions. It recommends limiting tool access, requiring human approval for high-impact actions and enforcing authorization in the connected systems, rather than letting the model decide what it may do.

3. Who manages the risks over time?

NIST’s AI Risk Management Framework offers a voluntary approach to considering trustworthiness and managing AI risks. It provides a broader lens than checking whether a model answered one test question correctly.

Bring to the project: Name an owner for the system, the people affected by its output and the situations that need escalation. Decide what to measure during the pilot and when a human should review or pause the workflow.

NIST: risk management for trustworthy AI

4. What could go wrong in the application?

The OWASP Top 10 for LLM Applications highlights security risks in applications that use language models. Use it as a starting point for a discussion with the people building and maintaining the system.

Bring to the project: Test how the application handles untrusted input, sensitive information and requests to use tools outside the intended task. Record failures and recovery steps, and verify that approvals are enforced by the application.

OWASP: LLM application security risks

Turn the reading into a small pilot

Choose one workflow, write down the expected outcome and agree on the approval and recovery rules. Test ordinary work alongside errors and exceptions. Review the results with the team before expanding access or adding more actions.

As an illustrative first pilot, consider an assistant that drafts replies to service enquiries. Let it read an approved enquiry queue and prepare a draft; treat sending and CRM updates as separate operations. The brief below records the decisions for a business owner and implementer.

• Allowed work: list the records it can read and the exact draft or update it may prepare. Give each connected tool only the access needed for that work.
• Approval: name the reviewer and show the final recipient, message and proposed record changes. Agree what happens if the proposed action changes after review.
• Enforcement: ask the implementer to demonstrate that the sending or update operation rejects a missing or invalid approval. Require the operation itself to validate approval before it runs.
• Recovery: define who can pause the workflow, where unfinished work is visible and how staff find which actions actually completed.
• Pilot checks: rehearse an out-of-scope record, an unexpected recipient, a changed draft and a repeated action. Write the expected stop, review or recovery outcome for each.

Use the TrilloBytes automation planning guide to capture the scope and estimate the time involved. For a concrete example, read how to brief a website-to-CRM automation.