EU AI Act Compliance Is a Pipeline, Not a PDF

Turning the EU AI Act and ISO 42001 into automated CI/CD gates, risk classification, and cryptographic provenance — not a last-minute audit binder.

Kovcheg's credit module drafts decisions on customer applications. Under the EU AI Act, this is not an "assistant" — it is a high-risk AI system. Creditworthiness assessment of individuals is explicitly named in Annex III, which moves the system into a different legal class: a mandatory risk management system, technical documentation, logs, human oversight, registration. In parallel, the text assistant generating replies to customers falls under Art. 50 — transparency for AI-generated content. One system, two different sets of obligations.

Continue reading “EU AI Act Compliance Is a Pipeline, Not a PDF”

AI Quality, Drift & Fairness: continuous evaluation and bias mitigation

A provider quietly updates the base model. The API is unchanged, behavior shifts, and no one deployed a thing. Continuous evaluation and LLM-as-a-judge are how you catch it before compliance asks why approvals in region N dropped.

A provider quietly updated the base model. The API is formally the same, the version string is unchanged — but behavior shifted: Kovcheg started inventing loan terms not present in the documents slightly more often, and treating applications from one region slightly more strictly. No one changed anything in the code. A month later it surfaces as a spike in complaints and a question from compliance: "Why have approvals in region N dropped?" This is what silent degradation looks like — the most common way an AI system's quality erodes without a single deployment.

Continue reading “AI Quality, Drift & Fairness: continuous evaluation and bias mitigation”

Governance Operating Model & AIMS: How to Assemble a Control Plane That Survives Entropy

Technical controls degrade without an operating model. Here is how to assemble every plane into an AI Management System with policy-as-code and auto-generated evidence.

Imagine every control plane is built. PII is masked. RAG respects permissions. Guardrails block prompt injections. The audit trail writes to immutable storage. Budgets hold. Content is labeled. Quality is measured. The supply chain sits under an AIBOM. The agent sits behind a policy gate. Six months in, an ISO 42001 audit arrives — and there is nothing to prove, because ACL sync silently broke in March, the golden dataset hasn't been refreshed since launch, the kill-switch has never been tested, and the credit module formally has no owner. The technical controls went stale. Not from an attack. From nobody having been assigned to maintain or audit them.

Continue reading “Governance Operating Model & AIMS: How to Assemble a Control Plane That Survives Entropy”

FinOps & Resilience: How to Run AI in Production Without Going Bankrupt or Falling Over

A gateway with budgets, semantic caching, and fallback is the only thing standing between your AI workload and a six-figure overnight bill or a cross-tenant data leak.

A B2B SaaS team turned on semantic caching with a similarity threshold of 0.88 and a global namespace to save on tokens. The cache returned a Tier-1 customer's cancellation summary during a Tier-3 customer's session. Two different requests were "similar enough" by embedding distance — and a cost optimization became a cross-tenant data leak. The team rolled back to exact-match caching.

Continue reading “FinOps & Resilience: How to Run AI in Production Without Going Bankrupt or Falling Over”

AI Supply Chain Security & Shadow AI: Components and the Kill-Switch

Know what your AI system is built from, block unverified components, and stop an autonomous agent instantly in an emergency.

Consider one bank. An engineer downloads a fine-tuned model from a public hub — a pickle checkpoint with a silent backdoor that executes code when the weights load. An employee finds the bank's internal AI tool slow, so they copy a customer statement into a public chatbot — corporate data has left for Shadow AI. The bank's agentic branch starts behaving anomalously, and it turns out there is nothing to stop it with. Per a 2026 Saviynt report, only 5% of security leaders are confident they could contain a compromised agent.

Continue reading “AI Supply Chain Security & Shadow AI: Components and the Kill-Switch”

How to Keep Customer PII Out of LLM Provider Logs

An in-flight anonymization gateway and Zero Data Retention contract as two lines of defense against GDPR violations through AI.

An employee pastes a customer's bank statement into an AI assistant to draft a reply. The statement contains a name, passport number, IBAN, address, and transaction amounts. The assistant calls a cloud model. From this point, the customer's PII has physically left the perimeter and sits in the provider's infrastructure — at minimum in active processing, and by default in abuse-monitoring logs for 30 days. The customer never consented to this transfer.

This is the single most common way companies violate GDPR through AI. Not through malice, but because nothing stood in the request path to strip the data before the model call.

Continue reading “How to Keep Customer PII Out of LLM Provider Logs”

Auditability & Reproducibility: How to Prove to a Regulator What Your AI Actually Did

