Product
An AI gateway for controls you can explain.
Kayrix is designed to sit between connected AI applications and configured model providers. It brings together input privacy handling, provider selection controls and transaction evidence, rather than leaving those responsibilities scattered across individual clients.
The request path, step by step
Connect the client. A supported application or configured OpenWebUI instance uses the Kayrix endpoint instead of contacting the model provider directly.
Apply the privacy policy. Kayrix checks supported content against configured detection and handling rules. Detected identifiers can be transformed according to the applicable policy. Requests that cannot continue under supported controls may be refused.
Forward to the configured provider. An allowed request is dispatched through the selected provider configuration. Only request types and integrations validated for the pilot are included.
Review the recorded transaction. The evidence path associates processing metadata with policy and provider information. Audit review is separate from the chat interface; it is not a second store of the complete conversation.
Return the response. The provider response returns through the gateway to the connected client, subject to the supported response contract and configured error handling.
Architecture explanation
REQUEST / RESPONSE PATH
Client or configured OpenWebUI
-> Kayrix request intake
-> configured PII / policy controls
-> provider dispatch
-> local or cloud provider
-> response through Kayrix to the client
SEPARATE EVIDENCE PATH
Kayrix recorded processing and transaction outcomes
-> scoped metadata and digests
-> Evidence / Audit
-> authorized DPO / IT reviewThe evidence path is separate from the provider payload and from the client response path. It describes scoped records emitted by Kayrix for authorized review.
Define compatibility before the pilot
An API-compatible endpoint is not a promise that every client feature is supported. Streaming, tools, document types, uploads and response handling must be included explicitly in the compatibility scope before use.
Evaluate the workflow, not a feature checklist.
A useful pilot checks normal requests, rejected requests, provider errors and the evidence that remains available afterwards. An error returned to the client does not, by itself, prove that no provider request was sent.