The development of artificial intelligence means that businesses in the transport, freight forwarding and logistics (TSL) sector are increasingly moving beyond using AI to generate text, analyse documents or prepare reports. So-called AI agents are becoming increasingly important. These are systems that not only generate responses but can also independently perform specific actions, use tools, retrieve information from company systems and take successive steps to complete a given task.

In the TSL sector, this may include automatically analysing transport orders, searching for carriers, preparing quotations, updating data in a Transport Management System (TMS), contacting customers or responding to delays. This raises the question of whether businesses can use such solutions freely and whether the activities of AI agents are restricted by the AI Act.

What Is an AI Agent Under the AI Act?

The first issue to clarify is the definition of an AI agent itself. The AI Act does not introduce a separate legal definition of an “AI agent”. The European Commission, however, indicates that an AI agent can be understood as a solution capable of receiving and processing information from its environment and taking actions based on that information, potentially affecting its environment, for example by calling functions or using tools.

An AI agent typically uses a general-purpose AI model (GPAI) and constitutes an AI system. This means that an agent is not a separate regulatory category under the AI Act. Instead, the provisions governing AI systems apply to it, together with the rules governing GPAI models where relevant.

This distinction has significant practical implications. The AI Act defines an AI system as a machine-based system designed to operate with varying levels of autonomy, which, for explicit or implicit objectives, infers from the input it receives how to generate outputs such as predictions, content, recommendations or decisions that can influence physical or virtual environments.

Autonomy is therefore an element of the definition of an AI system itself. It is not a characteristic that automatically causes a particular solution to be classified as a high-risk system. The mere fact that an agent can perform actions without obtaining human approval each time does not mean that its use is prohibited or that it automatically becomes subject to the most stringent requirements of the AI Act.

In practice, the key question is not whether a solution is an “agent”, but what the agent is used for.

The AI Act follows a risk-based approach. Certain AI applications are prohibited, others are subject to transparency obligations, while others may be classified as high-risk systems if they meet specific criteria. For AI agents, their ability to interact with people and generate content may also be particularly relevant.

As of 2 August 2026, the transparency obligations laid down in Article 50 of the AI Act are among the requirements that apply. This means that where an agent interacts directly with a natural person, that person should, in the relevant circumstances, be informed that they are interacting with an AI system.

Practical Implications for the TSL Sector

This can have very practical implications for the TSL industry. If an agent answers customer questions about transport availability, provides shipment status updates or conducts conversations concerning the terms of a transport order, the business should assess whether the agent’s operation complies with the applicable transparency requirements.

A different assessment may be appropriate for an agent used exclusively internally to analyse transport documents, search for data in a TMS or prepare a proposed response for an employee. In such cases, it cannot automatically be assumed that all obligations relating to communication with natural persons will apply.

The use of AI in employee management is particularly important. The AI Act identifies certain applications relating to employment and worker management as high-risk AI systems. These include systems used for recruitment and selection, candidate assessment, task allocation based on individual behaviour or personal characteristics, and the monitoring and evaluation of employees’ performance or behaviour.

In a TSL business, this may be relevant, for example, where a system analyses drivers and automatically assigns them routes, evaluates their work or makes decisions affecting their professional circumstances.

However, this does not mean that every system used for transport planning will qualify as high-risk. The decisive factors are the system’s specific intended purpose and how the data is used.

Requirements for High-Risk AI Agents

If an agent is classified as a high-risk AI system, the business may face substantially broader obligations. The AI Act provides, among other things, for requirements concerning risk management, documentation, the logging of certain events, data quality, human oversight and system security.

A particularly important concept is human oversight. A system should be designed so that a human can effectively supervise its operation, interpret its outputs and intervene where appropriate.

For an AI agent used in the TSL sector, this means that a business should clearly define which actions the agent may perform independently and which require employee approval.

It is important not to confuse the risk classification under the AI Act with cybersecurity risk. This distinction is particularly significant for AI agents.

