The collections follow-up of a services company has been running by itself for a year. It works, or at least nobody has complained. The manager who configured it no longer works there. Nobody knows with certainty what permissions the system has, what information it consults, or who could suspend it if tomorrow it started sending the wrong reminders to the ten best clients.
That scene, which my book AI Employee uses as a typical example of a first audit, does not describe a careless company. It describes the majority. The commercial proposal that the salesperson "makes" carries an artificial draft underneath. The monthly report that the analyst "prepares" is a pipeline with retouches. Some of those actions are simple assistance. Others are already part of the operation: if the system stopped doing them tomorrow, someone would have to do them. And probably nobody remembers how anymore.
The book calls that the second workforce. And the problem is not that it exists. It is that it is invisible.
A workforce nobody hired
Look at your company without paying attention yet to platform names. Look for work. Maybe one system recommends commercial priorities every morning. Another classifies incoming requests and routes them. Another drafts replies that someone reviews, or that nobody reviews anymore. Another generates invoices, triggers payment reminders, updates the CRM after every call, decides which case deserves human attention.
Nobody signed a contract with any of those systems. Many came in as pilots that stayed, as new features of software that was already there, as the personal project of someone who later changed positions. The result is an embryonic artificial workforce that the organization keeps managing as a collection of tools: with licenses and passwords, but with no roles, no metrics and no one responsible.
The discomfort, if you feel it, is the majority position. The book cites the Deloitte survey of more than three thousand business and technology leaders in twenty-four countries: 84% of organizations had not redesigned their jobs in function of the capabilities of AI, even though many already expected to automate part of their roles. Technology came in first and work design goes behind. The inventory exists to invert that order.
The inventory almost nobody has done
The exercise in chapter 1 is deliberately simple. Make an initial map with three categories: work done by people, human work assisted by AI, and work executed by software. Do not look for perfect accuracy; look for visibility.
The first pass usually surprises, because the criterion is not which platforms you bought but what work is being produced and who really produces it. That is where the cases I already mentioned appear: the artificial draft underneath the proposal "of the salesperson", the pipeline underneath the report "of the analyst", the collections that runs by itself. The surprise is not technological. It is administrative: you discover how much real work depends on systems that appear in no org chart.
Important: at this stage nothing has to be baptized as an AI Employee. That classification has its own instrument and its own requirements, which I develop in what is an AI Employee. What the inventory seeks is prior and more urgent: to recognize that artificial work exists, where it is and what size it is.
The six questions a technology purchase never asks
With the map in hand, take each activity from columns two and three and ask it six questions. They are the ones in the book, and they rarely appear during a purchase:
- Who answers for the result? Not who configured it. Who answers. If the answer is a shrug, you found an administrative orphan.
- How do we know it works? Is there a metric, or only the absence of complaints?
- What permissions does it hold? Not which ones it should have: which ones it has. The distance between the two answers is pure risk surface.
- What information does it consult? And who decided that it could consult it?
- Who can suspend it? And has anyone ever done it, even as a test?
- What happens when an exception it does not understand appears? Does it escalate it, improvise it or bury it?
On the second question, the book leaves a sentence that deserves to stay taped on the wall of any management committee:
Silence is not evidence of quality; sometimes it is evidence that nobody is looking.
These questions usually reveal an uncomfortable void. The company can have active automations and, even so, lack anyone clearly responsible. It can celebrate thousands of executed actions without knowing their impact. It can have granted accesses without documenting authority, or depend on one person who knows how to stop the system but never left that knowledge in writing.
The incident as a method of discovery
There are two ways of getting to know your second workforce: through an inventory or through an incident. The difference between the two is not one of degree. It is one of price.
The inventory costs a few hours of honest work and some discomfort. The incident costs whatever it costs the day the system fails: the badly calculated price that reached the client, the collection reminder sent to whoever should not have received it, the exception buried for months that shows up turned into a legal claim. And it costs something harder to recover: the internal trust in everything else that runs by itself, because after the first incident every automation becomes suspect.
When artificial work stays invisible, its risks, its costs and its real contribution stay invisible too. None of those three things disappears by not looking at it: it only waits. The day the system fails, everyone discovers at the same time that nobody was really managing the work, and governance gets improvised in panic, which is the worst design room that exists.
Invisible systems also share a perverse trait: while they work, they accumulate responsibility. Every month that collections runs by itself without complaints, someone assigns it a bit more, or stops reviewing a bit more. Autonomy grows by sedimentation, without anyone having granted it. When the incident arrives, it does not hit the small system that was configured a year ago: it hits the one that grew silently during all that time.
The question that comes before technology
The natural reaction after recognizing the second workforce is to look for the best platform to manage it. The book warns that this reaction, although it seems practical, reproduces the error that needs to be corrected: starting from the tool again.
Technology has a seductive force: it shows what it can do and invites us to confuse capability with need. But the question "what can we do with this AI?" opens possibilities without direction. The question that governs the whole method is a different one: what work really needs to be done?
The exercise to internalize it: choose an initiative you are considering and remove the name of the tool for a moment. Describe only four things: the result the organization needs, the frequency with which it must be produced, the consequences of doing it badly and the person who answers for it. Read it out loud without the brand. If the case loses its meaning when the product disappears, you were defending a technology, not solving a problem. If it stands on its own, you have real work waiting for design, and tool selection becomes what it always should have been: the last decision, not the first.
That discipline of designing the work before choosing the occupant has its own name and framework: WRM, managing the work before the worker. And its absence has an exemplary case that we tell in the demo that fools you.
Seeing the map changes the conversation
You do not need to solve the complete map today. You need to see it. By making artificial work visible, the management conversation changes in nature: you no longer ask what tools the company has, but what responsibilities are being executed, with what level of autonomy and under what human accountability.
That is the difference between having technology inside an organization and starting to build, deliberately, a hybrid workforce. The second workforce already exists in your operation. The only pending decision is whether you are going to know it through an inventory or through an incident.
Frequently asked questions
It is the set of artificial systems that already execute recurring work in an organization without being managed as work: they recommend priorities, classify and route requests, draft replies, generate invoices, trigger reminders and decide which case deserves human attention. The company manages them as tools (with licenses and passwords) but with no roles, no metrics and no one responsible. The book AI Employee calls it the second workforce: it exists in almost every organization, many times for years already, and it stays invisible because nobody has done the inventory that makes it visible.
Start with a map of three columns: work done by people, human work assisted by AI, and work executed by software. Do not look for perfect accuracy, look for visibility. Then take each activity from columns two and three and ask it the six questions of the book: who answers for the result, how do we know it works, what permissions it holds, what information it consults, who can suspend it and what happens with the exceptions it does not understand. The objective of this stage is not to classify anything as an AI Employee: it is to recognize how much real work depends on systems that do not appear in the org chart.
Six, in this order. First: who answers for the result? Not who configured it: who answers. Second: how do we know it works? A real metric, not the absence of complaints. Third: what permissions does it hold? The ones it has, not the ones it should have: the distance between them is risk surface. Fourth: what information does it consult and who decided that it could consult it? Fifth: who can suspend it, and has anyone ever tested it? Sixth: what happens when an exception it does not understand appears, does it escalate it, improvise it or bury it? A shrug on the first question is already a finding: an administrative orphan.
Because it crossed a border. While software only helped people, the topic could live in the Technology department. When a system starts receiving work (recurring responsibilities, authority, consequences on clients and money), questions appear that no technical conversation can answer: who defines the result, what authority the system has, who reviews its performance, who answers if it makes a mistake and when it must be stopped. Those are management questions, the same ones an experienced manager has been answering his whole career. The only new thing is that the occupant of the role is no longer always a person.
To classify what the inventory shows you, continue with what is an AI Employee. To design the work before choosing the occupant, read WRM: managing the work.
Want the full method? Read AI Employee. For executive AI consulting or keynotes and workshops.
Go deeper
Want to bring your team to the next belt?
Book a discovery call or explore the full book.