AI Agents in a Business Process: What They May and May Not Do

What Is an AI Agent in a Business Process#

An AI agent in a business process is a software component that, based on instructions, data and approved access to your systems, independently carries out part of a task. It reads a document, finds a relevant piece of data, drafts a proposed answer, or triggers the next step in a workflow. It differs from classic automation in that it also makes decisions within predefined limits, rather than simply executing a fixed sequence of steps. For a director or department head, this distinction matters, because it means that before rollout you must define exactly what the agent may assess on its own and where it must stop.

In practice, an agent often works across several systems at once. Using semantic search (RAG), it finds relevant sources in internal documentation, extracts data from documents, and enters it into a CRM or ERP system through an API. The limits of its operation - which sources it can access, which actions it may trigger on its own, and where it needs confirmation - are agreed with the client before the agent is given access to production data. This step matters as much as building the agent itself, because without clearly written limits, the risk falls on the whole organization, not just the technical team.

For a decision-maker, this means that introducing an AI agent is not just a tool purchase but a project that requires the same preparation as integrating a new information system. You need to define which departments are involved, which existing systems will be connected through APIs, and who within the organization approves exceptions. Only once these questions are answered does it make sense to discuss the agent's technical design. Without this preparation, projects often stall halfway through, once it turns out that the boundaries of responsibility were never clearly set.

One such project is Kwizmo, where we are developing an AI software solution for applying artificial intelligence to a client's internal data, documentation and business processes. It includes AI agents, semantic search, document processing, integrations with existing systems, and automation of parts of the process that previously required manual work. The project shows that an agent is not a standalone application, but a layer built between existing systems and the people who use them.

Where Companies Are Already Using AI Agents#

Companies with several departments most often introduce agents where the same tasks repeat across large volumes of documents or data, and where it is clear what the input is and what the output must be. Such a process is predictable enough to describe with rules, yet large enough that manual work is a real burden on staff. Before deciding on an agent, it is worth mapping out where in the process the most repetitive work occurs and where errors most often arise from staff being overloaded.

The choice of area also depends on how reliable the existing data is. An agent extracting data from poorly structured documents or incomplete databases will need more oversight and correction in the early phase than one working on organized, standardized sources. That is why, before rollout, we review the state of your data and the architecture of existing systems - it directly affects how much autonomy the agent can be given from the start and where a longer learning and supervision period will be needed.

For the client, this means the choice of area depends not only on where an agent would bring the most benefit, but also on where the risk of error is lowest. A process with clear rules and low risk is a better candidate for a first rollout than one where every error immediately affects a customer or financial reporting. A gradual rollout that starts on a lower-risk process allows rules and oversight to be tested before the agent is extended to more sensitive areas.

• document processing and data extraction from contracts, invoices and orders
• semantic search across internal documentation and knowledge bases
• support for users handling repetitive questions and requests
• predictive analytics and recommendation systems for decision-making
• decision-support based on internal data
• automation of workflows between departments and existing systems

What an AI Agent May Do#

Before an agent is given access to your systems, the project team and the client must jointly define, in writing, the scope of its authority. This scope determines which data the agent may read, which actions it may perform on its own, and where it must wait for human confirmation. A clearly written scope is not a formality - it is the basis for both testing and for determining responsibility later, if an error or dispute arises over what happened within the process.

Within this defined scope, an agent can significantly speed up parts of a process that previously required manually reviewing documents or searching across several systems at once. Because it works within clearly set rules, its behavior can be checked and repeated, which is a precondition for introducing it into an environment where an error carries business or legal consequences. This verifiability is exactly why the scope of authority is not something added later, but part of the agent's design from day one.

It is useful for the client that the scope of authority is not fixed. Once an agent proves reliable at a given step of the process, its authority can gradually be expanded - always by agreement between client and provider, never automatically. This gradual approach reduces risk and gives the staff supervising the process time to build trust in how the agent behaves in real, not just test, situations.

• read and analyze documents and data within approved sources
• draft a proposed answer, report or decision for human review
• search and connect information across systems using semantic search
• enter and update data in systems it has approved API access to
• trigger the next step in a workflow within predefined rules
• flag a competent person when it encounters an exception or an uncertain case

