EU AI Act Compliance

Risk Classification

Reva is an AI system under Article 3(1) of the EU AI Act — it uses LLM inference to interpret natural language queries and generate responses. The central question is which risk category applies.

Why Reva Is Not High-Risk

The only relevant Annex III category is 4(b) — Employment, workers management, which covers AI systems intended to “monitor and evaluate the performance and behaviour of persons” in work relationships. Here is why Reva does not fall under this category:

Intended Purpose: Release Management, Not Worker Management

Reva’s intended purpose is release management data retrieval and display. It queries Digital.ai Release and Jira APIs, presents structured results, and helps teams manage software releases. It does not make employment decisions, evaluate individual performance, or allocate tasks based on personal traits.

Privacy by Design Prohibits Individual Monitoring

Reva’s system prompt rules explicitly prohibit individual performance monitoring. Activity logs are anonymized — summaries attribute actions to “a team member” rather than named individuals. These guardrails are enforced at the system level, not as optional configuration.

Article 6(3) Exception Applies

Even under a conservative reading, Reva qualifies for the Article 6(3) exception because it performs:

• Narrow procedural tasks — transforming natural language into structured API queries
• Preparatory tasks — searching, indexing, and retrieving data for human review

Critically, Reva does not perform profiling of natural persons — the condition that would override the Article 6(3) exception. It retrieves factual data (task assignments, release status) without evaluating personal aspects or predicting behaviour.

Other Annex III Categories

Transparency Obligations

Article 50 of the AI Act applies to all AI systems that interact with natural persons.

Article 50(1) — AI Disclosure

Users must be informed they are interacting with an AI system. Reva operates as a named bot in Microsoft Teams — its AI nature is contextually apparent. Nevertheless, the bot’s welcome message and help text clearly identify Reva as an AI-powered assistant.

Article 50(2) — AI-Generated Content

Providers of systems generating synthetic content must mark it as AI-generated. Reva generates text responses and Adaptive Cards based on data from Release and Jira. These responses are informational — not deepfakes or synthetic media. Responses are attributed to “Reva” as a bot, providing clear provenance.

General-Purpose AI Models

The GPAI regulation (Chapter V, Articles 51–53) targets providers of general-purpose AI models — the organizations that develop and distribute the models themselves.

The open-source model exemption (Article 53(2)) benefits the upstream model providers, not downstream integrators. There is no blanket open-source exemption for AI systems built on open-source models — Reva must comply with its own AI system obligations regardless.

Provider & Deployer Obligations

X-idra Systems GmbH = Provider (Article 3(3))

X-idra develops Reva and places it on the market under its own brand. As the provider, X-idra is responsible for:

Since Reva is not high-risk, the heavy obligations of Article 16 (conformity assessment, CE marking, EU database registration, post-market monitoring) do not apply.

Customer = Deployer (Article 3(4))

Organizations deploying Reva on their infrastructure are deployers. Their obligations are limited to:

• Ensure AI literacy among users (Art. 4)
• Inform workers and representatives about the AI system before deployment
• Use Reva according to the provided instructions and usage restrictions
• Consult the works council if applicable (BetrVG §87 Abs. 1 Nr. 6)

GDPR & BetrVG Alignment

Reva’s privacy-by-design architecture supports compliance with both the AI Act and existing data protection regulations.

GDPR (EU 2016/679)

• Data minimization — only data necessary for release management is processed
• Local processing — all AI inference runs on the customer’s infrastructure; no data is transferred to external services
• No profiling — no personal data is used to evaluate individual characteristics, behaviour, or performance
• Right to erasure — conversation data can be deleted directly from the database
• Data portability — all data stored in a standard SQL database, fully exportable

BetrVG (German Works Constitution Act)

• No individual performance monitoring — prohibited by design and enforced via system prompt rules
• Anonymized activity logs — summaries never attribute actions to named individuals
• Autonomous monitoring reports task status only — overdue task alerts reference tasks and releases, not individual assignees
• Works council consultation — deployers are advised to consult their Betriebsrat before deployment per §87 Abs. 1 Nr. 6

Compliance Timeline

Technical Guardrails

To maintain Reva’s non-high-risk classification and prevent feature drift into regulated territory, the following guardrails are enforced:

Enforced at the System Level

• Individual performance tracking prohibited — system prompt rules prevent the LLM from generating individual performance assessments, comparisons, or reports
• Activity log anonymization — all summaries use “a team member” instead of names; no feature can bypass this
• Monitoring alerts reference tasks, not people — autonomous monitoring reports on overdue tasks and failing gates without attributing delays to individuals
• Read-only MCP policy — the LLM cannot create, modify, or delete data in Release or Jira
• Templated notifications only — the LLM cannot compose arbitrary message content for proactive notifications

Feature Review Process

Before adding new capabilities, each feature is assessed for potential impact on risk classification:

• Any feature analysing individual work patterns → potential high-risk trigger
• Any feature recommending task assignments based on personal characteristics → high-risk
• Any feature generating individual performance summaries → prohibited

Deployer Agreements

Customer agreements include clauses that:

• Prohibit use of Reva for individual performance evaluation
• Require deployers to inform workers about Reva’s presence
• Require compliance with local works council requirements