Into every proposal for a system that prepares documents we write one sentence: the system prepares a draft only; the final decision and the signature always remain yours. We first used it in a proposal on 3 June 2026 and have not moved from it since.
It does not look like a selling point. It is a description of how the technology actually works: a model produces probable text, not true text. Most of the time probable text is also correct, and that is exactly what makes it dangerous. The error does not arrive as an error message. It arrives as a fluent paragraph with the wrong date in it.
This text is about what to do with that in practice. Not about "a human should check the output" - anyone will tell you that. About how to arrange things so that the check is feasible and cannot be bypassed.
Responsibility cannot be moved onto a tool, however much somebody promises it
When an automation produces a quote with the wrong price, an invoice to the wrong entity, or a document with the wrong deadline, it carries your name and your stamp. The automation supplier is not responsible for the content of the document and cannot be: they do not know your case, cannot see the file, do not have the customer.
From which follows a split worth writing into the brief before any code:
- The system is responsible for the process having run - the data loaded, the document was created, it was saved in the right place, the notification arrived.
- A person is responsible for what the document says - and has to be given the conditions for that, not just an "approve" button.
Three places where a draft has to pass through a person
Not everything in a document carries the same weight. Checking everything with the same care means checking nothing, because by the third document the reviewer will click it through.
Numbers. Amounts, rates, percentages, counts. A model can copy them correctly and it can also calculate them, and it must not do the second. A number that is not in the source must not appear in the document.
Dates and deadlines. The quietest category of error there is: a date always looks right. Payment terms, notice periods, the start of performance, the last day of a deadline.
Parties and identification. Who with whom, whose name it is in, where it is going. Here the check also meets the question of which data may leave your system at all - there is a separate text on what goes to the language model.
Confirmation before sending is a step in the process, not an extra screen
An example of our own, because it is the best tested: our bot, which handles the chat on the site, never sends a reply by itself. We dictate the reply by voice, it turns it into businesslike text in the language the customer writes in, and then waits for confirmation. The reply is either confirmed or corrected. Only then does it go out.
The difference from an ordinary "AI chatbot" is one property: between the model and the customer stands a step that cannot be skipped, because without it the message does not exist. Speed drops by tens of seconds as a result. Nothing else drops.
This arrangement pays off wherever the output leaves the company: quotes, replies to enquiries, documents for the other side. It does not pay off where the output stays inside as working material - there confirmation only delays things and people find a way around it.
Four things that make the check possible, and without which it is a formality
A draft has to be recognisable at a glance. Not in small print in the footer. A document that has not yet been through a person should look different from a finished one - a different colour, a watermark, a different file name.
The source has to be visible next to the draft. The reviewer needs to compare the text against what it came from. On one project the client asked for this themselves on 10 August 2026: they wanted to attach files directly to the document creation so that values were pulled from them rather than retyped. Less retyping means fewer places where a value can appear without a source.
The version that was signed has to be stored. Not the latest version in the system. That specific one, the one a person approved. A year later it is the only way to find out what actually happened.
The model must not send anything out on its own. Sending is a decision, not a formatting step. When a system has the ability to send, sooner or later it will do so at a moment when nobody is watching.
Split the tasks between sub-agents so it is clear who did what
An architectural decision more closely tied to responsibility than it looks. On a project in early summer 2026 we decided on 30 May 2026 not to build one universal assistant but several sub-agents, one per task. The rule from 17 June 2026 belongs with it: each agent learns separately on its own data.
The practical reason is simple. With one large assistant you cannot say what caused an error, and the fix consists of adding another sentence to the brief and hoping. With an agent that does one thing, the defect can be reproduced, fixed and tested. It is also clear which person is responsible for that task, because the task has boundaries.
Where a model has no business at all
The last category: queries where the model adds no value and does add risk. On our bot that tells clients the status of their case, a rule has applied since 10 March 2026 that a query about a specific case is served by a scripted branch. The answer is assembled from data, not generated. It therefore cannot be phrased beautifully and be wrong.
The question to ask of your own automation: how much of what the model generates today is really just pulling a value out of a database? That part belongs in a script. It makes the system cheaper to run and removes an entire class of error.
What to have written into the proposal
Four sentences. If they are not in the proposal, add them.
- The system prepares a draft; the decision and the signature remain ours.
- The output is marked as a draft until a person approves it.
- The system does not send anything out without confirmation; exceptions are listed by name.
- The approved version is archived and can be retrieved.
Want this set up at your end
Tell us which documents your company produces repeatedly and who signs them today. We will come back with a proposal for where the confirmation step belongs and what can be done with a script instead of a model.
Systems with this split are what we build as part of business process automation.
Write to info@lamapixel.com or call +420 775 599 009.