What an AI Agent May Not Do#

It is just as important to write down what an agent is not allowed to do as it is to define what it may do. These limits are not there to restrict the agent's usefulness, but to protect the company from the consequences of a wrong or unauthorized decision. In a regulated industry, or in processes that affect customers, employees or financial reporting, this boundary is often also a condition for the system to go into production at all, since audit and oversight require a clear record of who, or what, made a given decision.

In practice, this means that an agent, even when it independently drafts a proposal, does not sign a contract, approve a payment, or make an HR decision in place of the responsible person. Its role is to prepare the basis - gather data, organize it, and propose - while the decision stays with a human who is accountable for it. This boundary matters especially in the public sector and regulated industries, where every decision must be traceable back to the person who made it.

For the client, it is important that these limits are written into project documentation, not just agreed verbally. Documentation is part of the handover and ensures that, even after staff or the provider change, it stays clear what the agent is authorized to do. Without this record, boundaries tend to blur over time, especially once an agent proves reliable in practice and there is a temptation to authorize it for more than was originally agreed.

• independently change data outside the approved scope or systems
• make final decisions with legal, financial or HR consequences without human confirmation
• access data it has not been explicitly granted rights to
• bypass existing security and approval procedures within the organization
• operate in the production environment without prior testing in a separate test environment
• change its own configuration or scope of authority without the client's knowledge

Data, Access and Security for AI Agents#

Any AI agent that reads or writes data in your systems is also a security question. Before it is given access, you need to determine which data it can see, who can change that access, and how every action it takes is logged. In the projects we run, development, test and production environments are kept separate, and real personal data is never used in the test environment, which reduces the risk that an early-stage error exposes sensitive customer or employee data.

Within Epix and its specialist partner network, we have access to profiles for security architecture, access management, infrastructure hardening and incident response, and standards such as ISO 27001 form part of the delivery structure within which projects are run. These profiles and standards are not a certification of Epix Group d.o.o. itself, but part of a wider network from which we assemble the project team according to the client's industry and requirements - for example, in the public sector, banking, or other regulated environments where security and traceability requirements are stricter.

For the client, this means security is not something resolved after the agent is deployed - it must be part of the design from the start. Who has access to which data, how that access is monitored, and what happens if the agent encounters data it has no right to - all of this must be defined before the agent first runs in the production environment.

• separate development, test and production environments
• no real personal data used in the test environment
• access credentials and passwords handed over formally to the client at project completion
• source code and data remain the client's property
• every change goes through review and testing before release to production

Impact on Employees and Process Change#

Introducing an AI agent changes the work of the employees who previously carried out these tasks manually. Part of their time shifts from doing the work to supervising it - reviewing proposals the agent prepares, approving exceptions, and making sure the agent stays within the agreed scope. This shift in role matters as much as the technical rollout itself, since without a clear explanation of why the process is changing and what is expected of staff afterward, the project meets resistance even when it is technically well executed.

The client's project manager plays a key role here, coordinating expectations between the departments using the process and the provider building the agent. For larger projects, we assign a project manager along with clear team responsibilities, deadlines, and communication and reporting arrangements, so every step of the change is traceable and staff running the process have a clear channel to report where the agent is not behaving as expected.

For a director or department head, this means answering, before rollout, who will supervise the agent afterward - not only who will build it. If this responsibility is not clearly assigned, oversight is lost as soon as the project moves from rollout into everyday use, and the agent ends up effectively unsupervised in practice, even though it was carefully bounded at the start.

Testing and Acceptance Before Production#

Before an agent starts working on real data, it goes through test scenarios that verify whether it stays within its agreed scope of authority. Testing includes manual and automated testing, testing as part of continuous integration and delivery, and acceptance testing against criteria agreed in advance with the client. Only once these criteria are met does the agent move from the test environment into production, where it works on real data within real workflows.

For projects where the risk of error is higher - for example in regulated industries or processes that directly affect customers - it makes sense to bring in independent QA, separate from the development team that built the agent. Independent review reduces the risk that an error overlooked by the development team carries through into production. Whether independent QA is needed is decided during project planning, not added afterward.

