Self-hosted AI gateway for EU AI Act record-keeping: what the Act asks for
A gateway that logs every model call can support the automatic logging the EU AI Act asks of high-risk systems, and it can keep those logs under the organization's control. It does not discharge the duties themselves. Article 12(1) requires high-risk AI systems to technically allow automatic recording of events over the lifetime of the system, and the provider and deployer obligations sit with the organization that places or uses the system. The gateway is one technical measure within that picture, so the first decision is whether each AI system in scope is high risk at all, since the Act's Annex III rules and its transparency obligations lead to different records.
The high-risk rules in Chapter III, Sections 1 to 3, now apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I product systems, following the 2026 amendment in Regulation (EU) 2026/1744. Those dates moved from 2 August 2026 and 2 August 2027. Article 19 requires providers to keep automatically generated logs for at least six months unless other Union or national law says otherwise, and Article 26(6) imposes the same six-month floor on deployers for logs under their control. A practical reading is that the gateway's retention settings, the database that stores request metadata, and the export path to the organization's SIEM must all be designed for a retention period set by the intended purpose and by sector law, not by a default. Confirm retention with counsel and the system's conformity file, and confirm which Article 12(2) events (risk situations and substantial modifications) the application itself must also record.
DeployOpen plans and implements the gateway, its logging schema, retention and access controls, and prepares the evidence an assessor would ask to see. DeployOpen does not issue audit reports, attestations or certifications, and conformity assessment under Annex VI is carried out by the provider's own internal control process or by a notified body where Article 43 requires one. Before scoping, ask your legal and compliance team which systems are high risk, who is the provider and who is the deployer for each, and whether the gateway will see the input data needed to satisfy Article 12(3) for any remote biometric use. The AI Act Article 12 text and the Article 19 text are the natural starting points for that review.
Which AI Act requirements a gateway log can serve, and how to configure it
This table maps the AI Act logging, retention, oversight and monitoring duties to what the gateway must capture and the LiteLLM or APISIX setting that produces it. Read each row as a split: the gateway produces the technical record, while the provider or deployer still owns the policy, the human oversight process and the incident decisions. The main takeaway is that a gateway log is strong evidence for the event trail but cannot, on its own, satisfy the organizational duties.
| Requirement | What the gateway must capture and the setting that produces it | Where the gateway cannot satisfy it alone |
|---|---|---|
| Article 12(1): automatic recording of events over the system lifetime | Timestamp, model, route, virtual key, team, request and response reference and guardrail decision per call. LiteLLM: PostgreSQL-backed spend and key logs, with callbacks to self-hosted log storage. APISIX: access and plugin logs shipped to self-hosted storage. | Only covers calls that pass through the gateway. Applications that call a model provider directly leave no record. Confirm that network egress is blocked for other paths. |
| Article 12(2): events relevant to risk, substantial modification and post-market monitoring | Model version or deployment identifier, configuration changes to routes, keys and guardrails, and error or fallback events. Keep an audit trail of admin changes. LiteLLM audit logs are an Enterprise feature; confirm current scope with the vendor. | The gateway cannot decide what counts as a substantial modification. That judgment belongs to the provider's change process and quality management system. |
| Article 12(3): fields for remote biometric identification (Annex III point 1(a)), where relevant | Start and end time of each use, reference database checked, input data leading to a match and identity of the verifiers. Only applies if the system is in scope. | Most gateway deployments will not carry this data. A biometric matching workflow needs its own records, and the gateway usually only routes the calls. |
| Article 19 and Article 26(6): logs kept under the organization's control for at least six months | Retention policy in PostgreSQL or object storage that you run, with backups and a documented deletion schedule. Keep LITELLM_MASTER_KEY and database credentials in a secret manager. Batching spend updates every 60 seconds at scale is a documented LiteLLM practice. | Six months is the minimum set by the Act unless other Union or national law requires longer. Confirm the period with legal counsel. Gateway defaults alone do not set retention. |
| Article 26(1) and (2): use per instructions for use and competent human oversight | Tag each route with the system it serves, its instructions for use reference and an approved owner. Use key scoping (restricting keys to specific models) and team roles so only authorized staff can change routing. | The gateway can enforce allowed models and users. It cannot train staff, assign oversight roles or prove competence. Those are organizational and HR records. |
| Article 26(5): monitoring, suspending use and reporting incidents to the provider first | Alerts on guardrail blocks, error spikes, unusual spend or output patterns, plus a kill switch that disables a route or key. Export events to a SIEM you operate. Keep the incident timeline linked to log IDs. | Detecting a risk and deciding to suspend or report depends on people and procedures. The gateway provides signals and the ability to stop traffic, not the legal assessment. |
Which open-source components fit the logging layer
Record-keeping under the EU AI Act needs two things: a gateway that sees every model call and a store that keeps those records under your control for the required period. The components below cover the gateway, the API layer alternative and the trace stores, each with the decision it supports and the limit to check before you commit.
LiteLLM as the logging gateway
LiteLLM sits between applications and model providers, so every call passes through one point where it can be recorded with its key, user and team. PostgreSQL is the primary supported database, and Redis 7.0 or newer becomes necessary once more than one proxy instance runs. The limit is licensing: audit logs, SSO beyond five users and team-level logging sit in the Enterprise license, so confirm the feature list against your record-keeping design before you assume the open-source build covers it.
Apache APISIX as the API layer
Apache APISIX fits where an existing API estate already runs on it, because the AI gateway functions can sit in the same data plane as current traffic. It is licensed under Apache-2.0 and offers traditional, decoupled and standalone deployment modes, so you can keep configuration in files under version control. The limit is that APISIX does not supply the AI-specific records by default; you must confirm which AI plugins and log fields meet your retention design.
OpenID Connect for access records
The openid-connect plugin in APISIX ties each logged call to a verified identity from Keycloak, Microsoft Entra ID, Okta or another provider, using authorization code, client credentials or token introspection flows. Records that name an individual or service account are more useful to a deployer reviewing operation under Article 26. The limit is that identity mapping must be designed deliberately, since shared API keys produce logs that cannot show who acted.
Langfuse as a trace store
Langfuse records prompts, outputs, traces and costs for LLM applications and can run in your own storage. It is MIT licensed except for its ee directories, so the core can be deployed without a commercial agreement. The limit is that trace records do not replace the gateway log: confirm which events each store holds, how long each keeps them, and who controls deletion before you treat either as the record under Article 26(6).
Arize Phoenix and hosting limits
Arize Phoenix offers LLM tracing and evaluation and can be self-hosted inside your own environment. It is licensed under the Elastic License 2.0, which prohibits providing the software to third parties as a hosted or managed service. If DeployOpen or another partner operates Phoenix for your organization, that arrangement needs legal review before deployment; running it yourself in your own accounts avoids the restriction, but confirm the terms with counsel.
Retention and control of logs
Article 19 and Article 26(6) require logs under the provider's or deployer's control to be kept for at least six months unless other law sets a longer period. Choose one system of record for model-call events, export it to storage you administer, and set retention in writing. The limit is that the open-source components do not decide retention for you; the period, legal hold process and deletion rules come from your own policy and applicable law.
How a gateway log chain supports the AI Act duties
A gateway log chain only supports AI Act record-keeping if every model call follows the same path. In a typical design, the application sends an OpenAI-format request to the gateway, which first authenticates the caller with a virtual key. The gateway then applies the key's model allowlist and budget, routes the request to a model provider or a self-hosted model using the configured routing strategy, runs input and output guardrail checks, returns the response, and writes a log record to the log store. Each step is a place where a record can be created, so the design should name which fields are written at each step, such as key identifier, team, application, model, routing decision, guardrail outcome, token counts and timestamps. Article 12(1) requires high-risk systems to technically allow automatic recording of events over their lifetime, so the reader should confirm with the implementation partner exactly which events the chosen gateway version logs by default and which need custom callbacks.
The gateway only sees every call if every application is forced through it. Direct calls from applications to provider APIs, developer laptops with personal keys, and batch jobs that bypass the proxy all create gaps that no log can close. Network egress rules that allow outbound traffic to model endpoints only from the gateway, and provider keys held only in the gateway's secret manager, are the practical controls. Keys tied to teams and applications are what let the log answer who used which system: a record that carries a team-scoped or application-scoped virtual key identifies the deploying organization's unit, not an anonymous API caller. LiteLLM supports per-key, per-user and per-team budgets and model restrictions on virtual keys, but mapping those keys to named high-risk systems is a governance decision that someone must own and document.
Article 19 and Article 26(6) require providers and deployers to keep logs under their control for at least six months, unless other Union or national law provides a longer or different period. The storage tier, backups and deletion rules therefore have to be designed for that period from the start. LiteLLM stores virtual key and spend data in PostgreSQL, and the production guide recommends Redis once more than one proxy instance runs, but Redis state is not a retention store. The reader should confirm where full request and response payloads go, whether the log store is in the organization's own accounts or data center, how backups are encrypted and restored, and how deletion jobs avoid removing records still inside the retention window. Retention periods for other applicable laws, such as sector or data protection rules, should be set by counsel and checked against the six-month minimum, which is the floor rather than the target.
What evidence auditors and market surveillance staff ask for
What log schema and field list do auditors expect from an AI gateway?
Auditors expect a documented, versioned log schema that states which fields are recorded for every model call, such as timestamp, route, calling application, virtual key or team identifier, model and provider, request and response identifiers, token counts, cost, guardrail decisions and error states. The gateway produces the raw records, typically through its logging callbacks into a store such as PostgreSQL or an external observability tool. Your organization must decide which fields are needed to reconstruct the system's operation, document the schema, and confirm with your assessors whether prompt and output content is captured, since that choice affects personal data handling under GDPR. Confirm the exact field names and the logging options in the version you run.
How do you prove automatic recording is switched on for every route to a high-risk system?
The evidence is a configuration export showing that logging is enabled on every route, model and provider that serves the high-risk use case, plus a test showing that calls through each route produce log records. Article 12(1) requires the system to technically allow automatic recording of events, so the gateway configuration itself is the primary artifact. Keep the exported configuration under version control, run a scripted check that compares the list of routes against the list of routes with logging enabled, and retain the results. Ask your assessors whether they want a sample of recorded calls traced back to the source request.
What retention settings and deletion records do you need for the six-month minimum?
You need the configured retention period for each log store, the justification for any shorter period, and records showing that deletion runs only after the minimum has passed. Article 19 and Article 26(6) require providers and deployers to keep logs for a period appropriate to the intended purpose of at least six months, unless other Union or national law provides otherwise. Document the retention rule, the scheduled job or database policy that enforces it, and the logs of each purge run. Where the gateway keeps logs in PostgreSQL, the retention job and its audit output sit outside the gateway itself, so they must be tested and evidenced separately. Confirm with legal counsel how longer periods required by other law apply.
Who can read or change the log store, and how is that access recorded?
Auditors look for role-based access to the log store, documented approvals for each access group, and an access log of the people and service accounts that read or export records. The gateway's admin access, the database credentials and any log export pipeline each need separate controls. Store the database secrets in a secret manager, restrict read access to named roles, and keep the access review records. LiteLLM documents that its master key should be kept in a secret manager, and its Enterprise features add audit logs and organization and team RBAC, which you should confirm for your license and version. Review the evidence with your security team before any assessment.
What change records show how routing and guardrail configuration was controlled?
Change records are the version history, reviews and approvals for every routing rule, model allowlist, budget, key policy and guardrail setting. Keep the gateway configuration as code in a repository, require a reviewed merge for each change, and link each change to a ticket that states the reason and the risk assessment. Record the deployed version of the gateway itself, such as the LiteLLM or APISIX release, and any upgrade test results. Auditors use these records to confirm that the system in operation matches the documented instructions for use and that changes to a high-risk system were controlled. Note that the evidence must be reviewed by your organization and your assessors before it is relied on.
How do you show that logs were used for monitoring and incident reporting under Article 26(5)?
Deployers must monitor operation, suspend use where the system presents a risk, and report serious incidents to the provider first. The evidence is the monitoring procedure, alert rules tied to the gateway logs, dashboards or reports reviewed at defined intervals, and records of each alert, investigation and escalation to the provider or authority. Keep the query used to review logs, the reviewer's name and the outcome. If no incident occurred, keep the review records showing the check was performed. Confirm the reporting chain and timelines with your legal and compliance team, since the Act and national authorities set the details.
Does DeployOpen issue the evidence or certify that our gateway complies?
No. DeployOpen plans, implements, hardens, documents and supports self-hosted platforms, and prepares systems, controls and evidence for compliance assessments. Independent auditors and certification bodies issue any audit report or attestation, and market surveillance authorities make their own determinations. A fixed-scope engagement can cover the log schema, retention configuration, access controls, change records and monitoring runbooks, and it is priced from a written scope rather than a published list. Ask any partner to show how each evidence item is produced, who signs it off, and where it is stored in your environment.
What the gateway alone does not satisfy
A gateway records model calls, but the Act asks for more than call records. The cards below cover the classification, oversight, notification and provider duties that sit outside the gateway and need their own owners, evidence and dates.
Deciding which systems are high-risk
The gateway only sees traffic, so it cannot tell whether an application falls under Annex III or Article 6. Each use case that reaches a model needs a documented classification decision, including whether an exemption is claimed. Ask your legal and compliance team to record that decision per system and link it to the gateway key or team that serves it. An unclassified application that calls the gateway still needs a classification.
Instructions for use and human oversight
Article 26(1) requires deployers to use high-risk systems according to the provider's instructions for use, through technical and organizational measures. Article 26(2) requires human oversight to be assigned to people with the necessary competence, training, authority and support. A gateway can enforce model allowlists and rate limits, but it cannot write procedures or train reviewers. Confirm who signs off on each high-risk use and how overrides are recorded.
Informing workers and affected people
Article 26(7) requires employers to inform workers' representatives and affected workers before a high-risk system is used at the workplace. Article 26(11) requires deployers of Annex III systems that make or assist decisions about people to inform those people. These notices are documents and communications, so the gateway can only show which systems were live and when. Confirm the notice text, the recipients and the date each notice was issued.
Application dates and further amendments
As amended in 2026, the high-risk rules in Chapter III Sections 1 to 3 apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I product systems. Regulation (EU) 2026/1744 changed these dates from 2 August 2026 and 2 August 2027. Retention plans should be tied to these dates, and counsel should confirm whether further amendments or harmonised standards change the obligations before rollout.
Provider duties for in-house systems
If the organization builds its own AI system and places it on the market or puts it into service under its name, it may hold provider duties, not only deployer duties. Those duties include technical documentation, a quality management system and log retention under Article 19. The gateway may be one component of that system, but the documentation and conformity assessment are separate work. Ask whether any internal system would make the organization a provider before assuming deployer obligations only.
Logs for systems outside the gateway
Any high-risk system that calls a model directly, runs a local model without the gateway, or uses vendor-embedded AI will leave no gateway record. Article 12 still applies to the system, so its events must be recorded by its own logging. Build an inventory of every AI system in use and mark which ones route through the gateway. Confirm each system's log source, storage location and retention before the gap becomes an audit finding.
Recording calls, not outcomes
The gateway records that a call happened, with its model, key, time and token counts, and can store prompts and responses if configured. It does not record the decision a person took, whether the output was relied upon, or any harm that followed. Article 12(2) asks for events relevant to risk and substantial modification, which requires application-level records. Confirm which fields your application writes alongside gateway logs so that decisions can be traced end to end.
How the logging layer is rolled out in order
The sequence moves from knowing which AI calls exist to proving that the gateway records them completely and that the records are kept under the organization's control. Each step closes with a check the reader can inspect. Timing depends on scope and is agreed in the written scope before work starts.
Inventory AI systems and model calls
DeployOpen works with the client's application owners and platform team to list every application that calls a model, including direct calls to provider APIs, embedded vendor features and internal tools. For each one the team records the business purpose, the models and providers used, the data categories involved and the people who use it. The step is done when the inventory covers every known call path and the client has signed off on it, because no later control can record a call that was never listed.
Classify which systems may be high-risk
Using the inventory, the client's legal and compliance leads decide which systems could fall under the Annex III high-risk categories, and which are likely out of scope or only subject to transparency duties. DeployOpen prepares the analysis inputs but does not make the legal determination. The output is a written classification per system with the reasoning and the owner who approved it. Confirm with counsel the current application dates, since the 2026 amendment changed when the high-risk rules apply.
Route all model traffic through the gateway
The platform team configures the gateway, such as LiteLLM or Apache APISIX, as the only path to approved model providers and self-hosted models. Network egress rules and provider credentials are moved so that applications cannot reach a provider directly. The check is a test from each application segment showing that direct provider calls fail and that gateway calls succeed. Without this step, the log would cover only the calls that happened to pass through it.
Configure virtual keys and the log schema
DeployOpen configures virtual keys per application, team or user, with model restrictions and budgets, so every call can be tied to an identifiable system and owner. The team defines the fields each event must carry, such as timestamp, system identifier, key owner, model, provider, input and output references, token counts and any guardrail decision. The output is a written schema and a test call that produces a complete record. Confirm with the gateway vendor which fields the open-source release captures and which need an enterprise license.
Set retention and access controls on the store
The logs are written to a self-hosted PostgreSQL or other store in the client's infrastructure. Retention is set to the period the organization's compliance lead determines, which must meet the at-least-six-months minimum in Article 19 and Article 26(6) unless other law requires longer. Access is limited to named roles, changes to log tables are audited, and backups are encrypted and kept inside the same boundary. The check is an access review and a restore test showing that logs can be read by authorized staff only.
Test log completeness on sampled calls
DeployOpen selects a sample of calls across systems, including failed calls, fallbacks, streaming responses and calls made with keys that were later rotated. For each sampled call the team compares the provider-side request count, the gateway record and the application's own event, and checks that every required field is present. Gaps are logged as defects with an owner and fixed before sign-off. The step closes when the sample shows no unexplained missing events and the known exceptions are documented.
Document the evidence pack
DeployOpen assembles the evidence pack: the system inventory and classification, gateway configuration exports, the log schema, retention and access settings, test results, and the procedure for monitoring and incident escalation. The pack is organized by the obligations it supports, including automatic logging under Article 12 and deployer log control under Article 26. DeployOpen prepares the evidence but does not issue assessments or attestations; the client's internal audit, the relevant authority or an independent auditor decides what it is sufficient to show.
Questions buyers ask about EU AI Act logging with a gateway
Does a self-hosted AI gateway alone satisfy Article 12 of the EU AI Act?
No. A gateway can technically allow automatic recording of events, which is what Article 12(1) asks of high-risk systems, but the regulation applies to the system as a whole. The gateway captures model calls, keys, routes and budgets. It does not capture the application's purpose, the inputs your staff use outside the gateway, the human oversight steps or the events that matter under Article 12(2). Article 12(1) requires automatic recording over the lifetime of the system, and Article 12(2) sets the event types to target. Confirm with your legal team which events your system must record, then decide what the gateway covers and what the application must add.
What drives the cost and effort of EU AI Act logging with a gateway?
The main drivers are the number of applications and routes that call models, whether you need enterprise features, how you design log storage and retention, and how much classification work the legal team must do first. Each application that calls a model adds mapping, testing and log fields. LiteLLM's SSO and audit log features beyond its free limit require an Enterprise license, so confirm the license need before you scope. Storage cost recurs and grows with request volume and retention. Ask any partner for a written quote that separates one-time build work from ongoing hosting, licensing, retention and support.
How long does it take to set up logging through a gateway?
The duration depends on the number of systems in scope, how many model providers and routes you already run, and how quickly the organization decides its classification and log fields. Teams with one gateway and a small number of applications can move faster than teams that must trace calls from many tools. No fixed timeline applies to every organization. Ask a partner for a written schedule tied to the agreed scope, and ask which dependencies sit with your team, such as system owner sign-off, access to identity providers and storage approval.
What must our organization provide before a partner starts the work?
You must provide named system owners, a current inventory of AI systems and the model calls each one makes, and a documented legal classification of whether each system is high risk under the Act. Without these, the gateway logs calls that nobody can map to a regulated use. Compliance and legal teams should confirm which high-risk rules apply and when, because Regulation (EU) 2026/1744 changed the application dates for Annex III systems to 2 December 2027. Also provide access to your identity provider, your PostgreSQL and Redis environment and the storage location where logs must stay.
Can our internal teams set up AI gateway logging themselves?
Often yes for the technical gateway work, if your platform team already runs Kubernetes, PostgreSQL, Redis and identity integration. Internal teams usually struggle with the parts that need legal and governance judgment: classification, retention periods, what counts as a relevant event and evidence packaging. LiteLLM's production guide names PostgreSQL as the primary supported database and recommends Redis 7.0 or newer once more than one proxy instance runs, which shows the operational footprint. Assess your team's skills against that list, then decide which parts to keep in house and which to contract.
Which Article 26 duties stay with us as the deployer?
As a deployer, you must use high-risk systems according to the instructions for use, through technical and organizational measures, and assign human oversight to people with the necessary competence, training, authority and support (Article 26(1) and (2)). You must also keep logs under your control for at least six months unless other Union or national law provides otherwise (Article 26(6)). You must monitor operation, suspend use and inform the provider and authority if the system presents a risk, and report serious incidents to the provider first (Article 26(5)). Workers and affected people must be informed where the Act requires it (Article 26(7) and (11)). A gateway supports several of these duties but cannot assign oversight or make those decisions for you.
Does DeployOpen issue an EU AI Act certificate for our gateway logging?
No. DeployOpen plans, implements, hardens, documents and supports self-hosted platforms, and it prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. For high-risk systems, the conformity assessment route depends on the system's category. Most Annex III systems use internal control under Annex VI, while notified bodies apply to some biometric systems and Annex I products (Article 43). Ask your legal and compliance team which route applies before you plan the evidence pack.
Build, partner or hosted logging: which fits the retention duty
The first decision is who holds the records. Article 26(6) requires deployers to keep logs under their control for at least six months, and Article 19 places a similar retention duty on providers. A hosted gateway that stores prompts, responses and metadata in the vendor's environment moves custody of those records outside your infrastructure, and you then depend on that vendor for retention periods, export formats, access during an investigation and deletion. Self-hosting keeps custody in your hands. The three options differ mainly in who builds, runs and pays for that custody: your own platform team with the open-source gateway and storage, an implementation partner under a fixed written scope, or a hosted plan priced by logged requests. Building in-house means your staff own the gateway, the PostgreSQL log store, backups, access reviews and the retention job. The recurring costs are people time for operations and upgrades, infrastructure for the database and storage, and any enterprise license you need. LiteLLM's enterprise features, including audit logs, SSO beyond the free limit and team-level logging, carry a license, and the free SSO allowance applies only up to 5 users, so confirm with the vendor which features your design depends on before you budget. A partner fee for a fixed-scope build is one-time for design and configuration, but the storage and operations still recur and remain yours. Ask any partner to state in writing where logs are written, who holds the keys and how the six-month period is enforced.
A hosted option can shorten the first deployment, but it adds recurring fees that scale with request volume, and it needs contractual proof that the vendor retains logs for the full period and releases them on request. Ask for the storage location, subprocessors, retention settings, export method and the procedure for deleting records after the period ends. If you choose hosted logging, you still need your own copy of the records to answer an authority or a provider's request, so the cost of an export path and its testing should appear in the comparison. Whichever option you pick, confirm the retention period with counsel, since Article 26(6) allows other Union or national law to set a different period. The AI Act Article 26 text is the starting point for that review.
How DeployOpen scopes, deploys and documents the logging layer
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For EU AI Act record-keeping, that means defining which model calls and events the gateway must log, configuring the logging layer in your environment, and preparing the evidence your compliance and legal teams need for their own assessment.
How we scope
- The written scope lists which AI systems, applications and model routes pass through the gateway and which fall under the logging requirements.
- We document the log fields, retention periods and access rules agreed with your legal and compliance owners before build starts.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins, and quotes follow from that scope.
How we build
- We deploy the gateway, its PostgreSQL and Redis dependencies and the log storage in your cloud accounts, data centers or air-gapped network.
- We configure virtual keys, team identities and model allowlists so every call is attributable to a system, team and user.
- We test that log records are written for each model call, including failed and fallback requests, and that retention and access controls behave as documented.
How we hand over
- You receive configuration documentation, a log field reference and a record of which logs are kept under your control and for how long.
- We provide runbooks for log export, retention changes, key rotation and investigating a specific model call on request.
- Handover includes a walkthrough with your security, compliance and platform teams so the owners of each log source are named.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, covering gateway version changes and logging regressions.
- We can re-test the logging layer after a model provider, route or high-risk system is added to the gateway.
- DeployOpen prepares systems, controls and evidence for compliance assessments, while independent auditors and certification bodies issue any formal outcome.
