Published · Reviewed by Horacio Poblete, CEO and founder
Start with the question that organizes everything else: who will use this deliverable, and to decide what. A reading summary for your own team and a report going to the board can come out of the same tool, in the same minute, and still call for very different reviews. What changes between them is the cost of a mistake. That’s why the standard is written by type of deliverable, not by tool or for "AI use" in general.
What workslop is and how to recognize it
Workslop is AI-assisted work that looks finished before it’s any good: complete, well written or visually convincing, but shallow or inconsistent. The term comes from a Harvard Business Review article and names something every manager has seen: the deliverable arrives quickly, and the time saved by the person who produced it reappears on the desk of the person who reviews it.
The most common signs:
- Volume without an answer: the document is long, covers everything and doesn’t answer the question that prompted the request.
- Orphan numbers: data with no source, or with a source no one has opened.
- Off-the-shelf conclusions: the recommendation would fit any company in the industry, not yours.
- Form over substance: flawless formatting and nice charts propping up fragile reasoning.
- Internal contradiction: one section says the opposite of another, and no one noticed.
- An author who can’t defend it: whoever delivered it can’t explain where a statement came from.
The last sign is the most useful day to day. If the person can’t defend the deliverable in a two-minute conversation, the deliverable isn’t theirs yet.
Why the standard is the manager’s responsibility
Many managers don’t know how to evaluate the quality of AI-assisted work because they never had to make their criteria explicit: before, visible effort served as an indicator. With AI, everything comes out looking finished, and each person decides alone when a deliverable is good. The one who pays is the manager, who reviews more, corrects more and comes to trust less of what they receive.
Without prepared managers, AI doesn’t reduce work. It shifts work.
The common view is that quality with AI is solved with a better tool or a more elaborate prompt. Almai’s view is different: the manager ensures quality, with explicit criteria and critical review. The tool speeds up production. The criteria decide what moves forward. That’s the role of quality guardian, one of the four that the AI for Middle Managers program prepares managers for.
What the standard looks like for four common deliverables
The examples below come from any leadership team’s week. Use them as a model and write your team’s own.
A report for the board
- What has to be right: every number matches the official source (the close, the BI, the financial system), never an estimate from the tool.
- What a person decides: the reading of the results and the recommendation. AI can propose the narrative; the executive signs off on the interpretation.
- How to review: the owner checks the numbers against the source, and a second person reads the narrative looking for conclusions the data doesn’t support.
A client proposal
- What has to be right: scope, deadlines and terms match what the company actually delivers, and no promise got in just because it sounded good.
- What a person decides: price, discounts, contractual exceptions and any new commitment.
- How to review: sales checks the fit with the client’s request, and whoever will deliver checks the feasibility.
A data analysis
- What has to be right: the dataset, the cut (period, filters, exclusions) and the method are written down along with the result.
- What a person decides: what the data means for the business and what to do about it.
- How to review: someone redoes one or two central calculations on their own. If the number doesn’t reproduce, the analysis goes back.
An email to a client
- What has to be right: facts, names, dates and a tone that suits that relationship.
- What a person decides: any sentence that creates an obligation, admits a mistake or changes a condition.
- How to review: the author always rereads before sending. Complaints, collections and renegotiations go through the manager.
A review checklist to copy
Take this checklist to your next review and adjust it by type of deliverable:
- Does the deliverable answer the question asked, right at the start?
- Does every number have a source, and has someone opened that source?
- Do the references cited exist, and do they say what the text claims they say?
- Is the conclusion specific to our company, or would it work for any company?
- Does any part contradict another?
- What was left out: risks, alternatives, unstated assumptions?
- Did AI make a decision no one noticed, such as a deadline, an amount or a recommendation?
- Did any confidential or personal data go in where it shouldn’t?
- Can the author defend the deliverable without reopening the tool?
- Does the recipient know what AI did and what a person reviewed?
For the eighth item, the guide on how to use AI without exposing confidential data helps separate what can go into a tool from what never should.
Who reviews what
Not everything needs to go through the manager, and trying to review everything is the fastest way to become a bottleneck. A simple arrangement separates three levels:
- Self-review: routine emails, internal summaries and drafts. The author applies the checklist and owns the deliverable.
- Peer review: analyses and documents that guide another area’s work. Someone checks the numbers and the logic.
- Manager review: anything going to the board, a client, a regulator or the press, and anything involving money, contracts or people.
Some decisions always stay with a person, whatever the tool: decisions about people (hiring, evaluation, dismissal), commitments to clients and suppliers, official numbers and the company’s public positions. AI prepares the decision. The person who decides has a name and a title.
How to agree on the standard with the team
A standard sent by email becomes a forgotten file; a standard agreed with the team becomes practice. An approach that works:
- Choose the three or four deliverables that circulate most in the team and cost the most when they go out wrong.
- In a short meeting, show an example of a good deliverable and one of workslop, without exposing anyone, and ask the team to point out the difference.
- Write the criteria for each deliverable in a few lines, in the format of the examples above.
- Keep the criteria, prompts that worked and good examples in a shared place. That living library is what keeps the standard standing when people change.
- Review the standard each cycle with what went wrong and what went right, and update the library.
If the team still uses AI on the side, without saying so, the first step is different: bring that hidden use into the open before asking for a standard.
Transparency about what AI did
Also agree on how the team declares its use of AI. The goal is to show the reviewer where to look, not to police anyone. One line at the end of the document does it: "Initial research and first draft with AI; numbers checked against the monthly close; recommendation is mine." That sentence guides the review and gives credit to the work that matters, which is checking and deciding.
With clients, the transparency rule should come from the company, not from each person. If it doesn’t exist yet, it’s worth including in the generative AI use policy.

