> 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/how-solcis-compares.md). # How Solcis compares Compare four approaches to governing AI systems, including where they run, who controls them, and what evidence they provide. ## What matters There are many products that can discover agents, evaluate actions against policies, and log results. However, in our experience, feature comparisons become outdated quickly. **Architecture reflects pedigree and focus:** where checks run, who operates the model, who holds the record, and what happens if the vendor becomes unavailable. These choices show how each approach aligns with Solcis and broader regulatory requirements. ## The four approaches Each approach makes a different trade between coverage, control, and operational responsibility. Use these summaries to identify the approach that fits your deployment boundary and assurance requirements.

Approach	Summary, strengths, and limits	Cover image
Log and review	Observability platforms record agent activity, flag anomalies, and support investigation. ✅ Strengths Sees activity broadly, including agents outside an enforcement path. Supports investigation after an incident. ❌ Limits Finds issues after an action occurs. Does not explain why an action was allowed.	https://644912709-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FFwpyjzyaYY4oV7LJBr4N%2Fuploads%2FGZGShGn07GoatrC2bfxR%2Fcover-log-review.svg?alt=media&token=28fd139d-83bb-4dc1-952f-05d13aca585d
A fully or partially hosted service	Agent traffic goes to a vendor service for evaluation, then logging. ✅ Strengths Starts quickly, with little or no infrastructure. Provides vendor-managed policies, models, and updates. ❌ Limits Agent traffic, records, and controls sit in the vendor's estate. Vendor changes, availability, and latency affect enforcement.	https://644912709-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FFwpyjzyaYY4oV7LJBr4N%2Fuploads%2F9jROxI2azmPcyM5ZH6ca%2Fcover-hosted.svg?alt=media&token=3f4f40ec-5f3a-40fb-8a95-cb49f0339a10
Build it yourself	Your platform team builds and operates the enforcement capability. ✅ Strengths Keeps the design, model, and deployment under your control. Can put a policy check before an agent framework. ❌ Limits Requires control lineage, lifecycle management, and ongoing operations. Requires independently verifiable evidence and assurance.	https://644912709-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FFwpyjzyaYY4oV7LJBr4N%2Fuploads%2FL03F91zD6kYDl4S0P6HN%2Fcover-build.svg?alt=media&token=e185ce92-27e3-4036-99e6-fbd52b05e9c2
Solcis	You run Compliance Studio and the Solcis Policy Engine in your environment with a model you host. ✅ Strengths The Solcis Policy Engine decides every connected action before it proceeds. Compliance Studio holds a receipt for each in an evidence ledger a third party can verify. ❌ Limits You deploy, secure, operate and upgrade them.	https://644912709-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FFwpyjzyaYY4oV7LJBr4N%2Fuploads%2FjmKehTcSZoMJMDxUf2Fg%2Fcover-solcis.svg?alt=media&token=9faa3c36-b306-4bb7-9ee9-f948e7ad9202

**Open control catalogues and runtime standards** sit alongside all four. Several bodies and vendors publish control sets for agentic systems and standards for runtime governance. A catalogue tells you what to control; a standard tells you what conformance looks like. Neither enforces anything. They're inputs to the approaches above, and Compliance Studio is built to take them as inputs. {% columns %} {% column width="41.66666666666667%" %}

