Security and Compliance

How beantragt.ai protects data, limits AI exposure and prepares for procurement, GDPR and operations.

Core principles

How the platform reduces risk.

EU hosting and data residency

Hosting within the EU. AI backends are selected per tenant and can be restricted to EU or sovereign providers.

AES-256-GCM field encryption

Sensitive fields are stored encrypted; encryption keys and data are kept logically separate.

GDPR and Data Processing Agreement (DPA)

Processor register, DPA draft and data-minimisation flows can be reviewed during a proof of concept.

AI governed per tenant

Providers, budgets and audit trails are configurable. Cloud AI can be excluded by operating model.

Accessibility as a quality goal

The interface follows EAA / EN 301 549 and WCAG 2.2. Formal conformance assessments are handled per project.

No automated decision-making

beantragt.ai receives applications and structures them. The platform prepares, it does not decide.

Operating model and data flow

One API contract separates interfaces, AI and specialist systems.

Website, embedded forms, specialist-system adapters and AI assistants can access beantragt.ai through the same contract. Permissions, encryption, audit and responsibilities stay controlled in the platform.

Diagram of beantragt.ai operating modes. — Built-in frontends, third-party clients and AI clients access beantragt.ai through one API contract. The application then either runs self-contained in beantragt.ai with case work in the back office, or passes through as an intake and validation layer to an external specialist system.

GDPR Art. 9 and data protection

How does beantragt.ai protect special-category data?

Sensitive fields such as name, IBAN, date of birth, address and GDPR Art. 9 data are stored with AES-256-GCM encryption. Keys and data are held separately. A database dump contains only ciphertext for these fields.

In the AI data flow, required field values are kept out of the model context. Identifying information belongs in protected fields and goes directly into the case. The model receives form structure, non-sensitive control data and free text when the assistant is used.

Required field values are not sent to the language model.

Name, date of birth, IBAN and GDPR Art. 9 fields are processed as protected fields and excluded from the AI context. Free text may be processed by the model.

AI usage transparent and auditable

AI usage and audit: token consumption and cost per context visible in the admin panel

Honest about the current state

What is ready and what follows per project.

Proven

Implemented and verified in the reference setup

EU Core Vocabularies / structured form standards as a starting point
SAML SSO module including eIDAS / EUDI Wallet profile verified in reference setup
Staff SSO via ADFS, Entra ID or generic SAML 2.0
Data-minimised CRM and export mappings
Retention periods and deletion routines per tenant
Processor register and DPA draft available for procurement and project start
AES-256-GCM field encryption for sensitive fields
API contract with stable UUIDs and named error codes
Delivery outbox with retry, backoff and audit log

Roadmap

Project-specific or in preparation

OOTS / SDGR full delivery: preflight and OAuth prepared, final delivery with first operator
Domain-specific data transforms via middleware or customer-funded extension
Specialist system connectors project-specific
eIDAS / EUDI Wallet production connection subject to authority, IdP metadata and operator approval
AI-assisted evidence review for attachments planned as an extension with human-in-the-loop

Identity and authentication

For citizens, staff and operators.

Citizens

Passwordless via email OTP: no password, no account required
eIDAS / EUDI Wallet: SAML 2.0 service provider, configurable minimum assurance level

Staff and operators

ADFS, Azure AD Entra, generic SAML 2.0
BSI TR-03130, signed messages, replay protection, open-redirect protection
SP private key via environment variable only, never stored in the repository

AI sovereignty

How can beantragt.ai run without cloud AI?

Cloud (EU region)

EU providers subject to operator approval, switchable off by policy

Sovereign cloud

IONOS, STACKIT or equivalent sovereign providers

On-premises

Operator-controlled endpoint in the appropriate operating model

Cost control and audit

Cost caps per tenant, audit records without raw prompts and clear policies for permitted AI backends.

Data processing

Data minimisation as a product principle.

The platform-level processor register covers engaged service providers under GDPR Art. 28 DPA. Status responses are served with Cache-Control: private, no-store. Only explicitly mapped CRM fields leave the platform.

Retention periods are configured per tenant. Deletion and retention processes are part of the operating model.

Processor register extract

Hosting (EU)GDPR Art. 28 DPA
AI provider (EU DPA)GDPR Art. 28 DPA
Mail transport (Scaleway SAS, Paris)GDPR Art. 28 DPA
OOTS delivery (FITKO)GDPR Art. 28 DPA
Specialist systems (authority-specific)GDPR Art. 28 DPA

Data Processing Agreement (DPA)

DPA draft on request. A direct download link will be added here once the final document is available.

Request DPA

Accessibility

Aligned with EAA / EN 301 549 and WCAG 2.2.

beantragt.ai follows the requirements of the European Accessibility Act (EAA), EN 301 549 and WCAG 2.2 criteria. The goal is a platform that works well with keyboard, screen reader and assistive technologies.

Forms are built so that screen readers, keyboard navigation and assistive technologies are supported. Contrast ratios, focus management and semantic markup are part of the quality process.

Questions about security or data protection?

We answer technical questions and clarify which materials would make sense for privacy, operations and AI usage in a possible PoC.

Request a demo