AI Working Groups: From Process Problem to Tested Improvement

“We should use AI to speed up our RFQs.” Which part takes too long: finding information, getting technical input, checking prices, writing or approval? Speeding up the wrong step moves the queue elsewhere. This is where an AI working group earns its place. Give a small group one process to understand, one improvement to test and a clear point at which someone decides what happens next. **In short** - A working group investigates and tests a defined use case; accountable leaders approve wider adoption. - Include the process owner and people who do the work, with specialist input relevant to the data and risk. - Use three stages: **process**, **plan**, **action**. - Measure the current process before testing a change, including quality and rework. - Finish with a decision to adopt, revise, pause or stop, and name the person responsible. ## What is an AI working group? An AI working group is a temporary, practical team formed around one business problem. Its job is to learn how the work happens, design a bounded test and report what the evidence shows. It may include an AI Champion, but it needs a process owner with the authority to change how that work is done. The UK government's AI Risk Management Toolkit describes multidisciplinary involvement, including business experts, end users and specialists, to identify and manage risks across an AI solution's life. It is a toolkit for teams designing, procuring or operating AI products, so an SME should scale the participation to the proposed use. [Source: UK Government AI Risk Management Toolkit](https://www.gov.uk/government/publications/ai-risk-management-toolkit/ai-risk-management-toolkit-guidance). For a straightforward internal task, the group might be the process owner, two people doing the work and someone who understands the tool and information rules. A use affecting customers or employees may need security, data protection, HR or other specialist involvement before a test begins. The AI Council or responsible senior leader sets priorities and decides on wider use. The working group supplies the evidence. ## Stage 1: Process — find the real point of friction Watch the work with the people doing it. Map the route from request to outcome: information, decisions, waiting, corrections and exceptions. With an RFQ, the group might discover that writing takes two hours but waiting for current rates and technical sign-off takes four days. An AI drafting assistant may help with the two hours; it cannot approve a price nobody has confirmed. A clearer handoff or shared source of current information may create more value. This expands on Smart AI Studio's [Problem First. Tools Second.](https://smartaistudio.co.uk/insights/problem-first-tools-second/) approach. The working group's output is a process map, a baseline and a short problem statement: “Responses wait for confirmed technical input; our goal is to reduce that wait without increasing errors.” If historic data is weak, sample recent cases and state what you observed. Record elapsed time, hands-on time, rework and quality issues. ## Stage 2: Plan — design a test that can answer a question Choose one change. It might be a better intake form, a standard source library, an AI-assisted first draft or a combination. Say which part of the process changes and what stays under human control. A one-page test plan should answer: 1. **Purpose:** What problem are we trying to improve, and by how much? 2. **Scope:** Which requests, team and period are included? What is excluded? 3. **Inputs:** What information is needed, who owns it and what may the tool access? 4. **Checks:** Who reviews factual, commercial and technical accuracy? What triggers escalation? 5. **Evidence:** Which measures will be compared with the baseline, including correction time? 6. **Decision:** Who can approve the trial, pause it and decide on wider use? For RFQs, test approved tools on suitable enquiries. Technical and commercial reviewers check responses before sending. Compare time to a review-ready draft, accuracy, review effort and final approval. A faster draft may add no value if review effort rises. Get the appropriate information and risk checks before processing real material. A test labelled “pilot” does not set aside data protection, security or contractual obligations. Government guidance on scaling AI tools recommends identifying the need, involving different perspectives, monitoring risks and keeping senior stakeholders informed. [Source: UK Government Hidden AI Risks Toolkit](https://www.gov.uk/government/publications/a-human-centred-approach-to-scaling-and-de-risking-ai-tools/the-mitigating-hidden-ai-risks-toolkit-html). ## Stage 3: Action — test, learn and make a decision Run the test within its agreed limits. Keep a simple log: what was tried, which cases were excluded, what went wrong, what staff changed and what the reviewers found. Speak to users during the trial, not only at its end. If results disappoint, ask whether source information, exceptions or added review work explain it. These findings are useful even if the test stops. At the end, the group should recommend one of four outcomes: - **Adopt** the approach for the agreed scope, with an owner and continuing checks. - **Revise** the process or test and run another limited trial. - **Pause** until a dependency, such as reliable information or a supplier assessment, is resolved. - **Stop** because the results or risks do not justify further work. The senior owner or council records the decision, conditions and review date. The group should also document the new process if the change is adopted. A pilot is complete when the business has learned enough to make a decision, not when a demo looks impressive. ## Give the group a brief and an end date Give the group a problem, sponsor, process owner, time allocation and reporting date. Ask participants what support they need. A useful brief is just a paragraph: **“Map how we respond to RFQs, identify the main source of delay, test one approved improvement on a limited set, and report quality, elapsed time and review effort to the leadership team.”** That makes the work visible and the handoff clear. It also leaves room for a valuable result that does not involve AI. **This week's action:** Choose one process and gather its owner and two people who handle it. Map the last real example together before proposing a tool. ## Explore the governance series - [AI governance for SMEs](/insights/ai-governance-for-smes-practical-starting-point/) - [AI Council](/insights/does-your-business-need-an-ai-council/) - [AI policy](/insights/writing-an-ai-policy-your-team-will-actually-follow/) - [AI Champions](/insights/ai-champions-business-role/) - [90-day governance review](/insights/ai-governance-90-day-review/) ## FAQs ### Who should be in an AI working group? Include a process owner, people who do the work and someone who can support the proposed technical approach. Bring in data protection, security, HR or other expertise when the use requires it. The group should be small enough to do the work. ### Who approves a working group’s recommendation? The named senior owner or AI Council decides whether to adopt, revise, pause or stop a proposed change. The working group provides the process map, test results, limitations and a recommendation; it does not approve its own wider rollout. ### How long should an AI working group run? Set a date tied to the question it must answer, rather than making it permanent by default. A narrow process may be mapped and tested in weeks; a complex use may need longer assessment. Review the scope if the group cannot state when it will report. ### How do you measure an AI pilot's success? Compare the trial with a baseline for the same process. Include quality, elapsed time, human review, rework and effects on users or customers where relevant. Decide the measures before the trial so a compelling demo does not replace evidence. ### What if the working group finds AI is not the answer? Record the finding and fix the actual constraint if you can. A clearer handoff, current source information or a simpler approval may be a stronger result than a new tool. The aim is improvement, not an AI deployment.

This article was written by Peter Lowe. The ideas and opinions are his own; AI was used to assist with drafting and editing.