For the client, acceptance testing is a chance to check whether the agent works in practice the way it was agreed at the start of the project - not just technically, but also from the perspective of how staff actually run the process. Acceptance criteria are therefore prepared together with the people who will work with the agent, not just the technical team.

Maintenance and Responsibility After Rollout#

Responsibility does not end once an agent is deployed. We can take over monitoring its operation, fixing errors, applying technical and security updates, and continuing development as the process in your company changes or extends to new areas. The scope of this support is defined per project and set out in a support agreement, so the client knows exactly what is covered and who is responsible if the agent stops behaving as expected.

This classification helps distinguish an event that requires immediate handling from a request for improvement that can reasonably wait for the next scheduled release. Response times within each class are agreed in the support contract based on the criticality of the process the agent is part of - support for an agent preparing internal reports has different requirements than support for an agent that is part of a customer-facing process.

For the client, it matters that this classification is agreed before the agent goes into production, not only once the first error appears. Clearly agreed support classes let an IT manager or department head know in advance whom to notify and what to expect when the agent runs into an unforeseen situation in a real working environment.

• class 1 - outage: the system or a key part is down, handled with the highest priority
• class 2 - disruption: the system works but a specific function does not, handled by agreed priority
• class 3 - defect: a minor issue with no impact on operations, scheduled into the next release
• class 4 - request: a change or upgrade, scope assessed and timing agreed with the client

How to Choose a Provider for AI Agents#

Choosing a provider for an AI agent in a business process is not just about technical knowledge of artificial intelligence, but about the ability to put together a project team that covers the full scope of the work - from process analysis and architecture to integrations, security, testing and support after rollout. We can take on a project in full or as a single work package, and we can also take over an existing or unfinished system after reviewing its source code, architecture, infrastructure and underlying data.

Within Epix and its specialist partner network, we have access to profiles holding certifications in cloud services, security and project management, and standards such as ISO 9001, ISO 20000/20001, ISO 27001 and ISO 27701 are part of the delivery structure within which we assemble a team for each project. These certifications and standards apply to Epix and its partner network, not to an individual employee or to Epix Group d.o.o. alone, so always check them in that context when choosing a provider.

For the client, it is worth asking how the provider will assemble a team for your specific project, who the project manager will be, and how the handover is organized - documentation, access and passwords must be part of the formal project closeout, and source code and data remain your property regardless of whether the same provider continues support after rollout.

• senior engineers and solution architects to design the agent and its boundaries
• AI specialists for modeling, semantic search and document processing
• DevOps and cloud engineers for the infrastructure the agent runs on
• cybersecurity specialists for access management and oversight
• QA and test automation engineers for independent testing before rollout
• project managers to coordinate between the client's departments and the provider

Price and Project Scope#

We do not publish prices for AI agent rollouts in advance, because the price depends on the scope of functionality, the number of user roles, and how many existing systems must be connected through APIs. It also depends on whether this is a new system or the takeover and upgrade of an existing one, the volume and condition of the data that needs to be prepared, and the security, audit-trail and compliance requirements, particularly in the public sector and regulated industries.

Scope is also shaped by how much autonomy the agent will have at the start - an agent that only drafts proposals for human review requires a different scope of testing and oversight than one that independently triggers steps in a workflow. The more actions an agent is allowed to perform on its own, the more thorough the testing must be before rollout, and the more clearly its limits must be documented.

Price is therefore set only after reviewing your requirements, scope and technical complexity. Before that, we propose a short analysis that breaks the scope into work packages, so each package can be estimated and delivered separately - allowing the client to make decisions package by package, rather than approving an entire budget before the scope of work is even clearly defined.

• scope of functionality and number of user roles
• how many existing systems need to be connected and what their APIs look like
• whether this is a new system or a takeover and upgrade of an existing one
• security, audit-trail and compliance requirements
• scope of the AI work - where the data lives, what accuracy is required, and which actions the agent may perform on its own
• level of support after rollout and agreed response classes