> 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/concepts/runtime-ai-compliance.md).
# Runtime AI compliance
Runtime AI compliance enforces your adopted controls on what AI systems do, at the moment of action, traced to the framework clause, with tamper-evident, independently verifiable evidence.
Organisations are giving AI systems – the AI-powered software, agents, and models they run – the ability to act: to call tools, move data, change records, and trigger workflows. Adoption is running ahead of control. A policy can say what an organisation permits, but it does not stop an AI system taking an unpermitted action at the moment it acts.
Runtime AI compliance closes that gap. It enforces the controls an organisation has already adopted at the point of action, and produces evidence of every decision.
## In one sentence
Runtime AI compliance is the enforcement of an organisation's adopted compliance controls on what its AI systems do, at the moment of action, traced to the framework clause the control satisfies, with tamper-evident and independently verifiable evidence. It extends an existing governance program to a new actor rather than creating a separate one.
## Key takeaways
* Runtime AI compliance governs what AI systems do, evaluated at the action boundary before the action proceeds wherever possible.
* The actor can be AI-powered software, an agent, or a model. Agents are the sharpest case, because they act autonomously at machine speed, but the discipline covers any AI system that takes actions.
* Controls are applied at the moment an action is proposed – preventively wherever possible – rather than only reviewed after the fact. Review after the fact breaks down at machine speed and volume.
* It enforces the controls you have adopted, each traced to the framework clause it satisfies, not a vendor's generic safety rules.
* Every decision produces tamper-evident, independently verifiable evidence.
* Runtime AI compliance sits alongside your governance, risk and compliance (GRC) platform, your AI governance program, and your observability stack. It extends them to the action; it does not replace them.
## What is runtime AI compliance?
Runtime AI compliance applies an organisation's existing controls to what its AI systems do, at the point of execution. It gives those controls a runtime enforcement point, so an AI system's intended action can be evaluated against its permissions, context, and the applicable requirements before it affects an external system. The result is a decision, and evidence showing what was attempted and which control applied.
The decision is one of three outcomes: `Allow`, `Deny`, or `Escalate` to a person for approval, each with a severity rating. Where enforcement is inline, the action waits for the decision before it proceeds.
Solcis provides this in two parts. The Solcis Policy Engine enforces your adopted controls on each action an AI system takes. Solcis Compliance Studio traces each decision to its framework clause and holds the tamper-evident, independently verifiable evidence.
## Why does runtime AI compliance matter?
Instructions and permissions alone cannot guarantee an AI system takes only authorised actions. A prompt that says "do not modify production data" is guidance, not an enforceable control. Once an AI system can access systems and act, the gap between what a policy says and what the system does opens at the action boundary.
Before an AI system calls an API, changes a record, executes code, or approves a workflow, an organisation should be able to determine:
* Which system is acting.
* What human or process initiated the task.
* What permissions and purpose apply.
* Whether the action complies with the relevant controls and regulations.
* Whether the action requires human approval or additional safeguards.
* What evidence is retained if the action proceeds.
This matters most as AI systems move beyond low-risk assistance and begin taking consequential actions across regulated workflows: approving transactions, modifying production systems, making decisions in regulated processes, or coordinating across multiple systems. In each case the AI system draws on the controls the organisation has already defined. Enforcing them at the point of action is what lets the system act quickly without exceeding authorised boundaries.
The [July 2025 Replit incident](https://incidentdatabase.ai/cite/1152/) shows what happens without this enforcement. During an active code freeze, an AI coding agent reportedly deleted a live production database despite explicit instructions not to make changes without approval, then wrongly claimed the data could not be restored. It was later recovered through a rollback. Telling a system not to act is not the same as enforcing that restriction at the point of action, and a system's own account of what it did is not evidence.
## How is runtime AI compliance different from governance, guardrails, and observability?
Runtime AI compliance is often confused with adjacent disciplines. Each answers a different question and acts at a different point.
| | AI governance | GRC platform | Runtime guardrails | AI observability | Runtime AI compliance |
| ------------- | -------------------------------------------------------------------- | ---------------------------------------------------------- | ---------------------------------------------------- | -------------------------------------------------------- | -------------------------------------------------------------------------- |
| Primary scope | AI systems, use cases, risks and accountability across the lifecycle | Organisational requirements, controls, risks and assurance | Common AI safety and security risks during operation | Visibility into system behaviour, decisions and outcomes | The actions AI systems take within connected systems |
| Core question | Is this AI being developed and used responsibly? | Are required controls defined, implemented and evidenced? | Does this behaviour break a predefined safety rule? | What did the system do, and what happened? | Is this specific action permitted under the applicable controls? |
| Enforcement | Sets what should be governed and who is accountable | Verifies controls exist and operate | Blocks, filters or flags generic safety violations | Records behaviour; does not enforce your controls | Allows, denies, escalates or rates an action against your adopted controls |
| Evidence | Policies, assessments, approvals | Control attestations, audit records | Safety events and interventions | Logs, traces, execution histories | Action-level evidence: the system, action, control applied, and outcome |
Runtime AI compliance complements these rather than replacing any of them. It enforces the organisation's own adopted controls, mapped to the frameworks and regulations it must meet, on each action, and captures the resulting decision and evidence.
## What are the properties of runtime AI compliance?
Four properties define the discipline.
### Preventive enforcement at the action boundary
The intended action is evaluated against the applicable controls before execution wherever possible, returning `Allow`, `Deny`, `Escalate`, or a `Risk Rating`. Preventive control suits high-impact actions such as deleting data, changing access, approving transactions, or modifying regulated records. Where prevention is not technically possible, detective controls identify and support investigation of the action afterwards, but they cannot provide the same protection as a decision made before the action occurs.
### Control-to-clause traceability
An action is evaluated against the controls and requirements that already govern the activity, not an AI-specific rule with no regulatory or organisational basis. Each decision traces back through the control to the framework clause behind it – a chain from requirement to control to action to decision – so an organisation can explain not only what was decided but why the control applied.
### Runtime enforcement, inline
The control fires at the moment the AI system acts. The Solcis Policy Engine enforces at this point, on the action path at model, tool and MCP endpoints or through a gateway, so the decision is reached before the action proceeds.
### Tamper-evident and independently verifiable evidence
Runtime enforcement is only useful for compliance if the organisation can later show what happened, why the action was evaluated, and what was decided. Every decision produces a record that is attributable, complete, tamper-evident, and independently verifiable, checkable by a third party without trusting the vendor or the operator.
## Where does runtime AI compliance sit in the stack?
Runtime AI compliance is an enforcement layer that connects existing governance and compliance controls to what AI systems do. It does not replace the GRC platform, the AI governance program, security controls, or observability tooling. It extends them to an actor that makes decisions and takes actions across connected systems.
* **GRC platform.** Defines and manages requirements, risks, controls, policies, frameworks, and evidence.
* **AI governance and safety.** Establishes how AI systems should be developed, assessed, monitored, and used responsibly.
* **Runtime AI compliance.** Applies the relevant controls to an action at the boundary and produces an attributable decision and evidence.
* **Observability and security tooling.** Provides operational visibility into behaviour, events, and security activity.
The distinction that matters is between knowing what an AI system did and controlling whether it was permitted to do it. Observability records an API call after it happens. Security tooling detects suspicious activity. GRC systems define the underlying control. Runtime AI compliance connects these at the point of action, using the organisation's existing requirements to decide whether an action should be allowed, denied, escalated, or rated.
## How does sovereignty relate to runtime AI compliance?
Sovereignty and runtime AI compliance answer different questions, and both are required.
Sovereignty answers where an AI system's data and infrastructure sit. Runtime AI compliance answers what the AI system is allowed to do, and proves it. Hosting a workload in-country keeps data within a jurisdiction, but it does not by itself control the system's actions or prove they stayed within approved boundaries. Runtime AI compliance adds that layer: governing and evidencing how an AI system accesses data, uses systems, and acts.
Because both Solcis products run in your own infrastructure, including air-gapped, the enforcement and the evidence stay inside the boundary you draw. How this applies under specific national regimes, and where an organisation can deploy in-border to satisfy residency expectations, is covered in the AI regulatory landscape pages.
## How do existing regulations and standards apply?
Runtime AI compliance does not require a separate compliance framework for AI. It extends the requirements, controls, and obligations already in an organisation's program to the actions its AI systems take. A regulatory or framework requirement informs a control, the control governs an action, the action produces a decision, and the decision produces evidence.
| Regulation / standard | Focus | How it applies |
| ---------------------------------- | ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| ISO/IEC 42001 | AI management systems, risk management, accountability | Existing AI governance controls apply to actions, with evidence showing how an action was assessed against the organisation's AI management requirements |
| ISO/IEC 27001 | Information security management system (ISMS) requirements and Annex A controls | Actions involving systems or information assets are evaluated against applicable security controls before execution |
| NIST AI RMF | AI risk management across govern, map, measure, manage | Identified risks inform controls that determine which actions are permitted, restricted, or require additional safeguards |
| EU AI Act | Obligations for high-risk AI systems, including record-keeping and human oversight | For high-risk AI systems, action-level decision records can support record-keeping and log-retention obligations (Articles 12 and 26(6)), and the `Escalate` outcome can support human oversight measures (Articles 14 and 26(2)). Applicability depends on the system's classification and the organisation's role |
| Applicable regulatory requirements | Sector-, jurisdiction- or activity-specific obligations | Relevant obligations map to controls that govern specific actions, such as accessing regulated data, approving transactions, or modifying records |
## Frequently asked questions
What is runtime AI compliance?
The enforcement of an organisation's adopted controls on what its AI systems do, at the moment of action, with verifiable evidence of every decision. It extends an existing governance program rather than creating a separate one.
How is runtime AI compliance different from AI governance?
AI governance sets policy, assesses risk, and oversees how AI is used across its lifecycle. Runtime AI compliance enforces the resulting controls on each action an AI system takes, and evidences the decision. Governance defines the rules; runtime AI compliance applies them at the action boundary.
Does it replace my GRC platform?
No. The GRC platform stays the system of record for requirements, controls, and evidence. Runtime AI compliance runs downstream of it, applies the controls it defines to each action, and reports evidence back up. Neither substitutes for the other.
What is the difference between runtime AI compliance and agentic compliance?
Agentic compliance is the agent-specific case of runtime AI compliance. Runtime AI compliance governs what any AI system does – AI-powered software, agents, or models. Agentic compliance narrows that to autonomous agents, where the actor has its own identity and acts across systems at machine speed.
Which frameworks apply to runtime AI compliance?
Any framework in your program. Runtime AI compliance is framework-agnostic: it enforces your adopted controls, whatever framework they come from, including ISO/IEC 42001, ISO/IEC 27001, NIST AI RMF, the EU AI Act, and national regimes. Each enforced decision cites the source control and clause.
---
# 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/concepts/runtime-ai-compliance.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.