Which EU AI Act deployer duties a self-hosted Dify can support
If you deploy a high-risk AI system in the EU, a self-hosted Dify can support some of the duties in Article 26 and Article 12 of the AI Act through configuration and evidence, but it does not meet those duties by itself. The platform gives you settings for log retention, human review steps and tracing, and you still need the organizational measures, competent people and documented procedures that the Act assigns to the deployer. Whether any of this applies to you depends first on the use case, not on the tool: the same Dify app can be a minimal-risk internal assistant or a high-risk system depending on what decisions it informs and in which Annex III area it falls.
Timing matters for planning. The Digital Omnibus on AI, Regulation (EU) 2026/1744, amended the Act in 2026 and moved the high-risk rules in Chapter III Sections 1 to 3 to 2 December 2027 for Annex III systems and to 2 August 2028 for Annex I product systems. Confirm the exact dates that apply to your system against the consolidated EU AI Act text, and confirm with your legal counsel whether your role is deployer, provider or both, since a deployer that substantially modifies a system or puts its own name on it can take on provider duties. DeployOpen plans and implements the platform, prepares configuration and evidence for your assessment, and documents what the system does. It does not issue certifications, attestations or legal advice, and an independent assessment is still your responsibility to arrange.
Mapping Article 26, Article 12 and Dify settings
This table pairs each EU AI Act deployer duty in scope with the Dify capability that supports it and the configuration a self-hosted deployment needs. Read the configuration column as the work to do, because several rows depend on settings you choose rather than on defaults. The main takeaway is that Dify's default 30-day workflow log cleanup does not meet the six-month retention deployers must keep under their own control.
| Requirement | Platform capability | Configuration |
|---|---|---|
| Article 26(6): keep logs under deployer control for at least six months | Workflow execution logs are stored in your own metadata database and can be exported before cleanup runs | Set WORKFLOW_LOG_RETENTION_DAYS to more than 180 or set WORKFLOW_LOG_CLEANUP_ENABLED to false, and document the export step in your log procedure |
| Article 12(1): automatic recording of events over the system lifetime | Workflow runs and node execution records are written automatically when the app runs | Confirm which events your system must record, test that each high-risk workflow produces them, and agree the retention period with counsel |
| Article 26(1) and (2): use per instructions and assign oversight to competent people | Human Input node pauses a workflow for a named reviewer decision, and app permissions limit who can run or edit apps | Place Human Input nodes where a person must approve outputs, restrict edit rights, and record reviewer training and authority in your own records |
| Article 26(5): monitor operation, suspend use and report incidents | Tracing and LLMOps monitoring show run behavior, but Dify does not decide suspension or reporting | Connect tracing to your monitoring stack, define alert thresholds, and document who can suspend an app and how the provider and authority are notified |
| Article 26(5): inform the provider of risks and serious incidents | No built-in reporting workflow is described in the platform documentation | Keep a contact register for each provider, and confirm the reporting route in your own incident process |
Why the 30-day cleanup default breaks a six-month log duty
Article 26(6) requires a deployer of a high-risk AI system to keep the logs under its control for at least six months, unless other Union or national law sets a different period. Dify's workflow log cleanup works against that duty by default. When WORKFLOW_LOG_CLEANUP_ENABLED is turned on, Dify deletes workflow execution logs older than WORKFLOW_LOG_RETENTION_DAYS, which defaults to 30 days according to the Dify environment variable reference. A deployer who leaves the default in place, or sets a value below six months, will lose records the Act expects to exist. Set the retention value deliberately, document it, and confirm the cleanup job behaves as the settings describe in your own test environment before relying on it.
Execution logs sit in the metadata database, which is PostgreSQL by default, while files and other artifacts go to whichever file storage backend you configure, such as S3-compatible storage. Both must be covered by the retention decision, and both must be included in backups. Confirm who owns each store, who can run restores, how long backups themselves are kept, and whether a backup restored after the retention window could reintroduce logs you meant to delete. Backups are often kept on a separate schedule from the application, so the retention design should name them explicitly. Article 12 is a separate point: it requires the system to technically allow automatic recording of events over its lifetime. That is a design property of the system that you confirm and test, not a retention period you choose.
The length of retention is a legal decision, not a platform setting. Ask your legal or compliance team which Union or national rules apply to your use case, whether any other law sets a longer period, and how log retention interacts with data protection obligations for personal data in prompts and outputs. Record the answer as a written decision with an owner and a review date, and link it to the configuration values in your deployment. The same decision will shape how you handle erasure requests, so it should be settled before the first high-risk workload goes live rather than after the first cleanup run.
How human oversight and monitoring are recorded in Dify
The Human Input node pauses a running workflow until a person responds, so a named reviewer can check output before the workflow continues. Article 26(2) requires that the person assigned to human oversight has the necessary competence, training, authority and support, so the node is one part of the control and not the whole of it.
- Pause and resume: The workflow waits at the node until a reviewer submits input, which keeps the model from completing the step alone. Confirm in your Dify version how pauses behave and what happens to a run that nobody answers.
- Decision record: Confirm which details the node stores for each review, such as the reviewer identity, timestamp, submitted input and the output shown, and whether those details sit in workflow logs that the cleanup job can delete.
- Named reviewer: Dify does not assign people to the step on its own. Workspace roles, or SSO groups on Enterprise, must limit who can respond to authorized reviewers.
- Not recorded: The reasoning behind an accepted or overridden output, and any escalation that happens outside Dify, need a separate written record.
- Overseer needs: Training on the system's limits, written authority to reject or stop output, and a support route for cases where the output looks wrong.
In a test workflow, confirm that a paused run shows the reviewer's identity and decision in the logs you intend to keep.
Article 26(5) requires the deployer to monitor operation of a high-risk system. Dify's LLMOps monitoring and tracing supply the operational data for that work, but monitoring only has value when someone reviews the data on a defined schedule and acts on what they find.
- Operational traces: Dify's monitoring captures run data for apps and workflows. Confirm which fields your version records, such as inputs, outputs, token use and latency, before you write them into a monitoring procedure.
- Retention clock: When WORKFLOW_LOG_CLEANUP_ENABLED is turned on, Dify deletes workflow execution logs older than WORKFLOW_LOG_RETENTION_DAYS, which defaults to 30 days. Article 26(6) requires logs under the deployer's control for at least six months, so set the retention value higher or export logs to storage you control. See the Dify environment variable reference for the settings.
- External tracing: If you forward traces to an observability tool you run, that tool holds its own copies with its own retention. Confirm the integration and its settings separately.
- Not recorded: Whether an output harmed a person, and whether an event counts as a risk or a serious incident, are judgments that need a defined process outside the platform.
- Overseer needs: A named person who reviews alerts or trace samples on schedule, the skill to read them, and the authority to escalate or suspend.
Confirm that your retention settings cover at least six months and that the storage holding exports is under your control.
Article 26(5) requires the deployer to suspend use when a system presents a risk, to inform the provider and the market surveillance authority, and to report serious incidents to the provider first. Dify does not provide a regulatory suspension function, so the procedure depends on the stop points you can control inside the platform and on the records you keep outside it.
- Stop points: Identify how to stop an app for users, such as unpublishing the web app, revoking service API keys or disabling the workflow. Confirm each behavior in your Dify version and test it.
- Records of suspension: Dify does not record your suspension decision or your notices to the provider or authority. Keep a dated decision log outside the platform.
- Notification path: Document who informs the provider, the authority and your own legal and compliance teams, and set any timelines with counsel. The Act sets the sequence, but your internal deadlines are yours to define.
- Direct provider access: Revoking Dify's keys does not stop calls that use the same provider credentials from other systems. Inventory every place those credentials are used.
- Overseer needs: Written authority to suspend without waiting for approval, a tested runbook, and a second person who can act when the primary is unavailable.
Run a tabletop exercise that stops one app from end to end and records the time of each step.
What evidence the platform produces and how to keep it
A self-hosted Dify produces several distinct records that bear on deployer duties, and most of them are either time-limited or live inside the platform itself. The cards below cover each record, how to move it outside the cleanup window, and what an auditor is likely to ask for.
Workflow execution logs and retention
Workflow execution logs record each run of an app, including inputs, node outputs and errors. When WORKFLOW_LOG_CLEANUP_ENABLED is on, Dify deletes logs older than WORKFLOW_LOG_RETENTION_DAYS, which defaults to 30 days. Set the retention value to match your own record-keeping policy, then export logs on a schedule to storage you control. Ask the auditor which period they will test against and confirm that exported records are complete and tamper-evident.
Human Input decision records
Where a workflow pauses at a Human Input node, the reviewer's decision, timestamp and any edited content form the oversight record that Article 26 expects deployers to be able to show. Confirm in your own instance how these decisions are stored and whether they fall under the same cleanup setting as workflow logs. Export them with the matching run record so each approval can be traced to the output it released.
Tracing exports for monitoring
Tracing data shows how the system behaved in operation, which supports the monitoring duty and the risk-escalation steps in Article 26. Choose a tracing provider you control, confirm where trace data is stored and how long it is kept, and document the export schedule. Ask the auditor for evidence of a review cadence, meaning who looked at the traces, what they flagged and what happened next.
App DSL exports with version context
DSL exports capture app configuration, workflow nodes, model parameters and prompts, which shows exactly what logic was in use on a given date. They do not include third-party API keys, knowledge base content or usage logs, so those must be recorded separately. Store each export with a release note linking it to the Dify version and the change ticket. Auditors usually ask which version produced a given output, so this pairing matters.
Configuration snapshots and SECRET_KEY handling
The .env file records the settings that govern access, storage and outbound requests, so keep a versioned, access-controlled copy for each environment. Store SECRET_KEY in a secrets manager rather than in the file itself, because changing it after deployment logs out all users. Record who holds the key, when it was last rotated under a planned window, and where the backup copy is kept. Auditors will ask for proof of both the current configuration and the change history.
Pre-upgrade backup records
The Dify Docker Compose docs recommend a backup before every upgrade and advise checking .env.example for new variables afterward. Keep a dated backup record for each upgrade that names the source version, the target version, the backup location and the restore test result. Releases arrive roughly monthly, so this record shows that each change to the system was reversible. Ask the auditor which backup they will sample and confirm it can be restored.
Configuring a self-hosted Dify for deployer evidence
This sequence sets up a self-hosted Dify so that the logs, human oversight records, monitoring data and access controls a deployer needs are kept under the organization's control. Each step ends with a check the team can repeat.
Classify the use case against the AI Act
Before configuring anything, the compliance lead and the business owner decide whether the Dify application falls under the high-risk rules, using the Act's Annex III categories and Article 6 criteria. Record the classification, the intended purpose and the person accountable for the decision. Confirm the applicable dates with counsel, since the 2026 amendment moved the Annex III high-risk rules to 2 December 2027. The output is a signed classification record that determines how much of the following steps is mandatory.
Set workflow log retention above the default
The platform team enables WORKFLOW_LOG_CLEANUP_ENABLED and sets WORKFLOW_LOG_RETENTION_DAYS to a value that covers the period your legal team confirms for Article 26(6). Dify's default of 30 days is shorter than the six-month minimum, so leaving the default in place fails the requirement. Confirm with counsel whether other Union or national law sets a longer period. Verify the setting by reviewing the environment file in the running containers and by checking that older workflow runs remain queryable after a test cleanup window.
Place Human Input nodes on oversight decisions
Workflow designers add Human Input nodes at each point where a person must review, approve or override the model output before it affects a decision about a natural person. Assign named reviewers who have the competence, training and authority Article 26(2) describes, and document their role in the application's instructions. Test one full run in which a reviewer rejects an output, and confirm the rejection and reviewer identity appear in the run record. Store the design document with the app version.
Enable tracing and define monitoring duties
Enable tracing for the application so that inputs, node outputs, model calls and errors are recorded for monitoring. Connect the traces to the observability stack your monitoring owner already uses, and confirm which fields are captured before they leave the Dify database. Write a monitoring procedure that states who reviews the traces, how often, and what triggers suspension of use and notice to the provider and authority under Article 26(5). The check is a documented alert that fires in a test run.
Lock access through SSO or roles
Restrict workspace and app access to named people. Where the organization runs Dify Enterprise, connect an identity provider over OpenID Connect, SAML or OAuth2 and separate workspace access from web app access. On Community, use workspace roles and disable open sign-up through the environment settings. Confirm removal of a leaver's access in a test account, and keep a dated list of who can edit prompts, publish apps and read logs.
Protect SECRET_KEY, credentials and backups
Set SECRET_KEY once, before first use, and store it in your secrets manager because changing it later logs out all users. Confirm the workspace encryption key storage choice and the SSRF proxy settings in the environment reference. Take a backup of the database and file storage, then restore it into a separate environment and open a workflow run to prove the backup is usable. Record the restore test date and result.
Define the export and SIEM copy process
Because retention in the platform is a setting you control, decide where long-term copies go. Export app DSL files for each published version, and send workflow and trace records to a log store under your control on a schedule. Note that DSL exports exclude knowledge base content, usage logs and third-party API keys, so those need separate handling. Enterprise audit logs are a separate product with their own retention window, so confirm that window before relying on it. Verify by retrieving a sample record from the copy after the source record is cleaned up.
Schedule upgrade checks against new variables
Dify ships minor releases roughly monthly, so assign an owner to review each release note for security changes and deprecated settings. Before each upgrade, take a backup and compare your environment file with .env.example, since new variables can change retention or security behavior. Re-run the retention, oversight and access checks after each upgrade. The output is a dated upgrade record showing the version, the checks run and the variables added or changed.
Questions deployers ask before bringing in outside help
Does self-hosting Dify alone satisfy Article 26 of the EU AI Act?
No. Dify provides features that support deployer duties, such as log retention settings, a Human Input node and tracing, but Article 26 places obligations on the deployer's organization. You still need to decide whether a use case is high-risk, follow the provider's instructions for use, assign oversight to competent people, monitor operation and set up incident reporting. Dify gives you the technical pieces; the compliance design around them stays with you. Confirm the current scope of Article 26 against the EUR-Lex text of Regulation (EU) 2024/1689 and with your legal counsel.
What drives the cost and effort of EU AI Act deployer work on Dify?
The main drivers are the number of AI use cases in scope, how many of them are high-risk, how retention is designed, whether logs must flow into a SIEM, how oversight workflows are built, and how much documentation the deployer must produce. Each use case adds its own app configuration, review path and evidence set, so costs grow with the inventory. Infrastructure, licensing and any Enterprise features are separate cost lines. Ask any partner for a written scope that lists use cases, retention targets, integrations and deliverables before agreeing a fee.
How long does the work take, and what sets the duration?
Duration depends on the number of use cases, how mature your existing logging and identity setup is, and how many approvals the design needs. A single well-scoped use case with an existing platform moves faster than a portfolio that needs new retention storage, a SIEM feed and new review roles. Because most engagements are fixed-scope, the timeline is agreed in writing before work starts. Ask for milestones tied to specific deliverables rather than a single end date.
What do legal, security and business owners need to provide?
Legal needs to confirm which use cases are in scope, which other Union or national laws may set longer log retention, and how the organization's obligations as a deployer apply. Security needs to supply logging standards, identity and access policy, SIEM targets and incident handling procedures. Business owners need to name the people who will exercise human oversight, describe each use case and its affected users, and confirm the instructions for use from the provider. Agreeing these owners early prevents rework during the build.
Can our internal team set this up without outside help?
Often yes, if you already run Dify or similar platforms and have people who can manage Docker Compose or Kubernetes, configure log retention and build review workflows. The harder parts are the legal mapping, the oversight design and the evidence set, which need people with compliance and risk knowledge. A common approach is to build the platform internally and bring in a partner for scope review, retention design or a readiness check. Assess your team against the specific duties before deciding.
Does DeployOpen certify that our Dify deployment complies with the EU AI Act?
No. DeployOpen plans, implements, hardens, documents and supports self-hosted platforms, and prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications. Conformity assessment and any certification come from independent auditors, notified bodies or the authorities named in the Act, depending on the system. Ask any partner to state clearly which parts of the work prepare evidence and which parts a third party must assess.
Which log and retention settings should engineers check first?
Start by confirming that the workflow log cleanup setting is enabled or disabled as your retention design requires, and set the retention period to the length your obligations call for. The default cleanup behavior removes workflow execution logs after the configured number of days, so a default deployment does not meet a six-month target without changes. Test retention in a staging environment, back up data before changes, and verify that exports reach your log store before the platform deletes them.
How DeployOpen scopes and delivers AI Act evidence configuration
DeployOpen plans, implements, hardens and documents self-hosted Dify inside your own infrastructure, including the log retention, oversight and monitoring settings that deployer duties depend on. Engagements are fixed-scope, with the evidence configuration defined in writing before any build starts.
How we scope
- We confirm which Dify apps are high-risk under your own classification before any configuration starts
- The written scope lists retention settings, Human Input node placement, tracing targets and log storage locations
- We state which deployer duties stay with your team, such as incident reporting, staff competence and fundamental rights impact
How we build
- We set workflow log retention and cleanup values to match your confirmed retention period, then test them against a sample run
- We configure Human Input nodes with named reviewers, decision records and escalation paths agreed with your business owners
- We connect tracing and monitoring outputs to storage you control and verify that the records remain readable after cleanup
How we hand over
- You receive a configuration record mapping each deployer duty to the Dify setting or process that supports it
- Runbooks cover log export, cleanup timing, oversight steps, suspension and how to contact the provider and authority
- Documentation states clearly which evidence remains your responsibility and which items need review by your legal or compliance team
How we support
- Ongoing support is available as a retainer for Dify upgrades, configuration changes and retention reviews
- We track Dify minor releases and check the environment variable reference for changes that affect logs or cleanup
- Retainers can include periodic checks that stored logs, oversight records and monitoring outputs still match your written scope
