EU AI Act compliance assessment.

A tier-by-tier analysis of Hydrate under Regulation (EU) 2024/1689. Written for procurement teams, legal reviewers, and enterprise customers who need a specific, honest account of where Hydrate sits in the regulatory framework, not a marketing summary.

Last reviewed: 2026-04-24 · Sedasoft Ltd, United Kingdom

1. Legislative background and application timeline

Regulation (EU) 2024/1689 (the EU AI Act) was published in the Official Journal on 12 July 2024 and entered into force on 1 August 2024. It establishes a risk-based framework for AI systems placed on the EU market or put into service where the output affects persons in the EU. The Act applies regardless of where the provider is established.

The Act applies in staggered phases. As of April 2026, the following provisions are in force and fully enforceable:

• Chapter II - Prohibited Practices (Article 5): In force since 2 February 2025. Bans eight categories of AI practice including subliminal manipulation, exploitation of vulnerabilities, real-time biometric surveillance in public spaces (with narrow exceptions), social scoring by public authorities, biometric categorisation inferring sensitive attributes, and emotion recognition in workplace and educational settings.
• Chapter V - General Purpose AI Models (Articles 51-56): In force since 2 August 2025. Imposes documentation, transparency, and copyright-summary obligations on providers of GPAI models (OpenAI, Anthropic, Mistral, Google). Downstream deployers using those models via API also have limited obligations from this date.
• Chapter VI and VII - Governance and Enforcement: In force since 2 August 2025. The EU AI Office and national competent authorities are operational; the penalty regime is live.

The following provisions are not yet in force but are scheduled to apply from 2 August 2026 (subject to any amendment from the Digital Omnibus package):

• Chapter III - High-Risk AI Systems (Articles 6-51): Full conformity assessment, technical documentation, human oversight, registration, and monitoring obligations for systems falling within Annex III categories. These obligations are not yet legally required but should be assessed now to understand your compliance runway.
• Article 50 - Transparency Obligations: Disclosure requirements for AI systems interacting directly with natural persons (chatbots, synthetic content, emotion recognition) and for AI-generated content.

The Act does not apply retrospectively to systems deployed before the relevant application date, but those systems must comply when modified in a way that constitutes a "substantial modification."

2. Product classification under Article 3(1)

The first question is whether Hydrate is an "AI system" as defined in Article 3(1):

"a machine-based system that is designed to operate with varying levels of autonomy and that may exhibit adaptiveness after deployment, and that, 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."

The operative word is infers. Recital 12 confirms that purely rule-based systems where operations are "defined solely by natural persons" are excluded. The EU AI Office's published guidelines (6 February 2025) distinguish classical statistical and rule-based approaches from machine-learning inference.

Hydrate contains components across this boundary. The analysis differs by component:

• TF-IDF and BM25 summarisation and keyword scoring: These are classical statistical methods - term frequency weighting and inverse document frequency calculations applied to deterministic rules. They do not "infer." This component is excluded from the AI system definition by Recital 12.
• SQLite FTS5 retrieval: Full-text search over an inverted index. Deterministic. Excluded.
• Embedding-based semantic retrieval (cosine similarity over pgvector or SQLite stored vectors): The similarity calculation is deterministic arithmetic. However, the embeddings themselves are produced by a trained neural network model (e.g., OpenAI text-embedding-3-small). The EU AI Office has indicated that operations that use learned embeddings are AI-mediated even if the distance calculation is trivial. This component brings the affected pipeline into scope.
• ONNX classifier models (query intent, entity routing, content classification): These are trained machine-learning models performing inference. Clearly within Article 3(1).
• LLM generation (OpenAI GPT-4o-mini, Anthropic Claude, local Qwen via LM Studio): These are third-party AI systems whose providers (OpenAI, Anthropic, etc.) bear GPAI obligations. Hydrate integrates them as a downstream deployer.

Assessment: Hydrate as a whole product is best characterised as an AI-assisted software tool. The Free tier in pure keyword-only mode (no API key configured, no embedding provider) is arguably outside the Article 3(1) definition entirely. With an embedding provider configured, it uses third-party AI systems and the tool overall is within scope. The Enterprise tier is unambiguously within scope: it uses LLM generation and embedding-based retrieval as core functions, and the customer's configured LLM provider performs inference on every fact-extraction call.

For the purposes of this assessment, we treat Hydrate as an AI system and apply the full regulatory framework conservatively.

3. Prohibited practices (Article 5)

Article 5 is in force. The eight prohibited categories are assessed below. All eight are assessed as not applicable to any Hydrate tier.

Conclusion: No prohibited AI practice is present in any Hydrate tier. This assessment covers both current design and stated roadmap. Any future feature that touches the prohibited categories will require a fresh legal review before deployment to EU users.

