> For the complete documentation index, see [llms.txt](https://docs.solcis.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.solcis.ai/references/frequently-asked-questions.md).

# Frequently Asked Questions

Common questions about what Solcis is, how it enforces your controls on what your AI does, and how it deploys.

## What Solcis is

<details>

<summary><strong>Who is Solcis for?</strong></summary>

Solcis is for regulated organisations that run AI-powered software, agents, and models in production. It suits organisations where compliance failures carry material cost and the chief information security officer (CISO) or risk leadership sponsors the deployment.

Three teams work together. The compliance team maintains the controls. The engineering team connects AI systems to the Solcis Policy Engine. The audit and assurance function uses the evidence in Solcis Compliance Studio. Each team works from the same controls and evidence ledger in Solcis Compliance Studio.

</details>

<details>

<summary><strong>What does Solcis govern?</strong></summary>

Your AI systems: the AI-powered software, agents, and models your organisation runs. Solcis governs the actions they take, a model call, a tool call, an MCP call, an API call, a data access. The Solcis Policy Engine evaluates each action against your controls before it happens, returns a decision, and records it. What it governs is the action, not the model's internal reasoning, which is why the same approach covers a simple AI feature and a fully autonomous agent.

</details>

<details>

<summary><strong>Is Solcis a GRC platform, or does it replace one?</strong></summary>

Neither. Solcis works with your governance, risk, and compliance (GRC) programme, it doesn't replace it. Your GRC platform is where you decide what your controls are; Solcis Compliance Studio is where those controls become runtime policy; the Solcis Policy Engine enforces them on what your AI systems do, at the moment they act, with a record of every decision. Controls come into Solcis Compliance Studio from your existing programme, keep their identifiers and their lineage to the framework requirement they satisfy, and become runtime policy. GRC platforms enforce offline, after the fact; the Solcis Policy Engine enforces at runtime, before the action proceeds.

</details>

<details>

<summary><strong>How does Solcis enforce, and where does it sit?</strong></summary>

In two layers. The Solcis Policy Engine enforces on the action path and at model, tool and MCP endpoints. Solcis Compliance Studio sends it enforcement policies and receives its decisions and evidence. Enforcement points include:

* **Solcis SDK.** Places the Solcis Policy Engine on the action path, inside the application at the point it decides to act. More complete coverage and richer context, for the applications you control.
* **Gateway.** Your own gateway or the Solcis Gateway puts enforcement in the traffic path. Model, tool, MCP and API calls are evaluated as they pass, with no change to your application code. Broad coverage across many applications.
* **NVIDIA OpenShell and Microsoft AGT.** Where you run them, they enforce security and infrastructure controls. Solcis Compliance Studio can supply them enforcement policies and collect their decisions and evidence.

The Solcis Policy Engine writes a compliance receipt for each decision; Compliance Studio's universal evidence ledger collects receipts from every enforcement point. See [Where Solcis enforces](https://docs.solcis.ai/why-solcis/where-solcis-enforces) for the full comparison.

</details>

<details>

<summary><strong>How is Solcis different from an AI guardrail?</strong></summary>

A guardrail enforces generic safety, PII redaction, jailbreak detection, content moderation, the same rules for everyone. Solcis enforces your controls: the specific obligations your organisation has adopted, traced to the framework clause behind each one, with a verifiable record of every decision. A guardrail can tell you it blocked something; Solcis can prove which adopted control denied an action, and why, at any point later.

</details>

<details>

<summary><strong>What type of AI gateway is Solcis?</strong></summary>

Solcis is not a traffic gateway. The Solcis Policy Engine decides whether an action proceeds, including through your own gateway or the Solcis Gateway, and Solcis Compliance Studio holds the evidence of each decision.

Many AI gateways manage model-call traffic. They route between providers, manage keys, cache responses, and attribute cost. Their records support platform operations.

The Solcis Policy Engine sits in front of the actions your AI systems take. It applies your controls and returns `Allow`, `Deny`, or `Escalate`, each with a severity rating. The action waits for that result. The Solcis Policy Engine writes a compliance receipt for each decision. Each receipt identifies the governing control, runtime policy, and rule. Receipts are held in Solcis Compliance Studio's tamper-evident evidence ledger.

|                  | Traffic-focused AI gateway               | Solcis Policy Engine                                               |
| ---------------- | ---------------------------------------- | ------------------------------------------------------------------ |
| Sits in front of | Model calls                              | Actions your AI systems take, including tool calls and data access |
| Decides          | Where the call is routed                 | Whether the action is allowed to proceed                           |
| Writes           | Telemetry for operations                 | One compliance receipt for each decision                           |
| Judged on        | Latency, availability, and cost per call | Whether the record survives independent verification               |
| Owned by         | The team that runs the platform          | The team accountable for the controls                              |

The Solcis Policy Engine can enforce through or alongside your existing gateway. The traffic gateway manages model infrastructure. Solcis enforces controls and produces evidence for accountable teams.

The Solcis Policy Engine enforces through a gateway, your own or the Solcis Gateway, or on the action path through the Solcis SDK. A gateway evaluates traffic inline. The Solcis SDK evaluates actions within your application. Actions that reach no enforcement point are neither evaluated nor recorded; Compliance Studio's coverage and agent discovery show where those gaps are. See [Where Solcis enforces](https://docs.solcis.ai/why-solcis/where-solcis-enforces) for the comparison.

See also [what Solcis does](https://docs.solcis.ai/why-solcis/what-solcis-does), [how Solcis compares](https://docs.solcis.ai/why-solcis/how-solcis-compares) and the [decision lifecycle](https://docs.solcis.ai/how-it-works/decision-lifecycle).

</details>

## How it works

<details>

<summary><strong>How do our existing controls become something Solcis enforces?</strong></summary>

Your controls are authored into runtime policy, expressed as code. A control is authored into one or more rules, and rules live in a runtime policy that the Solcis Policy Engine enforces. Authoring is a reviewed step, not a silent conversion: Solcis Compliance Studio assists in turning a control into rules, and your compliance function reviews and approves the result before it can enforce. Every rule cites the control and framework clause it came from, so nothing enforces without a traceable source.

</details>

<details>

<summary><strong>How are policies reviewed and approved before they can enforce?</strong></summary>

A runtime policy cannot enforce until a person approves it, agents and automated credentials cannot approve, and a policy whose control citations don't resolve cannot be approved. Before enforcing, you can run a policy in shadow mode: the Solcis Policy Engine evaluates real traffic and records what it would have decided, without blocking anything, so you see the effect first. Solcis Compliance Studio retains every policy version, so you can prove what was active at any time.

</details>

<details>

<summary><strong>What are the possible outcomes when the Solcis Policy Engine evaluates an action?</strong></summary>

Four. The action waits for the result before it proceeds.

| Outcome    | Effect                                                      |
| ---------- | ----------------------------------------------------------- |
| `Allow`    | The action proceeds; the decision is recorded               |
| `Deny`     | The action is refused                                       |
| `Escalate` | The action is held for a named person to decide             |
| `Severity` | The action proceeds with a rating attached for later review |

</details>

<details>

<summary><strong>Does Solcis add latency to our agents?</strong></summary>

Minimal. The full check loop, including inference, runs under 150ms, fast enough to sit in the live path of an action without holding the agent up. Three things make that possible:

* **Deterministic checks** carry most traffic and return almost immediately.
* **Small language models** handle the inference check, the cases rules alone can't judge. Small models run on your own hardware and stay inside the latency budget, where large, slow models would blow it.
* **Shadow mode** lets you run a policy against real traffic without enforcing, so you tune it before it goes live and it behaves predictably once it does.

A decision has two steps: a deterministic check against your rules, then, only where the policy calls for it, an inference check using a small language model you host. Actions return one of four outcomes. The Solcis Policy Engine refuses or holds an action only when a control you adopted says it should.

</details>

<details>

<summary><strong>Can Solcis govern AI agents when we don't control their source code?</strong></summary>

Yes, through a gateway, your own or the Solcis Gateway. Because it sits inline in the path of the agent's traffic, the Solcis Policy Engine evaluates the agent's calls with no change to the agent's code, covering third-party and packaged agents whose source you can't modify. The Policy Engine can also enforce at the model, tool and MCP endpoints those agents call. Where you run NVIDIA OpenShell or Microsoft AGT, Solcis Compliance Studio can supply them enforcement policies and collect their decisions and evidence. For applications you do control, the Solcis SDK places the Policy Engine on the action path, where it sees richer context.

</details>

<details>

<summary><strong>What happens if Solcis is unavailable when an agent acts?</strong></summary>

The action does not proceed. If the Solcis Policy Engine can't be reached, or a decision can't be completed, the safe default takes over: the action is held or refused, never quietly allowed. An enforcement layer that let actions through whenever it was unavailable would fail at exactly the moment it was needed, so the Policy Engine does the opposite. You can configure the behaviour within that safe boundary, but the Policy Engine will not let an ungoverned action through.

</details>

## Sovereignty and data

<details>

<summary><strong>Can Solcis run fully on-premises or air-gapped?</strong></summary>

Yes. Self-hosted is the only deployment model, there is no multi-tenant SaaS. Both Solcis products, and every component, run inside your environment: your cloud, your data centre, or an air-gapped network with no outbound connectivity. Air-gapped is a defined, supported deployment. Licensing is validated offline, with no phone-home.

</details>

<details>

<summary><strong>What does Solcis need from us to run?</strong></summary>

Four things, all of which stay under your control:

* **Infrastructure you provide.** Both Solcis products run in your environment, your cloud, your data centre, or an air-gapped network. There is no vendor-hosted component.
* **A model you host** for the inference check. Use one from the curated model list in Solcis Compliance Studio or bring your own; it runs on your hardware.
* **Your controls**, brought into Solcis Compliance Studio from your existing GRC programme and authored into runtime policy.
* **Your identity provider**, so your own people and roles govern access to Solcis Compliance Studio.

Solcis needs no connection back to us after install, including in air-gapped deployments. See [Deployment profiles](https://docs.solcis.ai/deploy/deploy-and-operate/deployment-profiles) for how the deployment options differ.

</details>

<details>

<summary><strong>Does any of our data leave our environment?</strong></summary>

No, not by default. Solcis operates no shared service and holds no copy of your data, so there's no path by which your action data, decisions, evidence, prompts or model interactions reach Solcis. Data leaves only if you set up an external destination yourself, such as your own log collector or a cloud model provider. Nothing is sent anywhere you haven't explicitly allowed, and you control that list. In an air-gapped deployment there is no external path at all.

</details>

<details>

<summary><strong>How is the evidence ledger protected, and can anyone alter or delete records?</strong></summary>

Solcis Compliance Studio's evidence ledger is tamper-evident. Each record is cryptographically chained to the one before it and signed before the decision is returned, so altering or removing any record breaks the chain in a way a verifier can detect. The ledger is append-only. Tamper-evident does not mean a record can never be changed; it means any change is detectable. An administrator cannot quietly edit or delete history without it showing on verification.

</details>

<details>

<summary><strong>Can we verify independently that Solcis is behaving as claimed?</strong></summary>

Yes:

* **The ledger.** Verify it with an offline tool that recomputes the chain and checks every signature, confirming the evidence set is complete and intact, without trusting Solcis or the people who run it.
* **The boundary.** Because enforcement runs on your own hosts, inspect the configuration and network directly to confirm what does and doesn't leave your environment.
* **The code.** The Solcis Policy Engine is source-available under the Functional Source License (FSL), and the Solcis SDKs and connectors are Apache 2.0, so their code can be audited.

</details>

## Frameworks and evidence

<details>

<summary><strong>Which regulatory frameworks does Solcis support?</strong></summary>

All of them. Solcis is framework-agnostic: it ships no fixed list of supported regulations and enforces the controls you've adopted, whatever framework they come from. International standards such as ISO/IEC 42001, ISO/IEC 27001 and NIST AI RMF, and the EU AI Act, are enforced the same way as any national regime. Your adopted control statements are authored into rules in Solcis Compliance Studio, reviewed by your compliance function, and each enforced decision cites the source control and clause. Solcis does not interpret regulation on your behalf; your compliance function and qualified advisers own the mapping.

Guidance is available for the Gulf, Australia and New Zealand, Asia, India, the United Kingdom and Ireland, Canada, and South Africa.

</details>

<details>

<summary><strong>Can a decision be traced back to a specific control and regulation?</strong></summary>

Yes. Every decision records the rule that drove it, the control that rule implements, and the framework clause that control cites, with the policy and control versions in force at the time. From any single decision you can walk back to the exact control and clause. The claim is precise: a decision cites the control it enforced, a statement about what Solcis did, not that the regulatory obligation as a whole was satisfied.

</details>

<details>

<summary><strong>Can Solcis send evidence into our existing GRC, SIEM or data lake tools?</strong></summary>

Yes. Solcis Compliance Studio gets evidence out in the formats downstream systems need, so decisions and their evidence move into your GRC platform, SIEM, or data lake. Evidence is exportable for these systems; the depth of direct, live integration varies by platform.

</details>

## Deployment and models

<details>

<summary><strong>Which AI models does Solcis use, and can we use our own?</strong></summary>

Solcis is model-agnostic. The inference check uses small language models, small enough to self-host and to return a decision inside the latency budget, which is also what makes air-gapped and sovereign deployments practical. Policies name a capability, never a specific model, and you bind that capability to a model in Solcis Compliance Studio (model routing).

* **Use the catalogue.** Solcis Compliance Studio provides a curated model list of small language models, each characterised for accuracy on Solcis's evaluation sets, with sizing and licence metadata, so you can select one that fits your requirements. Some run without a GPU.
* **Or bring your own.** Any model exposing a compatible endpoint, registered in Solcis Compliance Studio, can serve, including open-weight and locally certified sovereign models.

No Solcis-associated model is mandatory: policies can be fully deterministic, and where an inference check runs, it runs on your model on your hardware. Solcis does not send your prompts or data to a model it controls.

</details>

<details>

<summary><strong>What languages does Solcis support?</strong></summary>

Solcis supports multiple languages. Solcis Compliance Studio renders right-to-left layouts as well as left-to-right, and where a policy calls for judgement of content in a given language, an inference check can use a model capable in that language, including Arabic. For the current state of localisation across Solcis Compliance Studio, reports and alerts, contact the Solcis team.

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.solcis.ai/references/frequently-asked-questions.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