{% endcolumn %} {% column width="58.33333333333333%" %} #### **Deploy Solcis for your clients** Consultants, advisers and auditors run Solcis on their clients' infrastructure and verify its evidence independently. Become a partner Qualify an opportunity {% endcolumn %} {% endcolumns %} ## What each can promise Each row is a consequence of architecture, not a feature. That's why a regulated buyer can rely on it, and why it won't change with a release. | | Log and review | Hosted service | Build it yourself | Solcis | | --------------------------------------------------------- | ---------------------------------------------- | ----------------------------------------------------------- | ------------------------ | --------------------------------------------------------------------------------------------------- | | **Compliance scope** | Everything it sees, after the fact | The paths you route, within a latency budget | Whatever you build for | Every connected action, before it proceeds | | **Where your compliance infrastructure lives** | Split between you and the vendor | In the vendor's estate | Yours | Yours | | **Who can compel disclosure of your AI systems' traffic** | Your jurisdiction, and the vendor's if hosted | Yours and the vendor's home jurisdiction | Yours | Yours | | **What appears in your third-party register** | A monitoring provider | A critical service provider | Nothing | A software supplier; no running service dependency | | **Business continuity if the vendor fails or you leave** | Monitoring stops; history is what you exported | Enforcement stops; policies and records are in their estate | Continues | Continues. You hold the software, the policies and the ledger | | **Where it's hosted and how it's recovered** | The vendor's choice, or yours | The vendor's choice | Yours | Yours, to your continuity plan and your regulator's expectations | | **What changes without your consent** | Detection rules and models | Policies, models and the service itself | Nothing | Nothing. You choose when to upgrade | | **Whose model makes the call** | The vendor's | The vendor's, retrained on their schedule | Yours | Yours, run by you | | **Whose controls** | The vendor's detection rules, tuned | The vendor's policies, tuned to you | Yours | Yours, with lineage to the framework requirement | | **Who certifies the environment it runs in** | The vendor, by attestation | The vendor, by attestation | You | You. What you assess is how Solcis is built and delivered; see *Evaluate Solcis › Product security* | | **Who can verify the record independently** | Whoever has platform access | The vendor and you | Whoever you build it for | Anyone with the export and the record format | | **What you operate** | A platform or a subscription | A subscription | Everything | Compliance Studio and the Solcis Policy Engine | | **Time to a first decision** | Days | Days | Months | The quickstart; production in weeks | ## Business continuity is yours to plan Operational resilience regimes ask the same question of every critical system: what happens when the provider fails, is compromised, or exits? For a hosted service, the answer is that enforcement stops and your policies and records are wherever the vendor put them. Your compliance infrastructure is in someone else's business continuity plan.

Solcis puts it in yours. You choose the regions, the redundancy and the recovery objectives. You decide how the software is distributed across production, test and air-gapped environments. You hold the policies and the evidence ledger, and you back them up under your own procedures. If we disappeared tomorrow, your deployment would keep deciding and keep recording. That's a statement about architecture, not about our intentions, and it's one a hosted vendor can't make. ## Where Solcis is the only option Three requirements rule out everything else in the table. Suppose your AI systems' prompts and tool calls may not leave your boundary, whether by regulation, by policy or by classification. A hosted service is excluded before evaluation starts. Log-and-review platforms that ship logs to a vendor are excluded with it. That leaves building it or running Solcis. If your environment is air-gapped, the same is true, and the build has to include the model. Suppose the record has to be verifiable by someone who trusts neither you nor your vendor: an internal auditor, an assurance firm, a regulator. Then the record format has to be public, and the integrity check has to work from an export. No hosted product can offer it without also offering the traffic sovereignty it's built to avoid. ## Where the alternatives are the right choice A comparison that can't say this isn't one. A hosted service is faster to switch on and needs nothing run. Suppose your AI systems' traffic may leave your boundary and your regulator has no view on where it's checked. Suppose, too, that you're content to place your compliance record in a vendor's continuity plan. Then that speed is a real advantage, and you should weigh it. Log and review records activity that never reaches an enforcement point, and it's built for investigation after an incident. Compliance Studio's coverage and agent discovery show where those gaps are, but Solcis doesn't evaluate or record an action that reaches no enforcement point. Building it yourself gives total control over the design. For an organisation with the engineering depth to build, certify and maintain it, it's a legitimate choice, and some will make it. ## The trade Solcis is software you run, and every entry in its column follows from that. It's also what the column costs. You deploy it and secure it. We provide an upgrade process, while you retain control over when and how upgrades reach your environment. There's no free tier we host and no telemetry we watch. We made that trade deliberately, because the organisations we build for had already made it. *Sovereign by construction* explains why. --- # 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/how-solcis-compares.md?ask=&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.