Transparency
Artificial Intelligence Policy
Last update: 2 August 2026
NimBox SRE includes an agent built on artificial intelligence. This page explains what that agent does, what information it handles, where it is processed and — above all — where its judgement ends and a person's begins.
In one line: the agent diagnoses and proposes; making changes to a machine requires either a human-approved procedure or an explicit confirmation at that moment.
1. Regulatory framework
This policy addresses the transparency obligations of Regulation (EU) 2024/1689 (the EU Artificial Intelligence Act), applicable from 2 August 2026, and complements Regulation (EU) 2016/679 (GDPR) where processing involves personal data.
2. You are interacting with an AI system
When the agent replies in an incident, in a Telegram conversation or through any other channel of the service, the reply comes from an artificial intelligence system, not from a person. It always signs with a name identifiable as an agent, and its replies are recorded as such in each incident's history.
Root cause reports, draft procedures and summaries it produces are AI-generated content, written from evidence collected from the affected system.
3. What it is used for
- Analysing alerts and incidents from monitored systems.
- Gathering diagnostic evidence by running read-only checks.
- Writing root cause reports from that evidence.
- Proposing draft resolution procedures, which start unapproved.
- Consulting indexed technical documentation before proposing a command.
- Replying when a team member mentions it in an incident.
- Classifying and summarising operational information.
4. What a person decides
The agent operates at different levels of autonomy depending on the operation:
- Without prior authorisation: reading metrics, checking the state of a service, reviewing logs and running checks that do not modify the machine.
- With an approved procedure or explicit confirmation: any change to a system — service restarts, configuration changes, packages, network, firewall, users or deletions.
Procedures the agent proposes itself are created as drafts and are not executable until a person approves them. Closing an incident requires verifying that the condition which opened it no longer holds.
5. Technical controls
- System access through temporary credentials that expire and are revoked when the work ends.
- Recorded sessions: every command executed is logged and can be replayed afterwards.
- Audit trail of relevant actions, with author, timestamp and outcome.
- Isolation per customer: one company's data, documentation and credentials are not reachable from another company's agent.
- Execution limits and rollback mechanisms in approved procedures.
6. What is sent to the model
To diagnose an incident, the information needed to understand it may be sent to the model: error messages, log fragments, metrics, service state, configuration data and details about the affected machine. Data minimisation applies: what is sent is what the specific operation needs, not the whole system.
That information may contain personal data when it appears in the customer's system logs. In that case processing is governed by the service agreement and the corresponding data processing agreement, not by this page.
7. Where it is processed
The models used by the service are reached through our own gateway, which routes to providers selected on these criteria:
- Processing within the European Economic Area.
- Open-weight models whenever they meet the technical need.
- Configurations that neither retain queries nor use them to train models.
The specific model may change over time for reasons of performance, availability or cost, while keeping these criteria.
8. Logging and traceability
The technical trail needed to audit what happened is retained: date, service, operation, outcome and what originated it. Reports generated by the agent are stored alongside their incident and the evidence they were written from, so they can be reviewed later.
9. Limits of the system
Language models are statistical and can be wrong. An AI-generated report may contain an incorrect interpretation, omit a relevant detail or propose an action unsuitable for that particular system.
That is why the service is designed on the premise that the agent's proposal does not replace the judgement of whoever operates the system: what executes changes is an approved procedure or a person who confirms. A root cause report is a starting point for analysis, not a settled conclusion.
10. What we do not do
- No emotion recognition or biometric categorisation systems are used.
- No synthetic images, audio or video that could pass as authentic are generated.
- No automated decisions producing legal effects on people are taken.
- Customer information is not used to train models.
11. Changes to this policy
Both the technology and its regulation are evolving. This page will be updated when providers, models, features or applicable obligations change. The version published here is the one in force.
12. Contact
For any question about the use of artificial intelligence in the service, including further detail on how a specific feature works, write to [email protected].
This policy should be read together with the Privacy Policy, the Cookie Policy and the Legal Notice.
