How a self-hosted AI gateway supports ISO 42001 implementation
An AI gateway produces evidence for three ISO/IEC 42001:2023 Annex A controls: A.10.3 Suppliers, A.4.4 Tooling resources and A.6.2.8 AI system recording of event logs. It does not produce a certificate, and no gateway can. ISO does not certify organizations; accredited external certification bodies do, and the organization decides which Annex A controls apply through its statement of applicability under clause 6.1.3, which must justify including or excluding each control. For an organization preparing an AI management system that calls model APIs from many applications, the gateway is one component alongside the AI policy, supplier assessment procedures, risk records and review meetings, and the auditor will look at how these fit together.
For A.10.3, the gateway gives you one list of every model provider that applications can reach. Each entry should link to the supplier assessment that checked alignment with your responsible AI approach, the contract terms and the owner who approved it. Enforce this in the gateway by allowing only approved provider entries in the model configuration, and keep the configuration under version control so changes leave a history. For A.4.4, record the gateway version, the LiteLLM or APISIX release you run, its database and cache dependencies, and the routing and guardrail settings as tooling documentation. Confirm current release details, such as the latest LiteLLM version, against the LiteLLM releases page before you write the record.
For A.6.2.8, decide with your AI governance owner in which life cycle phases event logging must be enabled. At a minimum this covers the phase when the AI system is in use, so the gateway's request logs, including model, key, team and timestamp, must be on for every production call and kept in storage you control. Confirm with your legal team how long logs must be retained, since the EU AI Act sets a six-month minimum for high-risk providers unless other law requires more, and check whether your use cases fall under that Act at all. Logging that depends on each application remembering to call a logger does not meet this control, which is why centralizing calls at the gateway matters.
Which ISO 42001 Annex A controls the gateway supports and how to configure it
This table maps three Annex A controls to what the gateway can record, what the organization must still document, and the configuration that produces the evidence. Read each row as a split of responsibility: the gateway enforces and records, while the policies, reviews and life cycle decisions remain with the organization. The main takeaway is that a gateway supplies strong evidence for A.10.3 and A.6.2.8 and a useful inventory for A.4.4, but it does not complete any of them on its own.
| Control and need | What the gateway supplies | Configuration and organizational work |
|---|---|---|
| A.10.3 Suppliers: a process ensuring supplied services align with responsible AI use | Enforcement point that only lets applications reach approved model providers and records each call against a named provider | Configure model allowlists per virtual key in LiteLLM, and restrict routes so no team can reach unapproved endpoints. The supplier review process, criteria and approval decisions stay with the organization |
| A.10.3 Suppliers: evidence of provider use over time | Spend and request records in PostgreSQL showing which provider and model served each request | Set retention for these records and export them to the supplier review file. Confirm with the vendor how PostgreSQL backups and retention policies are handled in your environment |
| A.4.4 Tooling resources: documented information about tools used by the AI system | Model and gateway configuration held as code, including provider list, routing rules and guardrail settings | Keep the gateway configuration under version control and link each model route to a documented AI system record. The organization writes the tooling description itself |
| A.4.4 Tooling resources: access to the tooling | Virtual keys scoped per team, application and model, with per-key budgets and rate limits | Map each key to an owner and an AI system entry. Use SSO for the admin UI; LiteLLM documents SSO for Google, Microsoft Entra ID, Okta and generic OIDC, with a license needed beyond the free user limit |
| A.6.2.8 Recording of event logs: determine life cycle phases where logging is enabled | Per-request logs capturing caller, key, model, timestamp and spend, enabled at the proxy | Decide and document the phases in which logging is on, at minimum while the system is in use. Record that decision in the statement of applicability |
| A.6.2.8 Recording of event logs: integrity and retention | Log records written to the organization's own PostgreSQL database rather than a vendor cloud | Define retention and access controls for log tables, and protect the LITELLM_MASTER_KEY in a secret manager. Confirm whether prompt content logging is enabled and how it is redacted |
| Alternative edge layer: central API policy and authentication | Apache APISIX with the openid-connect plugin can enforce identity checks and route traffic in front of model endpoints under Apache-2.0 | Use APISIX where a general API gateway already exists. Confirm that model-specific budgets and provider accounting are still provided by LiteLLM or another component, since APISIX alone does not replace per-key spend tracking |
Which open-source gateways fit an ISO 42001 evidence setup
Two open-source gateways cover most self-hosted AI gateway needs for an ISO/IEC 42001 evidence setup. The choice turns on whether the organization needs model-specific keys, budgets and call logs out of the box, or already runs an API gateway that it wants to extend to model traffic. Licensing and enterprise features decide which evidence is available without extra cost.
LiteLLM for model-level control
LiteLLM is a Python SDK and proxy server that calls more than 100 LLM providers in the OpenAI request format. It issues virtual keys with per-key, per-user and per-team budgets, restricts keys to named models and records spend, which gives an auditor a direct line from a model call to an accountable team. Its core is MIT licensed except the enterprise directory, so confirm which features sit behind the enterprise license before you design the evidence set.
LiteLLM enterprise features and evidence
SSO is free for up to 5 users in the admin UI from v1.76.0, and the enterprise license is needed beyond that. Audit logs, SCIM provisioning, organization and team RBAC and team-level guardrails and logging sit in the enterprise tier. If your A.6.2.8 event log or A.10.3 supplier records depend on audit logs or SCIM deprovisioning, budget for that license and confirm its terms with the vendor before the design is frozen.
LiteLLM scaling prerequisites
LiteLLM's production guide names PostgreSQL as the primary supported database for virtual keys and spend records. Once more than one proxy instance runs, it requires Redis 7.0 or newer for shared rate limits, router state and cache. Keep the master key in a secret manager, run one Uvicorn worker per pod on Kubernetes and batch spend writes to the database. Each of these settings produces or protects evidence, so document them as part of the tooling record.
Apache APISIX for existing API estates
Apache APISIX is an Apache-2.0 API gateway built on NGINX and etcd, with an AI gateway capability and more than 100 built-in plugins for authentication, traffic control and observability. It fits an organization that already runs an API gateway and wants model traffic governed by the same policy, plugin and audit path. Confirm that the AI plugins and logging you need are present in the version you deploy, because model-specific budgeting is not the default focus of the project.
APISIX identity and deployment modes
The openid-connect plugin works with Keycloak, Auth0, Microsoft Entra ID, Google and Okta and supports authorization code, client credentials, token introspection and PKCE flows. APISIX runs in traditional, decoupled or standalone mode. Standalone mode reads a YAML or JSON file and hot-reloads it every second, which gives a reviewable configuration file as the record of who may call which model. Decoupled mode suits larger estates with a separate data plane.
Choosing between the two
Choose LiteLLM when the main evidence need is model-specific: keys, budgets, model allowlists and spend records for each team. Choose APISIX when the organization already operates it and the priority is consistent identity, traffic policy and logging across all APIs, including model calls. Many teams that adopt APISIX still need model-level budgeting elsewhere. Test both against your supplier and event log requirements before selecting one.
What documented tooling resources look like in practice
Control A.4.4, Tooling resources, asks the organization to document information about the tooling used for the AI system. For a self-hosted AI gateway, the documentation is largely the gateway's own configuration and its surrounding component list, so the work is to capture those artifacts in a form an auditor can read. Start with a component register that names every tool in the request path: the gateway (LiteLLM or Apache APISIX), PostgreSQL for virtual keys and spend records, Redis when more than one proxy instance runs, and any guardrail or observability tools such as Langfuse. For each entry, record the exact version deployed, the source of the release (the GitHub release page or the vendor download page), the deployment date and the named owner. Pin versions from the release records rather than from memory, and keep the gateway configuration file and model inventory under version control so each change has an author and a date.
Licenses differ by component and belong in the same register, because the obligations that follow from them are different. LiteLLM is MIT licensed outside its enterprise directory, while anything under the enterprise directory uses the license in that folder, so the register should say which features in use depend on enterprise code. Langfuse is MIT licensed except its ee directories, which should be excluded from the deployed build or recorded as not in use. Arize Phoenix is under the Elastic License 2.0, which prohibits providing the software to third parties as a hosted or managed service, and n8n is under the Sustainable Use License with .ee files requiring an enterprise license. If the gateway feeds a workflow tool, its license belongs in the register too. Confirm each license against the file in the repository at the version you deploy, not against a summary page, because licenses can change between releases.
The register is only useful if someone owns it and checks it against what runs. Assign a named owner in the AI governance function to approve each new component or version, and have the platform team reconcile the register against the running cluster during each change review. The schedule for that reconciliation is a decision your organization sets, and your own AI management system policy should state it. Ask your implementation partner to show how the register is generated and where it is stored, and how the gateway configuration, the model inventory and the release records are linked, so that an assessor can trace a model call back to the exact tooling that served it.
Which evidence auditors ask for from the AI gateway
What evidence does an ISO 42001 auditor expect from a model provider supplier register?
The auditor expects a maintained register of every model provider the organization uses, plus a record that each provider was reviewed against the organization's responsible AI approach, which is the intent of control A.10.3 Suppliers. The gateway helps by being the single place where provider connections are defined, so the register can be exported from the configured providers in LiteLLM or APISIX rather than assembled from memory. The gateway does not decide whether a provider is acceptable. Your organization must still write the supplier review process, define the criteria (data handling, model change notices, exit options, incident contacts), and keep the signed approval records. Confirm with your certification body how they want those records structured before you build them.
How do I show which models each API key is allowed to call?
Export the key configuration from the gateway and keep dated copies as evidence of the allowed model list. In LiteLLM, virtual keys can be restricted to specific models, so the export shows the model scope per key, user and team. In APISIX, the equivalent evidence is the route and plugin configuration held in its configuration store, which you can export and version. Auditors look for three things: that the allowed list exists, that it is applied to every key, and that changes to it are approved. The approval workflow and the mapping of keys to owners are records your organization must maintain. Test a sample of keys to confirm the export matches what the gateway enforces.
Which budget and rate-limit settings should be documented for an AI gateway audit?
Document the budget and rate-limit settings as configuration records, with their owners and the reasons for each value. LiteLLM virtual keys support per-key, per-user and per-team budgets, TPM and RPM limits, temporary budget increases and model restrictions, so the current values can be exported and compared against the approved policy. Record who approved each limit, when it changed and who may request a temporary increase. These settings support the controls around resources and operational limits described in ISO/IEC 42001, but the policy that sets the numbers is an organizational document. Ask your implementation partner to include a scheduled export of these settings in the runbook.
What log samples prove which model received which request?
A log sample should show, for each model call, the timestamp, calling key or application, requested model, the provider and model that actually served it, token counts and any guardrail decision. This supports control A.6.2.8 AI system recording of event logs, which asks the organization to decide in which life cycle phases event recording is enabled, and at a minimum when the system is in use. The gateway generates these records, but the organization decides which fields are required and whether prompt content is stored. Keep a documented logging specification, pull periodic samples, and check that the records match the routing rules. Also confirm which fields your legal and privacy teams allow to be stored before you enable full prompt capture.
How long should gateway logs be kept, and who can access them?
Set a retention period in a written policy, then configure the database and log storage to match it and prove the configuration. The gateway stores request and spend records in PostgreSQL, so retention is applied through database housekeeping, archival to your own storage, and deletion jobs that you can demonstrate. The EU AI Act sets a minimum of six months for providers of high-risk systems to keep automatically generated logs unless other law requires longer, so confirm whether that applies to your system. Access control evidence includes the admin UI SSO configuration, role assignments and the list of people who can read raw prompts. LiteLLM Enterprise adds audit logs and organization and team RBAC, which should be assessed against your needs.
How do I record changes to gateway versions and configuration?
Keep change records that name the gateway version, the configuration diff, the reason, the tester and the approver for every change. Use infrastructure as code or versioned configuration files so that each deployed state can be traced to a commit. LiteLLM publishes releases on GitHub, and it maintains support for the four most recent stable minor versions for both open source and Enterprise deployments, which helps plan upgrade windows. APISIX releases are listed on its downloads page, with 3.19.0 published on September 28, 2026, and the page marks no release as long-term support, so plan your own support window. Change records are an organizational process, and an implementation partner can help document it, but the approvals must come from your staff.
What does DeployOpen prepare for an ISO 42001 evidence pack, and what stays with us?
DeployOpen can plan and implement the gateway in your infrastructure, configure provider connections, keys, budgets and logging to a written specification, and prepare a set of evidence exports and runbook entries that map to the relevant Annex A controls. The engagement is fixed-scope, so the evidence items, deliverables and timelines are agreed in writing before work starts. DeployOpen does not issue audit reports, attestations or certifications, and it does not decide conformance. Your organization keeps the AI policy, the supplier review and approval process, the statement of applicability under clause 6.1.3, risk decisions and internal audit. Ask the partner to state precisely which records they produce and which ones you must write.
Evidence the gateway produces for each control and what the organization still owes
This table maps each of three Annex A controls to the evidence a LiteLLM or APISIX gateway can generate, the component that produces it, and what the organization must still define. Read it as a list of inputs for an assessor conversation, not as proof that any control is met. The main takeaway is that the gateway supplies records, while supplier policy, tooling documentation and log governance remain the organization's responsibility.
| Control and evidence | Producing component | Confirm with the organization | Auditor question it answers |
|---|---|---|---|
| A.10.3 Suppliers: register of model providers and routes | LiteLLM model list and APISIX upstream definitions, exported as configuration under version control | Approved provider list, owner for each provider, review cycle and who approves new routes | Which model suppliers are in use, and how do they meet the organization's responsible AI approach? |
| A.10.3 Suppliers: provider access and allowlists | LiteLLM virtual keys restricted to specific models; APISIX routes with consumer and plugin rules | Which teams may call which providers, and the approval record behind each allowlist entry | How is access to external AI services limited to suppliers that were assessed? |
| A.10.3 Suppliers: change history for provider routing | Git history of gateway configuration and LiteLLM admin audit logs (audit logs are an Enterprise feature) | Retention period for change records and who may change routing rules | When was a supplier added or removed, and who authorized it? |
| A.4.4 Tooling resources: inventory of gateway components | Deployment manifests and a component list covering LiteLLM, APISIX, PostgreSQL, Redis and etcd where used | Versions in production, patch owner and the record of the approved release used | Which tools support the AI systems, and what does each one do? |
| A.4.4 Tooling resources: configuration baseline | Configuration files for routing, retries, cooldowns and guardrail settings stored outside the running service | Location of the secrets store and separation between development and production configuration | How is the tooling configured, and can the current setup be reproduced? |
| A.6.2.8 Event logs: request records per model call | LiteLLM spend and request logs in PostgreSQL, or APISIX access logs shipped to the organization's log store | Which fields are captured (model, team, key, timestamp), whether prompts are stored, and the retention period | Are events recorded automatically while the AI system is in use? |
| A.6.2.8 Event logs: log access and integrity | Log store access controls, log shipping configuration and periodic checks that records arrive | Who can read or delete logs, where copies sit, and how prompt content is protected | Who can access the event logs, and how is their completeness protected? |
Why the event logs must be retained and who owns them
Control A.6.2.8 asks you to decide where and when the AI system records event logs, and at a minimum while the system is in use. In practice, the gateway is one of the strongest sources for that evidence because every model call passes through it. Record which application, team and key made each call, which model and provider answered, the policy decisions taken (allowed, blocked, redacted, failed over) and the timestamps. The control does not set a retention period, so the decision on how long these records are kept belongs to you. The EU AI Act sets a stricter baseline only if your system is high-risk and in scope: Article 12(1) requires high-risk systems to technically allow automatic recording of events over their lifetime, and Article 19(1) requires providers to keep those logs for at least six months unless other law provides otherwise. Confirm with legal counsel whether you act as a provider or a deployer for each use case, because the retention duties differ.
Ownership is the decision most teams leave unresolved. The gateway team usually runs the log pipeline, but the business owner of each AI system, the compliance lead and the security function each need defined access and a defined retention rule. Write these down in the statement of applicability and the logging standard. Keep the log store under your control, for example in your own PostgreSQL or log platform, so that prompt content and metadata are not held only by a model provider's dashboard. Decide early whether full prompt text is logged or only metadata, since that choice drives both retention duties and data protection obligations, and confirm it with your privacy team.
Track ISO/IEC FDIS 24970, *Artificial intelligence: AI system logging*, which defines common capabilities, requirements and an information model for logging AI system events. ISO shows it at the FDIS ballot stage since 28 August 2026, so it is not yet a published standard. Review its final text when it is published and map your log fields against it before the audit. Retention periods, legal hold rules and deletion schedules are not set by ISO/IEC 42001 and should be confirmed with legal counsel, your records management policy and any sector rules that apply to you.
What the gateway alone does not satisfy
A gateway produces useful evidence for ISO/IEC 42001, but it sits inside a management system that needs supplier files, impact assessments, a statement of applicability and people records. The cards below list the items a gateway cannot produce on its own and what to check before an assessment.
Supplier due diligence and contract review
The gateway shows which model providers are called, but it does not show whether each provider was assessed before onboarding. For A.10.3, keep a file per provider covering its responsible AI commitments, data handling terms, subprocessors, incident notice and exit conditions. Check that every provider named in gateway configuration has a matching file and an approval date, and that contract terms cover the data the gateway sends.
AI impact assessment
Routing logs record model calls, not the effects those calls can have on people or groups. An impact assessment should describe intended use, foreseeable misuse, affected populations and harm scenarios for each AI system behind the gateway. ISO/IEC 42005:2025 gives guidance on this assessment. Check that each virtual key or application mapped to the gateway points to a documented assessment.
Statement of applicability
Clause 6.1.3 requires a statement of applicability that lists the Annex A controls the organization needs and justifies each inclusion or exclusion. A gateway configuration does not record those decisions. Confirm that the statement cites A.4.4, A.6.2.8 and A.10.3 with the evidence location for each, and that exclusions are justified in writing.
Competence and human resource records
The gateway does not show who can change routing rules, approve budgets or review guardrail blocks. Under the resources objective, the organization documents human resources alongside tooling. Keep training records, role descriptions and access reviews for administrators, and check that gateway admin roles match those records.
Application context and output decisions
Gateway logs capture requests, tokens, keys and responses at the API boundary. They usually do not capture which user action triggered the call, what the application did with the output, or whether a person overrode it. Confirm with the application team which decision points need their own event records, and check that request identifiers link gateway logs to application logs.
Enterprise license for audit features
Some features that auditors ask about sit behind a commercial license. LiteLLM's SSO is free for up to 5 users from v1.76.0, and SCIM, audit logs, organization and team RBAC and IP allowlisting require an Enterprise license. Confirm with the vendor which of these your audit scope needs and price them into the design before the assessment begins.
How a gateway evidence project moves from scope to audit readiness
The sequence turns a gateway into a documented set of ISO/IEC 42001 evidence: scoped controls, inventoried suppliers, configured logging and tooling records, reviewed internally and then handed to an independent certification body. Each phase ends with an artifact the next phase depends on.
Scope the Annex A controls in the statement of applicability
The organization, with its compliance lead and DeployOpen, decides which Annex A controls apply to the AI systems that use the gateway. The statement of applicability lists each necessary control and records why it is included or excluded, as clause 6.1.3 requires. Most gateway evidence lands in A.10.3 Suppliers, A.4.4 Tooling resources and A.6.2.8 AI system recording of event logs, so these are confirmed here. The step is done when the statement of applicability is approved and each control has a named owner.
Inventory model providers and consuming applications
Engineering teams list every model provider, self-hosted model endpoint and application that calls the gateway, including which teams own each one. Shadow access is the usual gap, so the inventory should also ask which applications still hold direct provider keys. The output is a register of providers, endpoints and applications with an owner and a data classification for each. The step is done when application owners have confirmed the list and the gaps are logged as remediation items.
Deploy the gateway with PostgreSQL and Redis
DeployOpen deploys the chosen gateway, such as LiteLLM, in the organization's own cloud account or data center with PostgreSQL as the database. Redis is added when more than one proxy instance runs, because shared rate limits and router state depend on it. Secrets such as the master key are held in a secret manager rather than in configuration files. The step is done when the deployment matches the architecture document and the health checks pass in every environment.
Configure keys, budgets and event logging
Virtual keys are created per team or application, with budgets, rate limits and model restrictions matched to the inventory from the earlier step. Request logging is enabled and its retention and access rules are written down, since these logs become the event records for A.6.2.8. The team confirms which life cycle phases are logged and why, following the organization's own determination. The step is done when a test call from each application produces a log entry with the expected key, model and budget attributes.
Write the supplier and tooling records
The team writes a supplier record for each model provider, covering the services it provides, the data it may receive, the responsible AI commitments the organization requires for A.10.3, and the review cadence. A tooling record for the gateway and its supporting services documents the software, versions, configuration baseline and owners, as A.4.4 asks. Each record links to the register from the inventory step. The step is done when the records are signed off by the owners named in the statement of applicability.
Run an internal evidence review
Someone who did not build the setup samples evidence against each in-scope control. They check that the statement of applicability matches the running configuration, that logs exist for sampled calls, and that the supplier and tooling records are current. Gaps are recorded with an owner and a closure check, and the review repeats until none remain open. The step is done when the internal review report shows every in-scope control with evidence or a documented exception.
Hand the evidence package to the certification body
The organization assembles the statement of applicability, architecture document, inventory, supplier and tooling records, sampled logs and review report into one package. It then engages an independent certification body, since ISO does not certify organizations and DeployOpen does not issue audit reports. DeployOpen can support questions about the technical evidence, but the auditor decides what is sufficient. The step is done when the certification body confirms the package scope and begins its own assessment.
Questions buyers ask before hiring help for ISO 42001 gateway evidence
Does a self-hosted AI gateway give us ISO/IEC 42001 certification?
No. A gateway produces technical evidence that supports parts of an AI management system, but it does not certify anything. ISO does not certify organizations; external certification bodies do, and those bodies work to ISO/IEC 42006:2025 on top of ISO/IEC 17021-1. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make that determination. Ask any partner who claims otherwise to show which body would certify the work.
What drives the cost of gateway work for ISO 42001 evidence?
The main drivers are scope, the number of model providers and applications behind the gateway, licensing, and integration with identity and logging. Each additional provider needs its own supplier record and review. Each application may need its own virtual keys, budgets and log mapping. Enterprise features such as SSO beyond the free user limit, audit logs and SCIM are licensed separately, so ask which ones your design requires. Identity and logging integration often takes the most effort. Costs split into one-time work (design, configuration, documentation, evidence mapping) and recurring work (upgrades, log review, supplier reviews). DeployOpen does not publish prices. Fees follow from a written scope, so ask for a quote that lists each item and its recurring component.
How long does an ISO 42001 gateway engagement take?
The timeline depends on the agreed scope, the number of providers and applications, and how quickly your teams can make decisions and supply access. No duration applies to every organization, so confirm the schedule in the written scope before work starts. Ask the partner to break the timeline into design, build, evidence collection and handover. Also ask which items depend on your teams, such as identity provider access, network approvals and policy sign-off. Independent assessment timing is set by the auditor or certification body, not by the implementation work.
What does our team need to provide for the gateway work?
Your organization must name owners for the work. Typically this includes an owner for the AI policy, who sets approved uses and model rules, a supplier review owner, who approves model providers and reviews their terms, and a log owner, who decides retention and reviews event records. Engineering owners must also provide access to the gateway environment, the identity provider and the logging store. Without named owners, the evidence will describe a system that nobody reviews. Ask the partner to list these roles in the scope document with the decisions each one must make.
Can our own team set up ISO 42001 gateway evidence without a partner?
Often yes, if you have engineers who can configure and operate the gateway and staff who understand the management system clauses and Annex A controls. The work is not only technical. You must decide which controls apply, document the statement of applicability, define supplier criteria and keep records over time. Many teams underestimate the documentation and review cadence. A partner can help with configuration, hardening, log mapping and documentation, while your team keeps ownership of policy decisions. Be clear about which parts you will run yourselves and which the partner will deliver.
How does the partner handle gateway configuration and logging?
A typical engagement covers the gateway's routing, virtual keys, budgets, guardrail settings, log destinations and retention. For LiteLLM, that includes a PostgreSQL database for virtual keys and spend records, and Redis once more than one proxy instance runs. For Apache APISIX, it includes the deployment mode, the plugins used for authentication and logging, and how configuration is stored. Ask the partner to show how each log field maps to the AI system event records you need, where the logs are stored, who can read them and how long they are kept. Confirm how the partner tests that logs are complete after upgrades.
What should we check in a partner's proposal before signing?
Check that the proposal lists the controls in scope, the statement of applicability inputs, the supplier and tooling records to be produced, and the log fields and retention settings. It should name which features need a commercial license, who maintains the platform after handover and what recurs after go-live. Confirm that the partner does not claim certification and that fees come from a written, fixed scope. Ask how changes to scope are priced and approved. A clear list of client responsibilities is a strong sign of a realistic plan.
How DeployOpen scopes, delivers and supports AI gateway evidence
DeployOpen plans and implements self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For an AI gateway meant to produce ISO/IEC 42001 evidence, that means agreeing in writing which gateway records, supplier reviews and tooling documents will exist, then building and documenting them so an assessor can trace each one to a control.
How we scope
- Written scope lists which model providers and self-hosted models the gateway will route to.
- Scope names the Annex A controls the evidence targets, including A.10.3, A.4.4 and A.6.2.8.
- Scope states what the client keeps for the statement of applicability and what remains with the client.
How we build
- Configure LiteLLM or APISIX with virtual keys, model allowlists and per-team budgets matching the documented inventory.
- Enable structured logging of model calls to client-controlled storage, with retention set by the client's policy.
- Test routing restrictions, key revocation and log completeness, and record the results as evidence.
How we hand over
- Deliver tooling resource records covering each gateway component, version, license and configuration baseline.
- Provide a supplier review template for each model provider, with fields for data handling and approval status.
- Document log schemas, access controls and retention settings so the client's auditors can test them directly.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover version upgrades of the gateway, such as LiteLLM releases, with regression checks on logging and routing.
- Support reviews can refresh the supplier records and tooling documentation when providers or models change.
