E-ITS and artificial intelligence

The E-ITS portal now contains a module called SYS.5.15: Tehisarusüsteem (artificial intelligence system) in the 2026 version of the catalogue (eits.ria.ee, SYS.5.15). Its stated purpose is to set out measures for taking an AI system into use and operating it securely in an organisation.

A short history, so you recognise the older name. RIA's September 2025 newsletter reports that the 2024 version added two new modules, one of them for AI systems (RIA newsletter no. 4, 2025). In the 2024 version the module sat under the Estonian applications group as APP.EE.2 "Tehisintellektisüsteemid". In the 2026 catalogue the AI module appears as SYS.5.15. If you set up controls on the 2024 version, map them across when you move to 2026.

The module's measures run from M1 to M22. The ones that matter most for an organisation using AI are these:

• M1 Planning. Define the purpose, users, use cases and scope of the AI system. Assess whether and to what extent public large language models (LLMs) may be used, whether there is a legal basis for processing all the data involved, and how use and results will be checked.
• M3 Risk assessment and impact assessment. Assess the effect on business processes and the maximum possible harm, and the effect of the system's decisions on people's fundamental rights.
• M4 Responsibility. Assign roles across the lifecycle, a data owner and a product owner for each AI system, and a management-level steering group that reviews AI projects and compliance with policies.
• M5 Compliance with legislation. Identify legal requirements, check intellectual property and licence terms, and take the EU AI Act and the GDPR into account.
• M12 Correctness and transparency of results. For high-risk uses, a person validates and approves the system's initial decisions, and results of operation are logged so that you can check which parameters influenced a decision and when.
• M16 Supply chain. Map external providers and verify them before taking in a model or data from outside.
• M17 and M22 Confidential data. Protect confidential data, use pseudonymisation or anonymisation where possible, encrypt, and use data loss prevention (DLP) tools with defined people and a procedure for DLP alerts.

Note the allocation of responsibility in the module text: management owns planning and accountability (M1, M4), the IT manager owns most of the operational measures, and the information security manager owns additional technical safeguards (M19). The module's further-information section points to the EU AI Act (Regulation (EU) 2024/1689), the OWASP Top 10 for LLM Applications 2025 and ISO/IEC 42001:2023.

The E-ITS module links its measures to a catalogue of threats. Several are the ones people meet every day:

• Uncontrolled adoption of new technology (T1.06). AI tools are rolled out fast, and confidential data can reach unauthorised parties because security was not considered first.
• Loss of personal or confidential data (T3.02). Staff paste documents, contracts, customer data or incident details into a public chat tool. Once the text leaves your control, you cannot recall it.
• Third-party and cloud dependency (T2.10). Use of data by the provider without the owner's permission, unclear data mapping, and a business process that stops when the provider has an outage.
• Missing monitoring (T2.07). No logs means no proof of what the tool did or who asked for it.
• Wrong results and supply chain (T3.01, T6.03). Confident but wrong output that a person acts on, and models or plug-ins from sources nobody examined.

Two practical points follow. If you cannot say which data may go into which tool, staff will decide for themselves, so write a short rule. And a tool with write access is a bigger risk than a chat window: an assistant that can change records is an actor in your systems, and needs the same thought as a new employee. What may it do, who checks, how do you know what it did? Where personal data is involved, M5 requires compliance with the GDPR and the Estonian Personal Data Protection Act.

AI assistants are genuinely useful in compliance work. They draft risks, map controls, summarise documents and prepare tasks. The risk lies in how they are connected. Three principles cover most of it.

Least privilege. The assistant should see and change only what the person using it may see and change, and only in one organisation. Do not give it a shared administrator account. Prefer sign-in with the user's own account over a long-lived key, so that revoking the user revokes the assistant.

Human approval. Every change should be proposed, not applied. A person reviews each item and approves it. This matches the spirit of E-ITS measure M12, where a person validates decisions in high-risk uses. The assistant should also not be able to close the loop: it should not mark work as done or controls as implemented. Completion is a human statement of fact.

Audit trail. Every change made with the help of AI should be recorded: who approved it, through which connection, what changed. Ideally the log is tamper-evident so a later edit is detectable. This answers E-ITS M12(e) and the monitoring concerns of M13, and it is what an auditor will ask for.

Beyond those three:

• Check what leaves. Know which provider processes the content, where, and under what terms. Prefer an approach where the data stays in your system and the assistant reads it on demand rather than a copy being built elsewhere.
• Treat output as a draft. A person reviews it before it becomes a record.
• Make removals two-step, with a preview before anything is applied.
• Train people. Short guidance on what not to paste beats a long policy no one reads.

How InfoPol does this

InfoPol is a compliance and ISMS platform with risks, processes, assets, vendors, controls, documents, tasks, incidents, training and a tamper-evident audit log. Its AI layer, AbleTrace, lets your own AI assistant work through the InfoPol MCP server, and the limits are built into the server, not just written in instructions (AI and MCP, AbleTrace overview):

• The assistant signs in with OAuth using your own InfoPol account, and an organisation administrator has to turn MCP access on first. It is off by default.
• A connection is bound to one organisation and to the permissions of the user who created it.
• Every write needs a person's approval of that specific item. A request without approval is rejected before anything is saved.
• The AI does not complete work. A task can only be set to new or in progress, and a control can only be raised up to partially implemented. A person finishes tasks and marks controls implemented.

ISO/IEC 42001:2023 is titled "Information technology — Artificial intelligence — Management system". As the title says, it is a management system standard, in the same family of approach as ISO 27001 but for AI. The E-ITS AI module lists it as a reference. The practical difference is scope: E-ITS gives you measures for secure use of AI systems, while a management system gives you the policy, roles, risk process, review and continual improvement that wrap around them. InfoPol has a native ISO/IEC 42001 framework for organisations that want that route. We did not retrieve the standard's page on iso.org, which blocked our request, so for the formal scope and certification details go there directly.

The EU AI Act is Regulation (EU) 2024/1689 (EUR-Lex). E-ITS measure M5 tells you to account for it and, where a system is high-risk under Article 6, to meet its requirements. Three points to hold on to:

• Timing changed in 2026. Regulation (EU) 2026/1744, the "Digital Omnibus on AI", was published in the Official Journal on 24 July 2026 (EUR-Lex). For high-risk systems listed in Annex III, the Chapter III requirements now apply from 2 December 2027, and for those covered by Annex I product legislation from 2 August 2028.
• AI literacy stays, with a softer wording. Under the amended Article 4, providers and deployers must take measures to support the AI literacy of their staff, without a duty to guarantee a specific level for any individual.
• Most organisations are deployers, not providers. If you use an AI tool that someone else built, your role is usually that of a deployer. Whether any high-risk rules reach you depends on the use case, for example whether AI is used in employment decisions or other areas listed in the Act. That is a legal question for your situation.

The Omnibus changes more than these dates, and we have not analysed the rest, for example the transparency rules in Article 50. Check them against your own use.

1. Inventory the AI tools in use, including those staff adopted themselves.
2. Write a one-page rule on approved tools and data classes (M1).
3. Name an owner per AI system and a management-level steering group (M4).
4. Assess risk and impact for uses touching personal or confidential data (M3).
5. Check suppliers and where data is processed (M16).
6. Connect assistants to compliance systems only with the user's own permissions, human approval and an audit log.
7. Add AI-use guidance to awareness training, and look at ISO/IEC 42001 if you need a full management system.

To see how an assistant can work in a compliance system under these limits, read how the InfoPol MCP server works or contact us.