AI
AI solutions connected to real data and systems.
We build AI solutions that use the client's own data, documentation and existing information systems. Depending on the use case, a solution can include large language models, RAG, AI agents, semantic search, document classification, data extraction, process automation and integration with external APIs.
For business use of AI we define data sources, permitted actions, access rights, the audit trail, control points and the cases where user confirmation is required before execution.
When clients usually bring us in
- staff hunt for information across documents
- documents are reviewed by hand
- support answers the same questions repeatedly
- you need classification or data extraction
- you want AI inside the business process, not beside it
AI isn't always the right answer
If plain automation solves the process, we don't add AI because it's fashionable. We'll tell you where AI pays off and where it doesn't.
What this means for you
- Less time spent looking for information.
- Less manual retyping of data.
- Faster processing of documents and requests.
- More consistent answers from your team.
- A clear trail of where each answer came from.
Problem → solution
What the AI solution is made of
Click a part to switch it off - whatever cannot work without it goes dark. Click again to bring it back.
We connect AI to
- internal documents
- CRM
- ERP
- databases
- business applications
- APIs
- user portals
Capabilities
AI Solutions
Purpose-built systems for a specific business problem, not a generic chatbot.
AI agents
AI that completes several steps in sequence, within rules and permissions.
RAG
AI that uses the organisation's own knowledge and cites its source.
Document intelligence
Understanding, analysing and structuring documents.
AI customer support
Support for customers and staff with suggested answers.
AI automation
AI as a step inside an automated workflow, not a separate tool.
What is what: terms that get mixed up
A lot of very different things are sold as “AI”. The difference is not academic - it determines what data the system needs, how much work happens before go-live, what can go wrong and how the result can be checked at all.
| Term | What it means | When it fits |
|---|---|---|
| Generative model (LLM) | a model that produces text from a prompt and the context it is given | drafting, summarising, explaining, reformatting |
| RAG | the model answers from your documents and cites the source | internal knowledge, procedures, contracts, documentation |
| AI agent | a system that runs a sequence of steps and uses other systems | tasks a person does today by hand across several systems |
| Classification | sorting a record into known categories | routing mail, triaging requests, labelling documents |
| Extraction | reading specific fields out of an unstructured document | invoices, forms, contracts, tender documents |
| Semantic search | search by meaning rather than by exact wording | large document sets where keyword search fails |
| Process automation | rules and steps, with or without a model in one of the steps | repeatable tasks with clear rules |
When the rule is clear and the step repeats every day, plain automation is often cheaper, faster and more predictable than a model. We use a model where the input is unstructured, the language is natural, or the rules cannot be written out completely.
AI is not a standalone system
An AI solution rarely stands alone. To be useful it has to know who is asking, what that person may see, where the data and documents are, which systems it may read and what it may change. That makes every serious AI project an integration project as well.
- user identity and authentication
- permissions that apply to the AI as well
- databases and business systems
- the document system and the archive
- APIs of the existing applications
- ERP, CRM and DMS where they are the source
- logs, approvals and an audit trail
- monitoring after go-live
Choosing a model is only one decision
In practice “which model” matters less than where the data is, who may access it, how the output is checked and what happens on failure. We choose a model against the criteria that matter for the case, and keep it replaceable without rewriting the system.
- answer quality on your actual cases
- latency relative to how it will be used
- handling of Slovenian
- the context size the model accepts
- privacy requirements and where processing happens
- cost at the expected volume
- support for tool use and structured output
- hosting model: managed service or your own environment
Human in the loop
Full autonomy is not the goal of every AI process. Where a decision has financial, legal or business consequences, the right model is usually simple: the system prepares, a person approves, the system executes. Speed is kept, accountability stays with the person.
Governing an AI solution
Before go-live the boundaries have to be set: which data may be processed, who may use the solution, what is logged, how long it is kept and who approves higher-impact actions. This is not only a compliance question - without it you cannot establish why the system did something.
- data boundaries: what may and may not be processed
- access rights identical to those in the source systems
- assessment of the model provider and processing location
- logging of questions, sources and actions
- how long records are kept
- approvals for higher-impact actions
- an audit trail and the ability to review afterwards
What usually goes wrong in AI projects
| Risk | How we handle it |
|---|---|
| poor or disorganised source data | a source inventory and a quality review before development |
| no measure of when the output is good enough | an evaluation set of questions with expected answers |
| too much autonomy too early | higher-impact actions go through approval |
| exposure of data the user is not entitled to | permissions are enforced at retrieval, not at display time |
| no monitoring after go-live | logging, alerts and regular re-evaluation |
| the solution is not connected to the systems people work in | integration is part of the scope, not a later wish |
Who works on an AI project
- an AI/ML specialist for the solution design and the evaluation
- a data specialist for sources, preparation and quality
- a backend developer for system connections and permissions
- a solution architect to fit it into the existing architecture
- a QA engineer for test cases and regression
- a DevOps engineer for environments, monitoring and running costs
Epix also builds its own AI products, so we treat AI work as software engineering with its own requirements for data, permissions and verification - not as an add-on to a website.
How we design the AI
Use case
We start by defining which decision or step the AI takes over, and where it must stop.
Data
We map sources, quality and access. Without organised data, AI cannot produce a dependable result.
Architecture
We choose the model, the retrieval approach and the point where AI plugs into the existing process.
RAG, agents, tools
The agent uses your systems through their APIs, within the permissions you define.
Keeping AI in control
Guardrails
What the AI may and may not do, when it must ask a person and when it stops the process.
Human in the loop
A person approves the sensitive steps. Each approval is logged together with the reason.
Evaluation
Regular checks on sample sets, so we notice when answer quality drifts.
Monitoring and cost
Tracking success rate, failures and cost per task, with alerts when something deviates.
Related work
Sub-pages
FAQ
Where is our data stored?
It depends on your requirements. The solution can keep data inside the EU or in your own infrastructure. Access and retention rules are defined before development.
What about wrong answers?
AI doesn't decide alone where a mistake is expensive. We use source citations, checkpoints and human approval before an action is executed.
What does running AI cost?
We measure cost per processed item during the pilot and cap it with a daily limit, so there are no surprises.
Is AI always the right answer?
No. Where the rule is clear, plain automation is cheaper and more reliable. We say so before anything is built.
What data does an AI solution need?
It depends on the purpose: answering from internal knowledge needs the documents and the access rules for them; document processing needs sample cases; an agent needs access to the systems it is meant to work in.
Does our data have to go to the cloud?
Not necessarily. Where processing happens is decided against your requirements; what is feasible depends on the chosen model and environment, so we settle this before development starts.
How do you check that the AI answers correctly?
With a prepared set of questions and expected answers that is re-run on every change. A handful of random questions is not a measure.
Can the AI perform actions in our systems?
Yes, within the scope you define. Actions are split into read, write and approval-required; everything is logged.
When is AI not the right answer?
When the rule is clear and repeatable. Plain automation is then cheaper, faster and more predictable.
What do you need from us to start?
A description of the process you want to relieve, sample documents or questions, information on where the data lives, and agreement on which actions are permitted.
Related reading
Related solutions
Sounds like your project?
Send us the project description, your existing system, the tender documents or the event date.