AI
Agents and automation
Automation of repetitive processes and assisted agents, with supervision and defined limits.
What is delivered
Processes mapped before automation, so the error is not automated too
Explicit limits on what the agent may execute without review
Measurement of what was saved, in hours and in euros
What should be automated first?
The step consuming the most time and the least judgement, which is rarely the step that looks most impressive. Copying information between two systems that do not talk to each other is tedious, is what consumes most time in many operations, and is what automates most reliably.
Before that, though, it is worth asking whether the step should exist. A substantial part of the manual work in business processes exists to compensate for a missing integration or a field somebody does not fill in, and automating the compensation makes the original problem permanent.
We measure the process before proposing automation, and it is not unusual to conclude the right intervention is a process change or an integration rather than an automated flow. We say so, even when the conclusion is a smaller project than the one that came into the conversation.
How do you handle what goes wrong?
By designing for failure from the start, because external systems go down, formats change without warning and data arrives outside expectations. A flow assuming everything works fails silently, and failing silently is the worst property an automated process can have.
Each failure produces a case for human review with the context needed to decide, rather than a line in a log nobody reads. The exception queue is part of the design and is sized, because automation without an exception queue is hiding the cases where it got things wrong.
And there is reversibility. A flow updating records across several systems has to be able to undo what it did when it fails halfway, and designing that upfront costs little while manually reconstructing state after a partial failure costs days.
How do you integrate with systems that have no interface?
Preferably through a programmatic interface, even when that means asking the vendor. It is more stable, it is testable and it does not break when the screen changes. Negotiating with the system's vendor takes time and is almost always the shorter path in the medium term.
Where no interface exists and none will, automating over the graphical interface is a legitimate and fragile solution, and we say both. It works, and it breaks with system updates, so it requires budgeted maintenance and monitoring that detects the break before the user does.
What we avoid is building over a graphical interface when an alternative exists, because it is faster to set up. The difference appears after six months, when the first system update breaks the flow and nobody remembers how it worked.
What framework applies when there is automated decision-making?
If the flow takes a decision with legal or similarly significant effects on a person, a specific regime under the General Data Protection Regulation applies, with rights to human intervention, to express a view and to contest the decision. It is not the same as automation in general and is frequently confused with it.
In practice this determines the design: decisions of that nature pass through effective human review before taking effect, and the review has to be real rather than a rubber stamp. Control cases seeded into the queue measure whether review is actually happening.
Add the Artificial Intelligence Regulation's transparency obligation where a user interacts with the system: they have to know they are interacting with an automated system, and that is not met by a mention in the footer of a terms page.
How is the return measured?
By total end-to-end process time before and after, measured with the same definition at both points. It is the hardest indicator to manipulate and the one that best describes what changed for whoever is waiting on the outcome.
By the proportion of cases reaching the exception queue and by the reason. Automation with twenty per cent exceptions can be excellent if those exceptions were previously handled with the same effort, and can be bad if it is creating work that did not exist before.
And by the baseline, measured beforehand. The most common and most expensive mistake is starting to measure after automating, which makes it impossible to know whether what you are seeing is improvement, degradation, or the same performance as always seen with instruments for the first time.
How long does it take and who maintains it afterwards?
Six to twelve weeks for a flow of medium complexity, including describing the process, which is the longest phase and the one most frequently compressed. Automating from the manual rather than from the floor produces a flow that works on the normal case and fails on the exceptions, which is where the time sits.
Maintenance is ongoing and budgeted, because systems change. A flow delivered without a maintenance plan works until the first update to a system it touches, and the organisation then discovers nobody understands how it worked.
We can maintain or hand over. When we hand over, we do it with documentation written during the build and a session where your team makes a change rather than reading about one, because reading documentation is not the same as knowing how to operate.
How do you stop automation ageing badly?
With scheduled periodic review rather than reactive maintenance. A flow running for a year with nobody looking at it is producing results nobody has recently verified, and the discovery that it stopped working correctly usually comes from outside rather than inside.
And with monitoring over the outcome rather than only over execution. A flow that runs without error and produces wrong data passes any technical check, and the only way to detect it is periodically verifying a sample of what it produced against what it should have produced.
Where agents and automation can be run from
Not every delivery model suits every service. The table shows only those that make sense for this work, with the data residency position of each.
| Model | Where | When it makes sense | Personal data |
|---|---|---|---|
| Onshore Portugal | Lisbon, Porto, Braga, Coimbra, Aveiro, Faro, Funchal and Ponta Delgada | When data cannot leave the EEA, or when the end customer is Portuguese | Stay inside the EEA. No transfer. |
| Nearshore in Portugal | Lisbon and Porto, for foreign buyers | When you need a multilingual European base without incorporating | Stay inside the EEA. No transfer. |
| Global network | Uzbekistan, the Philippines, Poland, the Dominican Republic, Mexico, Colombia, Turkiye and Africa | When you need continuous cover, specific languages or the lowest cost | Poland is inside the EEA. The others require standard contractual clauses. |
The data column describes the applicable framework and is not legal advice. The detail is in international data transfers.
Related services
- AI managed servicesOngoing operation of AI-assisted workflows, with people in the loop where the risk requires it.
- Training dataCollection, annotation and review of model training data, including European Portuguese and the African variants.
- Evaluation and safetyModel output evaluation, adversarial testing and safety review, by native speakers.
- Document intelligenceExtraction and classification of information from documents, with human verification where it matters.
Frequently asked questions
Where do we start?
By measuring the process as it is. It is not unusual for the conclusion to be an integration or a process change rather than an automated flow.
What happens when a flow fails?
It produces a case for human review with context, not a log line nobody reads. The exception queue is part of the design.
Do you integrate with systems that have no interface?
We do, and we say that automating over a graphical interface is legitimate and fragile, and requires budgeted maintenance.
Is there automated decision-making about people?
If there is, a specific regime applies with a right to human intervention, and the design then requires effective review before the decision takes effect.
How do you measure the return?
By total process time before and after, with the baseline measured before automating.
How long does it take?
Six to twelve weeks for medium complexity, with describing the process the longest phase.
Who maintains it afterwards?
Us or you. If we hand over, we do it with a session where your team makes a change rather than reading about one.
What if the step should not exist?
We say so. Automating the compensation for a missing integration makes the original problem permanent.
Let us look at the numbers for your case
Tell us which processes you want to outsource, in which languages and at what volume. We come back with a euro estimate and an operating design, with no commitment.
We reply within 6 hours on working days. If you would rather write: info@corpshore.solutions