The ENISA Threat Landscape 2025 report notes an alarming trend: organizations subject to the NIS2 directive were targeted in 53.7% of all recorded incidents. Approximately 27.7% of data breaches occur in the digital infrastructure and services sector. For critical infrastructure enterprises and their digital partners, integrating artificial intelligence into the corporate landscape requires a radical rethinking of architectural approaches. Using external cloud APIs for autonomous AI agents creates uncontrollable supply chain security risks. A reliable scenario for sectors with high requirements is transitioning to on-premises integration, where data processing is controlled within the enterprise's secure perimeter.
The NIS2 dilemma: why external AI integrations are a critical supply chain vulnerability
The NIS2 directive requires critical infrastructure entities to strictly control the security of all third-party digital products and services integrated into their environment. When an enterprise connects an AI agent to an external large language model (LLM) via a public API, it effectively creates a data leakage channel. Any query containing personal customer data or technical documentation of infrastructure objects is transmitted to a third party, which contradicts the concept of data sovereignty.
According to the NIST Artificial Intelligence Risk Management Framework (AI RMF 1.0), when implementing AI in critical infrastructure, organizations must prioritize context, security, and system accountability rather than focusing solely on model accuracy. External APIs deprive engineers of the ability to control these parameters. Beyond the risk of data leakage during transit, there is a threat of the AI service provider itself being compromised, which makes the enterprise a hostage to the external vendor's vulnerabilities.
On-premises AI architecture: shifting from point-to-point APIs to managed data infrastructure
To eliminate supply chain risks, enterprises are moving from chaotic point-to-point integration to an orderly local infrastructure. In accordance with classic Enterprise Integration Patterns (EIP) by Hohpe & Woolf, reliable integration should be built on message-based integration, where channels, routers, transformers, and adapters ensure data flow manageability.
In such an architecture, a locally deployed LLM and its AI agents become just one of the consumers of the internal data bus. Deploying the model within a secure perimeter makes the transmission of confidential data over external networks impossible. However, on-premises deployment does not automatically eliminate all cybersecurity risks—it merely shifts the responsibility for protection and access control to the enterprise's internal infrastructure, which requires the implementation of robust architectural policies.
Metadata-level access control: preventing unauthorized AI agent access via RBAC and RLS
One of the greatest threats when working with autonomous AI agents is granting them excessive privileges. An AI agent searching corporate databases to generate responses may gain access to a wider range of documents than the user who initiated the query. This creates conditions for unauthorized data access.
Security must be ensured based on the "data-as-infrastructure" principle using mechanisms directly at the data platform level:
- Role-Based Access Control (RBAC): An AI agent must inherit the access rights of the specific user who initiated the session. If a user does not have access to the financial module, the agent should not receive that data for processing.
- Row-Level Security (RLS): Restricting access at the level of individual database table rows. Even if an AI agent has general access to a table, RLS ensures it only reads records permitted to the current user (e.g., based on regional affiliation).
Auditability and data lineage: building immutable logs for compliance
NIS2 requirements mandate full accountability and the ability to conduct detailed incident audits. For AI systems, this means the necessity of recording every step of information processing (data lineage). Every user query, the context retrieved from the database, and the final response must be logged.
As Kong experts note in their API Gateway architecture research, centralizing authentication, rate limiting, and traffic observability are critical for security. Using a local integration gateway allows for end-to-end auditing of every AI agent call. This creates a reliable audit trail, allowing regulators to verify exactly which data the AI agent used to form a response.
UnityBase platform as a foundation for secure AI integration in critical infrastructure
To implement such an architecture, enterprises need a reliable technology stack. One such solution is the high-performance full-stack JavaScript low-code platform UnityBase (a joint development by companies of the Intecracy Group alliance, where InBase acts as a key developer). UnityBase is designed for developing and modernizing enterprise systems with on-premises deployment capabilities.
Thanks to an architecture based on a unified Domain metadata model, UnityBase allows for the deployment of AI agents within a fully controlled perimeter, acting as a secure integration gateway between data and a local language model:
- Built-in security model: Support for RBAC and RLS mechanisms at the platform kernel level ensures that the AI agent only accesses data permitted to the user.
- Advanced access control: Commercial Enterprise (EE) and Defence (DE) editions provide Access Control Lists (ACL) and attribute-based security.
- Full audit (Audit Trail): The platform automatically records system queries, ensuring transaction logging for regulatory compliance.
Comparative analysis of architectural approaches to AI agent integration under NIS2 requirements:
| Comparison criterion | External AI APIs (Cloud-based) | Local integration (On-premises on UnityBase) |
|---|---|---|
| Data leakage control | Low (data transmitted to third parties) | Full (data never leaves the secure perimeter) |
| NIS2 compliance (Supply Chain) | High risk due to vendor dependency | Compliance with supply chain security requirements |
| Audit and query logging | Limited (depends on provider logs) | Full end-to-end audit of every call at the DB level |
| Access segregation (RLS/RBAC) | Difficult to implement at the model context level | Built-in segregation at the data platform level |
Transitioning to on-premises AI agent integration based on solutions like UnityBase allows critical infrastructure enterprises to implement automation while meeting NIS2 requirements regarding supply chain security and corporate data access control.
FAQ
How to ensure compliance with NIS2 requirements when using artificial intelligence in critical infrastructure?
To ensure compliance with NIS2, it is necessary to move away from external cloud APIs in favor of on-premises AI model integration. This allows for maintaining data sovereignty, controlling the digital services supply chain, and creating a reliable audit trail for all system actions.
Why is RLS (Row-Level Security) technology mandatory for AI agent integration?
RLS technology restricts access to information at the individual database row level. Without RLS, an autonomous AI agent could access confidential documents not intended for the current user. RLS ensures that the agent interacts only with data for which the request initiator has legitimate rights.
What are the benefits of deploying the UnityBase integration platform on-premises for data security?
UnityBase serves as a technological foundation that fulfills NIS2 architectural requirements through core-level mechanisms: support for Domain metadata, RBAC, RLS, and transaction auditing (Audit Trail). Commercial Enterprise (EE) and Defence (DE) editions also provide ACLs and advanced access control tools, allowing for the secure integration of AI agents into the enterprise's internal landscape.