ARTICLES
Agentic AI is moving into production in regulated industries and processes. As these deployments scale, the question is no longer whether to use them, but how to govern them. Most governance frameworks today focus heavily on the agent layer. They concentrate on autonomy, tool access, permissions, and human oversight. These are critical controls, but they address the brain of the system while the foundation is often treated as a general data-governance issue rather than a first-class control surface. There is a layer underneath the agent that determines whether trust is established or lost. It is the document layer: what the agent reads before it reasons.
Inputs are decisions
When an agent reads a document, a typically probabilistic transformation occurs. A model extracts values from that document and hands them to the agent as facts. The agent then reasons over those facts, calls tools, and acts. Current governance discourse often treats document ingestion as a neutral utility, assuming that what the agent reads is ground truth. This assumption is flawed. The extraction step is a decision to promote ambiguous source material into structured claims. In regulated workflows, this fact-creation step requires the same scrutiny as any downstream action the agent takes. An audit trail that begins only when the agent starts reasoning has a structural blind spot. For a system to be truly accountable, the audit must begin at the point of ingestion.
Verification at the model layer
Recognising extraction as a governed decision necessitates three specific shifts in how we build and audit these systems.
- Uncertainty as an escalation signal. Accuracy alone is insufficient for governance. Because document extraction is typically probabilistic, field-level confidence and uncertainty signals are one of the most practical mechanisms for deciding when an agent should escalate to a human, especially in high-consequence workflows.
- Version control and provenance. Compliance functions require rigorous change control. If the extraction model changes, the facts it produces may change too. Organisations must track model versions and training provenance to ensure that the document layer meets the same validation standards as any other system processing regulated data.
- Verification metadata. To be governable, the model must produce verification metadata rather than just an output. Systems like Google, AWS, and Azure already provide this receipt, including bounding boxes, text anchors, and per-entity confidence, which allows an auditor to trace an agent’s reasoning back to the specific pixels on the source page.
Verification at the data path
The second half of the governance gap is the data path: the physical journey a document takes during processing. When a document is read, it often transits through third-party services or sub-processors. This creates a specific risk. An organisation’s agent-layer policies may be strict, but the document extraction layer sitting one integration away may follow different rules regarding data residency and storage. In regulated environments, privacy and audit obligations extend through every processor and sub-processor that handles the document. Whether the document is processed in-region or used by a vendor for model improvement is a critical compliance question, not a technical preference.
Audit and accountability
Regulated industries must be able to reconstruct decisions. This requires knowing not just what the agent decided, but exactly what it saw, how confident the system was in that observation, and where the data was physically processed. If these elements are missing, the audit trail has a gap. While human oversight is a vital safeguard, it cannot fully compensate for an ungoverned or untraceable input layer. A governance framework that cannot account for how inputs became facts is fundamentally incomplete.
The principle
Governance is the precondition for deploying AI in environments where decisions have consequences. The current focus on agentic reasoning is necessary, but the conversation remains unfinished. Until the document layer and the data paths it relies on are governed to the same standard as the agent above them, these deployments will carry a structural risk that oversight alone cannot resolve. The ultimate trust question is not just what the agent decides. It is what the agent reads, and how it came to believe it.
12.05.2026
Five questions every payroll professional should ask before trusting AI with compliance work
Imagine a payroll manager posts in an online forum. They've just used a general-purpose AI tool to complete a month-end validation that normally takes three hours. It took two minutes. They're impressed, a little unsettled, and wondering whether others are doing the same.
It's a reasonable reaction. The capability is real. But the post raises a question that nobody in that thread is asking: should a compliance-sensitive process like payroll validation be handed to an AI tool without understanding what that tool actually is?
Payroll is audit-aware by instinct: checking, double-checking, 4-eye checks, 10% checks etc. Payroll professionals document and they ask for evidence. It's time to apply the same discipline to the AI tools being rolled out across our organisations. Here are five questions worth asking before you allow AI into payroll processes.
1. What was it trained on, and whose data was used?
Most general AI tools are trained on large volumes of text and documents from across the internet. Some agentic payroll tools are trained on real payroll data from real organisations. Either way, the question matters: if a model learned from sensitive payroll documents, whose were they, and did those people consent to that use? For compliance teams navigating GDPR and data residency requirements, this is not a theoretical concern.
2. What happens to my data when I use it?
Submitting a gross-to-net report to an AI tool is a data transfer. Where does it go? Who can see it? Is it retained after the session? Is it used to train future versions of the model? Cloud-based AI tools often process data on infrastructure outside your jurisdiction. That matters. "Data never leaves your network" is a procurement-grade claim. "We take data seriously" is not.
3. How does it handle uncertainty and errors?
When an AI tool produces an output, does it tell you how confident it is? Does it flag the cases it is less certain about, or does it present everything with equal confidence? A tool that cannot communicate its own uncertainty is not ready for compliance use, regardless of how impressive the demo looks.
4. Can it produce an audit trail?
If a regulator or auditor asks how a payroll calculation was validated, "the AI checked it" is not a sufficient answer. Can the tool show its working? Can it produce a structured, reviewable output that a human can stand behind? Auditability is not a feature. It is a requirement.
5. What exactly was it trained for, and when?
A general AI tool is trained for everything, which means it is optimised for nothing in particular. Payroll is a narrow, jurisdiction-specific domain. Social security rates change. Tax thresholds change. Statutory leave calculations change A model that was built on data up to a certain date is silently wrong about everything that changed after that date, with no way to flag it. Any AI tool applied to payroll work should be able to tell you precisely what it was built to do, in which jurisdictions, and how current its underlying knowledge is.
Payroll is adopting AI. It should. The efficiency gains are real and the administrative burden is genuine. But adoption without interrogation is how compliance failures happen.
These five questions are a starting point.
29 March 2026
Deployment-Agnostic AI: Why Training and Deployment Matter for Trust in Regulated Industries
The complete trust problem
to
“Where should this run?”
A healthcare company wants to use AI for document processing.
The compliance team asks one question:
“Where does our data go?”
The vendor answers:
“To our servers, for processing and for continuously improving our models.”
Deal dead.
This scenario plays out every day in regulated industries. But what’s often missed is that compliance teams are not asking a single question. They’re asking two, whether explicitly or not.
Question 1: Will you train your models on our sensitive data?
This is the training trust problem. Organizations in healthcare, finance, and other regulated sectors cannot simply hand over years of sensitive documents for model training, even with strong encryption and access controls.
This is the training trust problem. Organizations in healthcare, finance, and other regulated sectors cannot simply hand over years of sensitive documents for model training, even with strong encryption and access controls.
Question 2: Will our sensitive data leave our infrastructure during actual use?
This is the inference trust problem. Even if training happens elsewhere, routing documents through a vendor’s infrastructure during operation creates ongoing compliance risk and loss of control.
This is the inference trust problem. Even if training happens elsewhere, routing documents through a vendor’s infrastructure during operation creates ongoing compliance risk and loss of control.
Most discussions about AI in regulated industries focus on the first question. But solving training trust alone does not answer where data goes every time the system is used.
When I started building Khaonix, a document AI platform for regulated industries, it became clear that both problems had to be solved, and that solving one would need to enable the other.
Some vendors allow customers to opt out of model improvement. But even then, documents still need to flow through vendor-controlled infrastructure during processing. This means data control and deployment remain architectural questions, not contractual ones.
Why most AI vendors can’t solve both
Traditional machine learning creates an architectural constraint most vendors can't escape.
Machine Learning models need large volumes of real data to achieve good performance. For document AI, that means thousands of actual invoices, payslips, or medical records. But the dependency doesn't stop at initial training. These models require continuous access to production data for retraining, feedback loops from real usage to improve accuracy, and aggregated data across customers to maximize quality.
This creates an architectural requirement for centralized, vendor-controlled infrastructure. Vendors need multi-tenant SaaS deployment because they need ongoing access to customer data flowing through the system.
When vendors offer "on-premise deployment," it typically means accepting compromises: degraded model performance (trained only on your limited data), prohibitive costs (custom training from scratch), or ongoing dependency (model quality degrades without vendor updates).
The vendor isn't being difficult but they're constrained by their architecture. Their training approach requires data access, which requires a specific deployment model.
A different architectural starting point
Khaonix was designed around a different assumption: effective models should not require access to real sensitive data.
This led to what we call a bounded learning framework, where models are trained on synthetic documents rather than real ones.
Synthetic documents are generated to capture structural, regulatory, and system-specific patterns relevant to a given document type, without containing any real personal or sensitive information.
The synthetic data represents the problem space accurately enough to train effective models, without introducing privacy, governance, or data-retention risk.
Why this matters beyond training
Here’s the key insight: when training no longer depends on customer data, deployment no longer needs to preserve data access.
Traditional vendors require centralized deployment not only to process documents, but to maintain feedback loops for model improvement. With bounded learning, once a model is trained, it can operate without relying on production data.
What “deployment-agnostic” actually means
Because Khaonix does not require ongoing access to customer data for training or model improvement, different deployment models become genuinely viable, without architectural compromise:
- Multi-tenant SaaS
Standard enterprise security controls, minimal operational overhead - Private cloud deployment
Running entirely within a customer’s own AWS, Azure, or GCP environment - Dedicated or isolated infrastructure
For air-gapped or ultra-sensitive environments
Traditional “on-prem” offerings often sacrifice model quality, require vendor connectivity, or freeze models over time. With bounded learning, deployment is determined by security and compliance requirements, not by technical dependencies.
Customization becomes viable
Solving both training and inference trust unlocks another consequence: economic customization.
Traditional machine learning struggles with custom models because individual organizations rarely have enough historical data to train them effectively, and the cost of bespoke training is high.
With synthetic data generation, customization becomes a configuration problem. Training data can be generated to reflect specific systems, jurisdictions, regulatory contexts, or internal policies, without relying on years of real documents.
This creates two independent dimensions:
- deployment environment
- model customization
Why this isn’t security theater
A reasonable question: "Couldn't any AI vendor become more secure with better encryption and access controls?"
Not really. Better security controls are valuable, but they don't address the fundamental architectural constraint: traditional ML requires ongoing access to real data, which determines possible deployment models. This isn't about bolting security onto existing architecture. It's about different design choices from the foundation.
When auditors ask "How is this AI trained?" and "Where does our data go during processing?", the answers fundamentally differ:
- Training trust
Traditional: “Trust us with your data while we train.”
Bounded learning: “We don’t need your data.” - Inference trust
Traditional: “Your data must flow through our infrastructure.”
Deployment-agnostic: “Run it where you need.” - Ongoing dependency
Traditional: “We need your data to maintain quality.”
Bounded learning: “Model quality is independent of production data.”
Applicability across regulated domains
The bounded learning approach is intended for document types where:
- real training data is scarce due to privacy constraints
- compliance and explainability are essential
- trust and accuracy determine adoption
The same principles apply to healthcare records, financial statements, legal contracts, insurance documentation, and other regulated documents.
Payroll illustrates the approach, but it does not define its limits.
Conclusion Trust in regulated AI has two dimensions: training and inference. Most approaches address neither fully or focus only on training while ignoring where data flows during actual use.
Bounded learning solves training trust through synthetic data. More importantly, it enables deployment agnosticism, allowing data to remain in customer-controlled environments.
That shifts the conversation from
“Can we trust you with our data?”
“Can we trust you with our data?”
to
“Where should this run?”
That's not marketing language. It's what becomes possible when architectural choices are made with regulated environments in mind from the start.
10 February 2026
Architecture vs. Retrofits: Building Document AI for Regulated Industries
In six months, on August 2, 2026, the EU AI Act’s requirements for high-risk AI systems take full effect. Across regulated industries, procurement teams are already adding a new line to vendor questionnaires:
“How does your AI system comply with the EU AI Act?”
For many AI vendors working with sensitive documents, this is an uncomfortable question. The answer typically involves lengthy explanations about data-processing agreements, anonymization measures, human-oversight concepts, and compliance roadmaps that may never fully address the architectural challenge.
The issue is not documentation.
It’s architecture.
It’s architecture.
We built Khaonix to answer that question differently: with a document AI platform designed for regulated environments from the beginning. Here’s why that distinction matters and what it changes for enterprises operating under strict compliance constraints.
The fundamental problem with traditional document AI
Consider the documents that underpin critical business operations: payroll records, financial statements, medical files, legal contracts, insurance claims. These documents contain precisely the types of personal and sensitive data that GDPR and the EU AI Act are designed to protect.
For task-specific document AI, systems that must reliably extract, verify, or reconcile structured information, traditional machine learning still depends on large volumes of real documents. That creates a fundamental tension:
You need sensitive data to train the system, but using sensitive data to train the system introduces significant privacy, compliance, and governance risk.
Most vendors attempt to manage this tension through data-processing agreements, anonymization pipelines, restricted environments, and layered security controls. While necessary, these measures are ultimately retrofits: compliance safeguards added on top of architectures that were never designed for regulated use cases in the first place.
As regulatory scrutiny increases, these retrofits are becoming harder to defend.
A platform approach: privacy by design
Khaonix takes a fundamentally different approach. Our platform does not train on real documents at all.
Instead, it is built on a proprietary methodology that uses synthetic documents: artificially generated inputs that contain no real personal or sensitive information designed to replicate the structural patterns and edge cases found in production documents. This is not about generating “fake data” and hoping the model generalizes. It is an architectural framework we call bounded learning.
Bounded learning deliberately constrains what the AI is allowed to learn. Rather than attempting to interpret every possible variation of a document, the system is focused on the specific elements required for a defined verification or analysis task.
This intentional limitation delivers three critical outcomes:
- Privacy risk is eliminated by design
No real personal data is used during training. This removes data-retention concerns, breach exposure during development, and dependency on access to sensitive datasets. - Accuracy improves where it matters
A constrained scope allows the model to perform more reliably on the specific fields and relationships that are relevant to the task, rather than spreading capacity across irrelevant variation. - Regulatory alignment is built in
Applications are designed as professional support and verification tools, with clear task boundaries and human oversight, supporting risk-appropriate classification under the EU AI Act.
Payroll as proof: where regulation meets reality
Payroll is a clear example of where this approach matters. Payslips contain names, salaries, tax identifiers, and bank details: some of the most sensitive personal data organizations process. Under the EU AI Act, AI systems that influence employment-related decisions are classified as high-risk, triggering extensive compliance obligations.
PayrollCompare AI, the first application built on the Khaonix platform, applies the bounded learning framework to a concrete, high-value problem: comparing payroll outputs across periods and systems to identify discrepancies during parallel runs, audits, and consolidation.
By design:
- Model training uses only synthetic payslips
- The system supports verification and quality-control workflows
- No automated decisions about individuals are made
- Human oversight is integral to the process
- The tool operates independently of payroll system configuration
For procurement and risk teams, this enables a clear and defensible answer: the system supports human review, does not rely on real personal data for training, and is designed with regulatory boundaries in mind.
Beyond payroll: a platform for regulated documents
The same architectural principles apply across other regulated domains:
- Financial services: statement reconciliation, contract analysis, audit preparation
- Healthcare: document verification, claims support, structured record analysis
- Legal: contract review, due diligence, compliance monitoring
- Insurance: claims comparison, policy analysis, underwriting support
In each case, the documents that most benefit from AI assistance are also the ones subject to the highest regulatory expectations. Architecture-first design resolves this tension.
The shift to compliance-native AI
Regulated industries are not waiting for more powerful AI. They are waiting for AI that works within their constraints.
Not systems that add compliance as an afterthought, but platforms designed from the ground up to respect privacy, define scope explicitly, and enhance, rather than replace, human judgment.
As the August 2026 deadline approaches, enterprises face a clear choice. They can partner with vendors attempting to retrofit compliance onto existing architectures, or they can adopt platforms built specifically for regulated environments.
Khaonix was built for organizations choosing the latter path.
4 February 2026
The Myth of the Single Source of Truth
System fragmentation is often treated as a temporary problem. We tell ourselves that once the migration finishes, once systems converge, a single source of truth will finally emerge.
In practice, that assumption rarely holds.
Modern enterprises operate in fragmented landscapes by design. Phased migrations take years. Vendors change incrementally. Regulatory constraints prevent consolidation. In many cases, multiple systems coexist intentionally.
Fragmentation is no longer the exception. It is the operating reality.
The Trust Gap
As long as systems agree, fragmentation is manageable. The problem begins when they do not.
When records diverge and reports contradict each other, organizations stop trusting “the system” and start looking elsewhere. In those moments, authoritative documents, like statements, notices, payslips, become the final reference point.
Not because they are efficient, but because they are legally and operationally defensible.
Why Generic Document AI Fails Here
This is where generic Document AI struggles. Most models assume stable systems and consistent training data. Fragmentation breaks both.
In a fragmented world, “high accuracy” metrics look acceptable until correctness matters. In regulated environments, post-hoc confidence is not enough. Truth must be:
- Bounded: Limited to what the document explicitly states
- Traceable: Every output linked to specific source content
- Defensible: Verifiable through audit trails
This is the context Khaonix was designed for. Not to replace enterprise systems, but to operate where systems disagree, at the document level, where trust must be established independently.
In fragmented landscapes, competitive advantage does not come from assuming fragmentation will disappear. It comes from building AI that operates in the world as it actually exists.
7 January 2026
ARTICLES
Why We Build Bounded AI
Most AI systems today aim to handle everything: more documents, more formats, more flexibility.
That generality can be impressive. But in domains like payroll, HR, and finance, it introduces a critical problem: you can no longer reliably know when a result is trustworthy.
Generic AI optimizes for breadth. Bounded AI optimizes for dependability.
At Khaonix, we deliberately build bounded AI.Bounded AI means:
- A clearly defined task
- A clearly defined input structure
- A clearly defined output schema
- Explicit handling of out-of-scope cases
This matters because accuracy is only meaningful when the task itself is well defined. If everything is considered “in scope,” correctness becomes difficult to measure and trust becomes fragile.
Bounded does not mean static. Our systems evolve through deliberate scope expansion, introduced only when new document structures and fields can be handled reliably and evaluated properly.
For high-stakes document intelligence, dependability matters more than breadth.
That’s why we build bounded AI at Khaonix.
19 December 2025
