How a self-hosted AI gateway supports GDPR processor and transfer obligations
A self-hosted AI gateway lets an organization decide which model providers may receive personal data, but it does not by itself make any provider compliant. When staff tools and products call external LLM APIs, personal data may leave the EU, and the gateway is the place where that exposure can be enforced: an allowlist of approved provider endpoints, model restrictions per virtual key, and a block on any request routed to an endpoint outside the approved set. Those controls reduce the chance of an unapproved transfer, but they do not replace the legal work. Under Article 28(1) of the GDPR, a controller may use only processors that give sufficient guarantees on technical and organisational measures, and the gateway's own configuration is part of the evidence for that assessment.
The contract and the transfer mechanism carry the rest of the obligation. Article 28(3) requires a written contract that limits the processor to documented instructions, sets confidentiality, sub-processor conditions, assistance with rights requests and audit access, and deletion or return of data at the end. Where data goes to a third country without an adequacy decision, Article 46 requires an appropriate safeguard, such as Commission standard data protection clauses under Article 46(2), and the data exporter must document that safeguard. The gateway supports these duties by producing a current inventory of every provider it calls, the regions and sub-processors each one uses, and the log of which application sent which data to which endpoint. Teams should confirm each provider's contract terms, transfer tool and sub-processor list directly with that provider, since the gateway cannot read them.
DeployOpen plans, implements and documents the gateway, and prepares the evidence a controller or auditor will ask for, including routing configuration, key and budget records, and change logs. DeployOpen does not issue audit reports, attestations or certifications, and certification under Article 42 is voluntary and does not reduce the controller's responsibility. Before scoping an implementation, the data protection officer and legal team should decide which data classes may reach external APIs at all, which providers have an executed contract with the required Article 28 terms, and who approves a new provider. Those decisions define the gateway's allowlist, and they should be written down before the first production route is configured.
Which GDPR requirements a gateway can enforce and how to configure it
This table maps each GDPR provision that governs model providers to the gateway setting that enforces it and the evidence an assessor will ask for. Read it as a split of responsibilities: the gateway enforces technical routing and logging, while the contract with each provider and the legal transfer basis sit outside the gateway. The main takeaway is that a gateway shows where personal data went, but it does not make a provider compliant on its own.
| Requirement | Gateway setting | Evidence to keep |
|---|---|---|
| Article 28(1): sufficient guarantees from processors | Model allowlist per provider, so only providers that passed the internal due diligence can be called. Contract terms are not configured in the gateway. | Approved provider register with due diligence results, and the allowlist configuration export with change history |
| Article 28(2): sub-processor authorisation | Route changes to a provider or a new model endpoint through a reviewed configuration change, so the controller can object before traffic moves | Change tickets for new providers or endpoints, and records of the notices received under the contract |
| Article 28(3): documented instructions and audit rights | Gateway configuration kept as code with approvals. Audit rights and instructions are set in the DPA, not in the gateway. | Versioned routing config, admin access logs, and the audit clause in each provider agreement |
| Article 32: security of processing | Virtual keys per team, keys stored in a secret manager, SSO for the admin UI, and PII redaction before external calls | Key inventory, access review records, and redaction test results |
| Article 46(1) and 46(2): transfer safeguards | Routing rules that send personal data only to EU-hosted or self-hosted endpoints, and block non-approved regions by model allowlist | Routing rule set mapped to the transfer basis for each approved provider, such as standard clauses or certification |
| Article 46(3): ad hoc clauses | Gateway can enforce a provider only after its clause set is approved; the gateway itself cannot grant that approval | Supervisory authority authorisation records, where ad hoc clauses are used, linked to the allowlist entry |
| Request and access logging | PostgreSQL logs record which model and provider handled each request, with retention set by policy | Log schema, retention settings, and sample queries showing the provider for a given team |
Which open-source gateways fit a GDPR-controlled model estate
A gateway only enforces GDPR controls if it can restrict which providers receive personal data, record that routing, and run inside infrastructure the organization controls. The options below differ in how they handle keys and budgets, how they authenticate administrators, and which features sit behind a commercial license.
LiteLLM as the model routing layer
LiteLLM is an AI gateway that calls more than 100 LLM providers in the OpenAI request format. Its MIT license covers everything outside the enterprise directory, so the core proxy can run in your infrastructure without a license fee. Use per-key model restrictions to block providers that are not approved for personal data. For more than one proxy instance, plan for PostgreSQL as the primary database and Redis 7.0 or newer for shared rate limits and router state. Confirm which features you need before assuming they are in the free tier.
Virtual keys and budgets per team
LiteLLM virtual keys support per-key, per-user and per-team budgets, TPM and RPM limits, and restriction to specific models. These controls matter for GDPR because they let you tie each application or department to the providers its data processing terms cover. Keys need a PostgreSQL database. Ask your partner to document which team may use which provider, and how keys are issued, rotated and revoked when a provider's processor terms change.
Apache APISIX as the policy edge
Apache APISIX is an Apache-2.0 gateway, currently at 3.19.0, with AI gateway functions and more than 100 built-in plugins. It fits where an organization already runs API infrastructure and wants one enforcement point for authentication, traffic control and logging across many services. It offers traditional, decoupled and standalone deployment modes, so you can keep configuration under change control in a file-driven setup. Confirm the AI routing and provider-allowlisting features you need against the current plugin documentation.
OpenID Connect for administrator access
The APISIX openid-connect plugin works with Keycloak, Auth0, Microsoft Entra ID, Google and Okta and supports authorization code, client credentials, token introspection and PKCE flows. LiteLLM admin UI SSO is free for up to 5 users, and SSO beyond that, along with SCIM, requires an Enterprise license. Map administrator roles to your identity provider before go-live. Record who can change routing rules, since a change that adds an external provider is a change to personal data flows.
Enterprise features to price in
LiteLLM Enterprise adds SSO and SCIM beyond the free limit, audit logs, organization and team RBAC, IP allowlisting, secret manager integrations and team-level guardrails and logging. Each of these supports Article 28 obligations such as access control, documented instructions and audit, so the license decision belongs in the GDPR design, not after it. Ask the vendor which features each license tier includes and whether the enterprise directory terms apply to your deployment.
Kong Gateway as an option to confirm
Kong Gateway is an Apache-2.0 API gateway, currently at 3.9.4, and many enterprises already run it for general API management. Whether it can enforce model-level routing, token budgets and prompt logging for LLM traffic is a question to test, not assume. Run a proof of concept that sends one approved and one blocked provider request through the gateway and check that the block is enforced and logged. Include the cost of any plugins you need in the comparison.
Langfuse and Phoenix for logging
A gateway log shows which provider received a request, but observability tools record prompts, outputs and evaluations in more detail. Langfuse is MIT licensed outside its ee directories and can run in your own storage. Arize Phoenix is licensed under the Elastic License 2.0, which prohibits providing the software to third parties as a hosted or managed service. Internal self-hosting is a different question from offering it to customers, so have counsel confirm your use. Decide where logs are kept and for how long before choosing either tool.
How the gateway enforces which providers may receive personal data
The gateway is the single point where a GDPR processor decision becomes an enforced rule. Applications call one internal endpoint with a virtual key rather than calling model providers directly. For each request, the gateway first authenticates the key and resolves the team, application and user it belongs to. It then checks the requested model against an allowlist tied to the data classification the application declares for that workload, for example public, internal, personal data or special category data. If the model or provider is not approved for that class, the request is refused before any personal data leaves the environment. If it is approved, guardrails run on the prompt, the router selects an endpoint (a self-hosted model or an approved external provider), and the call is logged with the key, model, provider and classification. LiteLLM's virtual keys can restrict a key to specific models, which is the native control for this check. Confirm with your platform team how the data classification is passed to the gateway, because a classification that depends on the caller alone is only as reliable as the caller.
Data classes should map to approved processors in a table that the gateway configuration is generated from, not maintained by hand in two places. A reasonable starting design, to be validated against your own records of processing, routes personal data only to self-hosted models or to providers covered by a Article 28 contract with the controller's written authorization, and routes special category data only to self-hosted models. Each provider entry should record the contract reference, the processing location, the sub-processors the provider has disclosed, and the transfer safeguard relied on under Article 46 where data leaves the EEA. Under Article 28(2), a change of sub-processor needs the controller's authorization or, under general authorization, notice that allows an objection, so a new provider added to the gateway should trigger the same review. The register of approved providers then feeds the controller's records of processing, the Article 30 record, and the processor list that supports transparency duties. Ask your legal and privacy team whether the register must also cover internal routing rules and whether logs of refused requests count as personal data processing in your setup.
What transfer safeguards and processor contracts still need from the organization
Does an adequacy decision like the EU-US Data Privacy Framework cover a given model provider?
An adequacy decision covers a provider only if that provider is certified under the framework for the relevant data, so you must check the provider's current status rather than assume it. The EU-US Data Privacy Framework was adopted through Commission Implementing Decision (EU) 2023/1795, which is the instrument to read alongside the provider's own certification record. Confirm with counsel whether the provider is listed, whether the certification covers the data categories you send, and whether any transfer to a sub-processor or another region falls outside it. A gateway can enforce the result by allowing only providers and regions your counsel has cleared, but the legal conclusion stays with your organization.
When are standard contractual clauses from Implementing Decision (EU) 2021/915 needed?
Standard contractual clauses are needed when personal data goes to a provider where no adequacy decision applies, and Article 46(2) lists Commission standard data protection clauses as one safeguard that needs no further authorization. Implementing Decision (EU) 2021/915 sets out the clauses between controllers and processors, which is a different use from transfer clauses between exporters and importers outside the EU. Ask the provider which clause set it has signed, for which transfer scenario, and whether it covers onward transfers. Counsel should confirm the exact combination for each model endpoint before any personal data is routed to it.
How are sub-processor changes handled under general authorisation?
Under general written authorization, the processor may add sub-processors but must inform the controller of intended changes so the controller can object, as Article 28(2) requires. For a hosted model provider, this means you need to receive change notices, review the new sub-processors and their locations, and have a documented route to object or leave. An illustrative workflow is a shared mailbox that receives provider notices, a review record for each change, and a gateway configuration step that removes or blocks the affected endpoint if you object. Confirm the notice period and objection process in the contract, because the gateway cannot see a provider's internal subcontracting.
Does the EDPB's April 2026 opinion on the European Data Protection Seal matter for a specific importer?
It matters only if a specific importer holds or is pursuing the European Data Protection Seal, which the EDPB opinion of 16 April 2026 recognized as a transfer tool under Articles 42 and 46 based on Europrivacy certification criteria. The opinion is open to importers outside Europe that are not subject to the GDPR, so a provider could be relevant. Ask the provider whether it holds the seal, the scope of the certification, and its validity period. Certification under Article 42 is voluntary, lasts for at most three years, and does not reduce your responsibility for compliance, so it should be one input to your assessment and not a substitute for contract terms.
Why does a gateway log not replace a written Article 28 contract?
A gateway log records what happened, while an Article 28 contract records what the processor must do, and the GDPR requires the contract to be in writing, including electronic form, as Article 28(9) states. The contract must require the processor to act only on documented instructions, keep staff confidential, apply Article 32 measures, respect sub-processor conditions, assist with rights requests, and delete or return data at the end. A log can show that a request went to a provider, but it cannot establish the legal relationship, the processor's obligations or the audit rights. Keep the contract and the gateway evidence together so each answers a different question.
What must the organization ask a model provider to put in the processor contract?
The contract should cover the Article 28(3) elements: documented instructions, staff confidentiality, Article 32 security measures, sub-processor conditions, assistance with data subject rights and Articles 32 to 36, deletion or return of data, and information and audit access. Ask the provider to state whether prompts and outputs are used for training, where processing happens, how long logs are retained, and how breach notice is given. Confirm each item against the provider's data processing terms, because public terms can change and a negotiated agreement may differ. Counsel should review the final text before personal data is sent.
How much does the contract and transfer review cost, and who pays for it?
The costs fall on three parties: your legal and privacy team for the review, the provider for any contract changes it accepts, and your implementation partner for configuring the gateway to enforce the approved list. Review effort rises with the number of providers, regions, data categories and sub-processor chains involved. Ask any partner for a written scope that separates the technical enforcement work from the legal analysis, which should stay with your counsel. No price or duration is set here because none was supplied for this topic, so request a quote based on your specific provider list.
Can DeployOpen confirm adequacy or sign processor contracts for us?
No. DeployOpen plans, implements and configures a self-hosted gateway so that routing rules follow the providers and regions your organization approves, and it prepares evidence for compliance assessments. It does not provide legal advice, negotiate or sign contracts with providers, or issue audit reports or certifications. Your counsel and privacy team decide whether a transfer mechanism applies and what the contract must say. A written scope from a partner should state which parts of the transfer assessment are technical and which remain with your organization.
Evidence auditors and supervisory authorities ask for, and which component produces it
This table maps the records a GDPR assessor or supervisory authority is likely to request to the component that produces each one: the gateway, its database, the SSO layer, or the organization's contract store. Read it as a collection plan, since a missing record usually means a component was never configured to keep it. The main takeaway is that the gateway produces the technical trail, but the approved-provider register, DPAs and transfer instruments live outside it and need their own owner.
| Evidence item | Primary source | What the assessor checks |
|---|---|---|
| Records of processing and approved-provider register | Organization's contract store, mapped to gateway model list | Every external provider that can receive personal data is named, with purpose and data categories |
| Allowlist configuration exports | Gateway configuration (model and provider allowlist, exported on change) | Only approved providers and models are reachable, and changes are dated and attributable |
| Virtual key and team inventories | PostgreSQL database behind the gateway | Which teams and applications hold keys, which models each key can reach, and when keys were revoked |
| Routing and fallback configuration history | Gateway configuration under version control, with database change records | Failover never silently sends personal data to a provider outside the approved list |
| Call logs showing provider and data classification | Gateway request logs stored in PostgreSQL or the log platform | Which provider received which class of data, with a timestamp and calling application |
| Guardrail and redaction test results | Test records kept by the organization, run against the gateway | Redaction and blocking rules were tested before release and re-tested after changes |
| Admin UI access logs | SSO layer (identity provider) and gateway audit logs | Who administered keys, budgets and routing, and whether access used named identities and MFA |
| Retention and deletion settings | Gateway and database retention configuration, plus organization retention policy | Prompt logs are kept no longer than the stated purpose requires and deletion is executed |
| DPAs and transfer instruments per provider | Organization's contract store | Each processor has a signed contract meeting Article 28 and a transfer safeguard under Chapter V where data leaves the EEA |
| Breach-response records | Organization's incident register, using gateway logs as input | Gateway logs support detection, scoping and the Article 33 notification timeline |
What the gateway alone does not satisfy under GDPR
A gateway enforces which providers receive traffic, but it does not create the legal relationship with those providers or decide why personal data is processed. The gaps below sit with contracts, mapping, provider behavior and the controller's own accountability, and each needs an owner outside the gateway project.
Contracts and transfer instruments
Article 28 requires a written contract with each processor, and Article 46 requires a transfer safeguard before personal data leaves the EEA without an adequacy decision. A gateway routing to a provider does not produce either document. Check that each approved provider has a signed data processing agreement, and that any transfer relies on a listed instrument such as Commission standard contractual clauses, which may be based on Implementing Decision (EU) 2021/915. Confirm the wording with counsel before traffic is switched on.
Data mapping and lawful basis
The gateway sees prompts and responses, but it does not know why a team is processing a given record, which lawful basis applies, or whether the purpose matches the original collection. Those decisions come from records of processing and a data inventory maintained by the controller. Before adding a provider to an allowlist, document which categories of personal data each application sends, the purpose, and the retention period that applies to logs the gateway stores.
Provider handling after receipt
Once a provider receives a request, the gateway has no visibility into how that provider stores, logs, reviews or secondarily uses the data. Routing rules cannot enforce a deletion, an access restriction at the provider or a limit on staff review. Ask each provider for its documented processing terms, the regions where inference and logs are held, and whether it accepts the instructions and audit rights that Article 28(3) expects. Record those answers in the vendor file.
Provider retention and training terms
Retention periods and model training defaults are set by the provider's terms, and they change. A gateway can block a provider, but it cannot remove data already retained under a previous default. Check whether each plan used through the gateway excludes customer data from training, what abuse-monitoring retention applies, and whether zero-retention or regional options exist for the contracted tier. Confirm the current terms in writing rather than relying on marketing pages, and re-check them at each renewal.
Controller exposure under Article 83
Administrative fines under Article 83 fall on the controller and the processor, and a self-hosted gateway does not reduce that exposure on its own. Certification under Article 42 is voluntary, does not transfer responsibility, and the GDPR requires no audit report. Regulation (EU) 2025/2518 applies from 2 April 2027 and sets procedural rules for cross-border enforcement. The Omnibus IV and Digital Omnibus proposals may change some obligations, so confirm the current text with counsel.
How much does GDPR-ready AI gateway work cost and how long does it take
What drives the cost of a GDPR-ready self-hosted AI gateway?
The cost depends mostly on how many model providers the gateway must route to, how many data classes need separate rules, and which enterprise features the organization requires. Each provider adds configuration, credential handling, contract review and test cases. Each data class (for example, personal data, special category data or internal-only material) adds a routing policy, a guardrail rule and a logging decision. The main cost components are:
- Platform work: installing and hardening the gateway, connecting it to PostgreSQL and Redis, and configuring virtual keys, budgets and routing.
- Licensing: LiteLLM's SSO and SCIM, audit logs and team-level guardrails sit in the enterprise directory under its own license, and SSO is free only up to 5 users from v1.76.0 onward.
- Integration and testing: proving that blocked providers really receive no personal data.
Ask any quote to show each line separately so you can see which drivers you can reduce.
How long does scoping take before a GDPR gateway project starts?
Scoping time depends on the scope agreed in writing, not on a fixed template. A narrow scope covering one gateway, two or three providers and one identity source is quicker to define than a scope that also covers data classification across several business units, transfer assessments and the records for supervisory authorities. DeployOpen works with clients on fixed-scope engagements, so the scope, deliverables and timeline are agreed in writing before implementation starts. Ask for the scoping step to produce a list of providers, data classes, identity sources and log retention requirements, because those four items determine most of the later timeline.
Can our internal engineering team build this without a partner?
Yes, many teams with platform and security engineering skills can deploy LiteLLM or Apache APISIX, PostgreSQL and Redis themselves, and the open-source components are free to use under their licenses. The harder parts are usually the ones outside the software: deciding which providers a given data class may reach, documenting transfer safeguards, reviewing processor terms with each provider and proving the routing rules work under test. Confirm internally whether your team has capacity to maintain upgrades, patch the gateway and keep the enterprise-license decisions current. A partner can cover one part of this work, such as implementation and testing, while your staff keep ownership of policy.
What does the legal and privacy team need to contribute?
Legal and privacy staff own the decisions that the gateway enforces, so their input is needed before engineering configures routing. They should confirm which processing purposes and data classes apply, which providers are approved as processors, whether the contract includes the terms Article 28 of the GDPR requires, and which transfer tool covers each non-EEA provider under Article 46. They also decide retention periods for prompt logs and who may access them. Ask the partner to show which of these decisions are inputs to the configuration and which remain your responsibility, and confirm the required review steps with your data protection officer.
What should a quote for GDPR-ready gateway work include?
A useful quote lists the written scope, the deliverables and the assumptions behind them. It should name the gateway product and version, the number of providers and self-hosted models in scope, the data classes and routing rules, the identity integration, the database and cache design, and the test cases that show blocked providers receive no personal data. It should separate one-time work (design, installation, configuration, testing and documentation) from recurring work (upgrades, support and retainers). Ask which third-party licenses are required, who pays for them, and what the client must provide, such as provider accounts, infrastructure access and staff time for reviews. DeployOpen does not publish a price list, so compare quotes on scope and assumptions rather than on headline figures.
Which technical choices affect GDPR gateway operating costs?
Operating cost is shaped by the database and cache design, the number of gateway instances and the logging volume. LiteLLM's production guide names PostgreSQL as the primary supported database and requires Redis 7.0 or newer once more than one proxy instance runs, which means both services need backup, monitoring and patching. It also suggests 1 vCPU and 4 GiB memory per worker, and recommends one Uvicorn worker per pod on Kubernetes while scaling horizontally. Storage for prompt and decision logs grows with traffic and with the retention period set by your legal team. Ask the partner to model these components for your expected traffic rather than to quote a single figure.
Is there ongoing cost after the GDPR gateway goes live?
Yes, several costs recur after go-live. Software upgrades are needed because LiteLLM maintains support for the four most recent stable minor versions, so the team must move to a supported release on a regular cycle. Provider contracts, model lists and routing rules change as new models arrive, and each change needs review against the GDPR controls. Logs require storage, access reviews and eventual deletion. Enterprise licenses, if used, renew on their own terms. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and the scope of any retainer should be written down and priced separately from the initial implementation.
What does testing add to the cost of a GDPR gateway?
Testing adds cost because the gateway must show that its controls work, not just that it routes traffic. Test cases should confirm that a request carrying personal data cannot reach a provider that is not approved for that data class, that virtual keys stop working when revoked, that fallback routing does not send restricted data to a non-approved endpoint, and that logs record the decisions your records require. DeployOpen runs security testing for applications, APIs and AI systems, which can cover these checks. Confirm in the quote how many test scenarios are included, who reviews the results and how re-testing after a configuration change is handled.
How to roll out provider controls without breaking applications
Roll out provider controls in five phases, and do not start by blocking traffic. First, inventory current provider use: find every application, script, plugin and developer tool that calls a model API, including direct calls that bypass any existing approval process. Second, classify the data each use case sends, separating prompts that contain personal data from those that do not, because Article 28(1) and Article 46(1) only matter once you know which flows carry personal data. Third, approve providers only where the contract is in place: a written processor agreement under Article 28(3), and transfer safeguards under Article 46(2) where a provider is outside the EEA. Fourth, cut applications over to the gateway endpoint, one application at a time, keeping the old direct path available until each team confirms its requests succeed. Fifth, tighten model allowlists, provider restrictions and logging once traffic is stable, so that enforcement tightens after the inventory is accurate rather than before.
The gateway itself needs operational settings that protect its own secrets and availability. Keep the LITELLM_MASTER_KEY value, which must start with sk-, in a secret manager rather than in a configuration file or container image, and restrict who can read it. If more than one proxy instance runs, which most production rollouts do for availability, plan for Redis 7.0 or newer, since shared rate limits, router state and cache depend on it. Confirm with your platform team how the secret manager is integrated and which LiteLLM features need an enterprise license, such as SSO beyond the free user limit or team-level guardrails, before you promise those controls to a business owner. Use LiteLLM's production best practices as the checklist for this phase and test failover before the first production cutover.
What a GDPR-focused gateway scoping engagement covers
The scoping sequence turns a list of model providers into a written, enforceable gateway design, with each processor and transfer decision traced to a control and an evidence artifact. It ends with a fixed scope agreed in writing before any build work starts.
Inventory providers and confirm data flows
The client's team and DeployOpen list every application, team and script that calls a model today, along with each provider, endpoint region and the categories of personal data that may appear in prompts, files and outputs. Provider contracts, data processing terms and sub-processor lists are collected at the same time. The step closes when each flow has a named owner, a data category and a documented purpose, and any flow with unknown data content is flagged for follow-up.
Map processor duties to gateway controls
DeployOpen maps the processor requirements in Article 28 and the transfer rules in Chapter V to specific gateway capabilities, such as allowed provider lists, key scoping, logging and deletion handling. Each requirement is paired with the owner who will maintain it, whether that is the gateway configuration, the provider contract or the client's own policy. The step closes with a control matrix that the client's data protection officer reviews and signs off on.
Confirm the transfer basis for each provider
For every provider that may receive data outside the EEA, the client's legal team confirms which transfer safeguard applies, whether that is a Commission standard data protection clause set, an adequacy position or another instrument under Article 46. DeployOpen records the result against each provider in the inventory and marks any provider that lacks a confirmed basis as blocked by default. The step closes when no unapproved provider remains in the routing plan without a documented decision.
Design routing rules and model allowlists
DeployOpen designs the routing layer so that personal data categories reach only approved providers, using model allowlists per team, key restrictions and fallback paths that never cross to an unapproved endpoint. Failover behavior is tested on paper against each sensitive flow to confirm it cannot silently send data to a non-approved provider. The step closes with a routing specification that lists every allowed route and the rule that blocks the rest.
Define logging, retention and deletion
The client and DeployOpen agree what the gateway logs (metadata, prompts, outputs or none of these), where the logs are stored, who can read them and how long they are kept. The retention period is set by the client's own policy and legal review, and deletion or return of data at contract end is mapped to a concrete procedure. The step closes with a logging and retention standard that the gateway configuration implements and that auditors can trace.
Prepare the evidence pack
DeployOpen assembles the artifacts the client needs to show how processor and transfer obligations are met, including the provider inventory, the control matrix, the routing specification, configuration exports and the retention standard. The pack is organized so that the client can hand it to an internal auditor or supervisory authority without rebuilding it. The step closes when the client confirms the pack covers every control in the matrix. DeployOpen prepares this evidence but does not issue any audit or certification.
Agree fixed scope in writing before build
Scope, deliverables, acceptance checks and responsibilities for the client's legal, security and platform teams are written into a fixed-scope agreement before any build work begins. Items that depend on unconfirmed provider terms are listed as open assumptions with named owners. The step closes when both parties sign the scope document, which becomes the baseline for the build and for any change requests.
How DeployOpen scopes, deploys and supports a GDPR-controlled AI gateway
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For a GDPR-controlled gateway, that means mapping which data categories may reach which providers, then building the routing, key, logging and documentation controls that enforce those rules.
How we scope
- Inventory the applications, teams and data categories that will call models through the gateway.
- Map each provider and self-hosted model to its contract, processor role and transfer position before routing is designed.
- Agree deliverables, exclusions and timelines in writing, since most engagements are fixed-scope.
How we build
- Deploy the gateway, PostgreSQL and Redis in the client's infrastructure with per-team virtual keys and model allowlists.
- Configure routing so personal data classes can reach only approved endpoints, with failover limited to approved providers.
- Test blocked routes, key scoping and log content against the agreed policy before go-live.
How we hand over
- Document the provider register, routing rules, data classification mapping and change procedure for the client's records.
- Provide runbooks for adding a provider, rotating keys and reviewing sub-processor changes under the client's authorisation process.
- Deliver evidence for processor due diligence, such as configuration exports and test results, for the client's legal and privacy teams to review.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Review gateway upgrades and new provider onboarding against the documented routing and allowlist rules.
- Confirm with the client's counsel and data protection officer any transfer mechanism, contract clause or certification relied on for external endpoints.