A system may not qualify as “high-risk” under the AI Act while still posing a serious threat to the security of a business. For example, an agent with access to email, a TMS, a transport exchange, customer data and a payment system may be capable of performing a very large number of operations.

If its permissions are compromised or the agent is manipulated, the consequences could be far more serious than a simple error in a generated response.

When implementing AI agents, businesses must therefore distinguish between two separate issues: the system’s classification under the AI Act and the assessment of risks associated with its cybersecurity and autonomy.

The Hugging Face Incident: A Warning About Autonomous Agents

A good illustration of the scale of this problem is the incident involving Hugging Face, disclosed in July 2026. The company reported a breach affecting part of its infrastructure which, according to its analysis, was carried out from beginning to end by an autonomous agent system.

The attack began with the exploitation of a vulnerability in data processing, followed by, among other things, the acquisition of authentication credentials and movement between different environments. Hugging Face reconstructed approximately 17,600 actions performed by the agent during the campaign.

The important point is that this was not simply a matter of generating malicious code once. Rather, the system was capable of carrying out thousands of successive actions and making decisions while pursuing its objective.

The Hugging Face incident illustrates a problem that may be particularly relevant to the TSL sector. Traditional IT systems generally perform narrowly defined operations. An AI agent, by contrast, may independently select successive actions to achieve a particular objective.

If such an agent is granted access to multiple company systems, this can create a problem of excessive autonomy and excessive permissions.

For example, a freight forwarding agent might have access to a TMS, email, a transport exchange, a Customer Relationship Management (CRM) system and an accounting or settlement system.

From a business perspective, this may be extremely convenient because the agent could independently handle the entire process, from receiving a transport order through to its execution. From a cybersecurity perspective, however, it creates a single point through which multiple company systems could potentially be affected.

AI Act, NIS2 and Poland’s National Cybersecurity System Act

This is precisely why the AI Act should not be analysed in isolation from other regulations.

For TSL businesses, the NIS2 Directive and the amended Polish National Cybersecurity System Act, which implements it, may be particularly important. The amendment to the Polish Act entered into force on 3 April 2026 and introduced, among other things, a distinction between essential and important entities, as well as new cybersecurity management obligations.

The sectors covered by the legislation include transport, encompassing air, rail, waterborne and road transport.

However, this does not mean that every transport company is automatically subject to all the obligations under the National Cybersecurity System Act. An assessment of the company’s specific activities, size and the statutory criteria is necessary.

If a TSL business falls within the scope of NIS2 and the Polish legislation, implementing an AI agent should also be treated as part of its cybersecurity risk management framework.

Cybersecurity regulations require appropriate risk management measures, information system security and incident response arrangements. In Poland, entities covered by the amended legislation have, among other things, obligations relating to the implementation of an information security management system, incident management and reporting, and security audits in certain circumstances.

This is also important because an AI agent may become part of a company’s critical infrastructure.

If an AI system has access to a TMS, fleet management systems, location data, warehouse systems or other operational systems, its security should not be assessed solely by considering whether it generates accurate responses.

Businesses should also determine what could happen if the agent’s account were compromised, its instructions manipulated, a vulnerability in one of its tools exploited, or the agent gained access to data it should not be able to access.

The GDPR and Personal Data Protection

Another regulation to consider is the General Data Protection Regulation (GDPR).

An AI agent used by a TSL business may have access to data concerning drivers, employees, customers, contact persons, vehicle locations or information contained in email correspondence.

The use of AI does not exempt a business from complying with personal data protection legislation.

A business should therefore establish what data is made available to the agent, for what purpose, on what legal basis and whether the agent’s level of access is genuinely necessary.

The use of AI to evaluate employees and drivers may be particularly significant because the AI Act and the GDPR may apply simultaneously in such circumstances.

Supply Chain Security and Third-Party Providers

For businesses subject to cybersecurity regulations, the resilience of the entire supply chain may also be relevant.

An agent rarely operates in isolation. It relies on an AI model provided by an external supplier, libraries, APIs, tools, servers, cloud services and other systems.

This means that a business should assess not only the security of the agent itself but also the security of the providers and components on which it depends.

