From the Language of Compliance to the Language of Machines

AI compliance has a translation problem.

Regulations speak the language of obligations. Standards speak in principles. Policies express organizational intent. Engineering speaks in system design. And AI agents increasingly speak the language of actions. These are all requirements that must be satisfied.

At the heart is a deceptively difficult problem: compliance is written for humans, while AI systems operate through probabilistic models.

Asenion was built to bridge that gap.

David Van Bruwaene, Co-Founder and CEO of Asenion, developed this perspective through a background spanning philosophy, linguistics and artificial intelligence. While pursuing his PhD in philosophy at Cornell University, David developed a passion for linguistics and natural language processing (NLP), the field of AI concerned with enabling machines to understand human language.

That foundation informs Asenion's approach today: understand the language of the requirement, preserve its intent and translate it into something an organization can operationalize, verify and witness with runtime enforcement and evidence at scale.

A requirement is not a control

Take a simple requirement:

Personal data must be protected.

It’s clear to a compliance professional, but it isn’t yet an operational control. An engineering team still needs to know which data, in which use case and jurisdiction, who can access it, what the AI may do with it, what happens when conditions aren’t met and how to verify and evidence all of it.

A requirement describes what must be achieved. A machine needs to know what must happen. Between the two sits a layer most organizations are missing.

The control infrastructure

At Asenion, we think of that layer as a multifaceted chain. It starts with regulations, standards, frameworks, contracts and internal policies, and each step answers a different question:

1. Requirement — What must be satisfied?
2. Context — Where and under what conditions?
3. Intent — What outcome does the organization want?
4. Control objective — What compliance outcome must be achieved?
5. Control — What will actually be implemented?
6. Verification — Does the control work?
7. Evidence — What proves what happened?

Context and intent change the control

A requirement doesn’t produce the same control everywhere. An AI that summarizes support conversations and an AI that recommends hiring decisions may both process personal data under the same privacy rules, yet need very different controls. Context—jurisdiction, use case, data, affected people, risk level, deployment environment and downstream actions, turns a generic requirement into a specific compliance problem.

Intent matters just as much. Two organizations running similar AI under the same regulation may still choose differently: one lets AI recommend but never act without human approval; another allows automated execution within defined boundaries. Same requirement, different intent, different control.

That’s why a generic, LLM-generated control isn’t necessarily the right control. Effective AI compliance has to be policy-aware, context-aware and intent-aware.

Example: hiring AI, end to end

• Requirement: Provide appropriate human oversight for high-impact AI decisions.
• Context: An AI system that supports employee hiring decisions.
• Intent: AI assists recruiters but never makes the final decision on its own.
• Control objective: A qualified human reviews and approves the AI-supported recommendation before any final hiring decision.
• Control: The system requires documented human approval before a recommendation can proceed.
• Verification: Confirm the approval step works and cannot be bypassed.
• Evidence: Records of the recommendation, the approval and the resulting action.

That is operational compliance: something that can move through the organization—and through the AI system itself.

Agents raise the stakes

Traditional software executes predefined logic. AI agents interpret objectives, call tools, access enterprise systems, delegate to other agents and act on behalf of users. The question shifts from “Is this AI system compliant?” to “What is this AI system allowed to do, under what circumstances, and how do we know?”

Consider an agent with access to a customer database, under a policy that customer data may only be accessed for legitimate business purposes. At runtime, the system has to decide whether the request’s purpose is legitimate, whether the data is appropriate, whether this agent is authorized—and whether to allow, block or escalate the action, even when another agent delegated it.

The policy hasn’t changed. The operating environment has. That’s why controls can’t live only in documents, spreadsheets and point-in-time assessments. They have to follow the AI use case.

One control objective. Three types of controls.

A control shouldn’t disappear after an audit. At Asenion, the same control objective follows the use case through three points of control:

• Assess — Lifecycle assessment: understand the use case, applicable requirements, context, risks and controls.
• Verify — Pre-deployment verification: before release or a significant change, test that controls are designed and operating as intended.
• Witness — Runtime governance: govern how AI behaves in production, within defined control boundaries.

Each produces evidence, connecting the source requirement to the system’s actual behavior—instead of treating compliance as a once-a-year exercise.

What we’re building at Asenion

The Asenion AI Control System is built around this idea. Asenion ControlGen, our AI compliance control engine, turns requirements into control objectives and operational controls, contextualized for each use case and organization. Asenion Policy Packs provide reusable compliance knowledge. And the resulting controls follow each use case through Assess → Verify → Witness.

AI helps here: language models are good at reading regulations and drafting candidate controls. But generating a control isn’t the hard part. Knowing whether it fits the context and intent, can be implemented, actually works and can be proven—that takes structure, traceability and evidence.

The goal isn’t another policy library. It’s the connective tissue between what compliance requires and what AI systems actually do.

The future of AI governance

As AI becomes more autonomous, the distance between compliance language and machine behavior matters more. Organizations will still need policies, risk assessments, audits and evidence. Increasingly, they will also need control infrastructure that connects all of it to the systems actually using AI for runtime enforcement at scale: From the language of compliance to the language of machines.

That is the future of operational AI governance.