4. Per-tier risk classification

4.1 Free tier

4.2 Pro tier

4.3 Team tier

4.4 Enterprise tier

5. Hydrate Enterprise — detailed assessment

The Hydrate Enterprise server is a self-hosted Docker deployment that runs on the customer's own infrastructure. It is not cloud-hosted by Sedasoft; the customer controls the deployment environment and all data within it.

5.1 System architecture relevant to the Act

The Enterprise server consists of:

• Session capture and summarisation: Receives Claude Code session transcripts via the hydrate CLI's Stop hook. Summaries are extracted and stored locally. No session content leaves the customer's infrastructure.
• Fact extraction: Uses the customer's configured LLM (OpenAI, Anthropic, or a locally-hosted model such as Qwen via LM Studio or Ollama) to extract atomic facts from session transcripts. The LLM call uses the customer's own API key; Sedasoft is not party to that inference.
• User memory system: Stores extracted facts, learned preferences, and conversation history in PostgreSQL. Provides GDPR data export (Article 20) and right-to-erasure deletion (Article 17) via API endpoints.
• Context injection: On the next session start, relevant facts and session summaries are retrieved and injected into the developer's Claude Code context via the UserPromptSubmit hook. The developer receives their own prior context; there is no user-facing AI persona or character simulation.
• Authentication and access control: JWT plus API key authentication with role-based access control (read / write / admin). Per-connector scoping for multi-team deployments.

The Enterprise server does not include an expert persona system, emotion modelling, knowledge graph enrichment, hierarchical summarisation (RAPTOR), or ONNX classifier models. It is a team memory and context store, not a content generation or persona simulation system.

5.2 Annex III classification for the Enterprise server

The eight Annex III categories are assessed below. The assessment covers Sedasoft's own design and the intended use case. Where a customer could deploy the system in a way that triggers a category, that is noted as a customer responsibility.

5.3 Article 6(3) derogation

Even where a system falls within an Annex III category, Article 6(3) provides that the system is not treated as high-risk if it:

• performs a narrow procedural task, or
• improves the result of a previously completed human activity, or
• detects patterns that do not influence a decision without appropriate human review, or
• prepares for an assessment relevant to Annex III use cases without replacing it.

The Enterprise server's core function — retrieving a developer's own prior session context and surfacing it at the start of the next session — is a strong candidate for the "narrow procedural task" derogation. It improves the result of a previously completed human activity (the prior session) without replacing any human decision. Customers deploying in regulated contexts should document their Article 6(3) analysis explicitly rather than relying on this assessment.

6. Transparency obligations (Article 50)

Article 50 becomes applicable on 2 August 2026. Sedasoft is assessing compliance now in order to ensure all tiers are compliant on that date.

6.1 Article 50(1) - Disclosure of AI interaction

Article 50(1) requires providers of AI systems "intended to interact directly with natural persons" to ensure those persons are informed they are interacting with an AI system.

Free / Pro / Team tiers: The UserPromptSubmit hook injects retrieved context into a developer's Claude Code session. It does not interact directly with natural persons in the sense of Article 50(1); it interacts with the Claude Code process, which the developer operates fully knowingly. No disclosure obligation applies to these tiers under Article 50(1).

Enterprise tier: The Enterprise server is an API backend, not a user-facing system. In the standard deployment pattern, it injects prior session context into a developer's own Claude Code session via the UserPromptSubmit hook. The developer is fully aware they are operating a developer tool; no disclosure obligation arises for this primary use case.

Where a customer builds a user-facing application on top of the Enterprise server API that presents AI-generated responses to end users, Article 50(1) applies to that customer application. Sedasoft's compliance approach for Enterprise:

• The API documentation and Enterprise terms of service require customers to implement AI disclosure at the application layer for any user-facing deployment.
• The Enterprise server API response headers include a machine-readable X-Hydrate-AI-System: hydrate-enterprise/1.0; purpose=rag-retrieval header in all responses, providing a signal for customer applications to use in implementing disclosure.
• Sedasoft provides a reference disclosure implementation in the integration documentation.
• Customers who fail to implement disclosure where required are in breach of the Enterprise terms of service and in sole breach of Article 50(1); Sedasoft has fulfilled its provider obligation by contractually requiring disclosure and documenting the technical hook.

6.2 Article 50(2) - Synthetic and AI-generated content

Article 50(2) requires that AI-generated content that could be mistaken for authentic human content be marked with a machine-readable watermark or equivalent label.

The Enterprise server API returns content assembled from retrieved facts and session summaries; the LLM call that generates any text response is made by the customer's own application using the customer's own API key. The question of whether generated content requires an Article 50(2) mark depends on the downstream application context. Sedasoft's API response format includes metadata indicating the content was AI-assisted; customers are responsible for propagating this information in their user-facing interfaces. This is a deployer obligation under Article 25 and Article 50.