The Hugging Face incident demonstrated how important the boundaries between different technical environments can be for the security of advanced agents.

This does not mean, however, that businesses should abandon AI agents. On the contrary, their use in the TSL sector can deliver substantial benefits.

An agent can analyse hundreds of transport orders, search for carriers, compare rates, monitor deadlines, analyse documents, track shipment statuses and prepare customer communications.

The key is to design the agent’s level of autonomy appropriately. An agent should not automatically be granted access to every company system simply because doing so is technically possible.

How to Implement AI Agents Safely

In practice, a secure approach to using AI agents should be based on several fundamental principles.

1. Define the scope of tasks. Clearly establish which tasks the agent is permitted to perform.
2. Apply the principle of least privilege. Restrict the agent’s permissions to the minimum necessary to complete those tasks.
3. Maintain activity logs. Record the agent’s actions so that its decisions and operations can be reconstructed and reviewed.
4. Require human approval for significant actions. Operations with substantial financial, legal or operational consequences should, where appropriate, require human authorisation.
5. Provide an emergency shutdown mechanism. Ensure that the agent’s access can be revoked quickly or its operation stopped entirely.

For a freight forwarding agent, this could work as follows: the agent independently analyses a customer enquiry, searches for potential carriers and prepares a recommendation. It may also prepare a quotation and draft a message to the customer.

However, it should not have unrestricted authority to enter into contracts, approve payments, change counterparty details or assign orders to carriers outside an approved list.

These restrictions are not expressly prescribed by a single provision of the AI Act. Nevertheless, they are an element of rational risk management and may be relevant under the AI Act, cybersecurity regulations, data protection legislation and the rules governing a business’s liability.

What Should Businesses Take Away From the AI Act?

The most important conclusion for businesses is straightforward: the AI Act does not prohibit the use of AI agents.

There is no general rule requiring every agent to be approved by an administrative authority or to operate exclusively under direct human supervision.

What matters is how the particular system is used.

If an agent performs tasks with limited implications for people’s rights and safety, the applicable obligations may be relatively limited. If, however, it participates in decisions concerning employees, communicates with natural persons, performs actions with significant consequences or becomes part of a company’s infrastructure, a much more detailed assessment is necessary.

For the TSL sector, it is particularly important to view an AI agent not merely as a tool for improving efficiency, but also as a new component of the company’s infrastructure.

The AI Act establishes rules governing the use of artificial intelligence, while NIS2 and Poland’s National Cybersecurity System Act address system security and cyber risk management. The GDPR governs the processing of personal data.

Depending on the nature of the business, other rules may also apply, including those concerning the resilience of critical entities, employment law, transport safety and contractual liability.

As a result, safely implementing an AI agent requires more than checking whether its intended use is permitted under the AI Act. Businesses must also assess what data the agent processes, which systems it can access and what actions it can perform independently.

Before deploying an AI agent in a TSL business, it is therefore worth answering several fundamental questions:

• What tasks will the agent perform?
• What data will it process?
• Which systems will it be able to access?
• What decisions can it make independently?
• Will its decisions concern employees or other natural persons?
• Will it communicate directly with customers?
• What are its maximum permissions?
• What will happen if it malfunctions or its access is compromised?

Only by answering these questions can a business properly assess which requirements arise under the AI Act and which stem from other applicable regulations.

The biggest mistake would be to assume that, because an agent is not classified as a high-risk AI system under the AI Act, the business can give it unrestricted access to its infrastructure.

The AI Act primarily addresses risks associated with the use of artificial intelligence. Securing an autonomous agent requires a broader approach that also encompasses cybersecurity, data protection, access management and liability for actions performed by the system.

The Hugging Face incident demonstrates that, as agents become more autonomous, the main concern is no longer simply whether AI will generate an incorrect response. It is also how many actions it can perform independently, how many systems it can access and what might happen if a third party exploits its operation.

Author: Michał Krawczyk
Trainee Attorney-at-Law at Trans Lawyers

www.translawyers.eu