Where it fits and where it does not

The problem it solves

The artificial intelligence conversation in a small company usually runs backwards. It starts with a tool someone saw, continues with a trial that went well in a demonstration, and ends in a license that two months later one person uses.

The trouble is that the opening question was about the technology rather than the work. Nobody looked first at where the organization's time actually goes, which tasks repeat under stable rules, and which require judgement the company is not willing to hand over. The symptoms are easy to recognize: each area proposes its own use with no shared criteria, the trial that shone on prepared examples stumbles on real cases, and when someone asks whose time, exactly, the tool was meant to give back, nobody can answer.

What remains is an expensive, muddled feeling: the sense of being behind, with no clear idea of behind what. That feeling carries its own cost. It eats up leadership meetings that end without a position, it rushes the next purchase, and it teaches the team that every new initiative will fade like the last one. Left unaddressed, the company swings between enthusiasm and rejection without ever having decided, with reasons in writing, where it makes sense and where it does not.

What it covers

The workshop works on the participant's real operation, not on case studies from other industries, and it starts from a less common question: not what artificial intelligence can do, but which specific part of the work is worth pointing it at, and which is not. It is a judgement workshop rather than a tools workshop, because a decision tied to a product expires with the product, while the criteria for deciding where to apply the technology stay with the company. The first part inventories tasks: what gets done, how often, by whom, and how much independent judgement each one demands.

A three-cut filter is then applied to that inventory. Volume and repetition, because something that happens twice a year justifies nothing. Stability of the rules, because a task whose criteria change monthly is not a candidate. And error tolerance, the cut that eliminates the most candidates: there are tasks where a plausible but wrong answer carries consequences the company cannot absorb. This last cut weighs more heavily on artificial intelligence than on conventional automation. A badly written rule fails the same way every time, which makes it easier to catch; a system that drafts or classifies can be right many times over and then be wrong with exactly the same confidence, which means deciding in advance who reviews what.

The work in the room is on participants' own cases. Each person builds an inventory, runs it through the three cuts and tests it in small groups with other participants, who, not knowing the task, tend to spot the judgement hidden inside what its owner describes as mechanical. Whatever survives is ranked by effort and by consequence, and the group names out loud the work the company should not hand to a system, because saying so explicitly is what stops it being handed over by default.

The session ends with two lists. Where it fits, prioritized. And where it does not, with the reason written beside each one, which is what stops the same discussion recurring in six months. Alongside them comes something less visible and longer-lasting: a way of weighing the next proposal against the real operation rather than against the latest demonstration. What the inventory shows about where time goes rarely stays inside one area, and reading that kind of finding across all seven engines ALUD examines in an organization is the job of Business 360, its diagnostic.

What participants learn

• Inventory the operation's real tasks before looking at any tool.
• Apply a filter of volume, rule stability and error tolerance.
• Identify the work the company should not hand to a system.
• Prioritize candidates by effort and by consequence.
• Leave the reason for every rejection in writing.

Agenda

1. 01Why starting from the tool usually fails
2. 02Task inventory: frequency, who performs it, judgement required
3. 03Volume and repetition as the first cut
4. 04Rule stability: why shifting criteria disqualify a task
5. 05Error tolerance and the cost of a plausible but false answer
6. 06Work that is not delegated, and why to say so explicitly
7. 07Prioritizing candidates by effort and consequence
8. 08What needs to be in order before automating with AI

What the organization leaves with

• An inventory of your own operation's tasks.
• A prioritized list of where to apply AI first.
• A rejection list with the reason written beside each entry.
• Your own criteria for assessing the next tool that appears.