6.3 Article 50(3) - Emotion recognition

Article 50(3) requires disclosure when an AI system performs emotion recognition on a natural person. The Enterprise server does not perform any form of emotion recognition. It stores and retrieves developer session context; it does not infer or classify the emotional state of any natural person. Article 50(3) is not triggered by any Hydrate tier. If a customer were to build a modified application on top of the Enterprise server API that inferred human emotional states from user inputs, that would require disclosure and may constitute a prohibited practice under Article 5(1)(f) if used in a workplace or educational context.

7. General Purpose AI model obligations (Chapter V)

Chapter V is in force since 2 August 2025. It imposes obligations primarily on providers of GPAI models: companies that train and make available large foundation models (OpenAI, Anthropic, Mistral, Google, Meta, etc.). Sedasoft is not a GPAI model provider. Sedasoft builds products and services that use GPAI models via API.

As a downstream deployer of GPAI models, Sedasoft's obligations under Chapter V are limited. The key obligations that apply:

• Do not use GPAI models for prohibited purposes (Article 5). Assessed above; confirmed no violation.
• Implement Article 50 transparency when deploying GPAI output to end users. Covered in Section 6 above.
• If building a high-risk AI system on top of a GPAI model, bear provider obligations for that high-risk system (Article 25). The current Hydrate Enterprise deployment is not in a high-risk category. If a customer deployment triggers Annex III, the customer becomes the responsible party under Article 25.
• Verify upstream GPAI provider compliance. OpenAI and Anthropic have published the required technical documentation, usage policy summaries, and copyright compliance statements required under Articles 53 and 55. Sedasoft maintains records of this verification for its compliance file.

Sedasoft does not operate or fine-tune any foundation model. All language model inference is performed either via third-party API (OpenAI, Anthropic) or by a locally deployed open-weights model run on customer infrastructure (Qwen 2.5, Llama 3, Mistral, or equivalent). For locally deployed models, the customer is the operator of that inference infrastructure and bears the applicable obligations for their chosen open-weights model.

8. Territorial scope and EU representative

Article 2(1)(c) extends the Act's reach to providers established outside the EU where the output of their AI system is used in the EU. Sedasoft is incorporated in the United Kingdom, a third country following Brexit. Hydrate has users in EU member states. Accordingly, the Act applies to Sedasoft's operations.

EU representative obligation: Non-EU providers of AI systems used in the EU are required to appoint an EU representative (analogous to the GDPR Article 27 representative obligation). This representative acts as the point of contact for national competent authorities in the EU. Sedasoft is currently assessing whether its EU user base triggers this obligation and is taking steps to appoint an EU representative in a member state with competent AI Act authority.

UK regulation of AI is currently governed by the UK Government's pro-innovation principles-based framework (AI Regulation White Paper, 2023) rather than a binding EU-equivalent regulation. UK-specific compliance requirements are not within the scope of this document but are assessed separately.

9. Interface with GDPR

The EU AI Act does not replace GDPR. Where AI systems process personal data, both frameworks apply. Key intersections for Hydrate:

9.1 Article 22 GDPR - Automated decision-making

GDPR Article 22 applies to "solely automated" decisions that produce "legal or similarly significant effects" on natural persons. The Hydrate memory and retrieval system does not produce such decisions. The output of the retrieval pipeline is a set of facts injected into context; the LLM then generates a response. The LLM's response is not "solely automated" in the Article 22 sense for most developer tool use cases (a developer interacts with the AI tool and exercises their own judgment over the output). Article 22 does not appear to be triggered by the standard use cases.

For Enterprise deployments where the application built on top of the Enterprise server API influences decisions about natural persons (e.g., a lending decision-support tool, an HR screening tool), the customer must assess Article 22 obligations including the right to human review.

9.2 Data controller and processor roles

• Free and Pro tiers: The user is the sole data controller. All data remains on the user's machine. Sedasoft is not a data processor because Sedasoft does not process any personal data on the user's behalf. If the user configures a third-party LLM/embedding API key, the user is a controller in that relationship and the provider (OpenAI, Anthropic, etc.) is the processor; Sedasoft is not a party to that relationship.
• Team tier: The team administrator (or the employing entity) is the data controller for team member facts stored in the shared canon. Sedasoft is not a data processor.
• Enterprise tier: The customer is the data controller for all personal data processed by the Enterprise server. The Enterprise server runs on the customer's own infrastructure; Sedasoft does not hold customer data. For the standard on-premise deployment, the customer is both controller and processor. A Data Processing Agreement (DPA) is available as Schedule 2 of the Enterprise agreement for any Sedasoft-involved processing relationship.

