Compliance and Regulated Industries
Built for industries where AI answers must be traceable and auditable. PII detection, source citations, tenant isolation, and full observability by design.
Most AI platforms say they take security seriously. Then you ask for the architecture diagram and they change the subject.
I have sat in those meetings. A Dutch government agency, early in the project, before we wrote a single line of pipeline code. The first requirement was not "make it fast" or "make it smart." It was: no citizen data reaches the LLM. Period. Not encrypted. Not anonymized after the fact. Never sent.
That conversation shaped everything I built after it.
Why Regulated Industries Get Stuck
The pressure to adopt AI is real. Finance, healthcare, government - they all see the productivity gains. Internal policy lookup, document retrieval across systems, compliance checking. These are exactly the use cases where RAG delivers.
But most AI tools are black boxes. A user asks a question. Something happens. An answer appears. Try explaining that pipeline to the Dutch National Bank. Or to your CISO. Or to the patient whose medical record number might have been sent to OpenAI's API.
The concerns are specific. Financial institutions cannot risk BSN or IBAN numbers reaching third-party providers. Government agencies handling citizen data have sovereignty requirements that a privacy page does not satisfy.
Organizations need AI. Regulators need transparency. Most tools force you to choose.
I built Knowably so you do not have to.
PII Detection: Why I Chose Regex Over LLMs
This is a design decision I get asked about. Why use regex-based PII detection when you could use an LLM to detect sensitive data more flexibly?
Because determinism matters more than flexibility when a regulator is asking the questions.
When we started working with Dutch government data, I needed to guarantee that a BSN number would be caught. Not "probably caught." Not "caught 98% of the time in our benchmarks." Caught. Every time.
BSN detection uses the 11-check algorithm - the same deterministic mathematical validation Dutch government systems use internally. Every valid BSN is caught. Random nine-digit sequences pass through. IBAN detection validates against the ISO 13616 mod-97 checksum. Both use regex to find candidates, then mathematical proof to confirm them. No probability scores. No confidence intervals.
Detected PII is replaced with [VERWIJDERD] (Dutch for "removed") and stripped before any external API call. The LLM never sees the original value.
Could an LLM-based approach catch more edge cases? Probably. But when a regulator asks "will this always catch a BSN number that matches the 11-check?" the answer needs to be yes. Not "probably." Not "in our testing." Yes.
Technical details on input sanitization and PII detection
Prompt Injection: Hard Fail by Design
I made a deliberate choice here that not everyone agrees with: when prompt injection is detected above the threshold, the request throws an exception. Hard stop. No fallback. No "here's a safe response instead."
Security over availability.
The scoring system evaluates queries against regex patterns covering both English and Dutch injection attempts. Each match adds to a cumulative score. Base64-encoded payloads add extra weight - a common technique for hiding instructions. The total is compared against a configurable threshold per agent.
That configurability matters. A government agency processing citizen requests sets a low threshold - aggressive blocking, fewer risks. An internal agent for trusted employees can be more permissive. The tradeoff between security and usability is yours to tune, not mine to hardcode.
Full details on prompt injection prevention
Auditability: Tracing Every Query
Can your auditor reconstruct exactly what your AI system did last Tuesday at 14:32?
Not roughly. The full chain. What the user typed. How the input was sanitized. Whether PII was detected. What documents were retrieved. What the model generated. Which sources it cited.
I built and maintain the axyr/laravel-langfuse package specifically because I needed this for Knowably. Every query generates a complete trace. Every pipeline step - sanitization, PII detection, injection scoring, search, reranking, generation - is logged as a span with inputs and outputs.
The trace ID is stored on every assistant message in the database. Given any chat message, you can pull up the complete record of how that answer was produced.
For organizations that cannot send observability data to external services, Langfuse self-hosts. All trace data stays on your infrastructure.
Source Citations as Compliance Infrastructure
Source citations are not a nice-to-have in regulated industries. They are infrastructure.
Every document chunk sent to the LLM is tagged with a unique ID. The model cites these IDs in its response. After generation, citations are extracted and stored, creating a direct link from every claim back to a specific document passage, data source, and knowledge base.
When DNB asks how your AI system arrived at a particular answer about AML procedures, you show them the trace. The query, the retrieved documents, the specific paragraphs the answer was based on, the model that generated it.
When a citizen requests information about how a government decision was informed, the trail from AI answer to source document to original policy is complete.
This is what compliance teams actually need. Not a SOC 2 badge. A paper trail.
Data Sovereignty: When Nothing Leaves the Network
Some organizations cannot send data to external LLM providers. Full stop. Not "prefer not to." Cannot.
I built Ollama support as a first-class provider for exactly this reason. Run open-source models on your own hardware. Configure Ollama as both the chat model and the pipeline model for reranking and query expansion. Every AI operation stays on-premises.
Combined with self-hosted Langfuse, the entire stack - application, models, traces - runs within your infrastructure. For organizations that want managed cloud without data leaving their VPC, AWS Bedrock support is there too.
Where This Gets Specific
Financial Services
A compliance officer at a Dutch financial institution queries the internal policy agent about AML procedures. She accidentally pastes a client's BSN number.
The BSN is caught by the 11-check, replaced with [VERWIJDERD], and never reaches the LLM provider. The answer comes back citing the specific sections of the AML policy document. The full interaction is traced.
BSN and IBAN stripping prevents customer financial data from leaving the controlled environment. Source citations let compliance officers verify that AI-generated guidance traces back to approved policy documents, not the model's training data.
Government
This is the use case I built Knowably around. Dutch government agencies, staff who interact with citizen data daily.
BSN detection uses the same 11-check the government uses internally. Each agency gets its own dedicated database. Self-hosted deployment with Ollama keeps all citizen data within government infrastructure.
I also built a Rechtspraak MCP server for Dutch case law. The broader goal is the same: making Dutch legal and government data accessible through AI without compromising data sovereignty.
Healthcare
I have not deployed Knowably in a healthcare setting yet. If you are evaluating this for healthcare, reach out - I would rather have that conversation honestly than hand you a checkbox matrix.
The Architecture Is the Compliance
I did not build Knowably and then add compliance features. The compliance requirements shaped the architecture from the first conversation.
Separate databases per tenant. PII stripped before any API call. Deterministic detection over probabilistic. Hard failure on injection. Full observability on every query. Source citations on every answer. Self-hosted deployment when the data cannot leave.
These are not features. They are the foundation.
Explore the security architecture | Configure AI agents | Book a Demo