# Regulatory Compliance Controls

Technical and procedural controls implementing regulatory obligations — retention, access, audit trails, approvals and evidence.

**Rests on:** Risk Tiers

**Leads to:** Protected Attributes, Unity Catalog Governance

*Data Engineering and Analytics · Data Governance*


## Why learn this

Regulatory compliance controls are the set of technical and procedural measures that turn legal obligations — like 'keep records for seven years' or 'only authorised people may see this' — into things a computer system actually does and can prove it did. This matters directly for building AI: a model trained on regulated data, or used to generate answers that must be traced back to source documents, only counts as acceptable if the controls around it are real and auditable. Master this concept and you will understand why every enterprise AI system has access limits, approval steps, retention periods and audit trails as first-class parts of its design — not optional extras. It will also let you speak the language of compliance officers and engineers in regulated domains like banking and healthcare, and it is the foundation for the deeper topics of Data Privacy Compliance and AI Governance and Regulation, which you will see next. Concretely, after this page you will be able to look at a system description and point to exactly which controls exist, whether they produce evidence, and where the gaps are.


## The intuition

Think of a bank. A bank cannot simply decide to keep your transaction records forever, and it cannot let any employee see your account balance just because they are curious. Rules decide these things: laws like the Income Tax Act, RBI guidelines, and data protection regulations. But stating a rule is not the same as making it real. 'We must retain records for 8 years' is a policy written in a document; what actually makes it happen is a technical control — a retention schedule in software that deletes or archives files after 8 years, and logs that it did so. Similarly, 'only authorised staff may access customer data' becomes real through access controls — passwords, roles, and permission lists — and 'we must be able to show who did what' becomes real through audit trails that record every access and change. A control, then, is a mechanism: a piece of configuration, a software feature, or a process step that enforces a rule and, crucially, leaves behind a trace that the rule was enforced. Without controls, regulations are just suggestions; with them, they become operational facts.


## An analogy

Imagine a government office that issues passports. It does not just have a rule 'only the right officer may approve a passport' — it has a physical control: a locked room, a stamp with a unique number, and a logbook where every application and every approval is recorded. The lock on the door is an access control — it stops the wrong people getting in. The stamp and the logbook together are an audit trail — they record who did what, when, and with which authority. The approvals themselves are a workflow — a checklist that must be completed in order before a passport is issued. And the retention of files — how long the office keeps the old applications — is decided by law and enforced by what they do with the paperwork. This analogy carries almost all the way. In software systems, the lock becomes a permission system, the logbook becomes an audit log (a file or database that records events), and the approval checklist becomes a series of steps in a workflow tool. Where the analogy breaks down: in software, controls can be automated and enforced with perfect precision — a system can refuse an action outright because of a rule, whereas the passport officer might occasionally forget to check the logbook or could be overruled by a supervisor. Also, in software, evidence is generated continuously and can be stored inexpensively, so audit trails can capture far more detail than any paper log. The core difference is that software controls are deterministic — they do not rely on human recall or judgment — which is exactly why they are so valuable for compliance.


## Definition

Regulatory compliance controls are the technical and procedural measures — such as retention schedules, access permissions, audit trails, and approval workflows — that implement regulatory obligations and produce verifiable evidence that those obligations were met.


## How it connects

This concept sits inside Data Governance, which you have started studying. Data Governance is the umbrella of policies, ownership, catalogues and controls that determine who can access which data and how that is documented. Regulatory compliance controls are the 'controls' part of that picture: they are the mechanisms that enforce the policies. You have also seen Unity Catalog Governance, which is a tool that implements centralised access control and lineage — that is a specific technical control for data access. This page gives you the general idea of what a control is and why it must produce evidence, which will make Unity Catalog's permission model and audit features make more sense. It also connects to the idea of responsible data handling that appears when you later study Data Privacy Compliance and AI Governance and Regulation.


## Common misconceptions

**Controls are just paperwork** — If we have a policy document that says we keep records for 8 years, that is compliance.

A policy document is a statement of intent. It does not actually cause any data to be retained or deleted. Only a technical control (a retention schedule in software, or a manual process with a checklist and sign-off) can enforce the rule and prove it was enforced. In fact: Compliance requires a mechanism that executes the obligation and leaves evidence — a log, a timestamp, a signed approval. Without that, the policy is just words.

**Access control is enough** — If we limit who can access the data, we have done our compliance duty.

Access control is only one piece. Regulations also cover retention, audit trails, approvals, and evidence that the controls were followed. A system can have perfect access permissions but keep data forever (failing retention) and have no log of who changed a record (failing auditability). In fact: Access control is one of several control families. The full set — retention, access, audit, approvals, evidence — must work together.

**Audit logs are just for debugging** — An audit log is like a debug log; we can turn it on when we are having issues.

