Compliance and Regulatory Context
This chapter maps the platform against common regulatory regimes and clarifies the responsibility split between platform, operator, and customer.
The companion Security and Privacy chapter describes the platform's concrete security mechanisms; this page focuses on how those mechanisms map to regulatory context.
Regulatory Context
GDPR
When you deploy Operaide to process personal data, you are typically the GDPR controller for that data. Because Operaide is installed and operated by you or the operator you choose — not consumed as a SaaS from objective partner — objective partner is not a processor by virtue of the software alone. No personal data flows to objective partner as part of normal operation.
Every Operaide instance reports aggregated usage metrics to a central audit service (token totals, active-user counts, workflow execution counts, platform version). These metrics do not contain prompts, workflow payloads, or personal data; they are designed for capacity planning and cross-instance observability. The audit service connection is a required platform component — the nature of that data flow should be reflected in your own record of processing activities.
EU AI Act
The EU AI Act classifies AI systems by risk level, and the classification of any system built on Operaide depends on the use case it implements. Classification and conformity assessment are your responsibility as the deploying organization.
The platform provides architectural building blocks that support high-risk-system requirements: workflow decomposition for traceability, explicit step boundaries for documentation, typed interfaces at each step for robustness, and controlled data flows through the connection system. Human-oversight gates — the point in a workflow where a person has to approve or reject a decision — are designed into the specific workflow as an aktor, not enabled by a platform toggle. This is deliberate: meaningful human oversight depends on what is being decided and by whom, which is use-case-specific.
BSI C5
BSI C5 applies to the hosting infrastructure, not to Operaide itself. The platform can run on infrastructure that carries a C5 attestation; it does not carry a C5 attestation as a product. If C5 is a requirement for your deployment, the practical implication is that you choose an operator whose infrastructure is C5-attested.
Certification status of AI platforms
Formal certification schemes specifically for AI workflow platforms are still emerging. There is no established certification process you can obtain against criteria catalogs such as the BSI AIC4 today. A detailed orientation against the BSI AIC4 criteria catalog — covering all eight requirement areas — is available as a separate document on request.
Shared Responsibilities for Compliance
A compliance conversation about Operaide has three parties, not two.
| Concern | Platform (Operaide) | Operator (Infrastructure) | Customer (Deployment) |
|---|---|---|---|
| GDPR controller role | — | — | Yes |
| GDPR processor role (where applicable) | — | Yes (if hosting on behalf of the controller) | — |
| Infrastructure-level certifications (ISO 27001, C5, …) | — | Yes | — |
| TLS, network segmentation, firewalls, backups | — | Yes | — |
| Authentication and RBAC mechanisms | Yes | — | — |
| Tenant isolation (org, app instance, process, workflow step) | Yes | — | — |
| Workflow-level traceability and usage tracking | Yes | — | — |
| Controlled data flows through the connection system | Yes | — | Configured by customer |
| Use-case classification under the EU AI Act | — | — | Yes |
| Human-oversight gates in workflows | Platform primitives | — | Designed into the workflow |
| Quality, bias, and evaluation criteria | — | — | Defined per use case |
| Role assignments, data classification, retention policies | — | — | Yes |
| Long-term audit archival | — | Yes | Policy defined by customer |
| Incident response operations (24/7, SOC) | — | Yes | — |
What the Platform Provides for Compliance Workloads
The Security and Privacy chapter covers these mechanisms in detail. The compliance-relevant summary is:
- Infrastructure-agnostic deployment. Operaide runs as a containerized HTTP application. It can be deployed on public cloud, private cloud, or on-premises infrastructure of the operator's choice, with a reverse proxy (for example Caddy, nginx, Apache, or a cloud load balancer) in front for TLS termination. Operaide does not require a specific cloud provider, managed database, or managed object store. This lets you select infrastructure that already carries the certifications your compliance regime requires.
- Tenant isolation at four layers. Organization scoping, workflow-step isolation inside a Reaktor, app-instance isolation (own database and vector store), and process isolation at the operating-system level. Detailed in Security and Privacy → Tenant Isolation.
- Controlled data flows through the connection system. Every external data flow configured by apps is a first-class, typed, organization-scoped Connection object. There are no hidden environment-variable credentials and no hard-coded endpoints. The platform itself maintains one outbound connection — the required audit service feed that reports aggregated usage metrics (see Monitoring and Reporting → The Audit Service Feed). Beyond that, to enumerate every external data flow in a deployment, look at the list of configured connections.
- Automatic, persistent usage tracking. Every workflow execution and every AI call is recorded with start/end times, duration, success/error status, the initiating user, the model, the provider, token counts, and the related organization. These records are always-on, independent of any debug or trace setting, and surface in the Monitoring and Reporting dashboard with CSV export. This is the primary data source for evidence-based compliance reviews.
- Workflow-level explainability. Because Reaktors are decomposed into discrete aktors with typed inputs and outputs, the decision path through a workflow is visible as structure rather than hidden inside an opaque agent loop. When a reviewer asks "how did the system arrive at this result?", the answer is the graph of steps the workflow executed — each one with a documented purpose — not the contents of the LLM's weights.
- Role-based access control with a "can become" activation pattern for privileged roles. Detailed in Roles and Rights.
- Credential redaction in detail logs and the Connection REST API. When detail logging is enabled for troubleshooting, API keys, tokens, and passwords are automatically redacted from the stored trace and from API responses. Detailed in Security and Privacy → Audit Logging and Usage Tracking.
Mapping Common Requirements to Platform Mechanisms
The table below maps requirements that recur across compliance regimes to the Operaide mechanism that addresses them. "Customer" entries mean the requirement must be implemented as part of the workflow or operational setup, not enabled by a platform toggle.
| Requirement area | Platform mechanism | Additional responsibility |
|---|---|---|
| Access control, least privilege | Hierarchical RBAC, composite roles, "can become" activation for privileged roles | Customer assigns roles to users |
| Data minimization | Aktor-step isolation ensures each step sees only the data it needs | Customer designs the workflow to pass only the minimum required context |
| Data sovereignty / regional residency | Infrastructure-agnostic deployment allows choosing a region-constrained operator | Operator enforces region constraints; customer configures external connections that respect region |
| Traceability of AI interactions | Automatic TokenUsage and ReaktorUsage records (model, provider, tokens, user, org, duration, status) | — |
| Per-step traceability for explainability | Aktor decomposition with typed inputs and outputs; optional per-step detail logging (debug mode) | Customer decides when detail logging is appropriate for the workload |
| Controlled external data flows | Connection system with typed schemas, org scoping, lifecycle management | Customer configures connections; only the CredentialManager role can write credentials |
| Input validation at system boundaries | Typed schema validation on all external inputs (REST endpoints, workflow parameters, connection configuration) | — |
| Credential storage | API keys stored as SHA-256 hashes; connection secrets redacted in logs and REST responses | Operator handles volume-level encryption at rest |
| Tenant separation between organizations | Multi-tenancy enforced at query level; app-instance isolation at database and process level | — |
| Human-oversight gate in a decision flow | Aktor primitive (the platform can execute any shape of workflow) | Customer designs the oversight step as an aktor in the specific workflow |
| Long-term immutable audit archival | CSV export of platform records for ingestion into external systems | Operator provides the long-term archive with immutability guarantees |
| Authentication, SSO, MFA, conditional access | Delegation to an external OpenID Connect provider (Entra ID, Keycloak, Google Workspace, Okta, ...) | Customer and operator configure the identity provider |
| Backup, disaster recovery, high availability | — | Operator |
| Infrastructure certifications (ISO 27001, C5, …) | — | Operator |
Known Limits for Compliance Workloads
The Security and Privacy → Known Limits section lists the cross-cutting limits (detail-log retention, credential redaction vs. PII redaction, absence of an in-house SOC, aggregated-only audit feed). Three additional limits are worth calling out explicitly in a compliance context:
- No generic bias-monitoring or evaluation feature. Operaide does not ship a built-in bias detector or a generic evaluation harness. Evaluation, bias analysis, and quality gates are implemented as app-specific aktors; the platform provides the database access, logging, and custom UI building blocks needed to build them, but the definition of what to measure and how to act on it is use-case-specific. This is a design choice, not a gap: generic bias detection across heterogeneous workflows tends to produce false confidence more than insight.
- Human-in-the-loop is a workflow-design pattern, not a platform toggle. The platform can execute workflows that require human approval at specific steps — the aktor framework is flexible enough to pause for input, record a decision, and continue — but there is no global "require human oversight" switch. Designing oversight into a workflow is a deliberate act with consequences for latency, user experience, and cost, and belongs in the workflow definition rather than in platform configuration.
- Long-term immutable audit archival is an operator concern. Operaide retains its own usage records and (optionally) detail logs, but it is not designed to be the system of record for multi-year immutable audit trails. If your regime requires that, the recommended pattern is to export usage data periodically (via CSV or the audit-service feed) and archive it using the operator's long-term storage — for example, write-once object storage with object-lock semantics.
These are the points where the platform stops and your operator's or your own processes take over.
Design Mindset
Many of the properties that matter in a compliance review — explainability, traceability, human oversight, bounded error paths — are not features bolted onto Operaide. They follow from a specific way of thinking about LLM-powered systems: a reliable solution is built the way an experienced human would perform the task, decomposed into small, well-defined steps where each step has a clear role, a clear boundary, a clear error path, and an escape hatch when it cannot make a safe decision. This is the opposite of handing an open agent loop free rein over data and tools.
The consequence for compliance is direct. When a reviewer asks "how did the system produce this result?", the answer is the structure of the workflow — visible as code and as execution records — rather than the contents of a model's response. When a reviewer asks "what is this system allowed to do?", the answer is the list of connections and the typed interfaces of its aktors, not a promise about the model's behaviour.
The full version of this approach is being written up as a dedicated chapter. See Design Mindset for the current framing and more context on the audiences it addresses.