Most Polish companies in 2026 are not “behind on AI implementation”. Quite the opposite: they have too much AI. ChatGPT and Gemini on salespeople’s personal accounts, a pilot chatbot in marketing, an automation someone put together in free n8n, Copilot licenses whose adoption nobody measures. That is not transformation. It is chaos: costly, risky and exhausting for the organization.
This article is about how to move from scattered experiments to an organized portfolio of implementations that pays back and does not expose the company to data leaks. I write it from an advisory perspective, not a technical one, because the success of AI implementations today is decided not by technology but by how we make decisions. WeAreFuture is a Polish AI consulting and implementation firm from Warsaw. We implement AI in companies ranging from industrial manufacturers and the financial sector to branches of global corporations. The pattern repeats: companies do not need more AI tools. They need order.
Most Polish companies “build AI” in chaos
Before we talk about implementation, let us name the problem. AI chaos does not look like a lack of action. It looks like a lot of uncoordinated action. Here are five signs your organization is in exactly that place.
1. Shadow AI. Employees paste company data into personal ChatGPT or Gemini accounts: contract excerpts, customer data, code, internal reports. Nobody controls it, because “it only helps with the work”. This is the most common and the most dangerous sign, because it combines legal risk with a complete lack of visibility.
We covered this topic separately: how to get shadow AI under control, from an amnesty inventory to a register of AI systems.
2. Pilots without an owner. Three or four proofs of concept are running in different departments. None has a clearly assigned owner or a measurable KPI. After a quarter nobody can say whether any of them worked, so nobody closes or scales them. They simply exist.
3. Tools instead of processes. The company bought licenses (classically: Microsoft Copilot for the whole team), but nobody changed the way of working. The result? Adoption at 5-10%, and the invoice arrives every month. This is not the tool’s fault. It results from confusing buying technology with implementing change.
4. No data layer. Every new implementation starts from zero, because company data sits in silos: in the ERP, in emails, in SharePoint, in people’s heads. Without a data foundation, every AI project first spends weeks “digging in the data” instead of delivering value.
This is not just our observation from projects. In a survey of the trust4brand community, which we ran together with Kamila Cichocka (COO of Microsoft) as part of the AI Blueprint for B2B Marketing Leaders initiative, about 26% of companies had data scattered across systems, and more than 30% of leaders admitted they do not have full access to it. Modern architectures, such as a working data warehouse or CDP, together account for only about 1/5 of responses.
5. “Buy vs build” decisions made ad hoc. Sometimes we pick a ready-made SaaS because it is fast. Sometimes we build our own solution because of “sensitive data”. Without a consistent architecture these decisions clash, and the cost of maintenance grows exponentially.
This is not an impression from a few conversations. Research shows that in Poland only about 23% of companies actively use AI, and a large share of those that have started do so in a fragmented way, without a coherent strategy (PARP, the Polish Agency for Enterprise Development, and Jagiellonian University, 2026).
What chaos costs
AI chaos has three concrete costs that sooner or later land on the management board’s desk:
Financial - the budget for licenses, pilots and tools drifts apart and they do not add up to a whole. You pay several times for similar features.
Data and compliance risk - shadow AI is a leak vector, and from 2026 the obligations under the AI Act come on top. If you do not know where and which data goes into models, you cannot demonstrate compliance. (You can run a quick check of your situation in our AI readiness audit.)
Organizational fatigue - every failed, unmeasured pilot builds a belief in people: “another AI that does not work anyway”. This is the most expensive cost, because it takes away your most valuable resource for later implementations: the team’s trust and readiness for change.
The good news: you can get out of the chaos in an orderly way. The rest of this article is a map of that transition.
It often looks like this: marketing tests one tool, customer service another, IT a third. A year later the company pays for three overlapping subscriptions, none of them talks to company data, and nobody can show the board what came out of it. This is not a lack of ambition. It is a lack of architecture, and that is exactly what you need to set up first. If the main problem is a low level of skills in the team, start with AI training for companies or e-learning for every employee - because an implementation without people who understand AI always ends up at point three above.
This chaos has its source one level higher: unresolved AI decisions that the board cannot delegate.
The first architectural decision: on-premise, cloud or SaaS
Before you even think about what to implement, you must answer the question of where it will run and who sees your data. This is the first and most important architectural decision, because it determines everything that follows: cost, security, speed of implementation and level of control.
You have three models to choose from.
Dimension | SaaS (ready-made AI services) | Private cloud (VPC) | On-premise / sandbox |
|---|---|---|---|
Data control | Limited - data passes through the provider | High - data in your own cloud environment | Full - data never leaves your infrastructure |
Time to implement | Days to weeks | Weeks | Weeks to months |
Upfront cost | Low | Medium | High |
Scalability | Very high | High | Limited by resources |
When to choose | Non-sensitive data, fast time-to-value | Sensitive data + need for flexibility | Regulated industries, critical IP, data that cannot leave |
Most companies reflexively go with SaaS, because it is fast and cheap at the start. And for many use cases (e.g. marketing support, internal productivity tools) that is the right choice. But for sensitive data or regulated industries (finance, healthcare, manufacturing with protected know-how), default SaaS can be a trap. A private cloud or an on-premise sandbox, where the language model works without taking data outside, is the more sensible option there.
The key advisory point: there is no single right answer, there is a right answer for your specific case. That is exactly why the architecture is set before the first implementation, and not discovered after the fact, when it turns out the pilot processed data it should not have touched. How do you assess which model your implementation should run in? That is what the readiness audit is for. We come back to it in a moment.
More and more often we design hybrid models: sensitive data and logic stay in a private cloud or on-premise, and for less sensitive tasks we reach for ready-made services. For companies operating in the EU, the question of data residency comes on top: where the data is physically processed and whether the provider guarantees it stays in the EEA. This is not a technical detail but a condition of compliance, and often a boundary condition of the whole project.
Automations vs AI agents: what the difference is
The second decision that organizes thinking about implementations is the distinction between two things that Polish companies constantly mix up: automation and AI agents. This distinction directly affects the budget, so it is worth understanding at the board level.
Automation is a deterministic workflow. Rules of the type “if X, do Y”, built in tools such as n8n, Make or Microsoft Copilot Studio. Automation is predictable, cheap to maintain and does not need a language model to work.
An AI agent makes decisions based on a language model (LLM). It copes with ambiguity, understands context and natural language, and can handle a case that cannot be described in advance with a rigid rule.
Between them there is “automation with AI”: a workflow in which an LLM plays the role of one function (e.g. classifies an incoming email or extracts data from a document), but 85-90% of the logic is classic, deterministic automation.
Why does this matter to the person who decides on the budget? Because mixing up these concepts costs money in both directions. You build an expensive agent where a simple automation at a fraction of the cost would do, and you overpay. Or you try to solve with rigid rules a problem that requires understanding language, and the implementation simply does not work, while you lose time and the team’s trust.
A simple example: classifying and routing incoming emails is a job for automation with a single model call, not for an autonomous agent. But handling an unusual request that requires interpreting intent and reaching into several knowledge sources is already a job for an agent. The difference in the cost of building and maintaining can be several-fold.
We broke this distinction down in a separate post: how to recognize when to implement an agent and when ai automation is enough.
Readiness audit: five areas to check before implementation
An orderly implementation does not start with choosing a tool. It starts with an honest assessment of whether the company is ready. We check five areas, and each of them can stop or save a project.
Data. Quality, availability, silos. Does the data the implementation needs exist at all in a usable form? Is it up to date? Can you get to it without a three-month integration project?
How to organize this knowledge in practice, we show in the guide to building shared context for AI.
Processes. Which processes are worth supporting with AI? Not every process is suitable for automation, and supporting a bad process only entrenches its inefficiency.
People. Skills and readiness for change. Does the team understand what AI is and what to expect from it? Is there someone who will lead adoption?
Technology. Infrastructure, integrations, ERP. Do the systems the implementation is supposed to talk to have APIs? What does the planned migration look like (e.g. an ERP change within the next dozen or so months)?
Governance and compliance. GDPR, the AI Act, internal policies. Who is responsible for compliance? Do we have an AI use policy, or does everyone fend for themselves (see: shadow AI)?
An audit in these five areas takes hours of work, not weeks, and saves months of wrong implementations. The result is not a report for the drawer but a prioritized list of implementations with an assigned architecture and risk assessment: a starting point from which it is clear what to do first. You can do a preliminary version for your company in our AI readiness audit, and if you need a deeper strategic look, that is where we start every engagement within AI consulting and strategy.
Three categories of AI implementations: how we divide them
This is where the real “getting organized” begins. All the mess from the first section comes from companies treating every implementation as a separate, independent entity. We organize them into three categories that form a logical sequence.
1. Data layer (Data). This is the foundation. A data hub, RAG (retrieval-augmented generation) systems, vector databases, integrations with ERP, PIM, CRM. Without this layer, every next implementation starts from zero and limps. It is the least spectacular but the most important category, because everything else stands on it.
2. AI agents. Autonomous solutions based on LLMs. Examples from our practice: a quoting agent (prepares a quote from a customer request), a knowledge assistant (answers questions based on company documentation), a ticket-handling agent. This is the category with the highest business value and the highest complexity.
3. Automations. Process workflows, with or without AI. Document processing, data deduplication, connecting systems, notifications, reporting. Often the fastest route to the first measurable savings.
The sequence we recommend is usually this: data layer first (so there is something to build on), then automations (quick wins that build the organization’s trust), agents last (higher value, but it requires maturity and data). Trying to start with an ambitious agent without a data layer is a classic mistake that ends in an expensive pilot with no effect.
When you get to agents, the decision moves to how to build them. We laid out three approaches to building AI agents with time, cost and who maintains them afterwards.
This is exactly how our client Ergy approached it. They are betting first on a data warehouse as the foundation, and only on top of organized data will they build further implementations. It is a less spectacular first step, but thanks to it the next projects will not fall apart in production.
Within the portfolio we prioritize implementations with a simple matrix: business value × feasibility. First what gives a quick, visible effect at low risk (usually automations on good data), because the first successes fund and legitimize the harder projects. An implementation that is both difficult and uncertain in value lands at the end of the queue, not at the beginning.
We described extending this matrix to four dimensions, together with cost ranges and before/after metrics, in a separate guide to AI automation in a company.
The same logic of three categories stands behind our AI implementation offer, because only when you see the whole as a portfolio, and not a set of random projects, do decisions start to add up to something sensible.
How it looks in practice: case studies
The theory is simple. Let me show how these three categories and architectural decisions work in specific implementations.
B2B sales - an AI agent handling 2 thousand requests for quotation a month
An implementation delivered for a Polish manufacturing company. The entire process of handling requests for quotation, about 2 thousand a month, from the customer’s request to preparing the offer, is run by an AI agent integrated with the company’s key systems: ERP, CRM, an internal knowledge base and the PIM core (product data).
It is a textbook example of combining all three categories in one implementation:
Data layer - integrations with ERP, CRM, PIM and the knowledge base, thanks to which the agent has something to work with.
AI agent - interprets the request, selects products and configuration, prepares the offer.
Automation - ties the flow between systems and runs the process end to end.
The effect shows in the numbers: the handling time of a single request fell from about 7 days to 1 day. But the value does not come down to one metric. The repetitive, time-consuming part of request handling stopped requiring manual work, and the sales team can focus on what actually requires a human.
Configuring a private AI sandbox for automations and agents - first implementations and training
At a company in the regulated financial industry we set up an on-premise infrastructure: an internal, secure sandbox in which data does not leave the client’s environment. A company chatbot runs in this environment, along with various language models made available to n8n automations, serving several use cases.
Part of the implementation was also training for the business, so that teams can build further solutions on their own instead of outsourcing them every time. This is an example of an implementation in which the architectural decision is the starting point (on-premise, because sensitive data and regulatory requirements do not allow it to leave the organization), and building internal skills is part of the project from the start.
Adoption of an AI assistant from limited use to regular use by most of the team thanks to dedicated training programs and change management
In a global pharmaceutical company, adoption of an internal AI assistant grew from about 10% to 87%. Importantly, not thanks to a change of technology but thanks to a change management program: identifying ambassadors in the organization and dedicated training delivered directly in the tool employees use.
This is the best illustration of the thesis from the beginning of this article: the value of an implementation is determined by adoption, not by the purchase of licenses itself. These three cases show three different axes of the same problem: technology and integrations (an industrial manufacturer), secure architecture and skills (the financial sector) and adoption and change management (a pharmaceutical company). A mature AI implementation usually touches all three.
When NOT to build your own solutions
An advisor who says “always build your own” is not an advisor but a salesperson. Part of the value we bring is saying plainly when an AI implementation is not worth doing or when it is not worth doing your own way. Here is our decision filter.
The process changes every month → stabilize the process first. Automating chaos gives you automated chaos.
You do not have a data layer → start with data, not an agent. Otherwise you will build an impressive demo that falls apart in production.
There is no business owner and no KPI → do not start. An implementation without an owner and without a way to measure success is a future “pilot without an owner” from the first section.
The volume is too small to justify the cost of maintenance → let it go or pick the cheapest automation. Every implementation has to be maintained. If the savings do not cover the maintenance cost, the economics do not add up.
This filter sounds discouraging, but it works the other way: by eliminating implementations that make no sense, you free up budget and organizational energy for those that pay back.
From a single implementation to a shared AI Engine
Everything we have discussed (the architectural decision, the distinction between automations and agents, the readiness audit, the three categories, the decision filter) are elements of one whole. You can do a single implementation without all this. But a portfolio of implementations that does not turn back into chaos requires an operating model.
At WeAreFuture we base it on the AI Engine, a shared company context used by people and agents: data about customers and products, procedures written down step by step and decision rules, connected to the company’s systems. We build it in stages, process by process: an AI consultant and an AI engineer from WeAreFuture work alongside your people, and every stage ends with an assessment of the effect and a decision on the next one.
The difference between “we do AI” and “we have a shared AI Engine” is the same as between individual renovations and having an architect who makes sure the whole holds together. The first gives you impressive fragments. The second gives you a company where AI actually works and measurably pays back.
You do not need to start with a big program. The most sensible first step is a short Discovery: a few weeks, at the end of which you have a process map, architectural decisions and a prioritized backlog of implementations. It is the cheapest way to stop guessing and start deciding based on facts.
If you recognize the signs of chaos from the beginning of this article in your company, this is a good moment to start by getting organized. See our collaboration model, or book a call and we will show you what it would look like in your company.
(If you want to do an AI implementation with a partner, see the AI implementation offer for companies )
Frequently asked questions (FAQ)
How long does the first AI implementation in a company take?
A single pilot usually takes 6-12 weeks, from the audit and architectural decision, through the build, to the first results. The time depends mainly on the state of the data and the number of integrations, not on the AI model itself. Implementations based on ready-made SaaS can be faster; those requiring a data layer or an on-premise environment take longer.
On-premise or cloud: which is safer for company data?
On-premise gives full control, because data does not leave your infrastructure. It is the choice for regulated industries and critical know-how. A private cloud (VPC) is a reasonable compromise: data in your environment, but with the flexibility of the cloud. Public SaaS is the fastest and cheapest, but suitable mainly for non-sensitive data. Security is not only about location. It is also about governance and AI use policies.
How does an AI agent differ from automation?
Automation runs on rigid rules (“if X, then Y”) and does not need a language model. An AI agent makes decisions based on an LLM and copes with ambiguity and context. Mixing up these concepts leads to overpaying or to implementations that do not work.
Is an AI implementation compliant with GDPR and the AI Act?
It can be, if you design it for compliance from the start. The key is to know what data goes into models, where it is processed and who is responsible for it. The biggest risk is not designed implementations but shadow AI: employees’ uncontrolled use of personal tools.
Where to start if we have a chaos of pilots?
With an inventory and an audit: list all ongoing AI initiatives, assign them owners and KPIs, close those that make no sense. Then set the architecture (where the data runs) and organize implementations into three categories: data, automations, agents. Only then decide what to scale.
How much does an AI implementation cost?
A pilot starts at a few dozen thousand zloty (PLN). Implementations requiring many integrations with systems (ERP, CRM, data warehouses) cost several times more. Most important, though: most of the cost and time is generated by the data layer, especially in “Ask Your Data” type solutions, where we want to talk to our own data warehouse or data lake. The better the data is prepared, the cheaper and faster the implementation.
Part of this cost can be covered from public funds. We compiled grants, tax reliefs and loans for AI together with the conditions that exclude some of them.
Do we need our own AI team?
Not at the start. Most companies begin with an implementation partner who brings the methodology and skills, while building internal skills in parallel through training and joint work on projects. Over time it is worth having an internal owner of the topic, but building a full team “in reserve”, before the first implementations, is a common premature expense.
How do you measure whether an AI implementation pays off?
Define the metric before the start, not after the fact. Most often it is time (a shorter handling cycle), cost (fewer hours on repetitive tasks) or quality (fewer errors, shorter response time). It matters that the metric is assigned to a business owner and measured the same way before and after the implementation. Otherwise the ROI conversation turns into a conversation about impressions.
Does an AI implementation require replacing our systems (ERP, CRM)?
Usually not. A well-designed implementation integrates with existing systems through APIs instead of replacing them. If you are planning a migration (e.g. an ERP change), it is worth including it in the architecture from the start, but an AI implementation itself is rarely a reason to replace a working system.
Sources:
PARP / Jagiellonian University - Artificial Intelligence in Companies (2026)