9.3 Special category data (Article 9 GDPR)

Hydrate's fact extraction pipeline applies an eligibility classifier that filters out highly personal, sensitive, or special-category content before storage. Facts containing health data, political opinions, religious beliefs, or other Article 9 categories are rejected at the extraction stage. This filter is a default safeguard, not a guarantee: if a user explicitly inputs special-category data as a fact via the CLI or API, the filter may not catch all instances. Customers with specific special-category data requirements should configure additional filtering or prohibit relevant inputs in their usage policies.

9.4 User memory - data subject rights

The Enterprise server user memory system provides built-in support for GDPR data subject rights:

• Article 15 (access): GET /api/v1/users/{id}/profile, GET /api/v1/users/{id}/facts, and GET /api/v1/users/{id}/preferences
• Article 20 (data portability): GET /api/v1/users/{id}/export returns a complete JSON export of all stored user data.
• Article 17 (right to erasure): DELETE /api/v1/users/{id} performs a right-to-be-forgotten deletion across all tables (facts, preferences, sessions, identity slots, audit records, maintenance signals).

10. What Sedasoft does and commits to

This section summarises the compliance measures Sedasoft has implemented or is implementing, by obligation category.

11. Obligations that fall on Enterprise customers

Enterprise customers who deploy the Hydrate Enterprise server bear the following EU AI Act obligations in their own right. These are not delegated by Sedasoft; they arise from the customer's role as deployer (and potentially provider, if they substantially modify the system or release it under their own name) under the Act.

• Use case assessment before deployment. Before deploying the Enterprise server in a production context, customers must assess whether the deployment falls within an Annex III category. The Article 6(3) derogation should be documented if relied upon. Sedasoft can provide technical assistance for this assessment on request.
• Article 26 obligations (from August 2026) if Annex III is triggered. If the customer's deployment is classified as high-risk, the customer must: assign a qualified human overseer; monitor the system during operation for risks and anomalous outputs; report serious incidents to Sedasoft and to the relevant national competent authority; maintain logs of system use for at least six months; and conduct a Fundamental Rights Impact Assessment (FRIA) if deploying in a public-sector context.
• Article 50(1) - End-user AI disclosure. Customers who surface AI-generated content to end users through applications built on the Enterprise server API must ensure end users are informed at the start of every interaction that they are interacting with an AI system, not a natural person.
• GDPR controller obligations. Customers are data controllers for personal data processed by the Enterprise server within their deployment. This includes having a lawful basis for processing user memory data, providing privacy notices to end users, and honouring data subject rights using the API endpoints Sedasoft provides.
• Prohibited purposes. Customers must not deploy the Enterprise server for any purpose listed in Article 5. This is a contractual condition of the Enterprise licence and a legal obligation under the Act.
• Upstream model compliance. If customers configure the Enterprise server to use a locally deployed open-weights model (Qwen, Llama, Mistral, etc.), the customer is the operator of that inference infrastructure. Customers should assess whether the open-weights model provider has published the documentation required under Chapter V and whether any systemic-risk obligations apply to their chosen model.

12. Upcoming obligations - August 2026

The high-risk AI system chapter (Articles 8-49) and Article 50 transparency obligations are scheduled to apply from 2 August 2026. For Sedasoft, the practical steps required before that date are:

• Complete EU representative appointment.
• Confirm Article 50(1) compliance for all Enterprise deployments by verifying customer implementations include AI disclosure and by updating API documentation with compliant reference patterns.
• Finalise Article 6(3) derogation documentation for the standard developer-tool use cases, to confirm no Annex III conformity assessment is required.
• Publish Article 13 technical documentation in the required format (description, general logic, intended purpose, known limitations, human oversight instructions) if the system does not qualify for the full Article 13 exemption.
• Monitor the Digital Omnibus package for any revision to the August 2026 application date. If the deadline is extended, the compliance runway is extended proportionally but the substantive obligations remain.

We will publish an updated version of this assessment when any of the above deadlines pass or when material guidance is issued by the EU AI Office.

13. Questions and compliance contact

For EU AI Act compliance questions relating to an Enterprise deployment, a procurement assessment, or this document:

• [email protected] - Legal and compliance enquiries
• [email protected] - Enterprise sales and technical pre-sales
• [email protected] - General contact

This assessment is Sedasoft's good-faith interpretation of Regulation (EU) 2024/1689 as it applies to the products and services described. It does not constitute legal advice. Enterprise customers with specific regulatory requirements should obtain independent legal advice from qualified counsel in their jurisdiction.

Version 1.0 · Reviewed 2026-04-24 · This document will be updated when material guidance is issued or when obligations change. Next scheduled review: 2026-07-01 (ahead of August 2026 application date for Annex III and Article 50).