Compliance

This page is for whoever has to answer “are our AI assistants compliant?” It lists what almyty already does for you (telling people they are talking to an AI, asking a person before risky actions, keeping records, deleting old data) and what stays your job. For example: every web chat tells visitors it is an AI by default, and you can download a technical description of any agent to file with your own assessment.

This is not legal advice. Compliance is judged per use, not per tool. Use this as a starting point for your own assessment.

Who is responsible for what

almyty is the tool you build and run assistants with; you bring the AI models. Under the EU AI Act that split matters. The duties of a model provider (the company that makes the model you connect) stay with that company. The duties of a deployer (whoever puts an assistant in front of people) sit with you. almyty’s job is to make your part easy.

EU AI Act

The AI Act sorts AI systems by risk. Most assistants built on almyty (support assistants, internal helpers, data jobs) are limited or minimal risk, where the main duty is to be open that people are talking to an AI. If you use an assistant in an area the Act lists as high-risk (screening job applicants, credit scoring, access to essential services and similar), the full set of deployer duties applies.

What almyty gives you, requirement by requirement

What the Act asks	What almyty has	Where
Art. 50, transparency: tell people they are talking to an AI	An AI disclosure switch on every channel, on by default. The first reply of every conversation carries a line such as “You are chatting with an AI assistant.” (or the line in the agent’s branding). Turning it off needs the Enterprise plan’s white-label feature	Channels, Hosted chat
Art. 14, human oversight: people can step in	An agent can pause and ask a person to approve before it acts. Approval policies can require several reviewers, in order, for sensitive actions	Approvals
Art. 12, record-keeping	Every run keeps its steps, tool calls, cost and outcome. The audit log records sensitive actions. Every agent, tool and gateway keeps a history of changes	Analytics, the agent’s runs
Annex IV, technical documentation	A one-click download per agent describing it: what it does, its models and settings, its tools, human oversight, data handling, logging and change history	The agent’s page, Tech doc
Art. 9, risk management	Rules (constraints) on each agent, filters that remove personal data or block risky input, and on Business and Enterprise plans the compliance pack, which makes those filters mandatory for the whole organization and reports on them	The agent’s constraints, Self-hosting
Art. 15, robustness	Run limits on steps, spend and time that no agent can raise past what the organization or the operator set; every messaging channel checks that incoming messages really come from the platform, and refuses them when it cannot	Run limits, Channels
Art. 26, deployer duties (use as instructed, monitor, keep logs)	Usage monitoring, spending limits, a trace of every run, and on Business and Enterprise plans audit export	Analytics

What remains yours

Deciding the risk level of each use. almyty cannot know whether your assistant screens job applicants.
The conformity assessment and registration for high-risk uses.
Instructions for your own users, and reporting incidents to authorities where required.
Choosing models. The model makers carry the duties for general-purpose models; read their AI Act documents as input for your own file.

Conversations with an assistant usually contain personal data, so GDPR applies to almost every real use.

Less personal data: the personal-data filter hides personal details in what is kept (tool call records, the steps of each run, the audit log) and in answers to outside systems. Tools still get the real values they need to do their work.
Encryption: keys and passwords you store in almyty are encrypted. Self-hosters hold the encryption key, and the Enterprise plan adds keys you manage in your own cloud account.
Deleting: memories and conversations can be deleted one by one. Deleting an agent deletes its runs and its channels: its web chat, website bubble and messaging channels stop answering, and their addresses are free to use again. Conversations people had with it stay until the retention period removes them.
Members of the public: what a web chat or website bubble visitor leaves behind, where it goes and who can read it is spelled out in Hosted chat app, What almyty stores about a visitor. Visitors can delete and download their own data from the chat unless the agent’s visitor rules turn that off. Anyone else (someone on Slack, WhatsApp, SMS or email, or a caller over A2A) asks you, and the agent’s owner (or an owner or admin) answers from the agent’s Channels tab under Visitor data: look the person up, send them a copy, or delete it, with each answer in the audit log (Visitor data requests). Visitor conversations stay out of the agent’s shared memory unless the agent opts in. A channel’s own retention can only be shorter than the organization’s, and chat pages carry none of almyty’s analytics.
How long data is kept: admins set a period (1 to 3650 days) for agent runs, conversations, request logs, usage metrics and the audit log in the Data retention card under Settings → Organization → Details. An hourly clean-up deletes records older than that for good. It never touches runs that are still going or waiting for approval, and it records what it removed in the audit log. Empty fields keep records forever.
Your side: a record-of-processing entry for each assistant, a lawful basis for the data it handles, and data-processing agreements with your model vendors (you send them conversations under your own keys). Self-hosting in your own EU infrastructure keeps where data lives entirely in your hands.

Other rules worth knowing

Rule	Applies when	What helps
Cyber Resilience Act (EU, phasing in to 2027)	You sell software in the EU, including a product built on almyty	Dependency checks and secret scanning in almyty’s own build pipeline, the security-scanner filter; publish your own vulnerability-disclosure policy and software bill of materials
NIS2	Your customers are in essential or important sectors and pass supply-chain security demands on to you	Single sign-on and automatic user provisioning, custom roles, audit export to your security tools (Business and Enterprise plans) are the usual answers
DORA	Financial-sector customers in the EU	Audit trails, data export if you leave, incident evidence from run logs
SOC 2 / ISO 27001	Enterprise sales (not law)	The technical basics (single sign-on, roles, audit logging, encryption, change history) are in the product; certification itself is an organizational process
ePrivacy	You put the chat bubble on a public website	The bubble sets no tracking cookies by default; consent is only needed for what you add around it

Checklist for a new assistant

Decide the risk level of the use (minimal, limited or high).
Keep AI disclosure on for every channel people use (it is on by default).
Make the agent ask for approval before consequential actions, and add approval policies where you need more than one reviewer.
Download the agent’s Tech doc and file it with your assessment.
Turn on the personal-data filter where conversations may contain personal data.
Set how long data is kept, and review the audit log and runs as part of your monitoring.
Set run limits on any assistant open to the public, so one conversation cannot use up your budget. Every run records the limits that applied to it.

For developers

Human oversight is the built-in request_approval tool: the run pauses until a reviewer decides.
The personal-data and security filters are the pii-filter and security-scanner plugins; see Self-hosting for plugins.
Credentials and provider secrets are encrypted at rest with AES-256-GCM. Self-hosters set the key with ENCRYPTION_KEY; the Enterprise byo_kms entitlement adds customer-managed AWS KMS keys (see Enterprise).
The retention sweep records a retention_sweep audit entry with counts per data class.