Everyone who works with AI is now a manager

A manager asks a new employee to prepare a summary table. Two days later he receives a table with different columns than he needed, corrects it himself in the evening and from then on prepares the summaries on his own, because “it is faster that way”. On any given day, such a manager will indeed often get the task done faster. If, however, he chooses this path every time, he remains the main doer, regardless of how many people are on the team, and the team never learns to prepare the summaries. When working with AI, it is worth asking the same question that this manager should have asked himself: is the contractor unfit for the task, or has nobody told them which columns are expected?

Pause animation

An AI model is not an employee, yet its work has to be managed

This is not about treating the model like a new colleague from the department. The analogy concerns how work is organised, not the status of a person. The model has no contract, takes no leave and does not take offence at criticism. Like a new employee, however, it does not know what company it has joined, who will make a decision based on its work and how anyone will tell that it has done the job well. So you need to define the goal, provide context, set the limits of autonomy and agree the acceptance criteria. Responsibility does not pass to the model together with the instruction, just as it does not pass to an employee together with the message “take care of this”.

At the start of working with AI tools, however, it is easy to reverse this order. First comes the instruction “write me an analysis”, then the disappointment that the analysis ignores the company’s situation, and finally writing it all yourself from scratch. If the same instruction, without context and without naming the audience, went to a newly hired analyst, the result would be similar. Nobody would take it as proof that the analyst is not fit for the job. So the cause is not an imperfect prompt, but the lack of a brief that makes it possible to tell completing a task from producing a text on a similar subject.

A brief does not settle everything, though. Not every task is worth handing over to AI, just as not every task is worth delegating. For a short, one-off activity, preparing the context and checking the answer can cost more than doing the work yourself, just as explaining to someone which binder holds the contract takes longer than reaching for it. So it is the whole cycle that has to be measured: the brief, the execution, the verification and the corrections, not the time it takes for the first sentences to appear on the screen.

If, on the other hand, the task comes back every week, the calculation looks different. A well-prepared brief, a verified list of sources and acceptance criteria serve for subsequent tasks of a similar kind, and the process is organised only the first time. The manager from the beginning of this text, had he once described what the summary should look like, would have got back all his subsequent evenings. The four principles discussed below concern organising that first time.

Four principles bring order to briefing and accepting work done by AI

These principles correspond to the successive stages of delegation that every manager knows from working with people: formulating the brief, setting the limits of autonomy, accepting the result and capturing the way of working.

Principle 1: A brief, not a topic

“Analyse these offers” is the topic of a task, not a complete brief. No experienced manager would hand it over in this form to a new employee. A brief specifies who makes the decision, what matters to them, which documents may be used and which information must not be made up, as well as what form the result should take and on what terms it will be accepted.

A sample brief might read as follows: “Compare the three attached offers for the administration department. Take into account the total annual cost, the scope of service, the response time and the termination terms. For each value, indicate the document and the page. Mark missing data as missing, not as zero. Do not choose a supplier; prepare follow-up questions”. Such a brief gives a basis for checking the result. That matters more than the length of the prompt itself.

Principle 2: Limits before the work, not after the mistake

Even a well-formulated brief does not decide whether a given task should go to AI at all. A good job description does not mean, either, that a new employee is entrusted with signing contracts from day one. So it is worth adopting three categories of tasks, set for a specific process rather than once and for all for the whole technology. This is a practical division of work, not a formal risk classification.

• Delegated tasks: activities with a clearly defined result and acceptable risk, e.g. organising material or extracting data from documents, for which rules, a method of control and the situations in which the result goes back to a human are set.
• Co-created tasks: analyses, draft procedures, alternative solutions or materials for the management board, in which AI prepares proposals and a human checks the assumptions, corrects the direction and decides.
• Tasks that stay with a human in the adopted process: the final acceptance of risk, the approval of a document or a decision with consequences for the organisation or another person; AI prepares the material, but a convincing justification does not confer the right to decide.

The limits should be visible before the work begins. If they are set only after a mistake, the organisation is not managing the tool’s autonomy but reacting to its consequences, like a company that defines the scope of a power of attorney only after an unfavourable contract has been signed.

Principle 3: Acceptance based on fixed questions

The limits from Principle 2 say which results go back to a human. The review has to decide whether such a result can be accepted. Accepting work from AI works the same way as accepting work from an employee, with one difference: you cannot count on the author raising doubts on their own. That is why acceptance is worth basing on four fixed questions:

• Does the result answer the brief?
• Are the data correct?
• Do the sources support the conclusions?
• Have the limits of the task been respected?

The assessment of style is secondary, because an elegantly written mistake is still a mistake, and a neatly formatted summary with a wrong amount does not become a better summary because of it.

The scope of control is matched to the consequences. In a low-risk working summary, a spot check is enough, if the process allows it. In key matters (an amount to be paid, a procedural deadline, the legal basis of a decision), every critical piece of information has to be checked, just as every digit of a bank transfer is checked, not every third one. It also has to be defined in advance what happens once a mistake is found: extending the control, correcting the brief or suspending the use of the result.

Principle 4: Templates in the procedure, not in the chat history

A corrected brief and a proven method of control are of value to the organisation only when they are available outside the conversation in which they were created. A manager who has worked out a good way of preparing summaries with the team writes it down in a procedure. He does not count on his successor finding the right messages in the predecessor’s mailbox. The same has to be done with briefs for AI: the brief, the sources, the acceptance criteria and the typical mistakes go into the procedure or a shared library, where the team actually works. Not into yet another file that only its author knows about.

