AI automation in Cyprus
Automation for the work that rules could never cover: the step where somebody has to read something and decide.
Most automation stops at the first judgement call. A rule can move an invoice between two systems. It cannot read a supplier email, work out that the delivery slipped, and route it to the right person. That step is where the queue builds up, and it is the step we automate.
Nicosia-based. We run this in our own product before we sell it.
The automation you already have stops at the hard part
Rules are excellent at the middle of a process and useless at the edges. So the tidy, deterministic parts get automated, and everything that arrives as free text, a scanned document, an exception or an unusual case lands back on a person.
The result is a process that looks 80% automated and still needs somebody every day. The remaining 20% is not leftover work. It is the work that was hard in the first place, and it sets the pace of the whole process.
How this differs from rule-based automation
We build both, and the distinction matters more than the label. Picking the wrong one is expensive in opposite directions: a model where a rule would do is unpredictable and costs money per run, and a rule where judgement is needed simply does not work.
- 01
Use a rule when the answer is already in the data
If the field exists, the mapping is fixed and the same input always gives the same output, a rule is faster, cheaper, testable and auditable. That is process automation, and it is usually the right answer. We will tell you when it is.
- 02
Use a model when a person is currently reading something
Classifying an inbound message, pulling terms out of a contract, deciding whether two records are the same customer, drafting a reply for review. These are the steps where a rule needs a hundred exceptions and still misses the hundred and first.
- 03
Most real processes need both
The model handles the judgement, and deterministic code handles everything around it: fetching, validating, writing back, retrying, logging. A system that is a model end to end is a system nobody can debug.
What we actually build
The same four parts, whatever the process. The interesting engineering is in the last two, and they are the ones most projects skip.
- 01
The intake
Getting the work in reliably: mailbox, upload, queue, API, scanned batch. Unglamorous, and the most common cause of an automation that works in a demo and not on a Monday morning.
- 02
The judgement
The model call, with the retrieval and the context that makes it answerable. Prompts and grounding are version-controlled and change through review, not by someone editing a text box in production.
- 03
The confidence gate
Every output carries a confidence signal, and low-confidence cases route to a person instead of being written back silently. This is the part that decides whether the system is trusted after month three.
- 04
The evidence trail
What went in, what came out, which version decided it, who reviewed it. Needed to debug it, needed to improve it, and needed under the EU AI Act for anything that affects a person.
Where we will tell you not to
We would rather lose the work than ship an automation that quietly makes things worse.
- 01
When the process is not agreed
If two people would handle the same case differently and neither is wrong, there is nothing to automate yet. Automating a disagreement just makes it faster and harder to see.
- 02
When a wrong answer is expensive and nobody will check
AI automation is right when a human reviews the uncertain cases. If nobody has the capacity to review anything, the honest answer is that this is not ready, not that we should raise the threshold.
- 03
When a rule would do
A model costs money per run, varies between runs, and is harder to test. If the logic is stable, we will build the rule and charge you less.
We run this ourselves
Pileform is our own product: it reads finance documents, extracts what is on them, and turns them into post-ready entries across 55 VAT jurisdictions and 11 languages. It is built exactly this way, including the confidence gate and the review queue, because we are the ones who get called when it is wrong.
Related
Questions we get asked
What is the difference between AI automation and process automation?
Process automation handles work where the rules are known and fixed: move this field to that system, reconcile these two ledgers. AI automation handles the step where somebody currently has to read something and decide. Most real processes need both, and we build both, so we have no reason to talk you into the more expensive one.
How do you stop it from being confidently wrong?
Every output carries a confidence signal and low-confidence cases route to a person rather than being written back silently. We also keep a full evidence trail of what went in, what came out and which version decided it, so a wrong answer is something you can investigate rather than something you discover in an audit.
Do we need a lot of data first?
Usually no. Most of this work uses general models with your own documents and systems supplying the context, so there is nothing to train. If a case genuinely needs a trained model, we will say so, and it changes the project shape and cost enough that you should hear it early.
Where does our data go?
We default to EU-hosted processing and we tell you exactly which provider handles what before anything is built. If data cannot leave your infrastructure, that is a design constraint we work within, not a reason to say no.
How long before it is doing real work?
A first automation on a single, well-defined process typically reaches production in weeks rather than months. The scoping audit that comes first is deliberately short, because the biggest risk in this work is automating the wrong step beautifully.
What happens when the model gets it wrong?
Something you can see, correct and learn from. The confidence gate catches the cases it is unsure about, the review queue catches the ones it was wrong about but confident on, and both feed back into the evaluation set so the same mistake is caught next time.
Start with the step that still needs a person
Tell us which part of a process keeps landing back on somebody's desk. If a rule would fix it, we will say so.