OWNER-APPROVED ENGLISH VERSION — EFFECTIVE 26 AUGUST 2026. Version 1.0.0. Independent Czech legal review is recommended but has not been obtained. This English document applies only where English satisfies applicable language requirements. Publication does not enable paid signup, Stripe Live, a blocked territory or an unverified product capability.
1. Security approach
DIRI AI uses risk-based controls intended to protect confidentiality, integrity and availability. Security is shared: DIRI AI protects the service and configured infrastructure; customers protect their users, devices, credentials, content choices and administrator decisions.
This overview describes the control design and release requirements. It does not claim ISO 27001, SOC 2, PCI DSS certification for DIRI AI, penetration-test coverage or uninterrupted service. Provider certifications do not become DIRI AI certifications.
2. Identity, access and tenant controls
The intended controls include:
- unique user identities and protected production session cookies;
- server-side, role-based and tenant-scoped authorisation;
- administrator-managed invitations, roles and member removal;
- least-privilege access to production systems and provider accounts;
- separate development/test and production configuration;
- rate limits and anti-abuse controls; and
- audit records for security-relevant administrator and subscription events.
Cross-tenant access tests, privilege review and account-recovery evidence are required release checks. Multi-factor authentication should be enabled on provider and privileged accounts and made available to customers where supported.
3. Data protection
Supported traffic should use TLS in transit. Managed providers should encrypt stored data at rest using their standard controls, with regions chosen and verified in the Subprocessor List. Secrets must be held outside source code and ordinary logs. Payment card entry is delegated to the payment provider so DIRI AI does not need the full card number.
Voice recording storage is intended to be off by default. Telemetry must be sanitised and Customer Content excluded from routine logs where feasible. Production debugging must be time-limited, authorised and recorded.
4. Application and release security
The release process is intended to use peer/change review, automated tests, dependency and secret checks, trusted-ingress controls, signed provider webhooks and fail-closed readiness gates. A successful local test, preview page or health response is not production approval.
Critical provider calls, paid signup and live billing remain disabled when legal, billing, model or readiness evidence is incomplete. Security controls must not be weakened merely to make a readiness check pass.
5. Monitoring and incident response
The design uses sanitised application error telemetry, operational metrics, audit logs and provider events. Monitoring coverage, quota, alert delivery and on-call ownership must be proven for the exact release. Internal metrics are not marketing analytics.
Suspected incidents are triaged, contained, investigated, remediated and documented under the Incident Notification Policy. Personal-data breach obligations are assessed separately from ordinary availability events.
6. Availability, backups and recovery
The architecture uses managed hosting, database, cache/queue and object-storage providers. Backup, restore, queue retry and data-lifecycle configuration must be tested with exact-release evidence. No recovery-time or recovery-point objective is promised in standard plans until formally measured and contracted.
Standard plans have no percentage uptime SLA. This does not limit mandatory consumer conformity or remedy rights.
7. Provider risk
Providers are reviewed for purpose, access, contractual terms, security information, region, transfer mechanism, retention and deletion. Only the minimum necessary data should be sent. A configured account or provider DPA alone is not proof that the end-to-end production flow is ready.
OpenAI and ElevenLabs public-production calls, Stripe Live and parts of monitoring/readiness remain gated on the preparation date. The effective Subprocessor List must reflect actual activation.
8. Customer responsibilities
Customers must:
- use strong unique credentials and multi-factor authentication where available;
- keep devices, browsers and integrations updated;
- grant the minimum roles, review membership and remove leavers promptly;
- avoid uploading unnecessary sensitive or real-client data;
- verify exports before account closure and protect downloaded files;
- configure lawful retention and employee notices; and
- promptly report suspected compromise without publicly disclosing exploitable detail.
9. Vulnerability reporting
Send a concise report to security@diriai.com with the affected route, reproduction steps, impact and a safe proof. Do not access another customer's data, disrupt service, use social engineering, exfiltrate data or demand payment. Stop testing after confirming the issue and allow reasonable time for investigation.
No public bug bounty or broad safe-harbour programme exists unless separately published. Good-faith reports will be handled responsibly, but this overview does not authorise conduct otherwise unlawful.
10. Contact and version
Security reports: security@diriai.com. Privacy incidents: privacy@diriai.com. Effective version: 1.0.0. Effective date: 26 August 2026.