Every enterprise AI project eventually hits the same wall. The model works in the demo. It understands the input. It generates plausible output. The pilot looks promising. Then someone asks: how do we ensure it only does what it's supposed to do? How do we prove it to the regulator? What happens when it does something wrong?

And the answer, in most cases, is: we'll add guardrails later. We'll build a review layer. We'll have humans check the outputs.

That's compliance as an afterthought. And in regulated industries — insurance, healthcare, financial services — it's why AI adoption stalls at the pilot stage.

The fundamental mismatch

The problem
Generative AI is probabilistic by nature
LLMs produce the most likely next token given the context. Beautiful for creative tasks. Dangerous in a claims intake, medical referral, or financial transaction where the required step order must be established and fraud checks cannot be skipped.
The reality
Regulations are deterministic
Technical policies can enforce defined access and validation rules. Regulatory obligations also depend on context, organisational processes and legal interpretation.

The gap between probabilistic AI and deterministic regulation is the compliance gap. Most enterprise AI deployments sit in that gap, held together by human review layers that prevent AI from scaling.

"Rather than building an AI system and adding compliance constraints as a layer on top, we built the constraint layer first and placed the AI inside it."

The SKYLA design principle

Compliance as code

SKYLA approaches this from the opposite direction. The Agentic Runtime Fabric enforces compliance at the execution layer using OPA/Rego — Open Policy Agent, the same policy engine used in Kubernetes, cloud security, and enterprise authorization systems.

Compliance architecture — LLMs propose, deterministic rules decide
SKYLA compliance architecture: LLM proposes, OPA/Rego decides, GER records 🎙 Voice 💬 Chat PII Redaction Before any LLM call LLM Proposes Neural reasoning · Intent 🛡 OPA / Rego Policy Gate Configured policies evaluated before execution · Access · Validation · Step order PERMIT DENY ✓ Action Executes System updated · GER record created ✗ Action Refused Not logged for review — refused at source GER Audit Record Immutable · Timestamped · Regulatory-ready

The design evaluates proposed actions against configured policies before execution. Checks can cover step order, required fields and access rules; their coverage must be tested.

PII redaction runs before any LLM call. Test redaction coverage and data flows against the intended processing and retention requirements.

🇪🇺
Execution records for review
Execution records capture policy decisions and outcomes for review alongside system documentation and operating procedures.
🔒
Data minimisation in the design
OPA-backed policy enforcement governs field-level data access. EU data residency enforced at infrastructure level.
🏦
Evidence for operational review
Operational evidence needs to be assessed against the organisation’s sector, system risks and review requirements.
🏗
Multi-tenant isolation — hard boundary
The design separates tenant credentials, policies and data. Isolation must be tested against the deployment’s access model and integrations.

What this enables

When compliance is architectural rather than procedural, two things change fundamentally.

01
Human review becomes selective, not universal
SKYLA is designed to execute policy-controlled workflows — across voice and chat. Humans review edge cases, exceptions, and escalations: the work that genuinely requires human judgment. Not everything that passes through the system.
02
Audit becomes automatic
Every action is logged at the moment it executes — not reconstructed from call recordings after the fact. For a DNB-regulated insurer or EU AI Act audit, this is the difference between a defensible compliance posture and a scramble.

The design includes execution records. This fictional example illustrates the intended fields:

Illustrative execution record — fictional data
Every ARF action produces an immutable, timestamped audit record — ready for regulatory review at any point, not reconstructed after the fact.
tenant_idillustrative-insurer-demo
session_idfnol-20260517-8a3f
stepfraud_check
policy_decisionPERMIT
pii_redactedtrue
action_executedclaim_file.create
outcomeCONFIRMED
latency_ms142
eu_data_residencyENFORCED

A shared policy design for voice and chat

A key point: the ARF compliance architecture is channel-agnostic. It doesn't matter whether the input arrives as a voice call or a chat message.

🎙
Voice — FNOL, healthcare, telco CX
Live call → intent → PII redaction → LLM proposes → OPA evaluates → system executes or refuses → GER created. Evaluate control coverage and end-to-end latency in the intended workflow.
💬
Chat — digital-first workflows
Same policy layer, same audit trail. Digital channels, async workflows, hybrid interactions. The same OPA/Rego rules. The same GER audit record. Compliance doesn't depend on the channel.

The honest question

If your enterprise AI deployment still requires a human to validate every action before it executes, that is not AI automation. That is AI-assisted human work — a useful capability, but a fundamentally different proposition.

"What would it take to trust the AI to act, not just to advise? The answer starts with compliance as code — not compliance as a checkbox."

The question worth asking

SKYLA's answer is already live. The FNOL demo shows what compliance-by-architecture looks like in a regulated, high-stakes workflow — complete with the GER audit record created in real time. Try it. It is an own demonstration, not evidence of a client deployment.