AI privacy and control

Railbase includes an AI orchestration layer, not a bundled public model. AI features remain unavailable until the customer configures an approved local or cloud provider.

Provider boundary

• Local provider: prompts and retrieved context can remain inside the customer's environment, subject to that local service's configuration.
• Cloud provider: selected context leaves the estate for the configured provider under the customer's provider contract and Railbase policy.
• No provider: ordinary Suite records and deterministic workflows continue; AI-assisted features return unavailable rather than silently choosing a service.

Governed context

Railbase applies tenant scope, permissions, retrieval boundaries and configured redaction before an AI request. The system records provider/model identity, request purpose and bounded audit metadata without treating model output as authoritative business evidence by itself.

Actions and approval

High-impact actions can require human approval based on monetary, legal, security or data impact. The model cannot self-authorise an operation. Final execution runs through the same identity, permission, validation and audit path as a human-initiated action.

Customer responsibilities

The customer selects the provider, configures data-use/retention settings, controls credentials, defines allowed use cases and validates outputs. Do not send sensitive data to a cloud provider unless the legal, security and data residency basis has been approved.

FAQ

Is cloud AI required?

No. Railbase supports compatible local providers and can operate its ordinary business workflows with AI disabled.

Does Railbase train a public model on our records?

Not by default. Requests go only to the provider selected for the private estate, under the configured policies and applicable agreements.

Can an AI answer post money or approve itself?

Not merely because the model proposed it. Permissions, deterministic validation, approval policy and audit remain in force.