A corporate chatbot answers in two seconds to the question "what is the takt time of line 3 this week?" — provided that line 3 exists in the ERP, the data is up to date and the integration hasn't broken at 23:47 on Friday. When any of these conditions fails, the chatbot answers all the same: with confidence, fluency and incorrect information.
The thesis that vendors avoid stating in a demo: the corporate chatbot is not a language problem. It is a data problem. And in a Portuguese factory, the state of the data is frequently the obstacle that no language model can overcome.
What vendors don't show in the demo
Most corporate chatbot demos for industry run over clean demo data, in English, with a single-instance ERP. The reality of a textile factory in the Vale do Ave with three legacy systems, Excel files shared over a local network and item nomenclatures that evolved organically over 20 years is something else entirely.
A corporate chatbot is only as good as the worst data file beneath it. In a Portuguese factory, that file is usually an Excel with three versions and an unknown owner.
According to INE (2025), only 9.4% of small Portuguese companies with 10 to 49 employees were using artificial intelligence — and even among medium-sized ones (50 to 249 employees) adoption did not reach 20%. Eurostat (2025) identifies the lack of skills and knowledge as the main obstacle in 70.9% of EU companies. Corporate chatbots arrive at factories that do not yet have enough structured data to feed them. This article is for those who want to avoid that mistake before signing any proposal.
The complete framing of AI applied to industrial management is in the article AI applied to industrial management: from data to automated decision. Here we focus on the conversational channel — what the chatbot answers, what it invents and what it refuses.
Why this moment is different from previous ones
Language models accessible to SMEs
Until 2022, building a corporate chatbot required an NLP team, labelled training data and months of development. Today, an IT director with access to a large-scale language model API and a RAG framework (retrieval-augmented generation) can have a working prototype in days. The cost of entry has fallen. So has the cost of failing — because expectations have risen and users compare it with the ChatGPT they use at home.
Regulatory pressure that creates real use cases
ISO 27001 and the NIS2 Directive (transposed into Portugal by DL 65/2025) require documenting access, incidents and controls. A chatbot connected to the document management system can answer "what is the current version of the line 4 hygiene procedure?" without anyone opening the file server. It is not a luxury — it is auditing with automatic logging.
The AI Act (Regulation (EU) 2024/1689), in force since August 2024 with prohibitions applicable since February 2025, classifies chatbots that interact with workers in the context of performance assessment or candidate screening as high-risk systems. If your factory's HR chatbot answers questions about absences or individual productivity, read the article AI governance in industrial SMEs: what to document before the AI Act before proceeding.
Integration with vertical ERP is no longer fiction
Vertical ERPs for Portuguese industry — such as the MULTI ERP — increasingly expose data via REST API or webhooks. This means a chatbot can query stock in real time, the status of production orders or a customer's current account balance without database replication. Integration still has friction, but it is technically solvable. What is not solvable via API is the quality of the data on the other side.
Technical architecture: the four real options
RAG over internal documents
The most common pattern for industry. The chatbot indexes documents — procedures, technical specifications, machine manuals, ISO standards — and answers based on that corpus. It does not hallucinate about what is not in the corpus, if properly configured. The quality depends entirely on the quality of the indexed documents. An outdated work instruction produces an outdated answer with full confidence. There is a detail that implementation manuals rarely mention: documents digitised by poor-quality OCR — common in factories that converted paper to PDF without review — introduce silent errors into the corpus that the chatbot propagates as facts.
Chatbot with access to ERP API
The chatbot calls ERP endpoints in real time and answers "what is the stock of Ne 30 yarn in warehouse 2?" with the current value. It requires per-user authentication — not a shared service key, which is a Zero Trust problem — granular permission control and logging of every query. API latency affects the experience in a non-linear way: below one second, the user doesn't notice; between one and three seconds, they tolerate it; above three seconds, they give up and go back to the phone.
Analytical chatbot over a data warehouse
It connects to a BI cube or data warehouse and answers analytical questions in natural language: "what was the efficiency of line 2 last week?", "which customers have overdue balances over 30 days?". It is the technically most mature use case. Tools such as Qlik Sense already incorporate natural language layers over their data models. The specific risk of this pattern: the user interprets a weekly average as today's value and makes decisions based on it. The chatbot does not warn that it is talking about yesterday's data — unless it is explicitly configured to do so.
Autonomous agent with write capability
The chatbot doesn't just query — it creates orders, logs occurrences, sends notifications. It is the riskiest step. An agent that creates an incorrect purchase order due to misinterpretation of context causes real and auditable harm. For this level, read Automation vs. intelligence: when to scale to agents? before any architecture decision.
| Architecture | Implementation cost | Time to MVP | Operational risk | Typical use case in a PT factory |
|---|---|---|---|---|
| RAG over documents | Low–Medium | 4–8 weeks | Low (read only) | Consulting procedures, manuals, standards |
| ERP API (read) | Medium | 8–16 weeks | Medium (real-time data) | Stock, order status, customer balances |
| Analytical / BI | Medium | 6–12 weeks | Low–Medium | Production, financial, commercial KPIs |
| Agent with write | High | 20–40 weeks | High (irreversible actions) | Creating orders, logging occurrences |
What the chatbot answers well — and why
Query questions about structured data
"What is the delivery date of order 45231?" — if the ERP has the date and the API is available, the answer is correct and instant. The chatbot neither interprets nor infers: it returns the field. The real gain is this: the warehouse supervisor stops calling the back office to confirm data that is already in the system. In companies where that flow of internal calls consumes 30 to 45 minutes per shift, the return is immediate and measurable.
Navigation of extensive technical documentation
A footwear factory in Felgueiras with 800 to 1200 SKUs per collection has technical sheets, material specifications and quality control instructions for each reference. Finding the data sheet for sole model X in colour Y in a shared network folder takes minutes — when the folder is organised. A chatbot with well-indexed RAG returns the document in seconds. The value is not in the answer: it is in not having to search.
HR FAQ and internal processes
"How many holiday days do I have left?", "how do I request absence justification?", "what is the procedure for reporting an accident?" — repetitive questions that consume the HR department's time. A chatbot connected to pplPortal answers with the authenticated employee's data, without exposing third-party data. The volume of repetitive questions in this domain justifies the investment even in companies of 80 employees, where HR is frequently one person juggling multiple roles.
Triage of maintenance occurrences
"The cutting machine on line 3 is vibrating abnormally — what do I check first?" — if the equipment manual is indexed, the chatbot guides the operator through the first diagnostic steps. It does not replace the maintenance technician. It reduces the number of unnecessary calls and documents the occurrence automatically, which is relevant for any subsequent safety audit or root-cause analysis.
What fails — and how it fails
Hallucination about non-indexed data
This is the most dangerous error because it is invisible. The chatbot does not say "I don't know" — it says something plausible. If the question is about a procedure that is not in the corpus, the language model infers an answer based on the general pattern of the domain. In a factory, that can mean an incorrect safety instruction or an invented deadline.
A corporate chatbot's hallucination doesn't look like a computer error. It looks like the answer of an experienced colleague who is confusing two projects. It is harder to detect — and harder to correct after the user has acted on it.
The technical mitigation is called strict grounding: the chatbot only answers based on explicit sources and cites the source. If it doesn't find it, it says it didn't find it. Configure this behaviour by default — not as an advanced option that someone enables after an incident.
Outdated data with the appearance of current data
The RAG index was built in March. It is now October. The packaging procedure was revised in June. The chatbot answers with the March version, without warning. The user follows the wrong instruction. The solution is not technical — it is procedural: every document update must trigger an automatic reindexing. Without that pipeline, the chatbot becomes a well-presented archive of misinformation. This is the error we see most often in implementations that "worked in the demo" and failed in production.
Conversation context lost in long sessions
The operator starts by asking about line 3, then about the afternoon shift, then about efficiency. The chatbot loses the thread and answers about the wrong line. In an industrial context, where the user changes subject rapidly and with abbreviated language, session context management is critical. Always test with conversations of more than ten turns before putting it into production — not with isolated questions as in the demo.
Non-granular permissions
The chatbot has access to the ERP with a service key that has administrator permissions. The line operator asks "what is customer X's margin?" and receives the answer. This is not a chatbot problem — it is a security architecture problem. Each chatbot user should inherit exactly the permissions they would have in the ERP. Without Zero Trust applied to the chatbot, you have created a backdoor with a friendly interface and an empty audit log.
Fragile integration with legacy systems
The factory has the main ERP, a quality control system from the 2000s with an Access database, and a production planning Excel that the person in charge updates on Mondays. The chatbot integrates with the ERP. The other two systems are invisible to it. When the user asks "is order 1234 compliant?", the answer ignores the quality data. The chatbot does not know that it doesn't know — and it does not warn.
Trade-offs by decision dimension
| Dimension | Generic SaaS chatbot | Custom chatbot over vertical ERP | Who chooses the generic option | Who chooses the custom option |
|---|---|---|---|---|
| Initial cost | Low (monthly subscription) | High (integration + development) | Company <50 employees, first AI project | Company >100 employees, mature vertical ERP |
| Time to production | 2–6 weeks | 12–30 weeks | Immediate need, tolerance for limitations | Structured project, executive sponsor |
| Data depth | Generic documents, no ERP | Real-time operational data | FAQ, HR, documentation | Stock, production, financial |
| GDPR / NIS2 risk | High if personal data goes to an external API | Controllable if deployed on-premise or VPC | Only with non-personal data | With DPO and DPIA assessment |
| Maintenance | Vendor manages the model | Internal team or partner manages integration | Small IT, no development resources | IT with integration capability |
| Scalability | Limited by the subscription plan | Limited by the integration architecture | Organic growth | Planned expansion to multiple factories |
What works in practice
Start with the most boring use case, not the most impressive
The demo that convinces the CEO shows the chatbot answering "what is our quarterly EBITDA?" in natural language. The use case that generates real value in the first 90 days is "where is the work instruction for the finishing operation on line 7?". The difference is not one of ambition — it is one of risk and of the quality of data available. Validate the architecture with real data and a low-risk use case before expanding to analytical cases where an error has financial consequences.
A typical garment factory in northern Portugal could start by indexing its 200 quality procedures and machine manuals — documentation that exists but that no one can find quickly. The chatbot would not need integration with the ERP for this case. It would work as a conversational search engine over internal documentation. The value would be immediate; the risk, minimal; and the learning about corpus quality, real.
Logging of all questions — no exceptions
Every question put to the chatbot is a business datum. It reveals what employees don't know, what they search for most frequently, where the chatbot fails. Without logging, you have no way to improve the system or audit usage. Logging is also a compliance requirement: the AI Act requires traceability of AI systems that interact with workers. Configure logging before the first real user — not after the first incident.
Human in the loop for high-consequence answers
Define categories of questions that the chatbot escalates to a human instead of answering directly. "Can I work overtime this weekend?" — the chatbot checks the hours balance, but approval rests with the supervisor. "What is the maximum deadline I can give the customer?" — the chatbot shows the available stock, but the commercial decision is human. This separation is not a limitation of the system: it is a design decision that protects the company from errors with real and auditable consequences.
How to measure success after implementation
Adoption metrics
Monitor the number of unique sessions per week and per department — it identifies who uses it and who ignores it, which is management information in itself. A session abandonment rate (user closes without getting a useful answer) above 30% indicates a problem of answer quality, not of interface. Questions repeated by the same user on the same day are the clearest sign that the first answer was not useful. The percentage of questions escalated to a human should decrease over time as the corpus improves — if it does not decrease, the corpus is not being maintained.
Answer quality metrics
Implement explicit evaluation: after each answer, the user can mark "useful" or "not useful" with one click. Weekly, analyse the answers marked as not useful and classify the failures into four categories: outdated information, out-of-scope question, incorrect answer, correct but incomprehensible answer. Each category has a different correction — and confusing them is the most common error in the continuous improvement phase.
Operational impact metrics
- Reduction in IT helpdesk calls for procedure questions
- Reduction in average response time to stock or order status questions (compare before/after with a controlled sample)
- Number of maintenance occurrences where the chatbot was the first point of contact and the occurrence was logged automatically
Step-by-step implementation: from zero to chatbot in production
- Audit the data before any technology. Map the systems the chatbot will read from: ERP, document management, spreadsheets, quality systems. For each source, identify the owner, the update frequency and the format. If you cannot answer these three questions for each source, you are not ready to implement.
- Define the scope of the first use case with an explicit exclusion criterion. Write in one line what the chatbot answers and in a second line what it refuses to answer. "Answers questions about indexed quality procedures. Does not answer questions about real-time production data." Share this with all users before launch — not after the first complaint.
- Configure per-user authentication and granular permissions. Never use a shared service key. Each user authenticates with their own credentials and inherits the ERP permissions. Document this mechanism for NIS2 and AI Act auditing.
- Implement the automatic reindexing pipeline. Every time a document is updated in the Document Management, the chatbot index is updated automatically. Without this pipeline, the chatbot ages without warning and without anyone noticing.
- Launch with a pilot group of 10 to 20 users over four weeks. Collect structured feedback. Correct the failures before expansion. Do not launch to the whole factory at once — the error scales with the number of users and the system's reputation deteriorates rapidly after the first public incident.
- Review the logging and quality metrics monthly. Assign this responsibility to a specific person with a name and a calendar. Without an owner, the chatbot silently deteriorates while everyone assumes it is working.
The mistake Portuguese factories repeat
They buy the chatbot before they have the data. Then they blame the AI.
There is a pattern we see repeated: the company installs the chatbot, connects it to the ERP, runs the demo for management — it works. Three months later, the users have stopped using it. Not because the chatbot is bad. Because the quality of the ERP data was never sufficient to support questions in natural language. The order reference has the wrong customer code. The warehouse in the system does not match the physical warehouse after the September reorganisation. The item nomenclature has three different conventions depending on who created the record.
The chatbot does not solve data problems — it amplifies them. Before any corporate chatbot project, audit the quality of the master data in the ERP. If KORA Productivity logs line stoppages with inconsistent cause codes, the chatbot will answer inconsistently about operational efficiency. It is not an AI problem — it is a data problem that the AI made visible, with conversational elegance and without shame.
For broader context on process automation with AI, see Industrial process automation: where AI starts to pay off. For the document layer that feeds the chatbot's corpus, the article Generative AI in industrial document management: where to apply it and where to hold back details the limits of what cognitive capture can do.
The corporate chatbot is an interface, not a solution. When the data is clean, integrated and has an owner, it is extraordinarily useful. When it is not, it is a mirror that shows, with fluency and without hesitation, the real state of your operational data. The question before proceeding is not "which chatbot do I choose?" — it is "can my data stand up to being questioned in real time by someone who never forgives an inconsistency?"
Sources
- INE — Survey on the Use of Information and Communication Technologies in Enterprises, 2025. Available at ine.pt
- Eurostat — ICT usage in enterprises survey, 2025. Available at ec.europa.eu/eurostat
- European Commission — Regulation (EU) 2024/1689 of the European Parliament and of the Council (AI Act). Official Journal of the European Union, 12 July 2024.
- Directive (EU) 2022/2555 of the European Parliament and of the Council (NIS2), transposed into Portugal by Decree-Law 65/2025.
- McKinsey & Company — The state of AI: How organizations are rewiring to capture value, 2025. Available at mckinsey.com
- ENISA — Cybersecurity Guidelines for AI, 2024. Available at enisa.europa.eu
Frequently asked questions
What makes a corporate chatbot reliable in a factory environment?
Reliability depends mainly on the quality of the data that feeds the chatbot, not on the sophistication of the language model. A chatbot answers with confidence even when the data is outdated or incorrect. Integration with the ERP, file updating and data structuring are the real critical factors.
Why do corporate chatbots fail in Portuguese factories?
Many Portuguese factories have legacy systems, Excel files shared over a local network and nomenclatures that evolved over 20 years without standardisation. The chatbot is only as good as the worst data file beneath it. Disorganised data leads to incorrect answers that appear entirely confident.
What is the difference between a chatbot with RAG and one with ERP API access?
RAG indexes internal documents and answers based on that corpus — it does not hallucinate about what is not documented. ERP API access queries data in real time, answering questions about current stock or production orders. RAG is safer; ERP API is more up to date, but requires per-user authentication and access logging.
What is an analytical chatbot over a data warehouse?
It connects to a BI cube or data warehouse and answers questions in natural language, such as "what was the efficiency of line 2 last week?". It is the technically most mature pattern, but the user may interpret historical data as current and make incorrect decisions if the chatbot does not explicitly indicate the date of the data.
What are the risks of an autonomous agent that creates orders or records?
An agent that creates purchase orders or logs occurrences from a misinterpretation of context causes real and auditable harm. It is the riskiest level of implementation. It requires much more rigorous controls and human validation before any action is executed in the system.
Why do OCR-digitised documents cause problems in a chatbot?
PDF documents converted from paper by poor-quality OCR introduce silent errors into the corpus that the chatbot indexes. The chatbot propagates these errors as facts with full confidence, without warning that the source is defective. Manual review of digitised documents is essential.
How does regulation (ISO 27001, NIS2, AI Act) affect chatbot implementation in a factory?
ISO 27001 and NIS2 require documenting access and incidents — a chatbot connected to the document system automatically logs who consulted what. The AI Act classifies chatbots that assess performance or screen candidates as high-risk, requiring specific governance before implementation.