AI Governance for Engineers: Building Verifiable Technical Controls

Most engineering teams treat AI governance as a legal compliance checklist. They assume a PDF of policy guidelines is enough to keep the company safe. But when your application sends customer data to external APIs or trains a model on unverified datasets, a paper policy does not protect you. For engineers, effective governance is not a legal document. It is a set of verifiable, automated technical controls built directly into your software architecture.

Technical AI governance means enforcing data lineage, input/output validation, and model auditability directly in software architecture to comply with regulations like the EU AI Act and DPDPA. Relying on developer compliance instead of automated guardrails is a guaranteed path to failure. If your system depends on a developer remembering not to send personal data to an external API, your architecture is broken.

Why Policy-First AI Governance Fails (and the Systems Approach)#

Paper policies fail because they lack enforcement mechanisms. In a production system, developers move quickly, write code, and integrate APIs. If the only barrier to sending sensitive database records to a public LLM is a training slide deck from last quarter, that barrier will fail.

The regulatory landscape is changing quickly. Under the EU AI Act, failing to comply with prohibited AI practices can cost up to €35 million or 7% of your global annual turnover. In India, the Digital Personal Data Protection Act (DPDPA) 2023 carries penalties up to 2.5 billion INR (about $30 million USD) for failing to safeguard personal data.

Article 12 of the EU AI Act mandates that high-risk AI systems must automatically record logs over their lifetime to ensure traceability. This means capturing activation periods, input data, and system decisions. You cannot meet this requirement with manual reviews. You must design your systems so that every model input, output, and training run is tracked, audited, and verified automatically.

The AI Gateway Pattern: Consolidating Egress Control#

When microservices call external LLM APIs directly, you lose control of your data. One service might use the official OpenAI SDK, another might use a raw HTTP client, and a third might call Anthropic. This scattered access makes it impossible to audit outgoing payloads, enforce rate limits, or prevent sensitive data disclosure.

The solution is an AI Egress Gateway. By routing all external model requests through a single, centralized proxy, you create a single point of control.

The gateway acts as an interceptor. It handles token bucket rate-limiting, validates schemas, and strips personally identifiable information (PII) before the data leaves your network. You can use libraries like Microsoft Presidio or custom regex engines inside the gateway to scrub names, tax identifiers, and credit card numbers.

Here is a simplified example of how an egress gateway handler intercepts and sanitizes an LLM request:

import { PresidioClient } from './presidio';
import { auditLogger } from './audit-logger';
 
interface LLMRequest {
  model: string;
  messages: { role: string; content: string }[];
  userId: string;
}
 
export async function handleLLMRequest(req: LLMRequest): Promise<string> {
  const presidio = new PresidioClient();
 
  // Redact PII from the user input before it leaves the network
  const sanitizedMessages = await Promise.all(
    req.messages.map(async (msg) => ({
      ...msg,
      content: await presidio.redact(msg.content),
    }))
  );
 
  // Log the transaction deterministically for compliance
  await auditLogger.log({
    userId: req.userId,
    model: req.model,
    timestamp: new Date().toISOString(),
    payloadHash: hashPayload(sanitizedMessages),
  });
 
  return sendToModelProvider(req.model, sanitizedMessages);
}

This pattern addresses the core risks highlighted in the OWASP Top 10 for LLM Applications, specifically sensitive data disclosure. It keeps your core application code clean while ensuring that no unredacted customer data ever hits an external API.

Preventing Algorithmic Disgorgement: Consent-Aware Training Pipelines#

The Federal Trade Commission (FTC) has a powerful enforcement tool: algorithmic disgorgement. If you train a model on illegally acquired or non-consensual data, the FTC can order you to destroy the model, its weights, and the algorithms built from that data. This occurred in high-profile cases like In the Matter of Everalbum, Inc. (2021) and FTC v. WW International, Inc. and Kurbo, Inc. (2022).

If your training pipeline cannot trace which user data went into a specific training run, you face a catastrophic choice. When a single user requests data deletion, you might have to delete your entire model because you cannot prove their data was excluded.

To mitigate this risk, you must build consent-aware training pipelines using an immutable data ledger:

1. Tag Raw Data with a Unique Consent ID: When data enters your system, tag it with a consent token linked to your consent manager. If a user revokes consent under GDPR or DPDPA, update this token immediately.
2. Snapshot the Training Dataset: Before starting a training run, snapshot the dataset and generate cryptographic hashes of the included records. Store this snapshot in a secure registry.
3. Map Models to Snapshots: Maintain a metadata registry that maps the final trained model artifact back to the specific cryptographic hashes of the training snapshot.

By establishing this clear lineage, you can prove exactly which records were used to train a model. If a user revokes consent, you can verify whether their data was part of that run and target your retraining efforts instead of destroying your entire model.

Deterministic Guardrails: Dual-Path Architectures Over System Prompts#

Many teams rely on system prompts to enforce safety rules. They write instructions like: "You are a helpful assistant. Do not output customer PII or system passwords."

This approach is fragile. System prompts are easily bypassed using jailbreak techniques, prompt injection, or adversarial inputs. They do not serve as secure boundaries.

Instead, use a dual-path architecture that separates the primary LLM generation from the safety evaluation layer. This approach makes your responsible AI efforts verifiable.

In this system, you run a lightweight, deterministic classifier model like Llama Guard, or a policy engine like NeMo Guardrails, in parallel with or immediately after the primary LLM call.

If the safety classifier flags the primary LLM's output as a policy violation, the gateway intercepts the response. Instead of returning the model's output to the user, the system returns a pre-defined, static fallback message.

This dual-path setup also provides the foundation for model monitoring and AI observability. By logging the decisions of your safety classifier, you can track drift, detect adversarial attacks, and understand how often your system encounters policy violations.

Embedding-Level Data Lineage: Handling Deletions in RAG Systems#

Retrieval-Augmented Generation (RAG) systems present a unique compliance challenge. When a user requests that you delete their data, deleting their raw records from your relational database is not enough.

If you have converted those records into vector embeddings and stored them in a vector database, those embeddings still exist. Retaining vector embeddings of deleted user data violates GDPR deletion mandates and Section 7(3) of India's DPDPA 2023, which requires data to be accurate, complete, and consistent if it affects decisions about the individual.

To solve this, you must build a two-way metadata link between your primary database and your vector database:

1. Store Metadata Attributes: When you chunk and embed a document, store the source document ID, user ID, and consent status as metadata attributes alongside the vector embedding.
2. Build a Deletion Cascade Worker: Create an asynchronous worker that listens to your primary database deletion events.
3. Purge Vector Chunks: When a user deletes their account or documents, the worker must query the vector database using the metadata filters and purge all matching vector chunks immediately.

import { vectorDb } from './vector-store';
import { db } from './primary-db';
 
interface DeletionEvent {
  userId: string;
}
 
export async function processUserDeletion(event: DeletionEvent): Promise<void> {
  // 1. Delete raw user records from primary database
  await db.users.delete({ id: event.userId });
 
  // 2. Query and purge all vector embeddings associated with the user ID
  await vectorDb.deleteMany({
    filter: {
      userId: { $eq: event.userId }
    }
  });
}

This approach ensures that your vector search index remains clean and compliant, preventing deleted data from resurfacing in future LLM prompts.

Where to Start: A Phase-One Implementation Plan#

You do not need to build all these controls in a single sprint. Instead, focus on building runtime visibility first.

• Phase 1: Deploy a Basic AI Gateway: Set up a simple proxy container to intercept and log all LLM requests and responses. This gives you baseline visibility into what data is leaving your network, helping you identify PII leaks and track API costs.
• Phase 2: Implement Embedding Lineage: Update your RAG ingestion pipeline to tag every vector chunk with a user ID. Build a simple cleanup script to purge these vectors when users delete their accounts.
• Phase 3: Integrate Parallel Safety Classifiers: Replace fragile system prompts with a dedicated, lightweight evaluation model to screen inputs and outputs.

Governance becomes real only when it is connected to logs, tests, permissions, monitoring, and release processes. Bias reviews, drift detection, red-teaming, and incident response should live inside the engineering workflow. To take the first step toward verifiable compliance, look at your architecture today and identify where LLM calls are happening. Spin up a lightweight proxy container to audit those external requests, and start moving your guardrails from paper policies into your runtime network layer.