Debug logs typically record errors and warnings, and are often turned off in production. Audit logs are a compliance requirement: they must be always on, capture every relevant action (who, what, when, from where), and be tamper-evident. Treating them as optional debugging aids is a compliance failure. In fact: Audit logs are a formal control. They must be continuously active, include sufficient detail to reconstruct actions, and be protected against unauthorised modification.

**Approvals can be an afterthought** — We will add an approval step in the UI, and that covers the workflow.

A UI-only approval is easy to bypass — a user can call the underlying API directly and skip the UI. Also, an approval step without a logged decision and a linkage to the action is not evidence. The approval must be enforced at the system level, and its outcome must be recorded. In fact: An approval workflow must be a control at the service level — enforced by the backend, not just the front end — and it must log the approver, the timestamp, and the action approved.

**Compliance is a burden, not a design input** — Compliance is extra work we do at the end, after the system is built.

Adding controls after the fact is expensive and often incomplete — you have to retrofit access checks, retroactively log, or rewrite workflows. In regulated domains, compliance requirements are a design input from the start: the data model, the API signatures, and the workflow all need to be shaped by the obligations. In fact: In regulated domains, compliance controls are a design input. You plan the audit fields into the database schema, the permission model into the architecture, and the approval steps into the workflow, before you write much code.


## In short

Regulatory compliance controls are the mechanisms that make legal and policy obligations operational: they enforce access rules, retention schedules, approval steps, and audit trails — and they produce evidence that they did so, because in a regulatory investigation a control that is not logged is as good as absent. They are a design input, not an afterthought, and they are especially critical in AI systems that handle regulated data or take consequential actions.


## Where this is used

Regulatory compliance controls appear everywhere in modern AI systems, though the word 'compliance' might not be in the marketing material. In large language models, the most direct application is in how the model is accessed and how its outputs are governed. A regulated company cannot let an employee paste confidential customer data into a public ChatGPT-like tool without control. So they deploy an internal version behind access controls — a single sign-on system and a role-based permission layer — and they add an audit trail that logs every prompt and every generated response, tied to the user. They also add an approval workflow: a human may need to review and approve any output that will be sent to a customer or filed with a regulator. This is exactly what the book 'Large Language Models in Finance' describes: answers must be traceable to admissible evidence spans in source filings, so the system embeds a citation mechanism that makes each answer reference the exact paragraph — that itself is a compliance control, because it ensures every AI-generated answer can be checked against the original document. In retrieval-augmented generation (RAG), a model retrieves chunks of text from a knowledge base to answer a query. A compliance control here is the retention schedule on that knowledge base: if the knowledge base contains financial filings that must be kept for a certain period, the control automatically deletes or archives old documents and logs the deletion. It is also an access control: the retrieved chunks may come from different documents, and the system must check, per user, whether that user is allowed to see each retrieved chunk before including it in the answer. That sounds complex, and it is — a developer would write a permission check in the retrieval pipeline, something like: loop through the ranked chunks, and for each one, verify the user has the 'read' permission on the source document; if not, drop the chunk. In agentic systems — AI that can plan and call tools — compliance controls become even more important, because the agent might take actions on its own. A developer will add an approval workflow: before the agent executes a tool call that has side effects (like sending an email, transferring money, or deleting a file), the system pauses and asks a human to approve. That is a technical control — a 'human-in-the-loop' step. Every such action is written to an audit log with a timestamp and the user context, so that later you can prove what the agent did and who authorised it. In small models running on devices, like a smartphone app that classifies images or transcribes speech, the control is often about data minimisation — the model should not send raw audio or images to a server unless necessary. A technical control is the on-device processing setting that ensures the data never leaves the phone, and a logging mechanism that records when the model runs, without storing the content. This satisfies regulations like GDPR's principle of data minimisation. In everyday applied machine learning, such as fraud detection or recommendation systems, compliance controls appear as access control on the training data, retention of that data, and audit trails for model decisions. For example, a bank's fraud model may have a control that logs every prediction along with the features used, so that if a customer disputes a decision, the bank can produce an audit trail of what the model saw. The developer would write code to write to an audit table after every inference call. The framework a developer reaches for is often whatever the organisation's governance platform is — for data access, Unity Catalog or Apache Ranger; for audit logs, a logging system like AWS CloudTrail or a custom table in a database; for approvals, a workflow engine like Apache Airflow or a dedicated compliance tool. When these controls are done badly, the failures are specific and costly: an audit trail that only records 'success' and misses the context, so an auditor cannot reconstruct what actually happened; an access control that is too coarse (e.g., 'all analysts can see all data'), which causes a data breach and a fine; a retention schedule that is not actually enforced, so old data sits in a backup and violates deletion obligations; an approval workflow that can be bypassed by a direct API call, making the audit trail meaningless. These are not abstract warnings — they are exactly the things that get companies fined and models shut down. That is why the control must produce evidence, not merely exist: a control that isn't logged is as good as absent in a regulatory investigation.


---

Read this on the web: https://basavapurushottam.com/learn-ai/regulatory-compliance-controls