It is worth naming an owner of the template and a date for its review, because a prompt based on an outdated procedure does not become a good standard just because everyone uses it. The four principles define who accepts the result and against which criteria. They do not yet settle how to check whether it is correct in a specific task.

Three ways of checking for your next task

A real ability to assess a result requires specific actions, not a general instruction to “be careful”, which has never replaced a checklist in work with people either. Three actions are enough for such an assessment. None of them guarantees an error-free result, but each creates a specific checkpoint.

Require a source together with the answer

The first action is to demand a source. Generative models can present wrong content convincingly. This is colloquially called hallucinations, and the US institute NIST calls the phenomenon confabulation, that is, generating and confidently presenting erroneous or false content in response to a prompt. A request for sources should, however, be treated as the beginning of verification, not its end, just as a manager does not consider a report verified merely because it has a bibliography at the end: you have to open the document and check whether the cited passage really supports the claim, is current and applies to the situation at hand. You can add to the brief:

Asking for links and quotations makes sense only if the tool really has access to the internet or to the documents provided. A model without such access can generate convincing but non-existent addresses, provision numbers and passages, and the instruction “do not create quotations from memory” alone does not guarantee that the model will comply with it. So before using the answer, you need to establish whether the tool works with sources, and check every quotation and reference in the opened document.

A second model as a second pair of eyes

The second action is to entrust an initial review to another model. This can take some load off the human, much like the four-eyes principle in a team. Simply pasting the answer into another model with the question “is this right?” is not yet a thorough review, though, just as handing a colleague a report with the question “can you take a quick look?” is not one. The second model should be given the goal, the context, the acceptance criteria and the source materials, instead of being expected to reconstruct them from the finished text. Only tools approved in the organisation for the given type of data should be used, because the need for verification does not justify sending a confidential document to a random service. In a new conversation, in a different model, you can use the following prompt:

The second model is not an independent judge, however, and agreement between two answers does not prove the truth. Without external feedback, models do not reliably improve their own reasoning, and after an attempt at self-correction they are sometimes even worse, although well-designed verification reduces some of these weaknesses. Models acting as judges have known biases, and one of them is particularly important here: they recognise their own texts and rate them higher. That is why we recommend checking with a model from a different provider and verifying critical findings in the source, rather than counting how many models confirmed them. The second model is an additional layer of control, not the one who approves the document.

A source audit in a table shows whether the text says more than the source

The third action bases the control on the sources themselves. In texts based on many sources, a list of links under the text does not yet show which of them supports a specific conclusion. That is why it is worth using a simple table with a quotation from the source, the claim in the text and a link to the source. Such a layout makes it possible to check not only whether the source exists, but also whether the author has said more than the source supports. You can use the following prompt for this:

Such a table also has to be checked. Before using the material, open at least the sources of all critical findings, check that the quotations are verbatim and read their surroundings. The table is meant to make oversight easier, not to give yet another AI result an appearance of certainty.

Well-organised oversight lets you expand the scope of work with AI

Let us go back to the manager from the beginning of this text. If checking means nothing more than rewriting the whole thing, the decision to work alone is rational. Changing it does not require persuading anyone to trust technology more, but organising the task so that the result can be assessed without redoing all the work.

The benefits of working with AI should not be seen only in terms of immediate time savings. With a skilful implementation of AI:

• well-described criteria raise the quality of the whole team’s work, including work done without AI;
• shared templates make it possible to capitalise on knowledge, because one person’s experience becomes an asset of the organisation;
• clear acceptance points make it easier to run several workstreams in parallel;
• retained sources, versions and decisions make it possible to reconstruct on what basis the result was produced and who accepted it.

So the conclusion that, since AI results have to be checked, it is better to write the document yourself is worth answering with a question: does it really have to be written again, or is a better way of briefing and accepting work needed? It is a management question, regardless of whether the person asking it has the word “manager” in their job title. Everyone who briefs work and accepts its result is managing, even if their only direct report is a chat window.

This way of organising work does not have to be left to the discipline of individuals - it can be built into the environment. That is how we built SAIE. All communication with models passes through PROXY:AI, a central gateway with rules of access to models and tools and a record of who used AI, in what role and in which team. In TWIN:DESK, every answer based on documents comes with a quotation from a specific passage of the file, amounts are calculated by a calculator, and the Model Council lets you ask several models the same question and immediately see where they differ. The Prompt Assistant helps build good briefs, and conversations with a proven method can be saved, tagged and shared instead of being left in one person’s private history. The tools take over the structure and the record, while the decision on what we delegate and who accepts the result stays with a human - where it belongs.

We suggest starting with one task from your organisation: together we will describe the brief, the sources, the acceptance criteria and the method of control. Within the CDF methodology, we carry out the Initial Assessment (CDF-Eval), develop rules for human oversight of AI and methods of working with AI, and in the CDF Academy and the AI leaders programme we teach teams to work this way. These are specific measures supporting the development of AI literacy, which Article 4 of Regulation (EU) 2024/1689 (AI Act) requires providers and deployers of AI systems to take. The provision does not require every person to reach a specific level - it requires action. Get in touch with us.

Sources

• NIST AI 600-1, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, July 2024, section 2.2 “Confabulation”.
• J. Huang et al., Large Language Models Cannot Self-Correct Reasoning Yet, ICLR 2024.
• Z. Wu et al., Large Language Models Can Self-Correct with Key Condition Verification, EMNLP 2024.
• L. Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena, NeurIPS 2023.
• A. Panickssery, S.R. Bowman, S. Feng, LLM Evaluators Recognize and Favor Their Own Generations, NeurIPS 2024.
• Regulation (EU) 2024/1689 (AI Act), Article 4 as amended by Regulation (EU) 2026/1744, consolidated text.