Skip to main content

​
Glossary

Organization: the tenant unit inside the platform. All data belongs to exactly one organization, and access is checked against the caller’s organization on every request. Evaluation: a run that scores your AI product’s output against criteria you define, usually with a language model acting as the judge. Generation: producing test data: synthetic user scenarios, golden datasets, adversarial (red-teaming) test cases. Worker: a service that processes evaluation and generation jobs asynchronously, pulling them from a queue. This is the compute-heavy part of the platform. Worker pool: a set of workers. Shared pools process every organization’s jobs; dedicated pools are reserved for one organization. LLM gateway: the single outbound choke point for model calls. Handles provider routing, fallback, retries and quotas, so providers and models can be changed without touching the services. Helm chart: the packaging format for a Kubernetes application. Galtea publishes versioned charts you install with helm install or through a GitOps controller. ArgoCD: a GitOps controller that keeps a cluster in sync with configuration stored in git. Galtea uses it internally; it is optional for a self-hosted install. KEDA: a Kubernetes component that scales workloads on an external signal, in Galtea’s case queue depth. Optional. WireGuard: the encryption protocol used for the VPN tunnels in a private tenant. NetBird: the open-source overlay network, built on WireGuard, used to give private access to a tenant. Its control plane coordinates peers; it never carries application traffic. Routing peer: a VPN peer that advertises whole network ranges, so a site reaches the tenant without installing a client on every machine. Egress control layer: the component all outbound traffic passes through in a private tenant, enforcing a hostname allowlist that denies everything not explicitly approved. Workload identity: a mechanism that lets a Kubernetes workload authenticate to cloud services without a stored key. Signed URL: a short-lived, single-object URL that lets a browser upload or download from object storage directly, without the platform proxying the file.

​
FAQ

Can we start on shared SaaS and move to a private tenant later? Yes, and it is a common path. The product surface is identical, so your tests, SDK code and CI pipelines do not change. Existing data migration is scoped per case. What are the availability and support commitments? Availability targets, support hours, response times by severity and breach-notification terms are commercial commitments and live in your agreement rather than in these pages. Ask your Galtea contact for the current service description. How do we get our data out, and what happens at the end of the contract? Your test definitions, datasets and evaluation results are exportable through the API and the SDK at any time, in the same shapes the product uses. Retention while the contract runs is configurable per deployment; deletion at the end of it is covered in your agreement. In a self-hosted install the data is already yours and no export step is involved. Does Galtea need access into our network? Not for the platform to function, and never as an inbound firewall rule you open for Galtea. Traffic toward your AI product is outbound from the platform, with your endpoint as the server, and private tenant VPN connections are established outbound from your side. One deliberate exception: in model 4 Galtea needs credentials to run Helm against your cluster. You issue them, you scope them to the platform namespaces, you can restrict them to your VPN or bastion, and you can revoke them, or remove the access entirely by choosing the GitOps mechanism. See model 4. Can we use our own LLM provider account? Yes, in a private tenant and when self-hosted. Inference then runs under your contract, in your region, against your quota. In shared SaaS, inference runs on Galtea’s provider accounts. Can the models run in Europe? Can we use a European model? Yes to both, and they are different questions. The major models are available from EU-resident deployments, exposed in the gateway as separate entries with their own credentials, so choosing EU is choosing a route rather than trusting a setting. European models, Mistral Large among them, are available the same way. If even an EU region of a third-party provider is unacceptable, a model you host yourself behind an OpenAI-compatible endpoint is supported in a private tenant or a self-hosted install. One thing to decide deliberately: automatic failover between providers protects uptime but can move a request elsewhere, so a strict residency requirement means restricting the allowed set and giving up that fallback. Can we restrict which models are used? Yes, in a private tenant and when self-hosted. Restricting the gateway to an approved model subset is a normal requirement in regulated environments. Is our data used to train models? Not by Galtea, and in shared SaaS and private tenants not by the LLM providers either: the enterprise provider terms those deployments run under exclude training on submitted data. In a private tenant or self-hosted install you can additionally bring your own provider account and terms, and restrict which providers are reachable at all. Where exactly is our data? Shared SaaS: Galtea’s cloud account and region. Private tenant: a dedicated cloud account in the region you choose. Self-hosted: your infrastructure. Can our test data include personal or confidential information? The platform holds whatever you upload, so treat it as holding your test data’s classification and scope the test data accordingly. If your data cannot sit in third-party infrastructure, that points at a private tenant with your own encryption keys, or a self-hosted install. What happens if a Galtea component fails during a long evaluation? Jobs are queued and retried. A worker restart does not lose queued work. In a Galtea-operated deployment it is monitored and resolved for you; in a self-hosted install queue depth is the signal to watch. Can we run the platform completely air-gapped? Yes, by agreement. Images and charts must be mirrored into your internal registry, and you must provide an LLM endpoint reachable from inside the perimeter, which usually means a self-hosted or privately deployed model. Do we need ArgoCD, KEDA or a service mesh? No. All three are optional. The charts install with plain Helm on a bare cluster. KEDA only adds autoscaling; without it you set fixed replica counts. A service mesh only adds mutual TLS between platform services. Which cloud can we self-host on? Azure AKS is the validated target and has a complete deployment package. AWS EKS is the platform Galtea runs on itself. Google GKE, OpenShift and other conformant Kubernetes distributions are supported as a scoped adaptation. How often do we have to upgrade a self-hosted install? There is no forced cadence, and nothing expires or stops working if you stay on a version. Galtea ships releases frequently, typically weekly; how often you apply them is your decision and should match what your change process can absorb. The only constraint is the step size: upgrades are tested between consecutive versions, so catching up from far behind means applying the versions in order. Back up before each one. Can we get read-only access to the platform’s own monitoring? Not out of the box. In the shared SaaS models you get the status page and the support channel. In a private tenant, read-only dashboard access can be arranged on request, after a one-time setup that isolates your tenant’s metrics, logs and traces. In a self-hosted install the monitoring is your own. Who at Galtea can see our data? In Galtea-operated deployments, a restricted set of named personnel, for operations and support, with MFA, and that access is logged. In a self-hosted install, nobody: there is no access path. That access is recorded in audit logs, which Galtea’s own security team reviews; the logs are internal and are not exposed to customers. Further restrictions and break-glass procedures can be agreed per contract. The access-control and logging policies behind this are published in the trust center. Are you certified? Can we get your security policies? Galtea is ISO 27001 certified. The certificate, its scope, the policy set and the subprocessor list are published at https://trust.galtea.ai, without an NDA. Beyond naming the certification, these pages do not restate the trust center on purpose: anything dated that is copied into a document goes stale and then contradicts the live source. For a signed data-processing agreement or a report under NDA, ask your Galtea contact. Do you penetration test the platform? Yes, as part of the annual security audit cycle under the ISO 27001 programme. You can also run your own test, scheduled with Galtea first. Against the shared SaaS platform that scheduling is not optional: it is multi-tenant, so your traffic is indistinguishable from an attack on another customer.