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

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.

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.