Process automation with artificial intelligence
I build bespoke automations for professional firms and businesses: systems that read documents, sort incoming requests, prepare drafts and answer questions from your archives — using large language models where they are needed and ordinary software where it is enough. This is a separate practice from my forensic consultancy: here nothing is being proved in court; repetitive work is being taken off people's desks.
What I automate
The selection test is simple: an activity is a candidate when it is repetitive, follows rules that can be written down, and currently consumes hours of people who could be doing something better. The four recurring families each have a page of their own, plus one for law firms, which are a case apart.
Documents and data entry
Invoices, orders and forms read automatically and entered into your systems, with a human check on doubtful cases.
Email, PEC and triage
Shared inboxes sorted, data extracted from each request, draft replies prepared. Nothing sent without review.
Recurring reports and documents
Recurring reports, letters and standard documents drafted from your data, in your own templates.
AI document assistant
An internal assistant that answers questions from your documents, always citing its sources.
Automation for law firms
Intake, deadlines, document drafting and file search for law firms — with confidentiality treated as a design constraint.
How a project runs
-
Process analysis
Half a day with the people who do the work today, not only with those who manage it: where the data comes from, where it goes, which exceptions actually occur. The output is a written scope and a fixed-price quotation. If automation is not worth it, this is where I tell you.
-
Prototype on real data
A working system on your actual documents and cases, within a few weeks. You decide whether to continue by watching it work — on the easy cases and on the awkward ones, which I ask you to put in the sample deliberately.
-
Going into service
Integration with your tools, exceptions routed to a person, a log of every operation. At first the system runs alongside the manual process, until the numbers show it can walk on its own.
-
Maintenance
An automation connected to systems that change needs watching. We agree how: monitoring and maintenance by me, or a documented handover to your technical people. Either way, the system remains yours.
One undertaking, given in advance. If the analysis shows that the process is better fixed by an organisational change, by a feature of software you already own, or by nothing at all, I put that in the written outcome and the project stops there. Selling an automation where none is needed is the fastest way to lose a client's trust — and trust is the only thing genuinely on sale here.
Your data, and where it goes
Every automation handles your data and, usually, other people's: clients, suppliers, employees. A project starts from three explicit decisions, put in writing before a line of code exists.
- Where data may travel. Which steps run on your machines, which on external services, and whose — with the option, where confidentiality demands it, of running the models entirely on your own infrastructure.
- Under which contractual safeguards. Model providers are used in the business configurations where submitted data is not used to train their systems, and the processing is covered by the agreements Article 28 of the GDPR requires. These are conditions to be verified provider by provider, not assumed.
- What is logged. Every automatic operation leaves a trace: what went in, what came out, who reviewed it. You need that to trust the system, and whoever is accountable for the processing needs it to show how the system behaves.
My other profession helps on this ground: someone who reconstructs data breaches for a living designs his own systems knowing what goes wrong in other people's.
When automation is not worth it
There are three situations where the honest advice is not to start, and I would rather write them here than discover them after a signed quotation.
- The volume does not repay the project. An activity that takes a few hours a month does not justify a system that has to be built and maintained: it is fixed with a better written procedure, or left alone.
- The process changes with every case. Automation lives on recurrence. If every matter is unique and needs judgement from start to finish, a language model can at most prepare starting material — and that should be said plainly, not sold as replacement.
- The process is broken upstream. Automating a disorderly flow produces disorder at higher speed. In these cases the outcome of the analysis is a proposal to tidy the process, not an automation: it costs less and returns more.
Why I can do this work
Because it is the work I have done for twenty years, in the two halves this trade requires. The systems half: infrastructure, databases, mail, integrations between programs that were never meant to talk to each other — the record is in the CV. And the models half: in recent years I have designed and put into production systems built on large language models — architectures that read documents and answer with their sources cited, pipelines that generate and check content, multi-agent flows with supervision and logging — including an infrastructure that administers dozens of websites autonomously, from certificates to content to monitoring. Some of the projects are public.
The meeting point of those two halves is precisely what an automation project demands: knowing what a model does well, and knowing how to connect it — in a supervisable, reversible way — to the systems a business actually runs on.
Frequently asked questions
How much does an automation project cost?
It depends on the process: how many steps it has, how many systems the automation must connect to, how tidy the source data is. The quotation therefore comes after an analysis of the real process, in writing and at a fixed price — any figure named before that point would be an invention. The first assessment is free of charge.
How soon do we see something working?
The first prototype runs on your real data within a few weeks of starting, often sooner. That is a fixed point of the method: you decide whether to continue by watching the system work on your own cases, not by watching a slide deck.
Does automation replace our staff?
The projects I build take the repetitive part of the work away from people — retyping, sorting, formatting — and leave the judgement to them. Wherever the process has consequences for the outside world, a human review step remains: that is a design decision, not a technical limitation.
Do we have to change our management software?
No. The automation is built around the tools you already use — practice management software, email, shared folders, spreadsheets — by connecting them to one another. If your software has no integration interface, workable routes still exist, and the analysis stage settles which one applies.
What happens when the AI gets it wrong?
The system is designed on the assumption that it will. Cases the system is unsure about are routed to a person rather than processed blindly; every automatic step is logged and verifiable; and on any channel with legal or financial effect the final step is always human. A serious automation is recognised by how it handles its own errors, not by a promise not to make any.
Does our data stay confidential?
Yes, and as a design constraint rather than a stylistic clause: we decide where data may travel and where it may not, we put in place the processing agreements the GDPR requires, and model providers are used in configurations where your data does not train their systems. Where confidentiality demands it, the model can run on your own machines.
Who maintains the system after delivery?
An automation is software in service: it needs watching, updating when the systems it connects to change, and correcting when the process evolves. At delivery we agree how — ongoing maintenance and monitoring by me, or a documented handover to your own technical people. Neither route is compulsory.
Is there a task that eats hours of your week?
Describe to me how it works today: where the data comes from, who handles it, where it ends up. I will reply telling you whether automation makes sense, where I would start and what a first analysis would need — before any commitment.