Most Portuguese companies do not have an artificial intelligence problem. They have an unsolved automation problem — and confuse the two.
According to the INE, in 2025 only 9.4% of small companies (10 to 49 workers) used AI in Portugal. The figure is low, but the more relevant question is not the adoption rate. It is that a large proportion of these companies still process orders as PDFs by email, reconcile stock manually at the end of the month and approve invoices on paper. Scaling to AI agents on a process that is not yet automated is like installing autopilot in a car without power steering.
The operational distinction is this: automation executes known rules without variation; AI agents make decisions in contexts that the rules do not cover. The most common mistake we see in industrial projects is jumping straight to agents because "it looked good in the demo" — and discovering six months later that the base process was not yet stable enough to learn from it. This article gives you a decision matrix, a readiness checklist and the warning signs that distinguish a process that needs rules from a process that needs reasoning.
What you need before you begin
Before evaluating any technology, confirm that you have these conditions. Without them, the decision between automation and agents is premature — and expensive. A documented process means a written flow, even if imperfect, from start to finish. Accessible historical data means at least six months of structured records in the ERP, WMS or equivalent system. An identified process owner means a person who is accountable for the outcome — not a committee. Defined baseline metrics means you know the average time, the error rate and the current cost of the process before touching any new tool.
Two points that the usual checklists omit: integration infrastructure — can the source system expose data via API or structured file? — and a change budget. Automation and agents fail for lack of team time, not for lack of software. If the process owner has no room to take part in the pilot, the pilot fails. Always. If the process involves personal data, confirm the GDPR framework before any AI pilot — not after.
Step 1 — Classify the process by the nature of its decisions
Take the process you want to improve. For each decision within it, answer a simple question: does this decision always have the same answer if the input conditions are the same? If yes, automation solves it. Configure a rule, a workflow, a trigger in the ERP. Done. If not — because the context changes, because there are frequent exceptions, because the decision depends on unstructured information such as an email, an image or a behavioural history — you are in agent territory.
The clearest example we know: at a garment maker in the Vale do Ave, issuing dispatch notes for subcontractors is pure automation. The rules are fixed, the data is in the MULTI ERP, the process runs without human intervention. But the decision to accept or reject a batch with a colour deviation outside specification is another matter. It involves the supplier's history, the urgency of the order, the tolerance declared by the end customer and, often, a call to the quality manager. That is contextual reasoning — agent territory, not rule territory.
The practical method: identify all the decisions in the process, not just the steps. Mark each one as "fixed rule" or "context-dependent". Document the most frequent exceptions — they are the most honest signal of the real complexity. If more than 30% of the decisions are contextual, the process is a candidate for an agent.
Step 2 — Assess the real cost of exceptions
Automation is efficient in the normal case. Fragile in the abnormal case. The question few ask before choosing the technology is this: how much does each exception that reaches a human for manual resolution actually cost?
Calculate: how many exceptions per week reach a human? How long does each one take, in minutes of qualified work? What is the cost of an exception not resolved in time — delivery delay, line stoppage, contractual penalty? The formula is simple: (number of exceptions per week) × (minutes per exception) × (cost per hour of the resource). Compare that value with the estimated cost of implementing and maintaining an agent, including model training and validation.
If the volume of exceptions is low and the cost of each is tolerable, simple automation is enough — and cheaper to maintain. If the exceptions consume more than 20% of the time of the team responsible for the process, or if an unhandled exception has a direct impact on the customer, proceed to the agent evaluation. The 20% threshold is not arbitrary: below it, the cost of implementing and maintaining an agent rarely pays for itself within a two-year horizon.
Step 3 — Check the quality of the training data
Agents learn from historical data. If the data is dirty, incomplete or biased, the agent learns the mistakes of the past with more consistency than the right calls. This is the point where most projects fail silently — the agent works well in a demo, with clean data, and degrades in production, with real data.
There are four audits you cannot skip. Completeness: what percentage of the historical records has all the relevant fields filled in? Consistency: is the same event recorded in the same way by different operators? Bias: does the historical data reflect normal behaviour or an atypical period — pandemic, supply disruption, system change? Volume: for document classification or demand forecasting, the general rule is a minimum of 12 months of representative data.
A detail the manuals do not mention: in Portuguese factories with an ERP implemented more than ten years ago, it is common to find free-text fields used inconsistently by different operators — the same supplier recorded with three different spellings, item references with and without a space, dates in mixed formats. Cleaning this before the pilot is not an IT job. It is the process owner's job, with knowledge of the business. Plan at least four weeks for this phase.
Decision matrix: automation vs. agent
| Criterion | Automation (rules) | AI agent |
|---|---|---|
| Nature of decisions | Fixed rules, known conditions | Variable context, frequent exceptions |
| Process inputs | Structured (ERP fields, forms) | Unstructured (email, image, natural language) |
| Exception frequency | Low (<10% of cases) | High (>20% of cases) |
| Cost of error | Tolerable or recoverable | High or with direct impact on the customer |
| Historical data available | Not required | Minimum 6-12 months, clean and representative |
| Speed of process change | Stable (rules rarely change) | Dynamic (context changes frequently) |
| Explainability requirement | Low (the rule is the explanation) | High — requires explainable models (see AI Act) |
| Typical implementation time | 2-8 weeks | 3-6 months (validated pilot) |
| Maintenance cost | Low (update rules) | Continuous (monitoring, re-training, drift) |
Step 4 — Assess the regulatory framework
The AI Act (EU Regulation 2024/1689) has been in force since August 2024. The prohibitions have applied since February 2025; the rules on general-purpose models since August 2025. For Portuguese industry, the most immediate impact is on the risk classification of AI systems that make decisions with an effect on people — candidate screening, performance appraisal, credit decisions.
The greatest risk of an AI agent in an industrial SME is not technical — it is governance. A model that decides well 94% of the time and has no one monitoring the remaining 6% is a compliance problem waiting to happen.
Before scaling to agents, answer four questions. Does the agent make decisions that directly affect employees or customers? If so, classify the risk according to the AI Act before proceeding. Does the process involve personal data? Document the legal basis for processing before the pilot, not after. Is the model explainable? Black-box agents in high-risk decisions are a regulatory problem, not just an ethical one. Is there a human in the loop for critical decisions? The AI Act requires human oversight in high-risk systems — and "oversight" does not mean receiving a monthly report.
Step 5 — Define the oversight model before switching the agent on
This step is what separates implementations that last from implementations that are switched off after three months. An agent without structured oversight drifts — it learns from its own mistakes and amplifies them. The problem does not appear immediately. It appears after four or five months, when the quality of the decisions has fallen enough for someone to notice, but no one can explain why.
Define, before go-live: who reviews the agent's decisions and how often — daily or weekly, depending on volume and risk; what confidence threshold below which the agent escalates to a human; how the cases where the human corrects the agent are captured, because these are the most valuable re-training data that exist; what degradation metric triggers a review of the model; and who has the authority to switch the agent off if performance falls below acceptable. This last question seems obvious. It rarely has a clear answer before go-live.
In the AI applied to business management projects we support, the absence of this oversight model is the most common factor in silent abandonment — the agent is not formally switched off, it simply stops being used because no one trusts it.
Common mistakes — and the specific version of each
Automating the chaos. The company digitised a dysfunctional process without redesigning it first. The result is faster chaos. The warning sign: when mapping the process reveals that no one is quite sure who decides in the case of an exception, technology does not solve it — it makes it worse. Map the process at the gemba before any technology implementation. This means sitting alongside whoever does the work, not interviewing the operations director.
Confusing RPA with AI. Robotic Process Automation executes fixed sequences — it does not learn, it does not decide. Presenting RPA as "artificial intelligence" creates the wrong expectations and guaranteed disappointment when exceptions appear. The practical distinction: if you can write the rules in a Word document, it is RPA. If the rules depend on context that only an experienced human can articulate, it is a candidate for an agent.
Piloting with demo data. The agent works in a controlled environment and fails in production because the real data has inconsistencies that the demo data did not. A footwear factory in Felgueiras with 900 SKUs and three axes of variation — colour, size, width — has a data structure that no demonstration dataset replicates faithfully. Always pilot with real data, even if dirty, and define in advance what constitutes "good enough to proceed".
Ignoring model drift. An agent trained on 2023 data may be out of date in 2025 if market behaviour has changed — and in the footwear or textile sector, where collections change twice a year and international buyers alter specifications frequently, drift is faster than in stable sectors. Define a re-assessment schedule — at least twice a year — and treat it as maintenance, not as a project.
Scaling without a baseline. If you do not know the current average time of the process, you cannot measure whether the agent improved anything. We see this regularly: the company implements, the agent works, but no one can quantify the gain because there was no measurement before. Without a baseline, there is no business case for the next phase — and the next phase does not happen.
What we see in the Portuguese industrial context
At a typical footwear factory in Felgueiras, with 120 employees and a collection of 900 SKUs per season, the process of confirming orders from international customers is a clear candidate for an agent. The emails arrive in English, German and French, with references that do not match the internal nomenclature exactly. The decision to accept, propose an alternative or reject depends on the available stock, the production lead time and the customer's history. A rule does not solve it. An agent trained on 18 months of order and commercial-response history, with weekly oversight from the sales manager, does — and frees the sales representative for the conversations that genuinely require human judgement.
The same process at a food distribution company in the Lousada/Paços corridor, where orders arrive by EDI in a fixed format and the acceptance rules are deterministic, is pure automation. Any agent would be expensive and fragile over-engineering — and the warehouse manager would be the first to be sceptical, and rightly so.
The difference between the two cases is not the size of the company or the sector. It is the nature of the decisions within the process. That is the only question that matters to answer before choosing the technology. Everything else — costs, deadlines, suppliers — is a consequence of that answer.
Frequently asked questions
What is the difference between automation and AI agents?
Automation executes known, fixed rules without variation — if the input conditions are the same, the answer is always the same. AI agents make decisions in contexts that the rules do not cover, taking into account unstructured information, history and exceptions. Automation is efficient in the normal case; agents handle contextual complexity.
How do I know if my process is ready for an AI agent?
Before any agent, confirm: a documented process, accessible historical data (minimum 6 months), an identified process owner and defined baseline metrics. Also check whether you can expose data via API or structured file and whether you have a change budget — team time is critical. Without these conditions, the project fails.
How many exceptions justify implementing an agent?
If exceptions consume more than 20% of the responsible team's time, or if an unhandled exception has a direct impact on the customer, proceed to an agent. Calculate: (exceptions per week) × (minutes per exception) × (cost per hour). Compare with the cost of implementation. Below 20%, simple automation is cheaper to maintain.
What data do I need to train an agent?
A minimum of 12 months of representative historical data, structured and clean. Audit completeness (fields filled in), consistency (the same event recorded the same way), bias (data reflects normal behaviour) and volume. Dirty or biased data makes the agent learn the mistakes of the past with consistency — it is the silent cause of failures in production.
What is the most common mistake in agent projects?
Jumping straight to agents because "it looked good in the demo", without stabilising the base process first. Six months later, you discover that the process was not yet automated enough for the agent to learn from consistently. Always start with fixed-rule automation; agents come later, when the process is stable.
Do I need GDPR approval before an AI pilot?
Yes. If the process involves personal data, confirm the GDPR framework before any AI pilot, not after. This includes checking consents, processing purposes and data subject rights. Leaving it for later creates legal risk and delays the project — carry out the assessment at the outset.
What is the biggest risk of failure in an automation or agent project?
Lack of team time. Automation and agents fail for lack of participation by the process owner in the pilot, not for lack of software. If the person who knows the process has no room to be involved, the project fails. Always. Budget for change time, not just licences.
Sources
- Instituto Nacional de Estatística (INE) — Statistics on the adoption of information and communication technologies in Portuguese companies (2025)
- Regulation (EU) 2016/679 — General Data Protection Regulation (GDPR)
- Agência para a Modernização Administrativa (AMA) — Guide to good practices in administrative process automation
- ISO/IEC 27001:2022 — Information security management systems (applicable to data in AI agents)
- ENISA — Guidelines on AI Cybersecurity and Resilience (2023)