Six months after launch, a regulator asks why your AI denied a loan. Without an immutable trace of every call, you have no answer — and a high-risk system that is non-compliant.

Six months after your loan-approval system goes live, a regulator submits a formal request. A customer is appealing a denial dated May 12. The question is simple and lethal: why did the AI recommend denial?

If your answer is "the model decided so," you are already non-compliant. A high-risk system under the EU AI Act requires a reconstructible chain of evidence: the exact system prompt, the customer data pulled in, the model version, the guardrails that fired. Without an immutable trace of every call, the decision is unprovable, and the system cannot legally operate.

Continue reading “Auditability & Reproducibility: How to Prove to a Regulator What Your AI Actually Did”

Enterprise Access Control: Securing RAG with RBAC and ABAC

Naive RAG collapses data at different access levels into one index. Here is how to build identity-aware filtering so an employee sees through the assistant exactly what they can access in the source systems.


# Enterprise Access Control: Securing RAG with RBAC and ABAC

An operations clerk asks the assistant: "What were the terms on the last deal with this customer?" The assistant searches the RAG index, finds a document from the legal department, and hands it over. The clerk has no access to that document in SharePoint. They didn't hack anything; they just asked the bot, and the bot isn't a rights subject. The retriever found the most relevant hit, the model summarized it. This is how AI produces **privileged leakage**: data the person has no access to at the source flows out through the assistant anyway.

<!--more-->

This is a fundamental defect of naive RAG. Indexing collapses data at different access levels into a single vector index, and semantic search doesn't know about permissions. The fix is an **identity plane**: RAG must return answers strictly within the rights the user actually has in the source systems — Confluence, Jira, SharePoint, PostgreSQL — and that must be provable.

## The business goal

A user gets from RAG exactly what they're allowed to see in the source systems — no more. Three promises anchor the work:

1. No answer contains data the asker lacks access to at the source.
2. Access revocation at the source propagates into RAG within minutes, not days.
3. When a regulator or auditor asks "why did this employee see this," the answer lies in the permissions, not in the retriever's luck.

## What drives the work: threat and regulator

- **Confused deputy**: the AI acts under its own identity with the full permissions of the index, rather than on behalf of the user. A classic internal-leak vector.
- **OWASP LLM**: LLM02 (Sensitive Info Disclosure), LLM06 (Excessive Agency — when RAG tools reach into systems).
- **GDPR / banking secrecy**: access to PII without a legal basis is a violation even inside the company.
- **AI Act audit**: access to high-risk data must be logged and justified.

## The architectural pattern: Identity-Aware Hybrid Filtering

The 2026 enterprise-architecture consensus: don't choose between fast pre-filtering and precise authz — combine both.

JWT(user: groups, roles, tenant_id) │ ▼ [1] Pre-filter in the vector DB by ACL metadata (recall, cheap) │ candidate chunks ▼ [2] FGA post-check: CheckBulkPermissions against each chunk's source document │ permitted chunks (precision, ReBAC/ABAC) ▼ [3] LLM → [4] OPA post-filter on the answer (field masking, forbidden combinations)

Continue reading “Enterprise Access Control: Securing RAG with RBAC and ABAC”

Manifesto: AI Governance as a control plane, not a PDF policy

Governance that can’t be bypassed technically is not a document — it’s a control plane. Every model call physically passes through PII masking, access control, guardrails, and audit.

There are two ways to do AI governance. The first is to write a policy. A forty-page document: responsible AI principles, a committee, a role matrix, a requirement to "use AI ethically." It gets signed, filed in SharePoint, and revisited at the next audit. The second way is to build governance into the request path: every model call is physically unable to bypass PII masking, access control, guardrails, limits, and audit, because they stand in the way of the packet, not in the developer's head.

This is about the second way. The thesis is simple and blunt: governance that can't be bypassed technically is not a document — it's a control plane.

Continue reading “Manifesto: AI Governance as a control plane, not a PDF policy”

Chat, CLI, SDK, or Raw HTTP: Choosing the Right LLM Access Layer

The same LLM behaves differently behind four interfaces. The difference is not the model — it’s the orchestration around it.

The same prompt can be sent to a model in four ways: typed into a web chat, handed to a console agent, called from code via an SDK, or assembled as a raw HTTP request. The response will look similar. The system built around that response will differ wildly in latency, cost, predictability, and security — and that difference lives not in the model, but in the layer you use to reach it.

Continue reading “Chat, CLI, SDK, or Raw HTTP: Choosing the Right LLM Access Layer”